Post by thread:[PIC]: EmdInc dev env and the GFLn variables.

To someone who have built some project in Olins dev.envir... I have some trouble with my first project (using 16F628) It uses the /FLAG directive. This should define some asambler symbols so that you should be able to use the bit-instructions easily. Now, whatever I do, it always seems as the rellevant symbols (GFL0, GFL1) allways starts frorm addres h'00'. I'd expect them to start fro h'20' or 'h70' or something. This is verified by looking at the actual instructions generated. The flag_define macro should set things up correctly. There must be something that tells this macro the "base-address" of the global flags. I *thought* it was "gbankadr" which I have tried to change to H'20' in my *.ins.aspic. I could not see any difference. Well, I'm sorry I realy don't know what to ask about, but if someone has used the \FLAG directive successfully I'd like to know if you did anything special. Regards Jan-Erik. PS. Before anyone asks, no, I didn't find anything about this in my (PDF) manual either :-) :-) DS. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Well, after some further digging (in the .map file), I found that the GFL0 and GFL1 symbols actualy has the values 0x000020 and 0x000021 there, as expected... I looked in the .lst file where the generated instruction is "bcf 0,2". The "2" is expected since this is the third flag defined, but I expected h'20' instead of the "0". And the symbol section of the .lst file states that the GFL0 and GFL1 symbols both has the value 0x000000. Might it be that the linker changes the actual instructions after the assembler has done it's job ? Later, Jan-Erik. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>Well, after some further digging (in the .map file), >I found that the GFL0 and GFL1 symbols actualy has >the values 0x000020 and 0x000021 there, as expected... > >I looked in the .lst file where the generated instruction >is "bcf 0,2". The "2" is expected since this is the >third flag defined, but I expected h'20' instead of the "0". just remember that the .lst file for only for the module you have assembled. The complete memory map cannot be worked out until the linker can match the different memory areas to the control file that defines where they are, which is why it is only in the .map file that you can see the addresses you expect. If you do a hex dump of the .cof files you will find lots of information the linker uses to match the items it cannot determine at assemble time, to the memory map contained in the processor map file, and from that fills in the value which you thought was incorrect. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Thanks for clearing that out. I now *do* think that I have done something wrong myself... Back to "classic" debugging :-) Jan-Erik. Alan B. Pearce wrote: > The complete memory map cannot be worked out until the linker can match the > different memory areas to the control file that defines where they are, > which is why it is only in the .map file that you can see the addresses you > expect. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body