At some point you might need to port a new
RIOT, either because that specific development board is not yet supported or because you have a custom
BOARD for your project.
If you want to port a
RIOT you have two choices: doing it inside of
RIOTBASE or outside. In either case the file structure is basically the same and moving from one to another is easy.
This guide details the generic structure you need to add a new
RIOT, the different files as well as their functionality.
CPU_MODELis already supported in
RIOTso no peripheral or cpu implementation is needed.
Header files in
board-foo/include define physical mappings or configurations. e.g:
periph_conf.h: defines configurations and mappings for peripherals as well as clock configurations.
board.h: holds board specific definitions or mappings, for example LEDs, buttons. It might as well override default drivers parameters (e.g.: assigning specific pin connections to a LCD screen, radio, etc.). Some boards might also define optimized
XTIMER_%values (e.g. XTIMER_BACKOFF).
gpio_params.h: if the board supports SAUL then its saul_gpio_params_t is defined here.
include/, but if defined somewhere else then they must be added to the include path. In
INCLUDES += -I<some>/<directory>/<path>
Board initialization functions are defined in
board.c. This file must at least define a
board_init() function that is called at startup. This function initializes the
CPU by calling
cpu_init() among others.
A board's Makefile just needs to include
Makefile.base in the RIOT repository and define the
board (see modules for more details)
Dependencies on other
FEATURES can be defined here. This might specify
MODULES or dependencies that need to be pulled under specific configurations. e.g.: if your board has a sx1276 lora chip:
Makefile.depis processed only once so you have to take care of adding the dependency block for your board before its dependencies pull in their own dependencies.
This file defines all the features provided by the BOARD. These features might also need to be supported by the
CPU. Here, define the
CPU_MODEL (see build system basics for more details on these variables).
This file contains BSP or toolchain configurations for the
BOARD. It should at least define the configuration needed for flashing (i.e. a programmer) as well as the serial configuration (if one is available).
Although not explicitly needed, if upstreamed and as a general good practice, this file holds all
BOARD documentation. This can include datasheet reference, documentation on how to flash, etc.
The documentation must be under the proper doxygen group, you can compile the documentation by calling
make doc and then open the generated html file on any browser.