Searching \ for '[PIC] pulse counter help?' 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/time.htm?key=count
Search entire site for: 'pulse counter help?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] pulse counter help?'
2005\11\07@142056 by Danny Sauer

flavicon
face
I've finally gotten tired of my transmission's torque converter
locking up as soon as the transmission shifts into 4th gear.  So, my
plan is to build a simple device which will disable the lockup (which
is simply activating or deactivating a relay) when I'm below a given
speed.

I have an electronic speedometer which generates a nice buffered
square wave from the electronic sender.  Based on acceptable inputs
for the speedometer and an assumption that I'll never travel any
faster than 240MPH, I need to accurately count pulses with a frequency
of between 1Hz and 27KHz.  So, I guess that Nyquist would tell me that
I need to sample at about 54KHz.  So, presuming that I count for one
second intervals, a 16-bit unsigned int should be adequate.  I'll need
to have the capability to calibrate the unit (for tire or gear
changes, driving preference, etc), which I envision being implemented
by pressing a button to enter "calibration mode" and then pressing the
button again when I'm moving at the speed I want as the set point.
I'm pretty sure I'll want the enable to happen as some point which is
just a little faster than the disable point, so the converter isn't
constantly going in and out of lock mode - or maybe it'd be better to
have a timer loop start after crossing and staying above the threshold
point, resetting if the speed drops below before the lock time.  That
might be better.

So, with that background, here's my problem.  I'm not really sure of
what would be a good way to do the frequency measuring part.  I have a
lot of high-level programming background, but these little devices are
pretty new to me, and comprise most all of my assembler experience.
So, I was hoping that someone here might either have a quick solution,
or be able to point me in the right direction.  I think it's a 16f676
or a 12f675 that I'd be using with the 4MHz internal clock (sorry if
those are stupid part numbers - it's been a few months since I played
with them, and I've forgotten the model number).

Anyway, I don't know if I should use the internal timer with a
multiplier and sample on interrupt, or maybe use the speed sensor as a
clock input and do something with that?  Maybe I should just count the
operations that I can do between samples?  It really feels like I
should find some way to count the pulses which come in during a
specific period of time and then do something with that number - like
seeing if it's greater than or equal to a stored value over some
number of sampler periods.  I'm looking for advice, though, from
people who know these things way better than I do.  My primary concern
is being able to use *just* the PIC - not picking up an external
real-time clock or frequency counter or whatever.  I'd like to limit
this to just the chip, a voltage regulator, a relay, and a diode to
protect the pic from the relay (advice on the diode would be welcome
too).

If there's a FAQ out there that answers this, I'd appreciate a URL.
There's *so* much semi-related information that it's difficult to find
what I'm looking for.

Thanks much!
--Danny

2005\11\07@145529 by Andre Abelian

flavicon
face
Danny,

PIC has hardware built in CCP just use Capture and it does the job for you.
you can setup to capture every pulse or every 4th pulse etc. and it will
cause interrupt.

Andre



Danny Sauer wrote:

{Quote hidden}

2005\11\07@150310 by Timothy Weber

face picon face
Danny Sauer wrote:
> It really feels like I
> should find some way to count the pulses which come in during a
> specific period of time and then do something with that number - like
> seeing if it's greater than or equal to a stored value over some
> number of sampler periods.  

I'm no expert, but this sounds good to me.

You could use Interrupt On Change on an I/O pin and count all the
positive transitions.

Then, the 12F675's Timer1 has a maximum period of around half a second,
using the internal 4 MHz oscillator, so you could use that as your
sampling period.  When timer 1 rolls over, check your count, enable or
disable the relay, and reset the count to 0.

The threshold value you're looking for could be determined
experimentally (e.g., hitting a button writes the current count to
EEPROM, for reading back later) or by multiplying a known input
frequency by the clock period (0.524288 s).

No?
--
Timothy J. Weber
http://timothyweber.org

2005\11\07@152224 by Bob Blick

face picon face
> I've finally gotten tired of my transmission's torque converter
> locking up as soon as the transmission shifts into 4th gear.  So, my
> plan is to build a simple device which will disable the lockup (which
> is simply activating or deactivating a relay) when I'm below a given
> speed.


