Post by thread:[PIC:] Reading PortA on 16F877

-----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_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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}>From: "Aubrey McIntosh, Ph.D." <.....Aubrey.McIntoshKILLspam@spam@ALUMNI.UTEXAS.NET> >Reply-To: pic microcontroller discussion list <PICLISTKILLspamMITVMA.MIT.EDU> >To: .....PICLISTKILLspam.....MITVMA.MIT.EDU >Subject: [PIC:] Reading PortA on 16F877 >Date: Mon, 9 Feb 2004 10:32:23 -0600 > >-----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 EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body _________________________________________________________________ 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 listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

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}> -----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@listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

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 RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

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}> 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 spamBeGonelistservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> 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

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

> 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

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

> 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

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}

> 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

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.

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