PIC : how to make multiple non-blocking delays with one timer

[Bob Monsen]

Hi,

I had many requests about pic timers, so that I wrote a little C example to
show how to make multiple non-blocking asynchronous delays with only one pic
timer :

http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

Comments & questions are welcome

Bruno

One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

--
Regards,
Bob Monsen

Insanity: doing the same thing over and over again and expecting
different results.
Albert Einstein, (attributed)

 

[Deefoo]

The fact is, writing program examples leads to make choices between their
clarity and effectiveness, and too much novelties in the same program may
muddle the user with a heavier source code.

Ah, how I agree with you. Did you ever look at an MFC example? You want to
know how to use printf and they point you to a huge MDI OLE database
application with streaming multimedia internet connectivity and what not.

--DF

 

[BrunoG]

On Sun, 05 Mar 2006 11:30:56 +0100, BrunoG wrote:


One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

Yes you are right, usual restrictions about timings & data within ISR
should be applied by user.

As you suggest, the user's function called by the interrupt may just set
a flag. The user will have to check it and reset it in the main loop.
With minor changes, the ISR can do it itself, instead of calling the
user's function.

Bruno
http://www.micro-examples.com/public/microex-navig/doc/099-timers-delays.html

 

[nospam]

Good cbarn you are right, this time I do agree with you.

This is the same with only 7 lines :

http://www.micro-examples.com/public/microex-navig/doc/ultra-optimization.html

Please. Stop digging a bigger hole for your self. There is a reason you
have not had a single positive comment about the example you posted.

 

[Ian Bell]

One thing I don't like about this is that the callback happens at
interrupt level. This will force the callback user to lock his data
structures, and possibly cause interrupt latency problems if the 'user'
isn't careful about how long he keeps control in that callback.

PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

Absolutely right. What Bruno has done is to combine the scheduler and
despatcher into a single ISR. It would make better use of resources and
make the system more responsive if only the scheduler were in the ISR.

Ian

 

[Silvester]

This is something I would like to build.
It will not be a timer, it will count objects passing a point.

I have several chips on order: 7447, 7448, 74192, etc...
I'm looking for something I can work up on a bread board and then
possibly put on a small project PC board from Radio Shack.

It will eventually go into a paintball marker that has been built to
look like the Pulse Rifle from Aliens.

 

[Jim Thompson]

This is something I would like to build.
It will not be a timer, it will count objects passing a point.

I have several chips on order: 7447, 7448, 74192, etc...
I'm looking for something I can work up on a bread board and then
possibly put on a small project PC board from Radio Shack.

It will eventually go into a paintball marker that has been built to
look like the Pulse Rifle from Aliens.

First off, join the 21st Century and use 'HC parts ;-)

...Jim Thompson

 

[Ken Smith]

First off, join the 21st Century and use 'HC parts ;-)

At the suggested speeds, the CD4000 series would be a better option. You
don't need to worry as much about the voltage regulation.

 

[Silvester]

Thanks, but I need a display.
Preferably 3 digits using 7-segment LEDs.

I have a schematic from an OLD Radio Shack book that uses a 555 to
drive a 7490 that dumps into either a 7447 or 7448 and then into a
7-segment LED. I'd like to get THIS to count down and it would be great
if I could get it to use DIP switches to preset a number using binary.

I'm going to use an IR LED emitter and receiver to count objects
passing a point (piantballs leaving the barrel or hopper).

 

[Ken Smith]

PIC programs are nearly always busy loops, which check for timers or
port changes, and do something in response. Having an interrupt that ticks
away the timers, and sets a bit for the busy loop to check makes more
sense, and is easier to use in a broad range of projects. You can
supply an API to check the bit, or just document the bitmap, which can
then be used as a quick way to test whether any timer has expired.

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

 

[Silvester]

First off, join the 21st Century and use 'HC parts ;-)

At the suggested speeds, the CD4000 series would be a better option. >You don't need to worry as much about the voltage regulation.

What ever it takes...
I just need a schematic.

Really, I'm not looking to count more than 15 objects per second...

 

[Ken Smith]

Thanks, but I need a display.
Preferably 3 digits using 7-segment LEDs.

I have a schematic from an OLD Radio Shack book that uses a 555 to
drive a 7490 that dumps into either a 7447 or 7448 and then into a
7-segment LED. I'd like to get THIS to count down and it would be great
if I could get it to use DIP switches to preset a number using binary.

I'm going to use an IR LED emitter and receiver to count objects
passing a point (piantballs leaving the barrel or hopper).

Check out the 74HC192. It may be the right part for you.

 

[Ken Smith]

What ever it takes...
I just need a schematic.

Really, I'm not looking to count more than 15 objects per second...

Do you want the up-down feature too at this time?

It makes a difference in what I'd suggest.

 

[Silvester]

Counting down is more inportant than presetting the max count.

 

[Bob Monsen]

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

I don't know about the larger PICs, but for the 12 and 16 series, the call
stack is in hardware, and is not accessible to the programmer (it is also
limited to 8 calls, and wraps. Sigh...).

--
Regards,
Bob Monsen

If my theory of relativity proves to be correct, Germany will claim me
a German, and France will claim me a citizen of the world. However, if
it proves wrong, France will say I¡Çm a German, and Germany will say
that I¡Çm a jew.
Albert Einstein (1879 - 1955)

 

[Roger Hamlett]

I don't know about the larger PICs, but for the 12 and 16 series, the
call
stack is in hardware, and is not accessible to the programmer (it is
also
limited to 8 calls, and wraps. Sigh...).

The 18 chips, have larger stacks. Typically perhaps 20 deep (still not
large to handle anything other than call/return operations). You can also
access the 'top of stack' value, and the stack pointer. This allows you to
write a software stack, to extend the existing stack if required. However
it takes several instructions to access a single value (typically three
read or write operations on the larger chips - the stack is 21 bits wide
on these), then the I/O to the pointer.

Best Wishes

 

[BrunoG]

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

Yes, push and pop instructions do not exist on pic MCUs, they have to
be made by software.
Otherwise, cheating with stack return values is a good assembler trick,
but it would be risky to use it with a high-level language as C because
low-level registers are controlled by compiler.

Bruno

 

[Ken Smith]

Yes, push and pop instructions do not exist on pic MCUs, they have to
be made by software.
Otherwise, cheating with stack return values is a good assembler trick,
but it would be risky to use it with a high-level language as C because
low-level registers are controlled by compiler.

Some of the 8051 C compilers have special "not really C" stuff added to
them to make such stuff safe to do. They usually appear as some sort of
magic variable.

 

[Jasen Betts]

["Followup-To:" header set to sci.electronics.misc.]

I assume that on a PIC, you can't push a value onto the stack so as to
force the non-interrupt level to call the desired routine. If this is
true then using the busy loop idea is a good one. Without it, your timed
routines will be harder to code.

thatr method has disadvantages too, what if the routine that's being called
should be uninterruptable?

Bye.
Jasen