Category Archives: Raspberry PI Hat’s

ESP32/STM32/Raspberry PI – all in one dev kit

Starting at left is a ESP32 Breakout board, then one of my own STM32F405RG breakout boards, a 5″ HDMI, Wireless keyboard and Raspberry PI 3 with my 5 port Hat – and your right it’s a different Hat with screw terminals, so I do have 2 x 5 port Hat’s working.

 What I will do here is to wire up SPI between ESP32 & STM32 for testing, and I can add CAN breakout boards etc getting the boards to communicate. The only drawback here is that I can only use one SWD at the time, but I will get around that.

Raspberry PI Wiring

This shows a Raspberry PI 3 with a Communication Hat, Display and mini keyboard. This is basically all the hardware I need for a very advanced CAN Adapter & Analyzer. The main reasons I am skeptical is the wiring needed on this solution. Using a HDMI display is very powerfully, but you need a large project box for this. The total size and cost of the adapter adds up. I seriously which someone would create a more box-able display solution for Raspberry PI – one that take into account the Hat option.

Raspberry PI – 3 x RS485 & 2 x CAN Hat

This is a 5 port communication Hat mounted on a Raspberry PI 3. It contains 3 x RS485 and 2 x CAN ports. The design is not new for readers of this blog, but it is actually the first time I assemble rev 1.1 – just before I am about to order rev 1.2.

The colorfully display is because I am using 1206 led’s and saving old parts – all components on this was re-used from rev 1.0 boards. What amused me a bit is that as I mounted the MCU and switched Power on the old test program still worked. I have yet not broken a STM32 by soldering it on/off boards – quite impressive actually.

Functionally this Hat is ok, but mechanically I ordered a few Hat’s before I checked the drilling holes exactly, so rev 1.2 will correct this. I will also replace 0804 and 1206 with 0603 components + 2 leds per port is a bit overkill. I think if I reduce to 1 per port and mount them on the side that is better. Also cleaning up the line driver and replacing the 3P connector with a 4P for RS-X 12V + differential signal. I might have to make this a 2+2 port for that purpose.

 I also want to do an experiment. Both CAN and RS485 are differential signaling, so I wonder if I can get RS485 to work with a CAN Tranceiver and what quality it would have? The issue is that if I can do this I can more or less make the 2 CAN ports switchable between CAN & RS485. It is worth a try!

Why not Raspberry PI as CAN Adapter?

This is the rev 1.2 of my 5 port Hat with 3 x RS485 and 2 x CAN. I never ordered this PCB because it is only mechanical changes from Rev 1.1. But, using this or a galvanic version with Raspberry PI is an option for my CAN Adaptor plans.

The advantages with this is that Raspberry PI have an excellent HMI option. It would also enable a PLC style adapter where you add on what you need – but it would be a much larger solution as well.

The size difference from a packed, single board solution is not dramatic and it offer other options as you get a proper display, keyboard and a full Linix computer to back it up.

ESP32 PI – Raspberry PI Replacement

I have a few Raspberry PI Hat’s laying around and I wonder if I should make a ESP32 based replacement for Raspberry PI Zero W. The IO on ESP32 is far more capable than the one on the PI, but we have a few limitations and less pins to play with.This is an early draft with the 3D above and PIN mapping below.

Raspberry PI Pin ESP32 PI Description
1 3.3V
2 5V
3 8 – GPIO32 GPIO2 / I2C-SDA
4 5V
5 9 – GPIO33 GPIO3 / I2C-SCL
6 GND
7 10 – GPIO25 GPIO4
8 11 – GPIO26 GPIO14 / UART-TXD
9 GND
10 12 GPIO27 GPIO15 / UART-RXD
11 13 GPIO14 GPIO17
12 14 GPIO12 GPIO18
13 16- GPIO13 GPIO27
14 GND
15 GPIO9 GPIO22
16 GPIO10 GPIO23
17 3.3V
18 GPIO11 GPIO24
19 27 GPIO15 GPIO10 / MOSI
20 GND
21 28 GPIO2 GPIO9 / MISO
22 7 GPIO35 GPIO25
23 30 GPIO4 GPIO11 / CLK
24 31 GPIO16 GPIO8 / CE0
25 GND
26 33 GPIO17 GPIO7 / CE1
27 ID_SD I2C ID EEPROM
28 ID_SC I2C ID EEPROM
29 GPIO5 GPIO5
30 GND
31 GPIO18 GPIO6
32 GPIO19 GPIO12
33 GPIO21 GPIO13
34 GND
35 GPIO22 GPIO19
36 GPIO26 GPIO16
37 GPIO6 GPIO26
38 GPIO7 GPIO20
39 GND
40 GPIO8 GPIO21

 

