[Ovmsdev] RAM

[Michael Balzer]

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 at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121204/1f32aad4/attachment-0002.vcf>