[Ovmsdev] Stack sizes

[HONDA S-2000]

(I realize that I’m commenting on an old thread)

Besides automatic (local variable) and dynamic allocation, there is also a third choice: static allocation. I assume that you’re already considering static allocation as an option since you mention getting rid of recursion, which is, of course, not typically compatible with static allocation.

I only mention this because I tend to use way more static allocation in embedded firmware design than is common for high-level software running on a full operating system platform.

Brian


On 6 Dec 2017, at 9:05 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 200 bytes, not 2,000 bytes, so something else is going on here. Anyway, changing it to a dynamically (new/delete) allocated buffer, drops stack usage of that frame to 1,824 bytes (was 2,208 so that is 384 bytes saved).
> 
> That uint8_t b[line.length()+1] in OvmsServerV2::ProcessServerMsg() is also nasty - it will grow stack usage depending on line length. So, we’ll fix that as well. 192 bytes -> 160 bytes.
> 
> Things to note:
> 
> 	• Each stack call is a minimum of 32 bytes. Not so bad, really - we’d need to nest calls 32 deep to get 1KB stack usage.
> 	• Local variables are scary. They can be unexpectedly large. Best to new/free them, to guarantee just 4 bytes each.
> 	• The OvmsCommand::Execute recursion I was worried about is not so bad. Probably 100 bytes of stack, or so, for most commands. We could improve that by getting rid of the recursion (it is elegant, but not strictly necessary), but it doesn’t seem to be a big win.
> 	• I’m still looking for 150+ bytes in OvmsServerV2::ProcessServerMsg(), and 1,900+ bytes in OvmsServerV2::ProcessCommand(). Those would be big.
> 
> Regards, Mark.