Запуск шины CAN с приемопередатчиком RS-485

Недавно у меня было обсуждение, можно ли использовать приемопередатчики RS-485 для сети CAN-шины, чтобы получить гибкость для использования одного и того же оборудования либо в среде CAN, либо в полудуплексной сети RS-485, хотя и с другим программным обеспечением. .

схематический

смоделируйте эту схему - схема, созданная с помощью CircuitLab

Идея состоит в том, чтобы использовать драйвер шины RS-485, как обычно, при использовании платы в настройке RS-485. Что этот передатчик активируется DEN, когда кто-то хочет передать, и биты представлены на входе D, как обычно. Предусмотрены дополнительные подтягивающие и подтягивающие значения, чтобы обеспечить действительный уровень шины на открытых шинных линиях.

В режиме CAN вход D привязан к низкому (доминирующему) уровню, а вход DEN используется для представления потока битов при передаче. Когда DEN=1 (драйвер включен), шина управляется низким уровнем (доминантным), в противном случае линия остается рецессивной. Затем это должно имитировать природу шины CAN с открытым коллектором, поскольку только одно состояние активно управляется, а другое только пассивно подтягивается подтягивающими резисторами.

Часть, которую я рассматриваю, это SN64HVD11 и SN65HVD230 в качестве эталона для приемопередатчика 3V3 CAN.

Тайминги включения драйвера SN64HVD11 указаны как макс. 55 нс, а время спада ограничено 30 нс, что меньше сравнительных показателей «настоящего» CAN-драйвера.

Кто-нибудь пробовал это раньше? Есть ли проблемы, которые я могу полностью пропустить?

Пояснение: вся система предназначена для управления небольшими беспилотными транспортными средствами в академической сфере, поэтому совместимость со сторонними компонентами не считается важной.

Линии CAN-шины не работают при напряжении 2,5 В. RS-485 не используется при напряжении 5В и 0В соответственно.

Ответы (3)

Вероятно, его можно заставить работать, хотя я бы не назвал его «производственным решением»!

Одна вещь, которую вам нужно сделать, это инвертировать сигнал DEN, так как CAN имеет низкий, а не высокий доминирующий уровень.

Вам также необходимо настроить оконечную нагрузку, так как, хотя и CAN, и RS485 предназначены для оконечной нагрузки с помощью одного резистора 120 Ом на каждом конце шины, дополнительные резисторы смещения, которые обычно включают в себя RS485, будут немного подтягивать линии шины к напряжениям «либо стороне центральной точки», тогда как CAN должен рецессивно работать на холостом ходу при ~ 2,5 В на обеих линиях.

IIRC, до обнаружения доминирующего бита допускается около 0,5 В дифференциального напряжения.

Насколько я понимаю, и CAN, и RS-485 требуют оконечной нагрузки только с обоих концов. Для RS-485 резисторы смещения к земле и VCC часто предлагаются для обеспечения определенного логического уровня при разомкнутой цепи - мне интересно, должны ли эти резисторы смещения размещаться в каждом узле.
Инверсия сигнала DEN не должна представлять проблемы, поскольку контроллер CAN в любом случае подключен к драйверу шины через FPGA/CPLD.
Почти уверен, что rs485 использует один набор резисторов смещения для всей шины. Обычно они идут рядом с одним из двух терминаторов iirc.
В этом случае я неправильно истолковал схему, подразумевая, что терминация и смещение будут на каждом узле. Я все еще думаю, что CAN будет потенциально ненадежным, если там будут резисторы смещения RS485 (даже если только на концах шины)

Это будет работать, но уменьшит запас шума по сравнению с правильным RS485 или правильным CAN.

Большая проблема на стороне приема. Пороговое значение CAN обычно составляет 700 мВ (от +500 до +900 мВ). Пороговое значение RS485 обычно составляет 0 В (от -200 до +200 мВ).

Оконечная сеть находится только на каждом конце шины RS-485. Это разработано, чтобы дать разницу около 200 мВ между A и B (необходимо для приемопередатчиков RS485, чтобы гарантировать выход «1»).

Для приемника RS-485 вы получаете отрицательный запас по шуму при поиске недоминирующего состояния на шине CAN (в худшем случае), поскольку стандартные приемники RS485 имеют порог, указанный как +/- 200 мВ, где только CAN обещают 500мВ. Некоторые более новые приемопередатчики RS485 имеют типичное значение -50 мВ, в худшем случае 0 мВ, но они по-прежнему не обнаруживают 500 мВ.

Используя более новый трансивер и поменяв местами «B» и «A» так, чтобы CANL был RS485A, а CANH — RS485B, вы получили бы дополнительное смещение -200 мВ на шине, поэтому у приемника RS485 было бы больше шансов обнаружить не - преобладающее состояние (резисторы смещения будут тянуть противоположно доминантному биту, поэтому у приемопередатчика RS485 будет больше шансов увидеть кроссовер).

Потребуется некоторая работа над CPLD, чтобы инвертировать во всех нужных местах.

Когда я посмотрел на это, я решил установить оба приемопередатчика CAN и 485, оба подключенных к шине, и добавить логику, чтобы гарантировать, что только один из них будет активен одновременно.

Это правильный ответ. Сторону Tx можно заставить работать, но сторона Rx будет работать с неверными пороговыми значениями. Подключение приемопередатчика RS485 и CAN к одним и тем же линиям увеличит емкостную нагрузку, что может стать проблемой качества сигнала при высоких скоростях передачи.

Где-то я слышал, что некоторые из самых ранних приложений CAN использовали rs485. Не уверен, что современный CAN все еще совместим, но на первый взгляд они похожи. Проблема, которую я вижу, заключается в том, что приемопередатчик RS485 может иметь задержку включения после включения драйвера, но это будет упомянуто в техническом описании.

Но если протоколы действительно достаточно похожи, почему бы просто не добавить подтягивания вверх/вниз к шине rs485 и использовать трансивер CAN для обеих задач? Приемопередатчики CAN имеют ту же цену или дешевле и, похоже, имеют лучшую защиту от сбоев, чем приемопередатчики rs485 той же стоимости.

Это если они на самом деле совместимы, в чем я не уверен.