2A Motor Hat – Connectors

Connectors on this board is a challenge because I want to support 3 different usages:

  • 3-Phase that require a 3 pin connector.
  • 4 wire stepper that require a 4 pin connector.
  • PWM that require 1 pin + ground for every signal.

The board above uses 2.54 pitch connectors with space to mount small screw terminals. The ones I show here is just an example with a 18 x PWM and 18 x GND connections. These screw terminals are good, but they require access from top – so an alternative is to use something like the ones below that are right angle.

These are 2.54 pitch – 2 rows with 5.08 pitch apart. A bit big for my taste, but I think I can support them. And they don’t rule out anything as 2.54 pitch is very flexible. Height is an issue because PCB separators are 13mm to fit headers – these are 11mm on the back and a bit taller on the bit that will stick out from the board – I thing they will fit well.I need to make a package and show a 3D with these on a bit later.

HMI TFT Candidates

This first TFT cost ca 3.- USD and is 0.96″ with 80×160 pixels, 64K colors and what seems like a Half Duplex SPI. What I am looking for in displays are high quality displays with bare-bone adapters only adding connector, PSU and mounting screws. This is the smallest candidate and will be a bit challenging as I can’t hide a Hat behind it. One rule is that the HMI solution can’t extend the panel size, so I need a cable option between this and the GPU board. The entire board is only 24x30mm so this is small.

This is the same display without the bare-bone adapter. One option is that I grab this and add this on the back of my own adapter with GPU, but I have so far avoided this type of connectors. The price difference is marginal. I will look into it.

This cost around 4.- USD and is 1.3″ with a resolution of 240×240 pixels.

I face the same option to either use the adapter or bare TFT on this one. The adapters are however so well done and makes my life so much easier that

The next is this 4″ display with 800×480 pixel resolution as I mentioned before. This uses a OTM8009A controller that is supported in STM32 and several variants exist for ca 20ich USD. They offer SPI or parallel Interface.

I seriously want a 7″ display with minimum 1024×600 pixels, but I have not found anything that that match my criteria yet. I have a 800×480 display for ca 40ich USD, but I expect more 1024×600 displays to pop up soon.

HMI Solution

The HMI solution I find most attractive is stand-alone TFT solutions with UART as interface. I have used a few off-the-shelf displays earlier and the concept is great, but I want to evolve this a bit beyon just a stand-alone TFT – I want a complete, plug & play solution.

These displays interface to embedded solutions using a UART. You pre-program the graphics in a GPU and use the UART to exchange data only. This is an excellent solution and concept, but I lack a few components.

  • Using a TFT for data input is not always convenient, I often need custom keys and knobs to make up the rest of a panel.
  • I don’t always want to pre-load the graphics design, I want an option to download graphics from the embedded system using XML alike formats.
  • I want to chose wherever I use Web, PC, Raspberry PI or something else based on my needs without having to program x number of HMI Interfaces.
  • Graphics quality must be high!
  • And at last, but not least – customization factor needs to be very high.

I have already started a HMI project with a HMI Designer for a Desktop, Raspberry PI, Android or iPad etc. This is still a bit work in progress, but what I want to add is the embedded “HMI Browser”.

This is just an example display – this is a barebone TFT with a dumb adapter that is perfect for my plans and it exist loads of these. I want more options than a single display, but this is a start. The base concept is that I stack a HMI adapter with the GPU behind this – and as the adapter will be a Hat I can add whatever I want to this again.

I will finish my 3Phase/PWM board first, but this is my next project. Completion of a HMI solution for my projects is long overdue!


I have both 3-phase motors, stepper motors and PWM Hat on my list, so I want to use DRV8313 because this delivers 3 individual Half H-Bridges that are excellent for all of these options then combined together. I am pretty sure I can get 6 of these drivers on a Hat which would give:

  • 6 x 3-Phase Motors,
  • 4 x 4-wire Steppers, 
  • 9 x DC Motors, 
  • 18 x Solenoids/PWM signals. 
  • or any combination of these.

This would actually be a very powerfully Hat.

