MSP430G2211 MSP430G2231 Queries

~300 uS pulse is wide enough for G2xx to detect.

200 Hz max is slow enough for G2xx to count.

50 mS is long enough for G2xx to do a lot of integer calculations.

I do not understand your definition of "count = 1000/interval". You only said the max frequency is 200 Hz. Do not know the min.

Even at max frequency, it takes 42.5 seconds to count 8500 pulses. GOK how long at min frequency. Faster and more capable chips will not help at all.

I think I goofed up in my explanation.

 

I basically need to light up an LED if a shaft exceeds 8500 RPM and make it blink at 9000 RPM.

 

RPM=60000/interval // 60000 is minutes in ms and interval is the time difference between 2 consecutive high pulses.

 

I can provide the arduino code which already does this if that would help.

So, if the shaft encoder signal varies between >8500 RPM and <8500 RPM back and forth, the LED will appear to "blink". At >9000 RPM, it also blinks.

Anyway, G2xx can do what you said. If you use the Launchpad, it has two LEDs.

As OCY already stated, your choice of signals is ambiguous. It would be better to let the LED blink if you're between 8500 and 9000 (so even if you're moving in and out this range, it will still blink) and go to permanent on if you're above 9000.

However, about the cycle measurement itself:

Don't count the pulses per second. Long delays are 1) difficult to handle with the intenal timers adn 2) mean that you only get an update every second, which is a long time.
It' sbetter to measure the timer per pulse, so you get a new result on every round and can immediately detect whether  you are exceeding the limit, even temporary.

How to do it:

Set up a timer to count with a speed that is sufficient. On 9000RPM, you'll have 6.66 ms per pulse (150Hz). If you program the timer to run with 32768Hz (the watch crystal on XT1),  you'll get 218 pulses on 9000RPM, 231 on 8500 RPM, 246 on 8000RPM and the detection limit is 0.5RPM. Below that you'll get alias readings.

Now set up the CCR0 unit of the timer to capture mode, program the port pin assigned to TA.0 for module unse, input, and connect your sensor to the pin. You can define the edge (rising or falling) too. Each time, the sensor signal has the proper signal edge, teh CCR0 unit will fetch the current timer count and trigger an interrupt. In the ISR (interrupt service routine), you can compare the latest readign with the previous and know how many microseconds the last turn has taken. Avoid divisions as they are slow. Try to do multiplicaitons and shifts instead, or use tables if necessary. (watch out for the value ranges of the intermediate results)

Tejinder Singh said:

The question I have is that whether those uPs are fast enough to do this in almost realtime, max acceptable delay between reaching 8500 pulses and LED going on is about 50 ms.

Well, 50ms is an eternity. For detection and actin, way less than a ms are rquired. However, you have a sensor delay. On 8500RPM, rach turn takes 7ms. so this is the worst case detection time before the MSP wioll get a signal at all on which it can work. Still way below 50ms.
If you add a sensor on both sides of the axis, you'll get double pulse rates and half reaction times :) But be sure that they are palced precisely, or you'll get two different interchanging results for each half turn.

Tejinder Singh said:

Is there a more optimized approach or a uP from the same series that I can program using the launchpad board that would work better?

For this job, any MSP does equally well. A TimerA and one CCR register is the minimum exquipment every MSP has. If your minimum pulse width were <40ns, then only MSPs with a TiemrD would work, and if you ahve much to do or have higher frequencies/higher precision requirements, other MSPs with external HF crystal and higher
CPU speed would be good, but for the requirements you listed, any MSP fits well.

Thanks for the detailed input Michael.

I think elaborating the requirement criterion will help more here.

 

The square wave frequency will vary from 20 Hz to 200 Hz not more than that for sure. And there wont be any instance where its flipping back and forth around the 8500.

 

I can avoid the division easily by comparing time elapsed between 2 pulses rather than counting pulses / second and acting.

 

Another question crops to mind is that can the time interval be counted in micro seconds instead of mili seconds?

 

Thanks,

Tj

Tejinder Singh said:

Another question crops to mind is that can the time interval be counted in micro seconds instead of mili seconds?

Yes, it can. You only have to clock the timer with 1MHz. then every tick is one microsecond.

But then, however, the maximum for one turn is 65,536 milliseconds = 15Hz.

With the 32768Hz watch crystal clock, however, you are already counting in ~30 microsecond steps.

You'll require a more or less calibrated 1MHz (or 2,4 or 8) clock source then. Which is difficult since the G series doe snot support high-frequency crystals. And the internal DCO is relatively unprecise, produces a relatively large clock jitter (whcih may or may not be important) as it can onyl switch between two frequencies to build an average frequency, and worst of all, there is AFAIK no calibration value stored in these chips (as calibration takes time and raises the costs). So you'd have the calibrate the proper 1MHz settings for each individual device.

 

You'll require a more or less calibrated 1MHz (or 2,4 or 8) clock source then. Which is difficult since the G series does not support high-frequency crystals. And the internal DCO is relatively imprecise, produces a relatively large clock jitter (which may or may not be important) as it can only switch between two frequencies to build an average frequency, and worst of all, there is AFAIK no calibration value stored in these chips (as calibration takes time and raises the costs). So you'd have the calibrate the proper 1MHz settings for each individual device.

Another option is to not try to calibrate the DCO, but just measure it: run the DCO at approx. 1 MHz, and the WDT off a 32 kHz crystal, read them both periodically, measure the average DCO frequency, then use that to compute the limiting pulse timing.

E.g. keep a moving average of DCO clocks per 1024 WDT clocks (1/32 second, should be approx 31250). Call this "M". Then you want to alarm if pulse_interval < M × 32 × 60 / 8500, or (using 60/8500 = 3/425), pulse_interval * 425 < M &times 96. (Change 425 to 450 for 9000 rpm.)

Another option, if you can stand the slight delay, would be to simply count in 32768 kHz ticks, but average a few samples to get the full speed precision. 8500 rpm is 231.3 ticks, while 9000 rpm is 218.45.

But other than that bit of trickery necessary to get accurate timing, the MSP430 is very definitely up to the application. (MSP430 family deliberately do not include a clock PLL to enable fast clock start/stop.)

Cypher Punks said:

Another option is to not try to calibrate the DCO, but just measure it: run the DCO at approx. 1 MHz, and the WDT off a 32 kHz crystal, read them both periodically, measure the average DCO frequency, then use that to compute the limiting pulse timing.

Indeed a possibility, but it would require at least one more readable counter. (the WDT only expires, you cannot check its current count for comparisons) and the G series only has one timer/counter and this one is already required for the measurement itself.

Cypher Punks said:

keep a moving average of DCO clocks per 1024 WDT clocks

Nobody tells you what 1024 WDT clocks are. All you can do is waiting for an interrupt when 32768 WDT clocks have expired, requiring a 1MHz = 20 bit counter running with DCOclk. Which you don't have, except on the devices with RTC.

And since the DCO significantly drifts over time/temperature, you need to constantly check it. You cannot just do it once at startup, at least not if you require some accuracy. No, an external 1MHz oscillator on XT1 (supported even if the datasheet does not tell) would be best (yet expensive) or a different MSP with more timers or FLL unit or support or support fr HF crystals (or all three, on most newer devices).