[En-Nut-Discussion] Porttrans.h, was: Gpio again.

[Harald Kipp]

Hi Uwe,

Sorry for the delay. As usual, this GPIO discussion had become a bit
lengthy and I needed time to check the history.

On 18.06.2013 15:21, Uwe Bonnes wrote:
> The idea of defining and
> undefineing GPIO_ID is a good way to write the complex macros needed.

The main reason for writing this was to avoid all these lengthy ifdefs
at the beginning of several driver sources.


> However in it's present form there are several drawbacks:
> - There are few drivers in the general dev/ directory using porttrans.h

Yes, as far as I can see, porttran.h is mainly used in target-specific
code within the arch directory.

> - The code there is still sprankled with device dependent code like in
>   dev/sbi_mmc.c
> static int SbiMmcIfcInit(NUTDEVICE * dev)
> {
>     /* Enable all clocks. */
> #if defined(PMC_PCER)
> #if defined(MMC_CLK_PIO_ID)
>     outr(PMC_PCER, _BV(MMC_CLK_PIO_ID));
> #endif

Yes, this is ugly and should be replaced.


> again the same objection holds, that I had with NutGpio: I we want to
> write portable code, we must restrict ourselfs.

Well, although I agree, that's not my main concern. Instead, offering a
limited GPIO API would allow to port it in short time to new platforms.

Assume a totally new platform, let's say PicoBlaze. If we have a simple
GPIO API, this could be adapted to PicoBlaze in some minutes. If this is
done, you can already read and write FAT-formatted SD-Cards, because
bit-banging SPI is immediately available.


> - GPIO_FILTER_xx is also feature only available on few architectures.

There may be an alternative, extended API, but that should be optional.


>   I would start porttran2.h as a copy of porttran.h and strip
>   down. Assembling GPIO_INIT for archs not available here is harder and will
>   required code review and|or support from maintainers of the different
>   architecture. porttran2.h is not supposed to be includes in arch/dev code!

Could be a bit difficult. For example: We do not have anyone looking
after AVR32 right now. I'm sure, Thiago is still around, but is probably
busy with other projects. So it needs to be done carefully, step after
step. Specifically with AVR32 I'll help.


> Is this a way to go? Anything I forgot? Better names for porttran2.h?

I'd prefer a different term. Otherwise porttran may become the global
term for both and one needs to add: "I meant version 1, not 2".

Argh...finding new names is not really my favorite task...

portmacs was my first idea, but port and MAC are ambiguous. How about
piomacros.h?

Regards,

Harald