RC Servo decoding/encoding using 12F683

[rmteo]

Ah, now I see what you are trying to do - like what the multi-rotor guys would want. I did a similar application using a PIC24FJ32GA104 which has 5 independent input capture modules and 5 independent output compare/PWM modules. Most everything done in hardware (except for the intermediate computations) and fully interrupt driven. Vectored interrupts sure came in handy in this situation.

[ScaleRobotics]

like what the multi-rotor guys would want.

Yes! Add multi rotor motor conrol to the list, (as well as single rotor). Yes, for the last three links, you might have to upgrade up to a PIC16, or maybe even a PIC18. But I thought I would get an example out using one of the smallest chips supported by PBP to get peoples imaginations going. If the 12f683 can breeze through this, think what a 40mhz chip ( and a little of your imagination and a little of your code) can do. Something very similar was done 8 years ago, see link two. He added a lot of neat features. Too bad I didn't see it 8 years ago, I could have used that......

Only, with this code, you can put your own PBP code into it.

Here are a couple examples of things which perform servo encoding and decoding, with a "little" math in between, ok, and in some cases a "little" extra hardware. There is a lot more than this out there though....

http://www.servocity.com/html/servo_mixer.html Mixer for RC
http://homepages.paradise.net.nz/bhabbott/decoder.html Giving smarts to a dumb receiver
http://rcpilot.sourceforge.net/modules/rcap/index.php A rudder controlling autopilot using a PIC16F876
http://www.u-nav.com/circuitboards/alt3.html An altitude hold device
http://www.fmadirect.com/products.htm?cat=75&nid=6 A very smart receiver stablilizing device .. and more.
http://www.sparkfun.com/commerce/pro...oducts_id=9038 UAV autopilot based on a dsPIC30F4011 (ok a "little" faster than a 12F)
http://www.sparkfun.com/commerce/pro...oducts_id=8785 UAV autopilot based on Arduino chip

[rmteo]

I prefer to do everything in hardware where possible. Hardware is cheap (the same cannot be said for software - the abovementioned PIC24 is <$2) and will outperform anything that can be done in software. For example, on the PIC24FJ the built-in hardware multiplier will do a 17x17 multiply in a single instruction cycle - 62.5nS with a 32MHz clock. Compare this to a PIC12/16 (with a 4MHz clock) which needs about 250uS to do a 16x16 multiply operation - about 4,000 times slower.

Right now I'm working a flybarless controller which needs to take inputs from a receiver, inputs from 3 axis accelerometers, do the necessary math intensive (mostly word) computations, then output pulses to the CCPM servos. The pulses should be output concurrently and this is where the hardware PWM becomes really important.

[ScaleRobotics]

the abovementioned PIC24 is <$2) and will outperform anything that can be done in software.

Agreed, that is a very fast chip, but I always get an error programing PIC24F's with PBP code.

The PIC18 devices have a hardware multiplier, so that is ultimately where I am going with this. The pulse width is being sensed with a CCP1 capture, which is hardware. But the 12F needs a tiny bit of assembly to control that hardware. The PIC18F2431 has more hardware that lends itself better (than the 12F and 16F) to that sort of thing.

Right now I'm working a flybarless controller which needs to take inputs from a receiver, inputs from 3 axis accelerometers, do the necessary math intensive (mostly word) computations, then output pulses to the CCPM servos. The pulses should be output concurrently and this is where the hardware PWM becomes really important.

I really don't know what flybarless is vs flybraless, but seriously, that sounds very cool! I would love to see your code for that, and I am sure others would as well.

But with RC working at 50 hertz, how quick do you REALLY need the chip to be? That is a lot of time to do some math, at least for most applications.

[rmteo]

The nice thing about working in hardware is that coding is pretty straightforward - and not terribly exciting to see. It is usually a case of setting up registers to do what you want. Most compilers usually do this pretty efficiently anyway.

Why work with a less capable device when the only advantage may a slightly lower cost (perhaps less than a $1 difference). The higher end devices are far easier to use, have greatly superior performance/features - what's not to like.

BTW, the PIC18 has an 8x8 hardware multiplier (the PIC24's is 17x17). Even with a 40MHz clock, the PIC18 requires 4.0uS to perform a signed 16x16 multiply - the PIC24 with a 32MHz clock is still 64 times faster needing only 62.5nS.

[ScaleRobotics]

rmteo,

I agree with you. The PIC24's are definitely better than PIC18's. I don't hold anything against them. I just enjoy PBP better than my CCS compiler. And I think I can perform the math functions I need, including atan, cos, sin and hypotenuse (using a cordic equation), plus all the multiplication and division I need in the 20ms between RC frames. Once I start performing equations that exceed 20ms, I will certainly have to switch compilers! But maybe by then, MeLabs will support PIC24 devices.

[Squibcakes]

Right now I'm working a flybarless controller which needs to take inputs from a receiver, inputs from 3 axis accelerometers, do the necessary math intensive (mostly word) computations, then output pulses to the CCPM servos. The pulses should be output concurrently and this is where the hardware PWM becomes really important.

Ambitious. How is it coming along?

I have a 4 blade scaley with no stabilisation and wouldn't mind adding a gyro on the pitch axis... but this would require some tricky eccpm mixing similar to what you describe above....