PORTB + PORTC Interrupt-On-Change

[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

[towlerg]

Hi Barry

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.

You can buy a Saleae for 119Euros. Accepted that you'll need an old laptop for display. It'll store billions of samples @ 24Mhz, thats at least a decade better that Darrel is suggesting, and he writes great code. How many samples before the PIC runs out of memory?

Anyways, good luck with the project.

George

[Aussie Barry]

Hi George,

Yes, there are always a number of different ways to "skin a cat" but if I went with the logic analyser route then I would have nothing to design and build using a PIC

If we end up with more than a byte's worth of fault counts on any of the nine data lines within a one minute test period then we have more problems to worry about than a PIC running out of memory!

Cheers
Barry
VK2XBP