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.
It’s some years ago I wrote my first XML parser. The story was that I was doing a communication interface and discovered that the interface sent XML messages. In two days I wrapped up a small XML parser as a library and got the task done.The technique I used was a classic recursive descent parser.
The parser I will introduce here uses a very different technique that is much, much faster and smaller. This is a state engine parser. I was a bit bored a few years back and decided to test out the idea of a parser technique where you consider xml as a state engine with characters as events. Using a lookup table to categorize characters the technique ended up in a very fast parser in less than 300 lines of C++ code. This is closer to a SAX parser than a DOM parser and will parse a file or a communication stream byte for byte. The combination of low footprint and close to no RAM usage enable the parser for small MCU’s like Arduino.
The interface is callback functions with parser content. The parser will parse XML with a speed comparable to strlen(), but you need to parse the content. To help you get OnBeginGroup, OnParameter, OnEndGroup etc. We will be using this parser a lot due to the usability of XML.
Alf & Vegard’s RISC processor was created while they where students at NTH in Trondheim, Norway back in 1996. It has since become one of the most popular MCU’s worldwide. It’s foremost competition was Microchip’s PIC series, so it’s ironic that it’s now Microchip that own Atmel (and AVR). Even more ironic that while Atmel ruled we received rumours from the team that Atmel was in the process of ditching their 8 bits. Now we see new 8 bit AVR’s hitting the marked again.
Happy 20 year anniversary!
Modern CAN uses two formats referred to as CAN 2.0A and CAN 2.0B. These again can use at least two wired solutions. The one we discuss here is the high speed version using twisted pairs. Two newer relatives to CAN that require either a logic circuit or MCU with special port support are CAN FD and FlexRay.
CAN eXtended uses CAN 2.0B that often is called “extended frame”. CAN 2.0A uses a 11 bit arbitration field as ID, while CAN B add’s another 18 bits to this. CAN eXtended uses these 29 bits as follows:
- – 2 bit priority
- – 1 bit message direction
- – 8 bit device id
- – 10 bit stream id
- – 7 bit sequence number
- – 1 bit message continue indicator
As CAN only can carry 8 bytes on a single message we need to use several CAN messages for some of the larger easyIPC messages. To do so we take advantage of the 1 bit continue indicator. If cont = 0 we know this is a new message with a Message ID in the first byte of the payload. If we need to use several CAN messages as an envelope we add a envelope header and an envelope tail:
PID is 16 bit parameter ID. PID=0 is Envelope head, PID=1 is Envelope Tail. Envelope Head contain a 8 bit parameter indicating number of messages that at minimum is 2 and maximum 255. The first message will have cont flag =0, the rest will have cont flag =1 to indicate that this is not a message head.
Envelope Tail contain a 16 bit Envelope CRC which is the CRC for the total message payload.
Wow – I actually managed to order a Raspberry Pi Zero for 3.33 GBP. I have wanted one for months for testing, but declined to pay 50.- GBP or more on ebay. This was through one of the official distributors.
||Raspberry Pi Zero – Max 1 Pi Zero Per Customer!Pi Zero only
I purchased a Prusa i3 DIY kit from Hong Kong some time back. I assembled it and got it working, but have not used the printer much.
The first issue I had with it was that the board shorted and burned some lanes. I managed to fix that and even bought a spare control system (I actually have two spare systems). After that I discovered that I had an issue with the FTDI chip. The Scotish company making FTDI wanted to slam down on fake chips so they updated their drivers to actually damage fake chips.
I don’t like the fake chip industry, but neither do I believe that I as a customer should be responsible. I notice that CH340 chips have gained a lot of marked with makers after these incidents. The only way to know that I have a real chip is by ordering an expensive replacement from FTDI that will cost me the same as a new control system.
I use an Arduino Mega based control system with custom layout. It is quite nice and the firmware for it can be generated from on-line pages and downloaded. The PC front-end use a classic slicer and some custom G-code to operate the printer.
Running the printer I noticed that it sometimes switch on the nozzle fan and “forget” to switch it off. The effect is that the feeder stop feeding as temperature drop below 150 degrees and half my print ends up being a dry run. I have so far not found the configuration to control this better, so I am considering disconnecting the nozzle fan.
I have looked into the open source firmware code, but I am a bit reluctant to start making changes due to the state of the code. It reminds me a bit of a rat-nest to be honest. The challenge with those is that it requires a bit of time to get into and understand the code. I have actually considered re-writing the firmware, but again time. I have enough projects as it is – for now.
The main challenge is however to find a proper, free CAD program that is easy to learn and will allow me to create components that can be printed. One of my experiences is that you need to design the component for printing and you need to add the support mechanism manually. I have a few 3D parts around with support plastic so tightly integrated into the components that I can’t separate them, so I am not using the auto-generated crap anymore.
I need to find a solution to all this since I want to print legs for my spider on this 3D printer.
BasicPI Hat’s uses SPI in a full network with up to 8 Hat’s per Raspberry PI. Communication with a STM32 will clock at ca 15Mhz (Set on Raspberry PI). The protocol uses GPIO pin’s as chip select for critical messages, but will otherwise rely on each device to filter out it’s own messages on MOSI. This allows Raspberry PI to send on MOSI independent of what device that is sending on MISO.
This is possible since all information about sender and receiver is in the message header in the form of a hat/stream-id and MOSI can be filtered in software. The SPI Message format is illustrated below:
Chip Select on MISO is always done between two messages from a Hat. Raspberry PI will either detect a pad character meaning the Hat has nothing to send or wait for a message to complete if the device uses it’s time slot. Each active Hat have a 1ms time slot before Raspberry PI switch to another Hat. The device with Chip Select active will send a status message and either continue with messages in the queue or send pad’s if no messages is waiting.
The way this should work is that messages on MOSI are sent in the same sequence as they are inserted into the queue. Messages on MISO will be received as soon as the Hat receive chip select. ME will load balance chip select so that Hat’s with large MISO queues receive more sending time than Hat’s with empty queues.
HAL (Hardware Abstraction layer) is an interface between “normal” user modules and actual hardware. It makes hardware access easy and portable, it also gives us a layer where we can write optimized, hardware specific code if we need to. We will add more HAL classes as we go.
ETC (Elapsed Time Clock) count the time in ms and ys since the MPU was started. This is used for time differences by the RTOS itself and available all through code using the ETC::millis() or ETC::micros() functions.
GPIO is a class that provide access to a collection of pins. GPIO collections are declared in global space by the user and support logical pin grouping. This means that user modules can toggle pins with a given name even if their location is different from hardware to hardware. This allows the user to “wire” a board during initialization to preserve portability on modules that need pin Access.
More details on HAL classes can be found on Documentation->HAL in the menue as they are added.
The picture show a classic MPU9255 breakout board found on ebay for < 5.- GBP. MPU9255 provide both I2C and SPI interface and a total of 9 sensors (3 axis Gyro, Magnetometer and Accelerometer). In our case we will use the SPI ports Connected to STM32.
I am not sure if I should add a generic Sensor Hat or a specialised Spider Robot Hat (maybe both?).
The block diagram above outline the control system for the Spider Robot. The prototype was a mock up to test the basics of the concept and to proceed I want to make some changes:
- We need a proper CPU and I see no reason not to add in a Raspberry PI to execute AI logic. The servos and sensors are easily controlled by one of our BasicPI Hat’s, which leave us to design a PSU. I like the current 11.1V LIPO at 1.5AH. It should give several hours of operation.
- We need to add sensors. A few ultrasonic transceivers will enable us to check distance to surrounding objects, a MPU9255 adds Magnetometer, Accelerometer and Gyroscope, a couple of microphones adds hearing etc. Raspberry PI have digital camera option with possibilities for optical detection options. The rest is easily added to the IO processor.
- We need to work on the mechanics around the legs. I need a stronger servo on the inner arm and a better wiring solution to the legs. The problems detected was partly the servo breaking after continuous usage, plastic parts not taking the beating and wires worn out.
My first plan was to use a Raspberry PI Zero, but using a Raspberry PI 3 makes a lot more sense in this case. This adds the Wifi option directly.