Hart Software and Embedded Systems Development
Hart Software and Embedded Systems Development

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

A cup of coffee Cup of Coffee

Embedded Software and Firmware Design, Technology and Development Efficiency are subject areas that have to be constantly adapted to the current state of the art. This also includes, but not exclusively ideas for Fieldbus(HART), WLAN and Bluetooth to be integrated in embedded systems and testing respectivly verification tools.

That sounds pretty complicated doesn't it? It is! So grab a cup of coffee before you take a closer look at this page. If you have any questions, please email me and I will respond as soon as possible:

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.

Always the same Nonsense ..

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.

Software Abstraction

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:

The code of the main program of the application The Code of the Main Program of the Application

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.

The display of the application in the Windows Terminal The Display of the Application in the Windows Terminal

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.

Technical Article

Device Description Language

The 'Elektronik' journal presented first an article about DDL The 'Elektronik' Journal presented first an Article about DDL

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.

Device Description Language
Today I found an article about device descriptions on one of my accounts, which I translated into English. It describes the emergence of the DDL.
PDF-Dokument [259.6 KB]

Embedded Firmware

Real Time Serial Communication

Display of the result of testing Display of the result of testing
Real time issues in serial communications Real Time Issues in serial Communications

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

Display of an embedded device simulation Display of an Embedded Device Simulation

From the beginning of the development of the firmware/software of embedded devices, PC simulations of the device software have proven to be extremely helpful in reducing the development time.
However, the right interfaces and the concept are very important, because the realization of a simulation should be simple and easy to understand. That's why you shouldn't need any complex additional tools. The more the simulation is based on the original source code of the device and the corresponding interfaces, the higher its quality.

The firmware for the device should be as reusable as possible and easy to transfer to different platforms.

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.



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.

Code of the python example Code of the Python Example

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.

PDF-Dokument [47.3 KB]
Druckversion | Sitemap
Copyright © 1998-2023 Walter Borst. All Rights Reserved.