Searching \ for '[PIC]: 12c671 - GPIO vs TRIS Reg' 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: '12c671 - GPIO vs TRIS Reg'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 12c671 - GPIO vs TRIS Reg'
2001\03\02@233158 by Jess Hancock

flavicon
face
Hi

This is my first PIC project and is based on a 12C671.

The code was written by someone else and the hex code was
posted on the internet at:

http://www.qsl.net/ke4hor/polar.htm

I'm just trying to duplicate it.  I obtained the un-commented
assembler code via Bubble Software's disassembler, HEXPIC.EXE,
from the posted hex code and I am trying to figure out how it
works.

This application is supposed to input analog for D/A on
GP0 (Pin 7), GP1 (Pin 6), and GP2 (Pin 5).  A/D results go to
a PC via GP5 (Pin 2) connected to DB9 pin2 on PC and
GP4 (Pin 3) connected to DB9 pin 3 (data).  GP3/MCLR is
connected to +5V thru 4k7 ohms, no other connections.  So far
I have not been able to communicate with the PC but looking at
Pin 3 with an Oscope appears to show data being sent.  Pin 2
seems to be low with noise.  I have an OSCCAL value error
which may upset the timing.

Comments in the following code segments are mine and may be
in error.  Electrical connections are as indicated.

ad0083      MOVLW 0x07
                 MOVWF INDF
                 BSF STATUS, RP0 ; Bank 1
                 BCF GPIO, 4 ; GPIO(4), Pin 3

;GPIO(4) goes to PC RS232 pin 3 DB9 (data)

                 BCF STATUS, RP0 ; Bank 0
                 BSF GPIO, 4

-------------------------------------------

ad00CE        CLRF   0x24
                    BSF   STATUS,RP0 ; Bank 1
                    BCF   GPIO,3       ; GPIO (3), Pin 4, GP3/MCLR

;GPIO(3), is held high by 4k7 resistor.

                    BCF   STATUS,RP0 ; Bank 0
                    BCF   GPIO,3       ;
           ;
ad00D3       GOTO  ad0094
           ;

The code

BCF GPIO,3 and BCF GPIO,4

each appears twice in the above.  The first instance is
in Bank 1 and the second is in Bank 0.  In looking at
the Special Function Registers (Doc DS30561B, pg 12
Figure 4-2), it appears that for Bank 1, GPIO should
really be called TRIS.

Two questions:

1) what does each of the above segments accomplish? and
2) if in fact the first instance is referring to the TRIS
register, why isn't it called TRIS?

Other comments welcomed.  Thanks for your help.

Jess

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


2001\03\03@084836 by Bob Ammerman

picon face
> This application is supposed to input analog for D/A on
> GP0 (Pin 7), GP1 (Pin 6), and GP2 (Pin 5).  A/D results go to
> a PC via GP5 (Pin 2) connected to DB9 pin2 on PC and
> GP4 (Pin 3) connected to DB9 pin 3 (data).  GP3/MCLR is
> connected to +5V thru 4k7 ohms, no other connections.  So far
> I have not been able to communicate with the PC but looking at
> Pin 3 with an Oscope appears to show data being sent.  Pin 2
> seems to be low with noise.  I have an OSCCAL value error
> which may upset the timing.

This is very likely.

{Quote hidden}

The Bank 1 reference is indeed a reference to the TRIS register. It is
making the specified bit into an output.

The Bank 0 reference is actually setting the pin to zero.

> 2) if in fact the first instance is referring to the TRIS
> register, why isn't it called TRIS?

Because the disassembler doesn't keep track of the current bank.

> Other comments welcomed.  Thanks for your help.
>
> Jess


Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

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


2001\03\03@094605 by Drew Vassallo

picon face
>ad0083      MOVLW 0x07
>                   MOVWF INDF
>                   BSF STATUS, RP0 ; Bank 1
>                   BCF GPIO, 4 ; GPIO(4), Pin 3
>                   BCF STATUS, RP0 ; Bank 0
>                   BSF GPIO, 4

This might be some sort of data transfer out pin 3.  Apparently it's looking
to change GPIO,4 to output, then driving the pin high.  I don't know why,
though.

>ad00CE        CLRF   0x24
>                      BSF   STATUS,RP0 ; Bank 1
>                      BCF   GPIO,3       ; GPIO (3), Pin 4, GP3/MCLR
>                      BCF   STATUS,RP0 ; Bank 0
>                      BCF   GPIO,3       ;

