Searching \ for '[PIC]: Picky I/O' 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/ios.htm?key=i%2Fo
Search entire site for: 'Picky I/O'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Picky I/O'
2000\12\31@215350 by David VanHorn

flavicon
face
I'm having trouble with an I/O function.

I have a capacitor, connected through three resistors, to three I/O pins.
The Capsense pin connects to the cap through a 1k resistor.
The other two pins are varying resistance.
If I set them as inputs, then the resistances don't matter.
If I set either one as output, then it charges or discharges the cap at a
rate determined by it's resistor.

The basic idea is to read the cap RC time constant, as a form of A/D converter.

Everything's fine, till I get to the point where I want to watch the cap
discharge, until it's low, before taking one of the other pins to output high.

Read_Function:
       btfsc   PORTB,Capsense          ;loop here till low on cap sense pin
       goto    Read_Function           ;

The Capsense pin is set as an input, as is one of the other two pins
The third is an output, and I can see that it is low, and that the voltage
on the capsense pin is also low, but the code loops here forever,
indicating that it's seeing a high input.

I've walked through all the banking, and I believe that I'm in the right
banks when I'm talking to PORTB and TRISB.

I've disabled all peripherals that would otherwise use portb pins.

So, how could I get stuck here, given a low on the Capsense pin of portb?

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\31@230610 by Dwayne Reid

flavicon
face
I know its something that you have already looked at, but just what is in
the TRISB register.  Just for the heck of it, why not add a couple of lines
just before Read_Function:

        movlw   b'xxxxxxxx'     ;set bits accordingly . . .
        tris    PORTB

Lets just make sure that the DDR is what you think it is.

dwayne

At 09:50 PM 12/31/00 -0500, David VanHorn wrote:
{Quote hidden}

Dwayne Reid   <.....dwaynerKILLspamspam@spam@planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 16 years of Engineering Innovation (1984 - 2000)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2000\12\31@231648 by David VanHorn

flavicon
face
At 09:12 PM 12/31/00 -0700, Dwayne Reid wrote:
>I know its something that you have already looked at, but just what is in
>the TRISB register.  Just for the heck of it, why not add a couple of lines
>just before Read_Function:
>
>         movlw   b'xxxxxxxx'     ;set bits accordingly . . .
>         tris    PORTB

Here's the setup. The intent is as commented.
I will probably compact things once everything is working, but at this
point, I like to keep things separate, and as clear as possible.

Read_Cap_Done:
        ;In bank zero at this point
        bcf     PORTA,Function          ;Set function output as low,

        bsf     STATUS,rp0              ;select bank one
        bsf     TRISB^080h,Capsense     ;Set cap sense pin as input
        bcf     TRISA^080h,Function     ;Set the function pin as output
        bsf     TRISB^080h,Unitid       ;Set Unit ID pin as input
        bcf     STATUS,rp0              ;select bank zero
        bcf     PORTA,Function          ;Set function output as low
        clrwdt                          ;Limits how long we can wait

Read_Function:
        ;btfsc  PORTB,Capsense          ;loop here till low on cap sense pin
        ;goto   Read_Function           ;

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2000\12\31@233803 by Roman Black

flavicon
face
Since your code seems simple I guess you may have a
hardware problem! If I understand your circuit properly
you are using one pin to ground the C through R, then
the other pin to sense the voltage. And the third pin
hopefully floats so it doesn't affect anything.

Since it is not detecting low, my guess is the voltage
on the capsense pin is not going below the bottom
threshold. This could be caused by three things;

* there is a current leak holding the cap voltage high
* there is not enough current drain to pull the volts down
* voltage mismatch with pin types

Put a voltmeter on the cap. See if it below the bottom
threshold. Disconnect the float pin to see if that
is leaking to hold the cap volts up. Check the volts
on the low output pin, it may be too high.

My *guess* is you have quite a high value resistor
from the cap to the low pin, the PIC low voltage
can be as high as 0.6v. The low input threshold is
about 0.8v for the TTL inputs and 0.2v for the schmitt
inputs.

If you capsense is schmitt input that might explain
it?? What value is your discharge resistor??
-Roman









David VanHorn wrote:
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2000\12\31@235017 by David VanHorn

flavicon
face
At 03:36 PM 1/1/01 +1100, Roman Black wrote:
>Since your code seems simple I guess you may have a
>hardware problem! If I understand your circuit properly
>you are using one pin to ground the C through R, then
>the other pin to sense the voltage. And the third pin
>hopefully floats so it doesn't affect anything.

The third is set as input, so that would be the general expectation.

I've been away from pics for a while, so I expect that I'm missing
something peculiar to pic port pins.


>Since it is not detecting low, my guess is the voltage
>on the capsense pin is not going below the bottom
>threshold. This could be caused by three things;

