Is it possible to use uPSD3354 option "DPTR Auto Toggle" and "DPTR Auto Increment" in my source code ? Problem: the standard interrupt header do not contain code for saving and initializing this options in DPTC a DPTM registers. Original "memcpy" uses only "manual" DPTR toggle and don't use auto increment of DPTR. Thank you.
Perhaps it's also worth mentioning that dual DPTRs don't lend much advantage in most situations
maybe 'most', but the throughput advantage for a (lenghty) XDATA to XDATA move is enormous.
Erik
Which of course is exactly why memcpy() is implemented using this feature, in the dedicated Keil runtime libraries for architectures that support it. By extension, that also covers the implied memcpy()s in struct assignments.
But with that base covered, there really isn't much gain left to be had. There is the occasional situation where you're juggling just enough objects that not needing to re-load DPTR all the time actually helps. Been there, done that (in asm, though), on a DS80C390 with 24-bit DPTRs. The difference between flipping DPS and saving/restoring 3 bytes of DPTR would really have hurt.
That's why I said memcpy() is a great example of where the dual DPTRs do come in handy.
Another example might be something like a CRC calculation with a table lookup, where one DPTR can point to the table of pre-calculated partial values, while the other advances through the buffer to be CRC'd.
The extra DPTR is not usually very useful in regular code that mixes accesses to different locals or global tables. MOV DPTR, #data16 is 2 instruction cycles, while the "INC DPS" method for swapping DPTRs is still 1 instruction cycle. It's just about as fast to load the base address of a variable as it is to try to cache it in the other DPTR.
To pay off, you need a routine that very frequently accesses two particular variables, particularly if the pointers retain state by moving through a buffer.
(The CRC example, for instance, isn't as convincing if you're talking about a CRC-32 with a one-byte lookup; that's a 1K table of partial results. So, you'll load the base DPTR, do some math on the index, add it, then fetch the table value with 4 MOVs. Since you change the DPTR, you'll have to reload it. The main advantage to two DPTRS is that you don't have to shuffle the buffer pointer back out. If, on the other hand, your table is small, and you can get away with the MOVC A, @A+DPTR addressing mode, then holding the base table address in the DPTR will pay off even more.)