Searching \ for '[PIC:] Reading PortA on 16F877' 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=port
Search entire site for: 'Reading PortA on 16F877'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Reading PortA on 16F877'
2004\02\09@113450 by Intosh, Ph.D.

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I want to read either PortA or PortE on a 16F877 chip as digital input.

I have read the PortA, PortE, and A/D sections of 30292c.pdf
In particular, I have read p113.
On page 218, there is an example to use PortA.  I have not done the
CLRF PortA shown in the example, but otherwise comply.  I will try this in
the next cycle.

I have set ADCON1 to 0x06 and verified this with read and display to LEDs.
I have set  and verified TRISA to 0x3F

I do a very simple
        banksel PORTA
        movf    PORTA,w
        banksel PORTD           ;home of the LEDs.
        movwf   PORTD

The LEDs are always dark.  I have success with PORTC as an input.

Thoughts?


- --
Aubrey McIntosh, Ph.D.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBQCe2FwKlSw8yssF7EQKtwgCeJkH1LfsMeQzKfAIbhTNbV22kqvQAn3bS
eZLvXCkZhjwOSI+CpLj8fz3n
=kizK
-----END PGP SIGNATURE-----

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

2004\02\09@120702 by Mike Hord

picon face
The classic gotcha...Is PortA configured to work as a digital port?

The powerup state of PortA is default analog, and you need to
explicitly "fiddle" with the ADCON registers to turn that off and
use them as digital inputs.  Otherwise, they read as '0' regardless
of the actual input state.

Mike H.


{Quote hidden}

_________________________________________________________________
Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up
Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

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

2004\02\09@122141 by Hulatt, Jon

flavicon
face
- did you banksel ADCON1 before you set it to 0x6 ?

- assuming you've properly disabled ADC on the pins, are you sure they're
inputs? TRISC bits are High for inputs on PORTA on F877.

- what is connected to PORTA? are you sure any of the lines are *ever* going
high?

- are you sure your LEDs are wired up properly??

> {Original Message removed}

2004\02\09@140147 by Paul James E.

picon face
I'm not sure what BANKSEL PORTA is supposed to do.
Do a
    bsf     STATUS, RP0
    movlw   0xFF
    movwf   TRISA
    bcf     STATUS, RP0

This will setup PORTA as all inputs.

    Then to read the port, just do a movf 0x05, 0

This will move the contents of PORTA into the 'w' register.

Then do with 'w' what you need to do.

        Regards,

          Jim



{Quote hidden}

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

2004\02\09@142222 by Hulatt, Jon

flavicon
face
I think that encouraging someone to do "movf 0x05, 0" is a pretty bad idea-
the symbols are defined for a pretty good reason after all.

{Original Message removed}

2004\02\09@142636 by John J. McDonough

flavicon
face
Your code will work fine on a 16f84, and will work on an 877 if you are in
bank 0 or 1 (only) - remember the 877 has four banks.  You assume RP1 to be
clear.  On an 877, RP2 is guaranteed clear and TRISA is in bank 1, but maybe
not in some other part.

However,

     banksel TRISA
     movlw   0xFF
     movwf   TRISA
     banksel PORTA

will work in any case.

72/73 de WB8RCR    http://www.qsl.net/wb8rcr
didileydadidah     QRP-L #1446 Code Warriors #35

{Original Message removed}

2004\02\09@143227 by Eisermann, Phil [Ridg/CO]

flavicon
face
pic microcontroller discussion list wrote:
>  I'm not sure what BANKSEL PORTA is supposed to do.

I don't mean to be rude, but then why don't you look it up?
FWIW, it makes sure the correct bank to access PORTA is
selected. The assembler does it for you, so there's less
chance of human error.

>      Then to read the port, just do a movf 0x05, 0
>
>  This will move the contents of PORTA into the 'w' register.

that's exactly what the OP's code did! except that I find the
original code was much clearer and better documented than
your example.

why is your "movf 0x05, 0" better than the "movf PORTA, w"
in the original post?

I *really* don't mean to be rude, but I understand if it comes
across that way. I think (as will many others) that your
suggestion is a very bad idea. The symbolic names are there for
a reason. The code is much clearer with the symbolic names.

Phil Eisermann

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

2004\02\09@143847 by John J. McDonough

flavicon
face
Oh yes, if you want to be thorough:

      banksel TRISA  ; Select proper bank
      movlw   0xFF   ; will set port to all inputs
      errorlevel -302  ; suppress stupid message
      movwf   TRISA  ; set the port
      errorlevel +302  ; re-enable the message in case we screw up later
      banksel PORTA  ; Select the bank containing PORTA
   ; NOW we can read the puppy
     movf   PORTA,W

72/73 de WB8RCR    http://www.qsl.net/wb8rcr
didileydadidah     QRP-L #1446 Code Warriors #35


{Original Message removed}

2004\02\11@110712 by Paul James E.

picon face
All,

