Array Synchronized EDMA

Edwin-

> I did the following thing in the HSYNC ISR:
>
> if (Y > {
> Uint32 id;
> DAT_open(DAT_CHAANY, DAT_PRI_HIGH, 0);
> id = DAT_copy((void *)&src[Y][0],(void *)0xA0000000,4*no_of_pixel);
> DAT_wait(id);
> DAT_close();
> }
> Y++;
>
> This method really can the thing I want, the colour pattern can be
> displayed, and no need to configure any EDMA channel at all, very simple!
>
> However, since the transfer request is still depended on the CPU
> (interrupt->ISR->DAT->EDMA), two problems are introduced. (1) The CPU
> wastes resource at DAT_wait() and cause the CPU utilization increased
> to 75%. (2) Sometimes the CPU seems cannot handles the ISR in same
> speed (not sure), some lines are shifted to the right (delayed?).
>
> The second problem I had seen before, at that time I configured the
> EDMA and made the transfer request by CPU (set ESR) in HSYNC ISR,
> and every times the channel transmitted the same array. This problem was eliminated after changed to "event triggered transfer request" instead of "CPU triggered".

Can you move DAT_open() (everything but DAT_copy) outside the ISR? You should be
able to open a channel id, keep it open indefinitely, and re-use. The only concern
then in the ISR would be making sure the previous DAT_copy() has finished before the
next HSYNC interrupt. With your current timing it seems you don't have to worry
about that.

The advantage of the above approach is that you can use C code to combine VSYNC and
HSYNC as needed. Are you using VSYNC interrupt to reset Y (counter) to zero? If so
that's what I mean.

-Jeff

>
> That's why I really need the transfer be fully automated! Is it really
> cannot configure the channel transfer one array in the 2D array when
> a event is triggered? If so, I may need to think another way... Start a New Thread