Smart SPI Test Kit

This is the test suit for Smart SPI. This is an old pic, but I will upload a newer one showing RPI mounted behind the 32xServo and how we access SWD & Raspberry PI for development.

The mechanics of thos robot is dodgy, but it is a very good and fun test kit. I also have a different robot that we can have some fun with during testing using the 8x DC Motor hat.

Keep in mind that Raspberry PI Zero W provide both Bluetooth and Wifi – I only need battery added making this a very easy and scalable design.

Adding more Hat’sm we can scale up and we basically have a PLC style design with Raspberry PI as core. I have a few more Hat designs coming up, but once I have tested this I will try putting this into volum production through kickstarter.

I have no idea about prices yet, but I hope we can achieve ca 25.- USD or lower. This is no-profit, but the key is that I need volumes to push prices down. I also need to engange professionals for CE/FCC tests. I am not so worried about the later, as Wifi/Bluetooth is dealth with by 3rd party, and this is only a component – but, we need to test that we don’t have nasty signals by accident.

Smart SPI Driver

I need a specialized SPI driver to support the Smart SPI concept. The block diagram above show the logical view with device to device communication, while the diagram below show the physical design. Just to remind everyone – in the logical concept we communicate device to device. In the physical this is done by a device sending a message to RPI that send it to the addressed device.

A classic SPI will enable a CS, communicate with that device before it continue to the next device. As discussed before this is not optional as it do not take into account the actual stream queues, so we will implement several important tweaks to optimizeSPI communication efficiency.

We will only use the CS for ID procedures at start-up. I am currently looking into even drop this. Each device here is intelligent and capable of filtering out it’s own messages. They also have 3-state capability allowing them to listen only while only one respond back. This enables a free flow where RPI have a continuous send with a soft-switch selecting the device that communicate back.

This requires specialized SPI drivers both for Raspberry PI and STM32. The advantage for Raspberry PI is that we allow Linux to use deep DMA queues and avoid CPU heavy bit-banging. The only dissadvantage is a complex SPI driver.

My current Hat’s support CS addressing using a classic address selection. I am considering ditching that and set the MCU address directly with 3-4 GPIO pins. The drawback is that I need to modify all Hat’s, but that is doable since none are in production yet – and I am commiting to using a number of pin’s for address setting. The usage will be the same as before, but we drop the SPI ID procedure because it is not needed anymore. At precent I will focus on a single Hat, so I can pick up this as I make the next revision of the Hat’s. It also gives me time to mature this change a bit.

32 x Servo / IO Capability Map

This table is a all 32 channels on the 32 x Servo / IO Hat mapped out per channel. Explenation under the table.

