PORTB + PORTC Interrupt-On-Change

[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

[HenrikOlsson]

Hi Barry,
That's great! While you searched and found that PIC a did some test here, now they are kind of moot but since I did them I'll post the results anyway.

The subroutine code, as written originally takes, 769 cycles (on an 18F part, don't know if it'll be any different on a 16F1x) including the GOSUB and RETURN. At 32MHz that's ~100us.

I thought that was quite a bit to tell you the truth so I tried replacing the array indexing FOR-NEXT loop discrete lines (Counter[0] = Counter[0] + Result.BIT0 and so on) and it went down from 769 to 87(!) cycles. 87 cycles at 32MHz is only ~11us.

The tricky part would obviosuly be to update the LCD during the duration of the test. I think you'd need to write a single character to LCD, GOSUB the test routine write another character, GOSUB the test routine and so on. Obviously not rewriting static information every time.

Anyway, if you've found a suitable device then going the interrupt route is probably better!

/Henrik.