[En-Nut-Discussion] Rational for RFA_5: Nut/OS GPIO AP

[Uwe Bonnes]

Hello,

sorry, I have to bring up the GPIO Api again. In another mail I will send the
real RFA_5 proposal

A: I banged my head the last days how to implement Ole's proposal with B,C and
   D below in mind. I always hit a dead road or inconsistancies with possible
   implementations.

B: The uses cases I can cover in portable code with RFA_5 are

1. Query input
2. Query input with pushbuttom to ground and no external pullup
3. Drive a pin push/pull, e.g. for a ground connected LED or a
   bit-banged SPI driver
4. Drive a wired-or line low and release it, with internal
   pullup active, e.g. for a bitbanged  TWI drivers
5. Drive multiple lines push-pull with the ability to release and redrive
   them fast, e.g. to connect FT245, SJA1000 or DMA9000 to non-bus pins. The
   proposal will result in the released line always pulled-up by the internal
   pullup on AVR and STMF1, but that will not hamper functionality of chips
   like the ones given above
6. Do GPIO actions beside configuration reasonable fast so that a bitbanging
   one-wire driver has good chances to work. Time requirements for one-wire
   are in the microsecond range.

C: Implementation constraint is to implement GPIO without the need for
   memory to keep track of pin state and configuration

D: Corner cases we have to cover by having to support restricted
architectures:

- To release an AVR pin, we have to set DDR to 0. To drive the AVR pin
  push-pull, we need to set/clear PORT. Most other architectures have a
  register to declare a pin open-drain and then only setting the output data
  register does the right thing

- STM32 has a strange configuration register with non 1:1 pin/register 
  bit mapping. Pin0 direction maps to Bit2-3, Pin1 to Bit6-7 in
  configuration register X up to Pin 15 mapping to Bit 30-31 of
  configuration register X+1. I see no way to do a direction change for
  multiple pins, like needed in use case 5 above, without _much_
  overhead. For STM32F1 I must accept this overhead, for newer STM32
  families the line release functionality can be mimicked by switching the
  pin to open-collector _and_ to output data register to high. Both latter
  register have a 1:1 mapping of pin to register bit and so switching can be
  done in few commands. But again, this doesn't fit with other architectures
  where we have a single data direction register with 1:1 mapping.

- A had a glimpse at the GPIO implementation of LPC17/18, LM4 and AT91SAM7
  and don't see such brain-damaged constructions. _Please_, let me know of
  any such brain-damage exists I did not realize with any architecture
  already in NutOs or intended to be added to NutOs, and if a workaround 
  is hampered by the proposed RFA_5

- There is no way to find out programmatical that a valid port/pin
  combination has a reachable pin on the actual package, at least on AVR8 
  and STM32

E: More critic to RFA_4
- Ole posed restrictions on the family internal GPIO implementation. This is
  _not_ scope of the platform independant API!
- Harald requested very hard type restrictions. This is bad for AVR
  memory/stack footprint. I moved to more adaptable gpio_xxx_t types.
- (11.2) If pin configuration flags are treated as implementation hints, I see
  no harm done if additional flags are common defined.
- There is no explicit migration path given.

Executive's summary:
===================
If anybody has a _real_ implementation pending so that my thoughts and
proposals are void or void (part for) his work, please let me know and reject
RFA_5. If you miss important use cases and have an idea how to
implement with the given constraints, let's work together on RFA_6. But
please, don't argue without caring for the arguments, constraints and
explanations exchanged so long

Otherwise: If you reject RFA_5, you void much of my effort.

Bye 

-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------