Developing embedded projects usually requires all physical hardware (displays, sensors, buttons) to test code. This increases costs, slows down prototyping, and often creates messy test setups with multiple wires and breadboards.
This project proposes a small open-source library of Fake Drivers that allows developers to:
Run the same microcontroller code on a PC using simulated hardware interfaces.
Seamlessly switch to real hardware if connected, without modifying the code.
Test and prototype embedded applications without cluttered testboards or unnecessary wiring.
The main goal is to speed up development, simplify debugging, and reduce hardware dependency during early prototyping.
Core Concept
Fake Drivers provide the same API and function calls as the original hardware libraries, so developers do not need to rewrite code.
Each Fake Device appears on the PC as a visual interface:
Display → opens a window representing the real screen.
Button → appears as a clickable button on the GUI that triggers events like a real button press.
When real hardware is connected, the Fake Drivers automatically bypass simulation and interact with the actual devices.
This allows testing realtime user interactions and UI logic without building a full physical prototype.
Example Usage
#include <FakeDrivers.h> // Fake Drivers library
#include <DisplayLib.h> // Original display library
#include <ButtonLib.h> // Original button library
// Define devices the same way for PC or MCU
Display display;
Button button;
void setup() {
// Initialize the display window and the button on PC
display.begin(); // Opens a window representing the display
button.begin(); // Shows a clickable button on the GUI
}
void loop() {
// Read the button state (real or fake)
bool pressed = button.isPressed(); // On PC: true if user clicks the button
// Draw on the display
display.clear();
if (pressed) {
display.drawText("Button Pressed!");
} else {
display.drawText("Waiting...");
}
delay(500); // Keep the loop simple for demonstration
}
How it works on a PC:
display.begin() → opens a GUI window that simulates the screen.
button.begin() → shows a clickable button that can be pressed with the mouse.
button.isPressed() → returns true if the user clicks the GUI button.
display.drawText() → renders text or graphics in the display window.
On real hardware, the Fake Drivers automatically pass calls to the real devices, no code changes required.
Key Benefits
Run and test embedded code on a PC before using real hardware.
Interact with fake devices through GUI interfaces, simulating screens, buttons, and sensors.
Avoid messy testboards and spaghetti wiring, making prototyping cleaner and safer.
Enable faster debugging, UI testing, and prototyping without purchasing every component.
Provides a foundation for an open-source library that can eventually support multiple MCUs and devices.
Call for Contributors
We are looking for embedded developers, students, and IoT enthusiasts to help conceptualize, design, and develop this project:
Share ideas for designing Fake Drivers interfaces.
Contribute support for additional types of devices and libraries.
Provide examples, demos, or GUI improvements to accelerate prototyping.
Join the discussion and help build a library that allows seamless testing of embedded code on PC and real hardware, saving time, reducing costs, and avoiding messy test setups.
I moved your topic to an appropriate forum category @ishakismaili.
In the future, when creating a topic please take some time to pick the forum category that best suits the subject of your topic. There is an "About the _____ category" topic at the top of each category that explains its purpose.
Hi @ishakismaili ,
Welcome to the forum..
Making a HAL, cool..
I simulated displays, using LovyanGFX lib..
Discovered this just after I finished mazes, this was on Windows..
Then I ported this over to the UnoQ which is Linux..
Uses SDL2 at the core which should also work on Mac, don't have any access though..
before I found WokWi there was picsimlab which runs on your PC, don't think they have the TFT screens though..
Hi, thank you for moving my topic and for the guidance. I appreciate the reminder and will make sure to choose the most appropriate category for future posts.
Yes, I’m aware of Wokwi—it’s a great simulator for ESP32, Arduino, and other MCUs. The difference with my approach is that Fake Drivers let the same code run on both a PC (simulated) and the actual MCU without any changes. It also allows runtime interactions via a PC GUI and can integrate with FreeRTOS tasks, which is difficult to fully simulate in Wokwi.
I’m planning to create a working prototype first, and I’ll share it with you so you can see exactly how it works in practice.
Yeah, Tinkercad/Wokwi are pretty cool for simulating embedded projects. The thing with my idea is a bit different: the same code runs on both your PC (simulated) and the real MCU without changing anything. You can also interact in real-time with buttons, displays, and sensors through a PC GUI, and it even works nicely with FreeRTOS tasks, which is tricky to do in standard simulators.
I’m planning to put together a small working prototype soon and can share it with you so you can see how it really works
That’s really interesting—you’ve tried multiple approaches and even ported stuff across Windows and Linux, which is no small feat. The idea behind my Fake Drivers is a bit different: it lets the same embedded code run on a PC (simulated) and on the real MCU without any changes. You can also interact in real-time with buttons, displays, and other peripherals via a PC GUI, and it can work with FreeRTOS tasks, which is often tricky in conventional simulators.
I’m planning to put together a working prototype soon and can share it with you personally so you can see how it functions in practice.
Really appreciate your input—it’s inspiring to see how others have tackled similar challenges
That is essentially what Wokwi is. However, Wokwi is a cloud-based service. So if you created a free open source simulator that can run locally then this could be of interest to the community, even if it was functionally equivalent (or even inferior) to Wokwi.
You might be interested in this project:
It is not the same thing as what you hope to create, due to the fact that it is intended to be used for automated testing rather than a human friendly simulation. However, it is similar in that it allows executing Arduino sketches on a PC host. So perhaps you will find something there that can be utilized for your project.
Since you hope to receive collaboration on the project, I suggest you publish your work to a GitHub repository (or one of the alternative Git hosts if you prefer).
Thanks a lot for your feedback, I really appreciate it!
I totally agree with you — real hardware is always the best when it comes to debugging and getting accurate results. I also enjoy working with real components whenever I can.
The idea behind this approach came more from practical limitations I face sometimes. In my area, certain components are hard to find or quite expensive, and that can slow things down or even stop a project midway. On top of that, sometimes I just want to quickly prototype ideas without spending too much time searching for parts or worrying about availability and cost.
But I completely respect the “real hardware first” mindset
Cross-posting is against the Arduino Forum rules. The reason is that duplicate posts can waste the time of the people trying to help. Someone might spend a lot of time investigating and writing a detailed answer on one topic, without knowing that someone else already did the same in the other topic.
Repeated cross-posting can result in a suspension from the forum.
In the future, please only create one topic for each distinct subject matter. This is basic forum etiquette, as explained in the "How to get the best out of this forum" guide. It contains a lot of other useful information. Please read it.
I apologize for the cross-posting. I understand this has happened before, and I take responsibility for it.
As I’m still new to this type of community, I had some misunderstanding of the rules. I now have a clearer understanding and will follow the guidelines moving forward.
