From: Peter C. <pe...@pe...> - 2006-10-21 18:24:48
|
Hi chaps, I'm getting the following from sdcc when trying to compile some code, I assume this is a message passed from gplink to sdcc: error: no target memory available for section "code_autothermal" I'm currently using a 16f877. Anything I can do about this, apart from maybe going to a PIC with more memory? sdcc reports that --model-medium is not supported for pic14, which I suppose is logical as it has no external memory. Moving to pic18 would not be painful though I am not sure that they have more memory, either program or data (at least not the ones I have here, it seems smaller). It does not seem to be program memory as my PIC programmer software shows that I have used less than 50% memory. Not sure that I have too many variables. I can trim a few bits, but I feel I am sailing very close to the wind on the memory unless there is something I have missed. Pete |
From: Olgierd E. <ol...@te...> - 2006-10-21 21:06:38
|
Hi Pete, I think your problem may be to have a big variable, in the compiler model you can't have variables that use more than 256 bytes and this counts for arrays, for example you can't have: float array[65]; just because the whole array uses more than 256 bytes (a block) and I guess it can't be adressed internally with a 8 bits pointer. About the pic18F family, they have a max of 128kB of program memory (pic 18F8722) so I guess will have no problem to find a suitable one. Regards, Olgierd El s=E1b, 21-10-2006 a las 19:25 +0100, Peter Chant escribi=F3: > Hi chaps, >=20 > I'm getting the following from sdcc when trying to compile some code, I= =20 > assume this is a message passed from gplink to sdcc: >=20 > error: no target memory available for section "code_autothermal" >=20 > I'm currently using a 16f877. >=20 > Anything I can do about this, apart from maybe going to a PIC with more= =20 > memory? sdcc reports that --model-medium is not supported for pic= 14,=20 > which I suppose is logical as it has no external memory. Moving to pic= 18=20 > would not be painful though I am not sure that they have more memory,=20 > either program or data (at least not the ones I have here, it seems=20 > smaller). >=20 > It does not seem to be program memory as my PIC programmer software sho= ws=20 > that I have used less than 50% memory. Not sure that I have too many=20 > variables. >=20 > I can trim a few bits, but I feel I am sailing very close to the wind o= n=20 > the memory unless there is something I have missed. >=20 > Pete >=20 > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job = easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Peter C. <pe...@pe...> - 2006-10-22 10:25:25
|
On Saturday 21 October 2006 22:04, Olgierd Eysymontt wrote: > Hi Pete, > I think your problem may be to have a big variable, in the compiler > model you can't have variables that use more than 256 bytes and this > counts for arrays, for example you can't have: Nope, the largest is a buffer of 16 unsigned chars. I seem not to be using much programme memory and from gpsim it looks like I'm using less than 25% of the ram. |
From: Raphael N. <rn...@we...> - 2006-10-22 11:26:26
|
Hi Pete, > > I think your problem may be to have a big variable, in the compiler > > model you can't have variables that use more than 256 bytes and this > > counts for arrays, for example you can't have: > > Nope, the largest is a buffer of 16 unsigned chars. > > I seem not to be using much programme memory and from gpsim it looks like > I'm using less than 25% of the ram. Your message is about code_autothermal, which is the segment containing all code (plus strings) from autothermal.c, so your autothermal.c is too large. Background: According to gplink's 16f877.lkr, the 16f877 has four banks for code, (nearly) each 0x800 bytes, equalling 2k---which is wrong, as the device has 12k program memory, but still... Probably gplink tries to map code sections to banks, which fails for your code. If you went and split yout file into smaller pieces, gplink could fill up the banks with code from different sections. !!! Beware, splitting your code will introduce additional PAGESEL instructions around inter-file function calls. HTH, Raphael |
From: Peter C. <pe...@pe...> - 2006-10-23 00:01:47
|
On Sunday 22 October 2006 12:22, Raphael Neider wrote: > Probably gplink tries to map code sections to banks, which fails for > your code. If you went and split yout file into smaller pieces, gplink > could fill up the banks with code from different sections. > !!! Beware, splitting your code will introduce additional PAGESEL > instructions around inter-file function calls. BINGO! That did it. Made my code an order of magnitude more complex as well which will probally force me into good habits, but it did the job. Thanks. |
From: Raphael N. <rn...@we...> - 2006-10-22 11:36:40
|
> Your message is about code_autothermal, which is the segment containing > all code (plus strings) from autothermal.c, so your autothermal.c is too > large. > Background: According to gplink's 16f877.lkr, the 16f877 has four banks > for code, (nearly) each 0x800 bytes, equalling 2k---which is wrong, as > the device has 12k program memory, but still... > Probably gplink tries to map code sections to banks, which fails for > your code. If you went and split yout file into smaller pieces, gplink > could fill up the banks with code from different sections. > !!! Beware, splitting your code will introduce additional PAGESEL > instructions around inter-file function calls. Got another idea: Your project total might exceed the 8k assumed by gplink. So you might want to patch the linker script, adding two more CODEBANKs to fully use your device. IFF this turns out to be a bug in the linker scripts, you should also file a bug report with gputils... Regards, Raphael |
From: Peter C. <pe...@pe...> - 2006-10-22 17:56:53
|
On Sunday 22 October 2006 12:34, Raphael Neider wrote: >Got another idea: Your project total might exceed the 8k assumed by > gplink. So you might want to patch the linker script, adding two more > CODEBANKs to fully use your device. IFF this turns out to be a bug in >the linker scripts, you should also file a bug report with gputils... Looking at the relevent bit of the linker script 16f877.lkr and cross checking with the 16f877 data sheet it already includes all four codepages (gplink-0.13.3 alpha): CODEPAGE NAME=vectors START=0x0 END=0x4 PROTECTED CODEPAGE NAME=page0 START=0x5 END=0x7FF CODEPAGE NAME=page1 START=0x800 END=0xFFF CODEPAGE NAME=page2 START=0x1000 END=0x17FF CODEPAGE NAME=page3 START=0x1800 END=0x1FFF CODEPAGE NAME=.idlocs START=0x2000 END=0x2003 PROTECTED CODEPAGE NAME=.config START=0x2007 END=0x2007 PROTECTED CODEPAGE NAME=eedata START=0x2100 END=0x21FF PROTECTED So, unless I am wrong (frequently with PIC stuff) that is not the problem. Not tried the other trick yet. Pete |