• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 488 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Frequency measurement cap

Charles Miles
Prodigy 245 points
Other Parts Discussed in Thread: HALCOGEN

The frequency of an input signal from an external source is being calculated by my tms 470mf067 usb device.  

To do this, I am using the ECNT algorithm of the HET in parallel with the RTI peripheral.

The following output was generated by stepping the frequency from 8.2MHz to approximately 4MHz.  Clearly, the number of ticks/sec measred by the device is inacurate above 1.2MHz.  

Here is my project:  7318.CharlieTiming2.zip  (the home made computation algorithms are implemented in charlie.c)

  • 0
    TI__Mastermind 20870 points

    Charlie,

    I have found a table on the minimum period detected by the HET:

    For loop resolution pins: the minimum period is 2*hr*lr*tVCLK2 which would give you 2*64*1*12.5ns = 1.6us (or 625KHz) for a loop resolution prescaler of 64, a high resolution prescaler of 1 and an 80MHz VCLK2.

    For a high resolution pin: the minimum period is 1*hr*lr*tVCLK2 which would give you 64*1*12.5ns = 0.8us (or 1.25MHz) for a loop resolution prescaler of 64, a high resolution prescaler of 1 and an 80MHz VCLK2.

    Assuming the high resolution feature is enabled, I agree with your calculations (given the HET configuration).

    Regards,

    Forum Support

  • 0 in reply to Kevin Lavery
    Prodigy 245 points

    Is there a diffent LR prescaler value that would grant higher frequency capability?

  • 0 in reply to Charles Miles
    TI__Mastermind 20870 points

    Charlie,

    The HET executes the instructions with each instruciton taking a set number of cycles (see Section 12.7, Table 12-36 of SPNU495A for the cycles per instruction). Each loop must contain at least this many cycles (hr*lr).

    At a high level, you cannot reduce the LR prescaler without reducing the number of instructions.

    Regards,

    Forum Support

  • 0 in reply to Kevin Lavery
    Prodigy 245 points

    How can I get rid of the instructions that I don't need without breaking [HalCoGen's] functions:

    edgeResetCounter();

    edgeGetCounter();

    ?

  • 0 in reply to Charles Miles
    Prodigy 245 points

    nevermind, I got it to work.

    Answer: Erase the unnecessary instructions from the array, change HalCoGen's functions (to look at the new locations of the relevant data - SEE BELOW) and set the LR value within the PFR to a lower value.

    BEFORE: 

    unsigned edgeGetCounter(unsigned edge)
    {
    return hetRAM->Instruction[edge + 17U].Data >> 5U;
    }

    AFTER:

    unsigned edgeGetCounter(unsigned edge)
    {
    return hetRAM->Instruction[edge].Data >> 5U;
    }

    NOTE: The relevant instruction is now in the first slot of HalCoGen's array (hetPROGRAM[])

    PS: It is now accurate to approx. 3.8 MHz with a LR prescale factor of 4 (hetPFR = 0x00000200)

  • 0 in reply to Charles Miles
    Prodigy 245 points

    But according to your calculation I should be able to go to a really high frequency?

    "1*hr*lr*tVCLK2 which would give you 64*1*12.5ns = 0.8us (or 1.25MHz)"

    hr*lr*tVCLK2 which would give you 4*1*12.5ns = 50ns (or 20MHz)

  • 0 in reply to Charles Miles
    TI__Guru 59540 points

    Hello Charles,

    I marked your solution as verified so others can utilize the knowledge shared on the E2E forum. In regard to your last post, are you still looking for an answer on this?