c3io - A compact io driver for the C3 platform - alpha v0.02
jhh
Posts: 28
Hello!
I'd like to share something I've been hacking away on since my C3 board arrived. It's in a very early form, but I think is approaching a useful and semi-stable state, and I want to put it out for comments. I say semi stable, because I'm waffling on a design detail, and I wonder what others think. (More on that later)
In it's present form, it is a 1-cog IO driver (c3io.spin) for the C3's IO buses, including SPI, the C3's selection MUX for SPI, I2C, and exposes the SRAM via a virtual memory manager.
It is heavily based on:
- sdspi
- fsrw
- SD3.01FATEngine and the related RTCEngine
- spisram_cache (which is based on VMCog)
- the sources directory/demos referred to in "Unleashing the Propeller C3"
- various other objects from the obex
What is included:
c3io.spin
A singleton object which contains the cog code, providing a series of commands, similarly to sdspi. (Much of the calling pattern is the same, and some I2C commands may be compatible. SPI is very much not however...). It allows for "dma-like" calls to be made, with pointer being used from any of 1-32 bit transfers, to multi-byte transfers, supporting bi-directional SPI, fast/slow I2C, and paged access to the SRAM devices.
c3io, with one exception, is only concerned with bus-level mechanics, and the transfer to and from memory. It does not know or care what an SD card is, or an EEPROM, and so on.
Device Drivers
SPIN-based drivers are provided for the these C3s built ins: (all based on the Unleashing book, but using c3io for the low-level bus handling)
- SRAM (raw, generally one would use the virtual memory driver)
- Flash
- A/D Converter
An SD Block driver is provided, based partially on sdspi's high-level SD routines being converted to SPIN routines, and the same treatment done for SD3.01FATEngine, which has better support for later-model SD cards. All the bulk byte-transfer is driven by the c3io assembly module, with SPIN being used just for signalling and setup.
There are also drivers for:
- DS1307 RTC driver (based on that which SD3.01FATEngine requires)
- Wii Nunchuck and Classic controllers
TWO FAT implementations!
Conversions of both "fsrw" and SD3.01FATEngine are provided. In the former, c3io and the SD block driver replaces sdspi, For SD3.01FATEngine, c3io replaces it's assembly routine, and impacts mostly just one SPIN R/W function with the rest unchanged.
Demos
Very simple demo programs are included which only work on a serial terminal. They are sort of based of the same demo programs from the "Sources" directory of the propeller FTP site.
I didn't even know what the parallax terminal was when I started, so I "fixed" it to use something that worked with minicom. (IE: plain ol normal serial)
Unfortunately the demos are the least loved of all the code here. There's a lot I want to clean up, but it should be illustrative enough all the same.
A port of Zog
To give a better test of the virtual memory a conversion of David Betz's C3 version of Zog has been ported. It runs fibo.bin, but not much other testing has been done.
Not included yet
Any real apps.
This might not be for everyone. If you're concern is low-latency or highest bandwidth, then custom assembly is the way to go, or a device-specific COG. Again, c3io knows little about devices, save for the SRAM to support the VM. It is up to the callers to structure the calls to c3io, and provide the higher level.
That said, c3io should be no slouch, on multi-byte SPI transfers it should get up to approx 2.89 MHz clock on each byte or long sent.
Also... not for anyone without a C3, or is willing to configure their board to look like one, SPI MUX and all.
This is part of a longer-term vision to build a system that allows use of most any hardware, save for video and sound, in 2 cogs, ensuring that even with the addition of AV drivers, 3-4 cogs are left for the "application".
Future work directions include:
- building some complex applications (IE: zicog, or other such things) on top of c3io
- more I2C/SPI device drivers (wii i2c peripherals, enc28j60 driver)
And lastly, if you've gotten this far, the conundrum that's brought me to an early release....
I *just* added the VM stuff... and am second-guessing it. Early on, it seemed to make sense as the SRAM "bus" and the SPI bus are essentially the same resource, so it seemed an advantage to keep them together.
Why I am questioning it, is it occurs if I am enjoying a good hit rate, I am tying up the rest of the cog with requests contenting for other IO that could be occurring. On the other hand, hits are quite cheap, so does it really matter so much? So I wonder if keeping it as a separate assembly cog would be a better approach, and might let me do full-blown VMCog as well. (I think I have 3 longs of free cog memory...
Any thoughts on this, or anything else about c3io are welcome.
--Joe
I'd like to share something I've been hacking away on since my C3 board arrived. It's in a very early form, but I think is approaching a useful and semi-stable state, and I want to put it out for comments. I say semi stable, because I'm waffling on a design detail, and I wonder what others think. (More on that later)
In it's present form, it is a 1-cog IO driver (c3io.spin) for the C3's IO buses, including SPI, the C3's selection MUX for SPI, I2C, and exposes the SRAM via a virtual memory manager.
It is heavily based on:
- sdspi
- fsrw
- SD3.01FATEngine and the related RTCEngine
- spisram_cache (which is based on VMCog)
- the sources directory/demos referred to in "Unleashing the Propeller C3"
- various other objects from the obex
What is included:
c3io.spin
A singleton object which contains the cog code, providing a series of commands, similarly to sdspi. (Much of the calling pattern is the same, and some I2C commands may be compatible. SPI is very much not however...). It allows for "dma-like" calls to be made, with pointer being used from any of 1-32 bit transfers, to multi-byte transfers, supporting bi-directional SPI, fast/slow I2C, and paged access to the SRAM devices.
c3io, with one exception, is only concerned with bus-level mechanics, and the transfer to and from memory. It does not know or care what an SD card is, or an EEPROM, and so on.
Device Drivers
SPIN-based drivers are provided for the these C3s built ins: (all based on the Unleashing book, but using c3io for the low-level bus handling)
- SRAM (raw, generally one would use the virtual memory driver)
- Flash
- A/D Converter
An SD Block driver is provided, based partially on sdspi's high-level SD routines being converted to SPIN routines, and the same treatment done for SD3.01FATEngine, which has better support for later-model SD cards. All the bulk byte-transfer is driven by the c3io assembly module, with SPIN being used just for signalling and setup.
There are also drivers for:
- DS1307 RTC driver (based on that which SD3.01FATEngine requires)
- Wii Nunchuck and Classic controllers
TWO FAT implementations!
Conversions of both "fsrw" and SD3.01FATEngine are provided. In the former, c3io and the SD block driver replaces sdspi, For SD3.01FATEngine, c3io replaces it's assembly routine, and impacts mostly just one SPIN R/W function with the rest unchanged.
Demos
Very simple demo programs are included which only work on a serial terminal. They are sort of based of the same demo programs from the "Sources" directory of the propeller FTP site.
I didn't even know what the parallax terminal was when I started, so I "fixed" it to use something that worked with minicom. (IE: plain ol normal serial)
Unfortunately the demos are the least loved of all the code here. There's a lot I want to clean up, but it should be illustrative enough all the same.
A port of Zog
To give a better test of the virtual memory a conversion of David Betz's C3 version of Zog has been ported. It runs fibo.bin, but not much other testing has been done.
Not included yet
Any real apps.
This might not be for everyone. If you're concern is low-latency or highest bandwidth, then custom assembly is the way to go, or a device-specific COG. Again, c3io knows little about devices, save for the SRAM to support the VM. It is up to the callers to structure the calls to c3io, and provide the higher level.
That said, c3io should be no slouch, on multi-byte SPI transfers it should get up to approx 2.89 MHz clock on each byte or long sent.
Also... not for anyone without a C3, or is willing to configure their board to look like one, SPI MUX and all.
This is part of a longer-term vision to build a system that allows use of most any hardware, save for video and sound, in 2 cogs, ensuring that even with the addition of AV drivers, 3-4 cogs are left for the "application".
Future work directions include:
- building some complex applications (IE: zicog, or other such things) on top of c3io
- more I2C/SPI device drivers (wii i2c peripherals, enc28j60 driver)
And lastly, if you've gotten this far, the conundrum that's brought me to an early release....
I *just* added the VM stuff... and am second-guessing it. Early on, it seemed to make sense as the SRAM "bus" and the SPI bus are essentially the same resource, so it seemed an advantage to keep them together.
Why I am questioning it, is it occurs if I am enjoying a good hit rate, I am tying up the rest of the cog with requests contenting for other IO that could be occurring. On the other hand, hits are quite cheap, so does it really matter so much? So I wonder if keeping it as a separate assembly cog would be a better approach, and might let me do full-blown VMCog as well. (I think I have 3 longs of free cog memory...
Any thoughts on this, or anything else about c3io are welcome.
--Joe
Comments
- wii nunchuck and classic drivers converted to c3io
- zog has been ported over to use c3io and it's virtualized memory. Both the zog version used for this, and the VM code used in c3io come from David Betz's directory on the FTP site.
Here it is running fibo.bin with the zog debugger, (it's somewhat slower than David's implementation...):
Update: Already have this running about 3x faster... next release should be much snappier.... it's good to have benchmarks...
v0.02 was just uploaded, and is a little over 300% speedup on the VM. A LOT had been done in c3io.spin while trying to optimize this benchmark, so SPI should in general be faster too.
Still *slightly* slower than the original zog implementation, but much better, as seen here:
I just looked through the latest c3io.spin source, well done, well commented.
- I liked how you separated out spiDoSelect as it will make it easy for me to back port it to PropCade, Morpheus and other boards.
- if there is space in the cog, separate spiRead and spiWrite operations would speed those routines up about 40%
I will have to try this on my C3, and back port it :-)
Regards,
Bill
I did manage to free up some room, and the speed gains on such a path do seem considerable win. I might just drop the R/W command in the byte-oriented version, and just leave it for the bit-oriented. I'd like the latter to just use the "mailbox" for such things, but it might mean needing to expand it a little.