Embedded Software Engineering, Development and Test, C++, C#, Python

The following topics can currently be found on this page:

• Always the same Nonsense,
• Software Abstraction,
• Device Description Language,
• Real Time Serial Communication,
• Embedded Devices Simulation and
• HartTools 7.5 works with Python.

So that someone might like it, I myself have integrated one or the other useless thing into the software of the HartTools. Now I take the nonsense out again consistently.

Source Code Comments

• Not every comment in the source code of a software is automatically documentation.
• If you can hardly read the actual source code because of all the comments, that is anything but useful.
• Xml syntax elements make comments readable only in specific systems. In pure source code, they do the opposite. So I leave it out entirely.
• From source code you can only generate what is in it. Therefore, only something can be generated from it that looks like documentation, but in reality contains no additional information.
• When using a standard control, it makes no sense to document the methods and properties in the source code if the control itself is already documented.

Run Time Checks in Embedded Systems

Checks at runtime make no sense in embedded systems, since there are other ways to ensure that there are no internal problems (e.g. dividing by 0).

Run time checks are only recommended when it comes to processing user input.

The key to reusable code

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:

1. The reusability of the program code and
2. Independence from a platform such as Windows, Linux or any embedded system.

If you want to know more about how we did it, please click on the following link:
Example of Software Abstraction.

Device Description Language

When I published an article about the device description language in Elektronik, issue 18, of September 3, 1991, some colleagues from the technical world had a great time with a look at the ISO-OSI model. Nobody laughs at device descriptions anymore.
I would never have dreamed at the time that this new technology would one day become an international standard.
In the meantime, the device description is state of the art, which was also worth an entry in Wikipedia.
The Device Description Language is integrated in several fieldbuses and the well known HART Protocol. It is also often abbreviated as EDDL (Electronic Device Description Language).
Below is a draft of an article from 2003. I publish this page to show how simple and obvious technical solutions can often be.

Real Time Serial Communication

Embedded systems usually require a demanding real-time environment for digital communication and measurement tasks. But how can you simulate such an embedded system on Windows?

It is often said that Windows is not real-time capable. But that is not necessarily the truth. First, computers are becoming faster and faster, and second, computer games place demands on the real-time capability of computers right from the start. So you just have to know how to do it.

For HartTools 7.4 and 7.5 there have been practically no complaints in recent years that would have made a change necessary. The stability of Hart communication in particular has been very high over the past 10 years.

One of the building blocks that led to this is the control of the com port in the Windows system. Since Hart communication involves a transmission rate of 1200 bit/s, real-time capability is easy to establish, because the required reaction times are in a range of a view milliseconds.
From this code in HartTools we have derived a product with which we supply the source code for such a solution. The product name is Real Time Serial SCM. You can view the data sheet for this via the following link:
Datasheet Real Time Serial SCM.

Embedded Devices Simulation, Part 1

We are currently working on a framework for such a solution and I have summarized some details for a draft in a short working document: Embedded Device Simulation, Part 1

If you have any questions or comments on one off these topics, please send us an e-mail. We will answer you as soon as possible.

Walter.Borst@borst-automation.de

HartTools 7.5 works with Python 3.7.9

The module demonstrates the use of the HartDll from HartTools 7.5. It is kept very simple and shows the basic procedure for loading and using the Windows dll HartDrv75 in Python 3.7.9.
The example is loading the dll, registering the license and establishing a connection with a hart slave.

We have provided the complete source code in a pdf file which you can download by clicking the following link. Please let us know, if you are having any questions.