Searching \ for '[PIC] Weird GPIO-problem on a PIC12F683' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Weird GPIO-problem on a PIC12F683'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Weird GPIO-problem on a PIC12F683'
2007\06\14@135321 by Rikard Bosnjakovic

picon face
I've built a small cable-tester. In a loop, I have these lines:

       movlw   b'00000001'         ; run cable test on GP0
       movwf   GPIO
       call    delay_500ms

       movlw   b'00000010'         ; run cable test on GP1
       movwf   GPIO
       call    delay_500ms

       movlw   b'00000100'         ; run cable test on GP2
       movwf   GPIO
       call    delay_500ms

       movlw   b'00010000'         ; run cable test on GP4
       movwf   GPIO
       call    delay_500ms

       movlw   b'00100000'         ; run cable test on GP5
       movwf   GPIO
       call    delay_500ms

Each of the corresponding GPs are connected to an LED and an
(external) AND-gate. The problem is, none of the LEDs are being lit
when using the above code.

Even more weird, if I insert this piece of test-code (light all LEDs):

       movlw   -1
       movwf   GPIO
       call    delay_500ms
       clrf    GPIO
       call    delay_500ms

between the GP0/GP1 tests above, all LEDs are being lit.
Step-debugging in MPLAB and watching the GPIO, I clearly see
"00000001", "00000010" etc in GPIO for the various tests, but none of
them are being lit.

I also tried this:

   movlw b'11111100'
   movwf GPIO
   call delay_500ms

Then the LEDs are instantly flashing (for like 0.1 ms, just barely
noticeable) before turned off.

I've been scratching my head for a couple of hours now,
double-checking the datasheets but I just can't see what's wrong. It
works for all the LEDs at the same time, but not one at a time.

Can anyone explain what's happening? Could it be a RMW-problem? I
can't think of anything right now.


--
- Rikard - http://bos.hack.org/cv/

2007\06\14@141742 by William Bross

picon face
Rikard,

Did you clear the ANSEL register?  All the A/D pins default to analog
mode on reset.

Bill

Rikard Bosnjakovic wrote:

{Quote hidden}

2007\06\14@154838 by Jamesp

picon face

If the external AND gate has one GPIO connected to each input, and
assuming it's a 6 input AND gate, ALL pins would have to be HIGH for
the output to go HIGH. If there are any unused inputs on the AND gate,
ie an 8 input AND gate, pull each of them HIGH with a 10K or so ohm
resistor.  

The reason it works for the case of writing -1 is that this makes the PORT
take the value of '255', or all pins HIGH (0-1=255).

Try using an OR gate in place of the AND gate, and see if that works.


                                          Regards,

                                            Jim




{Quote hidden}

> --

2007\06\14@165156 by Rikard Bosnjakovic

picon face
On 6/14/07, spam_OUTjamespTakeThisOuTspamintertex.net <.....jamespKILLspamspam@spam@intertex.net> wrote:

>  If the external AND gate has one GPIO connected to each input, and
>  assuming it's a 6 input AND gate, ALL pins would have to be HIGH for
>  the output to go HIGH. If there are any unused inputs on the AND gate,
>  ie an 8 input AND gate, pull each of them HIGH with a 10K or so ohm
>  resistor.

That makes sense.

However, each GPIO goes to one AND-input (and one red LED) each, and
from the same input it goes through the cable in question to test, and
the opposite end of the cable goes to the second AND-input. The
AND-output goes to a green LED.

This means as soon as one GPIO goes high, one AND-input and one red
LED goes high, and if the cable is functional, the other end makes the
second AND-input high, making the output high, making the green LED
lit.

I'm not sure if I'm making sense, but I hope so.


--
- Rikard - http://bos.hack.org/cv/

2007\06\14@220409 by Hector Martin

flavicon
face
> However, each GPIO goes to one AND-input (and one red LED) each, and
> from the same input it goes through the cable in question to test, and
> the opposite end of the cable goes to the second AND-input. The
> AND-output goes to a green LED.
>
> This means as soon as one GPIO goes high, one AND-input and one red
> LED goes high, and if the cable is functional, the other end makes the
> second AND-input high, making the output high, making the green LED
> lit.
>
> I'm not sure if I'm making sense, but I hope so.

The design looks fine to me. Do add pull-down resistors to the second
AND inputs though, if you haven't already.

