Searching \ for '[PIC] Data transfer from P16F877 to serial PC' 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/microchip/ios.htm?key=serial
Search entire site for: 'Data transfer from P16F877 to serial PC'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Data transfer from P16F877 to serial PC'
2003\04\29@091306 by Jinx

face picon face
It's quite simple to set up comms and send/receive data

First, you need to set the PIC's registers for the data rate, based on
the speed of the PIC's clock. Example below is for 38400 baud with
a 3.6864MHz crystal

Then perhaps wait for a request from the PC, which may be a special
character like "S" (for send) or whatever you want. By handshaking
with the PC, the transfer will be a little slower but may result in a more
controlled transfer, particularly if the PC gets busy and can't keep up
with ungoverned transmission from the PIC

After a request, just put the data into the transmit buffer and off it goes

Those are the basics. You can add interrupts, error routines, checksums
etc etc

;================================================
;        Initialise RS232 serial comms
;================================================

; 38k4 with BRGH = 1 @ 3.6864MHz

; 38400 = Fosc / (16 * (X+1))
; 38400 = 3686400 / (16 * (X+1))
; 38400 * (16 * (X+1)) = 3686400
; 16 * (X+1) = 3686400 / 38400
; X = ( (3686400 / 38400) / 16 ) -1
; X = (96/16)-1
; X = 5

        bank1
        movlw   0x05         ;5 = 38,400 baud
        movwf   spbrg
        movlw   b'00100100'  ;brgh=1, Asynch, 8-bit, Tx enabled
        movwf   txsta

        bank0
        movlw   b'10010000'  ;Asynch, 8-bit, Rx enabled
        movwf   rcsta
        movf    rcreg,w      ;clear receive buffer and rcif

;================================================
;        Wait for request from PC
;================================================

get_req  bank0
        movf    rcreg,w      ;clear receive reg, buffer, and rcif
        movf    rcreg,w
        movf    rcreg,w
        bcf     rcsta,cren   ;clear any errors
        bsf     rcsta,cren

        btfss   pir1,rcif      ;wait for receive buffer to fill
        goto    $-1
        movf    rcreg,w      ;clear rcif

;then test received byte (in W) to see if it's a proper request

;================================================
;        Send byte to PC
;================================================

        bank0
        movlw   databyte          ;put data into transmit buffer
        movwf   txreg

;wait here to test for byte gone

        bank1
        btfss   txsta,trmt   ;byte transmission complete
        goto    $-1
        bank0

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

2003\04\29@104132 by Rick Regan

picon face
>;================================================
>;        Send byte to PC
>;================================================
>
>         bank0
>         movlw   databyte          ;put data into
>transmit buffer
>         movwf   txreg
>
>;wait here to test for byte gone
>
>         bank1
>         btfss   txsta,trmt   ;byte transmission
>complete
>         goto    $-1
>         bank0

  This reminds me of a question I've been meaning
to ask.  Some UART code I've seen checks TRMT=1,
other code checks TXIF=1, and some code checks both
flags.  Is there a reason why just checking TXIF=1
to verify that TXREG is empty is not sufficient?
Under what circumstances would you need to know that
that the TSR itself is empty before sending another
character?


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

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

2003\04\29@185747 by Jinx

face picon face
>    This reminds me of a question I've been meaning
> to ask.  Some UART code I've seen checks TRMT=1,
> other code checks TXIF=1, and some code checks both
> flags.  Is there a reason why just checking TXIF=1
> to verify that TXREG is empty is not sufficient?

The basic difference is that TXIF is part of the interrrupt system.
TRMT is not and has to be polled by code. In some applications
it may be advantageous to have comms interrupt-driven. The
example I gave came from a dedicated routine that had a push-
button entry, so there was no other s/w competing for attention
during comms so testing TRMT was sufficient

TXIF and TRMT are indicators for two registers, TXREG and TSR

TXIF shows the condition of TXREG. When TXIF=1 TXREG is
available for new data, ie the data previously in TXREG has been
moved to TSR (and so on to the comms line)

TRMT shows the condition of TSR. When set it indicates that TSR
is empty (MT) and that the data has been sent out

> Under what circumstances would you need to know that
> that the TSR itself is empty before sending another
> character?

TXREG can be loaded with new data (according to TXIF) even if
there is data still in TSR. The PIC won't transfer the new data from
TXREG to TSR until the previous data send is complete. Referring
back to example I posted, testing TRMT - and knowing that no new
data has been loaded into TXREG - tells you that the transmit module
is empty. In a handshake situation you could then wait for a data
request from the other device, possibly by enabling RCIF interrrupts
if the requests are unpredictable

That's my quick precis of some aspects of the TX part of the UART
in Asynch mode. It's covered in more detail in Section 10.2 of DS30292
(F877 manual) and Section 18.4.1 of DS31018 (Midrange Reference
Manual)

--
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 2003 , 2004 only
- Today
- New search...