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

[Ulrich Prinz]

Hi,

Option 1
You add some blind addons to the gpio api.
NutGpioPinSetHiz( port, pin, val) can be used to switch in/out on AVR while
ARM simply defines this as NutGpioPinSet( port, pin, val). For ARM
NutGpioPinCfg( port, pin, option) the pin is configured to HiZ with
NUT_PIN_CFG_HIZ while in AVR this value just configures the pin to input
and prepares output low.
This would unify the totally different architectures.

Option 2
You duplicate drivers that need optimized handling of certain chip
features. So gpio emulated mmc exists for arm and for avr.
This makes sense for some drivers not only for speed, but for features too.
I.e. handling fat32 on avr is hard and costs lots of flash, but it is easy
for arm.
2b could be a compromize. You prepare a lower level api. So a higher level
driver sits on top of these drivers that abstract some special
requirements. The higher level driver is disabled in chips that (currently)
not provide the low level API.

Option 3
Split Nut/OS and Nut/OS32 to get best out of both worlds without producing
unneeded overhead on AVR by using int or on ARM by using char.

Ulrich
Am 26.10.2012 11:15 schrieb "Harald Kipp" <harald.kipp at egnite.de>:

> 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
>
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>