2021-11-06 Firmware brainstorming for the next cycle

Owned by Ryan Dancy
Nov 06, 2021
3 min read

  • Replace build system (Scons?)

    • Standardize protobufs

    • Dependency management

    • We can play with the directory structure

    • Can we get rid of clang? Alternatively, consider changing compilers (clang might be better if it supports our platform)

    • Consider each part of the toolchain

  • Dev environment reform

    • Virtualbox is really slow and GDB-in-VSCode is hard to attach

    • Can we use a docker container instead?

    • See backpack, packer projects

    • Upgrade Ubuntu, make it easier to integrate new dependencies

      • In general, we really need proper dependency management

  • Rewrite the CAN library to be easier to use

    • It’s really hard to unit test because of the event system

    • Concurrency nightmare

    • Support CAN FD, if the MCU supports it

  • Rewriting projects

    • Not the drivers though

    • We don’t really know what hardware is doing

    • At the least we’ll end up refactoring a lot

    • More cohesive design, standard ‘template’

  • Research projects

    • Looking at different hardware (not STM32F072)

      • Could do a dual-core processor

      • Could upgrade the microcontrollers

      • Supporting CAN FD?

    • We’re using standard peripheral library → what about the ST-supported one? Other open-source peripheral libraries?

    • Standardization: MISRA C

    • Over-the-air bootloader updates

  • Proteus, or Simulink (Matlab), for simulating hardware

    • Would need a sponsorship for the license

    • In theory we could simulate the whole electrical system in Proteus/Simulink/etc

    • Would need component files for ICs

  • Telemetry: we can probably reuse the infrastructure

  • CAN FD

  • FreeRTOS

    • Real-time operating system (RTOS)

      • We’re on bare-metal, no scheduling handling, everything done through interrupts

      • RTOS handles scheduling through a kernel

        • FreeRTOS uses tasks, which are like threads

        • Tasks get prioritized, FreeRTOS schedules based on priority, saves us from doing it ourselves

    • MSXII was looking into an RTOS, many other cars use FreeRTOS (e.g. Stanford)

    • FreeRTOS is supposed to be minimal, should be very small (good for embedded / 128kB limit)

    • Benefits

      • More efficient, scheduler takes care of wait()

      • We can separate tasks out easier

      • Lots of support for real-time best practices

      • A lot better documented than ms-common libraries, easier to understand inner workings

        • Also, the team gets a lot of understanding of embedded concepts when rewriting

      • Clean up ms-common, standardize interface

      • There is x86 simulation support! (third party)

      • Safety - it provides guarantees on task scheduling

      • Marketable skill in industry

    • Drawbacks

      • We have to rewrite almost all the core ms-common libraries (CAN, I2C, etc) → it would replace a lot of event handling, FSMs, etc

      • Would take a lot of effort/time

      • Onboarding overhead / learning curve (another FW 10x session)

      • Debugging is a bit hard (threads) but tools exist

    • Unit testing? There is tooling around it, we will have to learn concurrency

      • It’s abstracted into separate tasks so we can test one at a time

    • Timeline: probably 4-8 months to rewrite the libraries

      • More viable if racing in 2024 than 2023 (probably a hard no if in 2023)

    • MSXII got the kernel set up, it’s easy to set up

    • Initial feedback: if we have time, let’s do it

  • Languages other than C (with FreeRTOS)

    • We investigated Rust before

    • C++ is possible

  • Lessons learned from validation and building a firmware system

    • Design for validation

    • Smoke tests

    • Separate out the functionality for unit testing and smoke testing

    • It should be very easy to verify that each feature works

    • In the future we should have more of the people writing the firmware also validating the firmware