Thank you Maarten and Jesus. Maarten Brock wrote: > Some comments, > > 1) Analog Devices has no datasheet for this thing on > their website ?! > http://www.analog.com/en/prod/0%2C2877%2CADUC842%2C00.html http://www.analog.com/UploadedFiles/Data_Sheets/ADUC841_842_843.pdf
> 2) Keil has a datasheet rev.0 from 2003 ?! > 3) It seems that when you enable the 11-bit stack push, > pop, call & ret will work just fine. But when accessing > parameters, local variables & temporaries on stack SDCC > uses @Ri indexing. So when stack has rolled over into > xram, it will access the wrong data! I do not recommend > to use this option unless you're willing to adapt SDCC > itself at several places! > Thanks for the insight. > 4) If you're really afraid the 8 bit stack will overflow > (have you checked how much it uses now?) you can even go > to --xstack. This will build a software stack in pdata > (movX @Ri) for parameters and local variables. The > hardware stack will only be used for push, pop, call & > ret and for temporaries. > An 8 bit xstack sounds good. I just tried recompiling my project with --model-large --opt-code-size --stack-auto --xstack and my ROM/EPROM/FLASH went from 45K to 65K (more than my target has) and i still have a lot of code i need to try and fit in the target. > 5) There are no near term improvements to be expected on > the use or location of temporaries. > 6) Breaking up large function into smaller ones might > help. > 7) I do not recommend to try to reduce stack usage. I > think it will make things worse. > 8) It's a very good idea to see if the interrupts > actually use the registers in the bank you reserved for > them. A good ISR is short and simple with no function > calls and therefor may not need any register at all. > > Greets, > Maarten > > >> Hi, >> >> I was looking at the stack roll-over capability >> of the Aduc842, and I thing you can take great >> advantage of it! This is from the datasheet: >> >> "By default, the stack operates exactly like an 8052 in that it rolls >> over from FFH to 00H in the general-purpose RAM. On the >> parts, however, it is possible (by setting CFG841.7 or CFG842.7) >> to enable the 11-bit extended stack pointer. In this case, the >> stack rolls over from FFH in RAM to 0100H in XRAM. >> >> The 11-bit stack pointer is visible in the SP and SPH SFRs. The >> SP SFR is located at 81H as with a standard 8052. The SPH SFR >> is located at B7H. The 3 LSBs of this SFR contain the 3 extra bits >> necessary to extend the 8-bit stack pointer into an 11-bit stack >> pointer." >> >> I never tried this before, but according to the >> datasheet, it would be very easy to activate in >> sdcc. In _sdcc_external_startup or the top of >> your main function (I don't remember where the stack is initialized) add: >> >> CFG842|=0x80; // Enable 11-bit stack >> SPH=0x7 // Locate stack at 0x700 >> SP=0; >> >> If that doesn't work, try not changing SPH and >> SP, and link with --xram-loc 0x200, as the stack >> would roll over from data 0xff to xram >> 0x100. Then, by making some of your new >> functions reentrant, you should be able to free >> some data memory. Or you can go to the extreme >> of making all reentrant (using stack-auto) and free lots of data memory. >> >> Jesús >> >> >> At 05:58 AM 10/3/2006, you wrote: >> >> >>> Maarten Brock wrote: >>> >>>> Hello Karl, >>>> >>>> Yes, you ran out of 'data' memory. Especially when >>>> accessing xdata (--model-large) the compiler uses many >>>> temporaries which are stored in registers and then in >>>> data memory. It tries to overlay them but is not very >>>> good at that. The result: high usage of the limited data >>>> memory resource. As you can see in the .mem file all is >>>> used. It has no point putting temporaries in xdata as >>>> xdata access (only indirect) was the issue in the first >>>> place. >>>> >>>> Am I saying all hope is lost? No, not all. You can try >>>> to use --stack-auto to put all temporaries on the stack. >>>> The stack uses idata which can be about twice as big as >>>> data memory, but it also might introduce extra >>>> temporaries. Also on the stack overlaying happens by >>>> definition in it's most efficient way. But I cannot >>>> guarantee this will solve your problems, it might even >>>> create more as stack pressure rises and stack overflows >>>> can happen. >>>> >>>> Greets, >>>> Maarten >>>> >>>> >>>> >>> Thanks for the info. I'm thinking though that --stack-auto will cause >>> more problems with potential stack overflows. >>> >>> Any near term improvements coming the the compiler to help improve it's >>> usage of these temporaries? >>> >>> Are there things i can do with my code, that will make the compiler work >>> better to help improve things? >>> >>> What i have in mind: >>> * remove reentrant function (i have 1 now) I would think that this only >>> reduces stack usage though. >>> * break functions into smaller pieces >>> * reduce function depth (reduce stack usage) >>> * I have 2 register banks for high priority interrupts allocated, I may >>> try not "using x" register bank, trade off on performance, but will add >>> a few bytes of "data" space. >>> * This processor (analog devices ADUC842) supports a 11 bit stack >>> pointer (SP and SPH) that would allow me to use --stack-auto and now >>> worry about overflows. However I don't know how to make SDCC do this, >>> or if it's supported. >>> >>> >>> I'm trying these now... >>> >>> Thanks >>> >>> -- >>> Karl Hiramoto http://karl.hiramoto.org/ >>> >>> >>> >>>>> Hi all, >>>>> >>>>> My code was compiling/linking/running fine, I added a few functions, >>>>> and now when linking i get: >>>>> >>>>> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area >>>>> OSEG. >>>>> >>>>> sdcc -v >>>>> SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 >>>>> 2.6.1 #4398 (Oct 2 2006) (UNIX) >>>>> >>>>> I also had the same with the 2.6.0 release. >>>>> >>>>> >>>>> I compile/link with args like: >>>>> >>>>> sdcc -c --iram-size 256 --model-large --xram-size 2048 --code-size >>>>> 63487 --opt-code-size --profile -I/usr/local/sdcc/share/sdcc/include >>>>> -L/usr/local/sdcc/share/sdcc/lib/large SD_MMC.c >>>>> /usr/local/sdcc/share/sdcc/include/malloc.h:46: warning 187: ISO C90 >>>>> does not support flexible array members >>>>> sdcc --iram-size 256 --model-large --xram-size 2048 --code-size 63487 >>>>> --opt-code-size --profile -I/usr/local/sdcc/share/sdcc/include >>>>> -L/usr/local/sdcc/share/sdcc/lib/large main.rel adc.rel alarms.rel >>>>> bluetooth.rel dac.rel interrupt.rel timer.rel uart.rel eeprom.rel >>>>> temperature.rel lookup_table.rel motor.rel lonworks-compat.rel >>>>> velocity.rel vfd_lcd_led.rel vel_to_vol.rel pressure.rel humidity.rel >>>>> FAT_format_disk.rel FAT_File_System.rel String_Util.rel >>>>> flash_sect_serv.rel SD_MMC.rel >>>>> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area >>>>> OSEG. >>>>> ?ASlink-Error-Could not get 4 consecutive bytes in internal RAM for area >>>>> OSEG. >>>>> >>>>> >>>>> $ cat main.mem >>>>> Internal RAM layout: >>>>> 0 1 2 3 4 5 6 7 8 9 A B C D E F >>>>> 0x00:|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1| >>>>> 0x10:|2|2|2|2|2|2|2|2|a|a|a|a|b|b|b|b| >>>>> 0x20:|B|B|B|B|c|c|c|c|d|d|e|e|e|e|f|f| >>>>> 0x30:|f|f|g|g|g|g|g|g|g|g|h|h|h|h|h|h| >>>>> 0x40:|h|h|h|h|h|h|i|i|i|i|i|i|i|i|j|j| >>>>> 0x50:|j|j|k|k|k|k|l|l|l|l|l|l|l|l|l|l| >>>>> 0x60:|l|l|m|m|n|n|n|n|o|o|o|o|o|p|p|q| >>>>> 0x70:|q|q|q|q|q|q|q|r|s|s|s|s|s|t|Q|S| >>>>> 0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xc0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xd0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xe0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0xf0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S| >>>>> 0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, >>>>> S:Stack, A:Absolute >>>>> >>>>> ERROR: Couldn't get 4 bytes allocated in internal RAM for area OSEG. >>>>> Stack starts at: 0x7f (sp set to 0x7e) with 129 bytes available. >>>>> >>>>> Other memory: >>>>> Name Start End Size Max >>>>> ---------------- -------- -------- -------- -------- >>>>> PAGED EXT. RAM 0 256 >>>>> EXTERNAL RAM 0x0000 0x0593 1428 2048 >>>>> ROM/EPROM/FLASH 0x0000 0xbdf8 48633 63487 >>>>> >>>>> >>>>> >>>>> If interested, i can post .map, .mem, .sym, .lnk. >>>>> >>>>> Am I reading the error message correctly?: There is no more overlay >>>>> space? I have plenty of xram where I would think variables could be >>>>> allocated. >>>>> >>>>> >>>>> Should I be using different compile/link flags? My target processor is >>>>> analog devices ADUC842. >>>>> >>>>> Thanks.. >>>>> >>>>> -- >>>>> Karl Hiramoto http://karl.hiramoto.org/ >>>>> >>> ------------------------------------------------------------------------- >>> ------------------------------------------------------------------------- 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 Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
