What is the correct way to interface pulse counters

Glenn Edgar

Other Parts Discussed in Thread: EK-TM4C123GXL, LM3S811

I have a unit which has to interface to flow sensors which generate a pulse rate based upon flow rate.

My intent is to use the edge count mode of the timer to count the pulses. The idea is to let the counters accumulate the pulses and every second

dump the contents of the counters. If this is the correct way to handle the pulse interface are there examples which are similar to this function.

My questions are as follows.

What is the correct way to dump and clear the timer without lossing counts?

Can the prescale function provide any increase in timer capacity, ie increase 16 bit timer to 24 bit resolution? If yes then how to do this?

Thanks

Glenn Edgar

over 10 years ago

0 Amit Ashara over 10 years ago

TI__Guru**** 244400 points

Hello Glenn,

The first thing you would need to ascertain is the rate at which the pulses are going to come in. The uC synchronizes the external input to the internal clock so as to detect the edges using rise and/or fall edge detection. To be able to do that correctly, it needs to ensure that sampling rate is >> the input pulse rate.

Second important thing that you may want to consider is the count mechanism. Establish the max and min rate of pulses. If the Max and Min rate of pulses is established then you can measure the time period between pulses using the edge time mode to establish the rate as well.

Regards
Amit

0 Glenn Edgar over 10 years ago in reply to Amit Ashara

Prodigy 250 points

The pulse rate is much less than 1000 pulses/sec. ( pulses are square waves) The flow is somewhat irregular so that the total pulses per minute is a much better working number than the pulse width. At 1000 pulses a second, a 16 bit counter store on minute total counts.

0 Amit Ashara over 10 years ago in reply to Glenn Edgar

TI__Guru**** 244400 points

Hello Glenn,

Which device are you planning to use:The TM4C123 or TM4C129 as the former has wide timers which could be very useful for such an application.

Also the pulse duration is still not clear. Is it going to be like microsecond wide pulses? The pulse rate is good enough for the acquisition to be done in edge time mode.

Regards
Amit

0 Glenn Edgar over 10 years ago in reply to Amit Ashara

Prodigy 250 points

I am using 123 but in future might use 129 in some applications. From what I see is that the code would be virtually identical.

The duty cycle of the pulses is 50%. Therefore the minimum pulse width would be 500 used.

I was mainly looking for examples of doing the edge capture.

Thanks

Glenn edgar

0 Amit Ashara over 10 years ago in reply to Glenn Edgar

TI__Guru**** 244400 points

Hello Glenn,

Thanks for the data. An example code for Edge Time code is not there but the closest one you can use is in

C:\ti\TivaWare_C_Series-2.1.0.12573\examples\peripherals\timer\edge_count.c

I would suggest the following two changes

1. Change the regular 16/32 timer to 32/64 timer
2. Configuration change from edge Cap Count to Edge Cap Time

Will be more than glad to assist you to build the code if you can make a start at it.

Regards
Amit

0 cb1 over 10 years ago in reply to Amit Ashara

Guru 47900 points

I've read and enjoyed the progress you two have made.

May I suggest two items - not yet having reached this thread? (and perhaps better detailing the, "interface of an external device" to an MCU)

a) Insure that the Flow Meter's output signal "remains at all times" w/in the MCU's input signal level rating. You must tie the Flow Meter's "signal ground" to the MCU's ground and then check/double check that the flow meter's output voltage never goes negative nor exceeds the MCU's Timer input signal rating. (we've noted some (older) Flow Meters which "glitched" upon power up - often exceeding the MCUs input signal rating - and over time - destroying that MCU input... observation was made prior to intro. of TM4C - but remains valid today)

While some MCUs "claim" the ability to "accept" input signals when the MCU is unpowered - we don't believe this to be, "best practice." Suggest that your Flow Meter be powered in concert (i.e. together) with your MCU board - so that any/all input signals are removed along w/MCU power...

b) As described - you must have an operational Flow Meter - and an appropriate gas/liquid to "flow" - and must properly make all (plumbing & electrical) interconnects. That's a lot of work - is it not?

You may escape that (necessary) time/effort by employing your MCU to generate "sample" output signals - which well mimic those of the Flow Sensor. Your MCU enables extremely precise control of signal frequency and waveform - employing another MCU Timer in it's "PWM Mode" yields a very nice 50% duty cycle signal @ variable frequency.

You would then connect that second Timer's PWM Output to your (first) Timer's input - employing the second Timer in place of the Flow Meter for your initial test & verification. (and later, calibration)

