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.
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
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.
I have drafted a few Hat’s so I am adding an overview just to move content into the new blog.
Zero GPIO was my first Hat. This is the new, revised version that I have not ordered yet. I am waiting to verify SPI interface before I order new Hat’s. For the Zero I actually also need to get a Zero as I don’t have one yet. Out of Stock they still are after 6 months.
I also added a full size version of the GPIO Hat with a proto-typing area.
Another Hat in both Zero and full size version is the Servo Hat’s with 16 and 32 servo connectors. The Zero version uses the STM32F103CB which is 48 pins. The 16 x version will soon be used in a Robot project with 12 servo’s.
The Hat I am doing software on is the 5 port communication Hat. I need to verify SPI interface with RPI on this. I am using a Raspberry PI 2 for now. Progress on this work can be read through other posts.
The Zero Com Hat (above) has not been mentioned before. This 3D model is illustrative, but it show a Zero Hat with a RS485, a CAN and a 2.4Ghz NRF24L01+ port. One version of this also uses normal Wifi. The drawback with this hat is the mounting of the NRF24L01+ breakout board. I need to find a way to mount it properly as it will not handle vibration well if mounted as illustrated on this model. This model also still uses the 2.0 pitch connectors that I decided to remove so it is “work in progress”.