Searching \ for '[PIC]: USART PIC16F628 and internal oscillator' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/ios.htm?key=usart
Search entire site for: 'USART PIC16F628 and internal oscillator'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: USART PIC16F628 and internal oscillator'
2001\09\16@034150 by Kevin Olalde

picon face
I'm trying to move a working circuit from a 16F84A to a 16F628.  The circuit,
through a MAX232 line driver was working well with the bit bang routines with
the 16F84A.  I swapped out the '84A for the '628 and haven't had much luck.  The
input and output from my program look to be garbled.  Meaning I'm sending and
receiving bytes, but the content is completely wrong (maybe baud?).

I'm using the internal oscillator at 4Mhz.  Does anyone know off hand of this
chip has any gotchas when compared to other chips with UASRTs?  I've tried a
number of permutations with the init code, but the same results persist.

I've copied a bit of the init code below (maybe someone will spot the newbie
thing I'm doing wrong).  Any advice would be appreciated.

Thanks!

Kevin


       banksel TRISA

       movlw   B'00111111'     ; set up PORTA, RA0:5 input
       movwf   TRISA ^ 0x80
       movlw   B'00000110'     ; set up PORTB, all outputs
       movwf   TRISB ^ 0x80    ;  except RB1:2, need to be set to
                               ;  enable the TX and RX pins
       clrf    PIE1 ^ 0x80     ;disable peripheral interrupts

       bsf     TXSTA ^ 0x80, BRGH      ; high speed baud option
       bcf     TXSTA ^ 0x80, SYNC      ; we want async comms
       movlw   25                      ; set baud rate to 9600
       movwf   SPBRG ^ 0x80

       bsf     TXSTA ^ 0x80, TXEN      ; enable transmitter
       bcf     TXSTA ^ 0x80, TX9       ; 8 bit transmit

       banksel RCSTA
       bsf     RCSTA, CREN             ; continuous receive
       bsf     RCSTA, SPEN             ; enable serial port

       movf    RCREG, W                ;clear receiver
       movf    RCREG, W
       movf    RCREG, W

       movlw   0                       ; send dummy byte
       movwf   TXREG

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\16@193657 by Tony Nixon

flavicon
picon face
Kevin Olalde wrote:
>
> I'm trying to move a working circuit from a 16F84A to a 16F628.  The circuit,
> through a MAX232 line driver was working well with the bit bang routines with
> the 16F84A.  I swapped out the '84A for the '628 and haven't had much luck.  The
> input and output from my program look to be garbled.  Meaning I'm sending and
> receiving bytes, but the content is completely wrong (maybe baud?).

Try disabling the comparator inputs.

;
; -----------------------
; DISABLE THE COMPARATORS
; -----------------------
;
       movlw b'00000111'               ; disable comparators
       movwf CMCON


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
spam_OUTsalesTakeThisOuTspambubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\16@213254 by Kevin Olalde

picon face
Thanks for the suggestion.  I was already doing that.

I have a question about the suggestion though.  How does the comparator adversly
affect the USART operation?  Is it the interrupts?

Thanks,
Kevin


Tony Nixon wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\16@220858 by Tony Nixon

flavicon
picon face
Kevin Olalde wrote:
>
> Thanks for the suggestion.  I was already doing that.
>
> I have a question about the suggestion though.  How does the comparator adversly
> affect the USART operation?  Is it the interrupts?
>
> Thanks,
> Kevin

There should be no interraction, they are seperate periferals on
seperate ports.

Since you are using the internal oscillator, perhaps the timing is off
by an amount that is causing the comms problems.

Here is a small program that should echo chars back to sender at 9600. I
have used it successfully with the internal osc.


Start   movlw b'00000000'               ; LVP lo, MCLR Lo
       movwf PORTA
       movlw b'00000100'               ; RX Lo, TX Hi
       movwf PORTB
       bsf STATUS,RP0
       movlw b'00000000'
       movwf TRISA
       movlw b'00000010'               ; RX = input
       movwf TRISB
       bcf STATUS,RP0