Our small tech firm employs such methods "all of the time" in fact we include that capability as an added, "feature" in our products. (i.e. provides a self-calibration and input signal "check" mechanism.)

Wish you well...

0 Glenn Edgar over 10 years ago in reply to cb1

Prodigy 250 points

Thanks for advise. I did use a pwm to test the counters.

I use a comparator to interface to the flow meters as some of my flow meters are 24 volt 2 wire and some 5v-24V three wire. Most of my flow meters are used for irrigation use.

Thanks

Glenn

0 Glenn Edgar over 10 years ago in reply to Amit Ashara

Prodigy 250 points

The edge demo code worked great. A question though. I tried the count up mode and it did not work. The data sheet said that some parts do not support this feature. Does the EK-TM4C123GXL support this feature? For me it did not work.

0 Amit Ashara over 10 years ago in reply to Glenn Edgar

TI__Guru**** 244400 points

Hello Glenn,

It should work. can you send the snapshot of the data sheet which states it does not work?

Regards
Amit

0 Glenn Edgar over 10 years ago in reply to Amit Ashara

Prodigy 250 points

TIMER_CFG_A_CAP_COUNT - Half-width edge count capture
TIMER_CFG_A_CAP_COUNT_UP - Half-width edge count capture that counts up instead
of down (not available on all parts) page 540 of driver documentation

TIMER_CFG_A_CAP_COUNT -------------------------------- works
TIMER_CFG_A_CAP_COUNT_UP -------------------------------- appears not to work

0 Amit Ashara over 10 years ago in reply to Glenn Edgar

TI__Guru**** 244400 points

Hello Glenn,

Could you share the configuration file for the UP Count.

Regards
Amit

0 Glenn Edgar over 10 years ago in reply to Glenn Edgar

Prodigy 250 points

Responding to request for code.

The data structure for counter is shown below.

TIMER_COUNTER_CONFIG_T timer_counter_state[TIMER_COUNTER_NUMBER] =
{

//{ TIMER1_BASE, TIMER_A, TIMER_CFG_A_CAP_COUNT, GPIO_PORTB_BASE, GPIO_PIN_4, GPIO_PB4_T1CCP0, 6,0,SECOND_TICK }, // example of timer a
{ WTIMER1_BASE, TIMER_A, TIMER_CFG_A_CAP_COUNT, GPIO_PORTC_BASE, GPIO_PIN_6, GPIO_PC6_WT1CCP0, 7,0,SECOND_TICK }, // example of wide timer
};

//TIMER_CFG_A_CAP_COUNT_UP
//TIMER_CFG_A_CAP_COUNT

// Seting up based for counitng down.
void setup_counters( void )
{
uint32_t timer_module;
uint32_t timer_type;
uint32_t timer_config;
uint32_t port;
uint32_t pin;
uint32_t pin_config;
uint32_t i;

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER0);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER1);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER2);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER3);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER4);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER5);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER0);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER2);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER3);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER4);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER5);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER6);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER7);

for( i = 0; i < TIMER_COUNTER_NUMBER; i++)
{
timer_module = timer_counter_state[i].timer_module;
timer_type = timer_counter_state[i].timer_type;
timer_config = timer_counter_state[i].timer_config;
port = timer_counter_state[i].port;
pin = timer_counter_state[i].pin;
pin_config = timer_counter_state[i].pin_config;

ROM_GPIOPinTypeTimer(port, pin);
ROM_GPIOPinConfigure(pin_config);
ROM_GPIOPadConfigSet(port, pin,
GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);

ROM_TimerConfigure(timer_module, TIMER_CFG_SPLIT_PAIR | timer_config);
ROM_TimerControlEvent(TIMER4_BASE, TIMER_A, TIMER_EVENT_POS_EDGE);
ROM_TimerLoadSet(timer_module, timer_type, 0xffff ); // for counting up set to 0
ROM_TimerMatchSet(timer_module, timer_type,0x0); // for counting up set to 0xffff
ROM_TimerControlLevel(timer_module,timer_type,true);
ROM_TimerEnable(timer_module, timer_type);

}

}

0 cb1 over 10 years ago in reply to Amit Ashara

Guru 47900 points

Amit Ashara said:
1. Change the regular 16/32 timer to 32/64 timer
2. Configuration change from Edge Cap Count to Edge Cap Time

Hi Amit,

The (highlighted) recommendation seems counter intuitive. And - poster seems to agree - as he reported success w/the (more obvious) Edge Cap Count method.

Now we know that when the input signals are very low in frequency - counters rapidly fill (may over-flow - especially when driven by a near "VHF" System Clock) - and thus the "Edge Cap Time" proves superior.