It appears that it's trying to use the MCLR as another GPIO pin, rather than
for MCLR.  It's setting it up as output, then driving it low.  But if you
have it connected as a *real* MCLR (pulling it high), this section is
meaningless.


_________________________________________________________________
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\03\04@220906 by Jess Hancock

flavicon
face
Thanks Bob and Drew for your responses.

Bob, the documentation indicates the GPIO/TRIS registers are at register
memory locations 0x05/0x85 and therefore it seems the disassembler should
know which register is being addressed.  To test, I modified the source code
below by substituting TRISIO for the first GPIO and then assembled it  and
got the following hex code and Message[302].  Excerpts from POLARMD2.LST:

0019   3008           00135 ad0019      MOVLW 0x08
001A   00A1           00136             MOVWF 0x21
001B   1683           00137             BSF STATUS,RP0
Message[302]: Register in operand not in bank 0.  Ensure that bank bits are
correct.
001C   1205           00138             BCF TRISIO,4               ; ??? RAM
Page TRISIO,4
001D   1283           00139             BCF STATUS,RP0
001E   1605           00140             BSF GPIO,4               ; ??? RAM
Page TRISIO,4
001F   17A1           00141             BSF 0x21,7
0020   282E           00142             GOTO ad002E
                     00143             ;
0021   13A1           00144 ad0021      BCF 0x21,7
0022   0CA7           00145 ad0022      RRF 0x27,f
0023   1803           00146             BTFSC STATUS,C
0024   1205           00147             BCF GPIO,4               ; ??? RAM
Page TRISIO,4
0025   1C03           00148             BTFSS STATUS,C
0026   1605           00149             BSF GPIO,4               ; ??? RAM
Page TRISIO,4
0027   1721           00150             BSF 0x21,6
0028   282E           00151             GOTO ad002E

Note: the comments "???RAM Page TRISIO,4" were produced when disassembling
the source HEX code.

Line 0x001C contains the TRISIO register and line 0x0024 contains the GPIO
register.  They both produce a hex code of 1205h.  I think I remember that
Msg [302] is not an error but a WARNING ?  or at least a caution.

So, when coding in assembly, which register name should one use - the
register name matching the Bank or is it sufficient to use either name and
preselect the correct Bank?  Is TRISIO the appropriate name to use for Bank
1?  Logic would say use the matching register name, but either seems to give
the same result here.  Is this consistent in other registers?  Or am I
missing something obvious?

Would you elaborate?

Thanks, Jess

{Original Message removed}

2001\03\04@223441 by Bob Ammerman

picon face
----- Original Message -----
From: Jess Hancock <.....jhancockKILLspamspam@spam@CWV.NET>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Sunday, March 04, 2001 10:08 PM
Subject: Re: [PIC]: 12c671 - GPIO vs TRIS Reg


> Thanks Bob and Drew for your responses.
>
> Bob, the documentation indicates the GPIO/TRIS registers are at register
> memory locations 0x05/0x85 and therefore it seems the disassembler should
> know which register is being addressed.

Yes, these registers have the specified addresses. But, where are those
addresses stored when the program is running.

Well, the low order 7 bits of the address are stored in the instruction
itself.

But the high order bit is stored in the RP0 bit of the status register.

Thus, the disassembler, which only looks at one instruction at a time, can
only see the low 7 bits of the address. The designer of the disassembler
decided to just use the register that would be referenced if RP0 was zero.

