Coffee Corner
To make embedded firmware code reusable and platform independent is the most efficient way to reduce firmware development costs and time. In order to accomplish this, a whole series of aspects must be taken into account. Software abstraction is only one of them.
Both Visual Studio 2019 and Visual Studio Code are very popular as a development environment. The questions that arise are the following.
1. Is it possible to develop platform independently with this?
2. Can I use the same source code?
3. How suitable are they for embedded systems?
4. Can you use them quasi co-existent?
In the following you will find a Windows demo program, the build of which is created once with Visual Studio 2019 and with Visual Studio Code and with which question 4 is practically answered.
A detailed description can be found in the data sheet.
If you want to take a closer look at the example, you can also download the source code for free.
The Key of Reuseable Code
Each of you knows what software abstraction means from your cell phone. Most mobile phones work with Android, whereby the actual operating system is Linux. Android only has the task of hiding the complexity of the Linux subsystem from users. That is called Abstraction.
Abstraction sounds very scientific, of course, but it's actually quite simple. It means that you structure the software you want at the highest level in such a way that it realizes the task without making it clear how it actually does it. What is meant is that it is not necessary to know which operating system is being used and which other auxiliary programs are required.
The following code is an example of this:
As you can see, the code is so simple that it needs no further commenting. The depth of the nesting could also be described as clearly arranged.
The software runs a console application that communicates with a HART device. I have to know that it is a HART device, since not only communication features are defined in HART, but also application features.
Abstraction is about breaking down the application into smaller and smaller packages, each of which is easy to implement and understand. Access to the operating system or the hardware is only made at a level that is as far below as possible.
Basically, this is the subprogram technique that we have known since the beginning of programming technique. Only two focal points are added:
Abstraction of an Embedded HART Protocol Application
The example shows a way to make the embedded code reusable and platform independent. HART is used for the communication and the Windows terminal as display.
The following shows how the code from the example application is further realized.
The outputs and inputs are made via a console. Behind this is access to the Windows terminal. The applied methods are defined in the CVConsole class.
For example, the function Init looks like this.
The realization here still looks relatively abstract for the most part, but it already accesses certain functions of the console API. A look at the ClearSteadyDisplay() function shows how further refinements are being made.
This function 'paints' the background and the border of the white display area and is not quite as trivial as the two higher levels. But the function is self-contained and therefore easier to understand.
The integration of the HART protocol communication software is designed similarly to the integration of the console. The basis here is the HartTools DLL together with the header file BaHartDrv76.h. The class with the access functions is declared as follows.
The functions of this class then access the interface of the DLL.
I think it would go beyond the scope to go into more detail here. This example will be available in HartTools 7.6 (Developer) in the summer (this Year, by the way). Then you are welcome to inspect and test it in detail.
Incidentally, the HartTools themselves proved to be very useful in the development of this example. In addition to a real device, I used the slave integrated into the FrameAlyst to run tests.