PORTB + PORTC Interrupt-On-Change

[Aussie Barry]

Hi Henrik,

Thank you for the subroutine timing analysis. 11us is a pretty good result!

I am now looking at ways to handle the interrupts and still trap subsequent events whilst the first event is being acted upon.

With the PIC16F1783 all pins on all ports can be configured to operate as IOC pins. Individual status flags can be read and cleared individually so my approach will be to jump to the ISR on an interrupt event, check which of the nine lines were affected using IF...ELSEIF...ENDIF statements, increment the appropriate error counter, clear the individual IOC flag and then return to the main program. My concern is the method used within the ISR to determine which line generated the interrupt. Is a 9 option deep IF...ELSEIF...ENDIF faster or slower than a 9 option deep SELECT CASE...END SELECT? Or is there a more elegant way of doing this which would take less time?

Comments and suggestions are, once again, welcomed and appreciated.

Cheers
Barry
VK2XBP

[Amoque]

I'm a little confused by your requirements.

You state it is a mechanical system - suggesting some debounce might be necessary(?), or is this part of the fault condition to be counted? You worry for the speed of the system and capturing every event, but then state the count need not be too accurate... The requirements are likely very clear in your mind, but reading... it leaves me wondering, just how fast an event you wish to capture and what constitutes an event?

Here we go into areas I'm not qualified to speak with much expertise...

I had imagined some level of filtering to eliminate the tiniest of glitches - capacitors, as used on power supply, to eliminate noise and other such tiny perturbances and measuring events in the range of a few milliseconds - maybe less, I hadn't really thought of minimal times possible, only to make a stable system that reacts reliably and consistently rather than to every stray passing gamma ray . Henrik's suggestion to use ORs is much better... I thought to use latching flip-flops to maintain state until the PIC could read and reset in a tight loop/ interrupt. My idea being that mechanical systems are typically pretty slow and messy, and accuracy at the level I work is typically limited to what I can see and measure. This seems not to be the case for your requirements.

Well, in any case it has been an interesting read - and you have determined an answer suitable... back to the bench for me!

Oh, as to your question... I'd likely stack all the flags into a bit array and then loop through as:

For LOOP = 0 to 8 'For each flag
If BIT[LOOP] Then 'If bit is set
CounterWord[LOOP] = CounterWord[LOOP] + 1 'Add one to count
EndIf
Next


...unless, as I was typing, Henrik posted a more artful method in the post following.

[Aussie Barry]

Hi Amoque,

Please let me clarify my requirements.

I am trying to capture fault conditions so I definitely do not want to de-bounce any of the lines. A fault in this test is defined as an intermittent open circuit and I need to determine not only which lines exhibit fault conditions but also how frequently the faults occur during the test period. The accuracy of an individual line's error count does not have to be to absolute; it is more important to capture a fault condition occurring on any of the other lines whilst processing an fault on an individual line.

For example:
1/. Initial state is set and there are no fault conditions.
2/. Under test conditions, line 1 exhibits a fault condition
3/. Whilst recording line 1 fault condition, line 2 also exhibits a fault condition

In this example I do not want to miss recording the line 2 fault whilst recording the line 1 fault.
If a subsequent fault condition occur on line 1 whilst the initial line 1 fault is being recorded, and some of these slip through, then that is acceptable - not ideal but acceptable. This is what I meant when I stated that "the count need not be too accurate."

So, extreme accuracy in counting individual line faults is not as important as the ability to capture fault events that may occur in quick succession across all nine lines.

An interesting challenge - yes?

I trust this clears up the confusion caused by me not explaining the how's and why's in my previous posts.

Cheers
Barry
VK2XBP

[Dave]

Barry, What is the time between fault conditions? I think I would propose using a couple of port expanders like the PCF8574 with the interrupt lines tied together going to 1 PIC interrupt line. When interrupted just read the port expanders and clear?

[Amoque]

Yes, quite the "sticky wicket". As I see it, your device must be prepared to capture 9 errors simultaneously- and constantly.

I was mistaken in my first assumptions by imagining something like a frame rate where you would have some measure of time between [machine] cycles to do something. I refer to 3/ above - since there is no measure of time allowed to record the event and no lower limit for the event timing (which, in itself provides some opportunity)... it seems impossible to me. The only hope I see is in "If a subsequent fault condition occur on line 1 whilst the initial line 1 fault is being recorded, and some of these slip through, then that is acceptable - not ideal but acceptable."

