MOD-RS485-ISO

[kostas]

Hello everybody
I own a  A13-OLinuXino-WiFi revC board, together with a MOD-RS485-ISO UEXT module.
I have a network of RS485 devices in which i'm trying to communicate via  MOD-RS485-ISO.
I have made settings based on the following
MOD-RS485-ISO connects to UART1 which is /dev/ttyS0
Since /dev/ttyS0 is the debuging console, i have  canceled this operation by commenting out
TO:2345:respawn.... line of /etc/inittab file.
PROG jumper is open
Y-A jumper closed
Z-B jumper closed
From my application's debugging information it looks like ttyS0 opens normally,frames sent to ttyS0,  but no transmition happens in RS485 line.
I was thinking that MOD-RS485-ISO module is a normal serial TTL to RS485 transceiver.
As UEXT-UART1 does not include hardware handshake signals while MOD-RS485-ISO has a nice microcontroller on board, i was also thinking that it would include auto direction-detection operation.
When i use a USB/RS485 module instead (all i have to change in my application is port name from /dev/ttyS0 to /dev/ttyUSB0) communication runs flawlessly.
I was wondering if there is any workaround, though i have read all (i guess) relative topics

Best Regards
Kostas

[dave-at-axon]

Hi there,

I've not used this module myself but quick glance at the (very poorly written) source code would indicate that the device does nothing other than listen for I2C data.

There is no UART code whatsoever that I could find in the download which would explain why you are not seeing any transmission on the RS485 bus. Nothing handles the TD, RD, TXD or RXD pins in sample code.

Unless the binary image loaded to the PIC when they manufacture them is different, I think you're going to have to develop the PIC code to handle the input and output of the UART.

The PIC used has NO hardware UART's so you would need to code for a software UART or bit bang. That I never saw on the source downloaded either. My assumption is that they were going to bit bang the INPUT to OUTPUT and monitor the TXD Input for activity. If none, it would stop output to the RS485 and disable the transmitter. You would need a state machine with timing on this to detect when the data input has stopped.

Olimex make some great hardware but they are let down with poorly written and supported source code.

[kostas]

Hi Dave
Thank you very much for your valuable information
Euro 16,95 is a nice price for a TTL/RS422/485 converter.
On the other hand, PIC programming is the masochistic way for me.
All i need is cheap, half duplex, isolated communication. It would be better to remove PIC and connect R-Rx, D-Tx, RE-DE with SCL or SDA and toggle it as GPIO between transmit and receive.

Best Regards
Kostas

[dave-at-axon]

Hi Kostas,

I am not exactly sure why they have the PIC in there in the first place. The documentation gives no clues to it's use and only talks about the I2C. Why you need I2C with RS485 is another guess.

There is a far simpler way to do this and still have isolation and power it from the same 3.3V on the UEXT connectors.

Use a small 3.3V input DC-DC that generates 9V output. Feed this to a 5V regulator to power a MAX13487, as this has auto transmit enable. The TX and RX lines are then fed from an ADUMxxxx bus isolator and you then have isolated RS485.

Price wise is about the same if not a little cheaper but you have a simple isolated RS485 with no need for any extra processor and no need for any GPIO Line to control the transmitter either.

If you need 4 wire then just have a second MAX13487 and use links to set the mode. 2 or 4 wire would be easy.

[dave-at-axon]

Hi Kostas,

I've just gone through the manual for this board and the software source that is listed. Nothing in the manual describes what the PIC is used for. The source only enables an I2C slave and sends back a value. There is no GPIO pins used. Even the interrupt handlers do nothing.

I am at a loss to how this unit can be used? You've already said you don't see any transmission on the RS485 output which would confirm my suspicions on the software not being completed.

The Wiki link on the product page states that it contains old code and customer projects. Most of the page is under construction and what little code there is, again does nothing with the GPIO pins for TXD, RXD etc.

Don't get me wrong, I like a number of the Olimex designs and I am using and loving the A20's I have. It's just that this module doesn't appear to do anything in regards to RS485 in and out.


If you are willing to unsolder the PIC and get this working without any messing around with code, I would connect SDA and SCL to the DE and #RE and control these in your software. You'll also need to connect TXD and RXD to the R and D lines. You will still have isolation with this method.

Good luck with it.

[mikenycz]

I looked at the MOD-RS485 board and pins 9 and 10 in the UEXT port which are SCK and SSEL (resp.) are the things tied to /RE and DE on the ADM3483ARZ chip. I think if you control these lines from software and drive on the RX and TX pins of the UEXT (pins 4 and 3 resp.) you should get an RS485 signal out of A and B on the MOD-RS485 board. I will be doing this as well. I will post any successes / failures.

