5 ms·

I'm a huge fan of simulations, I don't think you can develop a 'good' embedded system without it. My way of implementing something embedded is: * Develop a cap

I'm a huge fan of simulations, I don't think you can develop a 'good' embedded system without it. My way of implementing something embedded is: * Develop a capture program for the input feed/sensors, and capture as much as you can. * Develop a software model to recreate the input for a 'target' embedded system * Write the embedded system against the captured input. That will get you 95% there. * Run it 'live', check anything wrong (you will). Usual debugging & tweaks. * Do a feedback loop if problem input comes in, and keep /that/ preciously for your test unit sequence. * Once software is done, every time you make a change, run your simulator with all the test input you have and check your output for divergence. I very, VERY rarely need to JTAG into a board, I'd rather spend the time on the simulation model and get it accurate as I can than spend time 'debugging' on the target. That's why I wrote simavr for example [0], but I also use qemu lot for bigger systems. Unfortunately it's next to impossible to get anything upstream in qemu, so most of the work there just is dropped eventually [1]. [0]: https://github.com/buserror/simavr https://github.com/buserror/simavr [1]: https://github.com/buserror/qemu-buserror https://github.com/buserror/qemu-buserror

fest 10y ago
Do you have any suggestions on deciding where to draw the line for simulation? It seems that you are suggesting instruction-level simulation of the same binary which is going to be deployed, correct? What is the performance you're usually seeing for simulations like that?
- buserror 10y ago
  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.
su30mki117 10y ago
What is your opinion on Model-based development? Model creation in MATLAB/SimuLink and code generation with the help of a suitable tool (ex. TargetLink). I recently came to know that this is the preferred method in the automotive industry in Germany atleast.

fest 10y ago

Do you have any suggestions on deciding where to draw the line for simulation? It seems that you are suggesting instruction-level simulation of the same binary which is going to be deployed, correct? What is the performance you're usually seeing for simulations like that?

buserror 10y ago
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.

su30mki117 10y ago

What is your opinion on Model-based development? Model creation in MATLAB/SimuLink and code generation with the help of a suitable tool (ex. TargetLink). I recently came to know that this is the preferred method in the automotive industry in Germany atleast.