Electronic – Wrong output using SN75HVD10 (RS485)

This sounds like it should be easy to diagnose. You say the signals on the RS-485 bus look OK, so check the next point. Keep following the signal until you find it not right somewhere.

The next logical point to test after the RS-485 bus would be when it gets converted back to a single-ended signal that presumably gets presented to UART receive pin of the device. Does that look right? If not, there is a problem with the RS-485 receiver circuitry. If so, then either the device is not working or you have a protocol problem.

In general, it's good to keep dividing up the suspect parts of the system to isolate what is not working, or to test them in isolation. For example, you could either try to tap the UART line into the device and see if you get what is expected by looking at the bytes on a PC with a low level program, or you could try a program on the PC to inject what you think is the right sequence of bytes and see if the device responds as you expect.

Chances are that if the UART signal at the device looks OK (including the obvious issue of baud rate), then you have a protocol problem. In other words, somehow you're not sending the right data to the device. Early on in bringing up a system like this, I often use a low level test program on the PC that sends and receives individual bytes. I can type byte values in decimal, hex, and as ASCII character, and it displays everything it receives likewise. This can be very useful for verifying that you really do understand the protocol the device expects.

Do some of these experiments and tell us what you find. It would also help to provide some information on this device you are trying to talk to from the micro.

CAN can go up to 1 Mbit/s on busses up to a few 10s of meters. The passive state doesn't really slow down the signalling. A total of 60 Ω is pulling the lines together, which will make them do so quite fast. I have looked at bits on a CAN bus with a scope, and the edges have been nice and solid in both directions. Think of the fact that the passive state is still driving the bus together as if it were shorted, but the drive impedance is at the characteristic impedance of the cable. A deliberate driver would have the same impedance, so there is really no difference.

What limits the length of a CAN bus in practise is that the signal must do a round trip between the two most distant nodes in a fraction of a bit time. This is necessary for the collision detection mechanism to work.

RS-485 and CAN are really in two different leagues. RS-485 throws you a electrical spec for a multi-drop bus, and that's it. CAN defines whole messages with IDs and data bytes, a checksum, control information, collision detection, some error detection and error handling, and full use of the bandwidth under heavy loading, all on a true peer to peer network. In addition, this plus automatic sending retry is built into hardware on a number of low cost microcontrollers.

You could in theory implement something like this using RS-485 as the underlying bus, but getting all the protocol details right for reliable operation in all the corner cases is nowhere near as easy as some people seem to think.