Most ARM developers spend their days in front of an embedded IDE, which comes with a cross-compiler and a cross-debugger. The thought that you build your code for the target device, and run the code on it, is deeply rooted. And there are very good reasons for this - hardware dependencies, timing issues, and other things that prevent portability. In short, it is often very difficult to compile your embedded application into a host-PC application - or, at least to run it on the PC. And why would you?
As it turns out, there are several situations when this is a very good idea. This is why Atollic TrueSTUDIO bundle not only an ARM Cortex toolchain, but an x86 host-PC toolchain as well. Effectively, Atollic TrueSTUDIO can be used both for embedded development and PC application development at the same time. Read this blog post to learn more on this unusual but very powerful capability!
Let's consider the differences between embedded and PC applications for a while. A command-line PC application is usually developed using "clean" C or C++. Admittedly, GUI applications are different beasts, but lets keep the discussion to command line applications for simplicity.
Embedded applications are quite different. Not only do they have (many!) hardware dependencies, including SFR register access and interrupt handlers; they also require obscure linker configuration files, interrupt vector tables, debugger initialization scripts, power-on-reset startup code, and other things that makes life complicated. There might be timing dependencies and hardware requirements too. The net effect is that embedded code will not easily compile and run on a PC. Or would it?
Even if you have no intention of running your embedded code on a PC, it is good programming practice to isolate hardware dependencies from generic algorithm code and other application logic. In short, any experienced embedded developer would develop the embedded system using a well-defined architecture, with software modules, clear interfaces, and hardware abstraction layers.
With a properly designed embedded system, any hardware or operating system dependencies are isolated using hardware or platform abstraction layer code. An abstraction layer is software code that "maps" a platform-independent API call to a specific implementation for a particular underlying platform. By replacing the abstraction layer library, a piece of software can be made to work on a different platform.
By moving any hardware and platform dependencies into well-defined abstraction layer libraries, "clean" generic C or C++ code can thus be moved into a PC application, and be run on a PC. What reasons could there be to do this?
I can list several situations when this is of value, and I am sure many more exist. Consider, for example, these use cases:
- Assume you have an algorithm that analyze live-sensor data. It is hard, if not impossible, to reproduce identical sensor readings. This makes it very difficult to run regression tests on the algorithm code, as the input data may change for every execution run. It becomes hard to verify an algorithm change did not break anything. If you move the algorithm code to the PC, the same algorithm could read well-known data from an input data file instead of from a real-world sensor with volatile input data. This makes it possible to do regression testing of the algorithm itself. Admittedly, the move from an ARM processor/compiler to an x86 ditto might introduce bugs. But I would argue this risk is smaller than the risk of introducing bugs in the algorithm code.
- In another scenario, you might have an embedded system with a proprietary UART, USB, CAN or Ethernet application-layer communications protocol. If your communications protocol is implemented using generic C or C++ code without hardware dependencies (except a hardware abstraction layer), it can be moved to any computing platform. And so, while the protocol was first implemented on the embedded system, it can also be run as part of a PC application. In effect, the protocol stack talks to itself, in the form of a PC application exchanging messages with the embedded system. PC utilities that connect to the target board for configuration, administration or logging are great examples where this is highly useful.
- Some companies develop most of the application logic using high-level modelling tools, for example, MathWorks MatLab or IBM Rhapsody. Such tools might generate algorithm-, software framework-, or logic code in generic C/C++ that can equally well be tested on the PC, perhaps in a "simulation" environment. When the generic algorithm and logic code is deemed to be correct, the same code is run on the actual target hardware (using different hardware abstraction layer libraries). For developers finding themselves in this use-case, it might be a lot more convenient to be able to build and debug both the PC and embedded versions of their code using the same tool.
With Atollic TrueSTUDIO, you can create both x86 host-PC projects and deeply embedded ARM Cortex projects. Furthermore, you can have two such projects open in the IDE workspace at the same time, and even launch parallel debug sessions.
Again consider the second bullet-point above; the one with the same communications protocol code running on both the PC side and the embedded side as both systems exchange messages with each other.
With Atollic TrueSTUDIO, you can launch a debug session for both the x86 host-PC application and the embedded ARM Cortex application at the same time. You can set breakpoints on both sides, and step the code on either side as the two systems exchange protocol messages forwards and backwards to move through the handshaking sequence.
The capabilities of a tool to debug the behavior of two systems simultaneously as they communicate with each other across PC/embedded boundaries is quite unique and a major time-saver in certain situations.
If you haven't explored the use of the x86 host-PC compiler and debugger in TrueSTUDIO yet, you might find this capability very interesting indeed!
Do you want to learn more on ARM Cortex development and debugging? Read this whitepaper: