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.
I have used these on the PWM12 Hat and the one I have mounted was worn out after 3-4 times of inserting and removing a wire! I am not impressed!
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
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.
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:
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.
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.
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.
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.
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.
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!
This demo is a bit in the early stage, but I am using C# and .NET 4.7.2 for a simple test. I developed in C# a few years back and was a bit dissapointed over performance. But, I notice that this have improved dramatically with later .NET versions so I am putting it up for a test. What interest me with C# is that the combination of language, Visual Studio IDE and libraries/framework makes it very productive to work with on the HMI side. What have dissapointed me in the past was performance. I have similar demo using Qt and I have to admit that I have not been convinced about Qt performance either.
What I am experimenting with here is a graphical programming language. In this case I started on UML State diagrams. I am not sure if I want to complete this, but I was using UML State diagrams earlier and know it add some value. I simply want to see if this is a path to pursue if I start using this to generate code. The demo you see above was knocked up in ca 2 days work including scrolling/zooming and a lot of the basic graphichs work.
C# itself is much slower that C++, but C# graphics uses optimized C/C++ libraries and I must admit I like the improvements I see. What actually convinced me is the plot below. This is done in raster graphics with 10 line plots containing thousands of points and update itself ca 27FPS. This is a stupid test to verify if raster graphics are sufficient for my graphical designers.
The difference between C# and C++ is that .NET (that is C# VM) actually have started using more kernals on HMI. So while it is slower at first it seems to get the upper hand because it can use the entire CPU while C++ libraries are stuck with one kernal. I know I can get a much higher performance using C++, but that will require that I put in a lot of work. This is also why I tend to stick to 2D raster graphics – I lack a framework that can do the same on 3D engines without a lot of work first.
One of the drawbacks with C# used to be that it was Windows only, but both Linux, Android and iOS has since then been integrated into Visual Studio. We will see where this leads.
I have so many Hat’s by now that I try to make some systematic documentation on them. This drawing is part of what I call “Annotated Schematics” to document the design and collect notes needed for working on the Hat. This example is one of my more powerfully Hat’s as it contains 12 separate PWM ports with current sensors. PWM ports are actually separate Half H-Bridge ports with a GND connector each for maximum flexibility.
This Hat is so powerfully that it replaced a lot of other Hat’s I planned. I was considering a separate Stepper Motor Hat or DC Motor Hat etc, but I don’t see the point. This is one of the most flexible motor drivers I have made. If you go back on this blog you will also see my notes on how many attempts I made on routing this before I succeeded. So far it is only minor comments on what needs to change.
This show another part of my “standard” documentation, the functional block diagram. This is basically just a visual content list.
I have done PWM signals before, but I am looking forward to experiment with the current sensors. If I use current sensors on a Stepper I should be able to sense torque and automatically detect edges etc.
The reason I started assembling this now (it has been around for a while) is however x-mas coming up – powering multi-colored led string.