From: Kustaa N. <Kus...@pl...> - 2009-02-25 11:11:30
|
Hi, are there any issues I should now about if I use an array larger than one page (256) bytes on PIC18F4550? Specifically this is an array of four structs. Each struct is about 70 bytes so this will slightly 'overflow' one page. The seemst of compile but I've not yet had the opportunity to test it. br Kusti |
From: Gaye A. W. <wal...@wa...> - 2009-02-25 20:05:37
|
Kustaa Nyholm wrote: > Hi, > > are there any issues I should now about if I use an array larger than one > page (256) bytes on PIC18F4550? Specifically this is an array of four > structs. Each struct is about 70 bytes so this will slightly 'overflow' > one page. The seemst of compile but I've not yet had the opportunity to test > it. > > br Kusti > > Hi, you are probably looking for something like this: http://www.mail-archive.com/sdc...@li.../msg01557.html Rgards |
From: Kustaa N. <Kus...@pl...> - 2009-02-25 20:13:22
|
Thanks, Yes, this is sort of what I was looking for, but this did not completely answer the question. My array is not malloc'ated but is a global variable. I've not changed the default linker script and the compiler and linker seem to be happy. This sort of matches what was described in the thread you indicated but not quite. A word from the developer of PIC16 port would be appreciated. br Kusti ________________________________________ From: Gaye Abdoulaye Walsimou [wal...@wa...] Sent: Wednesday, February 25, 2009 10:05 PM To: sdc...@li... Subject: Re: [Sdcc-user] Larger than 256 byte arrays in PIC16 Kustaa Nyholm wrote: > Hi, > > are there any issues I should now about if I use an array larger than one > page (256) bytes on PIC18F4550? Specifically this is an array of four > structs. Each struct is about 70 bytes so this will slightly 'overflow' > one page. The seemst of compile but I've not yet had the opportunity to test > it. > > br Kusti > > Hi, you are probably looking for something like this: http://www.mail-archive.com/sdc...@li.../msg01557.html Rgards ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Sdcc-user mailing list Sdc...@li... https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Raphael N. <rn...@we...> - 2009-02-25 23:27:27
|
Hi Kustaa, > Yes, this is sort of what I was looking for, but this did not completely > answer the question. > > My array is not malloc'ated but is a global variable. I've not changed > the default linker script and the compiler and linker seem to be happy. This is strange: The attached source should not (and does not for me) link using the default linker script: The array largish[30] of 30 elements of an 11-byte struct consumes 330 byte of memory---no DATABANK is large enough. The linker yields warning: relocation of section "udata_larray_0" failed, relocating to a shared memory location error: linker script has no definition that matches the type of section "udata_larray_0" If you use a modified linker script (see attachment), to compile/link the attached larray.c with --obanksel=9 given, you can observe two properties (see edited .lst excerpt): 1. Array accesses with variable index (largish[u].key = u) will work correctly (they use FSR0L/H with correct 16-bit arithmetics applied). Whenever the array index is truely unknown at compile time (and cannot be inferred by the compiler), you should be safe. 2. If the array index is a literal (largish[23].key = 0x44332211), the generated code will lack BANKSEL directives when accessing multi-byte entities that cross bank boundaries (.key is a 4 byte unsigned long starting at address 0x2FD (253 bytes after the first byte of largish) and runs on up to and including 0x300 (in the next bank). The banksel instructions for all but the LSB of .key are optimized away, leading to the code writing the MSB to 0x200 instead of 0x300. The same problem will occur even when accessing a different field/different index of the array (element)---all subsequent banksels to the symbol "largish" will be removed, due to the assumption that each symbol completely fits into a single bank. If you can *guarantee* that all array accesses happed with a variable index (e.g., by using accessor methods in a separate .c/.o file to prevent inlining), you *might* try to do this. I would reconsider my data structures and try to split the struct or the array to avoid this problem in the first place. Alternatively (but still only true by chance --- which might change) you can leave out --obanksel and live with all the potentially required BANKSELs scattered throughout the code. > This sort of matches what was described in the thread you indicated > but not quite. A word from the developer of PIC16 port would be > appreciated. Hope that clears things up a bit, Raphael |
From: Kustaa N. <Kus...@pl...> - 2009-02-26 18:11:27
|
Hi Raphael, thanks for a very thorough treatment of the topic! Just what I was looking for. And yes, you are correct the code does not link with the standard linker script if I make my array larger than 256, my mistake. All in all, I think it is safer to conserve some memory and keep the array all on one page. Thank you once more. br Kusti ________________________________________ From: Raphael Neider [rn...@we...] Sent: Thursday, February 26, 2009 12:25 AM To: sdc...@li... Subject: Re: [Sdcc-user] Larger than 256 byte arrays in PIC16 Hi Kustaa, > Yes, this is sort of what I was looking for, but this did not completely > answer the question. > > My array is not malloc'ated but is a global variable. I've not changed > the default linker script and the compiler and linker seem to be happy. This is strange: The attached source should not (and does not for me) link using the default linker script: The array largish[30] of 30 elements of an 11-byte struct consumes 330 byte of memory---no DATABANK is large enough. The linker yields warning: relocation of section "udata_larray_0" failed, relocating to a shared memory location error: linker script has no definition that matches the type of section "udata_larray_0" If you use a modified linker script (see attachment), to compile/link the attached larray.c with --obanksel=9 given, you can observe two properties (see edited .lst excerpt): 1. Array accesses with variable index (largish[u].key = u) will work correctly (they use FSR0L/H with correct 16-bit arithmetics applied). Whenever the array index is truely unknown at compile time (and cannot be inferred by the compiler), you should be safe. 2. If the array index is a literal (largish[23].key = 0x44332211), the generated code will lack BANKSEL directives when accessing multi-byte entities that cross bank boundaries (.key is a 4 byte unsigned long starting at address 0x2FD (253 bytes after the first byte of largish) and runs on up to and including 0x300 (in the next bank). The banksel instructions for all but the LSB of .key are optimized away, leading to the code writing the MSB to 0x200 instead of 0x300. The same problem will occur even when accessing a different field/different index of the array (element)---all subsequent banksels to the symbol "largish" will be removed, due to the assumption that each symbol completely fits into a single bank. If you can *guarantee* that all array accesses happed with a variable index (e.g., by using accessor methods in a separate .c/.o file to prevent inlining), you *might* try to do this. I would reconsider my data structures and try to split the struct or the array to avoid this problem in the first place. Alternatively (but still only true by chance --- which might change) you can leave out --obanksel and live with all the potentially required BANKSELs scattered throughout the code. > This sort of matches what was described in the thread you indicated > but not quite. A word from the developer of PIC16 port would be > appreciated. Hope that clears things up a bit, Raphael |