Use of NHET on TMS570

Hi Dave,

You can try accumulating the PCNT results using the ADM32 instruction.
You can use the DJZ instruction to implement the loop that counts 10 iterations and then triggers the HTU to pick up the sum.

The only caveat - can you ensure that the sum of 10 successive PCNTs won't overflow 2^25 * LRP?   If so this should be straightforward.  Otherwise, detecting overflow is probably more complicated than it's worth; at least for NHET. 

Best Regards,

-Anthony

Hi Anthony,

Thank you for your reply. Your solution makes much better use of the NHET than mine and I will look at implementing this.

I am not sure that this would help the rounding problem though. The problem is that in taking 10 separate measurements I will have 10 rounding errors, whereas if I could take just one measurement, then there would be one rounding error only. I would like to start a timer on the first falling edge and then after the 11th falling edge (10 falling edges later) stop the timer, or capture the timer value. Is it possible to do this using the NHET?

Best Regards,

Dave

Hi Anthony and Gerhard,

Thank you for these informative answers.

It would be good if you could confirm whether there is a potential rounding problem with PCNT or WCAP because my application relies on taking highly accurate measurements.

Best regards,

Dave

Hi Dave,

WCAP's hi-res operation is illustrated in figure 18-23 of our TRM.   You can see that the capture edges do not cause the hi-res counter to reset,  they just result in taking snapshots of the hi-res count.   Let's say you take a measurement on falling edge #1 and another on falling edge #10 in a sequence of pulses.    On the leading edge you could have between 0 and -1 HR clock of error and on the trailing edge you could have between 0 and +1 HR clock of error.    But edges #2, #3, #4, #5 ... #9 don't affect the counter value at all and therefore they couldn't have caused any lost counts. 

PCNT is a litte different - as you can see in figure 18-21 and 18-22 of our TRM the PCNT instruction does hi-res counter to reset and start counting in mid loop - where the active edge occurs.    This means that edges #2, #3, #4... #9 actually change the hi-res counter value.  Now I don't believe you'd lose any HR cycles due to PCNT --- assuming the input signal maintains only one edge per loop resolution period.  This is due to the way PCNT works;  unfortunately we don't have a FALL2FALL example in the TRM, figures 18-21 and 18-22 are both RISE2FALL..   We probably should update the TRM with an accurate picture of FALL2FALL or RISE2RISE since this is more stressful as one count starts exactly where the other leaves off.  

But all other things being equal - I think I'd go with WCAP since it doesn't create a path where the edge actually changes the hi-res count.   (one less way things can go wrong, for example if you had a short pulse or glitch on one of the inputs). 

Best Regards,

Anthony

NOTE:  8/1/2011  I corrected this post from +/- 0.5 HR clock of uncertainty to -1 HR clock on the leading edge and +1 on the trailing.   The timer doesn't round like an A/D converter, it simply samples.

Hi Dave,

One of my colleagues checked PCNT for us;  he's confirmed based on a simulation that the PCNT wouldn't drop a count either on successive FALL2FALL captures.

I'm cc'ing him so he can post more details but this should confirm the PCNT instruction would work for you too.

Still would recommend WCAP though based on the above.  

Best Regards,

Anthony

Hi Dave,

The HR counter resets to 1 at the reset edge; so it will start counting from 1 to n (assume the capture edge occurs when HR count = n).

The first PCNT HR value should be ignored after the NHET hardware reset is released and NHET is enable.

I am attaching a RISE2RISE simulation (which is similar to FALL2FALL) where the capture and reset edges happen to be the same edge.

I have been comparing PCNT and CNT for acquiring measurements between sucessive falling edges. I can use PCNT and CNT separately to take measurements, but when I try to use both, I find that the data that is transferred by the HTU on request 1 is the same as the data that is transferred by the HTU on request 0.

Is there a way that I can stop the data acquired from the snapshot of the CNT timer from being lost?

Regards,
Dave

P.S. the code is as follows:

; Using PCNT to read the FALL to FALL counts for pin 10
P00   PCNT  { next=P01,reqnum=0,request=GENREQ,irq=OFF,type=FALL2FALL,pin=10,period=0,data=0,hr_data=0};
P01   BR    { next=P02,cond_addr=P02,event=NOCOND }
; Using CNT to get a snapshot of a timer on every 10th FALLing edge on  pin 12
P02   CNT   { reg=B, irq=OFF, max= 0x1FFFFFF }
P03   WCAP  { next= P06, hr_lr = HIGH, cond_addr = P04 ,  pin=12 , event=FALL, reg=B, data=0 };
P04   DJZ   { next= P06, cond_addr= P05, reqnum=1 , request= GENREQ,  data= 9 }
P05   MOV32 { remote= P04 , type=IMTOREG&REM, reg=NONE, data= 9 }
P06   BR    { next=P00,cond_addr=P00,event=NOCOND }

Hi Dave,

Can you also provide the HTU control packet configurations?

Regards,

Sunil

Hi Sunil,

3060.HTU.zip

I have attached a zip file containing htu.c and htu.h, I have removed a fair amount of the code to make it easier to read.

Regards,
Dave