Hi , people,
I have keyboard scaning sequence inside TimerB interrupt.
This sequence is relative slow, so its possible to lose bit/symbol
in software UART ( tied to TimerA). My intention is to make follow:

TimerB_ISR:
push r15
;...

mov #keybard_scanproc,r15
push r15
push SR
reti

keybard_scanproc:
;.....
pop r15
pop SR
ret

Is this correct way?
regards

Start a New Thread

What you did is correct. But there are simpler ways to do it. For
example, you could have just include the keyboard scaning as part of
the timer isr. This saves execution time to do the pushes, pops and
extra return. (The code is shorter.)

--- In m..., "stefandk63" wrote:
>
> Hi , people,
> I have keyboard scaning sequence inside TimerB interrupt.
> This sequence is relative slow, so its possible to lose bit/symbol
> in software UART ( tied to TimerA). My intention is to make follow:
>
> TimerB_ISR:
> push r15
> ;...
>
> mov #keybard_scanproc,r15
> push r15
> push SR
> reti
>
> keybard_scanproc:
> ;.....
> pop r15
> pop SR
> ret
>
> Is this correct way?
> regards
>

Start a New Thread

There is one statement below that worries me. Interrupts are more
difficult to debug and "interrupt" the normal flow of the program. It
has always been my view that interrupts should only do the absolute
minimum needed. Usually this is setting a flag, moving the contents of
a register, or incrementing a pointer. Something simple. No math
allowed, nothing that consumes time. This isn't always possible but if
your code forces you to reenable interrupts while in the ISR then
perhaps you should take a step back and evaluate how you are doing what
you are doing. There is likely a simpler more predictable way to do it.
The line I have trouble with is

This sequence is relative slow

This tells me that this does not belong in an interrupt.

Dan

________________________________

From: m... [mailto:m...] On Behalf
Of old_cow_yellow
Sent: Wednesday, September 03, 2008 9:10 AM
To: m...
Subject: [msp430] Re: interrupt priority "overrride"

What you did is correct. But there are simpler ways to do it. For
example, you could have just include the keyboard scaning as part of
the timer isr. This saves execution time to do the pushes, pops and
extra return. (The code is shorter.)

--- In m... ,
"stefandk63" wrote:
>
> Hi , people,
> I have keyboard scaning sequence inside TimerB interrupt.
> This sequence is relative slow, so its possible to lose bit/symbol
> in software UART ( tied to TimerA). My intention is to make follow:
>
> TimerB_ISR:
> push r15
> ;...
>
> mov #keybard_scanproc,r15
> push r15
> push SR
> reti
>
> keybard_scanproc:
> ;.....
> pop r15
> pop SR
> ret
>
> Is this correct way?
> regards
>


Start a New Thread

Stefan,

I agree with OCY and Dan and their architectural comments about this
program. I think from what you've said that this is a perfect example
of a program that needs to be written using an interrupt-driven state
machine. We discuss this approach in detail in our book MSP430 State
Machine Programming, available on amazon.com:

http://www.amazon.com/gp/redirect.html?ie=UTF8&location=http%3A%2F%
2Fwww.amazon.com%2FMSP430-State-Machine-Programming-ES2274%2Fdp%
2F0975475924%3Fie%3DUTF8%26s%3Dbooks%26qid%3D1214397954%26sr%3D8-
1&tag=softcom-20&linkCode=ur2&camp89&creative25

This book is written for our ES2274 board, but the approach given is
suitable for any MSP430 board with suitable porting of the examples, of
course.

Tom
Start a New Thread