Re: [Embedlets-dev] RE: (I2C?) SPI is *much* faster (and much less flexible)

[Gregg G. W. <gr...@sk...>]

>> I2C is about 100 kbits (if memory serves), SPI can be a few MBits. If you 
>> have to pick a standard for speed SPI wins.
>
>I would say to choose flexibility over speed in every case except those that
>absolutely need maximum speed.  As an example, C is the current language speed
>standard and yet slow, flexible Java is replacing it for most applications
>where maximum speed is not the main design constraint.

If you want to create a peer to peer SPI based architecture that allows 
arbitrary interconnects, then you would do the following.

A thread, on the master would loop continuously with 1-100ms (depending on 
time resolution needed), requesting a single bit from each SPI slave.  When it 
gets a one bit, it would put that slave number in a ready-list, and then stop 
polling it.  This would be one threads responsibility, and this thread would 
be called the 'carrier detect' thread.

Slaves in the ready-list are now ready to transfer packets between devices.  
The ready-list thread would start clocking bytes from the slaves, and feeding 
them any traffic that is destined for them.  Each slave in the ready-list 
would have a packet queue that would be composed of a several bytes of buffer 
(slave count + a few should work).  The packets from the slaves would have, at 
the front, a packet type identifier and a destination slave number.  The data 
would then be clocked, round robin, one byte at a time.  The master would 
transfer a byte to the slave, and take the return byte and process it.  When 
the slave indicated end of data, it would be put back in the poll list.

This would give you a full peer to peer (via the master) and multi session 
network that should be able to provide a high degree of flexibility using 
SPI...
-----
gr...@cy...  (Cyte Technologies Inc)