Here's something not directly related to your question. If you intend to
interrupt the power to the lockup solenoid, you will trigger an error in
the diagnostics. The dashboard light may not bother you, but eventually it
will be written into memory as a serious transmission problem and will
remain after you have removed your gadget. If you ever sell the car you
may find that suddenly all the dealers (yes, they are networked) think you
need a new transmission, and your car is worth $3000 less than it should.
This comes from the "been there, done that" department.

On the other hand, if your circuit pulses the brake pedal signal to the
computer, it will inhibit torque converter lockup and not generate any bad
codes. Also from the "been there, done that" department.

Also, you can get speed, rpm, etc from the OBD port, and there happens to
be an OBD related article in this month's Circuit Cellar magazine.

Cheerful regards,

Bob





2005\11\07@160752 by Danny Sauer

flavicon
face
Bob wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at 14:25:
{Quote hidden}

I should probably mention that this is a 1971 Chevelle with a BowTie
Overdrives TH200-4R.  The lockup is controlled using a very simple
circuit internal to the transmission which engages the clutch a moment
after the trans shifts into fourth, and disengages it just before
shifting out (based on my understanding).  The circuit depends on a
constant power source which runs through a switch on the brake pedal,
so that the converter automatically disengages when the brake's
depressed.  There's a manual override switch which will engage the
lockup solonoid in third as well - for towing purposes - which is
powered by the same brake switch power source.  My intention is to
place this relay after teh take-off for the 3rd gear override and
able to break power from the tranny.

If I had an engine managing computer, it'd probably be doing this for
me already. :)

Thanks for that, though.
--Danny

2005\11\07@162416 by Sean Schouten

face picon face
> You could use Interrupt On Change on an I/O pin and count all the
> positive transitions.
>
>
I would not turn the GIE on and have an interrupt disturb the rest of your
operation though. I would just poll the Pin. If you have to poll all the way
up to 54Khz and your pic is running at 4Mhz (= 1MIPS), you should have more
than enough time to poll and cater to other needs at the same time. It saves
you doing complicated things.

Sean.

2005\11\07@162614 by Sean Schouten

face picon face
Wouldn't it be possible to rig up a 2nd pic that fools the computer into
thinking that the torque converter is doing what it is supposed to by
generating the right feedback for the computer's actions? Just a thought!

Sean.

On 11/7/05, Bob Blick <spam_OUTbblickTakeThisOuTspamsonic.net> wrote:
{Quote hidden}

>

2005\11\07@172843 by regen / Mailinglists

flavicon
face
> Here's something not directly related to your question. If
> you intend to interrupt the power to the lockup solenoid, you
> will trigger an error in the diagnostics. The dashboard light
> may not bother you, but eventually it will be written into
> memory as a serious transmission problem and will remain
> after you have removed your gadget. If you ever sell the car
> you may find that suddenly all the dealers (yes, they are
> networked) think you need a new transmission, and your car is
> worth $3000 less than it should.
> This comes from the "been there, done that" department.

If the car has OBD, it will have an error memory for sure.

> On the other hand, if your circuit pulses the brake pedal
> signal to the computer, it will inhibit torque converter
> lockup and not generate any bad codes. Also from the "been
> there, done that" department.

This was a very common trick to disable the electronic slip differential
in early Volkswagen Golf VR6. But you should check, if the brake light
will flash the same time (as on later VR6 ;-)

Best Jens

2005\11\07@173430 by Herbert Graf

flavicon
face
On Mon, 2005-11-07 at 13:20 -0600, Danny Sauer wrote:
> I've finally gotten tired of my transmission's torque converter
> locking up as soon as the transmission shifts into 4th gear.  So, my
> plan is to build a simple device which will disable the lockup (which
> is simply activating or deactivating a relay) when I'm below a given
> speed.

Just a warning, depending on the vehicle disabling the lockup circuit
will result in an engine light.

For example, when the lockup clutch solenoid shorted in my 1988 Olds the
engine light came on when the computer detected to high a current draw.

So, I disconnected that wire. All that did was cause the engine light to
come on when the computer was NOT trying to engage the clutch! The
computer sensed that +12V wasn't present when the clutch wasn't engaged
and turned on the engine light.

