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

[Thiago A. Corrêa]

On Sun, Jan 11, 2009 at 9:37 AM, Harald Kipp <harald.kipp at egnite.de> wrote:
> 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.

Well, I won't pretend that I understand that *smile*.
Isn't SPI just "yet another serial port"? For a device independent
driver in particular we don't need a single implementation, all we
require is a single API, so the internal SPI ports should have their
full performance. The bit bang on the other hand should take advantage
of our new device independent GPIO interface, this way, not only it
makes it easy to port but also, if we later on support GPIO extender
chips, bit bang support on that chip becames available for free.

> 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");

Looks like we got an device independent SPI interface then, looking at
your commit (/include/dev/spibus.h)

> 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.

I'm totally lost on the filesystem implementations so far, except for urom :P
Perhaps as I work in ethernut internals with the AVR32 port this will
be clearer later :)

I've been toying in my head with the idea of a zlib filesystem, or
some compressed filesystem.
Something that is compressed in compile time much like crurom. But
that's just some crazy idea for a while... Already got too much in my
hands for the time being, maybe later on :)

> 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.

Well, a clever compiler might inline the calls for the GPIO at least.
Not sure if gcc is clever enough, would require whole program
optimization to detect that in a .c file instead of header.
Anyway, I think it's worth in the flexibility and removing the #ifdefs
makes it better to maintain the code.

> 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

Maybe NutNvMemSave could be expanded with a destination device or
something like that.
Then have the Nut/OS configuration use that, if it isn't already.
Shouldn't be too ugly, but most likely would affect all users, me included.


> 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).

Yeah.

> 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.
>

No problem from here at least. I was only waiting for the release to
commit of the discovery protocol thing, because it might cause
problems for someone. Other than that, I've been working on the AVR32
port in a different repository for the time being. Will merge later
when it is less ugly and all :P

Thanks,
   Thiago A. Correa