Maker Pro
Maker Pro

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

BrunoG said:
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

good grief 1600+ bytes for 2 little delays! if i'de written that I
wouldn't ever publish it. You should be able to get the guts of this
down to 50 bytes at most maybe half that with some effort.
 
B

BrunoG

good grief 1600+ bytes for 2 little delays! if i'de written that I
wouldn't ever publish it. You should be able to get the guts of this
down to 50 bytes at most maybe half that with some effort.

Hi, thanks for having a look at it.

this code is intended for beginners, and shows the way to handle interrupts
with mikroC.
it surely won't help you if you are an experienced programmer.

by the way, I would be curious to see a 50 bytes program that will do the
same. So don't be shy and post your C code. it will have to do the same :

- user-configurable numbers of delays
- user-configurable pointers to end of countdown function
- user-configurable delays in ms for each countdown
- non-blocking delays
- asynchronous delays
- only one timer used

Bruno
 
I

Ian Bell

BrunoG said:
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

2K of code is a bit of an overkill. I have done created a complete time
triggered prioritised cooperative scheduler on the 8051 in less than 200
bytes. Code can be found here:

http://www.8052.com/users/redtommo/ttcs.html

an
 
BrunoG said:
Hi, thanks for having a look at it.

this code is intended for beginners, and shows the way to handle interrupts
with mikroC.

It shows how to way to handle an interrupt.
it surely won't help you if you are an experienced programmer
agreed

..

by the way, I would be curious to see a 50 bytes program that will do the
same. So don't be shy and post your C code. it will have to do the same :

In the ISR all you need is

dec time1lowbyte
if zero set time1flag
dec time2low byte
if zero set time2flag

thats about 6 instructions

In your main idle loop ie. where your for{;;} is

test time1flag
if set clr time1flag dec time1high byte
if zero do whatevertime1

test time2flag
if zero clr time2flag dec time2high byte
if zero do whatevertime2

thats about 8 instructions

All you have to remember is that when you load the time values the high
byte needs to be incremented by 1.
 
B

BrunoG

In the ISR all you need is

dec time1lowbyte
if zero set time1flag
dec time2low byte
if zero set time2flag

thats about 6 instructions

In your main idle loop ie. where your for{;;} is

test time1flag
if set clr time1flag dec time1high byte
if zero do whatevertime1

test time2flag
if zero clr time2flag dec time2high byte
if zero do whatevertime2

thats about 8 instructions

Ok that's enough, I can't push you to post a real code in a known language.
I think even beginners have now made their mind.

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

Ian Bell

maxfoo wrote:
snip
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
cough!!

Oh, shit! Bird Flu.

Ian
 
B

BrunoG

I dont have the spare time to write, compile and debug code just for
you. If you cant see how simple your code should have been then you
need to find another occupation.

Sure you will not have enough time, eternity will not be long enough to
rewrite this within 50 rom bytes.

This example is written for 2 delays, but it can handle up to 255 delays
with the same rom size (1690 bytes) just changing the #define directive. I
added a comment in the source code to notice it to beginners, thanks.

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

Frank Bemelman

BrunoG said:
Sure you will not have enough time, eternity will not be long enough to
rewrite this within 50 rom bytes.

This is probably what eats most of the 1676 bytes:

unsigned long d
d /= 1000 ; // divide by 1000 because
d /= (long)Clock_Khz() ; // clock frequency is known in Khz

And these lines only add a bit of convenience... would be nice
to see how many bytes you need without these lines.
 
B

BrunoG

Frank Bemelman said:
This is probably what eats most of the 1676 bytes:

unsigned long d
d /= 1000 ; // divide by 1000 because
d /= (long)Clock_Khz() ; // clock frequency is known in Khz

And these lines only add a bit of convenience... would be nice
to see how many bytes you need without these lines.

Yes sure, long div is costly, as well as struct members and arrays usage.
But the goal of this program is to show how to use interrupts, timers and
pointers in mikroC, not to have an optimization challenge.

A math trick to replace long type calculations would spare a few hundreds of
bytes, but the example would loose its clarity.

