Getting the NHET timer to run faster

Nimit,

That's not how the N2HET works.  You must set the loop resolution period to be reasonably long.

All of the instructions in your N2HET program must execute within the time of the Loop Resolution Period.

Setting the HRP, LRP to 0 would mean that you have basically no cycles to execute N2HET code.
When you're getting the value of 0 you should also be seeing the PRGM OVERFL FLAG bit 0 of HETEXC2 set.  This is the exception that lets you know your HET program didn't finish within the allotted time.
By finish, that means branching back to address 0 where it will then wait (N2HET processor will essentially 'idle') until the start of the next loop resolution period.

Now that I've either confused you or discouraged you ;) the good news is that it's very simple to measure a timestamp of an event with resolution up to the maximum frequency of the N2HET (I'd need to check the datasheet for the RM42x but that should be on the order of 10-12ns depending on whether the part is 100Mhz or 80MHz...)

Here's how it works.   In the WCAP instruction that you are using for timestamp, you set the hr_lr option to hi-res. i.e. hr_lr = HIGH.  (comment here, if you look at N2HET 'machine code' in hex format,  hr_lr=HIGH has a value of '0' not ''1' in bit position P[8] - this catches people off guard a lot...)

So what's the deal with the 'hr_lr=HIGH'?   Well for each pin on the N2HET there's a sort of 'mini-timer' that's 7 bits and it keeps track of the offset into the loop resolution period to get the exact time when your event occurs.

This means that the data field of the WCAP instruction when run w. hr_lr=high will consist of:  

   Bits [31:7] will contain the loop counter value corresponding to the loop within the event occurred.

   Bits [6:0] will contain the fraction of the loop that passed when the event occurred

In the simple case, when you have the LRP set for a factor of 128,  you can just read bits 31:0 as a 32-bit timestamp measured in terms of HR clock cycles.     If  HRP=0 then this will be your 10 or 12ns system clock resolution.

If you have LRP set to something other than 128, then you would need to shift the right value by some number of bits to get it to represent HR clocks.  

This is because bits 6:0 represent the 'fraction' of the loop period, in binary of course.  In other words, the upper 25 bits are the whole loop count,  bit 7 represents the 2^0 position - or 1 whole loop.   bit 8 represents 2^1 or 2 whole loops.  bit 9 2^2 or 4 whole loops, etc...      bit 6 on the other hand represents 2^-1 loops or 1/2 of a loop.   this is true whether the LRP is 128, 64, or 32...   bit 5 represents 2^-2 or 1/4 of a loop, and so on.    This is basically just fixed point math, and the N2HET has the decimal place between bits 7 and 6.

If the fixed point part is confusing then just keep the LRP at 128 and ignore the fixed point stuff for now. 

The tradeoff here is that the 7-bit 'mini' timer (we call it the Hi-Res structure) can only track one event for each loop resolution period.   So in the case of LRP = 128,   this means that if you have 2 edges on the WCAP that you try to timestamp and they fall within 128 cycles of each other,  you won't be able to measure this reliably.  It will depend on whether these 2 edges happen to fall within the same LRP or span across 2 LRPs.

What that means is that the 128 LRP value isn't a limit on the RESOLUTION of the timer,  you can timestamp down to 10ns.   But it's a limit on the rate at which the timer can process incoming events.   Normally this is no issue when there's something 'mechanical' being timed by N2HET since 1.3 us is pretty fast for something mechanical;  but this might become a limiting factor if you try to use N2HET for something like a fast digital interface ...

Hi Anthony,

Thanks for your response. 

I did as you told, but still, the last 7 bits in the data field of WCAP are 0!

I ensured that the hr_lr bit is 0 in the het.c file. In fact, here are all the values in the WCAP structure:

As seen, the P[8] bit is zero.

I also set the LRP to 6, which made the least significant  7 bits the high resolution bits.

I am still unable to get a 32 bit resolution. Here's a sample value of the data field of WCAP:

The last 7 bits are always zero.

I would really appreciate any help in this regard! If it isn't much of a problem, could we communicate by email? We are actually on a deadline :/ My email id is njaintii.54@gmail.com.

Thanks and regards,

Nimit.