[En-Nut-Discussion] GPIO_CFG Definitions

[Uwe Bonnes]

Hello,

the GPIO functions greatly help to write (somehow) portable user
code. However at the moment every architecture defined its own set of
GPIO_CFG_DISABLED. So things tend to diverge.  I think, this is not good, as
so the user code may have a definition that is available in one architecture
and not in some other. So compilation will choke.

I propose:
- Move the definitions to the common header dev/gpio.h. Add there new
(architecture specific) definitions as needed. Definitions should
have a somehow general meaning. Perhaps the MCU_LPC177x_8x definitions 
#define GPIO_CFG_ADMODE     0x00000400
#define GPIO_CFG_DAC_ENABLE 0x00000800 
could somehow be merged with GPIO_CFG_DISABLED(see below) and some other
more general properity. If we get over 32 feature bits, we should think
again :-)

- Mark for each definition what should happen if the architecture doesn't
have or implement that feature. Choices are ignore or abort. If some example
requests GPIO_CFG_HYSTERESIS, this may work even on another architecture
that don't have hysteresis.

- get rid of NULL definitions as
#define GPIO_CFG_INPUT      0x00000000
that are not maskable. I see no sensible way to test for such a feature.
I think
#define GPIO_CFG_SPEED       0x000000C0
#define GPIO_CFG_SPEED_SLOW  0x00000040
#define GPIO_CFG_SPEED_MED   0x00000000
#define GPIO_CFG_SPEED_FAST  0x00000080
#define GPIO_CFG_SPEED_HIGH  0x000000C0
is okay, as there is a mask.

Otherwise I propose to rename (or at least alias) GPIO_CFG_DISABLED to
GPIO_CFG_ANALOG, as that is more intuitive i.m.h.o.

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

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