Post by thread:[PIC]: What am I doing wrong?

Hello, I am just trying to make a 16F877 do anything. Blink LEDs for all I care, but I am having no luck... Here is the code... ;====== XMTR.ASM ======================================== 2/08/02 ====== list p=16f877 radix hex ;-----= CPU EQUATES =--------------------------------------------------- tmr0 equ 0x01 status equ 0x03 porta equ 0x05 portb equ 0x06 portc equ 0x07 portd equ 0x08 porte equ 0x09 pclath equ 0x0a intcon equ 0x0b trisa equ 0x85 trisb equ 0x86 trisc equ 0x87 trisd equ 0x88 trise equ 0x89 adcon1 equ 0x9f rp0 equ 5 rp1 equ 6 ;-----= BIT EQUATES & VARIABLES =--------------------------------------- ;-----= PROGRAM =------------------------------------------------------- org 0x000 ; bcf status, rp0 bcf status, rp1 ; bsf status, rp0 movlw b'00000111' movwf adcon1 ; movlw b'00000000' movwf trisb ; bcf status, rp0 ; start nop clrf portb loop incf portb, f nop nop nop nop goto loop end VCC --- | / \ / \ | --- \ / V --- | ==PORT== As simple as that. I have it set to RC with a 10k and .1uF. On a scope RB 0-3 is changing but RB 4-7 isn't doing a thing, and when I connect an LED like in the diagram the PIC stops oscillating. What are the correct settings for the FUSES? -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Rather than writing out all the EQUs try using the INC file The fuses can be set as follows: As far as I understand it, portA A/D settings are only important if you're using portA. We're not so it doesn't matter. I've trimmed the code a bit. This *should* work if you paste it into MPLAB and adjust the tabs :) include "p16f877.inc" list p=16f877 __CONFIG _CP_OFF & _DEBUG_OFF & _WRT_ENABLE_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _PWRTE_OFF & _WDT_OFF & _RC_OSC ;-----= PROGRAM =------------------------------------------------------- bcf STATUS, RP1 ; into page 1 bsf STATUS,RP0 ; movlw b'00000000' ; set port B to output movwf TRISB bcf STATUS,RP0 ; then back to page 0 start clrf PORTB ; make sure portB is off loop incf PORTB,F nop nop nop nop goto loop END -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

James Burkart wrote: {Quote hidden}> > ;-----= PROGRAM =------------------------------------------------------- > org 0x000 > ; > bcf status, rp0 > bcf status, rp1 > ; > bsf status, rp0 > movlw b'00000111' > movwf adcon1 > ; > movlw b'00000000' > movwf trisb > ; > bcf status, rp0 > ; > start nop > clrf portb > > loop incf portb, f > nop > nop > nop > nop > goto loop > > end Put this is your code instead of your setup code... clrf PORTA clrf PORTB clrf PORTC clrf PORTD clrf PORTE bsf STATUS,RP0 clrf TRISA clrf TRISB clrf TRISC clrf TRISD clrf TRISE movlw b'00000111' movwf ADCON1 bcf STATUS,RP0 All the port pins other than RB are floting inputs which can cause lots of headaches. The data books specify C values as pF not nF as you are using. Whether there is a reason for this I don't know. Try 300pF and 100K for Fosc = 28KHz. You will still need to slow your loop down to see all the LEDs change state. Try this for your fuse setting. Make sure it appears only on one line in your source code. ; ; ------------------ ; CONFIGURATION FUSE ; ------------------ ; __CONFIG _CP_OFF & _WRT_ENABLE_OFF & _RC_OSC & _WDT_OFF & _PWRTE_OFF & _BODEN_OFF & _LVP_OFF & _CPD_OFF & _DEBUG_OFF -- Best regards Tony mICros http://www.bubblesoftonline.com salesKILLspambubblesoftonline.com -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu

