[En-Nut-Discussion] Rational for RFA_5: Nut/OS GPIO AP
harald.kipp at egnite.de
Fri Oct 26 11:15:27 CEST 2012
This is the same discussion over and over again and I'm missing my point
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
I already recognized in my initial post
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.
More information about the En-Nut-Discussion