stephane/libmodbus — pull request #35 by jaimealsilva (2011-10-23 21:56:05+00:00)
Title: Hardware that echoes transmitted bytes

OK, now I'm doing it right. Instead of [opening an issue](https://github.com/stephane/libmodbus/issues/34) I'm sending you a pull request. So here goes the explanation again:

I'm using libmodbus on a [Technologic Systems TS-7800 SBC](http://www.embeddedarm.com/products/board-detail.php?product=TS-7800) with the RS485 optional bus. It turns out that this board's MAX485 is wired in such a way that the receiver is always enabled (check out page 6 of [it's schematic](http://www.embeddedarm.com/documentation/ts-7800-schematic.pdf) bottom-right corner) so everything you transmit gets back on the receive buffer, libmodbus thinks it is the slave answer and fails with a checksum error.

I tried to fix it by disabling the receiver before transmitting with tcsetatrr and turning it back on after transmission but it didn't worked, the bytes were still echoed to the receive buffer. So finally I fixed it by reading from the port the same amount of bytes transmitted so they get out of the buffer.

I think this can be useful to someone else who has hardware that echoes the transmitted bytes. So I add a new field to the modbus_rtu structure and, added a couple functions and modified the rtu's transmit function. The new functions are:

int modbus_rtu_set_echohw_mode(modbus_t *ctx, uint8_t mode);
int modbus_rtu_get_echohw_mode(modbus_t *ctx);

echohw mode can be one of MODBUS_RTU_NO_ECHOHW and MODBUS_RTU_HAS_ECHOHW. By default the RTU is in MODBUS_RTU_NO_ECHOHW which means it works as usual, but if you change it to MODBUS_RTU_HAS_ECHOHW then all the transmitted bytes will be taken out of the receive buffer.

I also fixed some issues with the new RTS functions that break compilation when HAVE_DECL_TIOCSRS485 is not defined.

I hope this code is useful and will be waiting for comments.

Thanks again for libmodbus.