Disable edge detect interrupt situation...
dkemppai
Posts: 315
Hi all,
Hypothetical situation.
On an SX-28 can you disable interrupts on an input pin (port when you have a high frequency (1/2 or 1/3 Clock) signal on the input that has edge detect interrupts enabled? (The Mode register is not restored on the SX28 on RETI)
Example, let's say you enable interrupts on a pin that has a 1/3 clock frequency·signal on it and you try to disable the interrupts on this pin. To disable the interrupts, you need to set the mode register, and then move the new WKEN_D value to the register. The only problem is that interrupts occur between setting the mode register and moving the value to WKEN_D.
What is the highest frequency signal (asynchronous to SX clock, with SX Clock = 50Mhz) that you can have on a pin and still be able to disable interrupts on port b?
Brain teaser that crossed my mind last night!
-Dan
·
Hypothetical situation.
On an SX-28 can you disable interrupts on an input pin (port when you have a high frequency (1/2 or 1/3 Clock) signal on the input that has edge detect interrupts enabled? (The Mode register is not restored on the SX28 on RETI)
Example, let's say you enable interrupts on a pin that has a 1/3 clock frequency·signal on it and you try to disable the interrupts on this pin. To disable the interrupts, you need to set the mode register, and then move the new WKEN_D value to the register. The only problem is that interrupts occur between setting the mode register and moving the value to WKEN_D.
What is the highest frequency signal (asynchronous to SX clock, with SX Clock = 50Mhz) that you can have on a pin and still be able to disable interrupts on port b?
Brain teaser that crossed my mind last night!
-Dan
·
Comments
Actually, the SX disables interrupts itself on detection of a change-on-b.
I suspect you may be interested in how fast the interrupt may be re-enabled, no?
Also, can you clarify what you really mean by 1/3 clock; is it 3 times the clock frequency, or one third of the clock frequency?
Cheers,
Peter (pjv)
Nope,
I want to know how long it will take for me to turn off interrupts one a port B pin,
without entering the interrupt routine.
This is a case where you don't want the interrupt to run when in main line code.
As an example, Imagine a situation where you have an interrupt firing on an input
reading data from a RF receiver. There may be cases when the reciever looses RF
signal, and AGC takes over amplifying noise. With a wide enough noise bandwidth
you will get interrupts too fast to deal with them. In this case you want to shut the
interrupts off, so the rest of the processing can be done. (Just an example)
I ran into a similar situation, where an oscillation caused interrupts so often, that
no other processing could be done. The oscillation was high enough in frequency
that only one or two clocks happened before the interrupt was fired again. Those
clocks weren't enough to disable the interrupts, and not other code could be run.
(I fixed that problem, but it got me thinking!)
This only happens in the SX28, because the mode register is not restored on return
from an interrupt.
I think you need 3 cycles minimum to turn off·interrupts.
MODE·$0B
MOV·!rb,#%11111111
Am in incorrect...
-Dan
·
you might consider to save and restore the MODE register within the ISR on an SX28 "manually", i.e. save MODE to some temporary register before the ISR changes it, and restore it before doing the RETI/RETIW. You might also consider to turn off port B interrupts within the ISR when "noise scenarios" occur like you have described. As long as you are inside the ISR, interrupts are disabled, so it does not matter how long it takes to turn off the port B interrupts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
You are absolutely correct; in the case cited, it takes 3 cycles to disable the interrupts.
If you were able to leave the MODE register in the $0B state, then of course it is reduced by one.
Personally, I rearely use the interrupt-on-b feature, as I find it is generally insufficiently deterministic for my needs. My preference is to run an RTCC ISR at a high speed, and do everything on a very steady basis. Of course, if there is a lot to do, or if legitimate inputs may happen very rapidly, this technique may not be optimum.
Cheers,
Peter (pjv)