JohnSanderson wrote: > Fair enough. Microchip make these processors so I tend to > let them lead by example. Please stop indenting all your reply text with a bunch of spaces. It makes your text look ugly when it gets re-wrapped on other people's displays. Worse, it makes my reply look messy unless I go out of my way to fix your text, which I'm not going to do anymore. As for your point, Microchip examples often suck. Read the manual, understand how things work, then you don't need Microchip's or anyone else's examples. >> Huh? That makes no sense. How does the table read mechanism force >> these? I have used table reads many times and never defined named >> sections in the linker file for that purpose. > > It didn't make a lot of sense to me either to begin with. It > was done because I > couldn't find another easy way to make table reads cross page > boundaries. > It _doesn't_ mean there is no better way. It just means this > was the first > means I found to do it reliably. So I left it at that. Put down the dead fish and stop treating this stuff like magic. You need to sit down and read the manuals. You are playing with too much stuff you don't understand. The MPASM/MPLIB/MPLINK manual is well written and to the point. Read it. >>> The unassigned GPRs are loaded from 0x000500+. >>> These addresses are confirmed within the watch window but never >>> show any value other than 0x00. > > Semantics. No! Your imprecise description has caused the help you seek to be delayed, and more importantly the time of those trying to help you wasted. There is a big difference between something not showing in the watch window, which is what I thought your complaint was, to it showing 0. Didn't it ever occur to you that it was showing zero precisely because the value actually was zero and there is a problem with your code!!? > The data shown for each address above 0x000200 only shows > 0x00. Never anything else. OK, so go figure out why you aren't setting those locations to other values. Figuring the tools are wrong should be the last thing after you're very very sure you know exactly what's going on and have some solid proof and test cases. Generally anyone that has to ask here should simply assume the tools are working correctly. Newbies need not apply at all. > To me, a great benefit of using relocatable code is that one > does not > have to worry much about banking of program or data. > The linker sorts that out at compile/link time, provided the > programmer > sets up things correctly. Read the manual. Once again you don't understand what the assembler and linker each do and what kind of information they pass to each other. In relocatable mode, the linker can allocate sections to banks as it sees fit. You know nothing about the address of these variables at assembly time, except that each section will be wholly in one memory region as defined in the linker file. Or, if you put variables in named sections defined per bank in the linker file (like the .BANKn sections in my linker files), then you have the linker allocate variables as it sees fit within the bank of your choosing. You know the bank at assembly time, but not the address within the bank. Either way, the machine must still be set to the proper bank at run time to access a variable in banked (not access bank) memory. This doesn't happen by accident or magic, although waving the right kind of dead fish during a full moon works. Since the exact species of fish is difficult to guess, the more reliable way of using BANKSEL is preferred. > To re-iterate, I have run older `Tried-and-Tested' code thru > this process and had the same results. I don't know anything about your "tried and tested" code, so this isn't evidence of anything useful. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist