BasicPI

KiKad First Contact

Posted on by Jan

I decided to make Rev 1.4 of the 32xServoIO using KiKad. One of many reasons for leaving Target 3001 and using KiKad is that I want to show more schematics out here. That has been difficult with Target 3001. The main reason is however cost – I use a free version of Target 3001 with some age and lack support for 4 layers etc. I will give you a summary of the experience once I know KiKad better.

One thing that can be said about KiKad is that it is much, much heavier to get started with than Target 3001. Things are different for sure – hopefully to the better once I get to know KiKad more.

What you see above is the bare minimum for ticking a STM32F405RG. In fact you can even drop the crystal if you don’t use USB.

And first point to KiKad – I actually can copy schematics out here now! I could before as well, but with some difficulty.

32xServo/IO Hat

Posted on by Jan

These two 3D models show my old and new 32xIO. It’s a layout difference, but except for that they are mostly identical. The old board have the DIP selecting CS Pin for SPI, while the new dropped that.

Revison 1.1

Revision 1.3

The challenge with these 32xServo ports are that I do not have 32 PWM signals in HW. In theory STM32F405 do have 32 x PWM signals, but you can’t route them all at the same time. At most I get 28 signals if I switch everything else off – which I can’t.

The idea was to use a timer interrupt to bit-bang some of the pins to compensate, but to do that we need to actually use the MCU a bit. The classic RF pulse is 500uS to 1500 uS, so we need something like 50Khz interrupt or preferable 100Khz interrupt to process with some accuracy. I would have preferred using PWM signals only, but that is not possible. Also, we do actually have a powerfully M4 ticking at 168Mhz to support this, so we have plenty of juice – we can do this. The test is to put signals on a Servo and watch their behavior as they hold selected positions. I tried that with SW on a ESP32 and noticed “twitching” – small movements before I switched to HW PWM channels.

The way it is routed on 2.3 means I have:

  • 32 x GPIO channels since all are GPIO.
  • 17 x 5V compatible GPIO channels
  • 15 x ADC channels
  • 22 x Hardware PWM Channels.
  • 1 x SPI port for backbone bus
  • 1 x CAN port
  • 1 x USB port
  • 1 x User Led

I do however notice that I can optimize this a bit:

  1. I have used PC1 which is ADC capable for Status Led, while I have PC13,14 and 15 that are GPIO only available. This gives me one extra ADC channel, meaning I get all 16 ADC channels on IO.
  2. PC13, PC14 and PC15 can be used for Led’s giving me 3 user leds.
  3. PB12 and PB13 can be used on CAN2 releasing PB9 and PB8 from CAN1. That gives me 2 extra PWM/GPIO channels replacing 2 x GPIO only channels. CAN2 is Slave only thought, but I think I can accept that.
  4. If I ditch SPI1_MOSI and accept that this board only can be used as Half-Duplex Slave will free a PWM capable pin. I have to think about this one.
  5. In addition I need to add resistor options on SPI as well as the new SWD connector.
  6. Replace 2.54 pitch jumper with a 1.27 pitch.
  7. Move + Power lane away from ground plane looks doable to get a better ground plane.
  8. Move USB connector to right side closer to PSU.
  9. I also need to evaluate capacitance on the power connector.
  10. That leaves one change – I need different PSU on the 16 first versus the 16 last. Or more correctly. I think the solution here is to add an option to select between 3.3V/5V or Servo PSU on the 16 ADC capable channels.

I guess I can as well just start re-wiring this PCB from scratch due to the number of pin changes. But, I think this will be worth it + it is not that much work once I set my mind to do it. It is actually far more work making SW, but again – the changes will only affect the “wire” function and capability list. Done right Rev 1.4 should have:

  • 16 ADC/GPIO w/Mixed HW/SW PWM to left
  • 16 GPIO w/ HW PWM to right

PWM12 rev. 1.3 Draft

Posted on by Jan

Started to make a few modifications on PWM12 Rev 1.3. replaced spring terminals with 2.54 pitch screw terminals. Discovered that if I mount them on the edge I can access the screws. And I did not like the spring terminals at all. Also removed the 5V connector and added SPI resistors.

PWM Abstraction Layer

Posted on by Jan

