From: SourceForge.net <no...@so...> - 2010-08-20 13:59:49
|
Bugs item #1631532, was opened at 2007-01-09 13:59 Message generated for change (Comment added) made by tecodev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1631532&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic16 target >Group: fixed >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: PIC16 Port specific notes Initial Comment: from hor...@al... Hi our there, i've just started with sdcc, and found fine but I have some issues on it. For PIC182445,PIC18F2550,PIC18F445 and PIC18F4550 devices (PIC18F4550 has been tested) I found the following issues: 1. /sdcc/include/pic16/pic18f4550.h This family has TXCKP instead of SCKP in BAUDCON I understand. It's kept SCKP for compatibility, but the next bit - RXDTP - has to be named - for RX polarity. 2. /sdcc/lib/src/pic16/libio/usart/uopen.c I see that this is for compatibility too, but do not forget the settings below: TRISCbits.TRISC6 = 1; TRISCbits.TRISC7 = 1; Consider to assign SPBRGH as well, not just SPGRG. Here's why: /* Baud rates for BRGH=1 BRG16=1 OSC=48MHz */ /* 300 -> 39999 */ /* 600 -> 19999 */ /* 1200 -> 9999 */ /* 2400 -> 4999 */ /* 4800 -> 2499 */ /* 9600 -> 1249 */ /* 19200 -> 624 */ /* 38400 -> 311 */ /* 57600 -> 207 */ /* 115200 -> 103 */ SPBRGH = 0; SPBRG = 207; /* to 57600 */ In the last case, rates below 57600 requires SPBRGH as well (311 for 38400 :-) For your convenience, the init sequence of mine can be found in the attached archive. 3. /sdcc/lib/src/pic16/startup Since startup code does not reflect to linker script CODEPAGE NAME=vectors START=0x800 END=0x829 PROTECTED CODEPAGE NAME=page START=0x82A END=0x7FFF or --ivt-loc=0x800 either we had to do something... When I am using BRAND USB boot-loader, I have to prep the following as a workaround: /**/ /* - Special remapping of vectors to 800 - tweaking crt0 */ /* for AN956 USB boot loader */ /**/ #pragma code _reset 0x000800 void _reset( void ) __naked { __asm EXTERN __startup goto __startup __endasm; } #pragma code _high_ISR 0x000808 void _high_ISR( void ) __naked { __asm retfie __endasm; } #pragma code _low_ISR 0x000818 void _low_ISR( void ) __naked { __asm retfie __endasm; } It seems quite ugly.. Do you have better solution? 4. Am I right that stdio is far far from beta? Are there any tricks to bring up v(f)printf? I found only itoa to work at maximum... Here's the code of struggle: /* - First approach, without calling capability */ /* PASSED while(1) { while(!TXSTAbits.TRMT); TXREG='A'; while(!TXSTAbits.TRMT); TXREG='B'; while(!TXSTAbits.TRMT); TXREG='C'; while(!TXSTAbits.TRMT); TXREG='D'; while(!TXSTAbits.TRMT); TXREG='a'; while(!TXSTAbits.TRMT); TXREG='b'; while(!TXSTAbits.TRMT); TXREG='c'; while(!TXSTAbits.TRMT); TXREG='d'; while(!TXSTAbits.TRMT); TXREG='\r'; while(!TXSTAbits.TRMT); TXREG='\n'; } */ /* - Second approach, with calling capability */ /* crt0 _startup code provides us STACK */ /* PASSED while(1) { i++; while(!TXSTAbits.TRMT); TXREG=(i%10)+0x30; } */ /* - Third approach, with calling stream lib. */ /* PASSED while(1) { __stream_usart_putchar(((i++)%10)+0x30); } */ /* - Fourth approach, with calling usart lib. */ /* PASSED #define puts usart_puts while(1) { puts( "==stdinout test==\r\n" ); } */ /* - Fourth attempt, call itoa --> PASSED */ #define puts usart_puts while(1) { itoa( i++, buff, 10 ); puts( buff ); puts( "\r" ); } /* - Fifth attempt, call sprintf --> Failed */ /* #define puts usart_puts while(1) { sprintf( buff, "->%d\r\n", i++ ); puts( buff ); } */ /* - Sixth attempt, any (tiny, etc.. printf --> Failed */ /* stdout=STREAM_USART; while(1) { printf( "==>%d\r\n", i++ ); } */ 5. Documentation issues on PIC 16 port /sdcc/doc/sdccman.pdf --stack-model should be --pstack-model Best regards Gyuri (Gyorgy Horvath) ---------------------------------------------------------------------- >Comment By: Raphael Neider (tecodev) Date: 2010-08-20 13:59 Message: Item 1 seems to have been fixed with r4573. Item 2 has been fixed in r5938 via a massive change in selecting ADC/USART styles and a slight addition of style-dependant code. Item 3 has a functional workaround, items 4 and 5 have already been addressed, so I consider this request closed. ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2007-01-14 10:22 Message: Logged In: YES user_id=1115835 Originator: NO 1.-3.: still open 3.: there are sections 'vectors' defined for all supported devices in the .lkr scripts. SDCC might place its interrupt vectors in that section. For this to work, we would require that all interrupt handlers are known at some point in time, since we cannot simply append to a named section. Probably we can fill in a default interrupt vector table in section 'vectors' like <code> S_interrupts code vectors GOTO __startup ; 0x00 RETFIE ; 0x01 NOP ; 0x02 ; more NOPs here NOP ; 0x07 GOTO ___handler2 ; 0x08 RETFIE ; 0x09 NOP ; 0x0A ; more NOPs here NOP ; 0x17 GOTO ___handler3 ; 0x18 RETFIE ; new section here </code> and add default implementation of _handler1 and _handler2 a la <code N={0,1}> void handlerN(void) __naked { __asm retfie __endasm; } </code> to the libraries? Comments appreciated. We might further improve this solution by saving and restoring WREG, STATUS, and PCLATH right in the vector table, there should be enough space left... 4. > Am I right that stdio is far far from beta? How do you mean this? stdio should be close to production-stable. > Are there any tricks to bring up v(f)printf? No tricks, just the usual stack setup magic: #pragma stack 0x200 0x100 in your main() file will do the trick. The default stack is located in 0x200-0x23F (64 byte), which is simply too small for serious uses of printf. In my next commit, I will increase the default stack size to 256 bytes (one bank, 0x200 to 0x2FF). 5. Yes, right; I will update this in the next commit as well. Thanks for the report. Regards, Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1631532&group_id=599 |