BLDC Motor Control - Teensy 3.1 PWM capabilities?

[Omacitin]

Hey all,

I'm working on a making a brushless motor controller that I can use for a variety of motors and situations. I was hoping to use a Teensy 3.1 as the brains, for sensing motor position, control inputs, and calculating PWM outputs.

I'm still reading up on the various control methods, but right now, I'd like to get the hardware put together so that I can start experimenting and learning. To do that, I need to know exactly what I need for the various motor control methods. I think I've got most of it down, but I'm still a little fuzzy on the way that PWM is used, and what type I need.

I'd like to be able to implement the following:
Trapezoidal control
- Top (or bottom?) MOSFETS are pulsed to vary power
Sinusoidal control
- Ditto to trapezoidal, but duty cycle is a sine wave?
Field-oriented (or vector) control
- I think it's the same as sinusoidal, but the timing is adjusted according to motor position and speed
Regenerative braking
- All three lower MOSFETS are switched at the same time, with varying duty cycles, to make a boost converter
Slow and Fast Decay Braking
- One or two windings are quickly switched between top and bottom

So, from that, it appears that I need to be able to send PWM signals to all six gates. What type of PWM, though? Do I need to use phase-correct PWM? Is there a way to output signals that are mirror-images of each other, for braking? Also, I'm not sure how short the sine wave signals for sinusoidal control will be... Is there a way to control the widths of the individual PWM pulses, or will that not be required?

The parts I'm looking at using right now are the A4935, a triple half-bridge pre-driver, and the FTCO3V455A1, a triple half-bridge module. The pre-driver handles stuff like shoot-through protection and dead time insertion, and it will take 3.3v inputs from the Teensy. The motors that I'm planning on controlling all have latching Hall-effect sensors with 5v output, which the T3.1 will handle with interrupts.

The pre-driver chip has eight PWM inputs, 6 for the individual gates and two that switch all of the top or bottom gates at once. According to the Teensyduino PWM page, the Teensy 3.0 has 8 PWM outputs on the same timer, which would allow phase-correct output for all of them. Does the T3.1 have the same capabilities?

If I have any misconceptions about what's needed for the different types of motor control, please point those out.

Thanks a bunch.

 

[Omacitin]

I've got another question that might be easier to answer:

In the A4935 datasheet, pages 14 and 15, it describes a way to access a register that I don't recognize. The pins used are dual purpose, interrupt and data transfer. It looks very similar to I2C in format; the master feeds a clock signal into one pin, and the slave spits out the register data on the other. Except, there's no addressing, and the dual-purpose use would interfere with using the I2C module for other things.

Is there a name or library for this protocol? If there is none, it looks like it would be fairly straightforward to write a function for accessing the register. But the datasheet provides no max frequency for the clock. Is there a standard for that sort of thing?

Basically, what's the best way to access that register?

 

[dhylands]

You might be able to get away with using some type of SPI interface, but since it looks like its 10 bits, I'd be inclined to just bit bang it http://en.wikipedia.org/wiki/Bit_banging

You'd configure the clock signal as a GPIO output, and the data line as a GPIO input.

Page 7 of the data sheet shows the timing for the FF1 and FF2 signals, and page 5 shows that tLF an tHF need to be a minimum of 500 ns (which corresponds to a frequency of 1 MHz). They can be arbitrarily longer.

Just out of curiosity, I tried the following on my Teensy 3.1

pinMode(2, OUTPUT);
digitalWrite(2, 0);
digitalWrite(2, 1);
digitalWrite(2, 0);
digitalWrite(2, 1);
... repeated a bunch of times...

and I observed that the lows on pin 2 were 292 ns wide an the highs were 375 ns wide.

So you'll need a small delay (perhaps call delayMicroseconds(1))