An embedded ecosystem for beginners

Projects Ideas
, ,
1

Summary

The goal is to develop a cohesive, beginner-oriented ecosystem that replicates the “Arduino experience” with a safe, Ada-centric workflow. At its center is a simplified IDE—the Hub—which abstracts away the complexities of toolchain management by integrating Alire as a first-class citizen. This project seeks to provide a “plug-and-play” path for students and makers.

Rationale: The Post-Arduino Landscape

The recent acquisition of Arduino by Broadcom marks a pivot toward corporate enclosure. With the introduction of proprietary “App Labs” and a shift toward subscription-based cloud services, the maker community is facing a loss of sovereignty over their own code and hardware.

While the “Arduino way” was always technically limited, its simplicity was its strength. We now have an opportunity to offer a superior alternative: an ecosystem that is just as easy to use but built on the rock-solid foundations of Ada. By moving the community toward an open, Alire-powered stack, we ensure that the next generation of embedded developers isn’t locked into a single vendor’s proprietary cloud.

The “Hub” Concept: Simplicity by Design

The central pillar of this ecosystem is a dedicated IDE. Unlike GNAT Studio (GPS) or the highly extensible VS Code, this Hub is designed to do only one thing: get code onto a chip.

Key Features:

  • Alire-First Workflow: The Hub acts as a visual wrapper for Alire. Beginners shouldn’t have to learn the CLI to add a driver. Adding a “NeoPixel” or “OLED” library should be a single-click action that updates the alire.toml in the background.
  • Zero-Configuration: Following the “no-hassle” spirit of projects like LEA (Lightweight Editor for Ada), the Hub will bundle or auto-download the necessary cross-compilers via Alire upon first launch.
  • Context-Aware Scaffolding: The IDE will provide templates for packages with explanation of typical aspects like “Pure”, “Preelaborate”, “Elaborate_Body” and so on.

Synergies and Foundations

We aren’t starting from scratch. This proposal seeks to unify existing high-quality community efforts:

  1. Tooling: We can leverage the lightweight architecture of LEA 0.93 as a starting point for the editor, focusing on its small footprint and responsiveness.
  2. Hardware Support: Community runtimes runtimes (specifically the light, light-tasking, and embedded profiles by damaki) provide the perfect foundation. It should be extended for affordable maker chips like ESPs.
  3. Drivers: We will utilize the Ada Drivers Library (ADL) to provide a consistent experience for all supported targets.

Comparison: A Shift in Philosophy

Feature The Legacy “Arduino” (Broadcom) The Ada Hub Ecosystem
Backend C++ (with “Magic” Pre-processor) Pure Ada / SPARK
Package Management Manual .zip or Library Manager Alire (Versioned, Reproducible)
IDE Cloud-tethered “App Labs” Local-First, Open Source
Safety Runtime crashes, “Silent” failures Compile-time safety

Call for Collaboration

To move this from a proposal to a working environment, I am looking for community input on:

  • The “Standard Library” for Beginners: What features should or intentionally should not be used in the HAL (e.g. interrupts, DMA)?
  • UI/UX Implementation: Should we build on top of LEA, or develop an IDE the runs in the browser and requires zero installation?
  • Tutorials: We need contributors to port classic Arduino “sketches” to this new Ada ecosystem, emphasizing how Ada’s range types and representation clauses make hardware interaction clearer.

The pieces—Alire, LEA, and the community runtimes—are already here. We just need to build the Hub that brings them together for the next generation of makers.

4 Likes
2

LEA is Windows only solution :person_shrugging:

3 Likes
3

App Lab is freely available under a GPL 3 license.

Aside from that, I don’t think the value of Arduino is that it’s simple to set up. ST, NXP, and MicroChip all have simple GUIs that do what you’re describing much better than Arduino IDE does. The value or Arduino is that there’s a giant community around it, that’s what you would need to replicate to compete with Arduino.

4

I’m an Ada beginner (as in a very beginner) so may not be the type of person you are looking for, but I am interested in using it for firmware (in FPGA’s really I have a Zedboard).

Regardless, I would be happy to try and help with this, by putting together very basic beginner tutorials. I will be quite busy until July though.

5

There are already various runtimes for bare metal and a hal, they need bringing together I suppose and a hook based application framework like arduino would sit on top for beginners and then you go further and remove the framework for more advanced stuff.

There’s also vscodium which removes the crap from vscode, so you can base an extension on that.

6

First of all, Arduino was acquired by Qualcomm, not Broadcom. (Broadcom acquired VMware).

Let us try to keep the evil corporations straight. Broadcom attempted a hostile takeover of Qualcomm in 2017/2018, but it was blocked the the first Trump administration, citing national security concerns. (FWIW, I have worked with components from both, and have found them about equally hard to extract specification information from).

