There’s something that kills coding speed—iteration time. If you can smash a function key and run your code, then watch it break, tweak, and smash it again—you’re working fast. But if you have to first compile your code, then plug your hardware in, burn it to the board, and so on… you’re wasting a lot of time. It’s that problem that inspired [Larry] to create an embedded system simulator to speed development time for simple projects.
The simulator is intended for emulating Arduino builds on iPhone and Mac hardware. For example, [Larry] shows off a demo on an old iPhone, which is simulating an ESP32 playing a GIF on a small LCD display. The build isn’t intended for timing-delicate stuff, nor anything involving advanced low-level peripherals or sleep routines and the like. For that, you’re better off with real hardware. But if you’re working on something like a user interface for a small embedded display, or just making minor tweaks to some code… you can understand why the the simulator might be a much faster way to work.
For now, [Larry] has kept the project closed source, as he’s found that it wouldn’t reasonably be possible for him to customize it for everyone’s unique hardware and use cases. Still, it’s a great example of how creating your own tools can ease your life as a developer. We’ve seen [Larry]’s great work around here before, like this speedy JPEG decoder library.
Just a few layers of emulation occurring here….
https://wokwi.com/ is great for this when your device(s) are supported. It is possible to add new devices, but it’s not trivial
Can I use it to run 5 picos and communicate between them? I have a project…
This is not the purpose of my project – nothing like Wokwi. My project allows me to be efficient at software development and write/debug/profile my embedded code on my very fast and comfortable Mac.
I am confused. Why did Larry publish details about this project if he is just being a gatekeeper about the whole thing? It doesn’t benefit him or anyone else.
Replied to the wrong comment, but the point still stands.
I write software for a living, in other words, to make money. I share tons of unique software as open source, but this particular project is not something I want to give away. I’ve customized it for a few clients and they got tremendous productivity boosts from it. I’m quite tired of all of the “give me”, and “write it for me”, requests. If you read the blog post, you will understand the purpose of sharing info about this project in this form.
I’ll be honest and try to hopefully not sound rude.
I have found hardware emulation to be in either of two camps. One is ultra simplistic, with fisher price toy tier UIs, made for hobbyists, education and beginners in general. Great if you want to see your animated LED blink, but not much else. Anyway, it serves the intended target audience well, so who am I to complain?
The other is the wild west with thousands of dollar worth of proprietary solutions, multi headed dragon fighting with the tooling. But if your hardware is as valuable as the management thinks, this is truly the only way.
There is nothing in between. Something that can let me just figure out if my TWI or SPI bus code actually works before having to flash it on the actual device. Something that can let me hook up a pulseview/saleae recording of logic states to a simulated GPIO. Its great that we have several different emulated architectures but I’m not writing assembly, so its not truly useful for me, at the level that I want.
Your “in between” is called BSP, but it requires one to be a competent software engineer, not just a code monkey flipping registers to save 0,4935 ns on function call. Then you can run your code in qemu and test is to your heart’s content.
BSP, as in a “board support package”? Its always a bunch of poorly commented code and examples which try to hide all complexity behind single line do_complex_thing() type functions
Sorry, that doesn’t work this way :-(
(I still remember cursing STM’s USB implementation, where whoever wrote the code didn’t understand two-dimensional arrays and made a big mess, and other examples.
Or stories from coworkers about certain companies BSPs that were… less than bug-free.
You are 100% missing the point. Please read the blog post.
Not only is the project closed source, it appears to be somewhat closed access, in that you need to email the developer to discuss getting ahold of a copy. It’s possible I’m link-impaired, but I don’t think there’s a way to download an executable on your own. That’s not unexpected given the situation he describes.
It’s too bad he doesn’t just release it with zero support and zero contact info. Just create a github under a junk email address and don’t use any real contact info. I understand not wanting to support random “gimme gimme” people, but you can still share the code and disconnect yourself from it somehow.
Zephyr RTOS, native sim, forget doing proprietary emulation.
For hardware emulation, you can take a look at Renode.
It is under the MIT license.
It is a bit on the complex side, but it can be integrated with CI tools
It can also simulate environmental data that are read through UART, SPI, and others over a CSV file
https://github.com/renode/renode
https://renode.io/
I’m not affiliated with Antmicro, I just like what they did
Use Forth. Instant turnaround time.
“For now, [Larry] has kept the project closed source, as he’s found that it wouldn’t reasonably be possible for him to customize it for everyone’s unique hardware and use cases.”
I’d argue that this is a reason to open source it. He wouldn’t be able to do it alone. But many people would add their own hardware compatability.
i don’t get it. i’ve seen a bunch of ’embedded simulators’ marketted as development tools and i’ve never understood the point.
if you are building custom hardware with unusual functionality, you can’t hardly test that except in reality. and if you are building like the example, a ‘normal’ device with a display…then yeah you are debugging regular big-computer tasks like displaying a UI, instead of debugging embedded tasks like “what happened to my timer interrupt??”, then yeah you can emulate it…but why would you? like the rp2040 pico is capable of driving a display, and capable of talking usb too, and it’s super convenient to program and re-program. if i had to develop UI code for it, i would just do that on-board.
like i have definitely had the frustration of re-socketting a PIC12 for every new build, but that was completely unamenable to emulation. the modern microcontrollers where you are writing software that is much bigger than just a minimal hardware interface should already be convenient to upload new code to. if you’re still using something inconvenient in this role, you need to switch to rp2040!
Since it’s talking about the modules that do not directly touch the hardware seems like it is better to just compile those portions to your native CPU. It will run faster and you don’t need to do the burn or emulation. Just run the executable under test on your desktop / laptop.
Typically these days those modules are linked with unit tests and that is what you’re actually running as you iterate.
If all your code is tightly coupled with the RTOS you must need to pick an RTOS that can target your native environment. Which is probably most of them.
Forth interactive portable single task OS works best?
Now along with gcc c compiler transparent portable loader/linker upgrades, of course.
I figured that out quick when I was doing embedded development in college. I simulated the embedded environment on my PC and tested it there first. Unit testing is also another huge help!