Newer cars may even be worse. A disabled lockup clutch might even result
in your tranny or engine computer going into a less efficient "safe"
mode, who knows!

Just thought you'd like to know. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\11\07@173814 by Herbert Graf

flavicon
face
On Mon, 2005-11-07 at 12:22 -0800, Bob Blick wrote:
> > I've finally gotten tired of my transmission's torque converter
> > locking up as soon as the transmission shifts into 4th gear.  So, my
> > plan is to build a simple device which will disable the lockup (which
> > is simply activating or deactivating a relay) when I'm below a given
> > speed.
>
>
> Here's something not directly related to your question. If you intend to
> interrupt the power to the lockup solenoid, you will trigger an error in
> the diagnostics. The dashboard light may not bother you, but eventually it
> will be written into memory as a serious transmission problem and will
> remain after you have removed your gadget. If you ever sell the car you
> may find that suddenly all the dealers (yes, they are networked) think you
> need a new transmission, and your car is worth $3000 less than it should.
> This comes from the "been there, done that" department.

One of the first things I bought after getting an OBD2 car was an OBD2
reader. It is a tool I'd recommend everyone get. Even if you're not a
mechanic it sure is reassuring to know that if that light comes on you
can immediately find out WHY it came on, and whether it's safe to
continue driving.

My point is OBD2 readers can clear all the codes stored, getting around
this issue.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\11\07@174712 by Bob Blick

face picon face

> My point is OBD2 readers can clear all the codes stored, getting around
> this issue.

It can only clear the codes it is designed to clear. Transmission failure
codes are not part of the standard OBD2. So if your Volvo has a
transmission failure code, your $149 generic reader will not clear it.

Cheers,

Bob

2005\11\07@175217 by Danny Sauer

flavicon
face
Sean wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at 15:26:
> > You could use Interrupt On Change on an I/O pin and count all the
> > positive transitions.
> >
> >
> I would not turn the GIE on and have an interrupt disturb the rest of your
> operation though.

It seems that dealing with interrupts all the time would mess with
timing information.  Maybe I could use a tight loop to check for the
number of times Timer1 has overflowed since the last rising edge and
the value in Timer1.  Even down to 1Hz, the overflow counter should be
more than adequate (at most I'd have 2 overflows), so I'd just have to
store the two byte counter value and the one byte overflow counter for
calibration information.

If I did that, then I could have an interrupt-on-change handling
routine to take care of alerting me when a pulse occurs, and an
interrupt handler for when Timer1 overflows.  That'd get rid of the
"poll for overflow" loop.  Right?  So then I'd be pretty much freed
from having to deal with any timing calculations since I don't care
what the "actual" time is, so long as I have a "consistent" timing
source.  If I wanted to do something else with the chip (there's still
a few unused GPIOs!), that'd sure make things easier.  Presuming I
don't want to do anything else time-critical on the same chip at the
same time, I guess.

The only drawback to this that I see is that I'm getting timing
information for a single cycle as opposed to a series of cycles.  I
think it'd be better to do an average over several cycles for
accuracy.  Maybe my pulse interrupt handling routine could compare
timing information over something like 16 pulses or something?  That'd
probably increase my accuracy for higher frequency signals, I'd think.
I'm mostly concerned with the time period on the low end - I'll
probably be seeing something in the range of 50-100Hz at the speeds
I'm most concerned about, so 16 pulses should take less than .25
second, allowing me to take plenty of samples in my "stay above this
speed for a few seconds" or "drop below this speed for a few seconds"
window.

Thoughts?  Should I really worry about missing interrupts when I'm in
one routine handling an interrupt with interrupts disabled?  The
on-change interrupt handler should probably just decrement a counter
and see if it hit zero (or went past zero, I guess), which won't take
much time, and the timer overflow interrupt should just be
incrementing an overflow counter.  I can disable interrupts when the
counter gets to zero, do my processing, reset the state machine, and
re-enable interrupts.  Does this all make sense?

--Danny

2005\11\07@181515 by Timothy Weber

face picon face
Danny Sauer wrote:
> Sean wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at 15:26:
>
>>>You could use Interrupt On Change on an I/O pin and count all the
>>>positive transitions.
>>
>>I would not turn the GIE on and have an interrupt disturb the rest of your
>>operation though.
>
> It seems that dealing with interrupts all the time would mess with
> timing information.

Huh?  Why?  It doesn't sound to me like your timing requirements are so
tight that interrupt handling latency would be significant, and you
haven't yet said anything about doing anything else on the chip, so
losing cycles from your "loop: goto loop" code won't hurt!

If you do want to do something else, I'd say using interrupts will
simplify the overall design, not make it more complex.

> The only drawback to this that I see is that I'm getting timing
> information for a single cycle as opposed to a series of cycles.  I
> think it'd be better to do an average over several cycles for
> accuracy.  Maybe my pulse interrupt handling routine could compare
> timing information over something like 16 pulses or something?

You could certainly shorten the sampling cycle (e.g., by dropping the
prescaler value on Timer 1) and implement some kind of filter.

Again, I know nothing about cars, but this part seems pretty simple.
--
Timothy J. Weber
http://timothyweber.org

2005\11\07@183357 by regen / Mailinglists

flavicon
face
> It can only clear the codes it is designed to clear.
> Transmission failure codes are not part of the standard OBD2.
> So if your Volvo has a transmission failure code, your $149
> generic reader will not clear it.

Sorry, but ....

P0700  
Transmission Control System Malfunction

P0701  
Transmission Control System Range/Performance

P0702  
Transmission Control System Electrical

P0703  
Torque Converter/Brake Switch B Circuit Malfunction

P0704  
Clutch Switch Input Circuit Malfunction

P0705  
Transmission Range Sensor Circuit malfunction (PRNDL Input)

P0706  
Transmission Range Sensor Circuit Range/Performance

P0707  
Transmission Range Sensor Circuit Low Input

P0708  
Transmission Range Sensor Circuit High Input

P0709  
Transmission Range Sensor Circuit Intermittent

P0710  
Transmission Fluid Temperature Sensor Circuit Malfunction

P0711  
Transmission Fluid Temperature Sensor Circuit Range/Performance

P0712  
Transmission Fluid Temperature Sensor Circuit Low Input

P0713  
Transmission Fluid Temperature Sensor Circuit High Input

P0714  
  Transmission Fluid Temperature Sensor Circuit Intermittent


......

P07xx means Powertrain Standard (not Manufactor specific) Transmission


;-) Jens


