Category Archives: STM32 Development

Cold Soldering

Soldering 0.5 pitch components is a challenge to get right. My latest problem have been cold soldering. Meaning that pins look ok, but as I test them I have no connection. Not sure if this is lack of temperature, lack of solder tin or what, but I will have to find a more reliable way because it has caused a lot of issues lately.

The illustration above shows the problem. Pins look as if they are soldered, but in fact they are not. I suspect a combination of to little paste and to low temperatures, but lets see.

Having MCU’s you don’t trust don’t help, but just for the record the one I tested did work!

New MCU’s

It is rare that I receive chips from China as unprofessional as these, but it does happen. I have no idea if these works at all yet, but we will see. If not the seller will loose out. I actually mounted a XPortHub, so we will see – but, this is why I want to build the test-bench with sockets.

Failure of the week

This would have been an awesome Hat, and I am “kind of” done routing the PCB, but my remaining challenge is the currents that I need to support. My PCB lanes for 36V+ is far to thin for 12-24A, so this will never work!

This version of the Hat have 12 x Current Sensors. One of the challenges is that DRV8315 have Pad’s going through all layers for venting and this act as a barrier against any routing signals. I could have managed this board with 4 layers, so I think it’s time to make that change.

The area between DRV8313 and the connectors get to dense in the first place and this is where I need to apply 36V+. The option I have is to use thick air wires, but I basically have no room for them.

The alternatives I have is (1) try to push some of the components to the back side, (3) use thick air wires, (3) use a larger PCB or (4) ditch current sensors.

This being a Hat the size is set, but I used a wider format on the 3KW motor controller so I can use the same here. One of the challenges with DRV8313 is that it has 2 VM pins separated rather than together. This is from a functional point an excellent driver, but the design require some space around the DRV8313 if you want to use it’s features.

 This is a mock-up of the wider board. I extend width from 65mm to 100mm. I need to change connectors a bit, but it is an illustration. I have not given up the original format yet, so lets see.

HAL Design

One of the next tasks as I emerge from my marathon Hat designs is to wrap up an actual HAL (Hardware Abstraction Layer) in C++ for STM32F405. The Drivers from ST is named “HAL”, but they are low level drivers or merely C functions to interface to registers. They lack abstraction and normalized user interfaces. One good example is CAN. My MCU stop as I try to start the auto-generated CAN, so I went into CubeMX and get the following screen:

So where/how do I set bitrate?  Answer: with some difficulty! This is just an excellent example of stuff I don’t want to see in a HAL Interface because this is low Level driver stuff. I expect that the developer who create the HAL class actually deal with this and leave the rest of us a straight forward, well documented and normalized interface!

A proper HAL would actually have a function that allow you to set standard bit-rates as per ISO11898-2 that is the standard for CAN. To be honest I think many of the older ST drivers was better than these new “HAL” ones. I like ST’s MCU series, but their software department need to shape up!

I have mentioned before that one of the better “HAL” interfaces I have seen is the Arduino “Wire” library. Not the code itself, but the actual interface. I can’t use that 1:1 because that library is blocking and I want asynchronous schemes, but it is a good start. CAN as an example should only contain a few control functions Send/Receive/Init and the Init parameter should be baud-rate in normalized form. I admit that I have yet to look into what Mbed have done, so I will do that as well.

The most important to get right is actually GPIO pin mapping. Then writing code you often need to wire your electronics in software, meaning you need to know which pin that has a given function. The way I decided to do this was to create a class “hGPIO” and allow the user to map it’s logical pins to actual physical pins. This means that I declare a hGPIO variable “can1GPIO” and map pin1 as Tx, pin2 as Rx, pin 3 as On/Off, pin 3 & 4 Special purpose etc. My SW will be given a GPIO variable and expect the pins to follow that standard.

I don’t use an On/Off function on my CAN port’s yet, but my software don’t need to know that. In fact the only place in my software I should need to worry about actual schematics and driver setup is in a single AppInit function.

I have used both C and C++ on STM32 in the past, and I will still need to use C on some MCU’s. The reason is that GCC for some reason bloat a bit as we start C++ so we use up the first 65Kb Flash faster than with C. This is because C++ drag in libraries and it probably can be optimized, but I do not care about C++ on a 16Kb Flash MCU. On these small MCU’s I just use bare metal because I can’t afford the abstraction layer.

