3ph HD: Controller Port, Part 1

The summer's coming to an end, and one of my goals was to finish my transition from the MSP430F2274 to the STM32F103. Changing microcontrollers is a real pain in the ass, and not something I would want to do more than once every couple years. To motivate the transition, I am building yet another motor controller, the 3ph HD, that will have all the functionality of a half-3ph-Duo, but with twice the power and, most importantly, the ability to play three MIDI tracks through the motor.

Here's the new board. It's 3.9"x1.55", which is exactly half the footprint of the 3ph Duo. This is made possible by the compact IR21844 (or I guess it's now the IRS21844) gate drivers, the footprints for which you can see in the upper-left corner of the board. The MOSFET mini-brick, if it's not clear, goes on the other side. I've also apparently now completely given up silkscreened component designators (R12, C15, etc).

What the heck was that resistor again? ::Opens EAGLE.::

The soldering went easily enough, and there were no mechanical interferences. Here are a few views of the assembled board:

The capacitors I was worried about  (the small ones) clear by about 0.5mm...

The business end.

It might be small, but I really hope that with an adequate heat sink this board can hit the 2kW mark. That would make it pretty ideal as a scooter/bike controller, though I have no immediate vehicular plans for it. Before I can even begin thinking about that, though, I have to go through the arduous process of porting the control software to the new microcontroller. And before even that, the low-level functionality that one takes for granted like: "How do I even set a bit?" "How do interrupts work?" "How do I read an analog value?" I call it the "primer," because it's the absolutely essential bit of microcontroller-specific syntax.

Luckily, the STM32 lay of the land is very compatible with that of the MSP430. In fact that's one of the reasons I chose this over other ARM-based microcontrollers. Timers and PWMs are handled in a very similar fashion, as is analog-to-digital conversion. Interrupts are a bit different, but not in a bad way. The prioritization and nesting mechanism for them is much more apparent, which is good because I plan to use it. The biggest advantage, though, is the hardware multiplier. Oh, what I would have done for a hardware multiplier on the last controller...

Speaking of which, after I ported the bulk of the core functionality, I couldn't resist a benchmark. I copy-pasted the field-oriented control code from the previous 3ph controller (the scooter one) and changed the relevant variable names. The STM32 has a wonderful "extra" timer called SysTick that can generate high-priority interrupts. I decided to use SysTick to do my dirty work, the sine wave interpolation routine. This is the "fast loop" of the FOC code, the one that gave me all the problems in the 3ph Duo.

In the Duo, I hijacked one of the PWM timers to process the fast loop at 14.5kHz. It make sense: Why interpolate faster than your PWM generation? But it messes with the PWMs and required a good deal of hacking to get it to finish in ~50μs to give the slow loop some foreground time in which to run. This scope trace shows the relative time spent in the fast loop (high) and out of it (low):

Not ideal.

A lot of that 50-ish microseconds is spent scaling the PWM.  (The sine table look-up is actually pretty quick.) That's because the MSP430F2274 doesn't have a hardware multiplier, so it spends several dozen clock ticks shifting and adding things to "multiply" two numbers together. Division is even worse: The dimmer line in the scope trace is the extra time it takes to calculate the motor speed, which involves a single integer division.

The STM32 is an entirely different beast. Even though it has the same clock frequency (16MHz), it eats integer multiplies for breakfast and spits them out in one clock cycle. The result is a much faster fast loop, without pulling any hacks.

With SysTick set comfortably at 10kHz, the fast loop only runs at 10% capacity, including the division  for speed calculation. Certainly the slow loop also needs some processing time, but I never ran into problems with it even on the 3ph Duo, so there should still be plenty of leftover processing capacity. It could be used for things like sensorless state estimation, more advanced control loops, or injecting MIDI tracks into the phase PWMs...

First, though, I need to get back to the state where I know the core control algorithm is working.

Cue the scooter motors.

I made a nice heatsink block and hooked everything up to the rear motor of the BWD scooter. Unfortunately the USB connector on this board is sort-of flaky, so I'm going to need to change it or find some XBees that haven't been infected with the 10C0 firmware/virus. (Seriously, all my XBees have been bricked by this firmware from 2008...) But hey, once I figure that out, it'll give me a chance to test wireless programming.

I did manage to get the controller running in "dumb" mode so far, just setting a fixed magnitude for the sine waves and letting 'em run. This confirms most of the hardware functionality, since in order for the motor to spin correctly (not with horrible noises) the three gate drivers, six MOSFETs, and three Hall effect sensors all need to be doing their jobs. So at least I didn't totally mess up the board. 

In fact, as I would have expected, the motor is almost totally silent with sinusoidal commutation. I tried to take video of it, but there is so much background noise from fans (it's 90º in Cambridge) that it's not clear that the motor itself is silent. So you'll have to wait for the next video. Except by then it might not be silent anymore.......