sim-
commented
8 years ago Hello! It's the timing period (interval), not frequency, so the lower the number, the higher the maximum speed. It's kind of a legacy hack that it lines up-ish to milliseconds in 4-digit hex form. The number is scaled to be compatible with old quax code values, and specifies the time for two commutations. So, 0xe0 means 0xe0 * (16 / 2) ticks for two commutations, /2 for one commutation, and at 16 ticks per microsecond (16MHz), that's 0xe0 * (16 / 2) / 2 / 16 == 56µs. 0x80 * (16 / 2) / 2 / 16 is 32µs per commutation.
Before releasing this, though, I should run through all of the motors again (including gimbal and hard drives), since this setting also has a side-effect of catching the "spiral away" effect of losing motor timing, which can happen quickly sometimes (sometimes multiple times) during start-up, where no assumptions can be made about motor mass or power. If the inductive properties don't allow TIMING_MAX to be reached in this case, the motor can just sit and whine instead of starting (because electrically, it looks like it is spinning). This is the downside of lowering this value (increasing the maximum speed).
I was holding off on this change previously because it might make more sense to go not quite so fast (low value), and because the existing value was set by experimentation of where the timing code starts to lag by running out of cycles to peform the calculations. So, it works with faster values like 0x80, but the timing retards. The best solution to this is to fast-path the 24-bit math when it is not needed (which is basically all of the time other than when spinning very slowly -- it really only needs about 18 bits to fit TIMING_MIN * 240 degrees (TIMING_MIN * 2 plus the previous commutation time), which is the zero-crossing timeout).
Uhmm, so story short, the comment should be 32µs. ;)
Yo dawg I heard you didn't like hitting the rev limiter