Looking at STM32F405RG I actually have 26 Timer pin’s with PWM capacity so this looks very doable. What I want to add in addition to DRV8313 is INA193 (or INA194) to measure current on each DRV8313. Ideally I would have this on every PWM, but I am running out of space here, so lets see where we land.

Getting 6 x DRV8313 on a Hat is very doable, but I will need a 60V DC/DC and 6 current sensors as well + a DC-Rail sensor – that is 38 extra passive Components. 

An early mock-up like the one above is just a quick exercise to place the actual components on the PCB for a reality check – and this does not look like a go to me. It is not just about placing components, but all the lanes I will need between them. And it is still capacitors etc that I would like to place here.

So what can I do?

Firstly – 60V is a bit ambiguous for this board, 36V (meaning 24V) is more workable meaning I can ditch the 60V/3.3V DC/DC. That helps a lot.

The second option is the filters that I have on the current sensors – I can remove these from electronics and do them in software – that will reduce 36 components to 12 and the density of the board is suddenly far more realistic – and less complex.

The capability to remove filters from electronics because I can do them in software is something I often face, and in this case we can due to the raw capacity of the M4 MCU. This last mock-up looks far more doable. And I am happy with a 24V limit on this board because this is for small 2-3A motors that seldom needs higher voltages. Now – lets og and design this one!

Smart SPI Schemes

SPI is a very powerfully and fast serial port used between Master and one or more slaves, but I want to evolve the bus into a proper device to device bus. This is actually far more straight forward than I expected as both Raspberry PI and STM32F405 support Half-Duplex modes. RPI only support Half-Duplex Master, so all I need to do is to connect MISO and MOSI and set correct modes – Raspberry PI into Half Duplex Master and all STM32F405’s into Half-Duplex Slaves. Switching between sender is done in SW using a Dynamic time-slot scheme.

Doing this without Raspberry PI can be done in the same way by one of the devices taking over as Half-Duplex Master. The key here is that we have connected full SPI, MOSI to MOSI and MISO to MISO, but in Half Duplex one of them will be idle so we just connect them together. This should work!

F405 is capable of 42Mbps, but the closest RPI speed is 32Mbps – and if we assume 1ms switching time and max 4ms sending we should be around 25Mbps (80%) effective bandwidth usage.

This is a step down from 84Mbps bandwidth on a full duplex (F405), but it is still pretty good speed and very functional since we now communicate device to device directly.

The second scheme that I used before is using full duplex and using a dynamic time-slot scheme between device that send on MISO. This works very well, but I can only send to/from Master – never directly Device to Device in this scheme. This mode have the advantage of full duplex, meaning that with the same 32Mbps and 80% rule we have a 54Mbps total bandwidth. But, is this actually faster? The answer depends on your message flow – if all your traffic is to/from the Master then yes, if not we just waste bandwidth by turning messages around at master.

A 3rd Scheme of rotating Master is possible, but I fail to see what I would gain since changing Master means all communication goes through that device.

All my new Hat’s have full SPI connected and to enable Half-Duplex mode we simply add a jumper between MOSI and MISO on the header – this enables me to select communication scheme based on what I believe is most efficient.

Half-Duplex with STM32F405’s only will be at 42Mbps and as with ca 34Mbps effective bandwidth. We get lower speed with Raspberry PI because we need to fit available clock schemes with this as Half-Duplex Master.

Assuming we have 20 devices in a stack the max message wait time will be 5ms x 20 under full load which is 100ms. I am ok With that because this is a very worst case – I actually believe switch time is much much lower and we can improve parameters, but we can measure that later.

So how much bandwidth do we need for stereo sound? Assume that sound is 32 bit samples at 32Khz – this is 1Mbps bandwidth usage. This is a brute force calculation, but it still indicate that we have bandwidth for 25-50 channels of high quality sound. If I assume telecom quality which is 64Kbps we basically have capacity for ca 195 2-way phone calls simultaneously.

Doing video or sound over some distance is more of an issue, but don’t forget that we have Wired and Wireless Ethernet options as well.

To sum this up – I intend to abandon my attempt on rotating Master and focus on 2 schemes – Master with dynamic TDM slots on Slaves or Half-duplex with dynamic TDM slots that scale to load. I will be back with a more detailed protocol description later.

Upgraded LoRa Options