2005\11\07@183835 by Danny Sauer

flavicon
face
Timothy wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at 17:17:
> Danny Sauer wrote:
> >Sean wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at
> >15:26:
> >>I would not turn the GIE on and have an interrupt disturb the rest of your
> >>operation though.
> >
> >It seems that dealing with interrupts all the time would mess with
> >timing information.
>
> Huh?  Why?

I was thinking about things like counting the number of operations
between polling in order to calculate the frequency - but as my
stream-of-conciousness email rolled on I drifted away from that.  My
bad - I probably should've just erased that part. :)

> Again, I know nothing about cars, but this part seems pretty simple.

Knowledge of cars is irrelevent, and it *seems* simple to me too.  I
think I just needed to talk about it out loud to better figure out the
details.  I've been away from these devices for too long relative to
the time I spent with them to begin with.  Hopefully subscribing to
the list will keep me from doing that again. ;)

--Danny, always with the ideas but never with the time to implement
them

2005\11\07@185645 by Bob Blick

face picon face

> I was thinking about things like counting the number of operations
> between polling in order to calculate the frequency - but as my
> stream-of-conciousness email rolled on I drifted away from that.  My
> bad - I probably should've just erased that part. :)

Andre mentioned using the capture portion of one of the CCP peripherals to
measure the period. It works quite well, and there's no need to use
interrupts at all, so here's a second vote for capture.

Cheerful regards,

Bob



2005\11\07@204723 by Danny Sauer

flavicon
face
Bob wrote regarding 'Re: [PIC] pulse counter help?' on Mon, Nov 07 at 17:58:
>
> > I was thinking about things like counting the number of operations
> > between polling in order to calculate the frequency - but as my
> > stream-of-conciousness email rolled on I drifted away from that.  My
> > bad - I probably should've just erased that part. :)
>
> Andre mentioned using the capture portion of one of the CCP peripherals to
> measure the period. It works quite well, and there's no need to use
> interrupts at all, so here's a second vote for capture.

