[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status

[Harald Kipp]

Hi Uwe,

On 13.10.2012 00:08, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>     Harald> In fact, banks are not assigned to IDs, they are simply numbered
>     Harald> upwards. Sorry for the confusion. Hopefully I'll get it right
>     Harald> now. :-)
>  
> And here the different views arose: For the CM3 trees, "bank" was always a
> "handle" in the Win32 API view or "magic number" as it is the port base
> address in the arm memory range. I never knew other until recent.

I just checked this for the first time and indeed, its a handle or, more
precisely, a pointer into I/O-memory.


>     Harald> free. Motto: "Porting Nut/OS in 2 hours."
> 
> Well, I have a bitbanging debug driver under my fingers. This will allow to
> use the STM32F4 discovery boards nearly self-contained, after reflashing the
> original ST-LINK with the "Blackmagic Debug Probe" code. It uses the Gpio
> Api and at the moment the CM3 systick for timing. So it will work not only
> for STM32 but any CM3 arch.

Sounds quite promising.


>     Harald> repeater mode and other exotic stuff.  Instead of one simple
>     Harald> dev/gpio.h and its related implementations arch/arm/at91_gpio.c,
>     Harald> arch/avr/gpio.c etc. we now have several headers, and a growing
>     Harald> number of features. This makes it harder and harder for newbies
>     Harald> to implement GPIO on a new platform. The initial idea was
>     Harald> spoiled.
> 
> I don't agree with your view. Each architecture needs a setup for it's GPIO,
> and this setup is getting more complicated as chips get more
> compilcated. This results in more available feature, but many features are
> only features, nice things to have, but not nescessary for general examples.

I fully agree. For example, the avr-libc does not only provide C
standard functions. In addition it includes a standard API to access all
this platform specific I/O registers.

It will definitely help developers, if Nut/OS provides something similar
for targets, where this is not supported by a runtime lib like newlib.
But that API can be limited to, let's say Cortex-M.


> This is where my plea from July for a definition of a common subset for
> features, defined in include/dev/gpio.h came from. Other architecture
> specific features can then be defined in the dev/gpio_<arch>.h files. But
> other architecture must know what to do if they find such a feature
> request. Is it really a request or a requirement? Should they fail in
> GpioPinConfigSet or should they ignore the request? That we need to agree
> about.

IMHO, the GPIO API cannot make this decision. It has to be made by the
caller. Look at I2C. If the target supports open drain, then this is
perfect. If it doesn't, then the driver may alternatively switch the
pin's direction. This is often much slower and will work in single
master mode only. How should the GPIO API know about requirements,
possible alternatives and consequences for the I2C driver?


>     Harald> GPIO API, REST IN PIECE. ;-)
> 
> I hope, I oversee the smiley.

Notice the wink, in opposite to :-).


> My work on the AVR showed, that even for that arch you could defined the
> GpioApi in a way that will result in most cases in the single commands sbi()
> and cbi() as would unportable direct coding. And even
> the bank argument as a runtime variable can be handled without a big runtime
> switch case but by a pointer access if you look at the three consecutive AVR
> port/pin/ddr register as a structure.

Which is probably an advantage. But still there is no reason for me to
use this API in AVR-specific drivers.


>     Harald> A few target specific drivers use a different approach to avoid
>     Harald> the GPIO API and still provide configuration capabilities. They
>     Harald> are based on macros and include/cfg/arch/porttran.h. And they
>     Harald> are very tricky to implement, difficult to use and result in
>     Harald> ugly, hard to follow code.  Beside that, they use PIO IDs, not
>     Harald> port banks.
> 
> Seems like a lot of code has not been touched for ages. Does it really work
> still ? Has anybody tested?

That's a funny question. :-) Still working?! SPI chip selects use this,
and also UART hardware handshake. It's in use for 8 and 32 bit AVRs and
AT91.

Regards,

Harald