[En-Nut-Discussion] GPIO_CFG Definitions
bon at elektron.ikp.physik.tu-darmstadt.de
Mon Jul 16 12:38:17 CEST 2012
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.
- 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
- 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.
#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.
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the En-Nut-Discussion