What are the units for the RTI module COMP register?

Hi Dan,

RTI uses RTICLK as the unit tick. It increments the count once every RTICLK period. There is no conversion to time other than this. What is the RTICLK frequency you are using?

Thanks and Regards,

Vineeth

Vineeth,

Hi I agree - but I wonder if Dan is asking about the view through HalCoGen.

In the HalCoGen config window, it says 'RTI Compare <x> Input Frequency in MHz' and the result is "Actual Compare <x> Period in ms' in the tool-tips - which to me implies that between the GUI and the Hardware there is Math/Scaling performed.

Hi Dan,

 

Please clarify what you mean by "When I set the COMP register to 20000000 (in my CCS code)".

1)      Are you using the HALCoGen GUI itself to do this?

2)      Or are you using the HALCoGen APIs [rtiSetPeriod()]?

3)      Or are you using your own code to access the COMP register and write 20000000?

 

In case (1), the user is required to enter the “Compare <x> Period in ms”. The closest period possible with the current clock configuration will be displayed in the “Actual Period(ms)” box.

In cases (2) and (3), my previous reply is valid. There is no conversion to time happening(even in the HALCoGen APIs). The unit tick is driven by the RTICLK.

 

Thanks and Regards,

Vineeth

 

PS: Please expect delays in forum responses due to the holiday season.

Hi Vineeth and Anthony

I ask the question because of the view through HalCoGen makes me wonder if something hidden to me might be going on in the code and because (assuming that the clock speed is 100 MHz) with the numbers given I would think that I would get a 0.2 sec interval rather than a 2.0 sec interval.

So for the time being I will assume that there is nothing hidden going on when setting the COMP register in code (rather than HalCoGen). How do I check the clock frequency? Is there possibly a prescaler being applied?

Hi Vineeth

I am setting the COMP register in my own code (your choice 3).

Dan

Thanks Vineeth

I have a related question. I would like to get the greatest accuracy and precision possible for the RTI clock. Heating of the clock's crystal is a major source of frequency drift and therefore deterioration of timing accuracy and precision. If I set the prescale value to highest acceptable value given my accuracy needs do you think this will significantly reduce heating effects?

Daniel

Dan,

The RTI settings aren't going to really impact the concerns you're bringing up. At the e.o. the day the RTI timing is going to trace back to the crystal and any error in the crystal will pass through to the RTI. If you have the PLL in between the two - in theory this should filter out short perturbations on the crystal if they were to occur and keep the RTI locked to the average crystal frequency over some # of counts. (this is what the divider in the feedback loop of the PLL is for).

Anyway, point is that if you are worried about the crystal, the best thing to do is to consult w. crystal vendors. There might be some things that you could 'trim' for if you can measure temp. I'm not sure about this though. You may wind up at the end of the day needing a crystal that's temperature controlled. It all really depends on how accurate you need the timebase to be and over how long a period.

As an FYI - I haven't seen a temp controlled osc as long as I've been working here. I think of it as something exotic that you might find inside high end lab equipment. Maybe check what is done in a GPS system as they are very sensitive to accurate timing but also mainstream... Just an idea.

Hi Anthony

I didn't understand this sentence:

" If you have the PLL in between the two - in theory this should filter out short perturbations on the crystal if they were to occur and keep the RTI locked to the average crystal frequency over some # of counts. (this is what the divider in the feedback loop of the PLL is for)."

Could you explain further?

Dan,

I'm just speaking in very general terms here - but the PLL includes a feedback loop to regulate it's output frequency as some multiple of it's input frequency.

Think about how a voltage regulator works - it uses feedback to keep it's output voltage regulated around some multiple of a reference voltage (usually a bandgap reference on the regulator chip).

Both of these circuits will filter out noise and disturbances over a certain frequency range. A key difference between them though is that the voltage regulator has a precise reference to compare against with an absolute voltage output.

The PLL only has the input frequency to compare against and can only adjust it's output frequency to be some multiple of it's input frequency. It does this by counting some number of output clocks (with the divider in the feedback loop) and comparing the rate of this divided output with the input to create an error signal that adjusts the output frequency up/down.

Anyway why this is important is that any steady state error in your input frequency will pass through the PLL straight into the output frequency. So it's not going to help you at all with the problem of your crystal frequency drifting over temperature as this is a very low frequency (or even steady state) error.

If you were worried about some transient error that might affect your input clock then the PLL might help - but that's not the case you're asking about. This is why I would say it's not going to make any significant difference which clock source you use for your RTI .. if you are worried about counteracting shifts in the crystal frequency.

Anthony

Thank you for the great explanation!

Dan