I have a problem with rs485 driver SN65176b (which is exactly like max485).
I wrote a code for a pic to send modbus commands to a temperature controller but got no responses.
Here is how the command is being sent.
Then accidentally the wire on “Drive Enable” pin disconnected (left floating) and the slave responded! I’m very confused.
Isn’t the output driver supposed to be disabled when left open?
If the output driver is active, then how can the chip receive messages?
Why my code which controls the direction doesn’t work?
(devices are 10cm apart. power is 5v. no termination resistors. no fail-safe biasing resistors)
When the drive enable floats, there's no guarantee which state it will assume.
Maybe you should disconnect your controller, and look at your 65176 with a scope. Maybe the controller is not disconnecting its driver when you think it should. Maybe your software is inverting the driver enable, who knows? It's pretty hard to debug hardware without some kind of instrumentation.
Thank you
I have "Drive Enable(Active High)" and "Receive Enable(Active Low)" connected to each other and control it with one pin. I checked it and it's correct.
My main question is: If the output driver and receive driver are both active, then how does the chip receive messages (which does)?!
Thank you
I have "Drive Enable(Active High)" and "Receive Enable(Active Low)" connected to each other and control it with one pin. I checked it and it's correct.
My main question is: If the output driver and receive driver are both active, then how does the chip receive messages (which does)?!
connect both the reciever enable (RE) and driver enable (DE) together to a microcontroller pin and operate it like....high for transmission and low for reception....plz inform here if still any problem arise due to this
There is a further problem which is more likely to be the cause of the problem.
The RE and DE pins can be tied together, one is active high and the other active low but they can't be controlled in the method used in the program. I'm guessing the problem is that the end of the printf message is not being transmitted becasue the last character(s) are still in the UART buffer when the transmit is disabled. The 'dirty' fix would be to add a delay after the printf statement, a better solution is to check if the UART transmit buffer is empty before moving on.