Coffee Corner

Topics

• Python: HART, C#, C++, Multitasking, Unit Testing, Linux, MicroPython, Raspberry Pi
• Device Simulation
• Device Description Language
• The Malboro Computer
• HART-IP Slave and Master Stack
• FreeRTOS versus Linux
• Hart at a Glance
• Android and Linux
• Windows 11
• Using HartTools 7.6 in Python

There are currently two operating systems that are often used in embedded systems. These are FreeRTOS and Linux.

In the mid-eighties I developed a real-time system for the 8031. One of the main problems was that I wanted tasks that had high priority but only got the CPU at a certain percentage. Such a task was the operating task for the user interface. A maximum of 20% of computing time should be used for this, while the rest was available for measurement technology.

FreeRTOS enables such tasks and thus offers a real-time system with absolutely deterministic behavior. That's why I would definitely prefer FreeRTOS in an embedded system for process engineering software parts.

Although Linux is faster than Windows, it has fewer capabilities for implementing real-time structures. Constant temporal determinism is not always present in Linux and difficult to introduce.

For your information, you can find a document from the Internet in which the author comes to similar conclusions:
FreeRTOS or Linux?

A very compact view of the coding in the Hart Communication Protocol

I admit that I chose the title very loosely. But this short presentation has often been helpful to me when developing.
Hart at a Glance (Pdf)

However, my information is completely non-binding. The definitions of the Hart Specification are always decisive.

Improvements in Field Device Technology?

With regard to the design of field-mounted devices in process automation, there are currently essentially three alternative solution approaches that are being used by the device developers.

Android Apps for Field Devices

An application that is already common today is the connection of general mobile devices (phones and tablets) with the field devices via Bluetooth or NFC. Many manufacturers have already developed corresponding apps for this purpose.
The following is an example for this technology: SmartBlue App of Endress+Hauser.

The application (app) is usually not limited to Android alone, but is also available for iOS. I don't necessarily see it as a disadvantage that each manufacturer requires their own app for the devices. At least the tablet or phone is always the same.

The only parts that are required in the embedded area are a connection to Bluetooth or NFC.

One problem, however, is that someone who wants to program such an app has to understand at least as much about field device technology as they do about app development.

Embedded Android

The company ADC Group is offering an Android Device Kit.

Even though it is now possible to integrate embedded Android on a Raspberry Pi, when it comes to field devices you have to ask yourself what you want to do with them.

• Are sounds and vibrations needed in a field-mounted device? In most cases definitely not!
• The size of the display is also unlikely to change for field-mounted devices. The software for this flexibility is not necessary.
• Should apps of any kind be able to be installed on the embedded device? Such an approach would be undesirable in most cases.
• Android is based on a Java interpreter in order to be independent of the underlying platform. To do this, the developer must ask himself whether there is enough storage space available. If no browser functions are required on the embedded system, this effort on the embedded hardware would be unnecessary.

But an important point is the possibility of having something like a uniform user interface with Android. The following details come to mind.

• In an embedded field device, you can imagine that its functions are mapped by apps.
• Another important point is entering alphanumeric values using a software keyboard. This is always the same for all applications.
• The screen is divided into specific zones for all apps. It is helpful for the user of the device if this structure is always the same.

It seems entirely appropriate to integrate the above-mentioned functionalities into a uniform user interface. Whether it is necessary to place the original Android source code in an embedded device remains to be seen.

Embedded Linux

Off the top of my head, I couldn't say what's so advantageous about using Embedded Linux, even if this system is the basis for Android. One reason could be that it doesn't cost any licenses. However, there are also some stumbling blocks.

• Linux was developed over 30 years ago for PCs and is therefore probably a bit over-designed for most embedded systems.
• Since there are no requirements for real-time behavior in a PC environment, such things have never been incorporated into Linux. Linux has been optimized so that competing processes can access the same resources at the same time. This can lead to short-term blockages in the processes.

When real-time requirements of milliseconds or microseconds are involved in an embedded system, the developer is better off using a kernel specifically developed for embedded systems, such as FreeRTOS.

If you absolutely need an Android environment, you could also map it to a kernel other than Linux.

Windows 11 seems to be quite harmless and doesn't seem to be anything special. But I had to realize in the last few days that there can be quite a few problems.

First of all, however, it has been shown once again that a native DLL such as the HartDLL or the SlaveDLL in HartTools is unbeatable when it comes to portability. There were no problems with that at all.

The problems appeared with the use of the Com Controls HartX and SlaveX. It took me a few days to figure out what the problem was. Windows 11 is the first Windows with a pure 64-bit architecture. That would still be acceptable. But Office also comes with Windows 11 as 64-bit software. Apparently, in this case, all controls must also be 64-bit. Microsoft writes:
"Do NOT build your class library for AnyCPU. If you are using a 64-bit version of Office then build for x64. If 32-bit then build for x86. This will ensure that Visual Studio performs COM registration in the appropriate registry locations.".

Now we're in a fine mess. The old concept (any cpu) no longer works. The integration of such controls, of all things, depends on a very complex interface, the main components of which are entries in the registry. It will still take some more days of work to find a halfway reasonable integration of HartX and SlaveX that is acceptable to the users.
It goes without saying that this solution not only works with Windows 11 but also with older versions.

The whole thing wouldn't actually be a problem if there were only 64-bit Windows. Then you could follow that and everything would be fine, but then there are all the earlier versions. And you also have to take into account that only 20% of all computers are currently working with Windows 11.

HartTools 7.6 works with Python 3.8

The module demonstrates the use of the HartDll from HartTools 7.6. It is kept very simple and shows the basic procedure for loading and using the Windows dll BaHartDrv76 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.

Program Example 1 (pdf)