My suggestion: whip out a multimeter (or just hotwire some LEDs) and
test the PIC outputs. You might have miswired the AND gates, or maybe
the chip is defective, or the wire to test is wired wrong (in which case
your tester seems to be working perfectly). Testing the midpoint (the
PIC outputs) will allow you to rule your program out, if it's not the
problem.

With the behavior you described, it might be that the cable-to-test is
miswired. If there are no pull-downs on the AND gate inputs, you can get
all sorts of funky behavior due to varying charge on the FET gates when
inputs are floating (especially if a long but unterminated wire is
connected). Once you do add pull-downs, if the behavior persists, it
might be the test wire is just connected improperly, or the AND gates
are (assuming the PIC tests out fine as above). If the PIC doesn't put
out the proper states, then either there's someone competing with it
(e.g. the AND gate outputs are wired to the PIC outputs), or there's a
code problem (As others have mentioned, check analog mode. Doublecheck
TRIS too.)


--
Hector Martin (hectorspamKILLspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\06\15@032345 by Rikard Bosnjakovic

picon face
On 6/15/07, Hector Martin <.....hectorKILLspamspam.....marcansoft.com> wrote:

> With the behavior you described, it might be that the cable-to-test is
> miswired. If there are no pull-downs on the AND gate inputs, you can get
> all sorts of funky behavior due to varying charge on the FET gates when
> inputs are floating (especially if a long but unterminated wire is
> connected). Once you do add pull-downs, if the behavior persists, it
> might be the test wire is just connected improperly, or the AND gates
> are (assuming the PIC tests out fine as above). If the PIC doesn't put
> out the proper states, then either there's someone competing with it
> (e.g. the AND gate outputs are wired to the PIC outputs), or there's a
> code problem (As others have mentioned, check analog mode. Doublecheck
> TRIS too.)

I forgot to say that when I tested the code the cable-to-test was not
plugged in, because I was only tracking down the error as to why the
red LEDs did not lit. I've double checked the TRIS and ANSEL and I
can't find any errors. Also, the datasheet says that when the GPIO is
configured as output, ANSEL has no effect even if it's set.

I wrote an ugly test-loop writes the numbers 1..255 to GPIO, just for
the sake of testing and see what happens. No test-cable was plugged
in, and the LEDs did get lit. But not in the way you would expect
(binary look-a-likes), but rather "the higher the number, the more the
intensity". All five red LEDs got lit at the same time, and the green
as well.

So, this cannot be a code problem, since I've step-debugged the code
flawlessly and it works perfectly within MPLAB. The reason must be
that I have messed up big time in the external circuitory. Somewhere.

I have the tester working in another (non-PIC) version[1], and this
one was supposed to replace it. Somehow I thought that I could boast
to myself saying that I don't need any stinking schematics since I've
already constructed the "same" circuit earlier, 2 years ago. I will
put this protoboard in the trashcan and start over, and this time I
*will* make a schematic for it.

Thanks for the input.


[1] http://bos.hack.org/hacks/x1541-testare/

--
- Rikard - http://bos.hack.org/cv/

2007\06\15@060819 by Gerhard Fiedler

picon face
Rikard Bosnjakovic wrote:

> I have the tester working in another (non-PIC) version[1], and this one
> was supposed to replace it. Somehow I thought that I could boast to
> myself saying that I don't need any stinking schematics since I've
> already constructed the "same" circuit earlier, 2 years ago. I will put
> this protoboard in the trashcan and start over, and this time I *will*
> make a schematic for it.

Ah, here is the bug :)

At least, if you don't see it immediately when you draw it, a schematic
helps other people help you.

Gerhard

2007\06\15@062024 by Rikard Bosnjakovic

picon face
On 6/15/07, Gerhard Fiedler <EraseMElistsspam_OUTspamTakeThisOuTconnectionbrazil.com> wrote:

> At least, if you don't see it immediately when you draw it, a schematic
> helps other people help you.

True that.

I didn't do that for the complex poker clock - which happened to be my
first PIC-construction, by the way - some month ago, and I'm still
astonished I managed to get it to work. But I guess it was a one-shot
luck, because this real small project screwed up big time.

Good thing is that you (usually) learn by the mistakes. In this case,
I need to make it a routine to draw schematics for every circuit
before actually building it.

Thanks.


--
- Rikard - http://bos.hack.org/cv/

2007\06\15@064011 by Jan-Erik Soderholm
face picon face
> Good thing is that you (usually) learn by the mistakes.

Even in poker I hope ?  :-)

Jan-Erik.



Rikard Bosnjakovic wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2007 , 2008 only
- Today
- New search...