Need help on SX Interrupts.

achidichi · 2013-05-24 07:51

Hi:

Reading the SX20/28 and SX48/52 datasheets I found some differences related with interrupts topic.

The SX20/28 datasheet talks about 'missing the interrupt trigger at MIWU port' if these port interrupts are not 'disabled' when entering the ISR.

On the other hand, the SX48/52 datasheet talks nothing about 'triggers', it just says that interrupts will be executing again and again as long as there are pending bits on the MIWU port. I guess this last explanation makes more sense than previous one on the SX20/28 docs.

So, are they really a little bit different? Please advice.

Mike Green · 2013-05-24 16:25

Sorry for moving, then re-moving your post. The topic belongs in the SX forum, but that forum doesn't allow postings, so I moved it back. Hopefully you'll get an answer soon to your question.

Publison · 2013-05-24 16:38

Mike Green wrote: »

Sorry for moving, then re-moving your post. The topic belongs in the SX forum, but that forum doesn't allow postings, so I moved it back. Hopefully you'll get an answer soon to your question.

Mike,

Has the SX forum been shut down?

If so. how did achidichi get a post in there, where I can not post a new thread?

wass · 2013-05-24 20:01

I'm not 100% certain but do not think that there is any difference in interrupt processing. In both chips you need to clear the interrupt pending bit in order to allow for a new interrupt to occur. You do not need to disable interrupts on the 20/28 when entering the ISR. If you have more than one possible source of interrupt you'll typically want to read (and clear at the same time) the pending interrupt register as soon as you enter the ISR
The WKPND_B register exists on both the 20/28 and 48/52, but the 48/52 also has timer interrupt bits that need to be read/reset if needed.

achidichi · 2013-05-25 05:55

I really appreciate your answer.

1) So, the SX48/52 datasheet is right? As long as there are pending bits the ISR will be called and execute?.

As I told before, despite this reasonable logic, the SX20/28 datasheet suggests that in spite of these enabled pending bits (by external edges) there could be no interrupt callings (triggers) if they were activated while WKEN_B was enabled inside the ISR. This just makes me crazy.... I copy & paste the text from the datasheet I refer to:

"If an external interrupt occurs during the interrupt routine, the pending register will be updated but the trigger will be ignored unless interrupts are disabled at the beginning of the interrupt routine and enabled again at the end. This also requires that the new interrupt does not occur before interrupts are disabled in the interrupt routine. If there is a possibility of additional interrupts occurring before they can be disabled, the device will miss those interrupt triggers."

2) I am afraid I could loose some interrupts. I have 2 external edge sources I want to process asynchronously. I cannot afford to miss one (both edge sources are unrelated).
I know I could use some other tools like an FPGA but I know this simple task is a piece of cake with microcontrollers, right? The time interval between 2 edges on the same pin is big. But as they are unrelated they can appear at the same time on both pins.

Please advice on 1) and 2).

LoopyByteloose · 2013-05-25 10:25

The documentation for the SX20,-28 versus the SX48-52 is indeed different on the subject of interrupts... and has never been all that clear.

The main diagrams are not 100% right either.

The simplest explaining is that there are more sources for interrupts available in the SX48/52, but there is only one ISR vector regardless.

To make matters more complicated, if you intend to use the Sleep and Wake up features, there is another layer of complexity.

I actually turned to similar PIC chips to find a better explanation of the interrupts and the WakeUp/Sleep feature. The two additional timers on the SX48-52 are the main source of additional interrupt triggers. It seems that more than one trigger might be able to be available at the same time, but that is a nightmarish scenario.

I've spent a lot of time in the past trying to comprehend this. May be too much time. It take a lot of reading and rereading to get a true image of what is going on. I think I've done so, but haven't bothered to put it in any form that can be shared with others.

Zoot · 2013-05-27 16:35

The documentation is specifically talking about what happens if a TRIGGERED interrupt occurs WHILE you are already "in" the ISR processing another triggered (or RTCC) interrupt, though you would not generally want both triggered and RTCC interrupts. And yes, it gets messy -- essentially you are fooling the chip triggeres into thinking the interrupt is "available" even though the ISR is already being processed, so you don't miss the additional trigger(s).