Designing a PWM Interface is easy, but using ST’s “HAL” layer requires a bit of testing. A friend of mine decided to write his own drivers because he believe ST’s drivers are over-complicated and too low level. I agree, but I prefer to make my own C++ Abstraction Layer on top of the drivers.

So how should a PWM Interface look like?

Using PWM we have one limitation. One timer control many PWM ports. The example below is from STM32F405RG

  • TIM1 4 PWM signals
  • TIM2 4 PWM signals
  • TIM3 4 PWM signals
  • TIM4 4 PWM signals
  • TIM5 4 PWM signals
  • TIM8 4 PWM signals
  • TIM9 2 PWM signals
  • TIM10 1 PWM signal
  • TIM11 1 PWM signal
  • TIM12 2 PWM signals
  • TIM13 1 PWM signal
  • TIM14 1 PWM signal

In total 32 PWM signals, but TIM1 as an example control 4 ports and those 4 signals must share the same frequency, but they have individual duty cycle. Channel 1–3 on Timer 1,2,3 and 8 are used in PWM12.

  1. – start/stop each channel.
  2. – Frequency configuration of timer in Hz. To make this simple I also add frequency on each channel knowing that if I configure channel 1,2 or 3 to different frequency I will change all 3 channels.
  3. – Duty Cycle in %
  4. – Manual On/Off. On is 100% Duty Cycle while Off is 0% Duty cycle.

Wiring of PWM signals are the same as others. The same signal can be wired to different ports, so we wire each PWM signal to a Timer and Pin. This should be done in application initialization and is the only place where source code need to deal with physical layout.

This will work well for individual signals, but I also need to cover 3-Phase Motors, DC-Motors and Stepper motors in the Abstraction Layer as well as dual frequency signals.

A dual frequency means we pulse with a selected frequency and duty cycle and then use a secondary timer to create a lower pulse frequency based on that. This is an excellent way of providing PWM with an “amplitude”.

A 3-phase signal will use 3 or 6 PWM signals on a selected frequency – lets say 20Khz and then change duty cycle for each signal. If we use 64Khz we might want to change duty cycle only at 10Khz to avoid over-running the MCU as we need to do heavy math for each change.

DC is simpler as we use 2 signals and a selected frequency using duty cycle as speed (amplitude).

A stepper is even simpler as we use a trapezoidal algorithm to set position step by step. But, we can use the same trick with a higher frequency pulse to simulate amplitude and control torque.

This gives me the following AL classes:

  • alPWM – single PWM signal
  • alDCM – DC Motor composed of 2 PWM signals
  • al3PM – 3-Phase motor composed of 3-6 PWM signals.
  • alSTM – Stepper motor composed of 4 PWM signals.

In addition to the PWM side of things each class also need functionality to control it’s motor algorithm, but I leave that for a later entry.

DRV8313 Bug Found

Posted on by Jan

This puzled me because the 4 circuits on PWM12 was copied from the working motor controller, but looking at the schematics I suddenly realized that 3.3V out from the buck converter is connected to ground – which explains why I draw 10mA++ extra current and why the internal logic don’t respond – it was shorted. I actually have the same bug on the motor controller as well, but I have obviously fixed it there and forgotten to take a note – bummer!

I looked at various schematics using DRV8313 to make it simple and must have picked up this bug. I don’t use 3.3V from DRV8313 because it is to little, so all I needed to do wss to cut 3.3V loose from ground and things should work as expected. The 3.3V on DRV8313 actually annoy me – it is only 10mA – unusable for most things.

As I said – something utterly simple and stupid, staring me in the face and duplicated on all 4 circuits – doh.

Trapzoidal w/DRV8313

Posted on by Jan

This screen shot is from MC3X60V3A that also uses DRV8313. I fired it up and looked at code because I need a reference as I try to understand the errors I have on the PWM12 board. I use the same circuit, so I am puzled.

Trapsoidal algorith is a 6 step brute force algorithm where you control speed by frequency of the steps. It is easy to code and a quick test to verify drivers & motors.

Problems with DRV8313 on PWM12

Posted on by Jan

I have used DRV8313 in a project before and it worked well, but on my PWM12 Hat I seem to have 2 busted chips so far. I selected both from the same batch, so I will add a 3rd from a different batch and see if it works.

PWM12 is a very simple Hat and DRV8313 is straight forward to use. I will not know the answer to this before I get a circuit working, but I suspect a bad batch again. One indication is that the two I have used so far behave differently. The first output ca 1.75V, while the other output 0.

