Spec for Makerville Tools
Goals
Build modern CI/CD for embedded developers
The focus of the platform initially is 3 things -
-
Build the source code, version it, and run statistical analysis on the change to tell the developers how much of the devices resources their changes are consuming
-
Deploy the changes to their test fleet and get back a test report. This would be done with the help of a supervisor device that would be integrated into their physical test lab. To start with Makerville will configure and ship and off-the-shelf computer like a Raspberry Pi/BeagleBoard for this.
-
Collect logs from the test devices and make them query-able.
Values
Open source
Release all software under a copyleft open source license. Open source just makes more sense than any other model that is out there.
Extensible
We want to expose API endpoints, webhooks, and whatever else our users will need to extend the functionality of the platform. The idea is to build something akin to Linux i.e. something that can be used in drastically different industries with polar opposite requirements with some simple configuration changes.
Modern design
Make the user interface a top priority instead of an afterthought.
Stay Profitable
To make this a financially successful venture, so that it stays around for as long as it's needed, we will offer a commercial license for all our projects.
Built on open standards
Wherever possible we should use open source tools, libraries and most importantly, open standards.
Modern stack
To build an active community of contributors, it's important to use the tools and framework that have an active community behind it. This might sometimes mean picking the second or third best tool for the job - but it's well worth that trade off.
Components
- CI/CD tools
- Fleet management dashboard
- Data management
- Hardware middleware
- Device library
Details
CI/CD tools
Embedded systems developers have very little choice when it comes to tooling.
Name | Description | Additional notes |
---|---|---|
Makerville Kaagaz | tools to generate documentation from each build and version | PDF, HTML |
Makerville Taster | tool to download and flash builds on test devices | To be run on Overseer or a developer's machine |
Makerville Seraph | tool to build and upload release artifacts from your repo | Available as a Github Action/Gitlab Pipeline |
Kaagaz
One of the most underrated things to do is to treat documentation like code. We should version it, build it along with the code, and make it easy to access (HTML >> PDF). Kaagaz aims to do all of that, and then some.
Kaagaz is available as a CLI that is integrated with Seraph, and can also be used locally with git hooks.
Some of the things it does for your documentation
- Build a distributable PDF for your datasheet, user manual, and more
- Create a HTML website for easy sharing. Optionally password protect this website
- Embed links to builds and releases
Taster
Taster is a supervisor that downloads and flashes the latest builds from Makerville and sends back the test reports to the dashboard. It can be run on the developers machine or it can be run on the Overseer hardware that acts as the hardware supervisor for your test devices.
Some of the things that it does for your builds
- Manage the queue of builds for different hardware versions
- Connect to sensors and actuators for physically test your hardware
- Test and collect logs over serial
Seraph
Seraph is an integration for GitHub and Gitlab that links your repository to Makerville dashboard, and other tools. It also builds the code and documentation for your firmware repository using the enviroments provided by GitHub/Gitlab.
Some of the things that it does for your repo
- Statical analysis
- Manage compiler flags
- Track changes in firmware size
- Track changes in 3rd party library versions
- Show results from all the above the Makerville dashboard
Data management
Bidirectional communication
We need a way for the device and any client applications to communicate with each other using a light weight protocol that is suitable for microcontrollers. MQTT v5 is be the ideal protocol for such a usecase, and Eclipse Mosquitto(EPL/EDL licensed) is the most popular open source implementation for the same.
This channel is ideal for usecases like getting sensor data, communicating with the device about updates and rollbacks, making configuration changes to the device that is already deployed.
Object Store
We need an object store for 2 main reasons
- a place to host files required for device updates
- a place for the device to upload and download artifacts that it might need for its specific application (eg: machine learning models and data)
MinIO (opens in a new tab) is a popular open source (GNU AGPL v3) object store.
Hardware middleware
Makerville Overseer
The Overseer is an extensible physical computer with rich peripherals that is ideal for being at the heart of your in-house hardware lab. It is based on the BeaglePlay from BeagleBoard.org
The purpose of the Overseer hardware is to bridge the gap between your DUT (Device-under-Test) and the device management dashboard. Along with downloading firmware and test instructions from the dashboard, and uploading it to your test fleet, it will also provide extensible hardware using the Mikroe standard to help you physically test your prototypes.
Makerville Phone App
The Makerville Phone app is the swiss army knife for field technicians and engineers. It connects to your devices in the field using either BLE directly or using Modbus, Ethernet, serial, and more using additional hardware.
Architecture
Open source projects
Project | License |
---|---|
SQLite | |
Zepyhr | |
Grafana | GNU AGPLv3 |
MinIO | GNU AGPLv3 |
Mosquitto | EPL/EDL |
D3.js | |
MCUboot | |
Docker |
Roadmap
Phase 1 : Hardware testing
- Build the development tools for modern hardware workflows. Includes integration with version control, CI, CD, testing workflows and more.
- Create a dashboard to access builds and see device history
- Support versioning of software along with hardware. Ensure that underlying software libraries that are versioned are also tracked.
- Ideal customer is someone who wishes to make their development process faster, less manual, as well as keep a record of their releases
- Provide hardware (BeaglePlay) that works as the hub of their local hardware lab. Use wireguard to give access to this device through the dashboard and otherwise.
- In the dashboard, have the ability to create new data points for each device - calendar events, notes, and images.
Phase 2 : Fleet deployments
- Provide a standard way to deploy and manage devices in the field.
- Ideal customer is someone who - after using Makerville Tools for internal development - wants to manage their device fleets in production using a similar tool set
- Include features around Annual Maintenance Contracts (CalDAV and more)
- Support assemblies i.e. devices that are part of larger devices.
- Add support for role based access control (RBAC)
- Build a standard way to add extensions.
Phase 3 : Hardware partnerships
- Bundle certified hardware from partners
- Provide provisioning support for hardware
- Get on the train that's making India the next hardware manufacturing hub after China.
Further reading
- Better Embedded System Software by Philip Koopman