;
; -----------------------
; DISABLE THE COMPARATORS
; -----------------------
;
       movlw b'00000111'       ; disable comparators
       movwf CMCON
;
; ------------------------------------
; SET BAUD RATE TO COMMUNICATE WITH PC
; ------------------------------------
; Boot Baud Rate = 9600, No Parity, 1 Stop Bit
;
       bsf STATUS,RP0
       movlw d'25'             ; 9600 baud
       movwf SPBRG
       movlw b'00100100'       ; brgh = high (2)
       movwf TXSTA             ; enable Async Transmission, set brgh
       movlw b'10010000'       ; enable Async Reception
       clrf STATUS             ; RAM Page 0
       movwf RCSTA

MnLoop  call Receive
       movwf TXREG
       call TransWt
       goto MnLoop

;
; ------------------------------------
; WAIT UNTIL RS232 IS FINISHED SENDING
; ------------------------------------
;
TransWt bsf STATUS,RP0
WtHere  btfss TXSTA,TRMT        ; transmission is complete if hi
       goto WtHere

       bcf STATUS,RP0          ; RAM Page 0
       return
;
; ----------------------------------------
; RECEIVE CHARACTER FROM RS232 OR INTERNAL
; ----------------------------------------
; This routine does not return until a character is received.

Receive nop
         btfss PIR1,RCIF       ; check for received data
         goto Receive

         movf RCREG,W
         movwf RxHold          ; tempstore data
         return




--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesspamKILLspambubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\16@232434 by Kevin Olalde

picon face
Thanks, your version worked (of course).

Here's what I see I was doing different:
- You set RB1/RX  low and RB2/TX high, I set them both low.  Where did you get
this, I didn't see this in the datasheet?

- You only set RB1 as an input, I set both RB1 and RB2 (pg. 71 in the datasheet)

- The order of setup was different, is this significant?

- Your receive routine blocks.  I was polling looking at the RCIF flag:
Receive btfss   PIR1,   ; check if we have received and data
       return                  ; if not, just return
                               ; otherwise, move received byte into
       movf    RCREG, W        ; result into W
       return

- you're putting the output into TXREG, then waiting for TRMT to clear.
 I was waiting for TRMT to clear then loading TXREG.

OK, then I'm off to find the exact error of my ways.

Thanks!

Kevin


Tony Nixon wrote:
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\09\16@235444 by Tony Nixon

flavicon
picon face
Kevin Olalde wrote:
>
> Thanks, your version worked (of course).
>
> Here's what I see I was doing different:
> - You set RB1/RX  low and RB2/TX high, I set them both low.  Where did you get
> this, I didn't see this in the datasheet?

No, it's just the way I like to do it, which is an idle RS232 state.

> - You only set RB1 as an input, I set both RB1 and RB2 (pg. 71 in the datasheet)

There have been numerous yays and nays for UART setup. I have always
configured this way and have never had problems. As I understand it,
once the UART is enabled, it takes control of the port RX TX pins
anyway, so this may be irrelevant. I haven't heard of anyone pre-setting
UART bits that cause a failure, although that may be incorrect.

> - The order of setup was different, is this significant?

I wouldn't imagine so..??

> - Your receive routine blocks.  I was polling looking at the RCIF flag:
> Receive btfss   PIR1,   ; check if we have received and data
>         return                  ; if not, just return
>                                 ; otherwise, move received byte into
>         movf    RCREG, W        ; result into W
>         return

Did you clear the RCIF flag after a byte was received???

That's why I don't use this flag unless UART interrupts are enabled.

> - you're putting the output into TXREG, then waiting for TRMT to clear.
>   I was waiting for TRMT to clear then loading TXREG.

Horses for courses I would think, except this bit 'may' be misleading
before the very first byte is transmitted. I can't see this though,
because the data sheet mentions the TRMT flag = 1 on powerup meaning an
empty TX buffer.


--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
EraseMEsalesspam_OUTspamTakeThisOuTbubblesoftonline.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


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