Based on the "time-base interrupt" technique outlined by Stewart in this thread
http://forum.microchip.com/tm.asp?m=59908&...pt&anchor#60348
I've wrote some code for the 16F877, controlling eight LEDs, which I made complex enough to see how far I could go:
LED 0 blinks once with a certain ON time
LED 1 same as above with a different ON time
LED 2 blinks for a certain number of times with equal ON-OFF periods
LED 3 blinks for a certain number of times with different ON-OFF periods
LED 4 blinks for a certain number of times with equal ON-OFF periods
LED 5 blinks continuously with equal ON-OFF periods
LED 6 blinks continously with different ON-OFF periods
LED 7 blinks continuously with equal ON-OFF periods
The main loop consists of nine tasks continuously CALLed: one for the keyboard and one for each LED. Each LED is activated by pressing a different key in the keyboard. Time base is 2 msec and on/off periods range from 250 msec to 1500 msec.
Basically I can say that it worked from the first try demonstrating his point. Later, after experimenting for a while I've started to wonder about the following points:
1) A keyboard debouncing delay (I use 25 msec) requires just one 8-bit counter to be decremented while a 1500 msec delay demands three 8-bit counters. How to cope with VERY LONG delays and a VERY SMALL time-base? I asume here, that I also need VERY SHORT delays what precludes the use of a LONG time base.
2) With many of the delays requiring two or three (BTW, why not four or five?) 8-bit counters each, I've found that the time spent by the ISR just in checking and decrementing counters, could ammount up to one tenth of the time base period.
Isn't that excessive?
What if I have many other tasks to serve?
Is it any simple trick to reduce the number of counters?
3) With only TMR0 interrupt enabled, it's an event that repeats after an exact amount of time. The LEDs' blinking periods, since they affect each other, are essentially not exact. I assume then than whatever other event I want to occurr at an exact moment, could not! Let's say that if I want a pin going high exactly 6 msec every 25 msec what I could only get is just ABOUT that.
Should I consider that "exact" periods of wahtever, should be in fact, just periods "within a certain tolerance"?
4) What if other interrupts are enabled?. Being unable to assign any priority to TMR0 interrupt (16F877) the 2 msec time base would become not an exact occurrence anymore!
5) I run across an unforeseen difficulty: all LEDs required two flags: one showing the LED is "active" or "inactive"; another telling if it is ON or OFF. Probably due to lack of experience I found the handling of those flags somewhat complicate, cumbersome and hard to debug.
I couldn't follow Stewart's pseudo code very well regarding flags. I work in assembler so whatever comes from C language is hard for me to understand. Sorry about that![&:]
Comments of any kind are much appreciated. If at all possible please follow the order of the points as stated above. That would help me in understanding this new subject. Thanks also for that.
Agustín Tomás
http://forum.microchip.com/tm.asp?m=59908&...pt&anchor#60348
I've wrote some code for the 16F877, controlling eight LEDs, which I made complex enough to see how far I could go:
LED 0 blinks once with a certain ON time
LED 1 same as above with a different ON time
LED 2 blinks for a certain number of times with equal ON-OFF periods
LED 3 blinks for a certain number of times with different ON-OFF periods
LED 4 blinks for a certain number of times with equal ON-OFF periods
LED 5 blinks continuously with equal ON-OFF periods
LED 6 blinks continously with different ON-OFF periods
LED 7 blinks continuously with equal ON-OFF periods
The main loop consists of nine tasks continuously CALLed: one for the keyboard and one for each LED. Each LED is activated by pressing a different key in the keyboard. Time base is 2 msec and on/off periods range from 250 msec to 1500 msec.
Basically I can say that it worked from the first try demonstrating his point. Later, after experimenting for a while I've started to wonder about the following points:
1) A keyboard debouncing delay (I use 25 msec) requires just one 8-bit counter to be decremented while a 1500 msec delay demands three 8-bit counters. How to cope with VERY LONG delays and a VERY SMALL time-base? I asume here, that I also need VERY SHORT delays what precludes the use of a LONG time base.
2) With many of the delays requiring two or three (BTW, why not four or five?) 8-bit counters each, I've found that the time spent by the ISR just in checking and decrementing counters, could ammount up to one tenth of the time base period.
Isn't that excessive?
What if I have many other tasks to serve?
Is it any simple trick to reduce the number of counters?
3) With only TMR0 interrupt enabled, it's an event that repeats after an exact amount of time. The LEDs' blinking periods, since they affect each other, are essentially not exact. I assume then than whatever other event I want to occurr at an exact moment, could not! Let's say that if I want a pin going high exactly 6 msec every 25 msec what I could only get is just ABOUT that.
Should I consider that "exact" periods of wahtever, should be in fact, just periods "within a certain tolerance"?
4) What if other interrupts are enabled?. Being unable to assign any priority to TMR0 interrupt (16F877) the 2 msec time base would become not an exact occurrence anymore!
5) I run across an unforeseen difficulty: all LEDs required two flags: one showing the LED is "active" or "inactive"; another telling if it is ON or OFF. Probably due to lack of experience I found the handling of those flags somewhat complicate, cumbersome and hard to debug.
I couldn't follow Stewart's pseudo code very well regarding flags. I work in assembler so whatever comes from C language is hard for me to understand. Sorry about that![&:]
Comments of any kind are much appreciated. If at all possible please follow the order of the points as stated above. That would help me in understanding this new subject. Thanks also for that.
Agustín Tomás
