[Ovmsdev] Stack sizes

[HONDA S-2000]

Steve,

In the context of stack sizes - especially having to change them repeatedly during development - static allocation is a decent option, with the usual caveats. But, yes, when you’re running out of onboard RAM - something that is quite common in embedded systems - static allocation could cause more problems than it might solve. One thing about static allocation that sometimes helps is that the memory can be shared, reducing the total footprint, although that rules out recursive and sometimes even concurrent execution.

At any rate, I figured that static allocation was already being considered, where appropriate.

Brian


On Jan 12, 2018, at 3:06 PM, Stephen Casner <casner at acm.org> wrote:
> Brian,
> 
> Moving something from dynamic allocation to static allocation does not
> help because they both come from the same RAM.  In fact, static
> allocation makes sure that the space is always consumed, whereas
> if the space is dynamic allocated it may be possible to trade off at
> different times between different uses of the space.
> 
>                                                        -- Steve
> 
> On Fri, 12 Jan 2018, HONDA S-2000 wrote:
>> (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.