Quote:
|
Originally Posted by Tom Bottiglieri
I guess this depends on your application. If you only plan on changing one or two output values per communication cycle, you may want to send the 8 bit output value attached to an 4 bit ID number. You would only send the "new" data when it is needed, and the RC application would parse everything out and assign motors new output values.
For example...
If output #2 needs to change, your serial string could be: 02160N (where N is your Null termination key.)
If output #3 and #12 need to change, your string could be: 0312712254N (in this #3 is changed to 127 and #12 is changed to 254)
If nothing changes, just send a null.
|
It's far faster if the RC doesn't have to perform string parsing. (Kevin knows this, too; the first thing his code does is put the camera in raw mode.)
"03127\0" is six bytes (30 33 31 32 37 00h). "\x03\x7F" is 2 bytes (03 7Fh). You can use "\xFF\xFF" (FF FFh) for synchronization.
If you're worried about over-taxing the processor, stay away from strings.
Also, serial data doesn't have to be continuously streaming. If there's no change, you just don't transmit anything.
As for that big block to sort through the PWM selection, you can just use an array. If you look at tx_data_record in ifi_default.h, you'll see that all the PWMs are contiguous. So you can use this:
Code:
char* pwms = &pwm01; // pwm01 => txdata.rc_pwm01
// elsewhere...
pwms[port] = value;
Of course, if that doesn't work like I think it should (ie, the pointers are screwed up), you'll never know it except by strange, erratic, and just puzzling behavior. Use the dashboard during testing; if user byte 2 or user cmd are anything but 0, something's off.