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:
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.
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.
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:
If you want to know more about how we did it, please click on the following link:
Example of Software Abstraction.
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
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
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.
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.