Finally – the new project is set to launch soon. The hardware is almost complete, albeit only on paper for now. Well, that's what the reference boards are for. So we can start development on the target platform right away. So far – so good.
The reality is usually different: Development boards may not be available or in sufficient quantities. Ultimately, this means the team has to fight over the few available units for the time being. But what can software developers do to get started despite these adverse circumstances? The solution is: Simulate. (not to be confused with "playing blue"). But even if hardware availability isn't an issue, there are many other reasons to use simulation.
Why simulate?
In addition to the reasons already mentioned, there are a whole range of other advantages:
- When you frequently switch between working in the office and working from home, you don't want to move all your equipment with you every time. You're always going to forget something.
- A hardware abstraction is desirable in principle because it facilitates the Porting to hardware variants or completely new hardware-OS combinations. If you change hardware later, you may have to switch to a different operating system or SDK. With an OSAL, the changes remain manageable.
- In many of my previous projects, the devices had one or more CAN connections to the controllers of the overall system. If you install a switch in the "right" place, you can test the application on a PC using a USB2CAN interface (this is relatively quick with SDKs from IXXAT or Vector, for example). This allowed customers to conduct initial tests on their laptops in a "real" environment – long before the first hardware was even available.
There have also been cases where we were able to quickly identify errors in the controller software using the debugger. This would have been a more difficult task with the application on the target. - As elsewhere, Diversity a win-win situation for everyone. In this particular case, I mean that different Compiler can be used (target platform: gcc, clang – developer platform: e.g., Visual Studio). Compilers are like us: sensitive souls – and everyone complains about something different. In this case, different compilers provide a gain in security – assuming, of course, that all compiler warnings are enabled (anything else is a no-go anyway!).
- In any case, the fact that it is much simpler Debugging A simulation is worth it. Instead of the usual turnaround cycles (compile/link – download – start debugging; sometimes even via an SD card/USB stick – especially nice!), just press F5 and off you go (okay – I've outed myself as a VS user).
- On top of that, you can also benefit from additional safety features in the runtime environment. For example, in VS or Clang, you can enable checks for buffer overruns, memory leaks, uninitialized memory access, stack overflows, etc. This saves you the use of extra tools or time-consuming troubleshooting/debugging on the target. Because when such an error occurs in the field, it can be incredibly expensive or even dangerous!
How?
First, the application is separated into a hardware or OS-independent part and an OSAL layer is created (OSAL=Operating System Abstraction Layer). Of course, you could also use the application code #ifdefs to enable the target-specific code only in the target build. Many of us have probably encountered such code before. It's not really nice. And that's not the only disadvantage. Readability, maintainability, testability, portability to other hardware/OS/... suffer.
A version of OSAL is implemented for the operating system on which the developers are working (usually Windows, Linux less frequently). Naturally, OSAL and the application for the development environment will have slightly different runtime behavior than that of the target platform. However, this isn't so important at first. The main thing is that application development isn't unnecessarily hampered.
In cases where the application is based on, for example, Flash- or EEPROMIf the processor needs to access memory, this can usually be easily simulated, for example, using file access. This also opens up additional possibilities for automated testing of hardware errors (such as read errors).
Simulation can be somewhat more difficult in cases involving serially connected hardware, for example. However, there are workarounds here, too. Data from the external device can be recorded and imported into the simulation (via file or pipe).
Ultimately, it's just a question of which level you install the switch on and which mechanism you use to implement its functionality.
A completely different approach could be to rely on more abstract interfaces from the outset, such as communication via sockets. This would even allow communication across computer boundaries.
As is often the case, creativity—with moderation and purpose—has no limits. In any case, it's worthwhile to consider this aspect at the beginning of a project.
Please do not hesitate to contact us with any comments, suggestions or questions – either via the comment function or directly via e-mail (info@medtech-ingenieur.de) or by phone (09131/691240). And if you're looking for a job as a software developer, we'd love to hear from you!