BasicPI

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.

1

Raspberry Pi Zero – Max 1 Pi Zero Per Customer!Pi Zero only

1

£3.33

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?).