u/Rolex_37

I got incredibly tired of manually compiling and flashing my ESP32 every single time I made a minor code change, so I spent some time building a tool called FlashBot to automate the entire loop.

Right now, the workflow is completely hands-off. Here is what it does:

Auto-detection: Uses Linux udev events to detect the board the second it's plugged in.

Smart matching: Looks up the correct sketch from a config file (or prompts me to choose if I have multiple sketches mapped to that specific board).

Compile & Flash: Pulls everything together via arduino-cli and flashes it automatically.

History: Logs every single flash into a local SQLite DB so I don't lose track of versions.

Current Status: The core detection and flashing logic are fully stable. Right now, I'm working on polishing up a serial test suite and the logging system.

What I'm planning to build next:

Serial validation: Automatically open the port, send a test command, and verify the response post-flash to make sure the firmware is actually alive.

Differential builds: Only recompile if the sketch or dependencies actually changed.

Broadening hardware support: Moving beyond standard Arduino/ESP32 to natively handle STM32.

Mass flashing: Parallel flashing for when you need to push the same firmware to a handful of boards at once.

The goal isn't to replace your IDE or build system—it’s just to completely cut out the tedious "plug, compile, click flash, open serial, check" routine.

At its core it's a hobbiest tool if used in that manner

If you do a lot of hardware prototyping, does this hit a pain point for you? What kind of features would make a tool like this actually useful in your day-to-day workflow?

I got incredibly tired of manually compiling and flashing my ESP32 every single time I made a minor code change, so I spent some time building a tool called FlashBot to automate the entire loop.

Right now, the workflow is completely hands-off. Here is what it does:

Auto-detection: Uses Linux udev events to detect the board the second it's plugged in.

Smart matching: Looks up the correct sketch from a config file (or prompts me to choose if I have multiple sketches mapped to that specific board).

Compile & Flash: Pulls everything together via arduino-cli and flashes it automatically.

History: Logs every single flash into a local SQLite DB so I don't lose track of versions.

Current Status: The core detection and flashing logic are fully stable. Right now, I'm working on polishing up a serial test suite and the logging system.

What I'm planning to build next:

Serial validation: Automatically open the port, send a test command, and verify the response post-flash to make sure the firmware is actually alive.

Differential builds: Only recompile if the sketch or dependencies actually changed.

Broadening hardware support: Moving beyond standard Arduino/ESP32 to natively handle STM32.

Mass flashing: Parallel flashing for when you need to push the same firmware to a handful of boards at once.

The goal isn't to replace your IDE or build system—it’s just to completely cut out the tedious "plug, compile, click flash, open serial, check" routine.

If you do a lot of hardware prototyping, does this hit a pain point for you? What kind of features would make a tool like this actually useful in your day-to-day workflow?

I'm a CS student getting into embedded systems and I ran into a problem that kept facing:

ESP32 takes a time to compile, and if you're using something like Arduino IDE and just trying to flash the same file again it recompiles everything from scratch — even if nothing changed. That's a of wasted time when you're iterating fast on firmware.

So instead, what my project does is that it detects when a board is plugged in, checks if the source file has actually changed using a hash comparison, compiles only when necessary, flashes the firmware automatically, runs a test suite over serial to validate responses, and logs everything to a SQLite database for full traceability.

The USB detection and flashing are done. Rest of the pipeline in progress.

Known issues I'm aware of:

• Board-specific drivers still need manual setup per machine
• Currently only reliable on Linux/Mac — Windows COM port detection is inconsistent
• STM32 support via st-flash is still rough
• Not containerizable cleanly due to USB passthrough limitations in Docker

Looking for:

• Feedback on whether this is actually useful to other embedded developers
• Whether anyone has hit similar walls building something like this
• Any suggestions on the architecture or approach

Has anyone built something similar or know of existing tools that solve this better?

and is this project worth building on? and is there any use of open sourcing it?

Want me to adjust the tone or add anything specific?

I'm a computer science and systems engineering student and I'm really interested in getting into robotics ,not just software but electronics and the mechanical parts as well. I'm still a first year student and secured an internship in robotics which deals with simulation. But i end up asking the same question of how do I do this or how realistic is this plan of mine.

I'm currently learning analog and digital electronics to complement the software side as well. So is it possible for me to be a sort of "full stack" for robotics