A development approach that feels especially well suited for M5Stack + AI coding: add an SDL-based PC simulator and use it as the AI’s temporary “eyes” during development.
Why is SDL a particularly good fit for M5Stack?
Because M5GFX already has native SDL support. Instead of building and maintaining a completely separate fake UI, the same M5GFX-based drawing code can be rendered either to the real device display or to an SDL window on a PC.
In practice:
During development:
This is very useful for AI-assisted development. Instead of guessing what the device screen will look like from source code alone, the AI can run the PC version, inspect the rendered result, and iteratively adjust fonts, spacing, buttons, menus, and layout before doing the final test on real hardware.
I prefer treating the SDL simulator as disposable development scaffolding:
• UI and application logic are shared with the real device
• SDL is only used for development and AI visualization
• SDL-specific code lives under something like devtools/simulator
• Production firmware has no dependency on SDL
• The simulator uses a separate build target
• The entire simulator directory can be deleted without affecting the real M5 firmware
A prompt I use for coding agents is:
I think this is a very natural pattern for embedded development in the AI era:
Instead of adding video output to the device, use M5GFX + SDL during development to give the AI a virtual screen it can actually see.
Why is SDL a particularly good fit for M5Stack?
Because M5GFX already has native SDL support. Instead of building and maintaining a completely separate fake UI, the same M5GFX-based drawing code can be rendered either to the real device display or to an SDL window on a PC.
In practice:
Same UI code → M5GFX → Real LCDDuring development:
Same UI code → M5GFX → SDL window on PCThis is very useful for AI-assisted development. Instead of guessing what the device screen will look like from source code alone, the AI can run the PC version, inspect the rendered result, and iteratively adjust fonts, spacing, buttons, menus, and layout before doing the final test on real hardware.
I prefer treating the SDL simulator as disposable development scaffolding:
• UI and application logic are shared with the real device
• SDL is only used for development and AI visualization
• SDL-specific code lives under something like devtools/simulator
• Production firmware has no dependency on SDL
• The simulator uses a separate build target
• The entire simulator directory can be deleted without affecting the real M5 firmware
A prompt I use for coding agents is:
When developing an M5Stack project, use M5GFX’s native SDL support to create a PC-side display simulator as disposable development scaffolding. The simulator should reuse the real device’s M5GFX UI and application logic rather than maintaining a second UI implementation. Configure the appropriate screen resolution, rotation, and input mappings for the target device. Keep all SDL-specific code inside an isolated directory such as devtools/simulator and use a separate build target. Production firmware must not depend on SDL. Deleting the entire simulator directory must not prevent the real M5 firmware from building and running independently.
I think this is a very natural pattern for embedded development in the AI era:
Instead of adding video output to the device, use M5GFX + SDL during development to give the AI a virtual screen it can actually see.
