Hi all, Could somebody please point me to a DPP-registers-for-dummies resource? I have read the application notes and datasheets etc. but they only mention that DPP registers -exist-. I'm still not sure -why- and -how- to use them. Our existing project uses them but I'm not sure why. I'm adding code to run the whole app from RAM instead of flash and I think I'm running into NDATA/near/DPP problems. - You can specify the NCONST and NDATA areas using the DPPUSE linker directive. It doens't seem to be possible to point DPP0 to 8000, DPP1 and 2 to 20000 and DPP3 to the usual segment3. Or did I do something wrong? - What's the difference between NDATA and NDATA0? How are they both defined? DPPUSE only mentions NDATA, the M66/map file also shows NDATA0. - Why is DPP supposed to be faster? Doesn't the compiler need to add DPP code for each access? - How can it be that "near" objects have to be in the first segment but DPP registers can point to way-up-high memory? - I'm still not sure how the _sof_() function fits in. If PEC pointers have to be in the first segment anyway, why do you have to use _sof_()? Isn't the segment always set to 0, leaving a 00'xxxx (=16bit) address? Regards, Joost Leeuwesteijn
JL:Our existing project uses them but I'm not sure why. I'm adding code to run the whole app from RAM instead of flash and I think I'm running into NDATA/near/DPP problems. CW:What device are you using? Perhaps a newer version of the compiler would help??? I've done some more reading and I understand it a bit better now. DPP's really go hand in hand with compiler and linker intelligence. I looked at some .lst assembly output and saw what the compiler generates. But how can a compiler put near MOV instructions in only 2 bytes? Does that include the MOV -and- the (14 bit?) address? Near data does not have to be in the first segment, you're right. I was having a problem with a video buffer that had to be in the first segement because of a PEC transfer (C167), I put it in near data which was outside the first segment; the video memory (external) is also mapped in the first 64k. I now moved the near data to below the 64k. The old code was using an undocumented BUSCON remap trick to put it both in 64k and higher up memory. I'm still have some other problems (strange video output (random flashing pixels) and a problem when I enable a CRC function which uses a xhuge pointer). I remember somebody pointing to information (app note?) about near pointer/xhuge pointer mismatches and their difficult to find problems. Does anybody know what that was about? It might help me. -- Joost
But how can a compiler put near MOV instructions in only 2 bytes? Does that include the MOV -and- the (14 bit?) address? If you look at the mnemonics of the C166 instruction set you can see that there are forms that consume only two bytes if you use a Register(s) or 4 bit constant. Otherwise you are correct you need more than 2-bytes. In the case where the address is in the opcode then you need 4-bytes. I'm still have some other problems (strange video output (random flashing pixels) and a problem when I enable a CRC function which uses a xhuge pointer). What is your support structure? Can't you go to your distributor or Infineon for help? Concerning an application note use the Keil search option to find the relevant info or ask a direct here in the forum. question.
JL:I'm still having some other problems (strange video output (random flashing pixels) and a problem when I enable a CRC function which uses a xhuge pointer). CW:What is your support structure? Can't you go to your distributor or Infineon for help? It's not so much a support issue, more a 'received complex software project without proper documentation' issue :-) We have to make some modifications now (memory map, ROM to RAM copy, etc.) and it's difficult to find out what's really happening underneath. Concerning an application note use the Keil search option to find the relevant info or ask a direct here in the forum. question. Tried that, but haven't been able to find the article/note I saw once. And you can't search on "near" because it's a search keyword :-) Don't know how to 'escape' it. I could start a new thread to attract more readers. Thanks, Joost Leeuwesteijn