[FEATURE] S Band Radio

[ineskhou]

Short summary

S Band Radio

Motivation and user story

S Band Radio

Proposed implementation

Radio

Priority

Medium

[ineskhou]

Relevant Risk: #122

[jrpear]

The problem with S band radio driver was that the stack overflowed its allocated 4096 byte region when the driver passed the received packet along after obtaining it from the radio.

These are the paths I see to fit in the S band radio driver:

1. allocate more space for S band radio driver stack
2. reduce stack usage of functions in the above backtrace
3. avoid this call sequence altogether (by making one of the ports in the chain async)

Option 1 would be the easiest solution. Although I recall that when I increased the allocated stack size even a bit, the system would not boot. So probably memory usage would have to be reduced in other areas to allow this increase. Not nice.

Option 2 requires significant care and effort, but it is the most realistic solution here.

Option 3 would be an alright solution if one of the components in the call sequence is already active. Although it doesn't seem "nice" to me.

We probably will wind up doing option 2 or a mix of options 1 & 2.

In the above backtrace, the only stack frame which is non-framework S band driver code is deferredRxHandler, using 408 bytes. I believe I can eliminate 256 of that. All the stack frames above that (or, below in the image) are unavoidable framework overhead. The stack frames below that (or, above in the image) are a call chain triggered by the dataOut_out call.

Ideally, we would have some sort of instrumentation that could give us access to memory usage data easily. Easier than mucking about with a debugger. Ideally ideally, we would have a static code analysis tool that forbids code that has any path that uses more than the allocated stack space.

[jrpear]

Re: static code analysis tool, this sort of thing exists, e.g. StackAnalyzer from absint. Although it's not free.

Probably could hack something together out of OSS, which would actually be really cool to work on. This blog post would be a solid starting point.

Although indirect/virtual function calls could be a very large problem.