This is the first thing I started looking for when I started gathering ESP32s. I will definitely be checking this out! My main thought for it was experimenting with Meshtastic firmware without potentially bricking one of my devices.
Very cool, that was something I was looking into very recently.
I vibe coded a drone simulator that flys drones by simulating ESP32 in the browser where the actual flight controller C code that runs on real ESP32 is running as WebAssembly: https://mrtksn.github.io/liftlab/
So the drones are flying with the actual ESP32 flight controller and you can flash the real ESP32 board directly.
My work isn't as nearly as impressive as yours, I have some ESP32 boards and a Pi at hand and wanted to build a drone that adapts to different geometries and motors of inconsistent specs so I built this realistic as possible drone simulator that also simulates the boards alongside with the radio, battery, sensors and motors inside a physics simulator. The code that runs in the real boards is executed as a WebAssembly so it behaves exactly the same as it receives simulated sensor data.
The Pi board is intended for navigation and more complex tasks and is able to update the ESP32 flight controller even mid-flight.
On a lot of IoT projects, it's easier to create a "functional" software simulator for the hardware part so the mobile and cloud people can get going without having to wait for test hardware. Those simulators work at the level of emulating BLE or WiFi/API commands. Once you have hardware, the simulators are only used in CI/CD testing.
Where I can see this coming handy is instead of a "functional simulator" to actually have real firmware running for each mobile or back-end dev and CI/CD runner.
The challenge is is getting the peripherals emulation detailed enough to be useful - and in reality it'll never be good enough to completely replace physical hardware because you're trying to clone a buggy black box whose API is only vaguely documented.
But if it's just an approximation anyways, why not save yourself an awful lot of time and emulate the HAL a few layers up for the 95% of logic which doesn't require the actual hardware?
Just like in software, your cloud web app doesn't need a cycle-accurate emulation of the entire Amazon cloud. Mocking a few REST calls is often more than enough, and in practice mocking the SDK API has basically the same result.
Yes, it is also very very useful when doing agentic coding of ESP32 software - no messing with HW until you have something that works reasonably well already. So less time spent flashing.
… are just too much with their dense mix of formatting, brackets, semantic punctuation, command line arguments and part numbers etc. (This one is particularly absurd but it's not the only one).
I may be middle-aged now and a non-expert but I am pretty sure these things are generally exhausting to even expert young readers. I would urge you to reconsider how this page is presented.
Yes, I can agree - no one can read the docs anymore - too long and to messy. Will consider taking a pass on that soon. Thanks for the feedback! I did not really expect this level of interest when I started - just to avoid carrying all esp32 devices all the time - for demoing...
I can tell that a README.md becomes a DONTREADME.md when its contents are:
1) As long as a novel.
2) Poorly formatted.
3) Has several claudisms in each sentence.
It is one that I am not going to read and not even the author read it themselves either.
It’s also a predictor of the level of slop in a project since it is getting worse with the people talking about “code quality” have now vanished and are no where to be found.
True... Will take a pass - we are planning a 0.3.0. release I guess that is when we also should make it possible for humans to read the README and not only for agents...
Wokwi is SaaS emulator with a monthly cost - I need to have a tool for my own vibe coding of new ESP32 software - this is the tool I needed - and it turned out quite ok. Free for all, free forever is the plan. I'd call it developed by emulator developers using Claude - not "vibe" but partly spec-driven partly "vibed". It is fantastic to not need to read tons of specifications as Claude is doing that while developing but you still need to know what you are doing... (I have developed emulators quite a while... starting around mid 90s).
I will push back against this broad class of question (critisism?), as it could be applied to the large majority of creations people making, exluding a minority of truly novel things, and outright clones.
For a relevant example, look at Show HN: You could make this same post with a slight variation on every one of them.
It’s not a criticism. The creators of these projects have most likely shopped around and used existing projects before deciding to build their own. I’m as interested in the “why” they built something as much as the project itself. Unfortunately, with LLMs, it looks like writing and communication skills have taken a hit.
No, it's just that meaningful answers to "why" are hard to come by when you might only have twenty minutes invested.
In 2027, I can assure you I won't be shopping around for existing projects very often.
For starters, I don't need them. Second, it might take me longer to learn theirs than to build my own. And last, the amount of slop getting pushed out is going through the roof, making discoverability a difficult problem already.
It's a vibecoded project, so isn't it more like a creation of Claude? I think it's quite relevant to see where/if the clanker improved on the existing product.
I have tried to use wokwi several times and I ran into roadblocks trying to do what I want with it. They want you to pay and that’s limiting. I get trying to extract value for your work. But I love the idea an OSS solution you can do whatever you want with.
Yes, we all use better tools than writing in plain assembly these days. I am super happy that tools get better all the time... Worst time was entering DATA on C64... to do fast code (for me at least). Now life is better ;-)
Any plans to support H2?
This is awesome, I will certainly use it for some of my recent embedded work. Will try and contribute back as well.
This is the first thing I started looking for when I started gathering ESP32s. I will definitely be checking this out! My main thought for it was experimenting with Meshtastic firmware without potentially bricking one of my devices.
Very cool, that was something I was looking into very recently.
I vibe coded a drone simulator that flys drones by simulating ESP32 in the browser where the actual flight controller C code that runs on real ESP32 is running as WebAssembly: https://mrtksn.github.io/liftlab/
So the drones are flying with the actual ESP32 flight controller and you can flash the real ESP32 board directly.
Cool - so you also did a ESP32 emulator?
My work isn't as nearly as impressive as yours, I have some ESP32 boards and a Pi at hand and wanted to build a drone that adapts to different geometries and motors of inconsistent specs so I built this realistic as possible drone simulator that also simulates the boards alongside with the radio, battery, sensors and motors inside a physics simulator. The code that runs in the real boards is executed as a WebAssembly so it behaves exactly the same as it receives simulated sensor data.
The Pi board is intended for navigation and more complex tasks and is able to update the ESP32 flight controller even mid-flight.
Outstanding! Very cool.
On a lot of IoT projects, it's easier to create a "functional" software simulator for the hardware part so the mobile and cloud people can get going without having to wait for test hardware. Those simulators work at the level of emulating BLE or WiFi/API commands. Once you have hardware, the simulators are only used in CI/CD testing.
Where I can see this coming handy is instead of a "functional simulator" to actually have real firmware running for each mobile or back-end dev and CI/CD runner.
The challenge is is getting the peripherals emulation detailed enough to be useful - and in reality it'll never be good enough to completely replace physical hardware because you're trying to clone a buggy black box whose API is only vaguely documented.
But if it's just an approximation anyways, why not save yourself an awful lot of time and emulate the HAL a few layers up for the 95% of logic which doesn't require the actual hardware?
Just like in software, your cloud web app doesn't need a cycle-accurate emulation of the entire Amazon cloud. Mocking a few REST calls is often more than enough, and in practice mocking the SDK API has basically the same result.
Yes, it is also very very useful when doing agentic coding of ESP32 software - no messing with HW until you have something that works reasonably well already. So less time spent flashing.
Very nice! Are you planning P4 support? Have lots of S3 units and some C6, but P4 are the ones getting the most attentation at the moment.
Yes, it is in the plan - but I need to get some P4s also. Likely within a few weeks it should be there.
This emulator is actually pretty cool — especially since it’s based on an ESP32; you can do all sorts of neat things with it, even simple ones:)
This is huge! I love the idea of this and I’ve been frustrated by the solutions offered earlier.
Thanks!
I actually want to have a play with this sometime. But honestly, these gigantic, poorly-formatted AI-slop paragraphs like the one below this heading…
https://github.com/mikroverk/esp32sim#boards-esp32-s3
… are just too much with their dense mix of formatting, brackets, semantic punctuation, command line arguments and part numbers etc. (This one is particularly absurd but it's not the only one).
I may be middle-aged now and a non-expert but I am pretty sure these things are generally exhausting to even expert young readers. I would urge you to reconsider how this page is presented.
Yes, I can agree - no one can read the docs anymore - too long and to messy. Will consider taking a pass on that soon. Thanks for the feedback! I did not really expect this level of interest when I started - just to avoid carrying all esp32 devices all the time - for demoing...
#this-should-have-been-a-table.
I can tell that a README.md becomes a DONTREADME.md when its contents are:
It is one that I am not going to read and not even the author read it themselves either.It’s also a predictor of the level of slop in a project since it is getting worse with the people talking about “code quality” have now vanished and are no where to be found.
True... Will take a pass - we are planning a 0.3.0. release I guess that is when we also should make it possible for humans to read the README and not only for agents...
Is there one for RP2350?
Not in esp32sim - but I also happen to have Cooja-NG there we do have both RISC-V + ARM Cortex M33 - so it would not be hopeless to get that emulated.
It would be great fun.
so cool!!
How is this different from Wokwi.com? They’ve been doing for years, and have a large number of microcontrollers emulated.
Wokwi is SaaS emulator with a monthly cost - I need to have a tool for my own vibe coding of new ESP32 software - this is the tool I needed - and it turned out quite ok. Free for all, free forever is the plan. I'd call it developed by emulator developers using Claude - not "vibe" but partly spec-driven partly "vibed". It is fantastic to not need to read tons of specifications as Claude is doing that while developing but you still need to know what you are doing... (I have developed emulators quite a while... starting around mid 90s).
I will push back against this broad class of question (critisism?), as it could be applied to the large majority of creations people making, exluding a minority of truly novel things, and outright clones.
For a relevant example, look at Show HN: You could make this same post with a slight variation on every one of them.
It’s not a criticism. The creators of these projects have most likely shopped around and used existing projects before deciding to build their own. I’m as interested in the “why” they built something as much as the project itself. Unfortunately, with LLMs, it looks like writing and communication skills have taken a hit.
No, it's just that meaningful answers to "why" are hard to come by when you might only have twenty minutes invested.
In 2027, I can assure you I won't be shopping around for existing projects very often.
For starters, I don't need them. Second, it might take me longer to learn theirs than to build my own. And last, the amount of slop getting pushed out is going through the roof, making discoverability a difficult problem already.
It's a vibecoded project, so isn't it more like a creation of Claude? I think it's quite relevant to see where/if the clanker improved on the existing product.
OSS and the price? It may be vibe coded but the price is free.
yes, and this make your cool esp32 software demoable on GitHub pages for free!
I have tried to use wokwi several times and I ran into roadblocks trying to do what I want with it. They want you to pay and that’s limiting. I get trying to extract value for your work. But I love the idea an OSS solution you can do whatever you want with.
yes, and if you get stuck - post and issue or even a PR!
This one is vibecoded
Yes, we all use better tools than writing in plain assembly these days. I am super happy that tools get better all the time... Worst time was entering DATA on C64... to do fast code (for me at least). Now life is better ;-)
Clickable link: https://wokwi.com/