It is a reminder that I should stop buying advanced chips from Asia on aliexpress. Luckily I have 4 different batches, and I don’t know if this is the cause yet.

Update 1: Adding the 3rd circuit I get the same output as from #2. #1 have an offset the others do not have. What puzle me is that I have absolutely no signal from any of the DRV8313 chips and this was 2 different batches. I can measure input voltage, I can measure that nRESET, nSLEEP and EM4 signals are correct. I can also see the pulse – that shoul be it – I should see an amplified pulse on output. You see the schematics for the circuit #4 above – it is seriously not much to this.

I also notice that I draw ca 70mA with 3 x DRV8313 connected regardless of what signals I give. It is almost as if I have done a systematic or common error on all 4 circuits. Luckily I have a different motor controller (MC3X3A) that uses the same chip and is working, so I need to use this as a reference. In absolute worst case I will re-solder a verified, working DRV8313 over to a PWM12 board.

Update 2:I have added the 4th circuit from yet another batch with the same problem. I see an unusual power usage – ca 25mA (ca 6mA on the one that works) and no response. All signals in are ok – Power, ground, Enable, Reset, Sleep and PWM. My next step is to solder up a motor controller and using a DRV8313 there for so to move it to a PWM12 Hat. In addition just let the problem rest a bit and look at it with fresh eyes one of the following days. I suspect that I have done something blunt stupid and simple, but I can’t find it – yet.

Update 3: I moved a DRV8313 that was not working on PWM12 over to the motor controller and it works perfectly! Meaning it is something with my schematics or PCB layout that is off on all 4 circuits. In one way that is a relief because it means my batches are good – at least some of them. Now I just need to figure out what is wrong on PWM12.

Programming x-mas Led strings

Posted on by Jan

We are getting closer to x-mas and I am about to start setting up led strings in my garden. I have a load of 12V and 24V led strings, so I plan using my PWM12 Hat as LED Driver as illustrated below.

The system set up is straight forward – I use a number of PWM12 Hat’s stand-alone to drive the strings. Each channel can drive 5-10 meter of Led’s and I can support both 12V and 24V systems. I need to make a PSU with 5V, 12V and 24V and some kind of waterproof casing for the driver – I will probably just use a plastic bag and mount it on a plate for now.

Programming is easy as I can remote control this through the CAN ports and all we need to do is to output a PWM signal. Most strings are single lights, but I also have a RGB string that need 3 signals to set color. We set intensity by regulating PWM duty, but I have to work out a conversion scale as this is not a linear conversion. Using 32 intensity settings I can get 32,768 different colors on the RGB setting.

Programming with State Diagrams – part 1

Posted on by Jan

A quite like UML State Diagrams as they give a good high level view of what happens in the code on functional levels. I was first introduced to this by a tool that actually let you create embedded code. This overlap a bit with PLD, but it creates a better overview of event-flow and an alternative way of viewing your code. I have tested some tools that attempt creating code, but they are too limiting so I decided to create my own experiment.

I was a bit surprised to find that it is huge variations in how UML State Diagrams are used and since I intend to generate source code I need to define how we will use this.

An UML State Diagram is composed of “States” and “Events”. It has some similarity to a flow diagram like PLD, but the concept is a bit different in the sense that one state can generate several signals or events. Some tools will call it signals, while I prefer the name “events”.

 To define out states we make a rule that input are primarily on left, while output are primarily on right. I also add a round connection point for events where the color will display it’s status. All output events are displayed, while only mandatory input events are displayed by default. To create a new input event you simply grab an event and drag it to the state. This will add the input event and connect the events with a line.

The name of the state will be a function name and the content of that function can be a description representing source code, a PLD diagram or another UML State Diagram.

In the example above I show a full diagram with external input and output. This can be used as a component in other diagrams as follows:

Then used in another you chose what is displayed about the content – you can show the sub-diagram or simply add a text describing what is done.

This last illustration show Fork & Join. Fork will take one event as input and copy it into several events that now process in parallel. Join do the opposite – it takes several Events as input and wait until it has them all.

The experiment is to knock up a tool that does sufficiently of this so I can evaluate if this is a path forward. Is it worth it? At the end it comes down to one single thing – speed of development!