Category Archives: HMI

SDL

SDL (Simple DirectMedia Layer) is a 3D graphics engine that uses OpenGL or DirectX depending on platform. To use it is straight forward. You will do a few rectangles on screen with little work.

I am also working with GDI+ on Windows, so I was stunned as to how slow SDL is to start in comparison. I was even more stunned as I was looking for functions to draw circles, arcs and the finer graphics. They simply don’t exist. All I find is a function to do rectangles, point collections, pictures etc.

In simple words you will have to create a proper 2D library on top of this from scratch if you want to use this as a HMI framework. I have actually done similar tasks back in the DOS days so I know that this is a large task to take on.

Don’t take me wrong! Drawing a rude circle is done in a few lines of code. Drawing a high quality graphics one require a bit more work, but doing this with high performance will require a lot of hours.

It will not be my first option!

10 Mhz Logic Analyzer

One of my interests  for some time have been how to create a MSO (Mixed Signal Oscilloscope). I have several scopes, but I lack a Logic Analyzer on any of them.

My first thought was to bit-bang the GPIO of Raspberry PI directly, but as I looked into this I realized that I would not get much speed out of it. The issue is that Linux can’t really sit around bit-banging as it got other tasks as well. To actually do this you would be better of without the OS running.

They have created a 14 channel, 100Mhz Logic Analyzer on Beaglebone Black, but that makes heavy usage of the 2 embedded PRU’s. It would make sense if we could use one core to bit-bang, but I am not sure how to do that without replacing Linux itself.

One channel is typically 2kb of display data for a frame on a 1920×1024 screen. To be ideal we need a minimum of 25 frames per second (fps) and preferable 50 fps. That is ca 50-100Kb per second eight channels. Or more exactly 200Kb/s for 16 channels which again is ca 1.6Mbps and well within what we can expect from the SPI if we use a Hat.

A STM32 F4 can sample rather fast. Clocking at 180Mhz it should be able to do intelligent sampling of 16 channels up to 10M samples per second if the write the code correctly. This will obviously include some logic to trigger a sample run and upload it. As uploading is done by SPI from a DMA it don’t lake MCU time and we just need to fill a buffer and send it. This Application will need to be tight.

10Mhz will be good, but the hard fact is that most of my needs are covered with 1Mhz. The additional win here is that we get to program the analyzer logic so we can add recognition of things like CAN, SPI, I2C, UART etc.  I am considering two MCU’s for this job:

STM32F405 ticks at 180Mhz and is a M4. Cypress 5LP is a ARM M3 ticking at 80Mhz, but it contains programmable logic that might significantly increase the sampling frequency if used correctly.

User HMI Applications

HMI API

The drawing above illustrate the different components used to achieve a complete application with HMI. We have briefly discussed the internals of the Hat (left) consisting of hardware interfaces or communication drivers, a IO configuration and the SPI driver communicating with Raspberry PI.

RPI have the master SPI driver and two new components that are part of it’s easyIPC server. One is a Data Repository. Basically a database over available features and data associated with it. This database will be in memory.

API Server allows easyIPC to be connected to multiple clients either on the same Raspberry PI or from a different computer. This connect your HMI application to easyIPC as if it was a database of information.

HMI framework is basically the GUI used to visualize real-time data and add user Interfaces.

This is a very brief drawing sop we will consolidate it as we finish it.

HMI Solution

Dealing with embedded solutions you also need to deal with HMI. A majority of HMI will always be on displays so having the Raspberry PI as base is quite nice. It is very capable of supporting our GUI needs, but how do we program it?

A friend of mine uses Python with various libraries. I will do a Python demo, but I have something else in mind. I wrote an entry about the Nextion HMI solutions from www.iteadstudio.com earlier. They use a STM32 and a TFD combined with a designer. You create a HMI with objects that later can be communicated with using a serial port. I bought one of them for testing and I am quite impressed over the concept thought I will add that their solution have a few fallbacks.

I will always argue that source code must exist in human editable form. A HMI graphical design is no exception as it is source code with scripting logic embedded. I would have used XML for this purpose. The concept is not new as it has been used in various embedded solutions for years. The most common is PABX telephones with displays.

The issue with HMI is that using more advanced solutions like Qt or similar actually require a bit of knowledge. Most embedded developers or makers focus their knowledge differently and writing an advanced GUI application is often outside their comfort zone. They are simply not willing to spend the time required to master things like Qt. But, even if you master these skills you will find that solutions like Nextion take away a lot of hours if you can accepts the limitations.

I would like to put the GPU’s on Raspberry PI to some usage, but having looked into OpenGL I must admit that this is not an easy task. Using Qt makes it easier, but using Qt itself on Raspberry PI is a bit of an issue even if you forget the skillset issue most will have. Just for the record it actually exist other solutions than Qt as well.

What I would like to do is to create an advanced HMI solution for Raspberry PI using the concepts described above. You simply outline your HMI in XML that is loaded into an application that communicate with easyIPC. The Application + Your XML becomes Your HMI. Embedding this into a stand-alone executable is doable. The graphical designer part is the easy one in my case since I have made numerous flow-chart alike tools in the past. My only remaining puzle is to select a graphical library for C/C++ on Debian to build this in.