Post by thread:16f877 porta blues

Hello All, I am porting some 16f84 code to a shiny, new 16f877 in the new IDE i got for my birthday. I am having trouble getting porta to work as digital I/O. Here is the snip: list p=16F877 __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC ;&_LVE_OFF<--hates this include "P16F877.INC" beep_pin equ 3 ;----------------------------------------- nop ;for use by ide ORG 0 ;Reset Vector ORG 4 ;Interrupt bsf STATUS,RP0 clrf PORTC ;portc set output movlw b'00000001' movwf PORTA movlw B'00000110';.6--magic number movwf ADCON1 ;??? ;TURN OFF ADC bcf STATUS,RP0 CLRF PORTA movlw b'00001000' movwf porta ;no beep here The watch window shows that adcon1 is set as instructed, and the porta pins set as instructed, but there is no voltage on the led when i run the program on the chip under debug, and it does not detect the input on porta,0. im confused. Can anyone see where i fell off the bus? thanks, alice

part 0 6949 bytes Alice, Shouldn't it be       bsf     STATUS,RP0         clrf    PORTC           ;portc set output         movlw   b'00000001'         movwf   TRISA   ******* Steve Steven Kosmerchock Father/Student/Engineering Technician http://www.geocities.com/researchtriangle/lab/6584 "Great spirits have always encountered violent oppposition from mediocre minds."--A.Einstein {Original Message removed}

Hi Alice, 1. try changing the LVE to LVP. 2. is porta defined anywhere? the p16f877.inc file only has PORTA defined 3. are you doing a trisa and trisc someplace else? don't forget to change pages. Bill At 12:08 AM 4/13/00 PST, you wrote: {Quote hidden}>Hello All, > >I am porting some 16f84 code to a shiny, >new 16f877 in the new IDE i got for my >birthday. I am having trouble getting >porta to work as digital I/O. Here is the >snip: > > list p=16F877 > __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC >;&_LVE_OFF<--hates this > include "P16F877.INC" >beep_pin equ 3 >;----------------------------------------- > nop ;for use by ide > ORG 0 ;Reset Vector > ORG 4 ;Interrupt > bsf STATUS,RP0 > clrf PORTC ;portc set output > movlw b'00000001' > movwf PORTA > movlw B'00000110';.6--magic number > movwf ADCON1 ;??? ;TURN OFF ADC > bcf STATUS,RP0 > CLRF PORTA > movlw b'00001000' > movwf porta ;no beep here > > >The watch window shows that adcon1 is set >as instructed, and the porta pins set as >instructed, but there is no voltage on the >led when i run the program on the chip >under debug, and it does not detect the >input on porta,0. > >im confused. Can anyone see where i fell >off the bus? > >thanks, >alice >

On Thu, 13 Apr 2000, Alice Campbell wrote: {Quote hidden}> Hello All, > > I am porting some 16f84 code to a shiny, > new 16f877 in the new IDE i got for my > birthday. I am having trouble getting > porta to work as digital I/O. Here is the > snip: > > list p=16F877 > __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC > ;&_LVE_OFF<--hates this > include "P16F877.INC" > beep_pin equ 3 > ;----------------------------------------- > nop ;for use by ide > ORG 0 ;Reset Vector > ORG 4 ;Interrupt > bsf STATUS,RP0 > clrf PORTC ;portc set output > movlw b'00000001' > movwf PORTA > movlw B'00000110';.6--magic number > movwf ADCON1 ;??? ;TURN OFF ADC > bcf STATUS,RP0 > CLRF PORTA > movlw b'00001000' > movwf porta ;no beep here > Since I think I know where you got this code (or at least portions of it ;) let me go on the defensive and say that it is okay. Well, maybe it is. Recall that the f877 has four register banks. PORTA and TRISA share the same lower seven bits. Since only the lower 7 bits are decoded (or assembled) then specifying TRISA or PORTA as the source or destination for a file register related instruction will produce the same result. So the only thing that could cause the above code to fail is if RP1 is set. So you may wish to try: bcf STATUS,RP1 before the other stuff. You can make the changes to TRISA and TRISC registers if you want and just either ignore the warnings produced or mask them out like Paul recommends in every 10th post he makes. Incidently, the TRIS instruction AFAIK is available on the f877 (at least it is in gpsim). A quick glance at the data sheet shows that it isn't. Does anyone know for sure if the TRIS instruction is available for the f877? Scott