I didn't say it was better.  But it is explicit.  And as far as 'BANKSEL'
is concerned, I assumed it was a macro.  I personally don't bother with
macros.  To me, they tend to complicate things.   If you want to use them
and like them, I have no problem with that.  I just like to write my code
so it is easy to follow.  To me, the best way to that end is to not use
macros, and write everything in a straight forward manner.

                                             Regards,

                                               Jim

P.S.  I didn't think you were being rude.  You were just stating your
      opinion.   This likewise is my opinion, so I hope you won't think
      I'm being rude.



{Quote hidden}

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

2004\02\11@171916 by Jinx

face picon face
>  I didn't say it was better.  But it is explicit.  And as far as
> 'BANKSEL'  is concerned, I assumed it was a macro.  I
> personally don't bother with macros.  To me, they tend to
> complicate things.   If you want to use them and like them,
> I have no problem with that.  I just like to write my code so
> it is easy to follow.  To me, the best way to that end is to not
> use macros, and write everything in a straight forward manner

IMHO you would be in a small minority, and I strongly disagree.
There's absolutely no reason why code written in any style can't
be straight forward, but IMHO, again, there's a minimum standard.
For one thing it makes code easier for other people to read and,
just as importantly, for the author in a year's time. By using macros,
defines and equs you are adding one more level of documentation
and that is never a bad thing (because the name is a descriptor),
apart from the fact that it saves one hell of a lot of typing, and macro
usage eliminates many typos being complied. A macro can be as
simple as putting an instruction into plain English, doesn't have to
be complicated (or bloatware) at all

The code posted in the last couple of days for accessing F877
EEPROM is a perfect example of how using macros and register
names improves readability (not having a dig at you Mr Gois,
honest). I find it extremely fatiguing and tedious debugging code
that's peppered with, for example, lines like BSF STATUS,RP0
or MOVWF 0x05. Imagine mistyping RP1 or 0x15. How many
hours would it take to find ? Hours that could have been spent
doing something constructive and not getting all pissed off and
frustrated. I really don't see how macros complicate things, I
really don't. Obviously YMdoesV

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

2004\02\12@173030 by Paul James E.

picon face
Jinx,

You have some good arguments.  As far as 'EQU' and 'DEFINES' are
concerned, I use them all the time.  I wouldn't write a program
unless I did.  Unless it was very small, but then again?

But concerning 'MACROS', I just haven't found them to help me in
any constructive way.  So therefore, I just don't use them.

As far as you using them, I have no problem with that.  If they help
you out, then so be it.  But they just aren't for me.  And in case
you're wondering, yes I have tried them many times, but to me they
seem to be more bother than they're worth.

I have written many program for PICs where I work.  Some as far
back as 6 yesra ago. And there have been a few different people
that need to maintain the code, but I have yet to have someone come
to me and ask what the code does or how is it supposed to work.
Because I document well throughout the code, and write in a straight
forward way without using macros, I have achieved code that is readable,
maintainable, and performs as it was designed to do, and everyone is happy.

But I take your points seriously.   Maybe I'll try macros again, just
to see if my writing style or attitudes have changed.   I'll keep you
posted either way.

TTYL,

                                            Thanks and Regards,

                                                   Jim


{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

2004\02\12@173618 by Wouter van Ooijen

face picon face
>  Because I document well throughout the code, and write in a straight
>  forward way without using macros, I have achieved code that
> is readable, maintainable, and performs as it was designed to do, and
> everyone is happy.

I won't argue with you 'writing code that is readable ...', but I don't
agree that it has anything to do with not using macros, except maybe in
the sense that you and macros don't match, so without macros *you* are
simply more comfortable and hence write better code. When I use
assembler I lean heavily on macros. The limitations of macros in MPASM
were one of the reasons for me to abandon assembler an write a compiler
:)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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

2004\02\12@182504 by Olin Lathrop

face picon face
Paul James E. wrote:
> Maybe I'll try macros again, just
> to see if my writing style or attitudes have changed.

If you want to get a head start on macros, check out the file STD.INS.ASPIC
at http://www.embedinc.com/pic.  It's about 4000 lines of mostly macros that
I find useful in creating well written PIC projects.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
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

2004\02\12@182712 by Olin Lathrop

face picon face
Wouter van Ooijen wrote:
> The limitations of macros in
> MPASM were one of the reasons for me to abandon assembler an write a
> compiler :)

I agree.  The macro facility in MPASM is pretty primitive.  However, it's
still better than no macros and useful macros can be written.  My approach
was to write a preprocessor to add the features I really wanted but couldn't
have with native MPASM.  For details, see the PREPIC documentation at
http://www.embedinc.com/pic.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
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

2004\02\12@190040 by Jinx

face picon face
> Because I document well throughout the code, and write in a
> straight  forward way without using macros, I have achieved
> code that is readable, maintainable, and performs as it was
> designed to do, and everyone is happy

And you can't argue with happy ;-)

Just to be clear, no one would get on a high horse trying to tell you
that you don't know what's good for you. I have a comfort zone too.
The major benefits for me using macros are (1) reduces typos
(2) quicker to write code and (3) no or less time spent debugging
sections that are done deals (IF you have been careful)

