This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Timer64 32-bit chained mode

Other Parts Discussed in Thread: SYSBIOS

Hello,

(target is C6678, SYSBIOS bios_6_41_01_36)

I'm using the Timers->timer64->timer module.

I've looked at the source code and I've a couple of questions

1) Why is the implementation of Timer_setPeriod lacking in features vs the Timer_setPeriodMicrosec function ?

The Timer_setPeriod doesn't really support the 32-bit chained mode (where you need to configure both PRDHI and PRDLO.

It should be better implemented and at least documented. There is a major difference of features between the two functions.

2) In Timer_setPeriodMicrosec there is this code which truly manage the 32-bit chained mode

        pscCounts = counts >> 32;
        if (pscCounts) {
            shift = Intrinsics_maxbit(pscCounts) + 1;
            pscCounts = (1 << shift) - 1;
        }
        prdCounts = (counts >> shift);

with PSC the prescaler counts (PRDHI) and PRD the low period counts. Counts is an unsigned int on 64 bits.

What this code is solving, is the following problem :

given a 64 bit number A, find two 32-bit numbers B and C for which A = B x C

But mathematically speaking I don't understand the algorithm implemented.

Can someone explain it ?

Regards,

Clement

  • Clement,

    1.  Timer_setPeriod takes a 32-bit period value so it won't do anything with the prescalar.  Unfortunately, Timer_setPeriod is a generic API across all SYSBIOS architecture so it cannot change.  So guess what I'm saying is that you won't be able to set the 'prescalar' value using Timer_setPeriod.  A possibility would be to have another api that sets just the prescalar value in the case the chained mode case but we haven't had any request for it.

    2.  If you look at how the prescalar works on this part...everytime the count12 reaches the period12, it increments count34 by 1 and count12 is reset to 0.  When count34 reaches period34, it generates an interrupt.  So now lets just take an example:

    Lets say the part is running at 1.0 Ghz, and I want a period of 5secs (5,000,000 usec).  Of course I picked these numbers because it causes the PRD count to be more than 32bits.

    counts = ( freqKhz * period / 1000 )  so that would be (1,000,000 * 5,000,000 / 1000) = 5,000,000,000 = 0x12A05F200

    shift = 0 + 1;

    pscCount = (1 << 1) - 1 = 1

    prdCounts = counts >> shift = 0x12A05F200 >> 1 = 0x9502F900 = 2,500,000,000.

    So, we would put 2,500,000,000 in PRD12 and 1 in PRD34 to achieve a period of 5,000,000,000 (usec) or 5 seconds.

    Hope the helps some.

    Judah

     

  • Thank you for your answer Judah, as always.

    1) yes I was surprised to not see a Timer_setPrescaler function. Documentation of Timer_setPeriodMicrosec should clearly tell the user that in 32-bit chained mode it handles both the PRD and prescaler. Right now to set the prescaler we can only call Timer_setPeriodMicrosec or the reconfig function.
    I guess it is seldom used by customers.

    2) I've done a similar example and yes I see how it works. I think it's a clever implementation but I was wondering how the software dev came up with this solution, mathematically speaking. I guess you won't know the answer but maybe you know the guy who implemented it.

    Clement.