I hear you, but Mr Scope says otherwise. It droops to zero, and sits there.
I'm trying various perversions to diagnose where it's falling apart,
without butchering the routine too much.

>If you capsense is schmitt input that might explain
>it?? What value is your discharge resistor??

1k-10k for a 0.1uF cap.
I generally avoid high impedances where practical.

Happy new year :)


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body



'[PIC]: Picky I/O'
2001\01\01@000656 by 1?Q?Alexandre_N._Guimar=E3es?=
flavicon
face
Hi, Dave

   I am not the only one awake and working at the new years eve !!!!

   Just a list of things to check, might help.

   Unconnect everything from the pins and check if they are really floating
as you think.

   Short-circuit the capacitor and check if the routine works that way.

   Check to see if the definition of capsense pin is the right one.

   Double check to see if no other internal peripherals are using the pin.

Best regards and happy new year,
Alexandre Guimaraes
KILLspamalexgKILLspamspamiis.com.br

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\01\01@003426 by David VanHorn

flavicon
face
I just reconfirmed the low state, adding some "pings" on an unused pin.
It's definitely low, at 10mV, when that btfsc is executed.

If I enable that routine, we wait forever, even though the pin is an input,
and low.
It's as if something's getting between the code, and the external pin.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\01\01@004502 by Roman Black

flavicon
face
David VanHorn wrote:
>
> I just reconfirmed the low state, adding some "pings" on an unused pin.
> It's definitely low, at 10mV, when that btfsc is executed.
>
> If I enable that routine, we wait forever, even though the pin is an input,
> and low.
> It's as if something's getting between the code, and the external pin.


David when you initialse the port for direction, you are
following the PROPER sequence by issuing a

clrf PORTB

before your
bsf STATUS,RP0
bsf TRISB,x
stuff??

I have been caught by this before. Also it is a good idea to
use a softare delay of a half second or so defore doing any
pin sensing to allow voltages to stabilise, and my preference
is to set all pins as outs and drive them low, then 0.5 sec
delay, then change pins to inputs again and start running.

You never know if a capacitive load on a pin will cause
it to play up during initialisation especially if VSS is
not up to scratch yet. :o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\01\01@012323 by David VanHorn

flavicon
face
>
>David when you initialse the port for direction, you are
>following the PROPER sequence by issuing a
>
>clrf PORTB
>
>before your
>bsf STATUS,RP0
>bsf TRISB,x
>stuff??

Noooo..

Where do they say that this is required???

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\01\01@013150 by David VanHorn

flavicon
face
>
>David when you initialse the port for direction, you are
>following the PROPER sequence by issuing a
>
>clrf PORTB

This hasn't solved the problem yet, but I'm not sure I'm applying this
right yet either..

I put this in front of every major block of port switching, and the
waveforms are now more like what I expected.

What exactly is the dependency here??


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspam.....mitvma.mit.edu


2001\01\01@020549 by David VanHorn

flavicon
face
Looking at this further, it appears that the setting and clearing bits in
the TRIS register is not as simple as I thought.

I had assumed that I could flip a pin from input to output and back, by bcf
and bsf instructions on the TRIS registers.

Apparently this isn't true.

Reviewing a project that I did on the F84, where I had no problems of this
nature, I also notice that my I/O pins never changed direction once
established in the init.

So, since it's not spelled out in the data sheet, What exactly does it take
to flip bit X from output to input, and back again, without hosing the
other bits on the port, or their directions..

PIC:  Procrustean Internal Creation.
--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\01\01@075541 by Roman Black

flavicon
face
David VanHorn wrote:
>
> Looking at this further, it appears that the setting and clearing bits in
> the TRIS register is not as simple as I thought.
>
> I had assumed that I could flip a pin from input to output and back, by bcf
> and bsf instructions on the TRIS registers.
>
> Apparently this isn't true.

Hmm, read somewhere you have to do a clrf PORTx before doing
the TRIS thing. Maybe in my old 16C84 datasheet, that was
a good one.

I always do tristating like this:

clrf PORTB
movlw b'00100011'
(comment the bits here)
movwf TRISB

I have never tried using a bsf or bcf for tristating.
-Roman

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\01\01@121037 by David VanHorn

flavicon
face
>
>I always do tristating like this:
>
>clrf PORTB
>movlw b'00100011'
>(comment the bits here)
>movwf TRISB

This is VERY bad.
That would make it impossible to work with any single bit, without
glitching the entire port. I'm astounded if it's really true that you MUST
glitch the port.


So far, I'm having some success with:

movfw   TRISx       ;Read the current directions
iorlw   b'10101001' ;Turn bits to inputs
andlw   b'11111001' ;Turn bits to outputs
movwf   TRISx       ;All happens at once

So far, BSF and BCF are working on the port register, which is good,
because I need to be able to set/clear individual bits.

