timer resolution with MSP430

hmm, your description is a bit fuzzy...

Timothy Starr said:

My frequency stability requirements mandate the use of a crystal.

Timothy Starr said:

Can a MSP430 be used to generate the clock locally

The MSP has no internal crystal, so no. However, the MSP can handle an external crystal (and the proper load capacitance), so no digital external source is required.
All internal generated frequencies are just free-running oscillators and possibly no suitable for your problem.

You write 'the MSP'. Which one of the >300 different MSPs?
Nevertheless, the maximum clock speed for most MSPs is 25MHz, so the minimum pulse width that can be generated is 40ns. However, the maximum ratio between pulsewidth and frequency is 1:65536. So the minimum frequency for 40ns pulsewidth is 381,5Hz.

For 10Hz, the minimum pulsewidth is 1.5258µs.

There are some MSPs which feature a TimerD module which can handle higher (external) clocks for a smaller pulsewidth, but then the minimum frequency is higher too.

With some external hardware (a flipflop and some inverters) it is possible to limit the pulse time to 20ns while allowing for much lower frequencies. But external hardware wasn't what you want.

If you can live with 2µs pulsewidth, (requiring a 1, 2 or 4MHz crystal only), it is simple to set up a frequency from 10Hz to 250kHz with 2µs period resolution. Which is ~0.0002Hz in teh 10..20Hz range.

Yopur suggestions for a possible implementation have some problems.

1) you cannot set a por tpin high for a single MCLK cycle. The instruction to do a port change take 4 cycles (best case), so two subsequent port changes are 4 clock cycles apart. Minimum pulse width is 160ns if the MCLK is running on 25MHz. (and the smaller and cheaper devices have only 16 or 8Mhz maximum system clock)
2) ISRs have a relatively large latency and a software timer overrun will add a significant jitter. Sure an average frequency of 10Hz isn't much and adjusting in the 1/100th Hz for 10..20Hz means that you only need a timer interrupt every 500µs.However, the jitter may or may not be still significant, depending on the application.

It is possible on devices with USCI module to create sort of a self-resetting signal by programming the USCI for SPI output on maximum frequency. If you then write a single byte 0x80 to the oputput register, this is output with full speed, resulting in a one-cycle high pulse. Together with the software overflow counter (accepting the jitter), this is the closes thing you can get.

I never tried it and maybe you cannot create a high pulse but only a low pulse (as the line goes high again if idle). I remember a thread in which observations seemed to indicate this, but it wasn't pursued further.

Hi Jens-Michael:

Yes if we assume a 25MHz resoltuion is required, the MSP430F5xxx family is required I beleive. Add this to the need for small package and I was thinking of the MSP430F5131. Questions:

1) can't I just tie the output of one timer to another to get more than 16 bits of timing resolution?

2) If I were to tie one timer to the other, can I do it internally, or do I have to tie up two GPIO pins?

3) Is the MSP430G2231 capable of high-frequency (>16MHz, say)  crystal oscillator configuration? This is what's on our development boards...although I realize it has only one timer.

4) which devices in the 5xxx  family offer TimerD module? I would like to read up on this feature. Thanks!

-Tim

Hi Tim,

Your 'G2231 can handle up to 16MHz input on the XIN line, but not as a crystal.  It has to be a logic level clock signal.  Which means an external clock, which is slightly bigger than an external crystal.  But it makes a fine development platform if you can drive it with an external 16MHz clock.

To use an external crystal, you might look at the MSP430F21x1.  It will drive a high-speed crystal directly, and it's a very small MCU too.

A 16MHz crystal would work just fine, but so would a 10MHz crystal.  You could use Timer A to generate the one-clock pulse (62.5ns or 100ns).  CCR0 can generate a single-cycle pulse when the timer is in UP mode.  The dual-action output modes (like set/reset or reset/set) take the first action when the counter reaches CCRn and the second action when the counter counts back to zero.

You don't need multiple timers.  Just configure CCR0 not to generate any pulse until after the appropriate number of overflows through the timer.  Use interrupts to count overflows.  Once the correct number of overflows have passed, then in the ISR set CCR0 for the magic match value and for generating the pulse.  You can avoid complication with race conditions if you use an overflow period a lot less than 65536 ticks.  Say 50000 ticks.  In other words, in the ISR if the next pulse is still more than 65535 ticks away, then check again in 50000 more ticks (next overflow with CCR0 set to 49999).  Otherwise, just schedule the pulse now (CCR0 set to something larger than 15535 by design, and CCTL0 set for set/reset mode).

Your ISR logic could be written either for zero jitter and slightly inaccurate frequency or for very small jitter and perfectly accurate frequency.

Jeff

The idea with the reuced cycle time is a good idea. I didn't mention the possibility of a ISR counting of overflows because it might be that the remaining rest time of a cycle might be too short for another ISR call or too close to 0 so that multiple pulses appear. Your approach of reducing the 'counting' cycle time and allow for an overlong cycle in the 'action' cycle is an elegant solution, that ensures that there's always enough time.

And indeed, 10MHz is perfect if 100ns pulse time are okay.

For the HF input to a G series chip, it should be noted that this is not backed by the documentation. It is only verified by experiments. New silicon versions might no longer allow this.