TcPacketBase bug and improvement #81
Some improvements and possible bugx i found when coding the tc injector, which packs telecommands in the software and sends them to a packet distributor (the tc injector is propably a viable framework feature too, might add that in separate pull request..):
An additional function to set data and data length at once would be nice.
Also, calculating the full packet size with a given application data size before initializing it allows storing telecommands directly into the TC store by using getFreeElement(), so a function for that purpose would be helpful.
I also think there is a bug in the tcPacketBase::initializeTcPacket()
function. The length field should be set to the actual length minus 1, the minus 1 is missing.
I think, i have found that bug before. But I don't see the issue right now :-O I'm getting old.
The second point is actually done by TcPacketStored, which I completely missed. But i guess a static member function would still be nice..
I made a convencience API change for TcPacketStored:
ACK now has a default value of 1111 (ACK_FULL). I think this will be used in 99% of all cases anyway (right?..)
New order: service, subservice, APID, SSQ, data, size, ACK
Ok. if anything it makes it more clear that ACK isnt a boolean value, by hinting to the custom defined types (ACK_FULL, ACK_STEP...).
Also, memcpy is performed by the setAppData / setSourceData functions now to copy the supplied data. In its current form, the TcPacketBase and TmPacketBase are difficult to use in their own as soon as application and source data come into play. the addition of a few custom helper functions would help to decouple and simplify usage without needing Tc/TmPacketStored. However, maybe range checks should be performed then.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?