[Ovmsdev] Coding in vehicle_twizy - Memory section issue

[Michael Balzer]

Hi Julien,

both ROM and RAM space are very tight now. To my knowlede disabling some 
unneeded modules or code is the only real cure if you really need the 
space, only some specific space issues can now be resolved manually.

Generally, a look at the C18 user guide and the Microchip forum is 
always worth while.

The "cannot fit" error need not be related to a ROM space issue, it 
depends on the section type. "idata" is meant for initialized variables, 
i.e. global and static variables with a compile time constant init 
value. This needs additional memory and can mostly be avoided by using 
an efficient init function and proper coding.

"udata" is for uninitialized globals and statics -- the compiler may 
switch the section itself if you mix initialized with uninitialized 
vars, take care to avoid that.

Normally a section can only hold up to 256 bytes, so you also need to 
take care about the size of your variables and arrange them manually 
into sections with remaining capacity -- the compiler will not optimize 
section layout by itself. That's the reason I noted all RAM struct 
usages in the comments and used two different sections already.

Function parameters are placed on the software stack, which is by 
default a fixed bank of 256 bytes. The stack does not overlay with data 
sections, so that should not be the source of problems unless you nest 
calls too deeply.

Another fixed section "tmpdata" is used for intermediate storage, this 
is stressed by complex calculations, and the compiler does not optimize 
these very well. So you may be better off breaking complex calculations 
down and using vars to keep intermediate results.

You may give the C18 "overlay" storage class and the currently unused 
optimizer options a try.

Good luck & tell us if you find a solution.

Regards,
Michael


Am 08.01.2015 um 17:28 schrieb Julien NOZAIS:
> Hi everybody, best wishes for 2015.
>
> I came across a memory limit while working on my project, I hope you 
> could help me with it.
> I am working on the vehicle_twizy.c file. So far I added about 300 
> lines of running code, and I started getting the compilation error 
> "can not fit the section", which in general appears when you have too 
> many modules enabled while compiling.
>
>     Error - section '.idata_net.o_i' can not fit the section. Section 
> '.idata_net.o_i' length=0x00000035
>
> I identified that the memory issue is happening as I add more code, 
> and disappearing when I comment the code, independently of the nature 
> of the code. I first resorted to switching to less memory intensive 
> variables such as INT8.
>
> I then tried to put as many of my variables as I could in a separate 
> memory section. I used a pragma directive in the same fashion that is 
> used for the battery monitoring system extension.
>
>   #pragma udata overlay vehicle_overlay_data2
>
> It helped for a while, but at some point as I was writing calls to the 
> writesdo(..) function a few times, it started again. I guess 
> writesdo's arguments are stored in a memory section that was already 
> at almost full capacity. I thought there would have been some margin 
> before running into this kind of memory problem.
>
> For now my workaround is to remove the battery monitoring from the 
> compilation, as it leaves enough space for my code to run.
>
> Do you have any comments or ideas on this ?
>
> Best regards,
>
> Julien
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20150108/e529149a/attachment.htm>
-------------- 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/20150108/e529149a/attachment-0002.vcf>