That means using TMR0 as a counter, right?

Given my desired useful range of signals from 1Hz to 27KHz, isn't the
use of the counter going to be a limiting factor?  I can't wait for a
1Hz signal to overflow the 8-bit counter (256 seconds it a long time),
while a 27KHz signal will cause an overflow within 2.2ms.  If the
chip's running at 4MHz, then the clock's counter runs at 1MHz, right?
I guess it'd have enough accuracy on the high end, but to get a
reasonable number of pulses in, say, 3-4 seconds using the counter
overflow as a trigger I can't be accurate below 64Hz usint a large
multiplier.  If I use a large multiplier, than I limit the upper end.
If I instead use a time-based poll interval, then I lose a whole bunch
of precision on the bottom end by setting the interval low enough to
fit 256 pulses at 27KHz into TMR0 as a counter.  So, the range of
frequencies I want to be compatible with seems to limit me.  Granted,
I just arrived at that range based on what my speedometer takes as
input, but I figured the folks at AutoMeter had a good reason for
doing what they did.

At least, that's my understanding based on what I think's available to
me.  Please correct me if I'm wrong - you guys are the experts.  I
just want a fairly simple solution that I'll likely be able to get
right without a lot of debugging. :)  Well, that, and interrupt-driven
code seems like what all the cool kids are doing. ;)

Thanks!
--Danny

2005\11\07@211054 by Jinx

face picon face
> >
> > CCP peripherals
>
> That means using TMR0 as a counter, right?

The 12F675 has no CCP

It does have the 16-bit Timer1

> Given my desired useful range of signals from 1Hz to 27KHz

Assuming 4MHz nominal IntOsc -> 1us count rate

1Hz = 1,000,000 counts per cycle (ie between +ve edges)
27kHz = 37.037 counts per cycle

The simplest thing to do would be to have T0CKI as the edge
detector. Pre-set TMR0 to FF and use T0IF as the indicator
that an edge has occured, causing a roll-over. When T0IF -> 1,
read Timer1 and run it through the maths. If the maths will take
too long to process before the next anticipated T0IF (which you
can gauge by the reading in TMR1), then at the higher frequencies
you'll have to do two or more readings and average

2005\11\07@214012 by Bob Blick

face picon face
I guess in all the car talk I missed the choice of 12F675 - you don't
have a CCP peripheral. But you can use TMR1 running from the
internal clock with a prescaler value that gets the pickup frequency
within a nice range(TMR1 is 16 bit), and either poll your pickup or
have it generate an interrrupt, then read the period and subtract the
value you just read from TMR1 or just reset it.

But you should also protect yourself against TMR1 overflow, so you
should either poll TMR1IF or interrupt on it. And if you have an
overflow, I'd suggest setting the highest bit of TMR1. If you have
overflowed TMR1, you already know your speed is zero or close to
it, and if you clear TMR1, and then get a pickup sugnal immediately
following that, you might think your speed is high.

Cheerful regards,

Bob

2005\11\07@215853 by Timothy Weber

face picon face
Jinx wrote:
> The simplest thing to do would be to have T0CKI as the edge
> detector. Pre-set TMR0 to FF and use T0IF as the indicator
> that an edge has occured, causing a roll-over. When T0IF -> 1,
> read Timer1 and run it through the maths.

I guess to me interrupt-on-change is simpler than that - you don't have
to reset the the timer to FF, and you have 6 available pins to choose
from rather than one that's fixed.

Not to be contrary, just wondering if I've overlooked something.
--
Timothy J. Weber
http://timothyweber.org

2005\11\07@222120 by Jinx

face picon face
> have it generate an interrrupt, then read the period and subtract
> the value you just read from TMR1 or just reset it

Could add that at the higher frequencies the OP might choose
to take a single measurement and then ignore subsequent edges
until the maths has finished. Because the resolution will be a little
grainy at the top end, as 4MHz is quite slow, averaging would
help smooth out the eventual result, at the expense of having it
lag a bit behind real time

With a single reading (1000k/27k) = 37.037

If TMR1 = 37, frequency = 27027Hz
If TMR1 = 38, frequency = 26315Hz

no intermediate values in that 712Hz span

