N2HET or RTI module for event timing

Hi Dan,
It would be easier to use the RTI for the usecase you have mentioned(setting GIO output from ISR after a configurable delay). If your usecase is is to set a GIO output(after delay) on receiving a specific GIO input, you can probably program the NHET to do this without any interrupts(this would be more "precise").
What precision(1us?) are you looking for? And which device(at what frequency) are you using ?
Regards,Vineeth

Hi Vineeth

If I use the RTI module then I think I would need to force a reset on the counter before I set the time delay using the COMP register. Is that correct? If so then how can I reset the counter?

Does the RTI module use a different clock than the N2HET module? If so then which is more precise and accurate?

If I was to use the N2HET module then do you have so sample code for creating a delay using that module?

Thank you,

Dan

Dan,

No our RTI isn't really designed to be reset.   I think it's pretty nice this way - all of the capture and compare events use the same timebase and can be correlated to each other.

For periodic compares instead of resetting the counter like a traditional timer would do,  we *add* the period value to the current compare value to compute the next compare value - assuming that counter is free running.   So for example if you have the compare set for a value of 100 and the compare update register for 150, you will get your compare match events at counts of 100, 250, 400, 550, etc.

For what you are asking you could simply route a GIO interrupt event through the VIM to the RTI's capture event feature.  This will timestamp the occurrence of the initial GIO edge.    

Then in your ISR you can add your delay to this timestamp and write the value into the compare register.

This approach takes out all the jitter due to software because you are using hardware to measure the initial edge and to generate the output edge.  Assuming your 'delay' is long enough for the ISR to respond this could work quite well.

Here's a few pics of the idea copied from drawings in the TRM:

By relatively precise, I mean that I think the only jitter you should get is the synchronization uncertainty at the GIO input so probably on the order or a system clock ... for the low end RM42 or TMS570LS0432 that's around 80 to 100Mhz or 10 to 12 ns...

The N2HET on this part could achieve the exact same type of result.   It's program would be quite simple,  just a few lines of HET code.

You could simply implement a counter with a CNT instruction,  then WCAP a pin event for your input pin.  If the input pin edge occurs, your WCAP branch to code that initializes an ECMP or MCMP instruction for the delayed output, which can be done with a DADM64 instruction.  Your delay value goes into the data field of the DADM64.

The advantage of this approach of course is that there is absolutely 0 CPU load other than one time initialization of the HET, and the responsiveness is probably much faster...  you could probably handle a new input pulse every few microseconds.  

But you'd need to learn a little about how to program HET, because the blackbox driver in HalCoGen won't do this for you.

Hi Anthony

I think I will first try your RTI suggestion to implement these delays. It's nice and simple.

With respect to the system clock (running at 80 or 100 MHz) is the oscillator an external crystal, an internal crystal, or an RC oscillator? My concern is accuracy drifts due to heating etc. I would like the timing accuracy of these delays (which will always be less than 5 seconds) to be better than 100 microseconds so I am concerned about heating of the oscillator producing drift in its frequency.

Thanks so much,

Dan

Hi Dan,

Ok let's confirm, you need 100us accuracy over 5 seconds, which I think amounts to 20ppm (so +/-10ppm). The 'standard' for crystals seems to be +/-50ppm so I think you're right to be concerned.

There are components called Temperature Compensated Crystal Oscillators and Oven Controlled Crystal Oscillators that you might need to resort to.

Hi Anthony

Is this the statement that I would need in my ISR to read the present time (count) on the capture register and assign a new time for the RTI interrupt 1000000 counts later? :

rtiREG1->CMP[0U].COMPx = rtiREG1->CNT[0U].CAFRCx + 1000000;

Do I need to initialize anything in HalCoGen to get this capture register working. I tried using just the above code but it is not working yet.

Thanks,
Dan

Excellent!