[En-Nut-Discussion] Help: RS485 problem

[Tan Cheng-Lin]

I managed to get UART1 485 talking to a PC partially, via a RS232/RS485
converter (Rextron LCS485) connected to the PC serial port. Settings on
Rextron LCS485 is T.on/R.on on the left switch, and DCE on the right.

I made the following observations :

1. Isn't Pin6 (second from left 485 screw connector looking at componet
side of PCB) supposed to be connected to RX+ of the RS485 to RS232
converter? And Pin7 (first from left screw connector) to be connected to
RX- of the
RS485 to RS232 converter?  The data did not get through correctly until
I do the opposite (ie. Pin6 to RX- and Pin7 to RX+).  Any clue why?

2. I can make the ethernut send data to PC through the RX- and RX+ line
of the LCS485 and receive data from PC through the TX- and TX+ lines.
However, when I tried connecting RX- & TX- to Pin6 and RX+ & TX+ to
Pin7, and setting 
Rextron LCS485 to T.RTS/\R.RTS on the left so that they are half duplex
mode, 
I can only send data to the Ethernut from the PC but not the other way.
The signal swing on the RX+/TX+ is from 0 to 1V, and RX-/TX- is from 3
to 5V when Ethernut tries to send data to the PC.  Obviously something
is not correct.  

Has anyone managed to get the Ethernut talking and receiving from a PC
serial port via the RS485? If you have, which RS232/RS485 converter did
you use and please provide the configuration setting.

Thanks in advance!

Regards,
Marcus

>
>/* define UART1 */
>NutRegisterDevice(&devUart1, 1, 0);
>uart1 = NutDeviceOpen("uart1");
>NutDeviceIOCtl(uart1, UART_SETSPEED, &rs485baud);
>
>// Testprint
>NutPrintString_P(uart1, PSTR("Test String"));
>NutPrintFlush(uart1);

This should still work, but using NutPrint is deprecated.
Better use standard I/O functions, like:

     FILE *uart1;
     u_long baud = 9600;

     NutRegisterDevice(&devUart1, 0, 0);

     uart1 = fopen("uart1", "r+");
     _ioctl(_fileno(uart1), UART_SETSPEED, &baud);
     fprintf(uart1, "Test String\n");

Note, that Ethernut 2 uses half duplex RS485. There is
currently no specific driver. In order to use the standard
UART driver, you need to explicitely switch the direction
bit, PD4 or PD5, depending on your setting of JP2.

To avoid long delays while switching directions, you may
use a modified uartavr.c. Switch to receive (PD4/5 output low),
when the TxComplete interrupt occurs and the tx buffer is empty.
Switch to transmit, before transmitting the first character.

Or simply wait until I finished the new USART driver.

Harald