maybe this willhelp someone help me on thjis. I took a look at the JAL prog= ram and apparently during the build it creates a *.asm file that looks li= ke assembly code. At the beginning of the code it has the following: ; note: the f877 config is still fixed! __CONFIG H'3F32'=20 ORG 0000 goto __main ORG 0004 ORG 0004 __interrupt: ; 0004 __main: ; 0004 ; var H'020:000' transfer_bit ; var H'020:000' transfer_byte ;; 040 : var volatile byte status at 3 ; var H'003:000' status I don't understand this but maybe it will help shed some "light" on the pro= blem. also I know it states a 16f877 but it does work on this 16f876. Thanks again !!! -----Original Message----- From: Richard S To: PICLIST@MITVMA.MIT.EDU Date: Tue, 9 Mar 2004 17:16:06 -0500 Subject: Re: [PIC:] Newbie trying to assemble using MPASM for 16f876 Good catch. I used the code supplied to light all led's on port b had to ch= ange the x'hh' to h'ff' lucky guess but my first sucessful debug :-)) All LED's work except the one on port RB3 ( this is pin24 and is a shared f= untion with PGM). It is counting all the way up. Only way to reset to zer= o is reflash POR does not reset to zero. I have a program written in JAL that does work just fine for RB3 so it does= work just not with the counter you are all helping me with. I expect the= problem has to do with the shared function with PGM but I really have no= idea. I disconnected my wisp628 in circuit programmer but the LED on RB3= still does not light. Any ideas ??? -----Original Message----- From: Jan-Erik Soderholm To: PICLIST@MITVMA.MIT.EDU Date: Tue, 9 Mar 2004 21:55:20 +0100 Subject: Re: [PIC:] Newbie trying to assemble using MPASM for 16f876 Richard S wrote : > I gave this change a try. The system still counts to 111 then > either resets or rolls back over to 000 in an endless loop. But that is what you see on the LED's right ? Can you make some simple change to you code just to verify that you can lit up the other LEDs at all ? What I'm trying to say is that, maybe the system *do* count as it should, it just don't show on the LEDs. > Good thing is I think you just taught me how to name a > register. Use that name and tranfer data from one register to > another using W as the intermediary. :-)) The reason fpr this change, is that you should generally speaking be carefull with any "read-modify-write" instruction on the PORTx registers. As an example, the INCF instruction must first read whatever the PORTx reg is, increment the value and at last write the incremented value back to the PORTx register. On the other hand, a MOVWF instruction just writes to the PORTx reg (the read is done from the W regsiter). The problem with reading from the PORTx registers (without going into to much detail) is that you can (sometimes) not be sure that what you read, is what you wrote last time. Details in the docs, and it's a very well know "gotcha"... The standard cure is to keep a "shadow" register (portb_tmp in this case), then do any modifications on this register, and at last only *write* to the PORTx register using e.g. MOVWF. What I would do now, is to modify the code a little to verify that all 8 LED's actualy are working and are "settable" from the code. Something like : movlw x'hh' ; All "1" movwf portb : Send to portb loop goto loop ; Endless loop This should lit up all LEDs, I think. Jan-Erik. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.