link static files

[sheershak-agarwal]

Hello,

I am wondering about the most efficient way to do fprime file updates. In future updates we will be making gradual changes through components rather than the whole design. I see in the lib folder in build-artifacts that have some .a or static libraries for each component used. Does the cmake files allow us to compile/link the updated .a files? The .a files are of a decent size and we can uplink one static library in one ground pass.

Thanks in advance

[LeStarch]

If this is on the ground, then CMake will only compile changed modules and not touch the others. If you are talking updating individual components "in flight" that is a much harder problem.

[sheershak-agarwal]

Alright, Thank you

[Joshua-Anderson]

If your primary concern is limiting filesize of updates one approach to consider is binary diff patches.

You can make changes to the flight software and rebuild, then create a binary diff between the onboard version and the new release.
This is often simpler than trying to break flight software into independently updatable modules while minimizing the amount of data that has to be uplinked for the update.

[sheershak-agarwal]

that's an interesting idea but would involve a lot of edge case testing before bringing it to production. Also, in version 1.5.3 I have often seen executable more than 5-7 MB for a few components but since fprime 2.0, the size of exe was significantly reduced. Did you guys notice it as well?

[sheershak-agarwal]

I have another random question about GDS. I looked into the FRAMER and deframer code and saw that GDS is creating a seperate message for each telemetry channel. Am I right about this? If yes, Is there a way to create maybe one long message with all the channel or only the updated channels? I will have to edit the code but what do think the easiest way for that will be?
Thanks in advance.

[LeStarch]

@timcanham is working on a telemetry packetizer for this purpose. It wouldn't solve the event-single-packet problem, but most of the time it is voluminous telemetry that is the problem.

[timcanham]

We should update Svc/TlmChan to put as many updated channels in the ComBuffer as will fit. The Svc/TlmChan part is relatively straightforward, but the GDS would have to be updated to walk through all the channels instead of just one. It's very inefficient in its current form. I though there was an issue for this, but there is now: #1204

[timcanham]

BTW, Svc/TlmChan currently only sends updated channels, so that part is good.

[sheershak-agarwal]

That's awesome. Few more questions. "as will fit" means there would be a max size of the ComBuffer?
Also if I need to add the feature create one packet for Tlm then I should edit this section in

fprime/Svc/TlmChan/TlmChanImplTask.cpp

Line 42 in 3b271e2

for (U32 entry = 0; entry < TLMCHAN_HASH_BUCKETS; entry++) {

Call the PktSend after the the for loop, but I need to add something in middle to find the start of next channel. I don't think the tlm will be the same size. Also I couldn't find where to make the gds change. maybe here https://github.com/fprime-community/fprime-gds/blob/352594784f14b5bfe0472777645ce2ca6a2d4626/src/fprime_gds/flask/channels.py#L54

[timcanham]

For

fprime/Svc/TlmChan/TlmChanImplTask.cpp

Line 42 in 3b271e2

for (U32 entry = 0; entry < TLMCHAN_HASH_BUCKETS; entry++) {

, you have the right idea. Instead of sending a ComBuffer each time in that loop, you add the channel to a ComBuffer that is accumulating data. Once the ComBuffer is full (test the serialize return value), send it and clear the ComBuffer. Rinse and repeat until all the updated channels are sent.