For those are interested by a high-level language optimization challenge
(basic or C) for pic microcontrolers, please see :
http://www.mikroe.com/forum/viewtopic.php?t=3363

Thanks
Bruno
http://www.micro-examples.com/public/microex-navig/doc/200-pic-microcontroller-examples.html
 
BrunoG said:
Sure you will not have enough time, eternity will not be long enough to
rewrite this within 50 rom bytes.

This example is written for 2 delays, but it can handle up to 255 delays
with the same rom size (1690 bytes) just changing the #define directive. I
added a comment in the source code to notice it to beginners, thanks.

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

I tell you what, you build me a website and i'll write some decent code
for yours.
 
F

Frank Bemelman

BrunoG said:
"Frank Bemelman" <[email protected]> a écrit dans le message de


Yes sure, long div is costly, as well as struct members and arrays usage.
But the goal of this program is to show how to use interrupts, timers and
pointers in mikroC, not to have an optimization challenge.

A math trick to replace long type calculations would spare a few hundreds of
bytes, but the example would loose its clarity.

For those are interested by a high-level language optimization challenge
(basic or C) for pic microcontrolers, please see :
http://www.mikroe.com/forum/viewtopic.php?t=3363

Thanks
Bruno
http://www.micro-examples.com/public/microex-navig/doc/200-pic-microcontroller-examples.html
 
F

Frank Bemelman

BrunoG said:
Yes sure, long div is costly, as well as struct members and arrays usage.
But the goal of this program is to show how to use interrupts, timers and
pointers in mikroC, not to have an optimization challenge.

A math trick to replace long type calculations would spare a few hundreds of
bytes, but the example would loose its clarity.

Indeed. As an example it fits its purpose, and even for a real
application it's okay to use, if speed/space is not an issue.
 
J

John Popelish

Anthony said:
If you liked that, you should see the mess that hardware experts make
when they try to write software. ;-)

Did that crack make you feel better about the difficulties you have
with hardware design?
 
A

Anthony Fremont

John Popelish said:
Did that crack make you feel better about the difficulties you have
with hardware design?

Given the commentary by cbarn24050 and maxfoo, I really don't consider
mine to qualify as a "crack". In fact, I think it to be quite
appropriate. At least I wasn't publicly ridiculing anyone.
 
Anthony said:
Given the commentary by cbarn24050 and maxfoo, I really don't consider
mine to qualify as a "crack". In fact, I think it to be quite
appropriate. At least I wasn't publicly ridiculing anyone.

I wasn't trying to humiliate anyone either, he asked for comments. The
fact is needing multiple delays in a program is very commonplace and
it's normaly done with a few lines. What the author produced, however
well meaning, was just terrible. Thats not a problem for most people,
they just delete it in a heartbeat but a real beginner doesn't know any
better. Iv'e shown him how to do it, if he did it again that way he
would see for himself but his pride has been hurt, that was never my
intention, and so he's gone on the defensive. Your right about hardware
engineers messing up software but then again so do software engineers.
 
A

Anthony Fremont

I wasn't trying to humiliate anyone either, he asked for comments. The
fact is needing multiple delays in a program is very commonplace and
it's normaly done with a few lines. What the author produced, however
well meaning, was just terrible. Thats not a problem for most people,

Honestly, I hadn't looked at it until now. Since he uses structs and a
long divide, I'm not real surprised on the space requirements.
Personally, I don't use C on a PIC since the hardware is not really up
for it without allot of hoop jumping by the compiler. The 18F type PICs
are more capable in this regard. So to each his own. I've used C on
8052's and I liked it, but it was a good compiler too (keil).
they just delete it in a heartbeat but a real beginner doesn't know any
better. Iv'e shown him how to do it, if he did it again that way he
would see for himself but his pride has been hurt, that was never my
intention, and so he's gone on the defensive. Your right about hardware
engineers messing up software but then again so do software engineers.

Everybody messes up software, 'cept me of course. ;-) I'm surprised
that John seemed to take offense to my comment. I really wasn't trying
to upset anyone, hence the smiley.

I would say that it's pretty selfless of Bruno to maintain a web site
for the benefit of others.
 
Top