Interrupts: How to count timing in SX/B
I'm using a single wire serial connection to send data to an LCD. I also am using an interrupt to count down a timer. Of course, the interrupt for the timer is interferring with the serial info going to the LCD.
I believe I have to count the clock cycles for each instruction and each possible path through the interrupt. They all need to spend the same amount of time in the interrupt. Then, I need to adjust the timing of the next interrupt and take into account the time spent in the interrupt.
But, how exactly do I find out how long the interrupt takes? I have Gunther's book and he explains it well, but it is for using assembly, not SX/B. Do I need to look at the assembly breakdown of the SX/B and then add it all up?
Help me Obi-Wan....
Dan
I believe I have to count the clock cycles for each instruction and each possible path through the interrupt. They all need to spend the same amount of time in the interrupt. Then, I need to adjust the timing of the next interrupt and take into account the time spent in the interrupt.
But, how exactly do I find out how long the interrupt takes? I have Gunther's book and he explains it well, but it is for using assembly, not SX/B. Do I need to look at the assembly breakdown of the SX/B and then add it all up?
Help me Obi-Wan....
Dan
Comments
The easist way to handle this is to set a flag in the interrupt routine.
Make a subroutine to send 1 serial byte. In the subroutine clear the flag, then wait for the interrupt to set it. Then send the serial byte.
The idea is that since we know the interrupt just ended, another won't happen for awhile so we can send 1 byte with getting interrupted.
To make this work you want your serial rate as high as possible, and your interrupt rate as low as possible.
1 byte @ 9600 takes about 1 millisecond.
To find out how many cycles your interrupt routine uses, use SX-Sim it tells you the Min, Max, and Average ISR cycles.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?
www.iElectronicDesigns.com
·
Bean: Great idea Bean! I currently have the interrupt set for 100 times per second, so the serial should be faster than the next interrupt.
Thanks again Bean, I really appreciate your help,
Dan
Why not just interrupt every second and update the display while in the interrupt?
Just a thought,
Gary
JonnyMac: I ran across an article you wrote for N&V that is similar to your suggestion. I'll read through that again and see if I can figure it all out.
Since the entire program would need to use the interrupt to send text to the LCD, should I create a SUB, then put the text I want to send into a buffer and set a flag? Have the ISR check the flag to see if there is text to print, then send the contents of the buffer?
Trying to understand how the interrupt driven serial would know that I have text to send out, and where that text needs to be so the ISR could use it.
Thanks again for your help,
Dan
· You can't interrupt every second because the interrupt rate minimum is (clock / 65536).
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?
www.iElectronicDesigns.com
·
Bean is correct in that one cannot go into the ISR once per second using a crystal or resonator of 4 MHz. As he pointed out, the minimum time that one can go into the ISR is clock frequency/65_536. When using a 32.768 kHz or 65.536 kHz crystal, one can obtain an interrupt of once per second. If you use these slower clock rates, can your specific LCD system operate at lower baud rates.
Gary
[noparse][[/noparse]post edited to correct 'ISR once per minute' to 'ISR once per second']
Post Edited (Sens-a-Dat) : 6/16/2008 11:08:30 AM GMT
Does this sound like it will work? I'm going to give it a try here in the next hour or so.
Dan
Post Edited (DosManDan) : 6/16/2008 4:30:50 AM GMT