Searching \ for '[PIC]: What am I doing wrong?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'What am I doing wrong?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: What am I doing wrong?'
2002\02\09@065411 by James Burkart

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


2002\02\09@193616 by Benjamin Bromilow

flavicon
face
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 .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\02\10@170842 by Tony Nixon

flavicon
picon face
James Burkart wrote:
{Quote hidden}

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

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu



'[PIC]: What am I doing wrong?'
2003\10\03@162309 by Roberts II, Charles K.
picon face
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_OUTspamTakeThisOuTmitvma.mit.edu

2003\10\03@164626 by Ian Bell

flavicon
face
On Friday 03 Oct 2003 9:19 pm, you wrote:
{Quote hidden}

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-requestspamspam_OUTmitvma.mit.edu

2003\10\03@170328 by Andrew Warren

flavicon
face
Ian Bell <@spam@PICLISTKILLspamspammitvma.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 -- KILLspamaiwKILLspamspamcypress.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-requestTakeThisOuTspammitvma.mit.edu

2003\10\03@171128 by Olin Lathrop

face picon face
> 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-requestspamBeGonespammitvma.mit.edu

2003\10\03@171537 by Olin Lathrop

face picon face
>>         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-requestEraseMEspamspam_OUTmitvma.mit.edu

2003\10\03@172408 by Roberts II, Charles K.

picon face
-----Original Message-----
From: Olin Lathrop [RemoveMEolin_piclistspamTakeThisOuTEMBEDINC.COM] Sent: Friday, October 03, 2003 5:11 PM
To: PICLISTEraseMEspam.....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-requestspammitvma.mit.edu

2003\10\03@173858 by Ian Bell

flavicon
face
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-requestEraseMEspamEraseMEmitvma.mit.edu

2003\10\03@175604 by Olin Lathrop

face picon face
> 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_OUTspamKILLspammitvma.mit.edu

2003\10\03@180438 by Jinx

face picon face
>        MOVLW   Rx_Buffer
>        ADDWF   Rx_Num, W
>        MOVWF   FSR
>
> > ADDWF adds W to the File not the file to W.
> > After this line W still equals Rx_Buffer.

FSR does = Rx_Buffer + Rx_Num

Maybe you're thinking of SUBLW (=SUBWL) ?

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu

2003\10\03@181058 by Jinx

face picon face
> 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-requestspamspamspamBeGonemitvma.mit.edu

2003\10\03@182926 by Olin Lathrop

face picon face
> 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-requestKILLspamspammitvma.mit.edu

2003\10\03@185634 by Ken Pergola

flavicon
face
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-requestSTOPspamspamspam_OUTmitvma.mit.edu

2003\10\03@192542 by Olin Lathrop

face picon face
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-requestSTOPspamspamEraseMEmitvma.mit.edu

2003\10\03@193618 by Jinx

face picon face
> > 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-requestspamBeGonespammitvma.mit.edu

2003\10\03@193823 by Ken Pergola

flavicon
face
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-requestspamEraseMEmitvma.mit.edu

2003\10\03@194031 by Andrew Warren

flavicon
face
Ken Pergola <@spam@PICLIST@spam@spamspam_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 -- spamBeGoneaiwspamKILLspamcypress.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_OUTspammitvma.mit.edu

2003\10\03@194442 by Ken Pergola

flavicon
face
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.....spamTakeThisOuTmitvma.mit.edu

2003\10\03@201146 by Ken Pergola

flavicon
face
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-requestKILLspamspamspammitvma.mit.edu

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...