[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
harald.kipp at egnite.de
Sun Oct 14 13:50:54 CEST 2012
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.
> 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.
> 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
> 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
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
> 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.
More information about the En-Nut-Discussion