Ok here is a shorter, well documented, version of the routine that I posted as "Writing data to a block of addresses using INDF" and it is still giving me hell. I will not write the data to Rx_Buffer + Rx_Num, it always write to Rx_Buffer. RX_INT_HANDLER BANK0 BTFSS RCSTA,OERR ; test if overrun bit is set PCALL RX_1 ; if overrun bit is not set then goto RX_1 BCF RCSTA,CREN ; if overrun bit is set then stop continuios receive BSF RCSTA,CREN ;reset error start continuios receive MOVF RCREG,0 ;dummy read CLRF Rx_Num ;clear Rx_Num MAD NOP RETURN RX_1 BANK0 ;TEST!! MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W ADDWF Rx_Num, W ;Add Rx_Num to W MOVWF FSR ;Place W (Rx_Buffer + Rx_Num) into FSR MOVF RCREG,W ;moves RCREG into W BCF STATUS,IRP ;Clears IRP , Bank0 MOVWF INDF ;copies W into INDF INCF Rx_Num, F ;Adds 1 to Rx_Num MOVF Rx_Num, W ;Moves Rx_Num to W XORLW D'16' ;XOR's W with 16 BTFSS STATUS,Z ;Checks if we are at 16 GOTO RX_1 ;If not keep reading BSF Os_Action,RX_CMD;Set RX_CMD to start RX_CMD Routine GOTO MAD ;Leaves routine Rx_Num is my pointer for the 16 Byte Bank of addresses that starts with Rx_Num. The Bank0 Maacro sets the IRP bit in the STATUS register, but I put it in the code any way and it is still not writing to the proper address. So let me know if you spot anything. Charles K Roberts II ORNL-SNS Project -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

On Friday 03 Oct 2003 9:19 pm, you wrote: {Quote hidden}> Ok here is a shorter, well documented, version of the routine that I > posted as "Writing data to a block of addresses using INDF" and it is > still giving me hell. I will not write the data to Rx_Buffer + Rx_Num, > it always write to Rx_Buffer. > > RX_INT_HANDLER > BANK0 > BTFSS RCSTA,OERR ; test if overrun bit is set > PCALL RX_1 ; if overrun bit is not set then goto > RX_1 > BCF RCSTA,CREN ; if overrun bit is set then stop > continuios receive > BSF RCSTA,CREN ;reset error start continuios receive > MOVF RCREG,0 ;dummy read > CLRF Rx_Num ;clear Rx_Num > MAD NOP > RETURN > RX_1 > BANK0 ;TEST!! > MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W > ADDWF Rx_Num, W ;Add Rx_Num to W Here is the problem. ADDWF adds W to the File not the file to W. After this line W still equals Rx_Buffer. Ian -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

Ian Bell <@spam@PICLISTKILLspammitvma.mit.edu> wrote: > > ADDWF Rx_Num, W ;Add Rx_Num to W > > Here is the problem. ADDWF adds W to the File not the file to W. > After this line W still equals Rx_Buffer. God, no. The ",W" means that the result of the addition goes to W; RxNum is unchanged. -Andy === Andrew Warren -- KILLspamaiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

> RX_1 > BANK0 ;TEST!! > MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W > ADDWF Rx_Num, W ;Add Rx_Num to W > MOVWF FSR ;Place W (Rx_Buffer + Rx_Num) into FSR > MOVF RCREG,W ;moves RCREG into W > BCF STATUS,IRP ;Clears IRP , Bank0 > MOVWF INDF ;copies W into INDF > INCF Rx_Num, F ;Adds 1 to Rx_Num > MOVF Rx_Num, W ;Moves Rx_Num to W > XORLW D'16' ;XOR's W with 16 > BTFSS STATUS,Z ;Checks if we are at 16 > GOTO RX_1 ;If not keep reading This loop will always flood the entire buffer with the received character. For values of RX_NUM less than 15, it will immediately go back and write the RCREG value into the next buffer location. Since there is no wait for the next character to be received, RCREG still contains the previous received character. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

>> MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W >> ADDWF Rx_Num, W ;Add Rx_Num to W > > Here is the problem. ADDWF adds W to the File not the file to W. > After this line W still equals Rx_Buffer. No, the sum will be in W and RX_NUM will be uneffected. Note that W was explicitly selected as the destination. That's what the ", W" is all about. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

