 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
| RS-485 woes..... |
 Posted: Fri Sep 28, 2007 12:36 pm |
 |
|
Hi All,
I am developing a device that will communicate with other hardware using either RS-232 or RS-485. So far all of my development has been done using RS-232 and a PC, and everything has worked as expected. Now, I'm trying to validate the RS-485 communications, and things aren't going so well.... The development prototype has both a MAX232 type device, and an SN75176, as well as a pair of jumpers to switch the TxD and RXD lines on the PIC between these devices.
I have a very simple program that illustrates the "odd" behavior that I am seeing:
| Code: |
#include <16F628.h>
#fuses INTRC_IO, NOWDT, NOPROTECT, NOLVP, BROWNOUT
#use delay(clock=4000000)
#define Rx_In PIN_B1 // serial data receive pin
#define Tx_Out PIN_B2 // serial data transmit pin
#define Serial_Enable PIN_A7 // Serial data enable
//-----< Serial Port Definition >-----
#use rs232(baud=9600, xmit=Tx_Out, rcv=Rx_In, enable = Serial_Enable, ERRORS, stream = Network)
void main() {
while(1){
delay_ms(1000);
fputc('1', Network);
fputc('2', Network);
fprintf(Network, "\r\nHello World!\r\n");
}
}
|
When this code is run in "RS-232 mode" I see this on the Hyperterminal screen:
| Code: |
12
Hello World!
12
Hello World!
12
Hello World!
|
When this code is run in "RS-485 mode" I see this on the Hyperterminal screen:
As you can see, something is happening to prevent the fprintf statement from working properly when in RS-485 mode....... The fputc funtion works perfectly, but the fprintf does not  !
Perhaps my selection of RA7 as the enable control for the RS-485 chip is the problem? Nothing in the datasheet seems to suggest it would be a bad choice, however!
I'm doing this development on a custom prototype board using v3.249 of the CCS compiler.
Anyone see what I might be doing wrong??
Thanks,
Charlie |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 28, 2007 3:16 pm |
|
|
I think there's a bug. As a work-around, you could re-direct the output
of printf (not fprintf) to a routine that calls fputc(). Since fputc() works,
this should fix the problem. Example:
| Code: | #include <16F628.h>
#fuses INTRC_IO, NOWDT, NOPROTECT, NOLVP, BROWNOUT
#use delay(clock=4000000)
#define Rx_In PIN_B1 // serial data receive pin
#define Tx_Out PIN_B2 // serial data transmit pin
#define Serial_Enable PIN_A7 // Serial data enable
#use rs232(baud=9600, xmit=Tx_Out, rcv=Rx_In, enable=Serial_Enable, ERRORS, stream=Network)
void Network_fputc(char c)
{
fputc(c, Network);
}
//===============================
void main() {
while(1){
delay_ms(1000);
fputc('1', Network);
fputc('2', Network);
printf(Network_fputc, "\r\nHello World!\r\n");
}
}
|
|
|
|
Guest
|
|
| Posted: Fri Sep 28, 2007 3:45 pm |
|
|
Hi PCM,
Yeah, that worked - thanks!! I wish I thought of it!!
By, 'bug', I assume you mean a bug in the fprintf function in v3.249??
Hmmm, maybe this will prompt me to (finally) give the v4 compiler a try!
Thanks,
Charlie |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Sep 28, 2007 3:51 pm |
|
|
It appears to be fixed in vs. 4.056. Here's the ASM code. Notice
that fprintf() now calls the same routine as the fputc() lines do.
| Code: |
.............. fputc('1', Network);
005C: MOVLW 31
005D: MOVWF 22
005E: CALL 02E
.............. fputc('2', Network);
005F: MOVLW 32
0060: MOVWF 22
0061: CALL 02E
.............. fprintf(Network, "\r\nHello World!\r\n");
0062: CLRF 21
0063: MOVF 21,W
0064: CALL 004 // Get char from const string
0065: INCF 21,F
0066: MOVWF 77
0067: MOVWF 22
0068: CALL 02E // Call fputc() routine
0069: MOVLW 10
006A: SUBWF 21,W
006B: BTFSS 03.2
006C: GOTO 063 |
|
|
|
Guest
|
|
| Posted: Tue Oct 02, 2007 10:36 am |
|
|
Hi all.
OK, I've moved beyond the fprintf issue with a work-around, but now I'm encountering a problem with my INT_RDA interrupt handler in RS-485 mode. Again, my hardware and code work flawlessly when I am communicating with a PC via RS-232, but when I switch over to RS-485, things fall apart quite quickly...... Basically, in RS-485 mode, the interrupt handler is firing continuously, and nothing else is being executed. I suspect that the ENABLE logic that is supposed to control the direction of the RS-485 data has a bug in v3.249??
Can anyone confirm this? If it is a bug, has it been fixed?
Charlie |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Tue Oct 02, 2007 11:07 am |
|
|
No, enable works ok in 3.249
Last edited by treitmey on Tue Oct 02, 2007 11:15 am; edited 2 times in total |
|
|
Neutone
Joined: 08 Sep 2003
Posts: 839
Location: Houston
|
|
| Posted: Tue Oct 02, 2007 11:13 am |
|
|
| Anonymous wrote: | Hi all.
OK, I've moved beyond the fprintf issue with a work-around, but now I'm encountering a problem with my INT_RDA interrupt handler in RS-485 mode. Again, my hardware and code work flawlessly when I am communicating with a PC via RS-232, but when I switch over to RS-485, things fall apart quite quickly...... Basically, in RS-485 mode, the interrupt handler is firing continuously, and nothing else is being executed. I suspect that the ENABLE logic that is supposed to control the direction of the RS-485 data has a bug in v3.249??
Can anyone confirm this? If it is a bug, has it been fixed?
Charlie |
What is the voltage level on the PIC RX? If it is not high it will fire interrupts continuously. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
|
Storic
Joined: 03 Dec 2005
Posts: 182
Location: Australia SA
|
|
|
Guest
|
|
| Posted: Thu Oct 04, 2007 12:10 pm |
|
|
Hi All,
My RS-485 receive problem can be illustrated quite clearly with the EX_SISR.C example program. When my prototype board is in RS-232 mode, the program works flawlessly, but when it is in RS-485 mode, it does not. The problem appears to be caused by the serial receive ISR being triggered by the transmission of any characters. That is, Tx data from the PIC seems to be triggering the Rx ISR. This is only a problem in RS-485 mode. For the record, I do have the ability to "terminate" and "bias" the RS-485 connection, but this doesn't have any effect. My RS-485 hardware configuration is exactly the same one that I have used successfully in other hardware designs, so I don't think this is a hardware issue??
I've tried compililing with v3.249 and v4.050, with the same result.
Any thoughts?
Charlie |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Oct 04, 2007 1:40 pm |
|
|
Ahhh.....
In my TX isr I turn off RX so I don't see that data.
TX and RX are sharing the same 2 wires(right??)
note :CREN
| Code: | //=======================TXisr============================//
//Takes data from buffer and puts it into a TX stream (RS485)
//uses interrupts to empty buffer at proper rate
#INT_TBE
void TXisr(void)
{
CREN = 0;//CREN: Continuous Receive Enable bit=0 ie: no RX
idle_bus=FALSE;
fputc(TX_BUF[tx_indx_o],RS485);
tx_indx_o++; //not used//tx_indx_o &= TXMASK;
if(tx_indx_o==tx_indx_i)
{
disable_interrupts(INT_TBE);//Done TXing turn on RX again
CREN = 1;//CREN: Continuous Receive Enable bit=1 ie: RX enabled
}
}
|
|
|
|
Guest
|
|
| Posted: Thu Oct 04, 2007 2:29 pm |
|
|
Hi treitmey,
Thanks for the reply!
I'm sure it works, but I wonder if your technique is strictly necessary? The SN75176 is a two-line (RxD and TxD) to differential bus tranceiver. The IC has an internal Tx driver and Rx receiver, each with an enable line. One is active-high and the other is active-low, so that when tied together they act like a "direction" control. This direction control line is connected to the PIC pin specified in the #use rs232 directive as ENABLE. This is supposed to control the flow of data to/from the RS-485 bus without conflicts.
I've done this before with no problems using earlier compiler versions, but I can't seem to get it to work now!
Thanks,
Charlie |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Oct 04, 2007 3:04 pm |
|
|
I think this may be used as a bus contention trick.
So you read what you transmit and check it against the buffer.
If another device is in contention, the RX data would be garbled.
just a thought.
also see something like it in the drivers/rs485.c
inside
| Quote: | int1 rs485_send_message(int8 to, int8 len, int8* data)
|
there is a
and then
perhaps you could use this known good code? |
|
|
ThomasC
Joined: 09 Oct 2007
Posts: 62
|
|
| Posted: Tue Feb 05, 2008 8:46 am |
|
|
| PCM programmer wrote: | I think there's a bug. As a work-around, you could re-direct the output
of printf (not fprintf) to a routine that calls fputc(). Since fputc() works,
this should fix the problem. Example:
| Code: | #include <16F628.h>
#fuses INTRC_IO, NOWDT, NOPROTECT, NOLVP, BROWNOUT
#use delay(clock=4000000)
#define Rx_In PIN_B1 // serial data receive pin
#define Tx_Out PIN_B2 // serial data transmit pin
#define Serial_Enable PIN_A7 // Serial data enable
#use rs232(baud=9600, xmit=Tx_Out, rcv=Rx_In, enable=Serial_Enable, ERRORS, stream=Network)
void Network_fputc(char c)
{
fputc(c, Network);
}
//===============================
void main() {
while(1){
delay_ms(1000);
fputc('1', Network);
fputc('2', Network);
printf(Network_fputc, "\r\nHello World!\r\n");
}
}
|
|
I'm getting output here to Comm Operator (hyperterminal like program) I'm getting:
9D 9B E5 EB 6F 35 27 27 21 BF 51 21 1B 27 37 BD E5 EB (HEX)
I'm running:
PIC16F690 / PCM 4.060 / ICD2 / MAX485 / Telebyte Model 245 Superverter (RS485 to RS232 converter)
I do not understand why it comes out differently.
I notice that the value changes when the frequency is increased. Why does it do that?
Sorry to hijack this thread. Thanks! |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Tue Feb 05, 2008 9:15 am |
|
|
A 16F628 has a hardware USART on B1 and B2.
A 16F690 does not. A software implementation will be built.
Try starting a new thread with your new questions/problems. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
