mark at webb-johnson.net
Tue Dec 4 13:19:59 HKT 2012
The RAM usage is concerning. I would not be comfortable below 256bytes. Apart from stack usage for function return addresses (requirements there depend on how deep we recurse / nest our calls), any local variables in a function are also on the stack.
Is this new memory usage and code wrapped in a #define (with a compile time constant to enable it)?
I think before we discussed giving the vehicle modules the ability to directly issue net_msg output (or hooks to allow them to hook in as necessary to supplement the default output). That seems like a good way to do this, to generate the messages directly from the vehicle module, rather than having to get it off the can bus, store it, then sent it later.
On 26 Nov, 2012, at 3:51 AM, Michael Balzer wrote:
> I have begun implementing my battery monitoring as mentioned earlier, and it consumes a lot of RAM, as expected. I'm now down to 6% free RAM, or 193 bytes.
> Am I about to get into trouble with this? I.e. does the framework need some dynamic memory, or can we theoretically use the entire remaining RAM for vehicle stuff?
> As far as I understood the C18 docs right, the software stack will by default be limited to one bank, and all variables are fixed at compile time. So it seems we can use up all RAM?
> (Besides reserving some for future framework extensions of course...)
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
More information about the OvmsDev