[En-Nut-Discussion] Device independent bitbang drivers should use the device independent GPIO API.

[Harald Kipp]

Thiago A. Corrêa wrote:

>     Continuing my effort to port ethernut to AVR32, I found that the
> device independent bitbang drivers are using "old style" GPIO
> interface, which makes it quite a bit less "device independent" than

This SPI/TWI part annoyed me for years. Just implementing a version that
uses the new GPIO calls wouldn't solve all issues as long as there is no
general concept for devices attached to a peripheral bus. I remember,
that it had been suggested to follow the Linux way. I found out, that
while I2C seems to be quite stable on Linux, there had been a lot of
uncertainties about SPI as well. As far as I had been able to follow,
the recent idea was, to create a specific SPI controller driver, which
does _not_ follow the I2C design. I believe, that this is the right way
to go for Nut/OS as well, if we want optimal performance with minimal
code size.

I recently tried to implement a first solution of an SPI controller
driver. It had been tested on ARM7 and AVR8 and seems to work well. The
sequence for using it with a file system is as follows

 /* Register SPI device. */
 NutRegisterSpiDevice(&devSpiAt45d0, &DEV_SPIBUS, 0);
 /* Register file system. */
 NutRegisterDevice(&devRawFs0, 0, 0);
 /* Mount volume. Attaches FS to SPI device. */
 _open("AT45D0:0/RAWFS0", _O_RDWR | _O_BINARY);
 /* Open file. */
 fopen("RAWFS0:", "r");

Note, that the new raw file system directly accesses the volume, so
there's no explicit file name. I'm almost sure, that this will currently
not work for PHAT. But in general it will reduce the porting effort to a
minimum.

If you agree, that this is a valuable implementation, we may create a
related bit banging driver based on the generic GPIO interface. It will
be slow, but allow to get a lot of things working with minimal effort.
Of course all existing SPI routines need to be adapted to this new bus
interface (e.g. VS10xx MP3 decoder). I also tried to add some support
for non-volatile memory used by the Nut/OS configuration. This turns out
to become tricky and I ended up with some ugly code. This could be done
much nicer if we allow to configure pre-registered devices with the
Configurator, but that's a different story (see my older discussions
about the pure main routine without NutRegisterDevice).

Btw. it took me one full day to figure out, that PDC is not working on
the AT91SAM7SE with SDRAM. Well, the issue _is_ listed in the errata,
but I didn't expect a die problem. I hadn't got time to left to fix this
by using internal RAM for the buffers or try a different platform. So
PDC is not yet working.

Harald

P.S. Yes, you are all right. I announced to move to Nut/OS 4.8 soon and
not to add significant enhancements. I simply changed my mind, after the
SPI problem caught me again. I didn't want to take this issue again to
the next stable release. Sorry for the delay that has been introduced by
this change.