From: Rodrigo G. <tio...@gm...> - 2007-01-14 08:17:30
|
Hello all, First of all thanks and congratulations for providing us all such capable open source compiler for small devices. I experienced some strange behavior when trying to assign values to dereferenced pointers in my programs. I decided to post here since I could not find similar messages in the lists, forums, bug reports, Changelog, etc. My apologies if this regards to some previously solved /reported problem (or problem with my code). Here follows the relevant code: void main(void) { unsigned char c = 0x34; unsigned char *p; p = &c; p = 0x12; (...) There is no error messages when compiling but if I test *p after the last line of code above it seems to be neither 0x12 nor 0x34! If I remove the last line then both *p and c seem to store the same 0x34 value. I tried to check the generated asm file, and I had a look at gptrput1.c but I could find no mistakes. My target is the PIC18F1220, programmed using ICD2 (through serial port) and Piklab. More details about my setup bellow: $ sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3 #4555 (Jan 4 2007) (UNIX) $ gpasm -v gpasm-0.13.3 beta $ piklab -v Piklab version: 0.12.2 (rev. distribution) Qt: 3.3.6 KDE: 3.5.5 Piklab: 0.12.2 Piklab compiling log shows: sdcc -mpic16 -p18f1220 -V --debug -I/directory-here/ -Wl-opointertest.hex-Wl-m -Wl-ainhx32 pointertest.c message: using default linker script "/usr/share/gputils/lkr/18f1220.lkr" + "/usr/local/bin/sdcpp" -nostdinc -Wall -std=c99 -I"/home/guerra/Desktop/ecobe-firmware/" -Dpic18f1220 -D__18f1220 -DSTACK_MODEL_SMALL -obj-ext=.o -DSDCC_MODEL_SMALL -DSDCC=263 -DSDCC_pic16 -D__pic16 -I"/usr/local/bin/../share/sdcc/include/pic16" -I"/usr/local/share/sdcc/include/pic16" -I"/directory-here/" "pointertest.c" + "gpasm" -DSDCC_MODEL_SMALL -Dpic18f1220 -D__18F1220 -DSTACK_MODEL_SMALL -g -c "pointertest.asm" -o "pointertest.o" + "gplink" -I"/usr/local/bin/../share/sdcc/lib/pic16" -I"/usr/local/share/sdcc/lib/pic16" -opointertest.hex -m -ainhx32 -w -r -o pointertest pointertest.o crt0i.o pic18f1220.lib libsdcc.lib Any help appreciated. Cheers, Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Rodrigo G. <tio...@gm...> - 2007-01-14 08:39:35
|
Sorry, I misspelled the last line in the previous message. But the problem is still nevertheless pertinent. The code is as follows: void main(void) { unsigned char c = 0x34; unsigned char *p; p = &c; *p = 0x12; (...) Any help appreciated. On 1/14/07, Rodrigo Guerra <tio...@gm...> wrote: > > Hello all, > > First of all thanks and congratulations for providing us all such capable > open source compiler for small devices. > > I experienced some strange behavior when trying to assign values to > dereferenced pointers in my programs. I decided to post here since I could > not find similar messages in the lists, forums, bug reports, Changelog, etc. > My apologies if this regards to some previously solved /reported problem (or > problem with my code). > > Here follows the relevant code: > > void main(void) > { > unsigned char c = 0x34; > unsigned char *p; > > p = &c; > p = 0x12; > > (...) > > There is no error messages when compiling but if I test *p after the last > line of code above it seems to be neither 0x12 nor 0x34! If I remove the > last line then both *p and c seem to store the same 0x34 value. > > I tried to check the generated asm file, and I had a look at gptrput1.cbut I could find no mistakes. > > My target is the PIC18F1220, programmed using ICD2 (through serial port) > and Piklab. > > More details about my setup bellow: > > $ sdcc -v > SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > 2.6.3 #4555 (Jan 4 2007) (UNIX) > > $ gpasm -v > gpasm-0.13.3 beta > > $ piklab -v > Piklab version: 0.12.2 (rev. distribution) > Qt: 3.3.6 > KDE: 3.5.5 > Piklab: 0.12.2 > > Piklab compiling log shows: > sdcc -mpic16 -p18f1220 -V --debug -I/directory-here/ -Wl-opointertest.hex-Wl-m -Wl-ainhx32 > pointertest.c > message: using default linker script "/usr/share/gputils/lkr/18f1220.lkr" > + "/usr/local/bin/sdcpp" -nostdinc -Wall -std=c99 > -I"/home/guerra/Desktop/ecobe-firmware/" -Dpic18f1220 -D__18f1220 > -DSTACK_MODEL_SMALL -obj-ext=.o -DSDCC_MODEL_SMALL -DSDCC=263 -DSDCC_pic16 > -D__pic16 -I"/usr/local/bin/../share/sdcc/include/pic16" > -I"/usr/local/share/sdcc/include/pic16" -I"/directory-here/" " > pointertest.c" > + "gpasm" -DSDCC_MODEL_SMALL -Dpic18f1220 -D__18F1220 -DSTACK_MODEL_SMALL > -g -c "pointertest.asm" -o "pointertest.o" > + "gplink" -I"/usr/local/bin/../share/sdcc/lib/pic16" > -I"/usr/local/share/sdcc/lib/pic16" -opointertest.hex -m -ainhx32 -w -r > -o pointertest pointertest.o crt0i.o pic18f1220.lib libsdcc.lib > > Any help appreciated. > > Cheers, > Rodrigo da Silva Guerra > PhD Student > > Department of Adaptive Machine Systems > Graduate School of Engineering > Osaka University - Japan -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Borut R. <bor...@si...> - 2007-01-14 09:09:55
|
Rodrigo Guerra wrote: > <snip> > void main(void) > { > unsigned char c = 0x34; > unsigned char *p; > > p = &c; > p = 0x12; > > (...) > <snip> It should be: *p = 0x12; Borut |
From: Rodrigo G. <tio...@gm...> - 2007-01-14 09:49:22
Attachments:
pointertest.c
|
Hello Borut, Thanks for the reply but pls see my second message. I misspelled the last line in the email but it is correct in the program (I do use *p = 0x12). I attached the full source for your reference this time. I use two LEDs to debug my program in the device. I have one green LED in RA4 and another orange LED in RB4. The green LED goes on with PORTA = 0x00 and goes off when PORTA = 0x10. The same for the orange LED with PORTB. With the attached source the green goes on. When I uncomment the *p = 0x12 line both LEDs remain off. I tested several times and I am sure both LEDs are working ok and several other conditional tests worked fine. The dereferenced read also seems to work okay (gptrget1.c). PS.: This is a test application I wrote in order to narrow the problem I had with the original program (which is much longer). I am still stuck with this. I feel like I will try to re-design my code so that I don't need to use pointer dereferenced writing of values. Let me know if you find something else strange with this... Cheers, Guerra On 1/14/07, Borut Razem <bor...@si...> wrote: > > Rodrigo Guerra wrote: > > <snip> > > void main(void) > > { > > unsigned char c = 0x34; > > unsigned char *p; > > > > p = &c; > > p = 0x12; > > > > (...) > > <snip> > It should be: > *p = 0x12; > > Borut > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Rodrigo G. <tio...@gm...> - 2007-01-14 09:48:38
|
Oh God... sorry again... pls do not consider the function "change_value" in the version I just sent. Its just another test I was trying just when I got your reply. Anyway, you should have enough info so that someone can reproduce the problem... On 1/14/07, Rodrigo Guerra <tio...@gm...> wrote: > > Hello Borut, > > Thanks for the reply but pls see my second message. I misspelled the last > line in the email but it is correct in the program (I do use *p = 0x12). > > I attached the full source for your reference this time. I use two LEDs to > debug my program in the device. I have one green LED in RA4 and another > orange LED in RB4. The green LED goes on with PORTA = 0x00 and goes off when > PORTA = 0x10. The same for the orange LED with PORTB. > > With the attached source the green goes on. When I uncomment the *p = 0x12 > line both LEDs remain off. I tested several times and I am sure both LEDs > are working ok and several other conditional tests worked fine. The > dereferenced read also seems to work okay ( gptrget1.c). > > PS.: This is a test application I wrote in order to narrow the problem I > had with the original program (which is much longer). > > I am still stuck with this. > I feel like I will try to re-design my code so that I don't need to use > pointer dereferenced writing of values. > > Let me know if you find something else strange with this... > > Cheers, > Guerra > > On 1/14/07, Borut Razem < bor...@si...> wrote: > > > > Rodrigo Guerra wrote: > > > <snip> > > > void main(void) > > > { > > > unsigned char c = 0x34; > > > unsigned char *p; > > > > > > p = &c; > > > p = 0x12; > > > > > > (...) > > > <snip> > > It should be: > > *p = 0x12; > > > > Borut > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > -- > Rodrigo da Silva Guerra > PhD Student > > Department of Adaptive Machine Systems > Graduate School of Engineering > Osaka University - Japan > > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Ernst B. <e.b...@xe...> - 2007-01-14 14:41:12
|
On Sunday 14 January 2007 10:48, Rodrigo Guerra wrote: > > On 1/14/07, Borut Razem < bor...@si...> wrote: > > > Rodrigo Guerra wrote: > > > > <snip> > > > > void main(void) > > > > { > > > > unsigned char c = 0x34; > > > > unsigned char *p; > > > > > > > > p = &c; > > > > p = 0x12; > > > > > > > > (...) > > > > <snip> Could you try with: void main(void) { unsigned char c = 0x34; data unsigned char *p; // ^^^^^ p = &c; *p = 0x12; } "data" here tells the compiler your pointer will always be used to point into RAM, never Flash/EEPROM/xmem/whatever, so it can optimize the gptrput call away and directly work with the pointer. It's always good practice to declare your pointers like that, unless you really need a generic pointer. Still, this doesn't fix the original problem, but if the result is still wrong with a "data" pointer, the problem most likely lies elsewhere. /Ernst |
From: Rodrigo G. <tio...@gm...> - 2007-01-14 15:24:00
|
Hello Ernst, I've just tried to declare the pointer as a data pointer following your instructions and this worked out. Thank you very much for your support. Now I will try to transfer the solution to the more complex application. I will try to update the list in case something else comes out. PS.: I had already noticed in gptrput1.c that the code and the eeprom cases were not implemented yet, but the data case was there. I just didn't realize it would use some other code if I declared the pointer as a data pointer. Thanks again, Guerra On 1/14/07, Ernst Bachmann <e.b...@xe...> wrote: > > On Sunday 14 January 2007 10:48, Rodrigo Guerra wrote: > > > On 1/14/07, Borut Razem < bor...@si...> wrote: > > > > Rodrigo Guerra wrote: > > > > > <snip> > > > > > void main(void) > > > > > { > > > > > unsigned char c = 0x34; > > > > > unsigned char *p; > > > > > > > > > > p = &c; > > > > > p = 0x12; > > > > > > > > > > (...) > > > > > <snip> > > Could you try with: > void main(void) > { > unsigned char c = 0x34; > data unsigned char *p; > // ^^^^^ > p = &c; > *p = 0x12; > } > > "data" here tells the compiler your pointer will always be used to point > into > RAM, never Flash/EEPROM/xmem/whatever, so it can optimize the gptrput call > away and directly work with the pointer. > > It's always good practice to declare your pointers like that, unless you > really need a generic pointer. > > Still, this doesn't fix the original problem, but if the result is still > wrong > with a "data" pointer, the problem most likely lies elsewhere. > > /Ernst > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Rodrigo G. <tio...@gm...> - 2007-01-14 15:45:12
|
Hi, I just tried the following (function version): void change_value(data unsigned char *pointer) { *pointer = 0x12; } void main(void) { unsigned char c = 0x34; data unsigned char *p; p = &c; change_value(p); (...) But in this case it seems *p was kept unaltered (*p = 0x34) after the function call. Any clue why? Note: I also tried to cast &c to a data unsigned char * but this didn't work either. Regards, Guerra On 1/15/07, Rodrigo Guerra <tio...@gm...> wrote: > > Hello Ernst, > > I've just tried to declare the pointer as a data pointer following your > instructions and this worked out. > Thank you very much for your support. > > Now I will try to transfer the solution to the more complex application. I > will try to update the list in case something else comes out. > > PS.: I had already noticed in gptrput1.c that the code and the eeprom > cases were not implemented yet, but the data case was there. I just didn't > realize it would use some other code if I declared the pointer as a data > pointer. > > Thanks again, > Guerra > > On 1/14/07, Ernst Bachmann <e.b...@xe...> wrote: > > > > On Sunday 14 January 2007 10:48, Rodrigo Guerra wrote: > > > > On 1/14/07, Borut Razem < bor...@si...> wrote: > > > > > Rodrigo Guerra wrote: > > > > > > <snip> > > > > > > void main(void) > > > > > > { > > > > > > unsigned char c = 0x34; > > > > > > unsigned char *p; > > > > > > > > > > > > p = &c; > > > > > > p = 0x12; > > > > > > > > > > > > (...) > > > > > > <snip> > > > > Could you try with: > > void main(void) > > { > > unsigned char c = 0x34; > > data unsigned char *p; > > // ^^^^^ > > p = &c; > > *p = 0x12; > > } > > > > "data" here tells the compiler your pointer will always be used to point > > into > > RAM, never Flash/EEPROM/xmem/whatever, so it can optimize the gptrput > > call > > away and directly work with the pointer. > > > > It's always good practice to declare your pointers like that, unless you > > really need a generic pointer. > > > > Still, this doesn't fix the original problem, but if the result is still > > wrong > > with a "data" pointer, the problem most likely lies elsewhere. > > > > /Ernst > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > -- > Rodrigo da Silva Guerra > PhD Student > > Department of Adaptive Machine Systems > Graduate School of Engineering > Osaka University - Japan > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Raphael N. <rn...@we...> - 2007-01-14 23:43:46
|
Hi Rodrigo, > void main(void) > { > unsigned char c = 0x34; > unsigned char *p; > > p = &c; > *p = 0x12; } > Any help appreciated. The above code snippet compiles fine with SDCC 2.6.4, r4570. _main_c_1_1 (alias c) ends up at 0x80, p=&c makes p=(0x80, 0x00, 0x80), the first 0x80 (MSB) being the pointer type (0x80 --> __data), and 0x0080 being the address of c in data memory. *p=0x12 assigns 0x12 to memory location 0x80 (alias c), which seems to be perfectly fine. Tested with gpsim. Even reading back *p (glo = *p; with a global `char glo;' declared before main()) works nicely. Could you give more information? How did you `test *p' after the last line of code? What did you perceive? -- Regards, Raphael Neider |
From: Rodrigo G. <tio...@gm...> - 2007-01-15 01:39:43
|
Hi Nelder, I never tried the simulator, but I will give it a shot later. I checked out the SDCC 2.6.4 r4570 yesterday but it didn't compile... just now I tried r4573 and it still didn't compile. I get "Caught signal 11: SIGSEGV" when it tries to compile the device libs... Anyway I think it would be more appropriate to discuss compilation problem in a different thread. I use two LEDs to debug my program in the device. I have one green LED in RA4 and another orange LED in RB4. The green LED goes on with PORTA = 0x00 and goes off when PORTA = 0x10. The same for the orange LED with PORTB. I initialize both PORTA and PORTB with 0x10 and then I did something like this to test the value in *p: if (*p == 0x34) { PORTA = 0x00; // green } if (*p == 0x12) { PORTB = 0x00; // orange } while (1); When the assignment is commented out the green is on. When the assignment is put in there both LEDs remain off. On the other hand, if I declare the pointer as (data unsigned char *) then the orange goes on (suggestion of Ernst). Nevertheless, that same solution does not work with function arguments: void change_value(data unsigned char *pointer) { *pointer = 0x12; } void main(void) { unsigned char c = 0x34; data unsigned char *p; p = &c; change_value(p); (...) Both LEDs remain off. I already tested the function with generic pointers before, and also tried to cast before assignmend of address "p = (data unsigned char)&c;" but neither worked. I am sure the value is neither 0x34 nor 0x12 after assignment with general pointer. I also suspect there was some data memory corruption because when I first noticed the problem in the actual application some very unrelated variable seemed messed up... but I didn't isolate that problem to be sure... (difficult to reproduce). Regards, Guerra On 1/14/07, Raphael Neider <rn...@we...> wrote: > > Hi Rodrigo, > > > void main(void) > > { > > unsigned char c = 0x34; > > unsigned char *p; > > > > p = &c; > > *p = 0x12; > } > > > Any help appreciated. > > The above code snippet compiles fine with SDCC 2.6.4, r4570. > _main_c_1_1 (alias c) ends up at 0x80, p=&c makes p=(0x80, 0x00, 0x80), > the first 0x80 (MSB) being the pointer type (0x80 --> __data), and > 0x0080 being the address of c in data memory. > *p=0x12 assigns 0x12 to memory location 0x80 (alias c), which seems to > be perfectly fine. Tested with gpsim. Even reading back *p (glo = *p; > with a global `char glo;' declared before main()) works nicely. > > Could you give more information? How did you `test *p' after the last > line of code? What did you perceive? > > -- > > Regards, > Raphael Neider > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Raphael N. <rn...@we...> - 2007-01-15 09:07:29
|
Hi Rodrigo, > I never tried the simulator, but I will give it a shot later. I > checked out the SDCC 2.6.4 r4570 yesterday but it didn't compile... > just now I tried r4573 and it still didn't compile. I get "Caught > signal 11: SIGSEGV" when it tries to compile the device libs... Anyway > I think it would be more appropriate to discuss compilation problem in > a different thread. What platform are you compiling on? Some PowerPC or Sparc, i.e. big-endian, I guess? There have been unresolved issues reported a while back, but myself not having access to such a machine, I was/am unable to resolve them. The libs compile fine on my Intel/AMD Linux boxes. > I use two LEDs to debug my program in the device. I have one green LED > in RA4 and another orange LED in RB4. The green LED goes on with PORTA > = 0x00 and goes off when PORTA = 0x10. The same for the orange LED > with PORTB. > > I initialize both PORTA and PORTB with 0x10 and then I did something > like this to test the value in *p: Maybe this should be LATA and LATB; write to the latches, read from the port. However, this probably does not cure the problem. > I am sure the value is neither 0x34 nor 0x12 after assignment with > general pointer. I also suspect there was some data memory corruption > because when I first noticed the problem in the actual application > some very unrelated variable seemed messed up... but I didn't isolate > that problem to be sure... (difficult to reproduce). Memory corruption? You may need to use a larger stack: #pragma stack 0x200 0x100 added in the single (!) file containing 'void main(void)' should do the trick, giving you a 256 byte stack located at 0x200..0x2FF. You may also have a look at the linker-generated .map file (use sdcc -Wl,-m ... or gplink -m ... to create it) to see if wherever p points to is close to the lower stack boundary (defaults to 0x200) and thus might have been destroyed by calling __gptrget(). Regards, Raphael |
From: Rodrigo G. <tio...@gm...> - 2007-01-17 06:19:11
|
Hi again Raphael, You said you tested with gpsim and I attempted to try as well but gpsim (as of 0.22.0) seems not to support the PIC 18F1220 processor. Apparently the only 16bit PIC it supports is 18Cxx2 but even this seems to be not fully supported yet (accordingly to gpsim/PROCESSORS in their sources). Now I wonder if the problem could be more specific to certain types of 16bit MCUs. Which PIC did you use in your simulation? Regards, Guerra On 1/14/07, Raphael Neider <rn...@we...> wrote: > > Hi Rodrigo, > > > void main(void) > > { > > unsigned char c = 0x34; > > unsigned char *p; > > > > p = &c; > > *p = 0x12; > } > > > Any help appreciated. > > The above code snippet compiles fine with SDCC 2.6.4, r4570. > _main_c_1_1 (alias c) ends up at 0x80, p=&c makes p=(0x80, 0x00, 0x80), > the first 0x80 (MSB) being the pointer type (0x80 --> __data), and > 0x0080 being the address of c in data memory. > *p=0x12 assigns 0x12 to memory location 0x80 (alias c), which seems to > be perfectly fine. Tested with gpsim. Even reading back *p (glo = *p; > with a global `char glo;' declared before main()) works nicely. > > Could you give more information? How did you `test *p' after the last > line of code? What did you perceive? > > -- > > Regards, > Raphael Neider > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Raphael N. <rn...@we...> - 2007-01-17 12:26:49
|
Hi Rodrigo, > You said you tested with gpsim and I attempted to try as well but > gpsim (as of 0.22.0) seems not to support the PIC 18F1220 processor. > Apparently the only 16bit PIC it supports is 18Cxx2 but even this > seems to be not fully supported yet (accordingly to gpsim/PROCESSORS > in their sources). I use gpsim 0.21.12-pre (it may be an svn version, no official release); gpsim processor list quit reveals that the pic18f1220 is/was supported. [Update: Looked up and tried with the gpsim-0.22.0 release; also supports the pic18f1220, also yields the same good results on my IA32 box.] Then I feed my code (below again in full) using sdcc -mpic16 -p18f1220 -Wl,-m deref.c gpsim -i -s deref.cod (My actual sdcc invocation has more -I and -L paths specified, but these should not matter.) <code name='deref.c'> unsigned char glo; void main(void) { unsigned char c = 0x34; unsigned char *p; p = &c; *p = 0x12; glo = 0; if (*p == 0x12) glo = 1; if (*p == 0x34) glo = 2; if (c == 0x12) glo |= 4; if (c == 0x34) glo |= 8; } </code> Then I use the step command (step [Enter], [Enter], [Enter], ...) to obtain verbose output from the simulator, ignoring all warnings until it spins at the `bra $-0x0' instruction after having left main(). Scrolling back reveals that glo has been assigned 1 first and then its second bit has been set, indicating that both writing c via *p and reading back from both c and *p work nicely. Another way to obtain this result is to use the dump command after the simulator spins in the endless loop and look at memory locations 0x80..0x81 (according to my .map file, c goes to 0x80 and glo goes to 0x81). I find 0x80 holding 0x12 and 0x81 storing the desired value of 0x05. > Now I wonder if the problem could be more specific to certain types of > 16bit MCUs. Feel free to send me your .asm/.cod/.hex/.map/.lst files as generated by SDCC from the code above (or your failing test code)---maybe SDCC emits wrong code on AMD64?!? (Send these file to my personal mail account rather than the list, though.) > Which PIC did you use in your simulation? pic18f1220 as described above. Hope that helps, Raphael |
From: Rodrigo G. <tio...@gm...> - 2007-01-18 05:12:30
|
Hi Raphael, I compiled your code exactly as you said both in AMD64 and in an Intel machine. I tried diff between both .hex files and they are identical. The .lst files differed only in their time-stamps. The .cod files differed as well, but I could not really tell what because those are binaries -- anyway, with diff -a (to treat binary as text files) it seemed to do with the time-stamp as well. About gpsim, you were right, latest versions do support 18f1220 (I guess they just didn't update the text file PROCESSORS...). I reproduced your steps using gpsim just like you said (with both Intel and AMD64 .cod files, just in case) and the result was identical. Now I will go try the exact code I used in the device to see what gpsim shows... Cheers, Guerra On 1/17/07, Raphael Neider <rn...@we...> wrote: > > Hi Rodrigo, > > > You said you tested with gpsim and I attempted to try as well but > > gpsim (as of 0.22.0) seems not to support the PIC 18F1220 processor. > > Apparently the only 16bit PIC it supports is 18Cxx2 but even this > > seems to be not fully supported yet (accordingly to gpsim/PROCESSORS > > in their sources). > > I use gpsim 0.21.12-pre (it may be an svn version, no official release); > gpsim > processor list > quit > reveals that the pic18f1220 is/was supported. [Update: Looked up and > tried with the gpsim-0.22.0 release; also supports the pic18f1220, also > yields the same good results on my IA32 box.] > > Then I feed my code (below again in full) using > sdcc -mpic16 -p18f1220 -Wl,-m deref.c > gpsim -i -s deref.cod > > (My actual sdcc invocation has more -I and -L paths specified, but these > should not matter.) > > <code name='deref.c'> > unsigned char glo; > > void main(void) > { > unsigned char c = 0x34; > unsigned char *p; > > p = &c; > *p = 0x12; > > glo = 0; > if (*p == 0x12) > glo = 1; > if (*p == 0x34) > glo = 2; > if (c == 0x12) > glo |= 4; > if (c == 0x34) > glo |= 8; > } > </code> > > Then I use the step command (step [Enter], [Enter], [Enter], ...) to > obtain verbose output from the simulator, ignoring all warnings until it > spins at the `bra $-0x0' instruction after having left main(). Scrolling > back reveals that glo has been assigned 1 first and then its second bit > has been set, indicating that both writing c via *p and reading back > from both c and *p work nicely. > > Another way to obtain this result is to use the dump command after the > simulator spins in the endless loop and look at memory locations > 0x80..0x81 (according to my .map file, c goes to 0x80 and glo goes to > 0x81). I find 0x80 holding 0x12 and 0x81 storing the desired value of > 0x05. > > > Now I wonder if the problem could be more specific to certain types of > > 16bit MCUs. > > Feel free to send me your .asm/.cod/.hex/.map/.lst files as generated by > SDCC from the code above (or your failing test code)---maybe SDCC emits > wrong code on AMD64?!? (Send these file to my personal mail account > rather than the list, though.) > > > Which PIC did you use in your simulation? > > pic18f1220 as described above. > > Hope that helps, > Raphael > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |
From: Raphael N. <rn...@we...> - 2007-01-18 09:55:31
|
Hi Rodrigo, > Variations #0 and #2 work fine on the device but variation #1 doesn't > turn any led on. Strangely, when testing variation #1 with gpsim it > seems to work fine (the command "symbol _PORTA" returns 0b00000000 and > the same for PORTB). So then, you might try to test your code variations with interrupts disabled (the interrupt assembly code looks good, but...). Further you might try `Variation #1a' below, which includes __gptrget but not __gptrput. You also seem to not set any configuration bits. Maybe (though improbable) you are bitten by the watchdog in the longer code (__gptrputX and __gptrgetX add some cycles compared to dereferencing a __data pointer)? >From the data sheet I gather that a default value in the CONFIG2L register enables Brown-Out Reset but specifies a `reserved' threshold voltage. Your other code fragments, work though, so this should not be the cause of your problems either... Variation #1a: -=-=-=-=-=-=-=-=- /* sample code to setup CONFIG bits */ unsigned char __at(__CONFIG2H) conf2h = _WDT_DISABLED_CONTROLLED_2H; void main(void) { unsigned char c; unsigned char *p; init(); c = 0x12; // initialized to match below p = &c; LATA = 0x10; // turn off green led LATB = 0x10; // turn off orange led if (*p == 0x12) LATA = 0x00; // turn on green led if (c == 0x12) LATB = 0x00; // turn on orange led } Good luck in finding the bug (I am pretty much out of ideas by now), Raphael |
From: Rodrigo G. <tio...@gm...> - 2007-01-19 05:33:48
|
Hi Raphael, I will try interrupt disabled for once. But your suggested __gptrget variation I have already tested long ago. The getting seemed to work fine that time. Anyway, won't hurt to give it another try. I will talk about the configuration bits in the other thread... Regards, Guerra On 1/18/07, Raphael Neider <rn...@we...> wrote: > > Hi Rodrigo, > > > Variations #0 and #2 work fine on the device but variation #1 doesn't > > turn any led on. Strangely, when testing variation #1 with gpsim it > > seems to work fine (the command "symbol _PORTA" returns 0b00000000 and > > the same for PORTB). > > So then, you might try to test your code variations with interrupts > disabled (the interrupt assembly code looks good, but...). > Further you might try `Variation #1a' below, which includes __gptrget > but not __gptrput. > > You also seem to not set any configuration bits. Maybe (though > improbable) you are bitten by the watchdog in the longer code > (__gptrputX and __gptrgetX add some cycles compared to dereferencing a > __data pointer)? > >From the data sheet I gather that a default value in the CONFIG2L > register enables Brown-Out Reset but specifies a `reserved' threshold > voltage. Your other code fragments, work though, so this should not be > the cause of your problems either... > > Variation #1a: > -=-=-=-=-=-=-=-=- > /* sample code to setup CONFIG bits */ > unsigned char __at(__CONFIG2H) conf2h = _WDT_DISABLED_CONTROLLED_2H; > > void main(void) > { > unsigned char c; > unsigned char *p; > > init(); > > c = 0x12; // initialized to match below > p = &c; > > LATA = 0x10; // turn off green led > LATB = 0x10; // turn off orange led > > if (*p == 0x12) LATA = 0x00; // turn on green led > if (c == 0x12) LATB = 0x00; // turn on orange led > } > > Good luck in finding the bug (I am pretty much out of ideas by now), > Raphael > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Rodrigo da Silva Guerra PhD Student Department of Adaptive Machine Systems Graduate School of Engineering Osaka University - Japan |