PORTB + PORTC Interrupt-On-Change

[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

[Darrel Taylor]

Interrupts can be very useful for many different purposes ... this isn't one of them.
In fact, interrupts will only slow things down and reduce the resolution of your readings.

A variation of what Henrik was describing might look like this ...
The resolution with WORD variables for the counts is 9uS (16F1783 running at 32Mhz internal OSC).
If the counters are BYTEs, the resolution is 3.5 uS, as measured in the simulator.

With interrupts, using a BASIC language ISR, that resolution will suffer greatly.

DEFINE OSC 32

ANSELA = 0
ANSELB = 0

Results   VAR BYTE[9]
Res0      VAR Results[0]
Res1      VAR Results[1]
Res2      VAR Results[2]
Res3      VAR Results[3]
Res4      VAR Results[4]
Res5      VAR Results[5]
Res6      VAR Results[6]
Res7      VAR Results[7]
Res8      VAR Results[8]
IOCA      VAR BYTE
IOCB      VAR BYTE
Testing   VAR PORTC.0

IOCBP = $FF
IOCBF = 0

CLEAR
WHILE !Testing : WEND
PAUSE 20

WHILE Testing
    IOCA = IOCAF
    IOCAF = 0
    IOCB = IOCBF
    IOCBF = 0
    Res0 = Res0 + IOCA.0
    Res1 = Res1 + IOCA.1
    Res2 = Res2 + IOCA.2
    Res3 = Res3 + IOCA.3
    Res4 = Res4 + IOCA.4
    Res5 = Res5 + IOCA.5
    Res6 = Res6 + IOCB.0
    Res7 = Res7 + IOCB.1
    Res8 = Res8 + IOCB.2
WEND

[Aussie Barry]

HI All,

I am so glad I didn't show any of you my ISR code...it is embarrassing compared to what Darrel has just shared!

I also need to display results as they occur on a 4x20 LCD. There are two different display screens, one that gives a visual representation if a fault has occurred on any particular data line and another that displays actual fault counts for all nine lines. I don't know the timing requirements for LCDOUT statements but I am sure they will add considerably to the 9uS resolution with WORD variables. I could control the LCDOUT routine such that it only updates the LCD screen if a new fault has occurred. Is it possible to do a comparison using this pseudo-code:

Results VAR WORD[9]
OldResults VAR WORD[9]

IF Results <> OldResults THEN
Goto Display Routine ' break to the routine that updates the LCD screen
OldResults = Results ' Reset OldResults
ENDIF

Cheers
Barry
VK2XBP