Searching \ for '[EE] How to generate a 1000 Hz pulse? (and PIC tim' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'How to generate a 1000 Hz pulse? (and PIC tim'.

Exact match. Not showing close matches.
PICList Thread
'[EE] How to generate a 1000 Hz pulse? (and PIC tim'
2009\08\15@223118 by solarwind

picon face
To get accurate speed readings for my bicycle speedometer project, I
have to count how long it will take the wheel to turn rather than how
many times it has turned in x seconds. I want a 1 second speed update
rate so to go about it, I need to count how many milliseconds it takes
for the wheel to spin once. That way, I can get an accurate speed
reading.

So, I need some way to generate and count a 1000 Hz pulse. How would I do that?

One idea is, I could use a (16 bit) timer on a PIC (16 bit would allow
for a 65 second count using a 1 KHz pulse) and count up (can a PIC
timer count up (not down)?). I can use an external crystal for the
timer and divide it down to 1000 Hz (can I divide an external clock
signal down?).

That way, once I have the timer counting at 1000 Hz, I can read and
reset the timer every time the reed switch is pulsed. For example, if
it takes 0.764 seconds for the wheel to spin once, the timer would
read 764 just before being reset for the next count. I could use 2
magnets on opposite ends of the wheel for greater accuracy (and
balance).

Would this work?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\08\16@033912 by Steve Smith

flavicon
face
Why don't you try an interrupt driven timer then it will execute the code in
your main loop once every  20mS /1Sec/1Min ect... needs a variable for each
group and a flag register to signify its time to do each activity. All runs
of the system clock and uses TMR0 or TMR1 heres a little snippet from the
ISR that sets up a tick.

;------------------------ INTERUPT
PROCESS--------------------------------------
TMR1_ISR            
;------------------------ An interrupt (based on 4MHz crystal)--------------
;------------------------TMR1H (F3)  TMR1L (CE)
25mS----------------------------
;------------------------TMR1H (CF)  TMR1L (2B)
100mS---------------------------
;------------------------TMR1H (FB)  TMR1L (21)
10mS----------------------------
       BCF                PIR1,TMR1IF                ; CLEAR INT FLAG
       BSF                TICK                        ; SET 10ms FLAG
       MOVLW        0F3h                        ; RELOAD VALUE FOR TMR1H (10ms)
       MOVWF        TMR1H                        ; SAVE IN REG
       MOVLW        0CEh                        ; RELOAD VALUE FOR TMR1L
       MOVWF        TMR1L                        ; SAVE IN REG
       MOVLW        B'00110001'                ; PSCALE 8 INT AND ON AND SYNC
       MOVWF        T1CON                        ; FIT IT
       RETURN

Steve

{Original Message removed}

2009\08\16@080201 by Rolf

flavicon
face
solarwind wrote:
> To get accurate speed readings for my bicycle speedometer project, I
> have to count how long it will take the wheel to turn rather than how
> many times it has turned in x seconds. I want a 1 second speed update
> rate so to go about it, I need to count how many milliseconds it takes
> for the wheel to spin once. That way, I can get an accurate speed
> reading.
>
> So, I need some way to generate and count a 1000 Hz pulse. How would I do that?
>  
No you don't... really.

To get the speed of your bike you need to know the circumference of your
wheel.... and the rpm of the wheel.

Yo get the RPM you need to know the 'period'.

With the RPM you have to multiply by the circumference to get the speed.

Easy.

Now, you want to get the RPM, and, you do not need a 1kHz anything to do
that.

You use the CCP module in 'capture' mode of your PIC on a 16 bit timer
with a scaled to an appropriate prescalar so that you can get any
reasonable rpm for the wheel, with an overflow interrupt on the timer to
indicate the wheel is 'stationary' (or nearly so).

Use an RC filter to 'debounce' the reed relay, and then check for
impossible changes in the PIC too.

You can use a crystal for the pic with a 'nice' frequence like
4.194304MHz to get a good 1second interrupt using a standard 16bit timer
and interrupt on overflow with a good prescalar. That Crystal will also
make the RPM calculation somewhat easier.

Rolf

2009\08\16@090615 by olin piclist

