A Simple Embedded System in X Flavours
Most of us are here because we enjoy writing code that makes things happen in the real world. Throughout this conference and tech talks during the year, we are presented with lots of options for our embedded systems.
These options are often presented to us as floating gently down a calm river.
Yet, when we come to use these technologies in our serious systems, where we want reliability, unit testing and CI/CD, we feel like we are rapidly tumbling down towards a big waterfall.
How do I get a simple embedded system to work for me?
In this talk, I will discuss my experience getting a simple embedded system (reading a sensor and displaying it to a user) working in X technologies such as:
- Simulation: Custom, Renode, Wokwi
- Bare Metal / Languages: C, C++, Rust (Ferrocene), Ada, Circuit Python, Arduino, LibHal
- RTOS: ThreadX, FreeRTOS, Zephyr, Integrity OS, Riot OS, PX5, uC OS III, eCos, SafeRTOS, Nucleus
According to Tim Guite, what is the main practical obstacle when moving beyond simple "blinky" demos to real embedded projects with new tools?
Glad you enjoyed the talk! I would definitely endorse unit tests as part of software development, I have found them very useful and they fulfill the "regression test" aspect of some standards such as ISO 62304. System simulation is certainly complicated and not suitable for all situations. Teaching with a known simulated setup could be useful, avoiding issues about whether wires are connected properly or whether your corporate antivirus will allow you to plug in the USB cable! I also want to investigate Renode further, as they have examples of simulating connected systems for wireless mesh networking which would be very difficult to do with real hardware. Interesting times!
Very useful presentation. Thank you!
Very welcome Mohammed, great to hear you enjoyed it!
I've never seen Wokwi before. Seems really interesting, especially for that period of time before you get custom PCBAs back from the vendor. Normally I try to hack together dev boards, but maybe this could be worth trying instead.
Hey Mark, yea it is a really cool tool! Uri has a talk this year which goes into much more detail here: https://embeddedonlineconference.com/session/Breaking_Good_Why_Virtual_Hardware_Prefers_Rough_Handling
This was the first time I've used it in depth and I was quite impressed with how well it works!
Thanks for this overview of tools. Just like CI is getting more and more used in embedded systems, I am looking forward to seeing simulation tools like Wokwi and Renode being used more and more in the near future.
Also, sorry for the driver: I worked on the dht20 driver in Zephyr. Don't hesistate to raise an issue on Zephyr's github so it can be improved ;-)
Glad you found it useful! I really think that every embedded project beyond hobby level should have CI or a very CI-like script which builds and runs tests. Hopefully simulation tools can help extend that to (virtual) hardware in the loop tests and also allow more firmware development to take place alongside/ahead of electronic design!
Thanks for contributing the device driver! I probably did something wrong but will give it another look soon!
That was a great presentation (it linked well with Uri Shaked's talk "Breaking Good" about wokwi). It's hard to know what to even look for when getting started. "In the meantime I'll tell you how I got here" - this was my favourite bit, just after seeing all the detail in VS Code screen. Have you since had any joy with Renode? It seems to have potential, but I found little documentation out there apart from their own and a couple of articles from memfault that I didn't find useful for getting started.
Thanks Simon, glad you enjoyed it! Not yet, I agree that Renode has potential and that moving past the demos they have is not obvious. Worth looking into further!
Very happy to answer any questions :) The repo is here if you want to look at the code: https://github.com/TimGuite/simple_embedded_system
Thank you for sharing your experience with us!
Testing is really important in every type of development, regardless of its nature: whether it is mechanical, electrical or software engineering. The day I read James Greening's book "Test Drive Development for Embedded C" really changed the way I'm doing my job.
Though I'm kind of skeptical about using full-fledged simulators like Wokwi. I'm inclined to consider them more like a learning tool. It's fancy, colorful and does not involve "true" schematics, so it's perfect for a rookie developer with no hardware background.
Hence, using them for production-grade, complex software is barely possible. The main reason is that one never knows what's going on inside that simulator. What it simulates precisely and what not. Whether there are bugs? It is way too complex, so in the end, you may run into the case when you're testing the simulator itself, not the software it is running. Maybe it will change in the future, I don't know.
But as for today, my humble experience shows that decent coverage with unit tests eliminates the majority of the possible bugs and prevents occasional code degradation. Those are also easily integrated into the CI/CD flow, as they may be written hardware-independently. The rest is better run using real hardware.
But anyway, thank You for your opinion!