Searching \ for 'Still got the serial blues!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'Still got the serial blues!'.

Truncated match.
PICList Thread
'Still got the serial blues!'
1998\06\08@224844 by

picon face
Hello

This serial buiness is kicking my tail. The routine runs smoothly sending all
5 bytes of data through the first loop. The second and ... time though I get
garbage. Somehow the FSR is getting corrupted or its doing what I've told it
to do only I don't know what I told it. Make sense? The variables are located
in sequential registers.  The data in the variable registers is correct in
simulation. Can any one tell me what is going on? Using 16F84

here is a snip- The serial routine is called every 7 instructions because of
multitasking.

SERIAL
       MOVF    SSTATE,W        ;PCL #161
       MOVWF   PCL             ; dispatch to current state
TEST:   BTFSC   _HANDSHAKE      ; CHECK FOR SERIAL HANDSHAKE
       GOTO    LOADSEROUT              ; PIN=1 INITIATE SEROUT COMM
       MOVLW   ZERO_1
       MOVWF   SSTATE
       GOTO    W9

LOADSEROUT:
       BTFSS   _HANDSHAKE
       GOTO    IDL7            ; FALSE START RECEIVER NOT READY WAIT AND
       MOVLW   BUFFER-1        ;BYTE TO SEND
       MOVWF   FSR
       MOVLW   5             ;how many bytes
       MOVWF   BUFFER          ;LOAD BYTE COUNTER
       MOVLW   XMIT            ;LOAD SEROUT
       MOVWF   SSTATE
       NOP
       RETURN
XMIT:
       MOVLW   9
       MOVWF   SCOUNT          ;LOAD BIT COUNTER
       MOVLW   EMITBIT         ; EMITBIT TO PCL
       MOVWF   SSTATE
       MOVLW   BITTIME
       MOVWF   STIME           ;LOAD BUAD DELAY
       BCF     _SEROUT         ;START BIT NON INVERTED
;       BSF     _SEROUT         ;START BIT INVERTED
       GOTO    W13
EMITBIT
       DECFSZ  STIME,F
       GOTO    W4              ;BAUD DELAY
       RRF     INDF            ;SHIFT RT
       DECFSZ  SCOUNT          ;BIT COUNTER
       GOTO    SEND_BITS       ;SEND MORE BITS
       RRF     INDF            ;8 BITS SENT- SHIFT TO ORIGINAL
       MOVLW   BITTIME
       MOVWF   STIME           ;LOAD BUAD DELAY
       MOVLW   STOPBIT         ; SEND STOP
       MOVWF   SSTATE
;       BCF     _SEROUT         ;START BIT INVERTED
       BSF     _SEROUT         ;START BIT NON-INVERTED
       NOP
       RETURN

SEND_BITS

;       BTFSC    _C             ; IF _C = 0, PC = PC+2--INVERTED
;       BCF      _SEROUT        ; BIT1 = 0
;       BTFSS    _C             ; IF BIT2 = 1, PC = PC+2
;       BSF      _SEROUT        ; BIT1 = 1
       BTFSS    _C             ; IF _C = 0, PC = PC+2--NON INVERTED
       BCF      _SEROUT        ; BIT1 = 0
       BTFSC    _C             ; IF BIT2 = 1, PC = PC+2
       BSF     _SEROUT         ; BIT1 = 1
       MOVLW   BITTIME
       MOVWF   STIME           ;LOAD BUAD DELAY
       RETURN

STOPBIT
       DECFSZ  STIME,F
       GOTO    W4              ;BAUD DELAY
       DECF    FSR             ;NEXT BYTE TO SEND
       DECFSZ  BUFFER          ;?SENT ALL BYTES
       GOTO    LOADBYTES       ;SEND MORE
       MOVLW   TEST            ;SKIP SERIN
;       MOVLW   LOADLOOP        ; START SERIN ROUTINE
       MOVWF   SSTATE
       GOTO    W10

LOADBYTES
       MOVLW   XMIT
       MOVWF   SSTATE
       GOTO    W11

; Waste cycles to make up 19 cycles including call and return.
W4      NOP
W5      NOP
W6      NOP
W7      NOP
W8      NOP
W9      NOP
W10     NOP
W11     NOP
W12     NOP
W13     RETURN

1998\06\09@050528 by Dennis Plunkett

flavicon
face
At 05:52 PM 8/06/98 EDT, you wrote:
{Quote hidden}

If you are not reloading the BUFFER data, then the data will be rotated, but
out by one bit. Does this help? And while I look at your code, I have to ask
the question (Multitasking), as you know that a byte/bytes have to be sent,
why not complete the byte sending before returning to the task loop?


Dennis


-=====================================================================-

Dennis Plunkett: Embedded Hardware, Software design
NEC Australia DRMASS
ph 03 9264-3867

-=====================================================================-

1998\06\09@124433 by

picon face
In a message dated 98-06-09 05:05:39 EDT, you write:

<< >EMITBIT
>        DECFSZ  STIME,F
>        GOTO    W4              ;BAUD DELAY
>        RRF     INDF            ;SHIFT RT
>        DECFSZ  SCOUNT          ;BIT COUNTER
>        GOTO    SEND_BITS       ;SEND MORE BITS
***look here>        RRF     INDF            ;8 BITS SENT- SHIFT TO ORIGINAL
>        MOVLW   BITTIME
>        MOVWF   STIME           ;LOAD BUAD DELAY
>        MOVLW   STOPBIT         ; SEND STOP
>        MOVWF   SSTATE
>;       BCF     _SEROUT         ;START BIT INVERTED
>        BSF     _SEROUT         ;START BIT NON-INVERTED
>        NOP
>        RETURN
> >>

