Idea 5 of 6 · Embedded, open hardware
Oreo badge desktop simulator
Open Oreo to contributors without hardware by building a desktop simulator with headless golden-image tests.
Description
The problem this idea addresses and why it matters.
Oreo is an open MicroPython OS for an ESP32-S3 conference badge: about 22k lines of Python and 21 apps. The project is young, and today apps run only on hand-built hardware, with no automated tests, so very few people can contribute.
The OS already defines a hardware abstraction layer (oreoOS/api.py), but
several modules bypass it.
Impact. A simulator, a program that runs the badge software on an ordinary computer, opens Oreo to contributors without hardware and allows automated tests to check the apps on every change.
Expected outcomes
What must exist at the end of the project.
- Close the abstraction-layer leaks: inject dependencies into the launcher, and put IR, wifi and battery behind the API.
- A desktop backend on the MicroPython unix port, with a windowed mode and a headless mode.
- Scripted button input and a deterministic clock.
- A fake IR bus connecting two simulator instances.
- A pytest harness with golden-image tests, running in CI.
Stretch goals
Optional work, attempted only once the expected outcomes are complete.
- A web-canvas build.
- Wifi and HTTP mocks.
- A video playback fallback.
Out of scope
Work that is not part of this project, even if it appears related.
- Cycle-accurate ESP32 emulation.
- BLE emulation.
- A new quest protocol.
How success is measured
The checks that confirm the work is complete.
- At least 15 of the 21 apps run unmodified.
- Two simulated badges exchange an IR frame.
- Headless CI checks golden images.
- A new contributor builds an app from
app_templates/without hardware.
Material
The code, documentation and issues this idea builds on.
Code and documentation
- Repository: elixpo/oreo
- Setup instructions (README)
- Contribution guidelines (CONTRIBUTING)
- Codebase overview
Set up from the README; no private keys needed. If a step asks for a secret, report it as a setup issue. See configuration and access.
Related issues
No issues are linked to this idea yet. Ask about it at gsoc@elixpo.com.
Warm-up tasks
Complete at least one before you submit a proposal, and share the result as a pull request or by email to the programme address.
Set up this project: see Warm-up for the exact commands, how to tell they worked and known limitations. No private keys needed.
- Clone Oreo and read the README. No badge hardware is required.
- Read
oreoOS/api.py, then identify one module that imports hardware directly instead of going through it. - Install the MicroPython unix port and record how far an app runs before it requires hardware.
- Open a small documentation or test improvement pull request in the repository, and respond to review until it is merged or closed.
Skills, size and mentors
- Skills
- Size
- 175 hours
- Difficulty
- Intermediate
- Mentors
Ayushman Bhattacharya- Primary mentor
Vivek Yadav- Backup mentor
The primary mentor is the contributor's main contact; the backup mentor can step in. Send questions about this idea or the programme to gsoc@elixpo.com, and report defects as an issue in the repository. Mentors aim to reply within 48 hours on weekdays. GitHub Discussions for GSoC 2027 will open once Google announces the programme dates.
Terms used on this page
- MicroPython: a small version of Python for tiny computers.
- ESP32-S3: the small computer chip inside the badge.
- Simulator: a program that pretends to be the hardware, on an ordinary computer.
- Hardware abstraction layer: one shared layer of code that apps use to
talk to the hardware. Here it is
oreoOS/api.py. - Leak, bypass: code that talks to the hardware directly instead of going through that layer.
- Inject dependencies: pass in the parts a module needs, so a test or the simulator can swap in fakes.
- IR: infrared, the invisible light the badges use to talk to each other.
- MicroPython unix port: the version of MicroPython that runs on Linux and macOS.
- Headless: running without a window, for automated tests.
- Deterministic clock: a fake clock that tests control, so results are always the same.
- pytest, pygame, SDL: pytest is a Python testing tool. pygame and SDL are libraries for drawing windows and graphics.
- Golden-image tests: tests that compare the screen with a saved, known-good picture.
- CI: tests that run automatically on every proposed change.
- Cycle-accurate emulation: copying the chip's exact behaviour, step by step.
- BLE: Bluetooth Low Energy.
General terms such as mentor, proposal and pull request are defined in the glossary.