[En-Nut-Discussion] Nut/OS GPIO API Initial Design and Current Status
bon at elektron.ikp.physik.tu-darmstadt.de
Mon Oct 15 18:18:21 CEST 2012
>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
Ole> - Simple GPIO API with: - configure input / output, pullup,
Ole> pulldown, set pin value, get pin value, set pin high, set pin low
This sounds good. But what do with platform independant code requesting e.g.
pulldown on AVR? Should configure fail or should user code check the actual
flags? The AVR can't pulldown at all.
We also miss MULTIDRIVE here. Without MULTIDRIVE we can't do e.g. a bitbanging
With MULTIDRIVE we also have a problem with AVR. Let's take this example for
NutGpioPinSet( p, b,.. MULTIDRIVE)
NutGpioPinSetLow( p, b);
NutGpioPinSetHigh( p, b);
This doesn't result in a TRISTATE AVR pin. If we add a explicit function to
release and drive a pin, we can handle this for AVR. For most other
platforms release() and drive() will be empty macros.
The commands should also have a portwide counterpart with a mask argument. If
a platform in the sense of a 48-pin STM32 without FSCM (*1) versus a 144 pin
STM32 with FSCM has no businterface, we need to be able to implement a
bitbanging bus interface. And we shouldn't ripple through the related pins.
(*1)Flexible static memory controller (FSMC)
Ole> - Drivers: Try _not_ to use the I/O api as long as it is not a
Ole> - Try to keep functions as short as possible, try to be atomic
Ole> - CPU specific API for more detailed pin configuration Even double
Ole> code would be ok, if we keep things more clear then.
Ole> - Sample programs:
Ole> - Try to keep samples simple, always try to initialize I/Os in
Ole> the board file, do not create common samples that need more
Ole> sophisticate I/O pin settings.
Here again we need to think about a use case that is probably not thought of
yet. Someone has e.g. an Embed board, puts it in a breadboard and connects
e.g. a TWI portextender with flying wires. Then the user should have an easy
way to configure his setup, at least without going through the configurator.
Ole> bitbanging driver. Bitbanging drivers should try to use only common
Ole> API functions.
Huch: So you consider the code in e.g. arch/cm3/dev/nxp/lpc177x_8x_mci.c:
// Force all MCI control pins to basic I/O mode
GpioPinConfigSet(NUTGPIO_PORT0, 19, GPIO_CFG_OUTPUT); // SD_CLK
GpioPinConfigSet(NUTGPIO_PORT0, 20, GPIO_CFG_OUTPUT); // SD_CMD
GpioPinConfigSet(NUTGPIO_PORT1, 5, GPIO_CFG_OUTPUT); // SD_PWR
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