Pages: [1]   Go Down
Author Topic: Is the Due fast enough for BLDC commutation?  (Read 206 times)
0 Members and 1 Guest are viewing this topic.
Denmark
Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, I'm planning on using the Arduino Due for 3-phase commutation for a Brushless DC motor. The motor is 8-pole, and I would like it to run up to 10000 rpm. With 6 commutations pr. electrical rotations, it equals 8000 state changes pr. second which equals 125 micro seconds between state changes. However in order not to loose too much torque, i would like to make the state change within 5% of that period, which means 6.25 micro seconds.
I would like to avoid direct port manipulation etc. and instead use digitalRead, analogWrite etc.

So I imagine a process like: React to an interrupt triggered by one of 3 hall sensors - set flag in interrupt routine - check for that flag in main loop before any other processor intensive tasks (like lcd display, PID calculations etc.) - If flag is set then read 3 hall sensor states and analogWrite to the 6 outputs to the half bridge drivers according to the hall sensors  (cross conduction and over current is taken care of in hardware).

My question is: Is the Arduino Due able to do the above process in 6.25 micro seconds?

Another question is: Is it possible to do digitalRead on pins that are setup for interrupts.

Regards, Peter
Logged

Offline Offline
Full Member
***
Karma: 7
Posts: 146
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

There is a sliding scale of difficulty here.

Quote
Is the Due fast enough for BLDC commutation?

In general, yes. If you can do 9000 RPM with an 8bit AVR, 10kRPM should be easily achievable, and you can probably afford to be a bit loose with your coding.
http://www.instructables.com/id/BLDC-Motor-Control-with-Arduino-salvaged-HD-motor/

Quote
My question is: Is the Arduino Due able to do the above process in 6.25 micro seconds?

This I think is starting to push the limits, depending on how much calculation is performed, you can quickly eat up 5us and have not much left over.

If motor control was the only function, then it should still be doable, but you may need to do some optimizations and use whatever hardware assist is available. Will need to be interrupt driven.

Quote
check for that flag in main loop before any other processor intensive tasks (like lcd display, PID calculations etc.)

This is where you will probably run into difficulties. if you have the CPU 80% dedicated to driving the motor, the rest of the tasks have to be low-priority background stuff. There is no low-overhead way to assign priority to real-time tasks other than with interrupts.

With the right architecture, and some careful coding, you might be able to squeeze everything in. I would consider having a chip dedicated to motor control, and another for UI type functions.

Even with a detailed spec, it's not possible to give a definitive answer. The only way to find out for sure is to prototype it. If you write some representative control code and measure how much CPU it takes, you can get an idea how much is spare.
Logged

Please don't PM me asking for help. Ask questions in the forum.

Earth
Offline Offline
Sr. Member
****
Karma: 14
Posts: 329
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well, the Due is 84MHz and executes one instruction per clock so you get 84 instructions per uS and thus 525 instructions in the span of 6.25us. But, you really have 125uS if you can calculate and anticipate the next operation directly after doing the current one. That gives you upwards of 10,500 instructions. I'm fairly sure that the hardware pins can be toggled at least at 1MHz and maybe faster so that gives you plenty of leeway. But, if you plan to do this why wouldn't you use a chip with built-in three phase hardware outputs? This is much safer because they tend to support hardware based dead time and all sorts of other pleasantries. You might not need to do as much PWM with a BLDC but my understanding is that you still want trapezoidal waveforms so that means you are going to be doing PWM up the ramp and down.

BTW, you can always do digitalRead even if the pin has interrupts. Reading the pin state will still tell you whether it is high or low. But, if you hope to do fast I/O you really might want to use faster routines than digitalWrite/digitalRead. I seem to remember people commenting on ways to make those two functions faster but I'm not sure of the current state of either one. If you need speed it might be better to be sure you've got the fastest routines possible.
Logged

Denmark
Offline Offline
Newbie
*
Karma: 0
Posts: 21
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you, both smiley This gives me some ideas about how to make the code as efficient as possible i.e. interrupt driven and anticipating the next commutation. I guess I'll have to wait for the Due to arrive in the mail, and do some benchmark test. If it is too slow, I'll have to wrap my head around using direct port manipulation.
 
I'll be using 3 IR2183 for the half bridge drivers. The reason for this, is that i prefer through hole parts (related to poor soldering skills), and that I'll be using a total of 12 hefty mosfets, so i need some power for gate drive. Also the IR2183 have built in cross conduction protection and 500ns dead time. I haven't been able to find  a through hole 3-phase driver IC for this. I'm finishing of the schematic and will be making a post about this in the electronics part of forum.
 
I remembered reading something about analogWrite on the Due, having a lot of overhead, bit I can't find it again. Does anybody know how many cycles it takes to do an analogWrite (and maybe also cycles for digitalRead)?
Logged

Pages: [1]   Go Up
Jump to: