gnupic: Re: Interesting interaction between PORTE and PORTC
Subject:
Re: [PIC]: Interesting interaction between PORTE and PORTC
From:
Rick Mann ####@####.####
Date:
19 Nov 2002 20:43:58 -0000
Message-Id: <B9FFE154.F583%rmann@latencyzero.com>
Thanks for the response.
on 11/19/02 5:23 AM, Sergey A. Dryga at ####@####.#### wrote:
> I had similar problem with PIC16F84, solution was to configure pull-up
> on pins. The PORTC does not have internal pull-ups, maybe external will
> help. Also, check the circuit that drives this pin.
Well, so what bothers me on this particular one is that that port pin is
configured as an input. Furthermore, there is an IR receiver module
connected to it that would keep that input high until it receives a
modulated IR signal. I've confirmed that it's not receiving IR, yet the line
fluctuates.
The PIC is capable of overdriving the line and forcing it low, as I learned
when I had mis-configured Timer 1. I've double-checked to make sure Timer 1
is not misconfigured.
What's strange is that I enter this code just fine:
Loop
movfw gInputDisplay
movwf PORTD
movfw gPowerDisplay
movwf PORTE
nop (a few of these)
clrf PORTD
clrf PORTE
nop (a bunch more of these)
goto Loop
As soon as this code starts to execute, the problem happens. When the
problem is finished, 65 ms later, two things generally have occurred. PORTC
1 has twiddled, usually for the entire 65 ms, but not at a constant
frequency, and all the LEDs connected to PORTD & PORTE go out. However, I've
commented out all of the interrupt service code and GIE is disabled.
If I remove the clrf PORTE, the problem goes away.
65 ms can be a Timer 0 full count at 1:256 or a Timer 1 count at 1:1
prescale. I do use Timer 0 before I get to that code for some blocking delay
loops, but I don't see how it could be causing this particular behavior.
I sure wish I could get gpsim running on my OS.
--
Rick
