Quote:
|
Originally Posted by 6600gt
How demanding are serial port interrupts and communication in general on the RC?
|
From experience on my team, the interrupts are more "interrupting" than you may think. Last season we ran a serial LCD screen on the robot. Between this, multiple encoder interrupts (@ 128ppr), timer based interrupts for analog sensors, and a decent sized application, we managed to crash the RC a few times, via IFI's master processor's watch dog timer. We then added a switch to disable the LCD during matches, which stopped the crashing all together. I know this wasn't the most scientific of methods to find the real problem, but the crashes stopped after we shut down all serial communication.
Quote:
|
Originally Posted by 6600gt
Which one is more efficient and less demanding on the RC?
|
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.