Hi Matt, Great that you found a way around the "memory full" issue. I am doing my dsp coding in assembly, need to for speed, and for memory management also. Its amazing how much you can fit into the 21065L when you throw away the C compiler, and do it in assembler. Anyway, two comments on the way you shrunk your memory, and a little eye opener to others. When doing things in Assembler, you will end up taking a lot of short cuts, e.g. the way you position arrays in memory. For example, if you have a receive filter and a tx filter, you may put them in memory where the rx is first, and the tx follows it immediately. Then, based on mode (rx or tx) you may pick the rx or rx+@rx, giving the tx data. To some this may sound strange, but it saves space and allows re-use of many algorithms that would have been split up. Hence, saving lots of space. BUT, this trick, will kill you when you enable elimination. Since you never refer to the tx label in the code, it will get eliminated.Meaning whatever gets located after the rx will be used as the tx filter. Not a good position. You can set up a bogus reference to the location, then it is not eliminated. Whether you buy this kind of trick or not, its totally up to you, and I'm not going to argue about why or why not. But the point I want to make, is that if you turn on elimination, you had better go through your output code, and test each path again just to make sure that the data you wanted is still included, and that the code is 100% there. I have fallen into a trap in the past where the eliminator also eliminated some C code that wasn't called from a C function, but from an assembler function. Just be careful with elimination, is all I'm saying, and double check everything again. Or you will find something doesn't really work, it just appears to work because the data following it is close to what is required to make the function work, but when you recompile it again for production, then nothing works. Trust me, its happened before. Almost the same can be said for allowing the linker to locate things into memory across the two banks. One thing I found out is that if you completely use the IDE for your assembles/links, the linker puts things into the given memory segment based on the lexical of the filename. Meaning if you have the following files: aamain system version menu barf It will put them into the memory in the order of aamain barf menu system version. This may not seem like a problem, but imagine where the size of aamain, barf, and menu = half of the size of bank0. Then system size is = half of the size of bank0+1. This means that it will put aamain, barf, menu into bank0, and system, version into bank1. Not a problem it will all fit. NOT. If you use bank1 also for even just 10 bytes of 16bit data, then already half of bank1 is gone, and therefore your program, which is only the size of bank0 + 1 instruction, will not fit within memory. Notice how I utilized aamain as the name for the main program/main loop. It will not run at all if I put it as file name main, meaning it would have been put much later into bank0 or bank1. Another wonderful problem, main loop won't execute if in bank1. Again, be careful of location of files in memory. So be careful how you use these memory optimization techniques, they can bite you hard, and leave you scrambling to code crunch when all you need to do is to create more than one code segment, place each file you want into a given segment as size allows. After that, given that still not enough memory for the final touches, you may have to pursue overlays in assembler. I have now seen that it can be done, and allows me to use the small memory of this 21065L for features I would never have dreamt possible given its small memory. But yes, have to take care of overlaying functions or features that are execution time independent. e.g. if you have a setup system that only sets things up, and a running real time system that takes that data and runs, well, overlay them. If you have a feature that only runs upon user demand, you could overlay that again on top of the other two. PLIT is the way. Anyway, hope my ramblings have helped shed a little light for others on pitfalls you can encounter, and some techniques that could help. I'm sure there are others. John Henry KI4JPL --- In adsp@adsp..., "Matt Weber" <mweber@a...> wrote: > Hey Everyone, > > I've got a fix for my problem, and thanks for all of your help. Here is the > low-down on how to get around output segments that are full: > > "First of all, you should try to use linker elimination to reduce the > footprint of your application. > > If what you trying to accomplish is to split a big library into > different memory segments (e.g. block0 and block1), linker "one input > section -> many output sections" feature can be used to accomplish that. > > For example: > > Pmco0 { > ... > INPUT_SECTIONS($OBJECTS(seg_pmco)) > ... > } > block0_pm > > Pmco1 { > ... > INPUT_SECTIONS($OBJECTS(seg_pmco)) > ... > } > block1_pm > > Linker will fit 'seg_pmco' sections that do not fit into 'block0_pm' > into 'block1_pm'. > > Using overlays does NOT seem like a viable option in your case. In order > to use overlays, the application should be dividable into units based on > execution time behavior. E.g. one part of application used during one > phase, another part is used during another phase, etc. > > You can find more details in the help topic for li1040 linker error > message." > > Hope this helps Everyone. Creating an external segment and using this method > worked for me. > > -----Original Message----- > From: adsp@adsp... [mailto:adsp@adsp...]On Behalf Of Jon > Harris > Sent: 18-Aug-05 9:23 AM > To: adsp@adsp... > Subject: Re: [adsp] 21065L w C code... seg_pmco full of libc.dlb, > libio.dlb and source > I'm assuming you are using VDSP++ 4.0. If so, under Project > Options-Elimination, make sure you have Eliminate unused objects checked. > This > should remove any functions that are included in a library but not actually > called. It also removes variables that are deemed unused, which can > sometimes > cause problems with debuggig, so be careful. > > --- mattw_024 <weberms@h...> wrote: > > > Hello Everyone, > > > > Just had a question for you relating to mapping my code into memory. > > Previously I had developed my code on the 21060 because it had more > > internal memory space for my code, however now that I have finished > > developing the code I wanted to put it into the 21065L which is the > > processor I need to use. > > > > This is my problem: the seg_pmco section contains 0x3c62 words that > > are > > not being mapped to memory due to the code being too large to fit. > > (Obviously because there is so much code, just making the segment > > larger > > will not work because there isnt that much internal memory to work > > with). I had a similar problem in seg_dmda, which I solved by moving > > some of the data to an external segment I created (in the ldf). I > > attempted to do the same thing with the seg_pmco, but with no success. > > This was because I have libio.dlb and libc.dlb in that segment, which > > are very large, along with a lot of other code which is specific to my > > program. libc.dlb and libio.dlb do not appear to be movable, when > > using > > the expert linker. I tried to use the elfar utility to dissassemble > > those libraries so I could move the *.obj files individually. Im > > still > > working on that, but is there any better way to do this? Would using > > memory overlays be helpful? I'm a little unclear as to how I should be > > treating this, and Im sure there are many other pople who have run > > into > > similar problems since those *.dlb's are quite large. Let me know if > > using the elfar utlity to break those up into *.obj's is the way to > > go... if not what do you suggest? Thanks a lot. > > > > Sincerely, > > > > Matt Weber > > __________________________________________________ > > __________________________________________________