Still walking through the routines, it's moderately complicated.


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu


2001\01\01@122034 by Roman Black

flavicon
face
David VanHorn wrote:
>
> >
> >I always do tristating like this:
> >
> >clrf PORTB
> >movlw b'00100011'
> >(comment the bits here)
> >movwf TRISB
>
> This is VERY bad.
> That would make it impossible to work with any single bit, without
> glitching the entire port. I'm astounded if it's really true that you MUST
> glitch the port.

Actually I've never needed to change a pin from input
to output on the fly. I try and avoid that in my hardware
designs. I do drive some unusual loads from the PIC pins
so I get sensitive re pin states. I know a lot of guys
here do it so it is probably ok. I'll just shut up now.
:o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\01\01@123549 by David VanHorn

flavicon
face
So I did a little searching, and found this, which is talking to a DS1820
sensor, which requires the same sort of flipping between input and output.

They are just setting the bits with BCF and BSF as I would have expected.
This is F84 code, but AFAIK the ports are the same.

http://www.ubasics.com/adam/pic/picprog.html

M1HI BSF STATUS, RP0 ; go to page 1
     BSF TRISA, 3 ; make RA3 an input
     BCF STATUS, RP0 ; back to page 0
     RETURN ; master 1 wire HI

M1LO BCF PORTA, 3 ; port A, bit 3 low
     BSF STATUS, RP0 ; go to page 1
     BCF TRISA, 3 ; make port A, bit 3 an output
     BCF STATUS, RP0 ; back to page 0
     RETURN ; master 1 wire LO

SLOTLO CALL M1LO ; begin by taking RA3 low
       GOTO DLY80 ; and remain low
       SLOTHI CALL M1LO ; a quick low on RA3
       CALL M1HI ; return high right away
       DLY80 MOVLW $14 ; decimal 20 x 4 = 80 microsec
       CALL MICRO4 ; delay
       CALL M1HI ; always end on high
       RETURN

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu


2001\01\02@034648 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Just a thought, I see you are using PORTB.  You haven't got weak pullups
enabled have you?  Been caught by this before...

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@091005 by Drew Vassallo

picon face
Sorry this is so late, I've been enjoying the holidays and staying away from
e-mail :)

>I had assumed that I could flip a pin from input to output and back, by bcf
>and bsf instructions on the TRIS registers.
>
>Apparently this isn't true.

Well, yes it is.  The only thing you really have to watch out for is the
state of the pin when you switch from input to output.  If the pin is held
high as an input, then switched to an output, the port latch will be loaded
with the input value (high) and remain until it is reloaded with a new
value.

I've done this successfully for I^2C code using pull-ups to drive the I/O
lines.  The problem is that when you do ANY operation on the same port,
REGARDLESS of which pin you access, the port latches are set.  For instance,
if you are switching PORTB, 0 from input to output and it was held high
during the input phase, it will have a '1' loaded into the portb, 0 latch
even after you configure it as an output.  Let's say after you set this pin
as an output and clear it, loading a '0' into the portb, 0 latch.  Now,
let's say you set this pin as an output now, then the pin gets pulled high
by the attached peripheral (even though you aren't READING it at this
point), and during the time that this pin is held high, you do a read or
write on ANY PORTB PIN, then the high value on the 'switchable pin' will be
loaded into the PORTB, 0 latch and stay there until you re-output your
desired value.  This is not obvious and you really have to search your code
to find where you may be accessing other port pins when the input state is
unknown.  If this isn't clear, let me know and I'll try to re-explain it.

I forgot which PIC you're using, but this is from the 16C71 datasheet (same
as all the 16C series I assume, plus 16F84, etc..

<snip>
Any instruction which writes, operates internally as a
read followed by a write operation. The BCF and BSF
instructions, for example, read the register into the
CPU, execute the bit operation and write the result
back to the register. Caution must be used when these
instructions are applied to a port with both inputs and
outputs defined. For example, a BSF operation on bit5
of PORTB will cause all eight bits of PORTB to be read
into the CPU. Then the BSF operation takes place on
bit5 and PORTB is written to the output latches. If
another bit of PORTB is used as a bi-directional I/O pin
(e.g., bit0) and it is defined as an input at this time, the
input signal present on the pin itself would be read into
the CPU and rewritten to the data latch of this particular
pin, overwriting the previous content. As long as the pin
stays in the input mode, no problem occurs. However,
if bit0 is switched to an output, the content of the data
latch may now be unknown.
Reading the port register, reads the values of the port
pins. Writing to the port register writes the value to the
port latch. When using read-modify-write instructions
(ex. BCF, BSF, etc.) on a port, the value of the port pins
is read, the desired operation is done to this value, and
this value is then written to the port latch.
Example 5-3 shows the effect of two sequential read-modify-
write instructions on an I/O port.
;Initial PORT settings: PORTB<7:4> Inputs
; PORTB<3:0> Outputs
;PORTB<7:6> have external pull-ups and are
;not connected to other circuitry
;
; PORT latch PORT pins
; ---------- ---------
BCF PORTB, 7 ; 01pp pppp 11pp pppp
BCF PORTB, 6 ; 10pp pppp 11pp pppp
BSF STATUS, RP0 ;
BCF TRISB, 7 ; 10pp pppp 11pp pppp
BCF TRISB, 6 ; 10pp pppp 10pp pppp
;
;Note that the user may have expected the
;pin values to be 00pp ppp. The 2nd BCF
;caused RB7 to be latched as the pin value
;(high).
<snip>

