So SPI is *really fast* - i.e. I can run this at ~5MBPS no problem, and I'm only doing a 32 bit transfer each time. What's more, SPI is like synchronous duplex, as in during the same time shift out 32 bits, 32 bits come in. This is the major advantage of a clocked / master:slave relationship. This means that for a total of 64 bit transferred, we take only 6.4us. Holy heck. I'm not even going to bother writing non-blocking code.
*data = *data << 2; // shift parity and error bit out
*data /= 4;
}
```
OK - I've got this set up properly. Now I'll try plugging the encoder in an reading some values!
Great, and with a shift in some setting (I was wrong) I'm reading SPI values nicely. Next test is to see if these values get all messed up when I turn the motor on (update: nope, yay), introducing lots of EMF and noise into the system... Then I'll write some open-loop commutation using the encoder values (update: done). Then I'll think about writing a simple PID position loop. If I get through all of that tonight, I'll go to bed (haha).
But what's the larger goal here? I have one more day.
OK - I got closed-loop commutation working. This is where I take a position reading on the rotor and use that to advance the sinusoidal voltage I am sending to the phases such that *roughly* I get a magnetic field that is 90deg out of phase from the rotor's magnetic field. This is the max torque scenario.
// to update, must use duty update register, not just 'duty'
if(dir){
phaseu = elecpos/(modulo / 1024);
phasev = elecpos/(modulo / 1024) + 341;
phasew = elecpos/(modulo / 1024) + 682;
} else {
phaseu = elecpos/(modulo / 1024) + 682;
phasev = elecpos/(modulo / 1024) + 341;
phasew = elecpos/(modulo / 1024);
}
if (phaseu > 1023){
phaseu -= 1023;
}
if(phasev > 1023){
phasev -= 1023;
}
if(phasew > 1023){
phasew -= 1023;
}
```
Pretty slick, the key is adjusting the offset.
[Here](https://gitlab.cba.mit.edu/jakeread/mkbldcdriver/raw/master/video/clcomm.m4v) is a video of the motor turning *nicely* using closed-loop commutation. Not sure why this is upside-down, but that doesn't seem important. Also - you'll hear the 10KHz pwm buzz - this is something I plan on eliminating (it's simple - I just push the PWM frequency out of the audible range) but I have left it just in the audible range so that I can be sure when the gate-drivers are on (I don't want to fry anything!).
# The EMI Problem
Below, a log of me writing notes when I find this intermittent, horrible, reset condition.
Also: a note, I'm having odd reset events occasionally. Related to the earlier issue w/ usb power. I think I need to revisit the 'bfpsu' issue - wherein I want a 24V PSU that will deliver nice consistent power ~ 65 amps (that's about as much juice as is possible to pull out of a wall socket). I may need to build this, as these don't seem readily available. My other thought is to find a big switching PSU, and hook up a *giant* capacitor to the output to smooth it out.
OMG it's the SWITCH is being super intermittent. Don't use a switch rated for 7.5 amps past 7.5 amps. Heck!
OK - like 8th loop on this. I fixed that wiring and was still having a reset issue. Back at it now, added extra capacitance to the 5V output, and a diode that I had previously omitted soldering on. Seems better, but I make no promises to myself.
\ No newline at end of file
OK - like 8th loop on this. I fixed that wiring and was still having a reset issue. Back at it now, added extra capacitance to the 5V output, and a diode that I had previously omitted soldering on. Seems better, but I make no promises to myself.
Another update on this - I've shortened the motor lead wires and this seems to have killed the problem. Again, no expectations - I've been wrong a few times. But I suspect EMI was the issue, and shorter lines (smaller antennas) could be the solution! Hurray, maybe :| .
