Public Access
twislaandClaude Sonnet 5.5
3b4100dc6a
/dev/ has Debug Builds and the Debug Console (builds and the token, the console and its protocol, files and screenshots, driving the UI, crashes and Safe Mode, the command reference), Build, test and release (including how an update works), the architecture decisions and the milestone plans. Generated from the repository by site/tools/gen_dev_docs.py: the ADRs, the milestones, the README's sections, and the command reference, read from the firmware's own `help` text. The pages are committed (Zola cannot read outside its folder); the Site workflow checks they are current, and now also runs when src/main.cpp changes. M0, M1 and CONTEXT.md are not published. README: the gnss commands that the table lacked. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
1.2 KiB
1.2 KiB
+++ title = "Debug Builds and the Debug Console" description = "A firmware you can drive from your desk: its console over Wi-Fi, its screen as a PNG, its SD card, its crash dumps, and a way back when an update goes wrong." template = "guide-index.html" page_template = "guide-page.html" sort_by = "weight" weight = 1
[extra] eyebrow = "Developer docs" +++
A Debug Build is the same firmware plus a Debug Console: the serial console, over Wi-Fi, behind a token. It is the most useful thing in the project. With it you can:
- see everything the device prints, boot messages included, without a cable;
- run every serial command from your desk;
- press keys and take screenshots, so a UI change can be tested and looked at remotely;
- copy files to and from the SD card;
- read crash reports and fetch core dumps, decoded against the exact build that crashed;
- update the firmware over the same Wi-Fi, and know that a bad update rolls back to a build that still has the console.
Start with Debug Builds to put one on a device, then the Debug Console. The rest are what you can do with it.