From: Mika S. <mik...@wi...> - 2008-08-28 17:57:01
|
Hello, How to use malloc with PIC 18f4550 & sdcc ? I have been reading few info pages (http://www.btinternet.com/~Peter.Onion/sdcc/sdcc-intro.html) and have been trying to get the regression test malloc.c to compile without luck. I am using latest svn release of sdcc (28-Aug-2008). Thank you very much for help, -Mika Saari |
From: <mik...@wi...> - 2008-08-29 07:36:06
|
Hello again, > How to use malloc with PIC 18f4550 & sdcc ? I have been reading few > info pages (http://www.btinternet.com/~Peter.Onion/sdcc/sdcc-intro.html) > and have been trying to get the regression test malloc.c to compile > without luck. I am using latest svn release of sdcc (28-Aug-2008). > > Thank you very much for help, > -Mika Saari Managed to compile a sample code below with sdcc, but the xdata definition can not be found from header files (except from testfwk.h). What would be the correct way to introduce the heap ? Thank you again, -Mika Code I have been compiling: #include <pic16/pic18f4550.h> #include <stdio.h> #include <math.h> #include <malloc.h> #include <stdlib.h> #include <sdcc-lib.h> // xdata char heap[256]; This gives error of missing xdata data char heap[256]; // data char heap[512]; This gives linker error, do not know why int main() { float f1, f2; char *s1; s1 = (char *) malloc (100); f1 = 3.14; f2 = sqrtf(f1); sprintf(s1, "Float s1=%f and s2=%f", f1,f2); return 0; } |
From: Raphael N. <rn...@we...> - 2008-08-29 10:37:02
|
Hi Mika, > Managed to compile a sample code below with sdcc, but the xdata > definition can not be found from header files (except from testfwk.h). The PIC architectures do not offer anything like external data memory; so either just #define xdata __data or replace it (as you did). > What would be the correct way to introduce the heap ? > data char heap[256]; That looks pretty good, __data instead of data is safer, though. > // data char heap[512]; This gives linker error, do not know why The reason for the linker error is that the PIC organizes its memory in banks of 256 bytes each. You cannot declare structures/arrays larger than that unless you know what you are doing and modify the .lkr script (combine two adjacent banks (END address of first = START address of second - 1), i.e., turn DATABANK NAME=gpr1 START=0x100 END=0x1FF DATABANK NAME=gpr2 START=0x200 END=0x2FF into DATABANK NAME=gpr1 START=0x100 END=0x2FF Save the modified 18f4550.lkr in your project directory and add -Wl,-s,18f4550.lkr to sdcc's command line (or -s 18f4550.lkr to gplink's command line, depending on your build system/style) to use it. Make sure, though, that you *always* statically allocate the heap of at least 256 bytes if you do this, otherwise a random multi-byte entity (an int, a struct, ...) might be placed across the bank boundaries, which breaks compiler assumptions about BANKSEL placement and might cause accesses to the entity to fail (read/write in the wrong bank, good luck hunting such bugs!). Also, make sure to add #pragma stack 0x300 0x100 to your main() file to move the stack from its standard location (0x200-0x2FF) to 0x300-0x3FF. You might also reduce the stack size (0x100 => 256 bytes, 0x80 => 128 bytes *might* suffice, you could try). Note that using a 512 byte heap and a 256 byte stack leaves 'just' 160 byte of the 4550 available for other stuff. Hope that helped, Raphael |
From: <mik...@wi...> - 2008-08-29 11:16:40
|
Hi, Thank you very much. This really helped a lot :) -Mika > Hi Mika, > >> Managed to compile a sample code below with sdcc, but the xdata >> definition can not be found from header files (except from testfwk.h). > > The PIC architectures do not offer anything like external data memory; > so either just > #define xdata __data > or replace it (as you did). > >> What would be the correct way to introduce the heap ? >> data char heap[256]; > > That looks pretty good, __data instead of data is safer, though. > >> // data char heap[512]; This gives linker error, do not know why > > The reason for the linker error is that the PIC organizes its memory in > banks of 256 bytes each. You cannot declare structures/arrays larger > than that unless you know what you are doing and modify the .lkr script > (combine two adjacent banks (END address of first = START address of > second - 1), i.e., turn > > DATABANK NAME=gpr1 START=0x100 END=0x1FF > DATABANK NAME=gpr2 START=0x200 END=0x2FF > > into > > DATABANK NAME=gpr1 START=0x100 END=0x2FF > > Save the modified 18f4550.lkr in your project directory and add > -Wl,-s,18f4550.lkr to sdcc's command line (or -s 18f4550.lkr to gplink's > command line, depending on your build system/style) to use it. > > Make sure, though, that you *always* statically allocate the heap of at > least 256 bytes if you do this, otherwise a random multi-byte entity (an > int, a struct, ...) might be placed across the bank boundaries, which > breaks compiler assumptions about BANKSEL placement and might cause > accesses to the entity to fail (read/write in the wrong bank, good luck > hunting such bugs!). > > Also, make sure to add > #pragma stack 0x300 0x100 > to your main() file to move the stack from its standard location > (0x200-0x2FF) to 0x300-0x3FF. You might also reduce the stack size > (0x100 => 256 bytes, 0x80 => 128 bytes *might* suffice, you could try). > > Note that using a 512 byte heap and a 256 byte stack leaves 'just' 160 > byte of the 4550 available for other stuff. > > Hope that helped, > Raphael > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the > world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Maarten B. <sou...@ds...> - 2008-08-29 18:52:10
|
Mika, Using a heap in a small embedded device is usually regarded as unwise and not appreciating the limitations of small embedded devices. A microcontroller is no PC. SDCC supports some targets which can have 64k of ram or even more, but I've never heard of any PIC14 or PIC16 that can. I admit I know very little about the PICs so I might be wrong. But are you sure you want to use the heap in such a small device? Wouldn't you better use static allocation and save the code and memory costs of malloc and friends? Greetings, Maarten > Hi, > > Thank you very much. This really helped a lot :) > > -Mika > > > Hi Mika, > > > >> Managed to compile a sample code below with sdcc, but the xdata > >> definition can not be found from header files (except from testfwk.h). > > > > The PIC architectures do not offer anything like external data memory; > > so either just > > #define xdata __data > > or replace it (as you did). > > > >> What would be the correct way to introduce the heap ? > >> data char heap[256]; > > > > That looks pretty good, __data instead of data is safer, though. > > > >> // data char heap[512]; This gives linker error, do not know why > > > > The reason for the linker error is that the PIC organizes its memory in > > banks of 256 bytes each. You cannot declare structures/arrays larger > > than that unless you know what you are doing and modify the .lkr script > > (combine two adjacent banks (END address of first = START address of > > second - 1), i.e., turn > > > > DATABANK NAME=gpr1 START=0x100 END=0x1FF > > DATABANK NAME=gpr2 START=0x200 END=0x2FF > > > > into > > > > DATABANK NAME=gpr1 START=0x100 END=0x2FF > > > > Save the modified 18f4550.lkr in your project directory and add > > -Wl,-s,18f4550.lkr to sdcc's command line (or -s 18f4550.lkr to gplink's > > command line, depending on your build system/style) to use it. > > > > Make sure, though, that you *always* statically allocate the heap of at > > least 256 bytes if you do this, otherwise a random multi-byte entity (an > > int, a struct, ...) might be placed across the bank boundaries, which > > breaks compiler assumptions about BANKSEL placement and might cause > > accesses to the entity to fail (read/write in the wrong bank, good luck > > hunting such bugs!). > > > > Also, make sure to add > > #pragma stack 0x300 0x100 > > to your main() file to move the stack from its standard location > > (0x200-0x2FF) to 0x300-0x3FF. You might also reduce the stack size > > (0x100 => 256 bytes, 0x80 => 128 bytes *might* suffice, you could try). > > > > Note that using a 512 byte heap and a 256 byte stack leaves 'just' 160 > > byte of the 4550 available for other stuff. > > > > Hope that helped, > > Raphael |
From: Mika S. <mik...@wi...> - 2008-08-29 19:08:15
|
Hi, I am making tests and calculating inhex32 ascii and lst files to get idea how much rom and ram I am using So mainly testing at the moment. I think you are right about PIC16 and static memory allocation and I should be using that kind of approach. But just want to test what happens if using dynamic memory allocation. I am big SDCC newbie so need to test and study a lot pretty long time here :) Thanks for comments ! -Mika > Mika, > > Using a heap in a small embedded device is usually > regarded as unwise and not appreciating the limitations > of small embedded devices. A microcontroller is no PC. > > SDCC supports some targets which can have 64k of ram or > even more, but I've never heard of any PIC14 or PIC16 > that can. I admit I know very little about the PICs so I > might be wrong. > > But are you sure you want to use the heap in such a > small device? Wouldn't you better use static allocation > and save the code and memory costs of malloc and > friends? > > Greetings, > Maarten > > > Hi, > > > > Thank you very much. This really helped a lot :) > > > > -Mika > > > > > Hi Mika, > > > > > >> Managed to compile a sample code below with sdcc, but the xdata > > >> definition can not be found from header files (except from testfwk.h). > > > > > > The PIC architectures do not offer anything like external data memory; > > > so either just > > > #define xdata __data > > > or replace it (as you did). > > > > > >> What would be the correct way to introduce the heap ? > > >> data char heap[256]; > > > > > > That looks pretty good, __data instead of data is safer, though. > > > > > >> // data char heap[512]; This gives linker error, do not know why > > > > > > The reason for the linker error is that the PIC organizes its memory in > > > banks of 256 bytes each. You cannot declare structures/arrays larger > > > than that unless you know what you are doing and modify the .lkr script > > > (combine two adjacent banks (END address of first = START address of > > > second - 1), i.e., turn > > > > > > DATABANK NAME=gpr1 START=0x100 END=0x1FF > > > DATABANK NAME=gpr2 START=0x200 END=0x2FF > > > > > > into > > > > > > DATABANK NAME=gpr1 START=0x100 END=0x2FF > > > > > > Save the modified 18f4550.lkr in your project directory and add > > > -Wl,-s,18f4550.lkr to sdcc's command line (or -s 18f4550.lkr to gplink's > > > command line, depending on your build system/style) to use it. > > > > > > Make sure, though, that you *always* statically allocate the heap of at > > > least 256 bytes if you do this, otherwise a random multi-byte entity (an > > > int, a struct, ...) might be placed across the bank boundaries, which > > > breaks compiler assumptions about BANKSEL placement and might cause > > > accesses to the entity to fail (read/write in the wrong bank, good luck > > > hunting such bugs!). > > > > > > Also, make sure to add > > > #pragma stack 0x300 0x100 > > > to your main() file to move the stack from its standard location > > > (0x200-0x2FF) to 0x300-0x3FF. You might also reduce the stack size > > > (0x100 => 256 bytes, 0x80 => 128 bytes *might* suffice, you could try). > > > > > > Note that using a 512 byte heap and a 256 byte stack leaves 'just' 160 > > > byte of the 4550 available for other stuff. > > > > > > Hope that helped, > > > Raphael > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |