[En-Nut-Discussion] Bitbanging Drivers: Configuration in library or user code

[Harald Kipp]

Hi Uwe,

On 28.09.2012 11:33, Uwe Bonnes wrote:
 
> the advantage of the bitbangig drivers is that they can use any GPIO
> pin.

This is just one aspect. Another idea behind the GPIO API is, that you can get a new board up and running without much effort. Porting the Nut/OS kernel to a new platform can be done in a few days. But Nut/OS is not very interesting as a kernel, it's main advantage is peripheral support. If we have a number of platform independent bit-banging drivers based on the GPIO API, you only need to port this API first, which should be quite easy. As soon as this is done, you may use I2C, SPI and more, based on the GPIO drivers. That further means, that you can access FAT formatted memory cards, calendar chips, serial flash etc. with standard C I/O functions.

When more time is available, you may add better drivers using the peripheral hardware of that chip.


> At the moment most bitbanging driver however use fixed pins at library
> compile time for these bitbanging things. Changing the default pins requires
> the whole ethernut chain, with a change in the <board>.conf file and
> eventually even in include/<arch>/<subarch>/dev/board.h and a recompile of
> the library.

This highly depends on the GPIO API. At least for the AVR there are 2 versions of the GPIO API.

1. Runtime version
2. Compile time version

The runtime version provides callable functions like GpioPinGet() or GpioPinSet(), which allow to select any port bit during runtime without recompiling. The disadvantage is, that they create a lot of processor overhead.

The compile time version uses macros and produces optimal code, like sbi or cbi (set/clear bit) resulting in a single cycle instruction.

Apart from the AVR, both APIs are available in portable form as well:

The runtime version is provided by arch/avr32/dev/gpio_nutos.c for the AVR32, arch/arm/dev/atmel/gpio_at91.c for the AT91 family, arch/avr/dev/gpio_avr.c for the AVR and more...

The compile time version is provided by include/cfg/arch/porttran.h.

For performance reasons, most bit-banging drivers I wrote are based on porttran.h, but I still see fit for the runtime version, because not all port bit manipulations need to be fast. Beside that, the compile time macros can be confusing and the source code looks quite ugly.

Your latest changes to gpio_avr try to combine both, having the clean code of the runtime API without too much processor overhead.


> With a develoment board like an Arduino however, users probably don't want
> to develop NUTOS but only use it. Maybe the distributor of the board has
> already distributed per-compiled NUTOS libraries and so maybe there is no
> NUTOS infrastructre on the users PC at all. So if the users want to user
> other pins for configuration, they can't, if configuration is done in the
> library.
> 
> So I strongly suggest doing configuration of bitbanging drivers in the user
> code. Ethernut should supply good defaults, but the user must be able to
> easily  define.

Good point, and that's what the runtime version of the GPIO API is for. Right now, the drivers do not offer any pin configuration, but that could be easily added. In the existing code you simply need to replace the macro definitions by variables.


> With the One-Wire implementation I have asked for feedback on a user code
> configurable driver. However there was no feedback so long. dev/owibus uses
> different code to register a owibus. I could use the same code if we pass a
> (GPIO PIN) user configuration when registering. Probably there are other
> ideas. Any thoughts?

I haven't done anything with 1wire so far, sorry.

In general I have another problem with your latest changes, but will open up a different thread for this.

Regards,

Harald