We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi I want to use the second data pointer available in Dallas, since i am reading my port and then immediatly writing this data to external ram.All this has to be done in ISR in 10us. I am using in line assembly but the code is not working when i use both data pointers. void external0(void) interrupt 0 using 1 { //TRACK1[LEN_TRK1++]=XBYTE[0x8000]; //TRACK1[LEN_TRK1++] = XBYTE[0x8001]; //The above two C statements are replaced by the below mentioned Assembly code #pragma ASM SETB DPS ; DPS=1 ACTIVE DPTR1 MOV DPTR,#08000H MOVX A,@DPTR ; READ INC DPTR CLR DPS ; DPS=0 ACTIVE DPTR0 MOV DPL,LEN_TRK1+01H MOV DPH,LEN_TRK1 MOVX @DPTR,A ; WRITE INC DPTR SETB DPS ; DPS=1 ACTIVE DPTR1 MOVX A,@DPTR ; READ CLR DPS ; DPS=0 ACTIVE DPTR0 MOVX @DPTR,A ; WRITE INC DPTR MOV LEN_TRK1+01H,DPL MOV LEN_TRK1,DPH #pragma ENDASM } Thanx Faisal
I think this discussion has lost the woods for the cause of the tree. When copying a byte or two, very little time spent either way and it is easy to make the two approaches (almost) equally fast. If you are copying, say, 112 bytes from one place to another (I do, as part of a string reformatting routine) it is definitely faster to use 2 data pointers, than the code from the compiler.
loop: movx a,@dptr inc dptr ; do something to the accumulator inc auxr movx @dptr,a inc dptr inc auxr djnz r7,loop
A long time ago, I profiled the execution performance of the dual data pointers on the Dallas 320. I think that the break-even is somewhere around 5-6 bytes. That's why I tried to point out that using dual data pointers for only 2 bytes is overly complex and doesn't gain anything. For larger buffers, I agree that dual data pointers speed things up. Jon
"I think this discussion has lost the woods for the cause of the tree." Well yes Erik, but lets be more positive Jon & Jon took the discussion off on a second and interesting line by 'raising to the challenge'. I wouldn't disagree with JW that the break-even point is around 5 or 6 bytes. Efficient and complete C code for an application that can benefit from dual dptrs is another point. We don't necessarily have to answer every point the original question could rise; not that I wish to stop anybody raising to that challenge. In my mind there is also still the question - Will the compiler handle the problem of saving the context (i.e. pushing both dptrs) in an ISR. I suspect not but don't have time to investigate at the moment.
To see the worst case "context saving", just put in an external fn call. If you set the "use dual dptr" option, you get:
extern void fn(void); void external0(void) interrupt 0 using 1 { fn(); } ; FUNCTION external0 (BEGIN) 0000 C0E0 PUSH ACC 0002 C0F0 PUSH B 0004 C083 PUSH DPH 0006 C082 PUSH DPL 0008 C085 PUSH DPH1 000A C084 PUSH DPL1 000C C086 PUSH DPS 000E 758600 MOV DPS,#00H 0011 C0D0 PUSH PSW 0013 75D008 MOV PSW,#08H ; SOURCE LINE # 11 ; SOURCE LINE # 13 0016 120000 E LCALL fn ; SOURCE LINE # 14 0019 D0D0 POP PSW 001B D086 POP DPS 001D D084 POP DPL1 001F D085 POP DPH1 0021 D082 POP DPL 0023 D083 POP DPH 0025 D0F0 POP B 0027 D0E0 POP ACC 0029 32 RETI ; FUNCTION external0 (END)
Yep. With only 2 data pointers, you can get into a lot of crazy situations saving and restoring both data pointers. The infineon 515 has 8 data pointers so you have 2 that are available for each register bank. That kinda makes things better. However, the best utilization of dual data pointers is for moving memory like you would do with memmove, memcpy, and so on. Jon