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.

RM48L952, N2HET and PCNT instruction's HR Data Field

Hi,

I wish to capture the width of a pulse, with some accuracy. I've set-up one N2HET:0 to use the PCNT instruction.

The return data field after a capture has occurred contains 25bits of "data" and 7 bits of "HR Data".

It is my understanding that the "data" field updates every LR clock with the LR clock count. Therefore reading only the 25bits of data gives me a resolution of LR clock's. The HR clock is 100MHZ, and should give me a resolution of 10ns.

The question is how to use the "HR Data" field. Do I add the amount of time in 25bit LR Clocks and the amount of time in 7 bits of HR clocks together to get a result accurate to the nearest 10ns?

Thanks

Stomp!

  • Stomp,

    Please have a look to the following screenshot from RM48 TRM.

    The HR field valid bits depend on the ratio between Loop Resolution Prescaler and High Resolution Prescaler as shown in the table.


    The corresponding number of HR will have to be added to the number of loop resolution captured.

    Please let me know if this clarify your question.

  • Stomp,

    Another way to think about it - the one that I like - is to consider the HET as operating on 25.7 fixed point numbers. The radix is between bits 7 and 6 in the data field in HET RAM. And the unit is the loop resolution period.

    This is a trivial distinction if the loop resolution prescale is set to 1/128 HRP because then all 7 of the fractional bits are significant, and bit 0 corresponds to an HR clock -- 10ns resolution like you mentioned.

    But if you pick a different loop resolution prescale value (say /64 or /32) then while the HET still uses 25.7 format, it's the least significant bits that drop off first. So for example in the case of /32 - only fraction bits [6:2] are valid, and bit 2 equates to 1 HR clock or 10ns.

    While it might seem silly to run this way (you have less bits to work with if you pick /5) you might want to operate this way if you have a smaller HET program but would like the loop resolution period to be faster, because the HET is limited to making one high resolution measurment or scheduling one hi-resolution operation per pin per loop. The smaller the loop period - the closer you can space these measurements or actions.

    This is all basically the same as what is described in the table above, but if you are comfortable thinking about fixed point math then I at least find it easier to remember and think about this way.
  • Dear Jean-Marc and Anthony,
    Thanks both for the very thorough answers.

    The 25.7 format makes complete sense now. We implemented some code to check the LR divide rate and then shift the HR data field to the right depending on the loop resolution. We multiply this value by the HR clock period.

    Right now we are dealing with 4.00us pulses from our hardware and measuring 4.94us by using the N2HET, with a 160ns loop time.

    Thanks again!
    Cheers
    Stomp!.