-----Original Message----- From: Olin Lathrop [RemoveMEolin_piclistTakeThisOuTEMBEDINC.COM] Sent: Friday, October 03, 2003 5:11 PM To: PICLISTEraseME.....MITVMA.MIT.EDU Subject: Re: [PIC]: What am I doing wrong? >> RX_1 >> BANK0 ;TEST!! >> MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W >> ADDWF Rx_Num, W ;Add Rx_Num to W >> MOVWF FSR ;Place W (Rx_Buffer + Rx_Num) into FSR >> MOVF RCREG,W ;moves RCREG into W >> BCF STATUS,IRP ;Clears IRP , Bank0 >> MOVWF INDF ;copies W into INDF >> INCF Rx_Num, F ;Adds 1 to Rx_Num >> MOVF Rx_Num, W ;Moves Rx_Num to W >> XORLW D'16' ;XOR's W with 16 >> BTFSS STATUS,Z ;Checks if we are at 16 >> GOTO RX_1 ;If not keep reading > >This loop will always flood the entire buffer with the received character. >For values of RX_NUM less than 15, it will immediately go back and write >the RCREG value into the next buffer location. Since there is no wait for >the next character to be received, RCREG still contains the previous >received character. I thought that because I had continuios receive enabled that ot would constantly read RCREG. I was looking at the RCSTA register and I didn't see any bit that would let me know when the register had changed states. How do making sure that the next write is reading the new RCREG value?. -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestmitvma.mit.edu

On Friday 03 Oct 2003 10:15 pm, you wrote: > >> MOVLW Rx_Buffer ;Move Address of Rx_Buffer to W > >> ADDWF Rx_Num, W ;Add Rx_Num to W > > > > Here is the problem. ADDWF adds W to the File not the file to W. > > After this line W still equals Rx_Buffer. > > No, the sum will be in W and RX_NUM will be uneffected. Note that W was > explicitly selected as the destination. That's what the ", W" is all > about. > Woops. Ian -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestEraseMEEraseMEmitvma.mit.edu

> How do making sure that the next write is reading the new RCREG value? The RCIF bit in PIR1. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.mit.edu

