Codethink recently worked on platform libraries for the real-time M4 cores of the MediaTek MT3620, the first Azure Sphere chip certified by Microsoft focusing on the development of a set of drivers for the peripheral subsystems (SPI, I2C, I2S, ADC, PWM, GPIO and Timers).
The work involved developing the drivers (design of the interface, profiling & optimisation) alongside a set of example applications; showing how they would be used in practice. The libraries are to be used with an IoT platform, and the drivers play an important role. They handle every major I/O function of the Azure Sphere MT3620 library, including microphones, sensors, interfacing screens and even raw GPIO.
Instead of allocating larger teams of engineers to projects, Codethink prefers to identify a small team of experts to work on projects. A team of four embedded systems specialists, Ben, Kostas, Connor and Aiden, completed the initial work over the space of four months, including addressing any issues or bugs that arose. With work complete, the intention was to move the code into the open and publish on GitHub.
The engineers followed simple principles in designing the libraries but ones that require an amount of thought.
“Good library design comes down to following de facto standards and keeping interfaces as minimal as possible. It’s also important to be able to imagine what a user might expect from your library without them knowing anything about how the library works internally.” - Ben Brewer, Senior Engineer
As the libraries were modular; the team decided on priorities and delegated the work on each based on core competencies. The development team used a bare-bones existing API as a jumping off point and generated a similar basic cross-platform API whilst also supporting the hardware. The approach worked well and, as a result, most of the libraries were working early in the project.
The team identified areas to optimise the libraries, with the solution revolving around using DMA acceleration where the hardware would support it and minimising any extra code required. Having a smaller codebase to maintain and reducing the size of the work chain created.
The Codethink team ensured that whilst they worked, they ensured that the codebase is well documented; which is a must for open source work, as poor documentation can prove to be a barrier to use and adoption.
The work completed by the team enables the device to run low-level code in real time. This means that it will be able to interface with time-critical and CPU intensive peripherals. This has a positive impact on performance as developers can now use the two real-time 200MHz M4 cores instead of sharing time on the high-level A7 application processor.
We are delighted to be open sourcing this work, and are excited to further develop our offerings for Azure Sphere.
Here you can find the drivers and a set of example applications.
Other Content
- Speed Up Embedded Software Testing with QEMU
- Open Source Summit Europe (OSSEU) 2024
- Watch: Real-time Scheduling Fault Simulation
- Improving systemd’s integration testing infrastructure (part 2)
- Meet the Team: Laurence Urhegyi
- A new way to develop on Linux - Part II
- Shaping the future of GNOME: GUADEC 2024
- Developing a cryptographically secure bootloader for RISC-V in Rust
- Meet the Team: Philip Martin
- Improving systemd’s integration testing infrastructure (part 1)
- A new way to develop on Linux
- RISC-V Summit Europe 2024
- Safety Frontier: A Retrospective on ELISA
- Codethink sponsors Outreachy
- The Linux kernel is a CNA - so what?
- GNOME OS + systemd-sysupdate
- Codethink has achieved ISO 9001:2015 accreditation
- Outreachy internship: Improving end-to-end testing for GNOME
- Lessons learnt from building a distributed system in Rust
- FOSDEM 2024
- QAnvas and QAD: Streamlining UI Testing for Embedded Systems
- Outreachy: Supporting the open source community through mentorship programmes
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: Exploring a Bug in Stack Unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Achieving Long-Term Maintainability with Open Source
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Full archive