[Dspforum] CIPR question

[Wenstrand, Doug S.]

That doesn't specify any writes to the EDMA options register, so I don't see any inconsistency.  Init_input_dma_channel is just a function, the inside of it is where we have to be consistent.
Key is - if you are waiting for a 1 (i.e. the 0 bit to appear in the CIPR) you better set the TCC to 0 when writing the options register.  Similarly if you are waiting for a 2, (the 1 bit) then you should set TCC to 1.


From: dspforum-bounces at echelonembedded.com [mailto:dspforum-bounces at echelonembedded.com] On Behalf Of Alan Ding
Sent: Tuesday, November 03, 2009 2:59 PM
To: dspforum at echelonembedded.com
Subject: Re: [Dspforum] CIPR question

Wait, I don't get it then.

If the code that was handed to us had:

#define TCC_PING   1
#define TCC_PONG   2

 start_edma_input();  // init_input_dma_channel(&hEDMAStart, TCC_PING, ping, EDMA_getTableAddress(hEDMA_PONG));
 cnt = waitfordma(TCC_PING);

Shouldn't it actually be:

 cnt = waitfordma(TCC_PING*2);  //CIPR is 2*1 or 2 in this case

according to what you just said?  Or else waitfordma would be in an infinite pending state?


Thanks,
~Alan
On Tue, Nov 3, 2009 at 12:34 PM, O'Connor, Sean R. <Sean.OConnor at jhuapl.edu<mailto:Sean.OConnor at jhuapl.edu>> wrote:
Yes, this makes sense.  I wasn't thinking of the CIPR register as 16 locations, or essentially like 16 complete flags.  I will investigate tonight why I'm getting both transfers completing before I check the CIPR.  Thanks!

________________________________
From: dspforum-bounces at echelonembedded.com<mailto:dspforum-bounces at echelonembedded.com> [mailto:dspforum-bounces at echelonembedded.com<mailto:dspforum-bounces at echelonembedded.com>] On Behalf Of Wenstrand, Doug S.
Sent: Tuesday, November 03, 2009 11:21 AM
To: dspforum at echelonembedded.com<mailto:dspforum at echelonembedded.com>
Subject: Re: [Dspforum] CIPR question
Bits 19-16 of the options register are the Transfer Complete Code.  Those 4 bits are a number from 0-15, which specify which bit in the CIPR gets set when the transfer is complete.
So you are setting bits 2 and bit 1 of the CIPR respectively, so if you read the CIPR, you should see either a 4, or a 2 (bits 2 or 1 being set)  When you read a "6" its because both are set, meaning both transfers are complete.  This could be because you didn't check soon enough and they both finished, or because you didn't clear the CIPR bit after using it.

Make sense?
Doug


From: dspforum-bounces at echelonembedded.com<mailto:dspforum-bounces at echelonembedded.com> [mailto:dspforum-bounces at echelonembedded.com<mailto:dspforum-bounces at echelonembedded.com>] On Behalf Of O'Connor, Sean R.
Sent: Tuesday, November 03, 2009 10:21 AM
To: dspforum at echelonembedded.com<mailto:dspforum at echelonembedded.com>
Subject: [Dspforum] CIPR question

Setting the OPT registers for ping and pong to 0x20320002 and 0x20310002 should set CIPR to 2 and 1 when the transfers have completed, I think.  CIPR is actually getting set to 6 and 4 respectively, and if I use 6 and 4 as my masks things seem to operate as expected (at least ping and pong get updated and waitfordma() does not hang).  To my knowledge the OPT register is the only register that can effect the CIPR... so this discrepancy is confusing to me.  Any thoughts?

Thanks,
Sean


_______________________________________________
Dspforum mailing list
Dspforum at echelonembedded.com<mailto:Dspforum at echelonembedded.com>
http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com



--
-------------------------------------------------------
Alan Ding
Master of Sci, Electrical Engineering
Johns Hopkins University

Email: alan33d at gmail.com<mailto:alan33d at gmail.com>
Contact #: 4844593290
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091103/570ad553/attachment-0001.html>