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

[Harald Kipp]

Hi Uwe,

This is the same discussion over and over again and I'm missing my point
again:

Creating a minimal implementation to support a few essential bit-banging
drivers, mainly SPI for serial Flash and MMC. This allows to get a full
featured system running by implementing a few stupid simple routines,
which doesn't care about features or performance.

The other view is to implement every feature for every possible
situation with most optimal code:

On 25.10.2012 13:00, Uwe Bonnes wrote:

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

...

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

It seems to be impossible to find a compromise. You can have either one
or the other.


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

I can see this and I have no problem with your RFA. I just don't see my
idea reflected.

I already recognized in my initial post

http://lists.egnite.de/pipermail/en-nut-discussion/2012-October/014059.html

that almost no one was using the initial SPI/MMC drivers, because they
had been too bulky and slow. So why should I spend more effort in trying
to promote my initial view of a simplified GPIO? I'm quite tired of this.

And, there is another law, that we have to accept: The one, who is
developing the code, you in this case, dictates the design. But please
try to avoid breaking existing applications. I do not mean those, which
are in nut/app, but those which had been written by Nut/OS users for
their own projects.

Regards,

Harald