PORTB + PORTC Interrupt-On-Change

[Amoque]

There may also be the possibility that one might "snapshot" all the lines on an interrupt and then compare to the previous "snapshot" to determine which is the different state?

[Aussie Barry]

Hi Guys,

Henrik:
I am checking for break in continuity due to physical movement. My idea is to use weak pull-ups on one side of the data line and ground the other side. Any break in the line would cause a leading edge interrupt.
Due to the mechanical nature of the test, any line could fail irrespective of the other lines. The test period is around 1 minute.
The failure mode could be intermittent (ie momentary break in continuity) or permanent.
The tests are more indicative than quantitative in that I want to know if one (or more) data lines are broken more often than others - the actual count does not need to be specifically accurate.
Ideally there would be no failures during the test but hey, who lives in an ideal world? I has assigned WORD variables to all nine counters - just in case!

Amoque:
I am not sure how a snapshot would work considering any one of the nine data lines can generate the interrupt. What are you proposing?

Cheers
Barry
VK2XBP

[Charlie]

Use an external "OR" gate to generate the interrupt, then read the state of all the pins and increment the counter for the pin that has changed.
Or you could use PIC16(L)F1526/7 but that's a lot of pins and a difficult package to deal with.

FYI I found it using the part chooser on the Microchip site - I've never actually used the device.

[Aussie Barry]

Hi Charlie,

I had thought about the "OR" gate option but I am not sure if the intermittent fault would last long enough to read the state of all the pins after the interrupt was triggered.
The PIC16(L)F1526/7 still only has PORTB IOC as an option so all those other pins don't really help my cause.

Thanks for taking the time to research other option though - greatly appreciated.

Cheers
Barry
VK2XBP

[HenrikOlsson]

Hi Barry,
The question really is how short of an event you MUST be able to capture. If we're talking microseconds then you really NEED hardware interrupts. If we're getting up into millisconds or possibly the hundreds of microseconds range then a software aproach, in line with what I, and I think Amoque was saying, might work - YMMV.

Here's something in the line of what I'm thinking

SignalLines VAR WORD                                    ' Current state of inputs
oldSignalLines VAR WORD                                 ' Previous state of inputs
Result VAR WORD                                         ' Result of XORing

Counter VAR WORD[9]                                     ' 9 counters, one for each line
idx VAR BYTE                                            ' Index variable

' Subroutine to poll and evalute the signal lines, GOSUB this periodically.
Test:
    SignalLines.LowByte = PortB                         ' 8 lines on PortB and...
    SignalLines.Bit9 = PortC.0                          ' ...and one on PortC.0 for a total of 9.

    ' Any bit that is set in Result indicates a state change, 1->0 and 0->1.    
    Result = SignalLines XOR oldSignalLines

    ' Iterate thru the bits in result and increment the counter for each
    ' respective counter if the bit is set.
    For idx = 0 to 8                                    ' 9 bits, 9 counters
        Counter[idx] = Counter[idx] + Result.Bit0[idx]  ' Increment counter if bit is set
    NEXT
    
    oldSignalLines = SignalLines                        ' Clear any mismatch.

RETURN

Compiles but is not tested, meant as food for thought.

/Henrik.

[retepsnikrep]

Henrik

I though this would take ten pages of code and Darrels instant interrupts etc etc
Then you condense it into about 10 lines.

You are a master!!!

[Aussie Barry]

Hi Henrik,

Thanks for the program suggestion and detailed explanation of how it works.
Very nice and succinct code!

I would like to be able to capture events in the single digit millisecond region as a worst case scenario.
The XOR approach opens up more PIC options and I could use one with the fastest clock on offer.
Would you have any idea how long this subroutine would take to complete with a clock speed of say 32MHz or the shortest time achievable between captured events?

I have a bit of thinking to do before making a decision.

Thank you all for your valuable input to this project.

Cheers
Barry
VK2XBP

[Aussie Barry]

Hi All,

I found PIC16F1783 which has Interrupt-On-Change available on all I/O pins.
This device should be able to do everything I am looking at.

Cheers
Barry
VK2XBP