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

[Ole Reinhardt]

Hi all,

wow! Once I did not foolow the list for a weekend, a big discussion
started...

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
     pin value

     Where possible these functions should work as "atomic" as possible.

   - An architecture/CPU specific extended API that can control all
     other features. 

     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
   configurations).

   In most situations I used the GPIO API to configure I/O pin
   assignments. 

   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

Exmample:

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
bits... 



Abstract:
=========
   
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:
 

Ole:

- 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
  API functions.




Just my 2/100 EUR.

bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

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