What is the fastest possible time your pins will trigger? If it were my project, I would abandon triggered interrupts per se, and just use an RTCC rollover ISR running a minimum of 2-4 times faster than my possible fastest pin change (or much, much faster if I need more precise time count units between pin state changes). Then I could poll as many pins and their states as I need to in the ISR, update a few counter registers, and not have to deal with missed WKEN/WKPEND bits.

Zoot · 2013-05-27 16:42

e.g., say this ISR runs once every 10us:

INTERRUPT NOCODE 100_000

ISR_Code_Start:
ASM
BANK someBank

MOV W, RB ' capture all pins at once
MOV currPins, W

XOR W, lastPins
AND W, %0000_0001 ' checking pin state change on RB.0
SZ
   INC cntr1 ' increment counter on state change (triggers on leading AND falling edge, for example)
                  ' mainline can read this and reset as needed
                  ' or ISR can reset at regular intervals, etc.
                  ' additionally, the two pin registers can be used for the mainline to read the most recent state changes at will

MOV W, currPins
XOR W, lastPins
AND W, %0001_0000 ' checking pin state change on RB.4
SZ
   INC cntr2 

MOV W, currPins
MOV lastPins, W

ISR_Code_End:
ENDASM

RETURNINT

The idea is that you run the ISR often enough that you can't possibly miss a pin state change on the pins you are sampling.

LoopyByteloose · 2013-05-28 08:28

The problem with reading the material is that there is not one section of text or one diagram that completely answers your questions.

You have to run down all the sections and diagrams that apply and read and re-read everything to grasp what is really going on. I've done this at least five or six times and I kept learning more. It is much easier if you have a goal and want to be sure you are getting the results you desire. It is harder to just read it all for 'a comprehensive understanding' of the SXes.

And it never hurts to create and run some tests, observe the results, and compare them against your expectations.

ISRs with the Sleep/WakeUp enabled behave differently than ISRs without this feature.

achidichi · 2013-05-28 14:49

Thanx a lot for your valuable advices.
Yes, I will run some test programs to discard or accept facts explained in datasheets.

LoopyByteloose · 2013-05-29 08:42

I wish the writing was better, but you can figure it out with what I've suggested.

Since it is an EOL product and thread is now archived, nobody is going to revise the resources available.

You might find somebody at www.sxlist.com that is still sharing their knowledge. Similar PIC chips do help as the SXes were intended to be compatible replacement parts.

achidichi · 2013-05-31 08:06

Thanx a lot for your valuable help.
I didn't have time to test it yet but reading the datasheet more carefully regarding this MIWU port, I realized that they must be right about missing some interrupts. That is because of the 'exchange' instruction:
mov M, #$09;
clr W;
mov !RB, W
which can collide with the arriving of a new detected edge. Yes, your clearing of 'one' pending bit can erase a new detected edge on the rest of the pins if they happen to be at the same time. That is the real flaw on the machine here!!!. Why didn't they do it a 'bit addresable' port to avoid this messing? I don't know

!!!
I will use the sampling scheme as suggested by the documentation and Zoot.

bill190 · 2013-06-01 08:33

achidichi wrote: »

Yes, I will run some test programs to discard or accept facts explained in datasheets.

I've not worked with the SX, so I am not familiar with whatever development or debugging software is available...

But with other chips, where I did not understand exactly what the documentation was saying, I would do whatever it took to "SEE" what was happening.

In some cases I can write a test program to turn on an LED if such and so happens. (Or display "I was here" on a monitor if the program takes a certain path- whatever.)

Of if "fancy" debugging software is available, I may be able to slowly step through a program and watch registers for bits being set or not or see if the program takes a certain path.

Also with an external or debugging software logic analyzer, you can "see" what is going on (or not going on!)

And that is the trick to understanding or troubleshooting something. If you can see what is happening, then all is suddenly clear as light!

Need help on SX Interrupts.

Comments