Ch1 PC1 Analogue In
Digital In
Digital out
Servo
Software PWM
Ch2 PC2 Analogue In
Digital In
Digital Out
Servo
Software PWM
Ch3 PC3 Analogue In
Digital In
Digital Out
Servo
Software PWM
Ch4 PA0 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch5 PA1 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch6 PA2 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch7 PA3 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch8 PA4 Analogue In
Analogue Out
Digital In
Digital Out
Servo
Software PWM
Ch9 PA5 Analogue In
Analogue Out
Digital In
Digital Out
Servo
Software PWM
Ch10 PA6 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch11 PA7 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch12 PC4 Analogue In
Digital In
Digital Out
Servo
Software PWM
Ch13 PC5 Analogue In
Digital In
Digital Out
Servo
Software PWM
Ch14 PB0 Analogue In
PWM
Digital In
Digital out
Servo
Software PWM
Ch15 PB1 Analogue In
PWM
Digital In
Digital Out
Servo
Software PWM
Ch16 PB2 Digital In
Digital Out
Servo
Software PWM
Ch17 PB10 PWM
Digital In
Digital Out
Servo
Software PWM
Ch18 PB11 PWM
Digital In
Digital Out
Servo
Software PWM
Ch19 PC6 PWM
Digital In
Digital Out
Servo
Software PWM
Ch20 PC7 PWM
Digital In
Digital Out
Servo
Software PWM
Ch21 PC8 PWM
Digital In
Digital Out
Servo
Software PWM
Ch22 PC9 PWM
Digital In
Digital Out
Servo
Software PWM
Ch23 PA8 PWM
Digital In
Digital Out
Servo
Software PWM
Ch24 PA9 PWM
Digital In
Digital Out
Servo
Software PWM
Ch25 PA10 PWM
Digital In
Digital Out
Servo
Software PWM
Ch26 PA11 PWM
Digital In
Digital Out
Servo
Software PWM
Ch27 PA12 Digital In
Digital Out
Servo
Software PWM
Ch28 PB3 PWM
Digital In
Digital Out
Servo
Software PWM
Ch29 PB4 PWM
Digital In
Digital Out
Servo
Software PWM
Ch30 PB5 PWM
Digital In
Digital Out
Servo
Software PWM
Ch31 PB6 PWM
Digital In
Digital Out
Servo
Software PWM
Ch32 PB7 PWM
Digital In
Digital out
Servo
Software PWM

Analogue In means it has an ADC capability on the channel. This can sample at a very high frequency. It is 15 of these

PWM means we have a Hardware PWM signal with a very high frequency capability. It is 23 of these.

Analogue out means it connect to a DAC. It is 2 of these,

Digital In & Digital Out is on all 32 channels.

Servo is available on all 32 channels and is the default configuration.

Software PWM means we bit-bang the pin in software to create a PWM signal. Max frequency is ca 10KHz. Available on all 32 channels.

An updated version of this table can be found in Annotated Schematics (coming soon). Pin’s have all cababilities as per STM32F105RB capabilities, but more advanced features will need custom modified firmware to access.

Wireless 32xServo (IO) Controller

I maintain Zero mounting holes on all my Hat’s because it’s an easy & cheap way to assemble a wireless control system using the capabilities in Zero W. The picture above show Zero W on top of a 32xServo Hat. I have only populated 16 of them, but all 32 are available since the Hat fit’s nicely on the inside. The pic below show a Zero booting up with a 5″ TFT display. I tried booting the Zero W, but realized I need to update my image.

You can see the red dot from the 32xServo Hat mirroring in the display. The only practical issue here is that SWD is hard to get to – which isn’t a real issue as I just as easy can move the Zero to bottom of the stack for development – but, I did draft special SWD adapters for this purpose earlier that allow me access from the side (See 3D below).

This can be clicked on/off from the side while the Hat’s are inside a stack. The use of 1.27 pich headers is just about the right hight for this. The one thing this SWD adapter lack is a Boot and Reset button. I seldom need those, but I prefer to have them on the adapter – not waste space on the boards.

The 32xServo or 32xIO have the advantage that the signals are connected directly to the MCU. The new version (not shown here) have TVS diodes on each signal, but you can otherwise use the signals as per MCU capability for in/out. This makes this a very ideal wireless controller because you have 32 very capable channels + pointing at the obvious a Raspberry PI Zero W with camera port. I will re-assemble my 6 legged Robot with this on top later.

16 x Servo Module – 1st draft

Just the first 3D draft of my Servo Module. I still have the Raspberry PI Zero W hanging on the back of this – we don’t need to populate that header, but had plenty of room for it so just left it there. on top left you see jumpers to select Servo and Servo Signal voltage. On right you see a classic 3 x 16 header for servo connectors with the photo coupler providing a complete isolated Servo module.

I have a few changes I need to do – firstly I want to investigate how to add a current sensor with full isolation – possible using a photo coupler.