[En-Nut-Discussion] Problem with STM32 pin configuration

Ole Reinhardt ole.reinhardt at embedded-it.de
Tue Oct 6 01:14:25 CEST 2015

Hi Uwe,

perhaps I have an idea for a simple solution.

What about changing nut/include/dev/pins.h like this:

typedef enum
#define PIN_NONE  0

#define PA00      0x100
    PIN_PA00 = PA00,
#define PA00      0x101
    PIN_PA01 = PA01,
#define PA00      0x102
    PIN_PA02 = PA02,
#define PA00      0x103
    PIN_PA03 = PA03,
#define PA00      0x104
    PIN_PA04 = PA04,

This is just a rough thought. I have not yet tested it.

Best regards,


Am 06.10.2015 um 00:53 schrieb Ole Reinhardt:
> Hi Uwe,
> there is a problem with your new pin configuration scheme, which you
> committed a few days ago, which breaks several drivers.
> The problem is, that the GCC preprocessor does not know anything about
> types. But in several places, a preprocessor comparison like
> #if (SPI_CS0 != PIN_NONE)
> is used, where PIN_NONE is of the enum type nutgpio_t.
> The above comparison is always true, as the preprocessor takes SPI_CS0
> and PIN_NONE as identifiers, not as macros. These are then both replaced
> by 0. So finally the comparison is always true.
> This kind of preprocessor comparisons are at least used in
> arch/cm3/dev/stm/stm32_spi.c
> arch/cm3/dev/stm/stm32_emac.c
> but perhaps ins several more.
> See also https://gcc.gnu.org/onlinedocs/gcc-3.0.2/cpp_4.html#SEC38 for a
> detailed explanation.
> Could you please have a look at it? Unfortunately I do not have an idea
> for an elegant solution.
> Best regards,
> Ole

kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen

More information about the En-Nut-Discussion mailing list