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

[Harald Kipp]

Hi Ulrich,

On 12.10.2012 22:20, Ulrich Prinz wrote:
> I am still very deep in other things, far away from Nut/OS but I asked 

It's really nice to see, that many developers keep in touch, although
there current focus is somewhere else.


> 1) There is no reason to number ports out. No one ever needs to have 
> ports in a row following a numbered scheme. With pins it is useful, but 
> I never saw a solution that required ports to exist in a certain follow up.

No real need, of course not. As there also is no need to use numbered
sequences for file handles in low level C libs (open, read, write,
close). It's just a least common denominator and easy to handle.


> 2) To assign numbers to things that obviously are not related to any 
> mathematical predictable rule always causes software overhead in sort of 
> tables, switch cases, if then else...

An index? X1 = 5 * Y2? Where is the mathematical rule of indices 1 and 2?


> 3) From the users point of view, Who (the hell) cares what 
> NUT_GPIO_PORTA really means? Everyone would expect that if I place this 
> 'thing' somewhere it addresses exactly the port that the manufacturer 
> named A *). As a Nut/OS user I simply expect that 
> NutGpioPinGet(NUT_GPIO_PORTA, 5) would give me the state of the pin 4 on 
> port A.

No objections.


> 4) If you programmed on dozens of litte chips, you learn that every chip 
> has its special way to support a kind of fast GPIO access. But every 
> chips does it in a different way. So to port a system to this chip, you 
> need to take your time and take your revolutions.

Exactly.


> Independent of any chip or CPU, NutGetPin/Port(NUT_GPIO_PORTx, bit) must 
> give the value of the bit at that port.

That's the idea.


> It does not matter if NUT_GPIO_PORTA is a thing hidden in a #define, a 
> hex value for a hard coded address, a pointer to a virtual register or a 
> simple number. As long as the API user can use it to set a bit or a 
> port, it is a number in AVR, a struct in STM32 an offset in ARM.

No question, it can be done this way or another way, depending on the
platform.


> As you mentioned the extra features are a problem as different chips do 
> provide different optional features. I already proposed there something
> but only Thiago aver tried to follow that thing. The idea was to make 
> some some commonly used options as a standard and to allow integrators 
> to add more.

That's the point. Why do you want to add more features? Where is the
advantage?

If an MCU family provides specific features like debouncing or repeater
mode, a native API tailored for this specific family would be sufficient.

For AVR we have avr/io.h from avr-libc. For NXP we may create nxp-iolib
with nxp/io.h. GpioXXX currently uses avr-libc to implement the required
functions. When ported to NXP, GpioXXX could have used nxp-iolib likewise.

If I write a driver specifically for the AVR, I'd _not_ use GpioXXX.
Instead I'd use the non-portable avr-libc API, because my AVR specific
driver doesn't need to be portable.

And this is the point where I'm still missing an answer:

Why the hell is the portable Gpio API used for drivers, which are not
portable themselves?


> And if a board really doesn't support any kind of LED you could assign 
> the LED pins to some unused GPIOs, so it doesn't hurt the demo with lots 
> of #ifdef...#endif.

I also see this requirement, but think, that this is related to Ole's
topic about GPIO configuration.

Regards,

Harald