I finished the LoRa + GPS w/E22-900M30S earlier today and decided to add in E22-900M22S footprint. The modules are almost identical except in size. The only difference is that 30S have pin 10 to 3.3V while 22S have this to ground, so it is straight forward to have both footprints on the PCB.

The 3D model show the 22S module and illustrate well the size difference to the stronger 30S module. This enables 4 LoRa units:

  • E22-400M30S, 433Mhz, 1W, 12km range
  • E22-900M30S, 868Mhz, 1W, 12km range
  • E22-400M22S, 433Mhz, 0.1W, 6.5km range
  • E22-900M22S, 868Mhz, 0.1W, 6.5km range

All modules have an IPX antenna on the module, so I use a PCB antenna with wire to the IPX. This provides a PCB antenna option, but I can also use the IPX directly for more options.

As for the range listed above – this is datasheet numbers. It will be line of sight mostly and I expect somewhere between 2-6.5km for 22S. As for the stronger maybe 5-12km. I say this because E22 modules give very optimistic range data, but we will see.

LoRa/GPS Hat Annotated

  1. IPX Antenna for LoRa directly on the module.
  2. PCB Antenna for LoRa.
  3. Power leds + MCU Status.
  4. USB Connector for MCU.
  5. Separate Power connector.
  6. GPS Module. Can use NEO-6M, NEO-7M or NEO-8M.
  7. GPS Antenna.
  8. USB for GPS Module.
  9. UART TTL.
  10. SWD
  11. STM32F405RG. Powerfully ARM M4 capable of running MicroPython.
  12. Raspberry PI Connector.
  13. CAN Port.
  14. LoRa Module. 1W or 0.1W in 433/868Mhz area capable of up to 12km with up to 300kbps data-rate.

This board can function stand-alone, as part of a CAN stack or as a Raspberry PI Hat. LoRa and GPS can be switched off through separate power supplies.


This is a LoRa and GPS Hat. The larger E22-900M30S with a range of 12km at left and the small NEO-6M at right. NEO-7M and NEO-8M should also work.

I mistook NEO-6M for having a SPI interface, but realized this was for Flash/EEPROM.

I replaced coils normally used to separate frequency interference with 3 x SPX3819. One for the MCU and one for LoRa and one for GPS with Enable pin controlled from the MCU. This way I can switch modules on/off through power. I need to double-check peak power consumption on E22-900M30S, but SPX3819 supplies 500mA so I hope this is sufficient.


E22-900M30S LoRa Hat

This is the first mock-up with the LoRa unit on. This is the larger and stronger of the modules and it occupied a bit more place than I expected, but I will do. It’s not much passive components on these modules and I still think I have just about the space for the GPS and antenna on right side. We will see tomorrow as I make the package. 

The E22-900M22S is about 1/4 of the size. They are based on the same chip, but 30S got a stronger 1W sender. 22S uses 0.1W and cover 6.5Km according to its datasheet. I take those 12km and 6.5km with a pinch of salt. At these frequencies this will be at line of sight, but lets test.

As for my 3D models I am very accurate with PCB footprint, but the rest is as far as I go an illustration. The antenna as an example show the space it will occupy, but it lack details. You can sit days fiddle with these if you want to, but I prefer them simple and editable.

LoRa and GPS Hat

Packing a LoRa and GPS module on the same Hat should be possible and make a lot of sense. I could pack a battery manager as well, but I rather just make a separate board with battery on and this can be stacked on the back of this unit anyway.

The MCU is the classic STM32F405RG which have 3 SPI’s and I will use all 3. One for RPI, One for LoRa and one for GPS.

LoRa is E22-900M30S with a huge range, programmable sending power and frequency selection. This is based on the SX1262 RF chip. I have no experience with this, so I have ordered various units to start with. This unit is a bit large so it will occupy most of the left half. Luckily this has a IPX antenna so we don’t need to worry about antenna wiring.

NEO-6M, NEO-7M and NEO-8M are GPS modules that are very small. I will be using NEO-6M, but NEO-7M and NEO-8M are backward compatible, so we can upgrade and check those later.

This board is straight forward. Most of the work is actually to make the packages for the LoRa and GPS module.