DPP, near, NCONST, NDATA, speed, DPPUSE directive

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

Parents
  • Please point me to a DPP-registers-for-dummies resource
    Ok, I will speak from an Infineon point of view. Have you really read the user's manual and do not understand it?

    - Why is DPP supposed to be faster?
    This depends on where the memory is being executed? Basically the mov instruction using the DPP is only two bytes. Depending on how the instruction is in the instruction buffer an extended data access command (EXTP or EXTS) which are atomic but could result in more than a single machine cycle to execute. It definitely affects your code density.

    Doesn't the compiler need to add DPP code for each access?
    No, DPP's are a short addressing mode. Once the particular DDP is loaded you don't need to change it while working within the 16 Kbyte data range. This is the whole reason why you should never touch DPP3 as this provides DPP access to all the SFR's etc… and you have classes such as NDATA or NCODE…

    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.
    What device are you using? Perhaps a newer version of the compiler would help???

    - What's the difference between NDATA and NDATA0? How are they both defined? DPPUSE only mentions NDATA, the M66/map file also shows NDATA0.
    Both are near but as the name implies the NDATA0 is zero-initialized.

    If PEC pointers have to be in the first segment anyway
    This is not true for XC16x devices, the PEC now has 24-bit addressing. Ok, I use the _sof_() function to get a the offset of a pointer within a segment, but I don't use if I initialize a PEC within the first segment.

    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 am not aware of a limitation to only have near objects in the first segment?

Reply
  • Please point me to a DPP-registers-for-dummies resource
    Ok, I will speak from an Infineon point of view. Have you really read the user's manual and do not understand it?

    - Why is DPP supposed to be faster?
    This depends on where the memory is being executed? Basically the mov instruction using the DPP is only two bytes. Depending on how the instruction is in the instruction buffer an extended data access command (EXTP or EXTS) which are atomic but could result in more than a single machine cycle to execute. It definitely affects your code density.

    Doesn't the compiler need to add DPP code for each access?
    No, DPP's are a short addressing mode. Once the particular DDP is loaded you don't need to change it while working within the 16 Kbyte data range. This is the whole reason why you should never touch DPP3 as this provides DPP access to all the SFR's etc… and you have classes such as NDATA or NCODE…

    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.
    What device are you using? Perhaps a newer version of the compiler would help???

    - What's the difference between NDATA and NDATA0? How are they both defined? DPPUSE only mentions NDATA, the M66/map file also shows NDATA0.
    Both are near but as the name implies the NDATA0 is zero-initialized.

    If PEC pointers have to be in the first segment anyway
    This is not true for XC16x devices, the PEC now has 24-bit addressing. Ok, I use the _sof_() function to get a the offset of a pointer within a segment, but I don't use if I initialize a PEC within the first segment.

    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 am not aware of a limitation to only have near objects in the first segment?

Children
More questions in this forum