Mike Nycz

[dave-at-axon]

They are indeed on the MOD-RS485 Mike, but Kostas has the ISO version and this apparently does not have software on the PIC to driver them.

[Leonardo]

The MOD-RS485 and the MOD-RS485-ISO are different, i read some other posts in the forum confusing the two modules. In the MOD-RS485-ISO the I2C is used to set the direction of the RS485. Three I2C commands are supported, the first one to read the board ID, the second one to change the I2C address of the module, and the last one to set the port direction. I have a modbus library source code supporting another architecture and looking at the code i've seen wr/rd operations require a switch of port direction, in that case by setting a dedicated GPIO pin. Till now i succeded to open the I2C port (using debian on UEXT1 the device is "/dev/i2c-2") and sending commands as follows (as explained in the demo source code):

----
int i2c_fd;
unsigned char buffer[3];
buffer[0]=0x30;
buffer[1]=0x03;

I2C_Open(i2c_fd,0x22);
I2C_Send(i2c_fd,buffer,2);
I2C_I2C_Close(i2c_fd);
---
This is the case of enabling both TX and RX direction, but it works also for other commands, including reading the board ID.

But i cannot read/write anything from/to the UART, i tried with ttyS1, but i noticed also ttyS0 and ttyS2 exist, which one should i use?
Now i'm going to check the raw data passing through the RS485 leaving modbus for a moment. I'll also give a look to the firmware source code...

Leo

[dave-at-axon]

Hi Leo,

I can understand that the I2C is used to switch the TX/RX but where in the modules firmware does the TXD and RXD lines connect to the TD and RD of the RS485 driver?

If you look at the schematic, the TXD from the UEXT is connected to the PIC and not to the D line on the RS485 driver.

Now, if this code here is the source for the HEX inside the PIC, I see nothing controlling the TX/RX or passing the TXD to the D or the R to RXD. Either the code is not available or it does do what it says.

https://www.olimex.com/Products/Modules/Interface/MOD-RS485-ISO/resources/MOD-RS485_FIRMWARE_V2.zip

On your board, can you confirm with a scope if there is activity on the PIC TXD input (pin 2) when you send serial data to the UEXT. If there is, confirm if there is data on the D line from the PIC (pin 5)

If you see no data on the D line, this is the reason your board does not work.

[Leonardo]

Hi! I cannot use a scope at the moment, but looking at the PIC datasheet (especially pag. 4-9-215-218) and the firmware source code i found that TXD is the input of the Configurable Logic Cell 1 (CLC1) and D is the output, while RXD is the output of the CLC2 and R is the input. In the file user.c of the firmware code look at the function InitApp(), CLCs are configured there by setting some registers (CLC1GLS0, ...) and in the function CommandSetCLC() registers LCxEn and LCxOE are changed depending on the I2C direction command received. I've given also a quick look to some registers definition and it seems they are configured well, but someone should check with a scope for a proof.

Leo

[Leonardo]

Hello! I finally succeed to communicate through the MOD-RS485-ISO module, tested with modbus protocol on a modbus chain of two devices (the olinuxino master and a energy meter slave). The olinuxino board is a A20 with debian, for UEXT1 use i2c-2 and ttyS1 devices. In order to send data you have to send the i2c command 0x03 (TXRX ON) first, then write data to the uart (write()), wait for data to be transmitted (tcdrain()) and then switch back to RX ON with i2c 0x02 command. In order to read data simply use the select() on the uart dev and then read().
I hope this can help you!!

Leo

[in06khattab]

Hi,

I am working with OLinuXino board and I am using a MOD-RS485-ISO to implement a RS 485 modbus communication.  I am looking for code for this board, but I cant find any that I can compile. Could you please provide your code for your energy meter project?

Thanks,
Ahmad

[Leonardo]

Hello,
sorry but i can't share the modbus protocol code, it's not open source. anyway i think any modbus open source library should work, i could check it if you give me some compiling code...

Leo

[dave-at-axon]

Hi Ahmad,

Which OS and which programming language?

There are a lot of open source Modbus drivers out there you can look for. If you can use Java, then this is recommended. I use this under Android for both Modbus TCP/IP and Modbus RTU over UART.

http://sourceforge.net/projects/modbus4j/

I use both Modbus Master and Modbus Slave with this library. I had a small change to the UART code but the rest just worked. Under Linux I think no changes would be needed.