Was this the reasoning behind your suggestion - and if so - have you any suggestion as to the determination of "when" to switch from Edge Cap Time to Edge Cap Count? For example - in motor control - at very slow motor speeds - we must count "time between signal edges." As the speed increases - we transition to counting those signal edges.

Again - your recommendation of "when & why" to switch (edge cap time vs. edge cap count) or simply choose one method over the other - may be valued by your user community...

0 Amit Ashara over 10 years ago in reply to cb1

TI__Guru**** 244400 points

Hello cb1,

Sure. The reason for using Edge Cap Time was primarily for the fact that even if the CPU is interrupted, the Snapshot register will hold the event value allowing the user to come at a later time to read the same. The second reason was to allow for a debounce via timer. If the signal bounces the last time from a stable sampling would be held by the snapshot register. On the other hand a Count value will actually increment quickly to show up a faster flow, while in actuality that is not the case,

Regards
Amit

0 cb1 over 10 years ago in reply to Amit Ashara

Guru 47900 points

Hi Amit,

Thanks for this - I'm not familiar w/"Snapshot Register" - have reading to do.

Tend to doubt that poster's flow meter will cause signal, "bounce" - yet anything is possible.

Have you a general Application Rule or Guideline - which dictates when to choose one (Edge Cap Count vs. Edge Cap Time) over the other?

Using less sophisticated Timer/Counters - we made that selection based (essentially) upon the input frequency - primarily a low input frequency. (i.e. one which significantly "over-flow" the MCU clocked internal counter)

0 Amit Ashara over 10 years ago in reply to cb1

TI__Guru**** 244400 points

Hello cb1,

I think you did sum it up in the previous post. For fast pulse rate, count the pulses in Cap Count mode to distribute the error and for slow rate pulses rather use the time between two events.

Regards
Amit

0 Amit Ashara over 10 years ago in reply to Glenn Edgar

TI__Guru**** 244400 points

Hello Glenn,

First of all the API TimerControlLevel is for PWM mode and is not required for Edge Count Mode. Secondly the errata GPTM#15 is what you may facing as an issue in the timer edge count up mode.

Regards
Amit

0 Roberto Romano over 10 years ago in reply to Amit Ashara

Guru 27285 points

Hi Amit, in first thank you and CB1 for in deep analysis of timer mode I read and appreciated a lot learning about this complex peripheral, I am thinking from some word I read from poster his device can be something like this:

http://www.amazon.com/External-threads-Sensor-Flowmeter-control/dp/B00EXGC6TA/ref=lp_3206433011_1_13?s=industrial&ie=UTF8&qid=1421523004&sr=1-13

If this is sensor using a sophisticated timer has no sense, I am currently using an MSP430 G series to read and compute flow and volume too, I think TIVA can do same just from GPIO interrupt and compute time from library due max speed is less than 500Hz.

0 Amit Ashara over 10 years ago in reply to Roberto Romano

TI__Guru**** 244400 points

Hello Roberto,

Roberto Romano said:
If this is sensor using a sophisticated timer has no sense, I am currently using an MSP430 G series to read and compute flow and volume too

"The whole is greater than sum of the parts". There are applications (and lots of them) that can exist with MSP430 and a sensor (add a bunch of them). However when it comes to system integration of the new high speed sensors with head room for expansion+what if scenario, flexibility in architecture and support, TM4C is preferred more (don't take my word for it and we may disagree as well).

In this case the poster's end application is not very clear, i.e. is it just a flow sensor or there are more components to it. So we may need to wait for our poster to tell us more.

Regards

Amit

0 cb1_mobile over 10 years ago in reply to Amit Ashara

Guru 117855 points

Hi Roberto,

I vote w/Amit in this case (choose the ARM MCU) - three primary reasons:

a) lifetime ago - I was member of tech team tasked to design/implement "top selling" STB. (Set Top Box for TV) With a consumer product - penny saved falls to bottom line - poster's volume (unlikely) to rise that high.

b) "more the merrier" may (today) mean more confusion! It's hard enough for our tech team to "keep straight" the various "flavors" of ARM MCUs - let alone 8051, Z8 and/or MSP. Cortex M0 MCUs are (now) our choice when "pennies must be squeezed." (and they're multi-sourced - always important factor)

c) projects (most always) tend to expand - not reduce/relax. Amit used the marvelously descriptive word, "head-room" to describe. Better to provide "over-kill" so that future, unanticipated, add-on requirements may be satisfied.

0 Roberto Romano over 10 years ago in reply to Amit Ashara

Guru 27285 points