hmm, good thought. Now is there a nice way to terminate all those lines? i dug out some 10k sip resistors, but of course the 40-odd pin connector on the mchip project board is not set up to plug them in directly, and i have to be careful with port b because of b3, b6,and b7.. Is there an easy way to terminate all the loose lines without doing something to the project board i will regret later when it comes time to tear it out? a. {Quote hidden}> Alice Campbell wrote: > > > > Hello All, > > bsf STATUS,RP0 > > clrf PORTC ;portc set output > > movlw b'00000001' > > movwf PORTA > > movlw B'00000110';.6--magic number > > movwf ADCON1 ;??? ;TURN OFF ADC > > bcf STATUS,RP0 > > CLRF PORTA > > movlw b'00001000' > > movwf porta ;no beep here > > Don't forget all the unused port pins will be floating. This can cause > ugly problems when your projects get more complicated. > > I had 1 single pin floating out of 78 possible PIC pins (4 PICs) in the > virtual car project and it caused the system to crash intermittantly. > Very hard to track down |:-( > > -- > Best regards > > Tony > > http://www.picnpoke.com > .....salesKILLspam@spam@picnpoke.com

Alice wrote: .... >hmm, good thought. Now is there a nice way to terminate all >those lines? i dug out some 10k sip resistors, but of course >the 40-odd pin connector on the mchip project board is not >set up to plug them in directly, and i have to be careful >with port b because of b3, b6,and b7.. >Is there an easy way to terminate all the loose lines without >doing something to the project board i will regret later when >it comes time to tear it out? sip socket with sip R in the socket. ================= .... {Quote hidden}> > list p=16F877 > __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC >;&_LVE_OFF<--hates this > include "P16F877.INC" >beep_pin equ 3 >;----------------------------------------- > nop ;for use by ide > ORG 0 ;Reset Vector > ORG 4 ;Interrupt > bsf STATUS,RP0 > clrf PORTC ;portc set output > movlw b'00000001' > movwf PORTA > movlw B'00000110';.6--magic number > movwf ADCON1 ;??? ;TURN OFF ADC > bcf STATUS,RP0 > CLRF PORTA > movlw b'00001000' > movwf porta ;no beep here > Am I missing something here, or is this code supposed to be located inside the ISR space? [I suppose no interrupts?] Also, what did you do with ADCON0? [I suppose it doesn't matter here]. I realize there are POR values in all the regs, but I always like to initialize critical regs myself anyway [option, interrupt, A/D, etc] - lots easier to modify them to expand the code later, and also you don't have to remember what they POR to. Also, is this all there is? Never tried a program that just falls off the end of the PIC, usually put in an infinite loop at end. L1 goto L1

> Alice wrote: > .... > >hmm, good thought. Now is there a nice way to terminate all > >those lines? i dug out some 10k sip resistors, but of course > >the 40-odd pin connector on the mchip project board is not > >set up to plug them in directly, and i have to be careful > >with port b because of b3, b6,and b7.. > >Is there an easy way to terminate all the loose lines without > >doing something to the project board i will regret later when > >it comes time to tear it out? > > sip socket with sip R in the socket. > ================= ok. i have cut in half a 40-pin dip gold-plated machine pin socket and the two halves just fit in the breakout area. {Quote hidden}> > .... > > > > list p=16F877 > > __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC > >;&_LVE_OFF<--hates this > > include "P16F877.INC" > >beep_pin equ 3 > >;----------------------------------------- > > nop ;for use by ide > > ORG 0 ;Reset Vector > > ORG 4 ;Interrupt > > bsf STATUS,RP0 > > clrf PORTC ;portc set output > > movlw b'00000001' > > movwf PORTA > > movlw B'00000110';.6--magic number > > movwf ADCON1 ;??? ;TURN OFF ADC > > bcf STATUS,RP0 > > CLRF PORTA > > movlw b'00001000' > > movwf porta ;no beep here > > > > Am I missing something here, or is this code supposed to be > located inside the ISR space? [I suppose no interrupts?] > Also, what did you do with ADCON0? [I suppose it doesn't > matter here]. I couldnt see that it was required if the port is I/0. I tried putting a token one in, and it didnt make any difference. Well, if you want to be accurate, i initially confused ADCON0 with ADCON1 and took awhile to sort that out. > > I realize there are POR values in all the regs, but I always > like to initialize critical regs myself anyway [option, interrupt, > A/D, etc] - lots easier to modify them to expand the code later, > and also you don't have to remember what they POR to. > This sounds sensible. Also, it will require that i actually figure out if there are any POR settings i will regret BEFORE wasting time trying to track them down afterwards. > Also, is this all there is? Never tried a program that just > falls off the end of the PIC, usually put in an infinite loop > at end. > > L1 goto L1 Well, you dont want all the gory details, but it is part of a bigger program that isnt working on a 16f84, and is my first attempt to port to a 16f877 to debug. eventually, there is an end statement, and lots besides, including a very nice beep routine that takes the 8-bit adc reading and uses it to vary the frequency of the piezo so it tonally follows the adc input. but until i get porta going, it isnt very fun. as you know much better than me, the 877 is a lot more complicated than the f84. alice

Alice wrote: >> >> sip socket with sip R in the socket. >> ================= >ok. i have cut in half a 40-pin dip gold-plated machine pin >socket and the two halves just fit in the breakout area. > You can buy sip socket thingies too - for next time. Saves ruining a $2.50 socket. ===================. {Quote hidden}>> >> .... >> > >> > list p=16F877 >> > __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC >> >;&_LVE_OFF<--hates this >> > include "P16F877.INC" >> >beep_pin equ 3 >> >;----------------------------------------- >> > nop ;for use by ide >> > ORG 0 ;Reset Vector >> > ORG 4 ;Interrupt >> > bsf STATUS,RP0 >> > clrf PORTC ;portc set output >> > movlw b'00000001' >> > movwf PORTA >> > movlw B'00000110';.6--magic number >> > movwf ADCON1 ;??? ;TURN OFF ADC >> > bcf STATUS,RP0 >> > CLRF PORTA >> > movlw b'00001000' >> > movwf porta ;no beep here >> > >> >> Am I missing something here, or is this code supposed to be >> located inside the ISR space? [I suppose no interrupts?] >> Also, what did you do with ADCON0? [I suppose it doesn't >> matter here]. > >I couldnt see that it was required if the port is I/0. >I tried putting a token one in, and it didnt make any difference. >Well, if you want to be accurate, i initially confused ADCON0 >with ADCON1 and took awhile to sort that out. > I always have a subroutine that initializes all the critical regs, that can be called whenever need to re-init. Also, I declare the init values as constants at the beginning of the program, and then don't have to search all over to figure out the values inside. ; ------ Initial Register Values ----------- BANK0 = 0h ; slct bank 0. BANK1 = 60h ; " " 1. OPT_DEF = .... AD0_DEF = b'00000000' AD1_DIGI = b'00000110' ; set RA channels to all digital. AD1_ANA = b'00000000' ; " " " " " analog. DIRA_DEF ... PRTA_DEF DIRB_DEF ; zero_state - set cpu to zero state. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; zero_state ; init bank 1 regs. movlw BANK1 movwf STATUS movlw OPT_DEF movwf OPTION ; init bank 0 regs. movlw BANK0 movwf STATUS movlw AD1_DIGI movwf ADCON1 movlw AD1_DEF movwf ADCON1 .... return ====================== >> I realize there are POR values in all the regs, but I always >> like to initialize critical regs myself anyway [option, interrupt, >> A/D, etc] - lots easier to modify them to expand the code later, >> and also you don't have to remember what they POR to. >> >This sounds sensible. Also, it will require that i actually >figure out if there are any POR settings i will regret BEFORE >wasting time trying to track them down afterwards. > Bingo. =============== >> Also, is this all there is? Never tried a program that just >> falls off the end of the PIC, usually put in an infinite loop >> at end. >> >> L1 goto L1 > >Well, you dont want all the gory details, but it is part of a >bigger program that isnt working on a 16f84, and is my first >attempt to port to a 16f877 to debug. eventually, there is an .... >alice > I'm sure you've heard the following before, but .... <KEY FACTOR> When learning a new processor, I **always** write the simplest possible program first [ equiv of printf("hello world"); ] get it working, then build on that. If trying to adapt a program from another processor, you can just grab the very simplest stuff into program TEST1.ASM, and throw everything else away. Once TEST1 works, then insert it into the original, or start adding modules back into it. </KEY FACTOR> When building new programs, build up as small modules, patched together to do bigger things. Avoid spaghetti code of infinite goto's, try to do it as small callable modules. Test small modules in isolation, then link together and test that. As Wouter wrote - test, test, test, test, .... ============= BTW, you did remap the start of data memory, didn't you?

s'OK. Last nights experiments with new socket revealed that i had the breakout area pinout flipped by 180 deg. Blinkie blinks. It turns out that all the variatons for initialization work, even the old tris porta(as long as rp0 is NOT simultaneously cleared) So i'm back out of the ditch, and back to the original problem which is still patiently waiting for me, but now i am armed with a much better strategy for initilization of ports and breaking in new processors. time to fry more parts.... alice {Quote hidden}> I wrote: > > ; zero_state - set cpu to zero state. > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > zero_state > ; init bank 1 regs. > movlw BANK1 > movwf STATUS > movlw OPT_DEF > movwf OPTION > movlw AD1_DIGI > movwf ADCON1 > ; init bank 0 regs. > movlw BANK0 > movwf STATUS > movlw AD0_DEF > movwf ADCON0 > .... > return > > OOOPs, pay no attention whatsoever to any/all possible errors > in the code example from last time. ADCON1 is in bank 1, etc. > It was supposed to represent form [not necessarily work right]. > > [need to reread this stuff before pressing the send button > so fast - where's that paddle?].

Scott Dattalo wrote: (Obsequious comments glossed over) > Incidently, the TRIS instruction AFAIK is available on the f877 (at > least it is in gpsim). A quick glance at the data sheet shows that it > isn't. Not so. In fact, the opposite, but oh, so subtly. In all 14-bit series parts, TRIS and OPTION aren't confessed in the instruction set tabulation, but appear with the bizarre petulant "warnings" about the possibility of non-compatible vapourware in the imagined future; in the detailed instruction descriptions. It gets worse! I just browsed DS35007A-page 33 (PIC16F84A), which contains the apocryphal: "Note: To maintain upward compatibility with future PIC16CXXX products, do not use the OPTION and TRIS instructions." Since this document does *not* contain the full instruction description, (refers rather to DS33023) it certainly doesn't help you to understand TRIS and OPTION, *however*, and I have to laugh, because on page 32 it contains the every-bit-as-sensible advice: "Note: Microchip does not recommend code protecting windowed devices." I really think that says it all. To remain on track however (forever difficult), the PIC16F87X datasheet DS30292A contains the admonishment about TRIS and OPTION, which de facto *confirms* that they are there. I really wonder why on these parts they *didn't* remove that functionality. Is it because they actually wouldn't *dare* present a blatantly sub-functional part to an ever more discerning market (notably: this list)? Presumably however they employed a knowledgeable proof-reader on this occasion, as the comment about windowed devices has been edited out. Tony Nixon wrote: > I had 1 single pin floating out of 78 possible PIC pins (4 PICs) in > the virtual car project and it caused the system to crash > intermittantly. Very hard to track down |:-( Oh, so *that's* how it happened! :) Alice Campbell wrote: > hmm, good thought. Now is there a nice way to terminate all > those lines? My goodness, how soon these things are forgotten (overlooked)! Are we not discussing embedded *programming*? ;-) Be a programmer; terminate them in *software* (make them outputs, set them low, or port B has pull-ups). -- Cheers, Paul B.

On Sat, 15 Apr 2000, Paul B. Webster VK2BZC wrote: > Scott Dattalo wrote: > > (Obsequious comments glossed over) You know, I didn't have to look that word up since I just learned it a couple of days ago! (But how do you pronounce the damn thing? :) {Quote hidden}> > > Incidently, the TRIS instruction AFAIK is available on the f877 (at > > least it is in gpsim). A quick glance at the data sheet shows that it > > isn't. > > Not so. In fact, the opposite, but oh, so subtly. > > In all 14-bit series parts, TRIS and OPTION aren't confessed in the > instruction set tabulation, but appear with the bizarre petulant > "warnings" about the possibility of non-compatible vapourware in the > imagined future; in the detailed instruction descriptions. > > It gets worse! I just browsed DS35007A-page 33 (PIC16F84A), which > contains the apocryphal: "Note: To maintain upward compatibility with > future PIC16CXXX products, do not use the OPTION and TRIS instructions." > > Since this document does *not* contain the full instruction > description, (refers rather to DS33023) it certainly doesn't help you to > understand TRIS and OPTION, *however*, and I have to laugh, because on > page 32 it contains the every-bit-as-sensible advice: "Note: Microchip > does not recommend code protecting windowed devices." > > I really think that says it all. > > To remain on track however (forever difficult), the PIC16F87X > datasheet DS30292A contains the admonishment about TRIS and OPTION, > which de facto *confirms* that they are there. I really wonder why on > these parts they *didn't* remove that functionality. Is it because they > actually wouldn't *dare* present a blatantly sub-functional part to an > ever more discerning market (notably: this list)? I don't think they'll ever get rid of them. Perhaps they should abandon the useless warnings... The good news is that I know there's one less bug in gpsim. Scott

re: TRIS and OPTION Instructions The problem I have with these is that we have been warned for years not to use them. Though CVASM, MPASM, and apparently GPxxx, still support them, I think it's best to just set RP0 (and clear RP1 if appropriate) to setup the OPTION and TRISx registers. Then there is the problem of switching to a 40-pin device where the TRIS instruction doesn't work with Ports D and E... At 08:39 PM 4/15/00 -0500, Scott Dattalo wrote: >On Sat, 15 Apr 2000, Paul B. Webster VK2BZC wrote: >> >> (Obsequious comments glossed over) > ^^^^^^^^^^ >You know, I didn't have to look that word up since I just learned it a >couple of days ago! (But how do you pronounce the damn thing? :) Well, I did... That's the first word that I have had to lookup the meaning to in `decades'. Geesh Paul, that's scary ;-) - Tom ------------------------------------------------------------------------ Tom Handley New Age Communications Since '75 before "New Age" and no one around here is waiting for UFOs ;-)