From: george j. <az....@gm...> - 2007-01-19 08:24:00
|
I use sdcc to compile a program to read a analog input and display it on an lcd .but i get the following error. sdcc: /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: genModOneByte: Assertion `result->aop->size == 1' failed. Caught signal 6: SIGABRT . #include"pic/pic16f877.h" char x; int value1; int count; int count1; char value2; char value; char value3; char value4; char value5; char value6; char value7; char value8; void lcd(); void adc(); void sendcom(); void senddata(); void multiply(); void Delay(); void check(); void main() { lcd(); while(1) { adc(); } } void lcd() { TRISC=0X00; x=0x30; sendcom(); Delay(); x=0x01; sendcom(); Delay(); x=0x0c; sendcom(); Delay(); x=0x06; sendcom(); Delay(); } void adc() { //ADCON1=0x80; //ADCON0=0x89; _asm BSF ADCON1,7; BCF ADCON1,3 ; BCF ADCON1,2; BCF ADCON1,1; BCF ADCON1,0; MOVLW H'89'; MOVWF ADCON0; _endasm; //ADCON0=0X89; Delay(); GO=1; while(GO!=0) /* EQUILENT OF GO/DoNE BIT*/ { } x=0x80; sendcom(); Delay(); multiply(); } void sendcom() { TRISD=0x00; PORTC = 0x04; //rs=0,rw=1,E=2 PORTD=x; PORTC=0x00; } void senddata() { TRISD=0x00; PORTC=0x05; PORTD=value1; Delay(); PORTC=0x01; } void Delay() { count1=0xff; while(count1!=1) { count=0x0f; while(count!=1) { count--; } count1--; } } void multiply() { value=ADRESH; value=value&0x03; value=value*0.48; value2=0; value2=ADRESL; value2=value2&0x0f; value2=value2*0.48; value3=0; value3=ADRESL; value3=value3&0xf0; value3=value3*0.48; value4=value3|value2; value1=(value|value4); value5=value1/10; value6=value/10; value1=value5%10; value1=value1+'0'; senddata(); Delay(); value1=value6%10; value1=value1+'0'; senddata(); Delay(); } |
From: Raphael N. <rn...@we...> - 2007-01-19 10:26:31
|
Hi John, > sdcc: /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: genModOneByte: Assertion `result->aop->size == 1' failed. > Caught signal 6: SIGABRT Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report. > void multiply() > { > value=ADRESH; > value=value&0x03; > value=value*0.48; You seem to use floating point arithmetics on the pic14 port. Could you please report success or failure regarding this? I believed floating point not to work, but did not check for a long time... Any report would be highly appreciated. Anyhow, be warned: FP arithmetics might cause further troubles. If in doubt, try to approximate using integer arithmetics only. Regards, Raphael |
From: george j. <az....@gm...> - 2007-01-20 03:07:42
|
i am using sdcc version SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3 #4543 (Dec 31 2006) (UNIX) I solved the compilation problem by typecasting value5 and value6 now compilation is ok.I am not sure about the result.now i am trying to check that part.I want to know one more thing in pic16f877 to start an a/d convertion we have to set the GO/Done bit in the adcon0 .but in the header file it this bit is defined in three ways GO , NOT_DONE,GO_DONE will you plz tell which bit i have to set to begin A/D convertion .now i write this part in assemble. Also in pic16f84a first pin of portb can be set by RB1=1 but in pic16f877 it is not possable.is any way to do this now i am setting the whole portb. also i noticed one thing inside a c code if i wrote an asm ie _asm bcf STATUS,RP0; _endasm; it give an error that STATUS_bit PR0 is not defined.how we can solve this On 1/19/07, Raphael Neider <rn...@we...> wrote: > > Hi John, > > > sdcc: > /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: > genModOneByte: Assertion `result->aop->size == 1' failed. > > Caught signal 6: SIGABRT > > Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report. > > > void multiply() > > { > > value=ADRESH; > > value=value&0x03; > > value=value*0.48; > > You seem to use floating point arithmetics on the pic14 port. Could you > please report success or failure regarding this? I believed floating > point not to work, but did not check for a long time... Any report would > be highly appreciated. Anyhow, be warned: FP arithmetics might cause > further troubles. If in doubt, try to approximate using integer > arithmetics only. > > Regards, > 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 > |
From: Raphael N. <rn...@we...> - 2007-01-27 12:11:33
|
Hi again, forgot to answer your questions... > I want to know one more thing in pic16f877 to start an a/d convertion > we have to set the GO/Done bit in the adcon0 .but in the header file > it this bit is defined in three ways GO , NOT_DONE,GO_DONE will you > plz tell which bit i have to set to begin A/D convertion .now i write > this part in assemble. It does not matter which name you use; they all map to the same bit via the C union mechanism... > Also in pic16f84a first pin of portb can be set by RB1=1 > but in pic16f877 it is not possable.is any way to do this now i am > setting the whole portb. This has been added few revisions back. Consider updating your SDCC installation (e.g., from the 'nightly' builds http://sdcc.sf.net/snap.php (stalled on 2006-12-31) or via svn). Beware, though, that the current svn head revision is somewhat broken with regards to initialized arrays. > also i noticed one thing inside a c code if i wrote an asm ie > _asm > bcf STATUS,RP0; > _endasm; > it give an error that STATUS_bit PR0 is not defined.how we can solve > this Cannot reproduce this with a recent SDCC version. Probably you can use #pragma preproc_asm - to turn off preprocessing inline assembly code. -- Regards, Raphael Neider |
From: george j. <az....@gm...> - 2007-01-20 11:48:29
|
Is OR and AND operation is supported in SDCC .whether hearder file is required or not TRISD=0x00; PORTC = PORTC|0x04; //rs=0,rw=1,E=2 for command rs=0 rw=0 and en=1(00000100) PORTD=x; PORTC=PORTC^0x04; this code is not working plz replay me On 1/20/07, george john <az....@gm...> wrote: > > i am using sdcc version SDCC : > mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3#4543 (Dec 31 2006) (UNIX) > I solved the compilation problem by typecasting value5 and value6 now > compilation is ok.I am not sure about the result.now i am trying to check > that part.I want to know one more thing in pic16f877 to start an a/d > convertion we have to set the GO/Done bit in the adcon0 .but in the header > file it this bit is defined in three ways GO , NOT_DONE,GO_DONE will you plz > tell which bit i have to set to begin A/D convertion .now i write this part > in assemble. > > Also in pic16f84a first pin of portb can be set by RB1=1 > but in pic16f877 it is not possable.is any way to do this now i am setting > the whole portb. > also i noticed one thing inside a c code if i wrote an asm ie > _asm > bcf STATUS,RP0; > _endasm; > it give an error that STATUS_bit PR0 is not defined.how we can solve this > > On 1/19/07, Raphael Neider < rn...@we...> wrote: > > > > Hi John, > > > > > sdcc: > > /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: > > genModOneByte: Assertion `result->aop->size == 1' failed. > > > Caught signal 6: SIGABRT > > > > Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report. > > > > > void multiply() > > > { > > > value=ADRESH; > > > value=value&0x03; > > > value=value* 0.48; > > > > You seem to use floating point arithmetics on the pic14 port. Could you > > please report success or failure regarding this? I believed floating > > point not to work, but did not check for a long time... Any report would > > > > be highly appreciated. Anyhow, be warned: FP arithmetics might cause > > further troubles. If in doubt, try to approximate using integer > > arithmetics only. > > > > Regards, > > 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 > > > > |
From: Ori I. <or...@he...> - 2007-01-20 14:17:56
|
OR and AND operators are supported without a need for a header files, these are built in language operators. However registers like TRISD, PORTC etc. are defined in a header file. -- Ori Idan On 1/20/07, george john <az....@gm...> wrote: > > Is OR and AND operation is supported in SDCC .whether hearder file is > required or not > > TRISD=0x00; > PORTC = PORTC|0x04; //rs=0,rw=1,E=2 for command rs=0 rw=0 and > en=1(00000100) > PORTD=x; > PORTC=PORTC^0x04; > this code is not working plz replay me > > On 1/20/07, george john <az....@gm... > wrote: > > > > i am using sdcc version SDCC : > > mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3#4543 (Dec 31 2006) (UNIX) > > I solved the compilation problem by typecasting value5 and value6 now > > compilation is ok.I am not sure about the result.now i am trying to > > check that part.I want to know one more thing in pic16f877 to start an > > a/d convertion we have to set the GO/Done bit in the adcon0 .but in the > > header file it this bit is defined in three ways GO , NOT_DONE,GO_DONE will > > you plz tell which bit i have to set to begin A/D convertion .now i write > > this part in assemble. > > > > Also in pic16f84a first pin of portb can be set by RB1=1 > > but in pic16f877 it is not possable.is any way to do this now i am > > setting the whole portb. > > also i noticed one thing inside a c code if i wrote an asm ie > > _asm > > bcf STATUS,RP0; > > _endasm; > > it give an error that STATUS_bit PR0 is not defined.how we can solve > > this > > > > On 1/19/07, Raphael Neider < rn...@we...> wrote: > > > > > > Hi John, > > > > > > > sdcc: > > > /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: > > > genModOneByte: Assertion `result->aop->size == 1' failed. > > > > Caught signal 6: SIGABRT > > > > > > Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report. > > > > > > > void multiply() > > > > { > > > > value=ADRESH; > > > > value=value&0x03; > > > > value=value* 0.48; > > > > > > You seem to use floating point arithmetics on the pic14 port. Could > > > you > > > please report success or failure regarding this? I believed floating > > > point not to work, but did not check for a long time... Any report > > > would > > > be highly appreciated. Anyhow, be warned: FP arithmetics might cause > > > further troubles. If in doubt, try to approximate using integer > > > arithmetics only. > > > > > > Regards, > > > 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 > > > > > > > > > ------------------------------------------------------------------------- > 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 > > > |
From: george j. <az....@gm...> - 2007-01-21 10:28:48
|
The problem is solved it is some wrong with the code On 1/20/07, george john <az....@gm...> wrote: > > Is OR and AND operation is supported in SDCC .whether hearder file is > required or not > > TRISD=0x00; > PORTC = PORTC|0x04; //rs=0,rw=1,E=2 for command rs=0 rw=0 and > en=1(00000100) > PORTD=x; > PORTC=PORTC^0x04; > this code is not working plz replay me > > On 1/20/07, george john <az....@gm... > wrote: > > > > i am using sdcc version SDCC : > > mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.3#4543 (Dec 31 2006) (UNIX) > > I solved the compilation problem by typecasting value5 and value6 now > > compilation is ok.I am not sure about the result.now i am trying to > > check that part.I want to know one more thing in pic16f877 to start an > > a/d convertion we have to set the GO/Done bit in the adcon0 .but in the > > header file it this bit is defined in three ways GO , NOT_DONE,GO_DONE will > > you plz tell which bit i have to set to begin A/D convertion .now i write > > this part in assemble. > > > > Also in pic16f84a first pin of portb can be set by RB1=1 > > but in pic16f877 it is not possable.is any way to do this now i am > > setting the whole portb. > > also i noticed one thing inside a c code if i wrote an asm ie > > _asm > > bcf STATUS,RP0; > > _endasm; > > it give an error that STATUS_bit PR0 is not defined.how we can solve > > this > > > > On 1/19/07, Raphael Neider < rn...@we...> wrote: > > > > > > Hi John, > > > > > > > sdcc: > > > /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: > > > genModOneByte: Assertion `result->aop->size == 1' failed. > > > > Caught signal 6: SIGABRT > > > > > > Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the report. > > > > > > > void multiply() > > > > { > > > > value=ADRESH; > > > > value=value&0x03; > > > > value=value* 0.48; > > > > > > You seem to use floating point arithmetics on the pic14 port. Could > > > you > > > please report success or failure regarding this? I believed floating > > > point not to work, but did not check for a long time... Any report > > > would > > > be highly appreciated. Anyhow, be warned: FP arithmetics might cause > > > further troubles. If in doubt, try to approximate using integer > > > arithmetics only. > > > > > > Regards, > > > 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 > > > > > > > > |
From: george j. <az....@gm...> - 2007-01-22 11:28:43
|
Floating point arithematics is working well in sdcc.I set up an A/D convertor with an accuracy of .0048V .Using sdcc the convertion is very easy. > > On 1/19/07, Raphael Neider < rn...@we...> wrote: > > > > > > > > Hi John, > > > > > > > > > sdcc: > > > > /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:3609: > > > > genModOneByte: Assertion `result->aop->size == 1' failed. > > > > > Caught signal 6: SIGABRT > > > > > > > > Fixed in SDCC 2.4.6, r4581 (for both / and %). Thanks for the > > > > report. > > > > > > > > > void multiply() > > > > > { > > > > > value=ADRESH; > > > > > value=value&0x03; > > > > > value=value* 0.48; > > > > > > > > You seem to use floating point arithmetics on the pic14 port. Could > > > > you > > > > please report success or failure regarding this? I believed floating > > > > point not to work, but did not check for a long time... Any report > > > > would > > > > be highly appreciated. Anyhow, be warned: FP arithmetics might cause > > > > further troubles. If in doubt, try to approximate using integer > > > > arithmetics only. > > > > > > > > Regards, > > > > 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 > > > > > > > > > > > > > > > > |
From: george j. <az....@gm...> - 2007-01-25 05:37:52
|
#define __16f877A #include"pic/pic16f877a.h" void WriteByteToEE(unsigned char d, const unsigned char ad); void main(void) { WriteByteToEE( 0x45,0x01); while(1) { } } void WriteByteToEE(unsigned char d, const unsigned char ad) { //EEADRH=0x21; EEADR = ad; // Address to write to EEDATA = d; // Data to write WREN = 1; // Enable writes to the EEProm GIE = 0; // Disable interrupts during write EECON2 = 0x55; // Write "password" to EECON2 EECON2 = 0xAA; WR = 1; // Initiate a write cycle while(WR==1) //while loop { } WREN = 0; // Wait for write to complete EEIF = 0; // Disable writes to EEProm GIE=1; } This is a c code which write the data to eeprom .But it doesn't work. When this code is written in asm it works well. |
From: george j. <az....@gm...> - 2007-01-25 07:50:28
|
I forget to point out one thing when i use the sdcc version 2.6.3 it compile successfull but the data was not written on the eeprom.When the same code compiled with sdcc 2.6.0 then it work successfully,data is written on the eeprom.Is this a bug of sdcc 2.6.3.If it is abug of that version plz inform me On 1/25/07, george john <az....@gm...> wrote: > > > #define __16f877A > #include"pic/pic16f877a.h" > void WriteByteToEE(unsigned char d, const unsigned char ad); > void main(void) > { > WriteByteToEE( 0x45,0x01); > while(1) > { > } > } > > void WriteByteToEE(unsigned char d, const unsigned char ad) > { > //EEADRH=0x21; > EEADR = ad; // Address to write to > EEDATA = d; // Data to write > > WREN = 1; // Enable writes to the EEProm > > GIE = 0; // Disable interrupts during > write > > EECON2 = 0x55; // Write "password" to EECON2 > EECON2 = 0xAA; > WR = 1; // Initiate a write cycle > > while(WR==1) //while loop > { > } > > WREN = 0; // Wait for write to > complete > EEIF = 0; // Disable writes to EEProm > GIE=1; > > } > > This is a c code which write the data to eeprom .But it doesn't work. > When this code is written in asm it works well. > > |
From: Ernst B. <e.b...@xe...> - 2007-01-25 09:36:24
|
On Thursday 25 January 2007 08:50, george john wrote: > > EECON2 = 0x55; // Write "password" to EECON2 > > EECON2 = 0xAA; > > WR = 1; // Initiate a write cycle > > Well, the PIC Datasheet claims that an exact timed sequence is neccessary to write the internal eeprom: [quote the datasheet:] The write will not initiate if the above sequence is not exactly followed (write 55h to EECON2, write AAh to EECON2, then set WR bit) for each byte. We strongly recommend that interrupts be disabled during this code segment. A cycle count is executed during the required sequence. Any number that is not equal to the required cycles to execute the required sequence will prevent the data from being written into the EEPROM. Additionally, the WREN bit in EECON1 must be set to enable write. This mechanism prevents accidental writes to data EEPROM due to errant (unexpected) code execution (i.e., lost programs). The user should keep the WREN bit clear at all times, except when updating EEPROM. The WREN bit is not cleared by hardware. [/quote] Depending on the compiler optimization, redundand banksels etc, your EECON2 writes won't be translated into the exact reqired ASM sequence. Please check the intermediate ASM code generated by SDCC if that is the case. The only solution working regardless of compiler version and settings would be to implement it in inline ASM, like [quote datasheet:] BSF STATUS,RP0 ;Bank 1 BSF EECON1,WREN ;Enable write BCF INTCON,GIE ;Disable INTs MOVLW 55h ;Unlock write MOVWF EECON2 ; MOVLW AAh ; MOVWF EECON2 ; BSF EECON1,WR ;Start the write BSF INTCON,GIE ;Enable INTS [/quote] HTH, /Ernst |
From: george j. <az....@gm...> - 2007-01-25 10:27:02
|
But the problem is with the compiler if we compile the above code with sdcc 2.6.0 it will work but with sdcc 2.6.3 it will not work. On 1/25/07, Ernst Bachmann <e.b...@xe...> wrote: > > On Thursday 25 January 2007 08:50, george john wrote: > > > EECON2 = 0x55; // Write "password" to > EECON2 > > > EECON2 = 0xAA; > > > WR = 1; // Initiate a write cycle > > > > > Well, the PIC Datasheet claims that an exact timed sequence is neccessary > to > write the internal eeprom: > > [quote the datasheet:] > The write will not initiate if the above sequence is not > exactly followed (write 55h to EECON2, write AAh to > EECON2, then set WR bit) for each byte. We strongly > recommend that interrupts be disabled during this > code segment. A cycle count is executed during the > required sequence. Any number that is not equal to the > required cycles to execute the required sequence will > prevent the data from being written into the EEPROM. > Additionally, the WREN bit in EECON1 must be set to > enable write. This mechanism prevents accidental > writes to data EEPROM due to errant (unexpected) > code execution (i.e., lost programs). The user should > keep the WREN bit clear at all times, except when > updating EEPROM. The WREN bit is not cleared > by hardware. > [/quote] > > Depending on the compiler optimization, redundand banksels etc, your > EECON2 > writes won't be translated into the exact reqired ASM sequence. > > Please check the intermediate ASM code generated by SDCC if that is the > case. > > The only solution working regardless of compiler version and settings > would be > to implement it in inline ASM, like > > [quote datasheet:] > BSF STATUS,RP0 ;Bank 1 > BSF EECON1,WREN ;Enable write > BCF INTCON,GIE ;Disable INTs > MOVLW 55h ;Unlock write > MOVWF EECON2 ; > MOVLW AAh ; > MOVWF EECON2 ; > BSF EECON1,WR ;Start the write > BSF INTCON,GIE ;Enable INTS > [/quote] > > > HTH, > /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 > |
From: Raphael N. <rn...@we...> - 2007-01-25 11:10:59
|
Am Donnerstag, den 25.01.2007, 15:57 +0530 schrieb george john: > But the problem is with the compiler if we compile the above code > with sdcc 2.6.0 it will work but with sdcc 2.6.3 it will not work. After 2.6.0 was released I meddled with the banksel generation code in the compiler because the original code (in 2.6.0) sometimes forgot to generate required banksels. The new code (some time before 2.6.3) is more pessimistic and always generates banksels unless it is sure that a banksel is not required. Thus 2.6.3 emits more banksels than 2.6.0. The patch contributed by Alex identifies another class of redundant BANKSELs and removes them. Updating to 4595 should help. Raphael |
From: Ernst B. <e.b...@xe...> - 2007-01-25 13:02:55
|
On Thursday 25 January 2007 12:10, Raphael Neider wrote: > Am Donnerstag, den 25.01.2007, 15:57 +0530 schrieb george john: > > But the problem is with the compiler if we compile the above code > > with sdcc 2.6.0 it will work but with sdcc 2.6.3 it will not work. > And I'd say its not as much a problem with SDCC but with your code. Both versions did create CORRECT code for EECON2 = 0x55; EECON2 = 0xAA; WR = 1; with the 2.6.3 code being a bit slower due to the unneccessary banksel. The fact that the old sdcc version did create the "right" sequence of ASM instructions is more or less luck, but in no way enforced by your code. And even if sdcc with the latest patch does generate that ASM sequence again, thats still just "luck" and in no way required. Rationale (applies not only to SDCC, but to all compilers in general): If you need a specific sequence of ASM commands in your binary, the only way to make sure it is generated correctly is to use inline assembler and write it yourself. /Ernst |
From: Theblond <the...@fr...> - 2007-01-25 18:19:12
|
Dear All, > The new code (some time before 2.6.3) is more pessimistic and always > generates banksels unless it is sure that a banksel is not required. > Thus 2.6.3 emits more banksels than 2.6.0. > The patch contributed by Alex identifies another class of redundant > BANKSELs and removes them. I would warn that NOT every unnecesary banksels are removed, only those that have address information. e.g. mostly only this kind of stuff has affect and some internals: /* __data __at 0x0020 unsigned char variable; */ So, more banksels can be removed if the compiler will allocate the addresses for the variables. Regards, Alex |
From: <Ant...@se...> - 2007-01-26 14:01:21
|
> So, more banksels can be removed if the compiler will allocate the > addresses for the variables. Yes but the linker is there to allocate the space. It would be sufficient for the compiler to know some blocks of variables which must be allocated in the same bank, leaving the linker scope to assign the blocks to banks. The blocks might equate to the group of globals & static locals defined in one file, as typically one might define variables along with the functions which use them the most. There are other ways you might do this. Assigning variables in a structure, with a keyword which forces the structure to be allocated within a single bank, not crossing a bank boundary. I expect the linker already knows how to allocate other types such as ints and longs in this way, why not enable larger items to have the property=3F The only other way is to alter the sequence of compiler passes and linking for harvard architecture CPUs. Compile for data, link the data space, compile for code, and link the code space. This would help not just PIC. Nearly every 8-bit CPU has to load the high-byte of an address into a register when accessing a memory space. It need not reload the high byte for each variable used that is known to be in the same page. It would save 2 bytes and the instruction cycles for most variables accessed. Anthony ------------------------------------------------------------ This email and any attached files contains company confidential information = which may be legally privileged. It is intended only for the person(s) or en= tity to which it is addressed and solely for the purposes set forth therein.= If you are not the intended recipient or have received this email in error= please notify the sender by return, delete it from your system and destroy = any local copies. It is strictly forbidden to use the information in this e= mail including any attachment or part thereof including copying, disclosing,= distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common = law) for damage or breach arising or related to this email including but not= limited to viruses and libel. |
From: Raphael N. <rn...@we...> - 2007-01-25 10:12:38
|
Hi, > Depending on the compiler optimization, redundand banksels etc, your EECON2 > writes won't be translated into the exact reqired ASM sequence. > > Please check the intermediate ASM code generated by SDCC if that is the case. Ernst is right, SDCC inserts a redundant BANKSEL before updating WR. Luckily, Alex just posted a patch to fix this. Patch applied and problem probably fixed in SDCC r4595. Regards, Raphael |
From: <kt...@fr...> - 2007-01-25 10:17:15
|
Hi Raphael, Latest snapshots only available trough SVN ? Regards, KTy Quoting Raphael Neider <rn...@we...>: > Hi, > > > Depending on the compiler optimization, redundand banksels etc, your = EECON2 > > writes won't be translated into the exact reqired ASM sequence. > > > > Please check the intermediate ASM code generated by SDCC if that is t= he > case. > > Ernst is right, SDCC inserts a redundant BANKSEL before updating WR. > Luckily, Alex just posted a patch to fix this. Patch applied and proble= m > probably fixed in SDCC r4595. > > Regards, > 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=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Raphael N. <rn...@we...> - 2007-01-25 10:23:18
|
> Latest snapshots only available trough SVN ? Seemingly. According to the SF Compile Farm Status Page http://sourceforge.net/docman/display_doc.php?docid=10472&group_id=1#top, the compile farm is more or less down since 2007-01-05. SVN works, however. Regards, Raphael |