Hope this helps.  I think you'll find it does.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@094747 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Umm..I don't think that statement is entirely accurate.  When the pin is
switched to an output (by modifying the TRIS register), whatever is in the
the port latch is output on the pin.  The critical point is that you cannot
guarantee what is in the output latch if you have performed ANY Read Modify
Write operations on the port latch since that pin was configured as an
input.  The only safe ways this can be done is to either set the output
latch once and never do any RMW operation on that port, which is a tad
limiting, or explicitly set the the port latch every time before you clear
the TRIS bit.

This problem has been the downfall of many an I2C routine, even the ones
that come with Hitechs PICC don't address the problem properly.

Regards

Mike

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@104134 by David VanHorn

flavicon
face
>
>Just a thought, I see you are using PORTB.  You haven't got weak pullups
>enabled have you?  Been caught by this before...

No, but thanks anyhow.

It turned out to be a combination of problems, all ok now.

--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@104554 by David VanHorn

flavicon
face
>
>Umm..I don't think that statement is entirely accurate.  When the pin is
>switched to an output (by modifying the TRIS register), whatever is in the
>the port latch is output on the pin.  The critical point is that you cannot
>guarantee what is in the output latch if you have performed ANY Read Modify
>Write operations on the port latch since that pin was configured as an
>input.  The only safe ways this can be done is to either set the output
>latch once and never do any RMW operation on that port, which is a tad
>limiting, or explicitly set the the port latch every time before you clear
>the TRIS bit.

At this point, I'm ok.
I'm able to do BCF and BSF on the tris register, and on the port with
predictable results.

I had a couple problems hitting me at the same time, giving some pretty
wierd symptoms.

One point of note, I had missed that RA4 is open-drain, and therefore can't
drive high no matter WHAT you do in the code :)


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@111547 by Drew Vassallo

picon face
> > Well, yes it is.  The only thing you really have to watch out for is the
> > state of the pin when you switch from input to output.  If the pin is
>held
> > high as an input, then switched to an output, the port latch will be
> > loaded
> > with the input value (high) and remain until it is reloaded with a new
> > value.
> >
>Umm..I don't think that statement is entirely accurate.  When the pin is
>switched to an output (by modifying the TRIS register), whatever is in the
>the port latch is output on the pin.  The critical point is that you cannot
>guarantee what is in the output latch if you have performed ANY Read Modify
>Write operations on the port latch since that pin was configured as an
>input.  The only safe ways this can be done is to either set the output

Of course you're right.  I think I omitted that critical piece of
information in my haste to make it brief.  I believe, though, that I
included this information later on in my message.  Sorry for the confusion.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\01\02@115416 by David VanHorn

flavicon
face
>>
>>Umm..I don't think that statement is entirely accurate.  When the pin is
>>switched to an output (by modifying the TRIS register), whatever is in the
>>the port latch is output on the pin.  The critical point is that you cannot
>>guarantee what is in the output latch if you have performed ANY Read Modify
>>Write operations on the port latch since that pin was configured as an
>>input.  The only safe ways this can be done is to either set the output
>
>Of course you're right.  I think I omitted that critical piece of
>information in my haste to make it brief.  I believe, though, that I
>included this information later on in my message.  Sorry for the confusion.

The key issue on read/mod/write with port registers, is that there is
external hardware that may drag pins to different states than is currently
in the port register.  IF you can determine that this is not a problem,
then there should be no problem with using these instructions.  In my case,
with a 0.1uF cap through a 1k, I know that this pin will be heavily loaded,
but I'm not doing anything else on the port when it matters, and when I am
doing other things on the port, the state of this pin is irrelevant.

I haven't tested these instructions exhaustively with internal registers
(like tris) but I believe that it's not a problem, as long as you avoid
sequential ops to the same port. That's easy enough, through re-arrainging,
or nops.

It is a nasty-ism in the pics though.
In the AVR, this just dosen't happen. You have port, pin, and
tris-equivalent registers, where port is the output, and pin is the input
(causes newbieations!)
Bit set and reset is free of any constraints on sequential operations as well.


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


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