I find _simple_ macros particularly useful. MOVFW for example

movfw    macro   litval
        movf    litval,w
        endm

I have been known to type something like movf temp,f when I meant
movf temp,w. We've all done it. It's very very easy to overlook this
during debugging. Using movwf temp is much more informative from
that point of view. As a result I now spend more time optimising
functionality (which is important) rather than looking for typing errors
(which is annoying and always ends up with a self-kicking). And that
makes ME happy ;-)

> As far as 'EQU' and 'DEFINES' are concerned, I use them all the
> time.  I wouldn't write a program unless I did.  Unless it was very
> small, but then again ?

I have some small 68HC705 test programs, very old code, pre-PIC,
that I didn't bother to use defines for. As part of a HDD clean-up last
week I looked through them. Hardly had a clue what they were for

          bset 4,0
          nop
          bclr 4,0
          nop
          bclr 1,0
          nop
          bset 1,0

Hmmm, what did that do again ? Up to the port comments, down
to the code, up to the comments for the next lot..........

If I'd originally defined them as reset4040 and clock4040 I'd have
saved 10 minutes last week. It's all so obvious when you're in the
groove, but don't see it for a while and you'd be just as clueless
as anyone

But I think I'm flogging a dead (high) horse ;-)

--
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

2004\02\12@210444 by Jim Tellier
picon face
I've been following this thread for a bit, and I don't think anyone's
mentioned one of the pitfalls of using macros that seems to "bite"
assembly-code writers rather frequently:
(forgive me if this is redundant!)
The scenario in which you inadvertently use a "skip" instruction of some
kind, 'around' a macro instance that generates multiple instructions.
Depending on the style of your macro definitions, and how closely they
syntactically resemble actual mnemonics, bugs like this can be very tricky
to find.  True, you can usually zero right in if you're "simulating" the
code, but (as Murphy would have his way) for some reason these usually
manifest themselves in "critical" code that you can only execute in "real,
live" context.
 I'm not adverse to using macros myself, btw.   Just wanted to point out
that this is an area in which you need to be more diligent.

Jim

{Original Message removed}

2004\02\12@212142 by Jinx

face picon face
> The scenario in which you inadvertently use a "skip" instruction
> of some kind, 'around' a macro instance that generates multiple
> instructions

Good point. I hinted at that by saying "(3) no or less time spent
debugging sections that are done deals (IF you have been careful)"

However, there are so many things that can go wrong when coding.
If one doesn't get you, another will. And it's always our own fault. The
PIC only does what it's told to

Skips are probably the most obvious to watch for, and GOTO $x
too. Not such a good idea for portability into or out of the 18 series
(because of the two-word architecture) either, although I am guilty
of doing it. But generally only on projects that were designed for a
particular PIC and will more than likely stay in that PIC. Skips and
jumps should be made to labels, tidier

--
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

2004\02\13@032504 by Jan-Erik Soderholm

face picon face
Paul James E. wrote :

Paul, three quotes from your post :

>  But concerning 'MACROS', I just haven't found them to help me in
>  any constructive way.  So therefore, I just don't use them.

>  yes I have tried them many times, but to me they
>  seem to be more bother than they're worth.
>
>  Maybe I'll try macros again, just
>  to see if my writing style or attitudes have changed.

Now, I read this as you are only talking about writing
*your own* macros. Well, yes, that is one side of the macro
storry. But then other side is as important,  using ready made
macros builtin in some development environment, such
as MPASM or Olin's environment. IMHO, that is a rather
different storry.

And, I think this thread started with a builtin macro in
MPASM, didn't it ?

I've been using Olin's stuff for some time, and it was
a jump start for me both into relocatable code, the interrupt
model in the 18-series and structured PIC programming
in general. I havn't studied every macro in detail, but hope
that they'll work "as advertised"...

And, if someone else wold like to "read" my code, I can just
(besides of my comments/docs) refer to Olin's descriptions
of his envir/macros. Or the MPASM help file for the builtin
macros available there.

So, my point is that macros isn't only about writing *your
own* macros. *I* havn't written a single macro myself, but
*use* them a lot.

Regards
Jan-Erik.

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

2004\02\13@034617 by Wouter van Ooijen

face picon face
> The scenario in which you inadvertently use a "skip"
> instruction of some kind, 'around' a macro instance
> that generates multiple instructions.

Below is a mcro from my ZPL bootloader (yes, I do sometimes use
assembler!). Debug_Show_N is a another (multiple instruction) macro.

STOPZ  MACRO Value
  #ifdef DEBUG
     LOCAL stop, no_stop
     BZ stop
     BRA no_stop
stop
     Debug_Show_N Value
no_stop
  #else
     BZ $
  #endif
  ENDM

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2004\02\13@034620 by Wouter van Ooijen

face picon face
> My approach was to write a preprocessor to add the
> features I really wanted but couldn't have with native MPASM.

my preprocessor is called Jal :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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 2004 , 2005 only
- Today
- New search...