Averaging say 10 readings would get you the intermediate values,
although delaying the result by a few 100 us. A running average
is doable but may not be necessary, important and/or worth the
extra effort. If you wanted better resolution it would be far more
economic to stick in a fast crystal (would speed up the processing
time too of course for added benefits)


2005\11\07@222749 by Jinx

face picon face
> I guess to me interrupt-on-change is simpler than that - you don't
> have to reset the the timer to FF, and you have 6 available pins to
> choose from rather than one that's fixed.
>
> Not to be contrary, just wondering if I've overlooked something

No, IOC is an option. IOC isn't necessarily any easier, just another
way to do it. One advantage of T0CKI being unique is that if you
have other activity on GPIO, that might cause headaches with IOC.
But that's for the designer to sort out. IOC itself is perfectly viable

2005\11\08@072824 by olin piclist

face picon face
Danny Sauer wrote:
>> Andre mentioned using the capture portion of one of the CCP
>> peripherals to measure the period. It works quite well, and there's
>> no need to use interrupts at all, so here's a second vote for
>> capture.
>
> That means using TMR0 as a counter, right?

No, it doesn't.  It's time to actually *read* the data sheet.

> Given my desired useful range of signals from 1Hz to 27KHz, isn't the
> use of the counter going to be a limiting factor?  I can't wait for a
> 1Hz signal to overflow the 8-bit counter (256 seconds it a long time),
> while a 27KHz signal will cause an overflow within 2.2ms.

This brings up a different issue.  I can't imagine why you need 27000:1
dynamic range (15 bits) on your vehicle speed.  Even if you consider the top
end of 27KHz maps to an absurd speed of 240MHP, then 1MHP (447mm/S) still
results in 113Hz.  Especially since you were talking about 4th gear, why do
you care whether the car is moving at .1MHP, 1MHP, or even 10MHP?

Go read about the CCP module.  It is great for capturing the time between
pulses.  You may be able to use period directly since you're only comparing
to fixed speed values.  If you really need speed, then you'll have to do a
divide.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\08@074618 by olin piclist

face picon face
Jinx wrote:
> The 12F675 has no CCP

So get one that does.  12F683, 16F627A, ...

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\08@082935 by Danny Sauer

flavicon
face
Olin wrote regarding 'Re: [PIC] pulse counter help?' on Tue, Nov 08 at 06:35:
> Danny Sauer wrote:
> >> Andre mentioned using the capture portion of one of the CCP
> >> peripherals to measure the period. It works quite well, and there's
> >> no need to use interrupts at all, so here's a second vote for
> >> capture.
> >
> > That means using TMR0 as a counter, right?
>
> No, it doesn't.  It's time to actually *read* the data sheet.

For which processor?  The 12F675 or the 16F676 are my two options.
Since I didn't remember seeing CCP mentioned in their data sheets
(which I did read - cover to cover - and which I have printed out and
bound right next to me now), I figured it was a common abbreviation
for using the Clock as a Counter of Pulses or something like that -
another post cleared up that a CCP is something on other processors
which I'm not using.  Though, it sounds interesting.  I only have the
programmer from the PICkit-1 - do any of the midrange processors
compatible with that programmer have that?

{Quote hidden}

This is a valid question.  The speed sensor*s* I hope to be compatible
with typically have their output specified in pulses per mile, not
pulses per second.  The 1Hz frequency I arrived at based on a speed of
5MPH at the lowest possible pulse per mile rate (actually it's
something like .996 Hz, so for simplicity I truncated to 1Hz).  27Hz
was calculated based on the highest possible pule per mile rate at
240MPH.  Why 240MPH?  I chose to go with a speed divisible by 60 for
ease of calculating miles per second, and two of my cars are capable
of exceeding 180 MPH - the one I'm working on right now theoretically
should be able to do it, and the other peaked at 196 as measured by
radar.  No, not on the street, but I do occasionally race them, and
it's not inconceivable that I could at some point find myself making a
run at Bonneville or similar again.  Since there has to be a limit
somewhere, I don't want it to be a limit that I'll ever reach.  So, I
chose a worst case of 240MPH and a maximum pulse output rate, which is
actually about 26,843 HZ - 27KHz is easier to type.  I can't measure
the actual output, becuase that's only valid for the specific
transmission/rear end/tire size combination on the car right now.  If
I change any of those things, the frequency will change.  On another
car, the frequency will be different.  And I don't have a scope. :)
So, since I want a black box which can figure out for itself what
frequency I care about and whether or not the current signal is faster
or slower, I'm designing for the worst-case.

