Kurt, Remove the --iram-size 128 so you can still use the high internal ram for idata variables and stack. Otherwise everything must be crammed into the first 128 bytes.
Maarten > Maarten; > > Thanks. I had remembered reading that the stack used idata and could be > mapped into the upper 128 bytes but didn't realize data and idata were > different. I also see where data access to the upper 128 bytes maps into > the CY7C68013's SFR space. > > I assume if I set iram-size to 256 I need to set the location to zero. > (duh my bad early senior moment). > > Here I've set iram-size to 128 and iram-loc to 128 to get the stack into > the upper 128 and leave the lower 128 for data only. Also eliminated > using Register Bank 3 and let the compiler pack the data variables. Then > rewrote two functions to eliminate passing parameters and reduce the data > memory size required. > > So much for elliminating global variables for good programming practices. > It doesn't make much sense to do so at this level as both the global > variables and the additional passed parameters ended up at fixed locations > in data memory thereby doubling the memory required. > > Also for reference the code is started at 0x0500, to leave room for an asm > program which is used to locate interrupt vectors and USB Jump Vectors > starting a 0x0000 similar to Cypress's examples. Then xdata is placed at > 0x3600 to keep it above the code memory and yet stay within the Cypress > CY7C68013's 16 kbytes of internal RAM. > > Link command line: > sdcc -mmcs51 --model-small --iram-size 128 --idata-loc 128 ^ > --code-loc 0x0500 --xram-loc 0x3600 ^ > -L c:\SDCC\MyCode\EZ-USB_Lib -l EZUSB -I C:\SDCC\Include ^ > fw.rel myStart.rel dscr.rel D2A_A2D.rel gpif_D2A_A2D.rel ^ > crtpagesfr.rel myInit.rel myErrorCode.rel > > Memory Map: > 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|c|c|c|c|c|c|c| | > 0x20:|B|B|B|B|a|a|a|a|a|a|a|a|a|a|a|a| > 0x30:|a|a|a|a|a|a|a|a|a|a|b|b|b|b|b|b| > 0x40:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b| > 0x50:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b| > 0x60:|b|b|b|b|b|b|Q|Q|Q| | | | | | | | > 0x70:| | | | | | | | | | | | | | | | | > 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 > > Stack starts at: 0x80 (sp set to 0x7f) with 0 bytes available. > > Other memory: > Name Start End Size Max > ---------------- -------- -------- -------- -------- > PAGED EXT. RAM 0 256 > EXTERNAL RAM 0x3600 0x36c4 197 65536 > ROM/EPROM/FLASH 0x0000 0x2fca 11412 65536 > > Thanks again for all the help and suggestions. I might actually want to > do another embedded design someday. > > Kurt; > > > > > Hi Kurt, > > I think you misunderstand the keywords data and idata > and did not fully graps the (im)possibilities of the > 8051 internal ram. Data memory is only 128 bytes big and > it shares space with the registers and bit variables. In > the upper 128 bytes you can only have idata variables > and stack. When using --pack-iram, the stack is > automatically placed after all data and idata variables. > > --idata-loc 256 is impossible. There are only 256 > addresses (0-255) available. > > My recommendation is move some variables to > idata/pdata/xdata. > > Maarten > > > We was compiling fine, made a few additions, and now we're out of room. > We > > are using a Cypress CY7C68013 with 256 bytes of iram and don't believe > we > > should be out of room. > > > > Exact error message is "?ASlink-Error-Insufficient space in data memory. > 9 > > bytes short." > > > > Link command line is in a dos batch file. carrot (^) does a line extend; > > > > sdcc -mmcs51 --model-small --iram-size 256 --idata-loc 256 ^ > > --stack-loc 0xA0 --no-pack-iram ^ > > --code-loc 0x0500 --xram-loc 0x3600 ^ > > -L c:\SDCC\MyCode\EZ-USB_Lib -l EZUSB -I C:\SDCC\Include ^ > > fw.rel myStart.rel dscr.rel D2A_A2D.rel gpif_D2A_A2D.rel ^ > > crtpagesfr.rel myInit.rel myErrorCode.rel > > > > We've set iram size to 256 but it doesn't appear that the compiler will > > let me use it for data memory. Without the stack location change we get > > > an error that we were 14 bytes short. Is there a compiler limit that > does > > not allow for more than 128 bytes of variables? Added the no pack iram > > option when we moved the stack to no avail. We'ld like to use pack to > get > > the register space back but then it doesn't let us move the stack into > the > > upper 128 bytes? It seems a shame to have 256 bytes of RAM and not be > > able to have the compiler assign it. > > > > The last thing tried was to pack, eliminate using 3, and move the stack > to > > 0x7f, 0x7e, and 0xa0. With packing the stack move doesn't appear to > work > > and its allocated to 0x0000 when the data memory is "out of room". The > > iram size doesn't seem to allow the stack to be placed above 0x80 when > > pack is enabled. > > > > Any help is welcome. Thanks. (otherwise we'll have to eliminate a few > > variables, using 2, etc., or maybe assign fixed addresses for a few > > variables in the upper 128 bytes, then assign the stack in the upper 128 > > > bytes, and use the no pack iram option.) > > > > sdcc version is > > SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > > 2.9.2 #5524 (Sep 28 2009) (MINGW32) > > > > Running under Windows XP. > > Kurt M. Sanger > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