The closest "solution" I imagine is 9 processors on a common clock, each recording the status of its input on each tick. This will only work to the limits of the clock speed, but it is a start... Or, you might just use a DSO (of the best speed available) as, in the end, this is the function you describe, is it not?

I have had another thought - what of a decade counter on each line? You would not get specific timing, but at regular intervals you could record the number of faults by reading the counter values.

[HenrikOlsson]

Ah, come on guys, I think you are overcomplicating this.
From what I understand it's basically a test rig for flexible cable moving back and forth and the goal is to capture any glitches in the cable as it moves.

Using a PIC with IOC will probably work fine as long as the code for it is written properly. The only thing it will NOT catch is a second (and third and forth and....) fault condition on the very same line that initially caused the interrupt. But then again the absolute fault count per line wasn't that critical and I think that the interrupt latency etc will provide the "perfect" amount debounce (even though the specification said no debounce) for this to work perfectly fine. But again, make sure to read up on how to handle the IOC events in order to not miss events on lines any of the lines that didn't actually cause the interrupt currently being serviced.

Using a port expander, which I also suggested in my first reply, will work but in this case I don't see the benefits, only drawbacks, considering Barry did find a PIC with the needed number of IOC pins.

/Henrik.

[towlerg]

Have I missed something? Why not use a logic analyzer? If it's data presentation that precludes then write a plug-in (both of the obvious candidates provide for them) which will print out the results or give you a go/no go.

[Aussie Barry]

Hi Guys,

Thanks for all the fabulous responses.

1/. Towlerg: "Why not use a logic analyser?" - simply because I don't have one. I also need to replicate this test in other parts of the world so I don't think purchasing multiple logic analysers is a cost effective approach to solving the problem.

2/. Henrik: Great comment! Yes, I do not want to over-complicate the problem. I hope to send my ISR code to the group soon for comment on my approach to handle the IOC event and minimise loss of subsequent events on other lines.

3/. Amoque: Your multiple decade counter suggestion was quite inspirational! I had not thought of it like that but essentially I am trying to replicate the same concept with the PIC16F1783.

4/. Dave: Much of this testing is exploratory so I can't accurately predict what the time between events will be. Ideally there should be no faults at all (obviously) but if there are faults then I want to capture as many events on as many data lines as possible.

I am making good progress on the software side of the project but can't verify anything until the PICs arrive late next week/early the week after. As mentioned above, I will post my ISR code for comment soon. Fingers crossed my methods will not be shot down in flames

I am now concentrating on the hardware side of the project: machining enclosures, mounting LCD displays, push buttons etc but the most trying part will be building jigs to accept the device under test (DUT). Lots of fun ahead for me this weekend!

Cheers
Barry
VK2XBP

[Amoque]

"the most trying part will be building jigs to accept the device under test (DUT)."

I trust that you are looking for every opportunity to use those little Pogo Pin test probes. Those thing seem so cool that I just don't see how any project featuring them can't work.

[Aussie Barry]

Of course!

http://au.element14.com/mill-max/090...83?Ntt=1279883

Cheers
Barry
VK2XBP

[HenrikOlsson]

Hi Barry,
I don't see the need for all the IF/ENDIF stuff, care to explain?

Instead, why not do like I did in the previous example:

Counter[0] = Counter[0] + IOCBP.0  ' Positive edge on RB0
Counter[1] = Counter[1] + IOCBP.1  ' Positive edge on RB1
' ....and so on.

IOCBP = 0   ' Clear the interrupt flag registers

' Possibly clear the IOC flag as well IF DT-INTS doesn't do it (I don't know for sure).

If an IOC flag bit IS set the counter will get incremented, if it's not set the counter will not get incremented. If you want to capture negative edges as well then just add a similar block for IOCBN etc. The ISR will take the same amount of time every time which is good and it should be about as quick as my subroutine so you'll probably spend way more time getting in and out of the ISR than actually IN the ISR.

It might be better to read the complete IOCxP register into a temporary register and using that instead. The datasheet does discuss the correct way of doing this ensuring no events gets missed but I haven't really looked into it properly.

/Henrik.