@@ -972,4 +972,27 @@ First up, I'm hanging this thing up when I try to run it in an interrupt: might
Ah - no, this is probably because I am running the control loop in an interrupt, but the var is never returning because that happens in *another* interrupt.
OK, have 50khz of this going on, now I need to apply some twerk vector and see if I can poke it around.
\ No newline at end of file
OK, have 50khz of this going on, now I need to apply some twerk vector and see if I can poke it around.
To track performance:
- read takes 7.7us
- w/ all the whistles, down to the set, it's about 10us even
- 7.9us w/o the write to the dacs, so that's 2us alone
OK, now I just have to prevent this from running when things are non-calib'd. Or maybe there should be a dummy table in there, to start? Have to turn the timer IRQ off during calib, let's see...
OK, yep, but now the loop ranges from 40us to 10us because of this line:
```cpp
floatra=lut[result];
// to find the phase, want to find modulus this ra / 1.8
while(ra>1.8F){
ra-=1.8F;
}
```
Not cool. Also seems pretty terrence regardless: easy to stall.
Ah, I was mapping 1.8 - 1.0, should have been 7.2 - 1.0: the 0-1 'phase angle' sweeps thru 4 full steps, not one.
OK well this is a decent minimum viable thing: it commutates. There's (I think) an obvious relationship between control loop and maximum RPM, so it's probably all maths and optimization from here out. The encoder read is the the obvious bottleneck, so is that modulus operation. I'm not totally sure I'm applying phase angle ideally... ah yeah, obviously better results when I do 180* phase rotation rather than 90, why did I think it was 90? Thing's rippen at 5krpm w/ no load, that should do pretty well, stoked to put it on an axis tomorrow and issue some commands from the browser to whip things around. Exciting futures for motion control.