> Rx_Num is my pointer for the 16 Byte Bank of addresses that > starts with Rx_Num. Wait for the"buffer full" flag before picking up the data btfss pir1,rcif goto $-1 movf rcreg,w ;clears rcif too, ready for next data You could use INCF FSR to increment the store address more directly. Would help to clean up some of the clutter. If FSR is being used somewhere else in the program just store it temporarily. You can do the limit test on FSR, you don't really need a second counter (Rx_num) until maybe nested loops. BTW it will help find or avoid ,W ,F mistakes if you drop the ,F (or ,1), it's the default AFAICT that routine "should" do what you intend if you wait for rcif (but I've had just the one coffee so far this morning !!) -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

> Wait for the"buffer full" flag before picking up the data > > btfss pir1,rcif > goto $-1 This is correct for 16 family PICs. Note that on 18 family PICs you need to do GOTO $-2. That's why I have the ADR_WORD constant customized per PIC family. GOTO $-adr_word always works. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestKILLspammitvma.mit.edu

Olin Lathrop wrote: > GOTO $-adr_word always works Hi Olin, I'm curious why this notation is still used by people for the operands of branches (long or short). I can see the temptation to use this style, but it appears to me it is an accident waiting to happen (as far as future code maintenance/modification is concerned), when a simple label will work. (Like when you add some ASM instructions in the future and forget to re-adjust the 'GOTO $-adr_word' part.) Is there a good reason to use this notation and possibly risk introducing a human error instead of using a label that automatically is adjusted by the assembler? Thanks for your input on this. Best regards, Ken Pergola -- http://www.piclist.com hint: To leave the PICList piclist-unsubscribe-requestSTOPspamspam_OUTmitvma.mit.edu

Ken Pergola wrote: > I'm curious why this notation is still used by people for the operands of > branches (long or short). > I can see the temptation to use this style, but it appears to me it is an > accident waiting to happen (as far as future code maintenance/modification > is concerned), when a simple label will work. > > (Like when you add some ASM instructions in the future and forget to > re-adjust the 'GOTO $-adr_word' part.) > > Is there a good reason to use this notation and possibly risk introducing > a human error instead of using a label that automatically is adjusted by > the assembler? Everything is a tradeoff. As you say, the label allows code to be inserted between the GOTO and the target without trouble. However, it also makes a maintenence programmer wonder where all the jumps to the label come from. I think the relative GOTO is useful in decreasing clutter and avoiding ambiguity when the GOTO is to an adjacent instruction, maybe two instructions away at most (but preferably not). Anything further and I would definitely use a label. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestSTOPspamEraseMEmitvma.mit.edu

> > GOTO $-adr_word always works > (Like when you add some ASM instructions in the future and > forget to re-adjust the 'GOTO $-adr_word' part.) For loops that won't ever change, eg the rcif test, I'm quite happy using GOTO $ or BRA $. For anything longer, like a short routine where code code be inserted later, a label is better. Even if you don't add code, porting from a 12- or 14- to a 16-bit device can be trouble, looping around a CALL for example, if GOTO $ is used. I do agree, jumping to a label makes more sense, but you know, you get comfy and busy... -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Hi Olin, Thanks for your input on this. Yes, I see how it can be pretty safe if you know for sure the branch offset is only one adjacent instruction away. I thought people must have had good reasons to use this method. I know this is nothing new -- I've seen this in the days of Z-80 assembly language and I'm sure it goes back possibly to the very early days of assembly language programming, but I'll stop here -- no need for this thread to go off topic. Thanks again for your insight -- I appreciate it. Best regards, Ken Pergola -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestEraseMEmitvma.mit.edu

Ken Pergola <@spam@PICLIST@spam@spam_OUTmitvma.mit.edu> wrote: > > GOTO $-adr_word always works > > Hi Olin, > > I'm curious why this notation is still used by people for the > operands of branches (long or short). I can see the temptation to > use this style, but it appears to me it is an accident waiting to > happen (as far as future code maintenance/modification is > concerned), when a simple label will work. Ken: I know you asked for Olin's opinion, but I'll give you mine while you're waiting. All of the following is for one-word-per-instruction PICs; if I used PIC18s, I'd probably #define NEXT $+2 and #define PREVIOUS $-2. For jumping forward, I only do GOTO $+1, in order to get a two-cycle NOP. Any other forward jump has a label as its destination. For jumping backward, I use GOTO $-1 and GOTO $-2, but never use that form for looping backward more than 1 or 2 lines. I also almost never use it for anything other than polling a single signal; $-1 is for loops that don't include CLRWDT, and $-2 is for loops that unavoidably do. In those cases, the GOTO is so close to the top of the loop that there's no chance that I'll insert instructions in the loop without seeing that the GOTO has to change. Also, those loops never need any additional code additions, anyway; if the function of the loop changes from polling one signal to something more complex, that change warrants adding a label at the top of the loop to document what the loop does. -Andy === Andrew Warren -- spamBeGoneaiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- http://www.piclist.com hint: To leave the PICList .....piclist-unsubscribe-requestspam_OUTmitvma.mit.edu

Hi Jinx, Thanks for your take on this as well -- I just saw Olin's response. I have never used that style, but I can see how if you are very careful it can work well. I personally make enough coding mistakes so I prefer to leave as much "thinking" to the assembler. We all have our methods of doing things. :) Take care, Ken Pergola -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-request.....TakeThisOuTmitvma.mit.edu

Hi Andy, Thanks for your time and input. What's making me laugh about this thread is that it is just emphasizing to me why computer science is almost like voodoo. And I don't mean that to insult anyone here -- I would never do that on purpose. Programmers have to be absolutely correct on our code mnemonics and syntax, etc., but unfortunately us programmers can get away with being vastly different in our processes. (I wish my C++ course used Code Complete by Steve McConnell in addition to the regular C++ textbook.) Reminds me of the great article in Embedded System Programming by Jack Ganssle which is great reading for PICsters as well: Bailing frantically ------------------- What's the secret to delivering good code fast? The same thing that makes McDonald's hamburgers ubiquitous: process, process, process. by Jack Ganssle http://www.embedded.com/showArticle.jhtml?articleID=14704729 (Note: Above URL may be word-wrapped -- just pick up the pieces if it does) Take care Andy, Ken Pergola -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu