←back to thread

327 points AareyBaba | 1 comments | | HN request time: 0.27s | source
Show context
anonymousiam ◴[] No.46184727[source]
The same is true for the software that runs many satellites. Use of the STL is prohibited.

The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.

replies(7): >>46185566 #>>46187219 #>>46188652 #>>46189307 #>>46190613 #>>46191199 #>>46196185 #
coppsilgold ◴[] No.46187219[source]
> This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.

This seems like a rather manual way to go about things for which an automated solution can be devised. Such as create special ECC memory where you also account for entire cell failure with Reed-Solomon coding or some boot process which blacklists bad cells etc.

replies(1): >>46189186 #
j16sdiz ◴[] No.46189186[source]
It is more than that.

This is what make remote debugging possible. It is impossible to do interactive remote debugging over a ultra low bandwidth link. If everything have static address and deterministic static, you can have a exact copy on ground and debug there.

replies(2): >>46189748 #>>46195413 #
1. coppsilgold ◴[] No.46195413[source]
> If everything have static address and deterministic static, you can have a exact copy on ground and debug there.

You can also have deterministic dynamic - the satellite could transmit its dynamic state (a few bits signifying which memory cells failed) and then you proceed deterministically on the ground.