[Dspforum] CIPR question

Tue Nov 3 18:41:06 MST 2009

I think "fudge factors" floating around in code should be avoided, because
someone later has to ask the question "huh -- why is that times 2" in there?
And inevitable, it leads to the wrong conclusion (you can imagine someone
without much idea of what is going on saying something like "I bet it is
because these numbers are complex!").

The intent of TCC_PING/PONG was that they were in units "bit to set". I.e.,
they would be written to the OPT register in the appropriate field, and when
they are used to access the appropriate bit they would be used like:

1 << TCC_PING/PONG

Joseph

On Tue, Nov 3, 2009 at 6:03 PM, Alan Ding <alan33d at gmail.com> wrote:

> Sorry for the confusion.
>
> In my init_input_dma_channel code, I set:
>
>  EDMA_FMK(OPT,TCC,tcc)//Transfer Complete Indication, values between 0000b
> to 1111b
>
> where tcc is a Uint32 passed in as TCC_PING or 1;
>
> The code that was given to us had:
>
>  start_edma_input();  // init_input_dma_channel(&hEDMAStart, TCC_PING,
> ping, EDMA_getTableAddress(hEDMA_PONG));
>  cnt = waitfordma(TCC_PING);
>
> So I need to change that to:
>
>  start_edma_input();  // init_input_dma_channel(&hEDMAStart, TCC_PING,
> ping, EDMA_getTableAddress(hEDMA_PONG));
>  cnt = waitfordma(TCC_PING*2);
>
> that should fix my waitfordma hanging issue.
>
> ~Alan
>
> On Tue, Nov 3, 2009 at 3:22 PM, Wenstrand, Doug S. <
> Douglas.Wenstrand at jhuapl.edu> wrote:
>
>>  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> 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] *On Behalf Of *Wenstrand, Doug S.
>> *Sent:* Tuesday, November 03, 2009 11:21 AM
>> *To:* 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] *On Behalf Of *O'Connor, Sean R.
>> *Sent:* Tuesday, November 03, 2009 10:21 AM
>> *To:* 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
>> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>>
>>
>>
>>
>> --
>> -------------------------------------------------------
>> Alan Ding
>> Master of Sci, Electrical Engineering
>> Johns Hopkins University
>>
>> Email: alan33d at gmail.com
>> Contact #: 4844593290
>>
>> _______________________________________________
>> Dspforum mailing list
>> 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
> Contact #: 4844593290
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091103/082fb8e4/attachment.html>