AarC10
commented
3 weeks ago I would also recommend breaking up each module's native_sim implementation into separate branches that get merged into another branch before going into main. So for example feature/Batman/native_sim_impl/sensor_module and feature/Batman/native_sim_impl/power_module would get merged into feature/Batman/native_sim. Then when feature/Batman/native_sim is ready, it can be merged into main
Is your feature request related to a problem? Please describe. Currently, you need hardware to run firmware (shocker). We should be able to simulate application behavior over native_sim. Compiling for native_sim will generate a Linux executable that can be ran locally (if you use a superior OS). This can increase accessibility for backplane development and help further isolate dealing with most software level issues from hardware issues.
Describe the solution you'd like Define overlays for native_sim in the boards folder under each module project. Since hardware can't really be simulated, some more investigation needs to be done into this. We should see how other projects emulate hardware too.
Additional context Zephyr has hardware emulators which we should look into using. For sensors, we may want to just have a very simple sensor emulator driver that takes in a minimum and maximum bound in the devicetree. Then just uses a random number within those bounds when fetching new samples. Since this would be considered a different device and there may be instances of DEVICE_DT_GET_ONE in the code, we should also generify how we specify devices in the project.