For this specific application, I only care about speeds in the
30-45MPH range, give or take a few MPH.  But I can see other useful
applications for a speed-sensitive switch.  Disabling the trunk latch
and door locks at speeds over 5MPH, activating a "your speeding"
indicator at speeds greater than 65, engaging the nitrous controller
if a full-throttle switch is depressed *and* speed is greater than a
certain point (for traction purposes), etc.  So, if it's possible to
cover the whole range with room to spare without extra difficulty, why
not do it? :)

--Danny

2005\11\08@110409 by Timothy Weber

face picon face
Danny Sauer wrote:
> For this specific application, I only care about speeds in the
> 30-45MPH range, give or take a few MPH.  But I can see other useful
> applications for a speed-sensitive switch. [...] So, if it's possible to
> cover the whole range with room to spare without extra difficulty, why
> not do it? :)

One good answer is "Sure, go ahead!"

However, this brings up a rather subtle and deep issue in software design.

One classic software engineering principle is Donald Knuth's famous
statement "Premature optimization is the root of all evil."  I can talk
forever about that, but I think most of us who've done any non-trivial
programming know what it means.

There is another principle for which I have never heard such a nice
catchy aphorism, though the terms "feature creep" and "featuritis" refer
to it.  It's something like this:

1. Write code that will be easy to maintain and expand later.

2. BUT, don't implement features you don't need.

This can be a tricky line to walk.  Obviously nobody likes to go back to
old code and rip things out because they're not compatible with a new
direction - and it's even worse to go back and NOT rip things out, but
try to kludge something onto them that will sorta work.  So we try to
plan ahead.

But, if you plan for every feature you MIGHT need at some point in the
future, it becomes similar to premature optimization - you often go down
a slippery slope and find that something that seemed like it was going
to come "for free" has now affected your entire design and made it more
difficult to work with.  Nothing comes for free.

This is way too much detail so I'll stop here.  But I'll just say that
if all you need for THIS project is to answer the question "Is my
current speed faster or slower than a threshold?", you should maybe
beware of expanding that question to "What is my current speed?" if you
don't need to (or until you need to).

Hobby projects often have some immunity to this rule, because it may be
all about exploring something that interests you.  But even on a hobby
project, getting results in finite time is also a good thing...

I'll go away now.
--
Timothy J. Weber
http://timothyweber.org

2005\11\08@114803 by Danny Sauer

flavicon
face
Timothy wrote regarding 'Re: [PIC] pulse counter help?' on Tue, Nov 08 at 10:21:
> Danny Sauer wrote:
> >For this specific application, I only care about speeds in the
> >30-45MPH range, give or take a few MPH.  But I can see other useful
> >applications for a speed-sensitive switch. [...] So, if it's possible to
> >cover the whole range with room to spare without extra difficulty, why
> >not do it? :)
>
> One good answer is "Sure, go ahead!"
>
> However, this brings up a rather subtle and deep issue in software design.
>
> One classic software engineering principle is Donald Knuth's famous
> statement "Premature optimization is the root of all evil."  I can talk
> forever about that, but I think most of us who've done any non-trivial
> programming know what it means.

Probably all I need to say in reponse to this is that my day job is
about 25-50% maintaining and completing someone else's very large Perl
project.  Someone who felt compelled to use all of the obtuse features
Perl has to offer, who - I'm told - had to be *forced* to add any
comments at all, and someone who subscribed to the parenthesis free
school of Perl.  Someone implementing a project which was designed to
do it all, even though it only needed to do "some".

Augh.  I really like Perl, but people who are bad programmers should
stay the heck away from it - especially if I'll have to be involved
later on. :)

Good point, though, and a well-written one.  I'll refer back to it when
I post a little later about how I'd like to integrate a throttle
position sensor into this project so that the lockup enable point can
be shifted up and down a little based on where the throttle is at, and
so the converter can be unlocked when the throttle is opening
"rapidly".  There's good ADC sample code out there, though, so I may
not have to ask here...

