SX Interrupts

Rsadeika

Since their have been some mention of interrupts, for my own edification I would like to pursue this topic.

In the manual it states, the SX20/28 allows for up to nine sources of interrupts. This is pretty straight forward, Port B accounts for eight external, and there is one internal. The SX48/52 allows for up to seventeen sources of interrupts, Port B, one internal, the usual suspects. That is nine of the sources, you also now get one Wakeup, brings it up to ten of the sources. The confussing part, the other·seven sources.

The manual also goes on to state, ... six different internal interrupts can be configured for the Timers. So, am I to understand that, I am no longer restricted to one internal interrupt, and how do I explain or account for the Timers and/or the new interrupts as part of the ballance of sources of interrupts.

I guess maybe a brief explanation of this would be appreciated. I have more.

Thanks

Ray

Paul Baker

The timers are a more versatile timer than the RTCC, like the RTCC they have the ability to be clocked off the internal clock, or an external pin. Unlike the RTCC they have a capture input (for PULSIN type operations) and have a output pin (for PULSOUT/PWM type operations), they also have a compare mode register so the range of values traversed can be scaled accordingly. Read Chapter 8 of the User Manual for a full discussion, it may take a few read-throughs but it will eventually start to sink in.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Guenther Daubach

Let me place a general comment about SX interrupts here:

No matter, how many interrupt sources are available in the "small" and "large" SXes - there is always only one interrupt level, i.e. whatever source fires an interrupt, program execution will always branch to address $000 in page 0. So, the SX does not have any "vectored" interrupts as can be found in other controllers where different sources of interrupts cause the program execution branch to different locations in program memory.

This makes is a bit more tricky to handle multiple interrupt sources in one application with the SX, as the ISR code needs to figure out the interrupt source at the very beginning, and then branch to the associated interrupt handlers.

Furthermore, the SX can only handle one interrupt level, i.e. as soon as one interrupt has been fired, no matter from what source, further interrupts are disabled until a RETI or RETIW instruction is executed. So, when another event occurs that should trigger an interrupt while the ISR code is executed, this one might be missed, or its detection will be delayed until the execution returns from handling the recent interrupt.

Although it is possible to handle multiple interrupt sources with the SX within one application, I suggest that you begin with handling just one of the possible interrupt sources when you are new to this topic.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Rsadeika

Yes, I was thinking along those lines, the SX has only one "Interrupt" that starts at org $000. I got overly excited when I saw the description for the SX48/52, in terms of internal interrupts. I thought this was alluding to some hidden feature in the SX48/52.

Just to make sure I have the basic concept down,
ASM
Interrupt

···· RETI

SX/B
INTERRUPT

·· RETURNINT

when initiated by the correct option call, in this particular case, their is an interrupt that occurs on roll over, which happens to be 256 cycles. So, the code inside the interrupt, which has its own cycle count, meaning the commands that are used get run, goes back to the main code, where it left off, and then 256 cyles later, interrupt occurs, forever if you wish.

Now, we can shorten the RTCC time by adding
ASM
· mov W,#-50
·
· RETIW

SX/B

· RETURNINT (50)·· ;interrupt occurs every 50 cycles?
So, what basically occurs is that instaed of having to wait for the default time of 256 cycles, you now only have to wait, your new designated value,·cycles. In affect you now have a means of controlling how quickly the interrupt will occur. From a programming stand point, your main code execution gets controlled by your occurences, or cycle time·of the interrupt. I was trying to think of a condition when you would want your main code execution being interrupted every, lets say 5 cycles. But then I thought of Peter's (pjv) RTOS.

The concept I am still having some difficulty with is mov W,#-50, in the manual it states that now the interrupt will occur every 50 cycles. Some where else I read that by using a negative (-), you are really reducing the 256 value by the designated negative amount. So in essence by using a -50 you are really reducing the 256 count down to 206, and that would be 206 cycle instead of a 50 cycle. Or is it -50 is 50 cycles into the new roll over time. If this is the case then why shouldn't I just keep everything straight, and just use mov W,#50, that is the same result isn't it.

Thanks

Ray


·

Bean

Ray,
W is added to the RTCC so by adding -50 you are really reducing RTCC by 50 which means it will overflow again in 50 cycles.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

"Ability may get you to the top, but it takes character to keep you there."
·

Rsadeika

Now, I think I am getting pretty close to where I want to be on this. At first glance the RTCC business being at 256 cycles does not give you much room to play with, so that is why they gave you the pre-scaler. I think I got that one figured out, if you want to reduce the activation of the interrupt, you use a pre-scaler. The default is 256 cycles, when you use a pre-scaller of 1:2 = (2 * 256), 1:256 = (256 * 256), so, at the top end you have 65,536 cycles until the next interrupt occurs, generally spaeking.

The following statement is what I am having some trouble with. "Normally it is a requirement for the user program to process every interrupt without missing any. To ensure this, the longest path through the interrupt routine must take less time than the shortest possible delay between interrupts." Anybody care to elaborate on this, which leads into something that was mentioned about creating a coded interrupt that with the incorect cycle times can cause a situation where the program never leaves the interrupt. That could create a debug nightmare.

Anybody have a rule of thumb about how to pick a spicific interrupt rate, or do you just sit down and work out the numbers for each condition.

Thanks

Ray

Bean

Ray,
· If you want an interrupt to occur every 100 cycles, of course the interrupt routine will have to be less than 100 cycles.

Here is what happens:
· Your main program is merrily going about it's business, RTCC is increamenting with each clock cycle.

