Skip to content

GSOC Idea List

Marian Buschsieweke edited this page Feb 8, 2019 · 44 revisions

Below is a list of project ideas proposed for GSOC 2019 (don't hesitate to come forward with your own idea, if you have one that motivates you most). There are three categories of project ideas:

System

Project S1: low-memory optimized TLSF implementation

Project Category: System

Mentor: @kaspar030 (Backup: @emmanuelsearch)

Brief explanation: "Two Layer Segregated Fit (TLSF) is a memory allocator providing O(1) malloc and free. Unfortunately, with it's default configuration, it uses around 3.5kB for managing itself. The aim of this project is to to either adapt or re-implement TLSF in order to minimize this management overhead for use in low-end embedded devices with <=1MiB of memory. A non-exclusive list of ideas:

  • finding the right algorithm parameters / tradeoffs
  • limit allocation sizes (e.g, use 16bit bitfields)
  • make use of pointer compression for free list pointers"

Expected results: TLSF-based malloc/free with <0.5k self-management overhead integrated in RIOT

Knowledge Prerequisite: C, memory management, embedded programming.

Project S2: EEPROM Backed Configuration Data

Project Category: System

Mentor: @maribu (Backup: @leandrolanzieri)

Brief explanation: EEPROM can easily be used to store configuration data persistently even when the main flash is erased. When managing a large number of identical devices, being able to use the same firmware image for all devices is highly beneficial - especially during firmware upgrades. To still be able to configure each device individually, using EEPROM can be viable solution. This project should implement an optional hook executed during boot up that will load configuration data from the EEPROM and feed it into RIOT's standard configuration APIs.

This project consists of the following tasks:

  • Extend the existing EEPROM driver to allow the use of multiple EEPROM modules and add an extension API similar to RIOT's GPIO extension API
  • Convert existing users of the EEPROM-API to the new API
  • Add a driver for an external EEPROM module that can be used via the EEPROM extension API as a proof of concept
  • Join the effort to implement the EEPROM storage facility of the RIOT Registry
  • Extend RIOT's high level interface to sensors and actuators, SAUL, to provide a high level calibration API for sensors.
  • Add a Registry Handler on top of this high level configuration API

Expected results: RIOT gained the ability to use multiple EEPROM modules and external EEPROM. An EEPROM Storage Facility for the RIOT Registry was build on top of that. SAUL was extended to provide a high level calibration API. An Sensor Calibration Registry Handle was implemented to integrate the calibration API into the RIOT Registry.

Knowledge Prerequisite: C, embedded programming.

Project S3: unify RIOT's startup code across architectures

Project Category: System

Mentor: @kaspar030 (Backup: @emmanuelsearch)

Brief explanation: "Currently, all of the architectures supported by RIOT (ARM7, Cortex-M, AVR8, MSP430, RISC-V, MIPS32, native) have a unique startup procedure, despite doing similar work. This starts with differing names in the linker script for similar variables, continues with architecture-dependent assembler code for clearing bss and copying variables from the data section, different names for similar functions, order of initialization. This project is about analyzing unification potential and then applying it."

Expected results: all architectures have a defined and shared startup procedure

Knowledge Prerequisite: C, bare-metal embedded programming.

Project S4: RIOT Probes: Low Impact Data Acquisition for Automated Performance Evaluation and Testing

Project Category: System

Mentor: @maribu (Backup: TBD)

Brief explanation: For both automated performance evaluation and automated testing the common setup will consist of a computer and an embedded board. The computer will build and flash RIOT, start the test(s) or benchmark(s) and acquire data from the RIOT board. This data will then be classified by the computer as "test passed" or "test failed" in the testing setting, or the computer will calculate some performance metric out of it. RIOT's build system already solves automated building and flashing. For the tests and benchmarks often RIOT's shell is used, which is optimized for human-machine and not machine-machine interaction. The terminal output of the executed shell commands is collected and fed into a parser written for/tuned to the syntax used by the specific shell command. Using instead an interface optimized for data acquisition that uses a machine readable format could greatly reduce the effort of writing tests and benchmarks for RIOT.

This project consists of the following Tasks:

  • Propose a protocol/format to pass internal data from RIOT to a connected computer with the following features:
    • Machine readability (e.g. like JSON, XML, CBOR, YAML, ...)
    • Backward-compatible extensibility (E.g. lets say each data point is send a JSON object. If a new key is added an existing parses would still work by ignoring the new key)
    • Trival filtering of data (E.g. in the JSON object a key "sender" could be added with a value of the format <subsystem>.<module>.<function>. If the function dht_read() in the driver dht would create a data point the sender would be drivers.dht.dht_read.)
  • Propose a high level API that allows adding "RIOT probes" into the RIOT code base. Maybe it could look something like this:
int dht_read(const dht_t *dev, int16_t *temp, int16_t *hum)
{
    /* Code reading the sensor ... */ 
    rprobe_begin("drivers.dht.dht_read");
    rprobe_add_s16("temp", *temperature);
    rprobe_add_s16("humi", *humidity);
    rprope_send();
    return DHT_OK;
}
  • Implement these "RIOT probes" with taking special care that
    • when RIOT probes are disabled, no overhead in ROM/RAM/execution time is generated
    • when enabled, RIOT probes should have as little runtime overhead as possible and should ideally not block the calling thread
  • As proof of concept add a few RIOT probes to
    • the scheduler
    • your favourite network device driver
    • to GNRC's 6LoWPAN implementation
  • Extend RIOT's build system to be able to speficially enable RIOT probes for specified modules

Expected results: An API/protocol that allows the acquisition of data internal to RIOT in a machine readable format and implemented a few proof of concept probes

Knowledge Prerequisite: C, embedded programming.

Clone this wiki locally
You can’t perform that action at this time.