Introducing PLAIN

One of the challenges with a distributed system consisting of multiple Raspberry PI’s, multiple Hat’s and multiple RS-X connected devices is how to control it all. At the end we are running a complex, distributed system and coding logic on this level using a classic programming language like C/C++ is not straight forward. C/C++ is unbeatable dealing with low level electronics, performance and algorithms, but it is a bit clumsy to write higher level logic involving distributed logic. I would like to keep C/C++ to deal with low level things and HOW we do things, but I need something better to describe the logic and WHAT we want done. Having used years with various programming languages, PLC and CNC machinery I basically want to create something new that does things a bit differently.

I decided some time ago to name this PLAINProgramming Language for Automation Industry – basically a language/Logic concept to control robotics on distributed systems. We can evolve this a bit as we move forward, but I have a few key requirements:

  • Generic in nature.
  • Extendable and able to use C/C++ modules.
  • Deal with distributed, high level logic.
  • Support a future graphical CASE tool.
  • State-engine and event based Logic at core.
  • Easy to read top-down text, no cryptic syntax.
  • Easy to learn – read Logic in 5 min – yet powerfully to support Professionals.
  • Embeddable into other solutions.
  • Real-Time Centric.

The previous work on easyIPC fits straight into this work as is establish a plug & play communication network using multiple techniques. What I lack is an Ethernet based protocol, but I will return to this later.

At this point I am planning a language specification, compiler and Virtual Machine. The specification will need to evolve as we move forward on try & fail. Actually I want to start with the Virtual Machine.

7x Stepper Hat

rpi7xStepperThis is a very simple design to support 28BYJ-48 from a Hat. Using up to 4 x ULN2003 I get exactly 7×4 PWM signals. The only challenge is the connectors as I need to use 5 pin 2.54 pitch in this case since the steppers come with this attached (the 3D use the wrong package). I am only capable of mounting 3 of the 7 connectors on the edge.

8xDC Motor Hat – Connectors

8xDC_wSens1

One of the “challenges” with the Raspberry PI Hat size/format is that I always lack space for connectors. The 8 x DC Motor controller is an excellent example as I can manage 8 motor controllers, but adding connectors that support right angle is a challenge. It is not that the connectors don’t exist, it is size combined with cost.

Looking at the toy robot I am using I decided to add 2.54 pitch right angle connectors because this allows me space to add 8x sensor connectors as well. This results in a single board with 8 x DC Motors and 8 x End-Stop/Encoders. All accessible from the side offering straight or right angle connectors.

8xDC_wSens2

The pictures above show two different ways of mounting the Connectors – just experimenting for now.

8xDC Motor Hat

hat8xdc

An updated draft of 8xDC Motor Hat with TVS diodes and spike cutters. I am not happy with the connectors here. They are “ok”, but they are not easily to mount from within a stack and a bit expensive. I need to find alternatives. The 5.08 Power Connector is fine, it’s the 2.54 pitch motor connector in front I need to re-work.

A DC Motor driver like LM9110 that we use here is very popular and sufficient to drive a lot of small motors. In this case I need 5 to drive a toy robot arm so added 8. The input to the driver is 2x PWM signals driving a H-Bridge. The principle is simple as you switch on the PWM signal in the direction you want to drive. A bit more complicated is functions like speed, break and acceleration. The difference from the 32xServo is that we this time need to use PWM at a selected frequency with a duty cycle to indicate speed. With 8 motors this means we will be using 16 PWM signals.

Bit-banging will not work this time because we would need to iterate at 10,000Hz to achieve a frequency of 500Hz with 10% accuracy. I would like to adjust the frequency out for optimized motor drive and this is a perfect job for the Hardware Timers on the MCU. We will be using STM32F103RB or STM32F105RB that have a load of timers supporting 4 channels each. Each have a resolution of 16 – 32 bits, so we will not have any challenge with accuracy.

Finding 16 PWM signals works fine on F103 & F105 LQFP64 with Timer1,2,3 & 4 as they all have all 4 channels available on the same pins.

32 x Servo Hat – PWM Resolution

What “PWM” resolution will the 32xServo Hat Use? 

I have not given the question much concern, but I notice that someone advertise 12 bit resolution on similar products. I tested the same Circuit they use earlier and decided against using it because it’s I2C interface was to slow in making multiple servo position changes simultaneously. I simply could not move my robot the way I wanted, so lets look into the details.

The 32xServo Hat uses a M3 72Mhz ARM that only sit around to clock channels. So my resolution (position accuracy) is depending on how fast and reliable I can tick through a 32 entry table. 12 bit resolution means 4096 positions while we can estimate at least an iteration per 0,1 ms giving 10,000 positions. If we really need to we can probably add a zero to that.

The second question is more interesting – how fast can we change all 32 channels if it is part of a combined movement? And can we pre-store complex operations on the Hat?

This is the thing – we do have a powerfully MCU so we can program intelligence into the Hat to avoid that RPI needs to do low Level operations. Data transfer rates are fast so we can set 32 new positions within a single command using max 10ms from writing it on the PI until it is effect on the controller. This is crucial for more complex robots. The difference is not the speed of the SPI, but the fact that I can do it in a single command on 32 channels due to the design of easyIPC.

