So the 2 key parameters are the PWM frequency & the total power. The frequency has to be at least 24khz to avoid making noise but not 32khz to have enough clockcycles.
The total power determines how much of the total time the MOSFETS are moving current. The total power has to be less than 100% to create time for the interrupt handlers to fire. If it's too high, the motor will be jerky, intermittently short circuiting. You want the P MOSFETS to all turn on, then all switch to N some time afterwards to give the interrupt handlers time to fire.
With these parameters correctly calculated, the movement possible with the F330 is smooth, torquey, & silent but still prone to stalling at the same speeds previously found. The step size can be fractional again without making it stutter.
The decision was made to use a 4 byte packet, 2 sync bytes, a power level, & a phase. The trick is to ramp the power based on speed so it doesn't fry. Even at 300mA, those MOSFETs get blazing hot so they might be shorting during the PN switching.
Blheli has delays (NFETON_DELAY, PFETON_DELAY) when switching from P to N fets. It just decrements a counter in a loop to create the delay. The lion kingdom found the given value of 15 made it stall. Any nonzero delay made it rougher. It was going to be a compromise between delay & heat, but any delay was essential.
Without the L6234, the control board was a grotesque waste of an STM32F405. There's nothing an 8 bitter couldn't do. The F330 could probably do everything except the radio. There's still 1 SIL F330 based servo left. Time to button it up & mount it on the camera pole.
Enough testing had been done to settle on an interface. The fastest stepping in full step mode is 250Hz, so there's enough UART bandwidth for packets. The MOSFETS require PWM since 100% duty cycle at 5V makes them hot. It would be a 4 byte code with a 0xff, 0x88 sync code, a PWM duty cycle & the MOSFET code. Bits 0:2 enable the MOSFETs & bits 4:6 set the directions.
A delay of 4ms between steps made it spin fast. A delay of 256ms between steps made it spin coarsely but slowly. A delay of 15-19ms inclusive stalled it or made it spin backwards. The motor still got too hot at the lowest duty cycle which didn't stall, even though the MOSFETs were acceptible. It would need to time out the MOSFETs in the 4ms range & vary the duty cycle based on speed.
There wasn't enough precision for slow camera movement. This took the luster out of full stepping. With the roughness also encountered in microstepping, the only practical motor driver pointed back to an external L6234. The F330 can't drive the MOSFETS with its hard wired CEX pins. It needs to use an interrupt handler.
Blheli says it generates 24khz PWM on the F330. There's no sine wave table & it doesn't use the CPA to drive the MOSFETs, so it's probably full stepping. It uses the single Timer0 to generate PWM. There might be more precision to be gained with microstepping at 24khz.
As usual, the input PWM pin P0.7 is not the UART pin P0.5. Fortunately the UART pin isn't used, so that needs to be bodged over. Then, the PWM lowpass filtering capacitor had to be removed. The rest was a routine UART bringup & GPIO bit banging.
Note the MOSFET part number is under the MOSFETs. They're complementary PN pairs in a single package.
So full stepping the motor initially stalled it. Undoubtedly, this was already discovered with the L6234 since that was using microstepping. The problem with copying a UART code to GPIO pins is microstepping requires switching at microsecond resolution. The UART goes at 20khz if it's lucky. It needs a UART code for phase & a hardware PWM timer the same as lions did before.
The SIL F330 is prehistoric, dating back to 2004, yet it still has a 3 phase motor driver called the PCA. Even then, it has to be optimized 7 ways to sunday. Nothing but copying variables is possible in the interrupt handler. They got an awful lot to work in BL heli, but it was also assembly.
1 problem is the UART goes at 10khz while PWM goes at 32khz. The timing of the UART commands is much more coarse than what the L6234 was giving, but torque is higher. A test program which stepped it in the F330 at the PWM frequency didn't yield any increase in speed. It needed delays equivalent to the delays between UART characters. It's not practical to step it in the F330 because the timelapse mode requires direct control from the ARM.
Instead of calculating a step size when you have a motor driver on GPIOs, the maximum step between UART codes is always 1 & 10,000 steps can be sent per second. Speed has to be controlled by the delays between steps rather than the size of the steps.
After a few days of banging on microstepping, full stepping was giving better results with longer delays & a lot more torque. Either the interrupt handler or the transistor switching wasn't going fast enough for the microstepping to be smooth. Full stepping still wasn't as fast as the L6234 but it had a lot more torque.
The lion kingdom backed up the owSilProg archive since it seems to be the only general purpose F330 flasher & there's a chance of it disappearing. There are later F330 flashers which only support blheli firmware. Interest in programming RC microcontrollers completely evaporated after DJI took over the market. It shows how much interest was driven by a need to make money by selling quad copters rather than any interest in enhancing quad copters.
Ideally the servo firmware would be backed up, but the free programmers don't support reading. Usually, if something hasn't been used as long as these servos, it's never going to be used.
For writing custom firmware, there's the silabs IDE for windows.
This requires installing the Keil PK51 Developer’s Kit separately. The Keil didn't install from a network drive but did install from a local shared folder. Once installed, you have to change the assembler, compiler, & linker paths under project->toolchain integration. Then you have to select "generate hex file" in project->target build configuration. The hex generator is OH51.exe in the keil binary directory. Finally, you have to save the project to save the settings.
There were a bunch of retired brushless servos, 1st $60 ones & later $40 ones, all discontinued & in various states of disrepair. They could have great value in pointing cameras, but only with the more precise motion of stepper motors.
1 x SPT5835W used an unknown D1669 chip & 2 x TS-940-HG used the mighty Silabs F330.
Stepper mode servos have traditionally used external L6234's bypassing all the electronicals. Driving the motors with L6234's had problems with the high voltage required by the L6234, the extra space, the cooling required by the L6234, & the L6234 being discontinued. Ideally, their original microcontrollers would be reflashed with stepper motor firmware. They would read a code from the UART containing the states of the MOSFETs.
The SPT5835W was a lost cause. Maybe it used an ASIC or an unknown chinese brain. It might be possible to stuff another chip on a carrier board where the pot is, without increasing the size of the servo.
The TS-940-HG's will never be used as servos again because of glitches in their pots. The SPT5835W might be used as a servo again.