• AVR Freaks

Hot!"Format" of the "cinit table" (solved)

Author
toms
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2006/03/07 18:06:24
  • Location: London, UK
  • Status: offline
2020/01/23 02:31:46 (permalink)
0

"Format" of the "cinit table" (solved)

Hi everyone, Ive been doing a bit of searching about this, but havent yet managed to find a suitable answer so far.
 
I decided to give myself a little challenge to write some code for a PIC16F886 for a little project - its basically a PIC connected to an RTC that turns a relay on and off at certain times of the day to connect/disconnect a battery from a charger.
 
Anyway, Im using some idata/udata_shr sections, and as I learned, you need to write/include some code to actually initialise the idata sections. The compiler or linker, which ever, includes some "tables" at the start of program memory to describe how many sections need initialising and their start/end addresses etc. But I cant work out how this information maps to my application.
 
The table generated is:
 
0x02
0x00
0x03
0x00
0x26
0x00
0x01
0x00
0x78
0x00
0x23
0x00
0x02
0x00
 
Which to me, based on a description I found in an example included with mpasm says:
 
There are 2 idata sections
The first starts at 0x0003, ends at 0x0026 and is 0x0001 words long
The second starts at 0x0078, ends at 0x0023 (????) and is 0x0002 words long
 
Or something close to that effect (Ive had to sleep on it, so going by slightly hazy memory now that Im at work).
 
The problem is, my variables are only using the memory range idata 0x20-0x26 and udata_shr 0x70-0x75, and I cant for the life of me figure out how the above table relates to those two memory ranges (although as I understand it, udata_shrt should not appear in that table). And if the first starts at memory address 0x03, its going to effectively initialise a whole bunch of SFRs?
 
Hoping someone can tell me what is that I simply dont understand about this? Or do I understand it correctly and something is just broken with the implementation?
 
Thanks!
Tom
post edited by toms - 2020/01/23 14:52:09
#1

3 Replies Related Threads

    1and0
    Access is Denied
    • Total Posts : 10299
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: "Format" of the "cinit table" 2020/01/23 02:40:58 (permalink)
    0
    Using IDATA is more trouble than its worth. I suggest you to initialize your variables in your initialization code before the main loop.
    #2
    toms
    Starting Member
    • Total Posts : 78
    • Reward points : 0
    • Joined: 2006/03/07 18:06:24
    • Location: London, UK
    • Status: offline
    Re: "Format" of the "cinit table" 2020/01/23 13:42:27 (permalink)
    0
    Ive figured it out!
     
    A fresh mind always helps. I made a new project with a couple of IDATA sections with really obvious values and Ive determined the following:
     
    The first two words describe the number of IDATA sections to initialise.
     
    After that and beginning a table entry, two words are the start address in ROM where the data for that section starts and should be copied from.
     
    The next two words are the start address in RAM where the data should be copied to.
     
    And the final two words are the number of bytes that will be initialised.
     
    The example in the included idasm16.asm file seemed a bit ambiguous at first, but looking at it again now it is making a lot more sense. I guess trying to read into something late at night when you should probably be in bed is not the greatest idea. LoL: LoL
     
    And with that, Im going to soldier on with trying to use IDATA and see if I can bend it to my will. Smile: Smile
    #3
    toms
    Starting Member
    • Total Posts : 78
    • Reward points : 0
    • Joined: 2006/03/07 18:06:24
    • Location: London, UK
    • Status: offline
    Re: "Format" of the "cinit table" 2020/01/23 14:46:48 (permalink)
    0
    I think the thing that was throwing me off was, for example, an address of 0x03. But what Ive discovered after digging into it more is that it is just squeezing RETLWs where ever they will fit, and for one section which had only one initialised byte, it just happened to squeeze it in after the reset vector. All making perfect sense now - as usual, its not a bug, I just didnt understand it well enough. ;-)
    #4
    Jump to:
    © 2020 APG vNext Commercial Version 4.5