>If you are not reloading the BUFFER data, then the data will be rotated, but
>out by one bit. Does this help?

I discovered one of my problems. I don't need the second RRF. The data was
previously shifted to the original position with the previous RRF. When I only
run the serial out routine everything works, but when I  allow the
multitasking with the PWM, servo and motor, again the first 5 byte loop works
great but the second is garbage. Something else in the program must be
corrupting the FSR. I thought I was reloading the buffer. If not what should I
change?

1998\06\09@175757 by

picon face
>I discovered one of my problems. I don't need the second RRF. The data was
>previously shifted to the original position with the previous RRF. When I
only run >the serial out routine everything works, but when I  allow the
multitasking with the >PWM, servo and motor, again the first 5 byte loop works
great but the second is >garbage. Something else in the program must be
corrupting the FSR. I thought I >was reloading the buffer. If not what should
I change?

I found the real problem. The carry flag is used in the shift routine. What I
found is that during the multitasking the carry flag is getting modified by
other routines. When it returns to the serial routine the wrong carry flag
corrupts the data. How can I prevent this or save the carry flag and restore
it on re-entry to the program?

1998\06\09@181123 by Thomas McGahee

flavicon
face
----------
{Quote hidden}

only
> run the serial out routine everything works, but when I  allow the
> multitasking with the PWM, servo and motor, again the first 5 byte loop works
> great but the second is garbage. Something else in the program must be
> corrupting the FSR. I thought I was reloading the buffer. If not what should
I
> change?

Nichole,
Something is probably clobbering the FSR. If this is the case, you need to
keep a local copy of the FSR in another register and swap it back when the
routine is active. By the same token, you MIGHT want to save the FSR
contents before swapping so you can swap the original contents back
before continuing your multitasking! Otherwise the FSR problem will just
migrate over to the other routine. Whenever you multitask, use local
copies of things that might get clobbered.

Hope this helps.
Fr. Tom McGahee

1998\06\09@192155 by

picon face
In a message dated 98-06-09 18:12:21 EDT, you write:

<< Nichole,
Something is probably clobbering the FSR. If this is the case, you need to
keep a local copy of the FSR in another register and swap it back when the
routine is active. By the same token, you MIGHT want to save the FSR
contents before swapping so you can swap the original contents back
before continuing your multitasking! Otherwise the FSR problem will just
migrate over to the other routine. Whenever you multitask, use local
copies of things that might get clobbered.

Hope this helps.
Fr. Tom McGahee >>

I believe your right. Could you show me an example of how to do this?

1998\06\09@204515 by Dwayne Reid

flavicon
face
>I found the real problem. The carry flag is used in the shift routine. What I
>found is that during the multitasking the carry flag is getting modified by
>other routines. When it returns to the serial routine the wrong carry flag
>corrupts the data. How can I prevent this or save the carry flag and restore
>it on re-entry to the program?

Easy!

Don't use the carry flag.  Modify your routine so that the shift occurs
AFTER you have sent the current bit, then use btfsc / btfss bit 0 ( (if you
are shifting right) or bit 7 (shifting left) and ignore C altogether.  No
extra code and no extra RAM needed.  If you think about it, you are doing
exactly the same thing with C anyways.  Just 'slide' everything over by 1 bit.

dwayne


Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(403) 489-3199 voice     (403) 487-6397 fax

1998\06\10@074614 by Caisson

flavicon
face
> Van: <Nichole Petty> <.....PHXSYSKILLspamspam.....AOL.COM>
> Aan: EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Onderwerp: Re: Still got the serial blues!
> Datum: dinsdag 9 juni 1998 21:17
>
> >I discovered one of my problems. I don't need the second RRF. The data
was
> >previously shifted to the original position with the previous RRF. When
I
> only run >the serial out routine everything works, but when I  allow the
> multitasking with the >PWM, servo and motor, again the first 5 byte loop
works
> great but the second is >garbage. Something else in the program must be
> corrupting the FSR. I thought I >was reloading the buffer. If not what
should
> I change?
>
> I found the real problem. The carry flag is used in the shift routine.
What I
> found is that during the multitasking the carry flag is getting modified
by
> other routines. When it returns to the serial routine the wrong carry
flag
> corrupts the data. How can I prevent this or save the carry flag and
restore
> it on re-entry to the program?

Just store you STATUS register into memory, and restore when re-entering
the routine.  Or copy only the stored Carry-bit back.

Greetz,
 Rudy Wieser

1998\06\10@122115 by

picon face
In a message dated 98-06-09 20:51:57 EDT, you write:

<< Easy!

Don't use the carry flag.  Modify your routine so that the shift occurs
AFTER you have sent the current bit, then use btfsc / btfss bit 0 ( (if you
are shifting right) or bit 7 (shifting left) and ignore C altogether.  No
extra code and no extra RAM needed.  If you think about it, you are doing
exactly the same thing with C anyways.  Just 'slide' everything over by 1
bit.

dwayne
 >>

Thanks I think I've got this thing working now. At lleast in simulation

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