[riot-devel] UART1 support for remote-reva/-revb and firefly

Thomas Geithner thomas.geithner at dai-labor.de
Tue Dec 19 17:26:38 CET 2017

Hi all,

For a specific project, I need the second UART (UART1) at a remote-revb
resp. firefly board. The current board definition includes only the
first UART (UART0) in boards/remote-revb/include/periph_conf.h.

Furthermore, my required pin configuration is conflict with the second
SPI, so I would like to disable SPI1 too.

For my project, I'm using a modified version of the periph_conf.h, but
the best solution would be an generic board configuration which allows
enabling/disabling/configuring the required functions. And, in my
opinion, it would make sense contributing this to RIOT.

What would be the best way for this? In my current version, I'm doing
this in the following way (allowing enabling UART1 my the application
makefile via "CFLAGS+=-DENABLE_UART_1")


#define UART_NUMOF          (2U)
#define UART_0_EN           1
#define UART_1_EN           1


#define UART_NUMOF          (1U)
#define UART_0_EN           1



/* UART 0 device configuration */
#define UART_1_DEV          UART1
#define UART_1_IRQ          UART1_IRQn
#define UART_1_ISR          isr_uart1
/* UART 0 pin configuration */
#define UART_1_TX_PIN       GPIO_PIN(PORT_C, 4)
#define UART_1_RX_PIN       GPIO_PIN(PORT_C, 5)


static const spi_conf_t spi_config[] = {
        .dev      = SSI0,
        .mosi_pin = GPIO_PB1,
        .miso_pin = GPIO_PB3,
        .sck_pin  = GPIO_PB2,
        .cs_pin   = GPIO_PB5
        .dev      = SSI1,
        .mosi_pin = GPIO_PC5,
        .miso_pin = GPIO_PC6,
        .sck_pin  = GPIO_PC4,
        .cs_pin   = GPIO_PA7

But I don't like this, because it
- mixes UART and SPI configuration
- the pin configuration is static (while the cc2538 allows a flexible

The pin assignment could be improved in the following way (which lets
the application makefile overwrite the default configuration):
#ifndef UART_1_RX_PIN
#define UART_1_RX_PIN       GPIO_PIN(PORT_C, 5)
Alternatively, the pin assignment could be left open (since there is no
reasonable default configuration for this boards).

And the second SPI could be encapsulated by something like "#if
ENABLE_SPI1" or maybe "#if !DISABLE_SPI1".

What is your opinion about this? Or do you see a better way? If are okay
with that, I would start preparing a pull request.

Thanks in advance,

More information about the devel mailing list