Qualcomm has had Arduino for about six months, and I have seen no ill effects upon the Arduino IDE 1 and 2 (you install these to your development computer). On the other hand, I wouldn’t touch the cloud IDE with a ten-foot pole. Actually, I don’t use Arduino IDE 1 or 2 either…I either work from the command line with arduino-cli and make files or use Visual Studio Code. I’m retired and I teach robotics at a private school one day a week, and we’re just advancing from basic electronics to Arduino Unos.

During my class preparation, I stumbled across third-party Arduino core libraries for STM32 and RP2040/RP2350 microcontrollers that are really fantastic, including FreeRTOS support. I have actually been wondering how to graft Ada into the Arduino toolchains rather than to replace it with something else.

My investigation into Ada on RP2040 has also used make files, but I haven’t gotten around to incorporating support for Visual Studio Code yet.

7

On this point I’d like to add my two cents.

I think additional Alire commands might be more helpful then a new IDE. Something like alr gdb or the likes to start a gdb server and automatically push the code to the embedded device. Having a good CLI foundation is a must for any IDE.

And VSCode seams to be the cooler IDE than GnatStudio or LEA. There is more documentation for vscode and people who are interested in (embedded) programming are likely to already have it installed.

I personally use doom emacs as alire is preconfigured and I only need to enable ada support.

8

@ThyMYthOS this is a nice project. I’d like to share my two cents. As creator of the Ada Drivers Library (ADL), I thought about this topic for a while because, at one point, I considered shifting the ADL towards a similar idea.

The main goal of ADL is to provide full access to the underlying hardware features. There is some level of common interfaces across hardware (HAL.* packages), but you should be able to do anything you would do with the vendors’ drivers. So the drivers are difficult to set up and require some level of hardware knowledge, which varies from one vendor to another. Therefore, it is not very beginner-friendly. It’s a trade-off between capabilities (using all the hardware features) and ease of use.

Arduino, on the other hand, is focused on ease of use. Regardless of the underlying hardware, Arduino always provides the same features and interface. Which means you don’t have access to all the hardware capabilities (say STM32 DMA2D hardware-accelerated graphical operations), but the same piece of code will run on any of the supported boards, as is.

In the end, I decided to keep ADL as the full-featured drivers library, but I still think there’s room (and the need) in the Ada ecosystem for an Arduino-like platform that will complement the ADL/*_hal crates solutions.

Here’s how I would do it.

  • Copy the Arduino API: https://docs.arduino.cc/learn/programming/reference/
    • Keep it simple, don’t try to use advanced Ada features. Pins are integers, and that’s ok.
  • All the interfaces in a single package spec
    • The API can be documented in a single webpage, there’s no need to overcomplicate things
    • Follow the principle of least surprise
  • Don’t support more than one run-time, don’t support tasking / exception propagation
    • Tasking is an advanced topic, leave it for *_hal crates
    • Porting/maintaining a tasking run-time is not easy
    • Tasking is not possible/desirable on every hardware (e.g. AVR)
    • Using something like Alire - Bare_runtime, run-time support will just be a matter of linker scripts, easy
  • The hardware abstraction layer (HAL) should be a binary blob (static lib), and the interface package a binding over it
    • This way, implementation details of the HAL are hidden from the users
    • You can choose to implement the HAL blob in any language you want, including using the vendor’s drivers
    • One HAL blob per board, pre-compiled, shipped as a binary. Users are not exposed to the complexity and potential failures of building the HAL. The platform does that for you in CI/CD.

I like the idea of using a dedicated IDE, like codewith.mu for microPython/CircuitPython or the Arduino IDE. But you have to enable Ada language server support in some way, otherwise you will provide an outdated experience.

I hate to say this, but exposing Alire to the users seems dangerous; there’s a lot that can go wrong. One way would be to restrict the crates you can depend on to a subset, for instance, with a dedicated prefix (arduinolike_*). So people can contribute libraries meant for this ecosystem with an understanding of its limitations, and users stay within safe bounds.

I would also auto-generate and “hide” the .gpr files so that users never have to edit or see them.

Flashing and debugging are the hard parts. Doing embedded Ada without a debugger feels like you lose 30% of the benefits. Unfortunately, it’s very rare to have debuggers onboard, and if there’s one, using it doubles the complexity of setting things up.

Again, following Arduino’s path is probably the best option. You can only push binaries, and count on a serial port for feedback. One button to compile, one button to run, that’s it.

I will be happy to contribute to this project as much as I can.

PS: ADL is centralized/mono-repo because I created it before the Alire age. There are benefits to having everything in one place (consistency and interoperability being the main ones), but today this future is in Alire. And ADL is getting replaced by *_hal crates such as (samd51_hal, rp2040_hal, nrf5x_hal), which provide the same service but in a modular and decentralized manner.

2 Likes