Mark, I'm confused now :-) PIC18F manual section 5.1.2 says: "The stack operates as a 31-word by 21-bit RAM and a 5-bit Stack Pointer, STKPTR. The stack space is not part of either program or data space." So I thought the call return address stack is a special area limited to 31 levels. C18 user guide section 3.2.4 says: "The stack is sized and placed via the linker script with the STACK directive. ... If a stack larger than 256 bytes is used, the -ls option must be given to the compiler." So I thought as there seems to be no -ls option or special linker script for the OVMS project, the software stack (arguments & locals) is currently fixed and limited to one bank of RAM (256 byte). What am I missing? Btw: I'm now down to 161 bytes "free", and besides the known GPRS connectivity problems, which also result in garbled text and complete modem lockouts sometimes, everything still seems to work. For the #ifdef wrap, I'll add that. Transmitting just the raw sensor data to the server will first need an App (or another client) that processes the data. I haven't yet looked into the android code and understood it's also not the actual source for the current App. I also like the idea of the car module being independant of the App where possible, being usable by SMS as well. For the net_msg output from the vehicle module, well... I'm doing that already... sorry if I wasn't meant to :-) The current Twizy module already transfers the "B" and "H" messages, using your diff mechanism during normal operation, and always (stat=0) for command responses and alerts. Server & App support would cut down storage need significally, but I would still need to first store at least the raw CAN values, as the CAN interrupt handler cannot send net data directly. And as the data stream should be able to use the diff scheme to keep traffic volume low, I still need static CRC variables for all messages. I think that already results in less than 256 bytes free, but I'll check it. Regards, Michael Am 04.12.2012 06:19, schrieb Mark Webb-Johnson:
Michael,
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.
Regards, Mark.
On 26 Nov, 2012, at 3:51 AM, Michael Balzer wrote:
Mark,
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...)
Thanks, Michael
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26