3 ms·

No I do not necessarily advocate instruction level -- sometime it's just not practical. If course if you can it's good (aka QEMU or simavr) but sometime it's no

No I do not necessarily advocate instruction level -- sometime it's just not practical. If course if you can it's good (aka QEMU or simavr) but sometime it's not possible or not necessary. For example in my last opens source project. I fed the signal I was receiving to a plain linux program, because I was more interested in the algorithm than the pure embedded bit. THEN I transposed it all into the embedded firmware as is (See [0], there are still remnant of that in the rather shotgun-style linux program). So 'applicative' simulation is as good for many cases, while the instruction level is good when you want to validate the /true/ embedded responses of the real CPU... The idea is primarily to be able to isolate the problems, and be able to develop/test them in a feedback loop individually if possible. As for instruction level speed, well, these days QEMU is likely to be at least as fast as a good ARM CPU without any problem (very often, a lot quicker). And simavr is several hundred times quicker than a real AVR when running on a x86* host. In fact, it's often more of a problem trying to simulate 'real time' like input/timers than the other way around... [0]: https://github.com/buserror/rf_bridge https://github.com/buserror/rf_bridge

diydsp 10y ago
You are wise. This is how I develop, too. The strategy is essentially to develop the algorithm/software outside the embedded platform, then port it to the embedded platform. I, too, record input data streams and process them via desktop. Then I stream the recorded data through the embedded system. In the worst case, updates can be made in the embedded system, but in the best case, they can be developed and proven outside then the benefits carried out into the embedded system. These days, I firewall as much code as possible into "flat", "pure" C/C++ files that contain no low-level calls or libraries or includes whatsoever. Even my tasks under RTX are wrappers to the actual tasks. I can run my multi-task programs under linux just fine with a pseudo task manager. My build system uses the same exact C files for both the desktop and embedded code. There are layers of API calls, but the compiler just optimizes them all out so I don't even sweat it. You might think that makes it less "realistic," but in practice, it makes it more robust, since the tasks are (mostly!) coded to run at any frequency or pattern of switching. You might think this massive front-loading takes time, but it's never wasted. Things come out so clean at the end. Especially because lots of documentation can be written between the desktop and the embedded porting. I was inspired to do this by projects like MAME and MIDIBox. Both are multi-media real-time system across numerous platforms. They benefit from repeated porting. It shakes the bugs out.

diydsp 10y ago

You are wise. This is how I develop, too. The strategy is essentially to develop the algorithm/software outside the embedded platform, then port it to the embedded platform. I, too, record input data streams and process them via desktop. Then I stream the recorded data through the embedded system. In the worst case, updates can be made in the embedded system, but in the best case, they can be developed and proven outside then the benefits carried out into the embedded system. These days, I firewall as much code as possible into "flat", "pure" C/C++ files that contain no low-level calls or libraries or includes whatsoever. Even my tasks under RTX are wrappers to the actual tasks. I can run my multi-task programs under linux just fine with a pseudo task manager. My build system uses the same exact C files for both the desktop and embedded code. There are layers of API calls, but the compiler just optimizes them all out so I don't even sweat it. You might think that makes it less "realistic," but in practice, it makes it more robust, since the tasks are (mostly!) coded to run at any frequency or pattern of switching. You might think this massive front-loading takes time, but it's never wasted. Things come out so clean at the end. Especially because lots of documentation can be written between the desktop and the embedded porting. I was inspired to do this by projects like MAME and MIDIBox. Both are multi-media real-time system across numerous platforms. They benefit from repeated porting. It shakes the bugs out.