Is a timer delay accomplished with an interupt?

[ShortBus]

I'm a hobbyist trying to teach myself PBP by experimenting. My current project is replacing the lights in my 1973 Honda motorcycle with LEDs. When the brake light is activated, I'd like for the LEDs to pulse several times, with progressively longer intervals (100ms, 200ms, 300ms, etc) and then stay on until the brake is released. Many modern bikes do this as a deceleration warning to help avoid getting rear-ended.

In PBP, I basically run a continuous loop until a pin is high and then do a GOSUB to execute the flash loop, which takes about 2.5 seconds to complete. What I'd like to do is add some sort of timer to prevent the flash routine from executing more than once every 5-10 seconds. If I'm slowing down for a turn, I might depress and release the brake a few times. The flash loop should be executed only the first time I depressed the brake; subsequent activations should just keep the pin high until the brake is released. After x seconds, the next activation causes the flash sequence again.

From my readings, it looks like I'll need to use an interrupt to time how longer it's been since the brake was last activated. But I can't wrap my head around how to use them. Could someone please provide me with an example? Thank you!

[Acetronics2]

Hi ShortBus,

I Hope your bike is not a CB 250/350 ... no emergency brake signal needed ... cause no break at all !!! LOL ...

But ... I'd bet for a CB 750 ...

Being serious ... no interrupt needed :

a fair solution could be to use a 32.768 Khz Xtal for clock ... and let TMR 1 ( 16 Bits ) run quietly ...

that permits to use 12F683 and 16F628 as "simple" Pics.

How to ???

By polling the TMR 1 Overflow bit !!! (TMR1IF)

Let's have TMR 1 running freely : an overflow will occur after the delay you want "not to re-arm the flashing sequence" ... let it run ...

Let's use the brakes :

Overflow bit is set : engage the flashing sequence, and when releasing brakes... quit the flashing sequence and reset TMR 1 and it's Overflow bit ...

re use the brakes :

- before "Timeout" : overflow bit is clear ... continuous lighting !

- after "Timeout" : overflow Bit is set ... engage the flashing sequence !!!

32.768 Khz Xtal ??? just will need you to correct the programmed times by x 122 if using the Std "DEFINE Osc 4"

( Programmed PAUSE 10 will give 1220 ms instead of 10 ms ... so, if needed, use Pauseus :
Pauseus 1000 will give 122 ms instead of 1 ms ... )

This is just not to twist your brain on how to create " 1 - 10 seconds" delays ...



Alain ... Genuine Kawasaki H1 rider ... ha,ha,ha !!!

[Jimbo]

Hi ShortBus,

I Hope your bike is not a CB 250/350 ... no emergency brake signal needed ... cause no break at all !!! LOL ...

But ... I'd bet for a CB 750 ...

Being serious ... no interrupt needed :

a fair solution could be to use a 32.768 Khz Xtal for clock ... and let TMR 1 ( 16 Bits ) run quietly ...

that permits to use 12F683 and 16F628 as "simple" Pics.

How to ???

By polling the TMR 1 Overflow bit !!! (TMR1IF)

Let's have TMR 1 running freely : an overflow will occur after the delay you want "not to re-arm the flashing sequence" ... let it run ...

Let's use the brakes :

Overflow bit is set : engage the flashing sequence, and when releasing brakes... quit the flashing sequence and reset TMR 1 and it's Overflow bit ...

re use the brakes :

- before "Timeout" : overflow bit is clear ... continuous lighting !

- after "Timeout" : overflow Bit is set ... engage the flashing sequence !!!

32.768 Khz Xtal ??? just will need you to correct the programmed times by x 122 if using the Std "DEFINE Osc 4"

( Programmed PAUSE 10 will give 1220 ms instead of 10 ms ... so, if needed, use Pauseus :
Pauseus 1000 will give 122 ms instead of 1 ms ... )

This is just not to twist your brain on how to create " 1 - 10 seconds" delays ...

Alain ... Genuine Kawasaki H1 rider ... ha,ha,ha !!!

- - - -

This is a very old thread, but I as a fellow rider I thought I should add
something important in case others want to make their own flashing
brake light.

The word of the day is "FAILSAFE" ... as in "when it fails, the
default condition is a safe condition".

A PIC & associated parts is a complicated device. It can crap out for
no obvious reason. The way the original poster was planning to use
the PIC called for it to power his brake light, introducing a 'pulsing'
effect before going solid on. This is a mistake and can cause a
garbage truck to go up his behind.

The FAILSAFE way ... or close as you can get ... is to make sure the
power from the brake switch ALWAYS goes DIRECTLY to the bulb/LEDs.

This calls for the introduction of a relay - mechanical or (better) solid-
state - into the design. Wire the 'hot wire from the brake switch through
the "NC" (normally closed) contacts of the relay and then straight to the
light. This means the default mode is that the light will always come
solid on when you press the pedal/brake-lever just like it was originally
designed to do.

The PICs job here isn't to power the light, but instead to power the RELAY.
The simplest approach is to suck power from the brakelight wire and use
that to power-up the PIC. Fewer running hours = less chance of failure.

The PICs program commands a pin attached to the relay coil. You could
use just a couple of "Pause()" statements between commands to toggle
that pin on and off to get the timing just the way you want.

The signal from the PIC energizes the relay, pulling the "NC" contacts open
thus breaking the circuit. The brake light goes out for as long as the relay
is energized.

The most likely scenerio if the PIC fails is that it will source no current. In
that case, using this design, the brakelight will come on solid and stay that
way as long as you've got the brakes engaged - just like the factory intended.
The PIC doesn't so much blink the lights as it "un-blinks" ... briefly interrupts
the normal flow of power to the light.

If you power it from the brake wire (the side BEFORE the relay) you don't
have to poll anything or do interrupts, the PIC will use it's power-up time
as a reference and count its 'unblink' sequence from that moment.

For added safety against the possible electrochemical effects of wet wires
on a solid-state relay, ground the "coil" lead through a 10K or 22K resistor
to ensure it's not activated by tiny stray currents. Mechanical relays are
not so sensitive, but the contacts can eventually burn out.

An alternative to a relay is an old-fashion bipolar NPN transistor (these
are tougher than CMOS varieties) - any of a dozen kinds will do, just
don't hesitate to pick one with a higher current capacity - a TO-220a
packaged kind will do nicely. Then tie the 'base' lead to the brake-wire
side with a 1/2-watt resistor ... 1K ought to work, 5K is better for
this app IF will work with your choosen transistor ... so that the
transistor automatically conducts when you hit the brakes.

The PICs job is to be also attached to the 'base' lead - but THIS
time to "suck away" the power being provided through that 5K
resistor. 12v / 1000 ohms = 0.012 amps ... which is within the
amp range most PIC pins can sink safely. When in doubt, add a
buffer amplifier between the PIC and the NPN 'relay' transistor.
Just make sure the "broken" condition of the buffer amp is to
draw NO power from the NPN transistors 'base' lead.

Frankly, you're better off with a small automotive or "rugged
service" grade of solid-state relay. It costs a bit more than
the transistor, but it's got some worthwhile safety features
hidden within.

Anyway, I hope everyone gets my point ... as your life may depend
on the brakelight working, do NOT trust a homebrew PIC to do the
job. Make sure the light will ALWAYS come on, then use the PIC to
force it to turn off for the "blink" effect.

-Jimbo (motorcycle #15 and counting)