<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Julien,<br>
    <br>
    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.<br>
    <br>
    Generally, a look at the C18 user guide and the Microchip forum is
    always worth while.<br>
    <br>
    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.<br>
    <br>
    "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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    You may give the C18 "overlay" storage class and the currently
    unused optimizer options a try.<br>
    <br>
    Good luck & tell us if you find a solution.<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 08.01.2015 um 17:28 schrieb Julien
      NOZAIS:<br>
    </div>
    <blockquote
      cite="mid:751077C3D22CF442998DE2411473493391A57A@trip.uni.lux"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
      <div style="direction: ltr;font-family: Tahoma;color:
        #000000;font-size: 10pt;">Hi everybody, best wishes for 2015.<br>
        <br>
        I came across a memory limit while working on my project, I hope
        you could help me with it.
        <br>
        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.<br>
        <br>
        <font face="Courier New">    Error - section '.idata_net.o_i'
          can not fit the section. Section '.idata_net.o_i'
          length=0x00000035</font><br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
          <font face="Courier New">  #pragma udata overlay
          vehicle_overlay_data2</font><br>
        <br>
        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.<br>
        <br>
        For now my workaround is to remove the battery monitoring from
        the compilation, as it leaves enough space for my code to run.<br>
        <br>
        Do you have any comments or ideas on this ?<br>
        <br>
        Best regards,<br>
        <br>
        Julien<br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>