Amit Ashara said:
n this case the poster's end application is not very clear, i.e. is it just a flow sensor or there are more components to it. So we may need to wait for our poster to tell us more.

I fully agree with you and in particular as I noted usual lack of information, on my side all is known processor is battery powered excluding TIVA(coin battery) and communication line provide power to flow sensor too, and not least ready to use protocol library still work in progress with tiva.

Maybe from what I read on another post from Glenn we can codevelop RS485 interface or on new TIVAWare may be present. This moment I feel out of service so Iquit to warmer place till feel better...

0 Amit Ashara over 10 years ago in reply to cb1_mobile

TI__Guru**** 244400 points

Hello cb1

I liked the point-b, "multi-sourced". Its works out better in volume (and I have seen that with a customer some time back). A lot of customers have been moving to ARM solutions as they have competing products, allowing them to save more pennies when it comes to pricing. I actually used the term "The whole is greater than sum of the parts", when discussing with a group of customers, who were obviously comparing MSP with TM4C on power numbers... (not a good comparison)

Regards
Amit

0 Roberto Romano over 10 years ago in reply to Amit Ashara

Guru 27285 points

Hi Amit, yes I agree again your position, its excellent in all but one thing:
MSP430 has small casing, instead of SO8 smallest 8 pin I was preferring SOT23-8 or SC70 or smaller, from 14 pin and up QFN are really small and a 4x4mm(16pin) to 6x6mmm(40pin) case cannot compete at all to TIVA smallest QFP64, so are TI planning release TIVA on a smallest CASE?
If less pin is planned can be possible have pin compatible to old LM3S811? Can we have also some QFN version to save space on tight application?
This way when you are space constrained TIVA lose at start. So on a small board I can use 3x3, 4x4 LCC MSP, I can use C28027 but not TM4C12XX due to large footprint, casing of a motor, of a valve, sensor or whatever is sometimes choose by case than performance.
I wish open a voting about alternate casing, can I open question or only internal can add voting app?

C2000 VS TIVA, can I open a public comparison post about motor application? I was thinking today about INSTASPIN was on Stellaris but not on TIVA, from your perspective can TIVA substitute also C2000 entry level series? Clearly cannot compete eHPWM, CLA nor FPU or TMU, VCU II (performing also FFT) and ADC speed too.
My perspective now is a*MSP+b*C2000+c*TIVA123+d*TIVA129+e*FPGA+f*other, all parameter are winning than D is at risk of adsorption by E.
Future silicon market can change parameter to a new light but a .26$ MSP forever compete TIVA price. and a parameter is maximized to all sparse actuator and sensors.

0 Amit Ashara over 10 years ago in reply to Roberto Romano

TI__Guru**** 244400 points

Hello Roberto

First things first, unfortunately there are no new packages being planned for TM4C12x series.

C2000 is targeting a segment altogether different that Tiva as is MSP. By similar analogy you can compare MSP and C2000 as well and come to a conclusion that b is also not winning. Application, functionality and cost matters and the equation should be A*app+B*Function+C*Cost. The device that meets the requirement wins...

Regards
Amit

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

I have to say I would like more ARM mcus from TI. I know MSP and C2000 are more of TI "speciality" but I am more into ARM. 1st it has normaly good C libraries in most cases. Second as i learn more about the core base the less I want to have the same learning process with other mcu arquitecture, especially when ARM is so multi-sorced.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis Afonso said:
I would like more ARM mcus from (vendor)

Who would not? We note that (others) produce, provide, stock Cortex types: M0, M3, M4 & M7.

This valley - M4 lurks - alone...

Situation is not new - your "like" is (unlikely) to occur anytime soon - especially at the low end (M0) of the scale. (which provides lowest cost, multiple, small packages and maintains the "learning/familiarity" which are bypassed when employing (older) non-ARM alternatives...

0 Roberto Romano over 10 years ago in reply to cb1_mobile

Guru 27285 points

Hi CB1, IMHO, MSP430 now is acting as M0 is for you, in my perspective also small experience is on ARM, long time on C2000 and MSP lock some critical to them I know who are than TIVA WIP.
Forever as I wrote to Amit I dont' think C2000 inverter nor PFC can be moved to ARM without pain, ACIM motion was on Stellaris, so maybe can be moved to but TIVA is more expensive than C2000 and I again know C2K, Instaspin SW is again not really simple as they say but ready.
Alternate TIVA can be used but not now, Stellaris failure is still open issue caused long delay to projects.

Arm-based microcontrollers

Arm-based microcontrollers forum

What is the correct way to interface pulse counters