Convert a brushless servo into a stepper motor

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.

Final view of the programming pin positions.

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 SIL F330 is the same brain used on the Turnigy plush ESC's.  It uses the C2 interface for programming.

https://www.silabs.com/documents/public/application-notes/AN127.pdf

Commercial C2 programmers rival the cost of a better motor driver.

There is a C2 programmer for arduino that was intended to reprogram Turnigy ESC's.

http://www.olliw.eu/2012/owsilprog/?en

There's no source code & it's for windows only.  

There's diagram for connecting the F330 to the arduino.  

The programming software is buried in this link:

http://www.olliw.eu/2012/owsilprog/#firmware

Newer F330 tools have been written & are focused on just supporting blheli while the original owSilProg continues to work on Windows 10 & support any hex file.

The next step is to write the C2 programmer to the arduino.

There are a bunch of owSilProg files in the zip file, 1 of which must be written to the arduino.   The lion kingdom managed to flash the arduino with the avrburntool like this.

Then you can run blhelitool & specify any hex file you want in the hex file field.

https://drive.google.com/file/d/1bKCg5ScDbcDfRND4LSNZqrGYF8x7UkYl/view?usp=sharing

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.

https://www.silabs.com/developers/8-bit-8051-microcontroller-software-studio

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.

The BLheli source code for the SIL F330 is

https://github.com/bitdump/BLHeli/blob/master/SiLabs/Turnigy_Plush_6A.inc

https://github.com/bitdump/BLHeli/blob/master/SiLabs/BLHeli.asm

It's all assembly language.

The lion kingdom just copied the silabs/mcu/examples/c8051f330_5/blinky project as a starting point.

The blinky project has a C & ASM version.  The C version uses an interrupt while the ASM version uses an infinite loop.

Like other Keil compilers, the free 8051 C compiler is restricted to 0x800 bytes.

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.