· All of a sudden RTCC rolls-over (from 255 to 0), the interrupt is started (I think there is a 3 cycle delay until·the first interrupt instruction is executed).

· Now RTCC is STILL merrily increamenting while we are in the interrupt routine.

· Let's suppose that the interrupt routine took 40 cycles(including overhead), so RTCC would be 40.

· Now if RTCC was not adjusted the next interrupt would be 216 cycles later, but we are going to use RETURNINT 100

· That means that RTCC is is going to be 40-100 or 40 + 156 = 196 so the next interrupt will occur 60 cycles later.

· You see how the time spend inside the interrupt routine is accounted for.

· The interrupt routine can take different number of cycles, but it will always be called every 100 cycles no matter what.

I hope I didn't confuse you any more...
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95

http://www.parallax.com/detail.asp?product_id=30012

"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015

Product web site: www.sxvm.com

"Ability may get you to the top, but it takes character to keep you there."


Post Edited (Bean (Hitt Consulting)) : 1/10/2006 11:50:15 PM GMT

Amit

Guenther, you seemed to suggest that there are good ways of doing vectored interrupts with the SX.· I poked around online for a while and found some resources about holding the interrupt in a flip-flop and then using the processor to clear the flop after it has determined the source.· I've also read about shifting the pin status into a register and examining the register to determine the source.· From my understanding the second method works only if the interrupt trigger lasts for a few clock cycles whereas the first allows for short interrupts as well as simultaneous interrupts.· If a second one comes while still executing the first, then that info is held in the flop.· Do you have any preferred method for dealing with multiple sources?· Thanks!

-Amit

CarlC

When an interrupt is called a flag is set in the WKPND register which indicates which pin caused the interrupt condition (external). I'm not sure how an RTCC interrupt is indicated. Perhaps you can check the RTCC count to see if it was the cause of an interrupt at the beginning of your ISR.

If you change mode to allow WKPND acces:

mov m,#09
mov w,#$FF
mov !rb,w

The value FF is loaded into !rb which keeps interrupts disabled and puts the original value of the WKPND reg into W which you can use to direct your interrupt response based on which pin caused the interrupt.

While in the ISR, you cannot service another interrupt request because interrupts are not re enabled until you clear the WKPND reg. If you clear it early in your ISR, you risk triggering the ISR before it's completed and obliterating important register values from the prior interrupted ISR.

That's as far as I've gotten so far anyways.

Paul Baker

Amit, Guenther discloses handling multiple ISR sources on page 129 in his book "Programming the SX Microcontroller: A Complete Guide", its an excellent reference for assembly on the SX. It's why I always suggest getting the SX Tech Tool PLUS instead of the LITE version.


You can look through the source code for his book to see if there is a code sample of how its done: http://www.parallax.com/dl/src/prod/sx/ProgSXEdPre.zip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Peter Verkaik

I have put a template in the attachement (for sx28).
Could someone extend this for a SX48? Or post a sx48 template for interrupts.
As I understand the Sx48, 7 more interrupts could be generated.
Also, the sx48 timers can be incremented on rtcc pin input.
Is it possible to have normal rtcc rollover interrupt AND external
pin interrupt using SX48 timers?

regards peter

Rsadeika

Peter,

The template looks pretty good, but I have some questions. Am I to assume that the 'template' should be used strictly for monitoring the B port. Also, maybe a brief explanation of the folowing - mov·w,#(-int_period)&255·;adjust rtcc properly. For me this is kind of new, what does this do.

Did you give up on the other code, Peter's RTOS modification? I was kind of hoping to see some code that allows you to run "time critical" things like UART,and I2C while being able to also run seven levels of non time critical code in an interrupt. While you are at it could you make it re-entrant. LOL

Serously, I think you were onto something with the other idea. It would be really neat if you could combine Peter's RTOS idea with your idea of time critical events.

Thanks

Ray

Peter Verkaik

The template should illustrate how to handle multiple interrupts.
The retiw makes sure there is a rtcc interrupt every N cycles (N=217 in the template).
PortB interrupts may appear anytime, even together with rtcc interrupt. The portB
interrupts are accumulated so it is possible to postpone portB handling (to other
isr runs or mainlevel code). The portB interrupts are asynchronous and therefore
placed after handling the rtcc interrupt.
I have not given up on pjv's RTOS, but my intend is to have only a single preemptive
thread that is treated as if it were the interrupt routine (it looks that way from
the mainloop code) so it will complete before returning to the mainloop code and
there is no context to save upon return from that routine.
I now want to know how SX48 interrupts can be added to the rtcc interrupt and
portB interrupts and when these extra interrupts must be handled (after portB or before?)
When I get all the pieces I will make the several interrupts sources conditional.

regards peter

Yendor

I'm running out of 'cycle' space in my interrupt on the SX28.· (RTCC Overflow, by about 16 clocks w/ NOPRESERVE according to SX/SIM).

Other than increasing Frequency, adjusting the cycles and trying to optimize code,·can I use an SX48 w/ the software timers to act as RTCC of 1024 instead of 255 to gain·more·interrupt 'cycle' space (just a tad more?)

Using the prescaler won't work right, as it 'reduces' the code space the interrupt can support, effectivly slowing it down, right??

So, the maximum to maintain a Midi Baud rate (31250) be:

• 50MHz 4us = 200 Cycles of code (+ overhead) Rate = 250000
• 50MHz 4us = 100 Cycles of code (+ overhead) Rate = 250000 w/ RTCC of 2
• 20MHz 2us = 160 Cycles of code (+ overhead) Rate = 125000

Anything else would requre RTCC to be > 255.

Thanks!

Rodney