Returning to more complex operations – I think we should add a micro-script allowing the Hat to store pre-loaded operations – We actually got 20-32Kb SRAM we can put to some usage because it is more or less unused right now.

32xServo Hat Revision 1.1

32xservehat_1_1Not very exiting, but it has taken me most of the day. This is the revision 1.1 of the 32xServo Hat. Just for the record – the red lanes are actually ground plane so it will all be covered with GND – I just switched it off for the picture.

  • Added optional TVS diode on PSU for better protection.
  • Added 100uF and 100nF capacitor on PSU for spike cutting.
  • Adjusted pin header positions to better fit 3×4 headers.
  • Adjusted the lower 16 channels as they where a bit close to the bottom edge.
  • Added TVS on all 32 channels for protection of the MCU.
  • Changed all LED’s to 0603 package.
  • Added weak pull-up on nRESET.

32xservehat_1_13d

The lower 16 channels can use 3×4 right angle connectors allowing the Hat to be used in a stack. I finally found a good price on 3×4 right angle down to ca 10 cent each – still looking. You can still use classic 2.54 Pitch pin headers that is even cheaper.

Revision 1.0 is actually ok to go, so I will try putting this into production & sales since a lot of people have asked for it. It will be exiting to see what assembly prices I can achieve. PCB & Components are probably ca 10.- USD all together.

Embedded Query Engine

Permanent storage of configuration and run-time parameters is not straight forward with small, embedded solutions as the build in Flash only allow large pages and have a limited number of re-writes intended for program download only. Older MCU’s used a build in EEPROM for this purpose that have been removed from modern MCU’s, so we need to solve this ourselves. W25Q16 is a typical solution using a SO8 package to provide a 16Mbit SPI Flash that allow pages as small as 256 bytes to be written.

The SPI interface will in this case use 6 pins. I have been toying with the idea to create an embedded “disk” that use ca the same footprint as a SO8 as a connector, a 2 pin UART as interface with an offloaded query engine.

embeddedstorageblock

The block diagram above illustrates the idea. We use some kind of storage that can be Flash, FRAM, EEPROM, SD Card or maybe a USB  stick or even a proper hard-disk. Using an UART as interface we create a query engine capable of storing an retrieving data without the host using it’s time. PSU is basically 3.3V from the host with an added sensor to detect power loss and a super capacitor enabling a few seconds operation so we can Flush SRAM out to the storage.

UART is my preference in this case because it is straight forward and available on every MCU in my target range. USB is seldom accessible and even SPI ports are limited and often needed for other things. Using a crossed TTL Interface directly we have a full duplex communication on several Mbits directly.

I can use the SWD connector I designed earlier for this, but we probably should use a 2.54 pitch 4-wire connector and allow for a few cm of wire. If we add a M2 mounting drill hole we can locate the “disk” on a convenient place.

Using a separate MCU to off-load data storage and retrieval basically work the same way as sending SQL to a server. With a bit of clever query algorithm we should be talking about a read/write time < 1mS almost independent of query complexity or data amount (within reason).

ed16m

 The 3D model above is an early draft of the Embedded Query Engine to get an idea about actual size.. This is based on the STM32F030 and the supecap we used on the motor controller. I copied some diodes as well just to get an idea. This is single side assembly and I prefer to keep this simple. I can probably find smaller supercap and diodes for a start – but as always – work in progress – for now it is just an idea that is funny to play around with. Notice that most of the space is related to the supercap.

Visual Studio on Raspberry PI & STM32

visualstudioraspberrypi

This is a dumb blink demo with a console output just to show that it actually works. I have used Visual C++ and later Visual Studio since 1995 so I am not surprised that things work smoothly. A few buttons on my PC to install this, a sudo command on raspberry pi and it just Works. The demo runs on my Raspberry PI 3, but the printf is re-routed to a terminal window in Visual Studio. I actually have a display and keyboard/mouse on the PI as well, but don’t really need one for non-display Applications. Single step debugging etc Works fine – almost as if you develope a Windows app.

I had to use VisualGDB for STM32, but the same experience. This makes my work on software so much easier because I can use Visual Studio for everything. VisualGDB is a commercial solution, but at 79.- USD I will consider a license – though I will considering hacking a free solution because it is actually straight forward.

MC4X15A – Heatsink

mc4x15a-heatsink

Funny how things work out some times. I initially planned for this to be a more narrow board, but had to extend the height to 40mm due to MCU and connectors. This left space unused on top and bottom of the driver making it easy to add mounting holes for an adapter and now a extra set for a 40 x 28mm heat-sink on the back. The red diodes in the middle is taller than the HEXFET’s, so one option might be to mount a space filler and use a larger heatsink with the same size as the PCB.

I want to add a SPI Flash and evaluate options to add a Ethernet before I actually order these boards. As for BEMF I want to add some 100nF Ceramic capacitors to help on spiking, but other than that we should be good.

I also realize that the two resistors mounted on left bottom need to be moved a bit up in case I want to mount the temperature connector bended inwards. At least one of them must go to the HEXFET’s. I have added two temperature sensors to have some flexibility in case I am running two DC motors or want a temp sensor on the motor as well.