face picon face
solarwind wrote:
> To get accurate speed readings for my bicycle speedometer project, I
> have to count how long it will take the wheel to turn rather than how
> many times it has turned in x seconds. I want a 1 second speed update
> rate so to go about it, I need to count how many milliseconds it takes
> for the wheel to spin once. That way, I can get an accurate speed
> reading.
>
> So, I need some way to generate and count a 1000 Hz pulse. How would I
> do that?

I don't remember the exact diameter of a bicycle wheel, but let's say the
circumference is 9 feet.

 (60 mile/hour)(5280 feet/mile)
 -------------------------------- = 10 rotation/sec
 (9 feet/rotation)(3600 sec/hour)

The hard part will be gracefully dealing with slow speeds as the periods
become infinite.  The easiest way to measure period is with a CCP module in
capture mode.  Your input frequency is so slow that you can use a 32768Hz
crystal on timer 1 and keep the PIC asleep between captures.  Since you
don't need one part in 3000 resolution (assuming top speed of 10Hz as
above), you can use the prescaler to give up some resolution on the fast end
and get more range at the slow end.  You still have to deal with overflow,
but it all can be done.  Below some speed you just don't display a value.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\16@105545 by jim
flavicon
face
All,

Put more magnets or whatever on the wheel so you increase the frequency at
lower speeds.
So for instance, instead of 1 magnet (trigger), have 4 or 6 or 8 or 10 or
whatever.  Then in
software, even at low speeds, the frequency will be high enough that the
period between
triggers is short enough to be measured easily.  You can calculate the speed
from the new frequency.

Jim



{Original Message removed}

2009\08\16@152017 by Mark Rages

face picon face
On Sat, Aug 15, 2009 at 9:30 PM, solarwind<spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:
> To get accurate speed readings for my bicycle speedometer project, I
> have to count how long it will take the wheel to turn rather than how
> many times it has turned in x seconds. I want a 1 second speed update
> rate so to go about it, I need to count how many milliseconds it takes
> for the wheel to spin once. That way, I can get an accurate speed
> reading.

Why do you want a 1/second update rate?  Why not update the screen
when new information arrives, eg. at the "wheel rotated" event?   You
can always add resampling later if that's what you really want to do.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
.....markragesKILLspamspam@spam@midwesttelecine.com

2009\08\16@162000 by Marechiare

picon face
> To get accurate speed readings for my bicycle speedometer
> project, I have to count how long it will take the wheel to turn
> rather than how many times it has turned in x seconds. I want
> a 1 second speed update rate so to go about it, I need to count
> how many milliseconds it takes for the wheel to spin once.
> That way, I can get an accurate speed reading.

A 32 bit  free running counter over the prescaler giving 10KHz. On
sensor event store the counter's value. Store last 4 values. That's
it. On a display interrupt get the difference between first and 4th
values, that is total time span for the last 3 rotations, calculate
and show the speed.

And, please, don't ask how to organize a 32 bit free running counter,
what's prescaler, why you need an interrupt to display the result etc.

2009\08\17@073922 by olin piclist

face picon face
jim wrote:
> Put more magnets or whatever on the wheel so you increase the
> frequency at lower speeds.
> So for instance, instead of 1 magnet (trigger), have 4 or 6 or 8 or
> 10 or whatever.

How's that better than just increasing the prescaler, essentially clocking
the timer lower?  You still have all the same constraints.  At the high end
you need some minimum resolution.  For a fixed size timer, that dictates the
lowest frequency you can measure without wrapping.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\17@094640 by olin piclist

face picon face
Mark Rages wrote:
> Why do you want a 1/second update rate?  Why not update the screen
> when new information arrives, eg. at the "wheel rotated" event?

Because that would make the numbers change too fast for reasonable human
viewing at ordinary speeds.

I would have the interrupt routine compute the period, low pass filter that
a little, then leave it lying around for the foreground to to grab when it
wants.  The foreground code grabs the current period value maybe twice a
second, inverts it to make speed, and displays the result.

Decoupling the period measurement from the display actually solves more
problems than it creates.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\17@112351 by jim

flavicon
face
Olin,

I didn't say it was better.  It's just a suggestion.
If you don't like it, don't use it.  I don't care.

Jim





{Original Message removed}

2009\08\17@115515 by olin piclist