In other words, the very same instruction bit pattern can refer to either
the GPIO register or the TRISIO register, depending on the value of RP0
(which is not determined by the particular instruction being disassembled.

More sophisticated disassemblers do _try_ to keep track of the value of RP0,
but in general that cannot be done perfectly.

>To test, I modified the source code
> below by substituting TRISIO for the first GPIO and then assembled it  and
> got the following hex code and Message[302].  Excerpts from POLARMD2.LST:
>
> 0019   3008           00135 ad0019      MOVLW 0x08
> 001A   00A1           00136             MOVWF 0x21
> 001B   1683           00137             BSF STATUS,RP0
> Message[302]: Register in operand not in bank 0.  Ensure that bank bits
are
> correct.
> 001C   1205           00138             BCF TRISIO,4               ; ???
RAM
{Quote hidden}

It is a warning. Basically the assembler is telling you:

"I can't fit the address of this register into the 7 bits I have for a
register address in the instruction. You better make sure that RP0 is right
for this reference!".

> So, when coding in assembly, which register name should one use - the
> register name matching the Bank or is it sufficient to use either name and
> preselect the correct Bank?  Is TRISIO the appropriate name to use for
Bank
> 1?  Logic would say use the matching register name, but either seems to
give
> the same result here.  Is this consistent in other registers?  Or am I
> missing something obvious?

You should use the register name that you are actually trying to access, and
you should be very careful to ensure that you have RP0 set appropriately.

This happens with all registers that are 'shadows' of each other in the two
banks.

>
> Would you elaborate?
>
> Thanks, Jess
>

I hope that makes some sense.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\04@225157 by Jess Hancock

flavicon
face
Yes, Bob, your explanation makes good hind-sight sense.  I'll get this thing
working one day - and hope to learn more and more in the process.  Man, you
sure do work late!

Thanks, Jess

-----Original Message-----
From: Bob Ammerman <.....RAMMERMANKILLspamspam.....PRODIGY.NET>
To: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Date: Sunday, March 04, 2001 10:37 PM
Subject: Re: [PIC]: 12c671 - GPIO vs TRIS Reg

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\04@232943 by Roman Black

flavicon
face
Hi Jess, is it possible your include file is
corrupted, or you have linked the wrong include file?
-Roman


Jess Hancock wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\03\04@235508 by Jess Hancock

flavicon
face
Roman, I haven't checked all the EQU's but the GPIO (0x05h) and TRISIO
(0x85h) are correct.  I'm new at PICs and trying to understand someone
else's uncommented code obtained by disassembling the hex source (this is
worse than a jig saw puzzle - no colors to give clues!).  I have programmed
the 12c671 but RS232 is not working.  The OSCCAL value was programmed
incorrectly so that may be a major factor why it doesn't work.  Thanks for
your interest.

Jess

       00008 ; RAM Page 0 Registers
                     00009 ;
 00000004            00014 FSR          EQU 0x0004
 00000005            00015 GPIO         EQU 0x0005
 0000000A            00016 PCLATH       EQU 0x000A
                     00021 ;
                     00022 ; RAM Page 1 Registers
                     00023 ;
 00000081            00024 OPTION_REG   EQU 0x0081
 00000085            00025 TRISIO       EQU 0x0085
 0000008C            00026 PIE1         EQU 0x008C

{Original Message removed}

2001\03\05@082910 by Drew Vassallo

picon face
>(0x85h) are correct.  I'm new at PICs and trying to understand someone
>else's uncommented code obtained by disassembling the hex source (this is
>worse than a jig saw puzzle - no colors to give clues!).  I have programmed

