View previous topic :: View next topic |
Author |
Message |
JerryR
Joined: 07 Feb 2008 Posts: 164
|
Tx only RS232 |
Posted: Wed Jun 08, 2011 5:57 am |
|
|
This should be a well documented topic, but I can't seem to find an answer after a somewhat complete search.
I need only to perform transmit RS232 functions. My hardware supports using the hardware tx USART pin on a 18FL14K22. Using either hardware or software USART function, can I implement only tx functions and leave the rx pin "released" for use as a discrete I-O line?
Thanks group |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19360
|
|
Posted: Wed Jun 08, 2011 8:16 am |
|
|
Declare both in the #use rs232 statement (if you don't, the code won't select the hardware UART). Then the compiler only actually 'generates' the receive code, when it is used, so this is not a problem. Then just use the pin as normal.
It is slightly harder to do the opposite way round (hardware receive, with the TX pin used for normal I/O), with you having to turn off the TXEN bit in the UART, or this overrides the normal pin functions, but for the receive pin, you can read/write the pin normally, even if the UART is enabled.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
JerryR
Joined: 07 Feb 2008 Posts: 164
|
|
Posted: Wed Jun 08, 2011 8:24 am |
|
|
Ttelmah:
Thanks for the reply. I'll double-check the code and operation, but attempted this using hardware EUSART pins and couldn't control the receive pin (RB5). You're right, it looks like your method should work fine. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Wed Jun 08, 2011 9:21 am |
|
|
Yes, just don't assign a pin in the use rs232(....) function. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jun 08, 2011 11:44 am |
|
|
Temtronic,
What you propose, won't work.
Here's the normal declaration with both hardware pins for this PIC:
Code: |
#include <18LF14K22.h>
#fuses HS,NOWDT
#use delay(clock=20M)
#use rs232(baud=9600, xmit=PIN_B7, rcv=PIN_B5, ERRORS)
//======================================
void main(void)
{
putc(0x55);
while(1);
}
|
The program above produces the code below, which writes to TXREG.
So it's using the hardware UART for Tx.
Code: |
...... #use rs232(baud=9600, xmit=PIN_B7, rcv=PIN_B5, ERRORS)
0004: BTFSS PIR1.TXIF
0006: BRA 0004
0008: MOVWF TXREG
000A: GOTO 0040 (RETURN)
.
.
.
....... putc(0x55);
003C: MOVLW 55
003E: BRA 0004
.................... |
Here is a revised program based on your proposal to leave out the Rx pin:
Code: |
#include <18LF14K22.h>
#fuses HS,NOWDT
#use delay(clock=20M)
#use rs232(baud=9600, xmit=PIN_B7)
//======================================
void main(void)
{
putc(0x55);
while(1);
}
|
Here's the generated code for the program above. It's clearly not using
the hardware UART. It's manually "bit banging" the transmitted byte.
That's not what the O.P. wants.
Code: |
.................... #use rs232(baud=9600, xmit=PIN_B7)
0004: BCF TRISB.TRISB7
0006: BCF LATB.LATB7
0008: MOVLW 08 // Send 8 data bits
000A: MOVWF @01
000C: BRA 000E
000E: NOP
0010: BSF 01.7
0012: BRA 0030
0014: BCF 01.7
0016: RRCF ??65535,F
0018: BTFSC STATUS.C
001A: BSF LATB.LATB7 // Set or clear Pin B7, based on the
001C: BTFSS STATUS.C // current bit value that is being sent.
001E: BCF LATB.LATB7
0020: BSF 01.6
0022: BRA 0030
0024: BCF 01.6
0026: DECFSZ @01,F
0028: BRA 0016
002A: BRA 002C
002C: NOP
.
.
.
.
0042: GOTO 006A (RETURN)
.................... putc(0x55);
0064: MOVLW 55
0066: MOVWF ??65535
0068: BRA 0004 |
|
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Wed Jun 08, 2011 2:35 pm |
|
|
The OP's second sentence led me to believe either hard or soft was 'ok' to implement but I could have been thinking wrong....
...it's about 40C here today and I'm not used to it ,yet. |
|
![](templates/subSilver/images/spacer.gif) |
|