Kick Off
folknology
repository and actually create some code. This gets over the deadlock
of waiting for Xmos to commit. We should choose a code project not yet
covered by the current xmos examples, that way it will be useful and
in addition to what exists, taking nothing away. It would then be able
to set an example to Xmos. It will also enable the foundation to
troubleshoot early issues and formulate a working pattern.
So all we need is a good idea, thoughts?
regards
Al
Al Wood
How about a quad mode SPI library, its not to big, not to ambitious ,
fairly accessible for all to work on and very useful?
Kaspar Bumke
This would be useful for your Amino project and it looks like(as you already know) BEBDigitalAudio is already working on fixing the bug with multiple UDP listeners:https://www.xcore.com/forum/viewtopic.php?f=10&t=877
Al Wood
stack hidden behind their info wall
Al Wood
kick off with. (believe you me I would love a decent network stack!)
russ
a pretty big enchilada that could divide our efforts at a key moment.
A good TCP/IP requires either a lot of coding from scratch, and
therefore maintenance and test efforts, or one must integrate a well
designed stack, which also requires tracking fixes from upstream.
Since it's clear that more TCP/IP work is being done inside XMOS,
should we wait until after the motor controller release, to see if
there is any advance there? Or will xmos move to a common TCP/IP that
it maintains, and ensure that all future apps run on top of it?
I am also interested in Al's quad SPI idea. By this, Al, I take it you
mean a low-hardware requirement, efficient, general purpose driver
that reliably manages 4 SPI devices? I may need a multiple channel
ADC design soon, so grouping around this requirement would suit me
well, and I could contribute code and resources towards hardware
design for proof of concept.
Best,
--r
On Nov 21, 9:22 am, Al Wood <a...@folknology.com> wrote:
> I was trying to find something a little smaller and more 'neutral' to
> kick off with. (believe you me I would love a decent network stack!)
>
> On 21 November 2010 17:20, Al Wood <a...@folknology.com> wrote:
>
>
>
>
>
>
>
>
>
> > I also know that Xmos have a completely new version of the tcp/ip
> > stack hidden behind their info wall
>
Al Wood
> I'd love to have a good TCP/IP stack, too. But I also agree that it's
> a pretty big enchilada that could divide our efforts at a key moment.
> A good TCP/IP requires either a lot of coding from scratch, and
> therefore maintenance and test efforts, or one must integrate a well
> designed stack, which also requires tracking fixes from upstream.
>
> Since it's clear that more TCP/IP work is being done inside XMOS,
> should we wait until after the motor controller release, to see if
> there is any advance there? Or will xmos move to a common TCP/IP that
> it maintains, and ensure that all future apps run on top of it?
>
Agreed with above, lets see what Xmos release with the Motor kit..
> I am also interested in Al's quad SPI idea. By this, Al, I take it you
> mean a low-hardware requirement, efficient, general purpose driver
> that reliably manages 4 SPI devices? I may need a multiple channel
> ADC design soon, so grouping around this requirement would suit me
> well, and I could contribute code and resources towards hardware
> design for proof of concept.
>
Quadmode is an enhanced SPI mode. it adds 2 extra pins. One negotiates
using standard SPI and switches into quad mode. Quad mode itself
transfers nibbles with the clock rather than a single bit, it enables
relatively high data rates to be achieved with ADCs, memory etc..
device select works in the same way as SPI as those pins are reused.
It is backward compatible with SPI which is why its a useful
interface.
Kaspar Bumke
Although I have no need for Quad Mode SPI at the moment, a good general purpose SPI interface with an easy API would be useful.
I was trying to find something a little smaller and more 'neutral' to
kick off with. (believe you me I would love a decent network stack!)
On 21 November 2010 17:20, Al Wood <a...@folknology.com> wrote:
> I also know that Xmos have a completely new version of the tcp/ip
> stack hidden behind their info wall
>
> On 21 November 2010 17:18, Kaspar Bumke <kaspar...@gmail.com> wrote:
>> I am most interested in the TCP/IP stack at the moment. I know it is already
>> and XMOS project, nevertheless a fork or starting from scratch, done right,
>> could be a good project and a good illustration of the problem with XMOS
>> developing behind the info wall.
>>
>> This would be useful for your Amino project and it looks like(as you already
>> know) BEBDigitalAudio is already working on fixing the bug with multiple UDP
>> listeners:https://www.xcore.com/forum/viewtopic.php?f=10&t=877
>>
>> On 21 November 2010 17:04, Al Wood <a...@folknology.com> wrote:
>>>
>>> On 21 November 2010 16:53, folknology <a...@folknology.com> wrote:
>>> > I think the best way to kick this off is to set up a project
>>> > repository and actually create some code. This gets over the deadlock
>>> > of waiting for Xmos to commit. We should choose a code project not yet
>>> > covered by the current xmos examples, that way it will be useful and
>>> > in addition to what exists, taking nothing away. It would then be able
>>> > to set an example Xmos. It will also enable the foundation to
>>> > troubleshoot early issues and formulate a working pattern.
>>> >
>>> > So all we need is a good idea, thoughts?
>>> >
>>>
>>> How about a quad mode SPI library, its not to big, not to ambitious ,
>>> fairly accessible for all to work on and very useful?
>>>
>>>
>>>
>>> --
>>> http://www.folknology.com
>>
>>
>
>
>
> --
> http://www.folknology.com
>
Al Wood
> Ok fair enough. I still think we should host a public repo with xtcp v3 to
> allow us to document it and share "hacks" that make it work for us. But I
> can see why the main focus of this foundation should be its own project.
>
> Although I have no need for Quad Mode SPI at the moment, a good general
> purpose SPI interface with an easy API would be useful.
>
SPI would have to be included of course
Kaspar Bumke
Are there any other suggestions as to what that major project could be besied quad mode SPI?
Russ Ferriday
On Nov 21, 2010, at 4:43 PM, Kaspar Bumke wrote:
> Should we have a vote as to wether to host and contribute to a version of xtcp as well as a project completely of our own?
Yes, but I think that people who vote for it, need to be in a position to help with the considerable effort.
On that topic, my recent experience of the TCPIP stack on Microchip has been very positive.
It looks as though it might be a (relatively) easy port, since it's just a big fat polling loop. This might not seem very smart, but I'm getting pretty high throughput (5MByte/s outbound, and about 10MByte/s in prospect, if I adjust for performance.)
I think I would prefer to do this than take a shim on top of a layer on top of a wrapper on top of uIP or whatever, especially if that whatever has some exotic threading feature.
The main feature is there seem to be very few mysteries.
Then I would want to wrap it with a channel-based protocol, so it can collaborate with any process.
>
> Are there any other suggestions as to what that major project could be besied quad mode SPI?
>
I don't have one at the moment. I wonder what XMOS has on the back burner that they have no manpower for?
--r.
Russ Ferriday
On Nov 21, 2010, at 10:00 AM, Al Wood wrote:
> Quadmode is an enhanced SPI mode. it adds 2 extra pins. One negotiates
> using standard SPI and switches into quad mode. Quad mode itself
> transfers nibbles with the clock rather than a single bit, it enables
> relatively high data rates to be achieved with ADCs, memory etc..
> device select works in the same way as SPI as those pins are reused.
> It is backward compatible with SPI which is why its a useful
> interface.
Ah, right. I'm behind the curve on that one.
Would be great to know if there is one of these being baked on the other side of the fence.
So yes, I'd still be interested in the outcome of that. It would be good to look at all likely hardware needs, and come up with a hardware abstraction so that the code could be used across devices.
And having a test suite to run after new features are added would be essential... We need to acknowledge the reality that reliability comes from testing, and testing is painful. Simplying testing is worth it weight in gold. We would start to see core drivers, and little plugins/adapters being written to adapt to new hardware versions.
--r
Russ Ferriday -- Systems Architect & Entrepreneur
CEO Topia Systems Ltd.
ru...@topia.com -- +1 (805) 910 7877 -- www.topia.com
Russ Ferriday
--r
On Nov 21, 2010, at 4:43 PM, Kaspar Bumke wrote:
> Are there any other suggestions as to what that major project could be besied quad mode SPI?