This is not a new task as I did this before and created a C++ library EFC (Embedded Foundation Classes) to go with it. But, time has changed and it’s time to move on so I want to re-visit my old designs and re-fresh them before I start writing loads of new stuff for now 10 Hat different Hat’s + some, but don’t worry my list of Hat’s I want to make is very long so it will still be plenty of electronics, but I will start moving more and more into Software and end-user projects through this year.

Happy New Year!

Connector Size

These 2.54 pitch spring terminals occupy more space than I hoped for, so I had to abandon current sensors on each DRV8313 to get room for them. The red areas are the spring connectors. The yellow is the MCU which I desperately need space around since I will be taking out close to every pin on this design.

I will add in a common current sensor. I also realized that for the current sensors to be of usage for 3-phase I need to mount it on a single PWM outputs (phase current). That array of 1206/1210 components are the capacitors. I decided to remove the larger one and replace them this an array to get the profile down.

Heat sink on this Hat is very straight forward – you mount it on the back to cool down the PCB. Notice that each DRV8313 have an array of holes connecting and venting out on the back side, so it is fully possible to mount this straight on a heat-sink.

Taking out 18 PWM signals on such a small design is maybe ambiguous, so I could drop down to 12 – 3 x 4-Phase, 3 x Steppers, 6 x DC Motors etc. If I did that I could move the MCU to right and attempt 12 (or 6) x current sensors.

The reason I keep on about current sensors is because they enable positioning on a 3-phase as well as torque calculations on both 3-phase and Steppers. With torque calculations on Stepper I could avoid end-stops on CNC machinery etc – simply detect where the end is and just put up a mechanical stop. To get more channels I can just stack up boards, so adding the sensors back is worth more than channel density + 12x 2.5A PWM channels are still a good. Hat.

Raspberry PI Hat’s

It’s been many Hat’s lately as I am focusing more and more on this as my main core for everything. I still have a load of Hat’s that I want to start on, but I won’t exactly have much spare time the coming year. This is just a summary of projects that I am working on and intend to complete.

XPortHub. Basically a communication Hub With CAN, RS485, RS232, SPI, I2C, USB + Micro SD Card, RTC, Flash etc. This Board is actually assembled and so far working well.

Wifi Hat based on ESP32 to enable a low-cost Wifi/Bluetooth With CAN, RS485 and a few IO ports. I have PCB for this Board, but have yet not assembled or tested it.
32 x IO / Servo Controller.

Not ordered.

8 x DC Motors + 16 x Sensors.
7 x 5-Wire Stepper Driver.
3KW Universal motor driver, Capable of 60V @50A on 3-Phase, DC, Stepper or Solenoids.
NB-IoT/4G Hat.
Light-weight 60V PSU. This is only a test board with the Hat format.
LoRa + GPS Hat. Shown With 12km 1W configuration.
LoRa + GPS Hat. Shown With 6.5km 0.1W configuration.
2A Motor Controller. Can run 6 x 3 Phase, 4 x Steppers, 9 x DC motors or 18 Solenoids/PWM signals. This is still work in progress.
3KW 3Phase Motor Controller. This uses DRV8301 and is designed for 60V@50A. This actually need a revision before it is ordered.
Mini stand-alone 3-Phase Controller for 2A. This is assembled and is working, but the 60V DC/DC needs a revision.
CAN – USB Adapter. Assembled in rev 1.1 and working.
ESP32 Utility Driver – 4 sensors, 8 Servo/IO, 2 H-Bridge, 7 PWM signals. This is assembled and working rev 1.1.
Model Train Cockpit Controller. This is a failure and need a revision + a support adapter. A rev 1.2 is on my list.
STM32FxxxRx Breakout Board. Assembled and tested for F105 and F405.
Breakout for STM32F031F4 or STM32F042F6. Assembled and working.
My SWD Adapter. This will need an upgrade, but it has been one of my most usefully designs. It enables me to use a small 1.27 pich footprint on my designs and deal With ST-Link 2.54 Pitch. Next Version will have Reset and Boot Connectors.
Micro sensors and actuators. I had 4 of these designs and the Temperature, Light, Proximity sensor will be upgraded. More external sensors will be added later.

And more – many of my older designs have either been ditched or evolved into more mature designs listed above. I will be focusing more and more on the new Raspberry Hat format for everything. The exception will mainly be a series of intelligent sensors evolving out of my STM32F031F4 micro designs.

 

 

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 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!