Hi all,
I am a new comer. RIOT is quite interesting project to me. I would like to be a contributor as many of you out there (Developing features, fixing bugs). By looking at how to be a contributor, it is hard to know where should I start. I am glad to hear from people what would be a good starting point? what hardware board I should have to start with?
Thanks in advance.
Hi @madokapeng, welcome to the RIOT forum!
For the general question on how to contribute, did you already have already have a look on our contributing guidelines? For specific tasks there is the âGood first issueâ label on GitHub, which we try to keep up-to-date. Some of the tasks are entry level and others are more involved, but good to get to know the code base. Another thing that is always welcome are improvements in documentation, especially if you think there are hard-to-understand or misleading parts in the current one.
Writing drivers for a CPU peripheral or some sensor is a good way to start IMHO. In the embedded space, good data sheets are usually readily available.
Depending on your experience, there are possible projects of varying difficulty. A few suggestions for boards are available here, but those are usually boards with Microcontrollers (MCUs) not yet supported by RIOT.
As with all code bases, itâs usually a good idea to read a few Pull Requests to get a feeling of âhow things are doneâ around here. Maybe this already gives you an idea for an interesting projects.
This should be the easiest. Get a cheap board from AliExpress, Adafruit, Olimex, Pollin or Seed Studio with a Microcontroller (or Microcontroller family) that is already supported by RIOT.
This will be mostly copy & paste from an existing board where you have to change / add the pin configuration to match the schematic of your new board.
@miri64 wrote an article with more details about this.
If your board comes with sensors / a display / some other component not yet supported by RIOT (e.g. if you get an esp32 based watch), this can also lead to
You can also get a sensor break out board to connect to an already supported board. Or maybe you have a board that comes with a sensor that is not yet supported by RIOT.
I2C Temperature / Moisture sensors are easy, usually you can just read a register and then have a formula to convert the register value into a temperature value. Try to avoid floating point arithmetic here. 
Make sure to check open / closed PRs if you can build on some existing work that has gone stale.
It can often be helpful to check what other systems are doing if you are stuck with something.
MCUs are composed of a CPU core (often a standard ARM Cortex-M processor) and vendor provided peripherals.
Common peripherals (SPI, I2C, UART, Timers, etc) can be found on every MCU. RIOT provides a common API so code can be written in a vendor agnostic way.
That means those interfaces have to be implemented for every CPU family. This is not always complete.
E.g. cpu/sam3/periph (found on the Arduino Due) and cpu/lm4f120/periph (found on TM4C123G LaunchPad) lack an I2C driver, many others lack a Watchdog driver (this is a low hanging fruit).
USB is also only implemented for some STM32, nrf52 and the sam0 family - although that might be a more complex, yet equally rewarding task.
There are two variants of this:
cpu/stm32)Vendors will usually reuse peripherals across their lines of MCUs. That means you can leverage the existing implementation and might only need to do some small modifications to get your new chip running.
Or you discover that some long overdue refactoring is needed before you can add your new processor.
In any case, make sure not to break the existing functionality
In that case starting with a new family can be easier as you donât have to accommodate for the existing siblings but can start from a clean state. It means however that you will need to provide all the peripheral drivers yourself. If you are lucky, the vendor provides a good reference implementation that you can use. If you are unlucky, you are stuck with an opaque HAL and no good data sheet.
New ARM Cortex-M CPUs are easier to support than RISC-V ones, for one simply because the Cortex-M port is much more mature, but also because ARM already provides a standard CPU core with an interrupt controller, so the only thing that will differ across vendors is the clock setup and peripherals. With RISC-V there is more variety, e.g. the interrupt controller can vary (note: this is also true for âclassicâ or âbigâ ARM cores (non -M))
This is not for the faint hearted, but I wanted to include it here for completenessâ sake. This would mean porting RIOT to a new architecture (pic24, stm8, Z80, 8051, âŚ) and will also lead to the previous task. This will require knowledge of the architecture and assembly to implement proper task switching.