BTW, Kunth should've said something about not putting in arbitrary
limits where there doesn't need to be a limit.  That's *my* pet peeve.

--Danny

2005\11\08@124250 by Paul James E.

picon face

All,

Another thing you may want to look at possibly is a frequency to voltage
converter.  This way, you can measure a voltage using the ADC on the PIC,
and you could adjust the trip point with a pot on another ADC pin. And
with this in mind, you could even have a third pot that would adjust the
fallout point once it did lock up.  So you could adjust the trip point
both up and down and have the desired hysteresis.  This adds a little more
hardware, but it would solve the frequency problem (IIRC, the FV9400(?) F
to V has a BW of about 100Kkz I believe), it would simplify the firmware,
and you could use it in more than one application.   Also, that would
allow room for adding other features not necessarily related to the
frequency measurement.

Just food for thought.


                                            Good Luck and Regards,

                                                   Jim



{Quote hidden}

> --

2005\11\08@124300 by Timothy Weber

face picon face
Danny Sauer wrote:
>>statement "Premature optimization is the root of all evil."  I can talk
>
> Probably all I need to say in reponse to this is that my day job is
> about 25-50% maintaining and completing someone else's very large Perl
> project.  Someone who felt compelled to use all of the obtuse features
> Perl has to offer, who - I'm told - had to be *forced* to add any
> comments at all, and someone who subscribed to the parenthesis free
> school of Perl.  Someone implementing a project which was designed to
> do it all, even though it only needed to do "some".

I feel your pain!  I'll stop preaching to the choir.  I think featuritis
particularly bites me when dealing with microcontrollers - maybe it's
because my head is more in desktop apps so I'm still not quite used to
the relative difficulty of implementing a feature at this level.

And yeah - write-only code is everywhere, but Perl sure does make it easy!

> BTW, Kunth should've said something about not putting in arbitrary
> limits where there doesn't need to be a limit.  That's *my* pet peeve.

Agreed - though we could probably make that into a special case of
"premature optimization" with a little effort.

Cheers.
--
Timothy J. Weber
http://timothyweber.org

2005\11\08@162011 by olin piclist

face picon face
Danny Sauer wrote:
> For which processor?  The 12F675 or the 16F676 are my two options.

I didn't realize you were using a PIC without a CCP module.  CCP stands for
"Compare, Capture and Pulsewidth modulation".  In the capture mode it saves
a snapshot of timer 1 when a pulse is received.  The software can then grab
the captured value when it gets around to it, as long as that happens before
the next value is captured.  Since the hardware is doing the timer capture,
there is no latency or jitter.  You can run timer 1 from the instruction
clock and get very accurate period measurements that way.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\11\08@212018 by Danny Sauer

flavicon
face
Olin wrote regarding 'Re: [PIC] pulse counter help?' on Tue, Nov 08 at 15:24:
> Danny Sauer wrote:
> > For which processor?  The 12F675 or the 16F676 are my two options.
>
> I didn't realize you were using a PIC without a CCP module.  CCP stands for
> "Compare, Capture and Pulsewidth modulation".  In the capture mode it saves
> a snapshot of timer 1 when a pulse is received.  The software can then grab
> the captured value when it gets around to it, as long as that happens before
> the next value is captured.  Since the hardware is doing the timer capture,
> there is no latency or jitter.  You can run timer 1 from the instruction
> clock and get very accurate period measurements that way.

I'm not very familiar with the PIC line at all - so I've been sticking
with the 12f675 and the chip that's basically the same but with more
GPIOs, the 16F676.  In one of your other posts I saw mention of the
12F683, so I read the data sheet on it today.  The CCP does look like
a nifty piece, and the presence of 4 ADCs addresses a problem I had
earlier with working around the limitation of having just one on the
chips I was using.  Other that having more available memory, it looks
to be the same form a programming perspective.  Maybe I should look at
the rest of the line a little more closely... :)

Thanks.
--Danny

2005\11\09@124236 by Andre Abelian

flavicon
face
Danny,

It is important to mention that you are not  familiar with pic line that
way we can explain more instead of saying use CCP.

Andre


Danny Sauer wrote:

{Quote hidden}

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