Hamburger wrote:how to deal with unused values in MSPs?For example:
Code: Select all
case MSP_RAW_IMU:
headSerialReply(18);
for(uint8_t i=0;i<3;i++) serialize16(accSmooth[i]);
for(uint8_t i=0;i<3;i++) serialize16(gyroData[i]);
for(uint8_t i=0;i<3;i++) serialize16(magADC[i]);
break;
when run without a magneto sensor, the variable magADC[] never contains anything useful; so it makes no sense to transmit it. I think it should not be transmitted and the length of the MSP would need adjustment. Is that ok?
Adjusting MSP length is something reasonable for servos of motors or boxes, or for optional variables at the end of a message (like rssi)
But adjusting MSP length for every messages is not always relevant.
Typically, MSP_RAW_IMU is here to transmit a generic 9DOF IMU output.
As an alternate route, it would be possible to transmit padding zeros. Kinda stupid, but it would preserve the length of the MSP.
you have to think also to GUI or OSD coders, they expect to have a value.
magADC[x] is 0 if not used.
If you short the length of this message as the GUI is hardcoded to read 3x3 values, some tail values would be read in the inbuf buffer with maybe garbage values.
The current implementation of such hard coded references in the MSPs to otherwise unused variables has the nasty side effect that such variables get compiled in and waste memory (and bandwidth for transmission).
So the question is:
how should MSPs handle such cases - either adjust the MSP length or use zero padding?
I prefer adjusting the length. What do you think?
Explicitly use zero padding would reduce a little bit the code size.
But I'm not in favor to isolate every variable for code readability.
I have something in mind for the next step, using structs in order to avoid memory variable duplications in serial and which should optimize the flash size much more than 0 padding strategy.
But for this, we have to reorganize some parts and move .ino in .h