[HN Gopher] Velxio 2.0 - Emulate Arduino, ESP32, and Raspberry P...
___________________________________________________________________
Velxio 2.0 - Emulate Arduino, ESP32, and Raspberry Pi 3 in the
Browser
Author : dmcrespo
Score : 185 points
Date : 2026-03-27 20:44 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dmcrespo wrote:
| Hey HN, I posted Velxio here a while back and got great feedback.
| Since then I've shipped a major update
|
| What's new in v2:
|
| - 19 boards across 5 CPU architectures (AVR8, Xtensa, RISC-V, ARM
| Cortex-M0+, ARM Cortex-A53) - ESP32 emulation via QEMU (lcgamboa
| fork) -- real flash images, ROM function emulation,
| GPIO/ADC/timers - ESP32-C3 and CH32V003 run on a custom RISC-V
| core written in TypeScript, entirely in the browser - Raspberry
| Pi 3B via QEMU raspi3b -- boots real Pi OS, runs Python -
| Realistic sensor simulation: DHT22 (40-bit protocol timing), HC-
| SR04 (trigger/echo), WS2812B NeoPixel (GRB decoding) - 48+
| electronic components from wokwi-elements
|
| Architecture:
|
| - AVR, RP2040, and RISC-V emulation runs client-side (avr8js,
| rp2040js, custom TS core) - ESP32 Xtensa and Pi 3 run on backend
| QEMU - Compilation via real arduino-cli - React + Vite frontend,
| FastAPI backend - Self-hostable via Docker, no account needed
|
| Source: https://github.com/davidmonterocrespo24/velxio (AGPLv3)
|
| Happy to discuss the emulation architecture -- particularly the
| trade-offs between in-browser vs. backend QEMU emulation
| philkrylov wrote:
| Hi, adding WS2812B LED strips of arbitrary length would be
| awesome! Scrolling the canvas is sometimes problematic.
| Otherwise very interesting.
| dmcrespo wrote:
| Thanks! That's a great suggestion, supporting WS2812B strips
| with arbitrary length is definitely something I'd like to
| add. I also have in mind adding many more LED based
| components. I'll take a look at improving the canvas
| scrolling too
| ehnto wrote:
| When I try to visit velxio.dev, a CrowdSec page shows up and
| says I am not allowed to view it. I am a pretty normal android
| user on firefox mobile, so that is surprising.
|
| I look forward to trying this out though, great project!
| dmcrespo wrote:
| Oh, thanks for reporting this.that definitely shouldn't
| happen. It's likely an overly aggressive CrowdSec rule
| blocking some legitimate traffic. I'll look into it and
| adjust the configuration
| dmcrespo wrote:
| Quick update: this should be fixed now. It was an overly
| aggressive CrowdSec rule blocking some legitimate traffic.
|
| If anyone still has issues accessing velxio.dev, let me know
| ehnto wrote:
| Nice one! I can access it now.
|
| Really awesome project, it runs well on my old android
| phone, the fact that I can use a tool like this on my phone
| is pretty wild, you have done well with the UI in that
| regard. The oscilloscope is a really nice feature too.
| dmcrespo wrote:
| Mobile support is something I've been paying a lot of
| attention to, so it's really good to know it runs well
| even on older devices.
|
| And glad you liked the oscilloscope, that was a fun one
| to build.You can select the motherboard and ping you want
| to monitor.
| dmonterocrespo wrote:
| Velxio 2.0 is live.
|
| A free, open-source emulator for 19 embedded boards: Arduino,
| ESP32, Raspberry Pi, RISC-V , running real compiled code in your
| browser.
|
| The best part: it's fully local.
|
| No cloud dependency. No student accounts. No data leaving your
| network. Self-hostable with a single Docker container.
|
| Universities and bootcamps can deploy it on their own servers and
| give every student access to a complete embedded development
| environment, for free.
|
| I've been working on this for over a year, and just shipped v2.0
| with ESP32 emulation (via QEMU), a custom RISC-V core, and
| Raspberry Pi 3 support that runs real Python
| exe34 wrote:
| Is it easy to feed an elf or bin and run that (esp32c3)? I see
| compilation available, but I'm playing with asm and have my
| toolchain figured out already and would just like to emulate
| the firmware.
| mysteria wrote:
| Another +1 for this one as this is what turns this tool from
| a toy environment with basic sketches into something that's
| actually useful for larger projects with a full toolchain,
| libraries, and so forth.
| dmcrespo wrote:
| That's exactly the direction I'm aiming for
|
| A lot of simulators stop at simple sketches, but the goal
| with Velxio is to support more realistic workflows ,
| multiple boards interacting, real toolchains, and more
| complex setups
|
| Still early, but definitely moving in that direction
| mech422 wrote:
| just curious - if it runs from a docker container, what is the
| advantage of running the browser as opposed to just ssh'ing in
| ?
| dmcrespo wrote:
| The main advantage is accessibility and ease of use: with the
| browser, no setup is required on the user's side, no
| toolchains need to be installed, and there's no need to be
| familiar with SSH or terminal workflows
|
| It also provides a more visual and interactive environment
| (editor, peripherals, simulation controls), which is
| especially useful for teaching and for beginners.
|
| The Docker image is there so you can easily install it on
| your own machine if you want to run it locally or work on
| development
| mech422 wrote:
| The visual component editor does look pretty nice :-) I
| guess I always just associated sbc's with a more 'hands on'
| style...
|
| Anyway, seems like a pretty cool project - congrats!
| dmcrespo wrote:
| Thanks! The visual editor is actually a big part of the
| project
|
| I used a little AI to create the graphical interface
| since I focused heavily on emulation, testing, and
| refining and optimizing the circuit editor. But now I
| have plans to improve the UI and make it faster and more
| intuitive
|
| Still a lot to improve there, but glad it's useful
| already
| jdnenen wrote:
| Emulating the CPU is nice, but the trouble has always been
| emulating the peripherals
|
| Does your editor do this? I tried the example but didn't see
| e.g. LEDs blinking
| dmcrespo wrote:
| You can add peripherals There's a "+" button on the right
| side of the circuit editor where you can add components like
| LEDs
| dmcrespo wrote:
| Yes,peripherals are fully emulated, not just the CPU. LEDs
| blink, buttons respond to clicks, Serial Monitor works,
| servos rotate, displays render (ILI9341 TFT), and we have 48
| o more components from the wokwi-elements library. The Blink
| example should show the built-in LED toggling on pin 13. If
| it didn't blink for you, it might be a compilation issue
|
| try the example Traffic Light : Simulate a traffic light with
| red, yellow, and green LEDs
| functional_dev wrote:
| does this handle the timing differences between browser
| execution and real time hardware? or is it focused on logic
| verification?
| dmcrespo wrote:
| Both, with a nuance. The AVR simulator syncs to wall-
| clock time and each frame calculates cycles from real
| elapsed deltaMs, so delay(1000) takes 1 real second and
| timer-dependent code (PWM, millis()) runs at correct real
| time rates. The RP2040 and ESP32-C3 simulators use a
| fixed cycles-per-frame budget (125MHz/60 and 160MHz/60
| respectively), which targets real time but doesn't
| compensate for frame drops . if the browser stutters,
| emulated time stretches slightly. All three are cycle-
| accurate at the instruction level though, so the logic
| and peripheral behavior is faithful to real hardware
| regardless of frame timing
| hex4def6 wrote:
| First of all: Awesome work! Playing with it now.
|
| One suggestion: The main splash screen image is nearly 8MB big.
| It takes a noticeable time to download on my connection. I'm not
| sure what bandwidth costs these days, but seems like that could
| be something to optimize.
| dmcrespo wrote:
| Thanks a lot! Yes, that's something I have pending, I'm
| planning to replace it with an SVG or an animated GIF to
| improve loading time
| radicality wrote:
| I often write a bunch of Esphome 'code' , which I then use with
| various esp32 based devices (mostly from M5stack) via
| esphome/HomeAssistant.
|
| Can this project help me in any way during dev stage before
| uploading the code to device just to see it doesn't work ? Eg
| could I use this to somehow compile&run those esphome yamls via
| this emulator?
| dmcrespo wrote:
| That's a really interesting use case. I'm currently evaluating
| integrating the ESPHome compiler into the project, so it could
| potentially compile and run ESPHome YAMLs during the
| development stage
|
| It's still exploratory, but it could definitely go in that
| direction
| cyberax wrote:
| That would be awesome! ESPHome is the easiest way to
| integrate custom devices into your HomeAssistant with online
| updates, logs, and other functionality. Nothing else comes
| close.
| urbandw311er wrote:
| This is a great idea. It's always been inconvenient requiring
| access to the physical board just to be able to test these sort
| of projects.
| dmcrespo wrote:
| Exactly,that's the idea. Not having to flash the chip a
| thousand times just to see if everything works. The goal is to
| let you test the setup as fast as possible, ideally without
| installing anything locally
| wumms wrote:
| Nice work! One minor point for me: it wasn't immediately clear
| that you need to press Compile before Play gets enabled (e.g.
| Arduino IDE let's you upload right away and compiles if needed)
| dmcrespo wrote:
| Good point.I'll improve that. Thanks!
| kaycebasques wrote:
| Can someone who has used both wokwi and this do a
| compare/contrast? The footer suggests that it's built on top of
| wokwi-elements
| dmcrespo wrote:
| Velxio is definitely inspired by Wokwi, and I really like what
| they've built. Parts of Velxio also reuse open-source
| components , for example, the wokwi elements are used for the
| visual SVG rendering of boards and peripherals, but they don't
| include any emulation logic.
|
| I also integrated a couple of existing open-source emulators,
| like the Raspberry Pi Pico and Arduino ones. And I even reached
| out to the creator of Wokwi to share the project.
|
| In terms of differences, one of the biggest ones is that Velxio
| supports multiple heterogeneous boards in the same circuit: for
| example, two Arduinos connected over SPI or serial, ESP32 with
| Arduino, Raspberry Pi 3 with a Pico, etc.
|
| Another major difference is the focus on full emulation,
| including ESP32 (via QEMU) and a Raspberry Pi 3 running Linux
| (still in beta).
|
| There are also quite a few other differences, but those are
| probably the most notable ones
| GCUMstlyHarmls wrote:
| The container instructions has `-d` in it, but note that after
| booting the container it downloads another, I don't know, 300+mb
| more (its still downloading as I write), so if you can't connect
| that's why.
|
| Might be better to not include `-d` in the instructions?
| dmcrespo wrote:
| Good catch!!! thanks for pointing that out
|
| The container pulls additional assets on first run (mainly
| emulation dependencies), which is why there's extra downloading
| even with -d.
|
| You're right that it can be confusing. I'll update the
| instructions to make this clearer (and probably remove -d so
| users can see what's happening)
| flymasterv wrote:
| Awesome. Is there any chance of getting MicroPython or
| CircuitPython support?
| dmcrespo wrote:
| I'm currently working towards that.
|
| The Raspberry Pi emulation already runs Python, and I'd like to
| extend that into proper MicroPython / CircuitPython support for
| microcontrollers as well
|
| It's a bit tricky depending on the board/emulator, but
| definitely a priority!
| dmcrespo wrote:
| Quick update: traffic is still coming in waves, had to scale up
| compilation workers to keep up with demand
|
| Things are more stable now, but still tuning performance under
| load
|
| If anyone finds it useful, the source is here:
| https://github.com/davidmonterocrespo24/velxio
|
| Always happy to get feedback or contributions.
| mvkel wrote:
| This is fantastic. I am doing my first-ever consumer electronics
| product and this would save a lot of soldering time
| dmcrespo wrote:
| That's awesome -- and exactly the kind of use case I had in
| mind
|
| Being able to iterate without constantly flashing hardware can
| save a lot of time early on.
|
| If you end up trying it in your workflow, I'd love to hear how
| it goes
| triilman wrote:
| I like this Idea but I don't want to use this. I know what kind
| of prompt U using to create this one: "Create something like
| Wokwi and make it local"
| dmcrespo wrote:
| Fair enough , though there's quite a bit of low-level work
| behind it (emulation cores, QEMU integration, protocol timing,
| etc)
|
| Definitely inspired by existing tools, but trying to push
| further into full multi-board emulation and local-first
| workflows
| noahnathan25 wrote:
| Pretty cool project! if you're checking it out, try one of the
| built-in examples and hit "Compile + Play". It runs immediately,
| no setup required
| dmcrespo wrote:
| Thanks! Yeah, that's probably the easiest way to get started,
| just load an example and hit "Compile + Play".
|
| I tried to make it as close to zero-setup as possible so people
| can just jump in and experiment
| suwsixect wrote:
| Great project! Now all there is left to do is a VS Code plugin.
| Also make it play nice with platform io.
| orangmisterius wrote:
| Abang
| dmcrespo wrote:
| Thanks, appreciate it! Glad you like it
| Surac wrote:
| Nice Project. One of the benefits of such small boards is the
| ability to provide a "Hands on" experience. Use your hands to
| wire, press buttons and turn knobs. Emulating all this is a big
| thing but it takes away the learning in my eyes. It's like flying
| drones. It looks cool but gets boring after 10 minutes.
| sourdoughtronic wrote:
| That looks awesome, thank you for your hard work! I would love
| tinker with it, but I'm not sure how to abstract things connected
| to those supported u_controller boards? Example, 7x16 Pico
| unicorn hat is driven by RP2040 PIO.
| dmcrespo wrote:
| PIO isn't abstracted yet, we use rp2040js which has a full PIO
| emulator that executes the actual PIO instruction set (MOV,
| SET, PUSH, PULL, etc.) cycle by cycle, including the FIFOs and
| clock dividers. So it's not an abstraction. it's a direct
| emulation of the PIO state machines, same as how avr8js runs
| real AVR instructions
| xyrox1 wrote:
| Good job
| dmcrespo wrote:
| Thanks, appreciate it!
| varispeed wrote:
| Isn't the problem with these emulations that they are not
| realtime and therefore will never give true feedback? As in the
| simulation will unlikely to translate to real world behaviour.
| deringeorge2 wrote:
| Really impressive - browser-based hardware emulation is a brutal
| WebAssembly performance problem. Curious what you're doing for
| the rendering layer: are the circuit visualizations on
| canvas/WebGL, or DOM-based? I've been hitting similar render-loop
| problems with a deck.gl mapping project (realtime vessel
| positions, thousands of points updating simultaneously) and the
| pattern I found that helped most was batching state updates on a
| fixed 2s interval before diffing the render layer - prevents the
| WebGL context from recomposing faster than the data actually
| changes meaningfully. Does Velxio have a similar throttle, or
| does it redraw on every emulation tick?
| dmcrespo wrote:
| Thanks! The rendering is DOM-based, circuit components are Web
| Components (from the wokwi-elements library) wrapped in React,
| and wires are SVG. No Canvas/WebGL, which keeps it simple for
| the component count we're dealing with (typically dozens, not
| thousands).
|
| The emulation itself is pure JavaScript (avr8js), not
| WebAssembly. The simulation loop runs on requestAnimationFrame
| and executes 267K AVR instructions per frame (16MHz / 60fps) in
| a synchronous batch. Port listeners use dirty-checking so the
| UI is only notified when a GPIO register actually changes value
| and since all those cycles run in one JS microtask, React
| reconciles exactly once per frame regardless of how many state
| changes happened during the batch
|
| So there's no explicit throttle interval like your 2 sec
| approach, but the architecture achieves something similar. the
| CPU runs freely, state changes are coalesced within each rAF
| frame, and the DOM only sees the final result. For your deck.gl
| case with thousands of points, the 2s batch makes sense since
| you're dealing with a much higher entity count hitting the GPU
| , our problem domain is simpler (dozens of components) but the
| cycle-accurate emulation is the expensive part
| pshirshov wrote:
| From what I can see, I cannot give it an ESP32-C6 firmware binary
| to execute, I have to compile my source code (C only) and the
| source has to use Arduino APIs. Under the hood it's still QEMU.
___________________________________________________________________
(page generated 2026-03-28 23:01 UTC)