face picon face
jim wrote:
> I didn't say it was better.  It's just a suggestion.
> If you don't like it, don't use it.  I don't care.

I'm not the one building the bike speedometer.  I was only pointing out how
your suggestion "less than optimal".  Others can do with that information as
they wish.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\17@124352 by Marechiare

picon face
> I would have the interrupt routine compute the period,
> low pass filter that a little, then leave it lying around for
> the foreground to to grab when it wants.

In general that is not a good idea to load the sensor event interrupt
routine with the calcs. The sensor event interrupt should be of the
highest priority and its mission should be to persist the current
state only.

> The foreground code grabs the current period value
> maybe twice a second, inverts it to make speed, and
> displays the result.

There should be middle level (I'd say Business Level) code to deal
with the persisted state. Its output should be meaningful values, like
speed, distance etc.

And there should be UI (User Interface) level code to display the BL
level output.

> Decoupling the period measurement from the display
> actually solves more problems than it creates.

That's very true.

2009\08\17@125708 by olin piclist

face picon face
Marechiare wrote:
>> The foreground code grabs the current period value
>> maybe twice a second, inverts it to make speed, and
>> displays the result.
>
> There should be middle level (I'd say Business Level) code to deal
> with the persisted state. Its output should be meaningful values, like
> speed, distance etc.
>
> And there should be UI (User Interface) level code to display the BL
> level output.

I agree that what I called "foreground code" would actually be several
modules.  However, there is no point computing speed from period except when
it's needed, which is whenever you want to display a new speed value.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\08\17@134421 by Marechiare

picon face
>>> The foreground code grabs the current period value
>>> maybe twice a second, inverts it to make speed, and
>>> displays the result.
>>
>> There should be middle level (I'd say Business Level) code to deal
>> with the persisted state. Its output should be meaningful values, like
>> speed, distance etc.
>>
>> And there should be UI (User Interface) level code to display the BL
>> level output.
>
> I agree that what I called "foreground code" would actually be several
> modules.  However, there is no point computing speed from period except when
> it's needed, which is whenever you want to display a new speed value.

I agree that there is no such point for the app at this stage of the
development. But later the calculated values will be needed for other
functionality. So to make the app consistent snd to avoid unneeded
recalculations it would make sense to provide complex calcs at some
reasonable period.

2009\08\17@141630 by jim

flavicon
face
All,

My opinion is if you want to build an application for yourself, or for sale
for that matter, and you have an idea for the software/firmware in mind, and
you can get it to work, then there is no reason to not use it.
With that said, obviously there are ways of optomizing some routines.  But
that doesn't mean that one way is more correct than another.  Only that it
is different.

My point is this.  If you want to write your software to make calculations
of numbers that you may or may not use at some later time, and the unit
functions as you'd like it to, then write your software that way.   If you
want to try to optomize your code somewhat, and you have few ideas about how
to go about doing that, and you want advice from the PICLIST, then by all
means ask for such advice.

However, you're not wrong if you get advice and decide not to use it, but
instead go with your original idea.
As long as the final outcome of the device you build meets the
specifications you want it to, then all is well.

If anyone is angered by this, flame me off line, not on the list.

Jim



{Original Message removed}

2009\08\17@142803 by Mark Rages

face picon face
On Mon, Aug 17, 2009 at 12:44 PM, Marechiare<marechiarespamKILLspamgmail.com> wrote:
{Quote hidden}

YAGNI.  http://c2.com/xp/YouArentGonnaNeedIt.html

Especially in embedded programming, you should endeavor to not add
features until they are needed.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
.....markragesKILLspamspam.....midwesttelecine.com

2009\08\17@145630 by Marechiare

picon face
>> I agree that there is no such point for the app at this
>> stage of the development. But later the calculated
>> values will be needed for other functionality. So to make
> the app consistent snd to avoid unneeded recalculations
> it would make sense to provide complex calcs at some
>> reasonable period.
>>
>
> YAGNI.  http://c2.com/xp/YouArentGonnaNeedIt.html
>
> Especially in embedded programming, you should
> endeavor to not add features until they are needed.

It is not about extra features, it's about architecture, or you may
call it culture. No (almost) extra code, just the code organization.
The discussion is pretty much useless, either a person is able to get
it or he is not. You can't make him to overcome the wall.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...