It may help to run through some of the beginners projects listed on the
PICLIST.  (Go to WWW.PICLIST.COM and it's listed right on the home page).
Many of them are simple enough to understand and some (like mine :)  are
commented pretty well, explaining why things are done the way they are.

Trying to use disassembled code to learn from is just not smart.  Once you
get more experience/exposure to the basics of handling the SFR's and
configuration options, you'll be able to approach uncommented code and
(sometimes) be able to see what's happening.

--Andrew


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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\05@090444 by Olin Lathrop

face picon face
> Bob, the documentation indicates the GPIO/TRIS registers are at register
> memory locations 0x05/0x85 and therefore it seems the disassembler should
> know which register is being addressed.

No, because only the low 7 bits of the address are encoded into the
instruction.  The upper two bits come from the bank bits.  The disassembler
can't always know the runtime value of the bank bits, and therefore can't
tell whether GPIO or TRISIO was addressed.  If in doubt, it reports the name
of the register in bank 0.

> So, when coding in assembly, which register name should one use - the
> register name matching the Bank or is it sufficient to use either name and
> preselect the correct Bank?

Always always always use the name of the intended register!  Just because
using a different name causes the same instruction to be generated doesn't
make it right.  Imagine someone (or maybe you) trying to figure out in three
years what you intended.  Not only might that change from one PIC to
another, but using an alias register name is like writing deliberately
misleading comments.

By the way, I deal with this register banking issue by using macros that
switch banks for me only when needed.  For example, my code might look like
this:

come_from_someplace unbank   ;clear bank setting assumptions
    dbankif  trisio         ;set banks for access to TRISIO
    movlw    12             ;load some value into TRISIO
    movwf    trisio

    dbankif  gpio           ;change banks as needed to access GPIO
    movlw    34             ;load some other value into GPIO
    movwf    gpio

You are free to use my bank switching macros and lots of other stuff.  Go to
http://www.embedinc.com/pic and see file STD.INS.ASPIC.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\05@133840 by Jess Hancock

flavicon
face
Thanks for the input Olin.  That's quite a set of macros you have.  I'll
have to remember those and after I get a foot or two on the ground, I may
come back to them.  Right now only have a toe or two on the ground re PICs.

One answer always seems to raise more questions.  Your macro's use
IF/Endifs.  Does MPLAB and most assemblers support them?  I'll go check out
MPLAB.  I just realized the other day that the 12c671 does not have decision
making commands other than the btfsc, btfss, decfsz and incfsz instructions.

Thanks, Jess

{Original Message removed}

2001\03\05@181950 by Bob Ammerman

picon face
Jess,

The IF and ENDIF you see in Olin's macros are _not_ runtime assembly
language commands.

Rather, they are commands handled at assembly time, simlilar to C's
#if/#else/#endif

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: Jess Hancock <KILLspamjhancockKILLspamspamCWV.NET>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Monday, March 05, 2001 12:54 PM
Subject: Re: [PIC]: 12c671 - GPIO vs TRIS Reg


> Thanks for the input Olin.  That's quite a set of macros you have.  I'll
> have to remember those and after I get a foot or two on the ground, I may
> come back to them.  Right now only have a toe or two on the ground re
PICs.
>
> One answer always seems to raise more questions.  Your macro's use
> IF/Endifs.  Does MPLAB and most assemblers support them?  I'll go check
out
> MPLAB.  I just realized the other day that the 12c671 does not have
decision
> making commands other than the btfsc, btfss, decfsz and incfsz
instructions.
>
> Thanks, Jess
>
> {Original Message removed}

2001\03\05@210504 by Olin Lathrop

face picon face
> One answer always seems to raise more questions.  Your macro's use
> IF/Endifs.  Does MPLAB and most assemblers support them?

Yes, all my source code is for the MPLAB assembler.  It is available for
free, and more importantly, is the official assembler from Microchip.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\05@221603 by James Cameron

flavicon
face
On Mon, Mar 05, 2001 at 06:25:49PM -0500, Olin Lathrop wrote:
> [someone else wrote]
> > One answer always seems to raise more questions.  Your macro's use
> > IF/Endifs.  Does MPLAB and most assemblers support them?
> Yes, all my source code is for the MPLAB assembler.  It is available for
> free, and more importantly, is the official assembler from Microchip.

gpasm also supports if/endif constructs.

I haven't checked lately, but gpasm probably has a more relaxed software
license when compared to MPLAB/MPASM, and includes source.  Runs on most
platforms.  Doesn't tie you to a single supplier.  Compatible with the
assembler mnemonics used by MPASM.

--
James Cameron    TakeThisOuTquozlEraseMEspamspam_OUTus.netrek.org     http://quozl.netrek.org/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\03\05@231125 by Scott Dattalo

face
flavicon
face
On Tue, 6 Mar 2001, James Cameron wrote:

> On Mon, Mar 05, 2001 at 06:25:49PM -0500, Olin Lathrop wrote:
> > [someone else wrote]
> > > One answer always seems to raise more questions.  Your macro's use
> > > IF/Endifs.  Does MPLAB and most assemblers support them?
> > Yes, all my source code is for the MPLAB assembler.  It is available for
> > free, and more importantly, is the official assembler from Microchip.
>
> gpasm also supports if/endif constructs.

and much more now.

>
> I haven't checked lately, but gpasm probably has a more relaxed software
> license when compared to MPLAB/MPASM, and includes source.  Runs on most
> platforms.  Doesn't tie you to a single supplier.  Compatible with the
> assembler mnemonics used by MPASM.

gpasm is still released under GPL. Craig Franklin joined the development a few
months ago and has been really cranking away. gpasm is now up to version 0.9.2
. There's even a window's version now too. You can get the latest here:

http://gpasm.sourceforge.net/

gpasm also can generate code for the sx processor (although the mnemonics are
limited to PIC mnemonics - gpasm doesn't support the Parallax mnemonics).

Scott

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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