[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
ole.reinhardt at embedded-it.de
Mon Oct 15 15:47:16 CEST 2012
wow! Once I did not foolow the list for a weekend, a big discussion
I think a lot of different views have been discussed, and so I just want
to tell you my own opinion in a few word before I'll try to bring all
these threads together.
Q: Why did we add more and more features?
A: When I started implementing the API for NXP I looked to the AT91, the
AVR and also to the STM32 api and found that it was not easy at all
to bring everything together. I decided to go the STM32 way, as it
was most comparable to the NXP.
While implementing I then discovered, that the different LCP devices
have quite different register sets at some points and that it became
a mess to get them pressed into one API.
I also found that it will became complicated to follow the way that
Ulrich suggested: To just deny featured that are not supported by one
platform with an error code. That just because we will endup with
FLAG definitions that will became easily wider that 32 bits if we
reserve one bit for each flag that has ever been introduced on any
platform. So things got messed up.
I would vote for:
- A small GPIO API with _basic_ functions. Speed should not be the
first priority, but the functionality that we provide, should be
available on all platforms.
I would suggest
configure input / output, pullup, pulldown, set pin value, get pin
value, set pin high, set pin low (last two as special cases of set
Where possible these functions should work as "atomic" as possible.
- An architecture/CPU specific extended API that can control all
This API should also provide a way to configure the I/O pin
assignment (alternate functions) for CPUs that provide using
different I/O pins for the same peripheral
Q: Why do you use the GPIO api in your platform drivers:
a: Thats exactly the point why I posted my first Thread (I/O
In most situations I used the GPIO API to configure I/O pin
Sure I could have done this directly using the registers, but using
the API makes things more understandable. But anyway I would vote to
remove these configurations from the drivers and to move them into
the board init code.
I we every would need to control a GPIO line by a driver (e.g. to
apply a reset signal or something like this) we should think about
the platform device idea which I proposed in my initial thread where
we could register a function (as callback) that will set the I/O
accordingly. This way you are independent to any specific
implementation and even can use a totally different way to control
this signal (e.g. a FPGA)
Last but not least I would like to suggest one more idea (even if it
conflicts with the idea of simplicity and fast I/O access):
Why not keep the API extendable?
E.g. it would be a good idea that we could add an I2C I/O expander chip
as extra I/O pins that will be enumerating with the next free I/O bank
The CPU provides 4 32 bit I/O ports:
We have than bank 0 to 3, each 32 bit deep
We later register our I/O expander with 16 bits, as bank 4 with 16
I think we are at a point where we should try to bring our ideas into
short bullet points, that we can compare with each other instead of
reading long threads...
My basic ideas as bullet points. Perhaps everyone of you could also add
his ideas as a seperate set of bullet points so that we end up with a
list later to have a starting point for a final discussion:
- Simple GPIO API with:
- configure input / output, pullup, pulldown, set pin value, get pin
value, set pin high, set pin low
- Try to keep functions as short as possible, try to be atomic
- CPU specific API for more detailed pin configuration
Even double code would be ok, if we keep things more clear then.
- Sample programs:
- Try to keep samples simple, always try to initialize I/Os in the
board file, do not create common samples that need more sophisticate
I/O pin settings.
- Drivers: Try _not_ to use the I/O api as long as it is not a
bitbanging driver. Bitbanging drivers should try to use only common
Just my 2/100 EUR.
Thermotemp GmbH, Embedded-IT
Embedded Hard-/ Software and Open Source Development,
Integration and Consulting
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
More information about the En-Nut-Discussion