Помощь в выборе между RS485 или CAN [закрыто]

ПРОБЛЕМА

Я создаю плату управления роботом для подключения к Raspberry Pi в качестве хобби. Мне нравятся специализированные платы для различных функций, и я изучаю решения для коммуникационной шины. В прошлом я пробовал:

  • 5V UART: проблемы с шумом
  • I2C: просто не работает с шумом
  • Пластиковые оптические волокна POF: классные, но дорогие и большие
  • RS485 по аудиокабелю с разъемами 3,5 мм и настраиваемым протоколом: работает как часы. Мне нравится, насколько недорогие разъемы и кабели.

Ниже приведено изображение для справки одного из роботов, которые я сделал в прошлом, используя шину RS485 с настраиваемым протоколом через аудиокабели с разъемом 3,5 мм.

Платы двигателей с шиной RS485 с аудиоразъемами 3,5 мм

Ниже изображение для справки моей последней версии робота-шляпы Raspberry Pi. Я хочу добавить дисплей и разъемы для коммуникационной шины, добавить улучшенный регулятор мощности и перенести элементы управления двигателем и сервоприводом на подчиненные платы.

введите описание изображения здесь

ИДЕИ

Я думаю либо о реализации шины CAN, либо о шине RS485 с менее специализированным протоколом, который имеет некоторое применение на рынке.
Вот пример ведомого устройства, использующего шину CAN.
Вот пример ведомого устройства, использующего шину RS485 со своими пользовательскими протоколами.

Технические характеристики:

  • Три провода (два данных + один экран), поэтому я могу использовать аудиокабели и разъемы 3,5 мм для своих ведомых.
  • Я хочу, чтобы шина была менее индивидуальной, чтобы я мог прикрепить ее к существующим доскам объявлений.
  • пропускная способность 1 Мбит/с
  • Устойчив к шуму

ВОПРОС

Мне бы хотелось узнать, какую шину вы бы использовали в этом приложении, в частности, если есть шина, которую я не принял во внимание, предложение по стандартному протоколу через шину RS485 или ваши причины, по которым вы бы выбрали шину CAN. Спасибо за ваш вклад!

РЕШЕНИЕ

В RS485 не используются доминирующие протоколы, а CAN имеет большие накладные расходы на кадры данных.
Я решил реализовать два 3-контактных разъема 3,5 мм Jack с приемопередатчиком RS485, подключенным к AT4809 для аппаратного обеспечения. По шине RS485 я буду повторно использовать свой собственный протокол master-slave.

Ниже схема и начальное размещение компонентов.Схемы и начальное размещение

Для RS-485 требуется только приемопередатчик на rpi, для CAN требуется контроллер через spi/i2c. Выберите RS-485, идет прямо на заголовок gpio. Кроме того, обе шины по-прежнему требуют «общего» заземления, поэтому теоретически 3-проводной дополнительный экран. Тем не менее, этот вопрос лучше подходит для форума, такого как EEVblog.
Вы по-прежнему можете использовать CAN PHY и передавать на него данные UART, нет необходимости в контроллере CAN, если только нет необходимости в использовании протокола CAN. Точно так же RS-485 не обязательно совпадает с протоколом UART, даже если он обычно используется с ним.
Я бы спросил, почему так много шума, что все остальные протоколы связи не работают? Моторы, конечно, но эффект можно уменьшить с помощью демпферов и фильтров. А хорошая фильтрация и экранирование должны уменьшить влияние шума на сигнальные линии связи. В противном случае вы можете маскировать проблему с коммуникациями промышленного уровня только для того, чтобы шум вызывал проблемы в других местах.
Вы опаздываете на вечеринку, но одна из причин, по которой у вас проблемы с шумом, заключается в том, что проводка работает ужасно. Некоторые кабельные каналы, в которых кабели находятся вдали от силовой электроники и электроники привода, могут значительно улучшить ЭМС. То, что у вас есть в настоящее время, это около 20 антенн желтого цвета, улавливающих все электромагнитные помехи от плат и двигателей. Но тогда я не уверен, насколько хорош Rasp Pi в первую очередь для приложений, интенсивно использующих электромагнитные помехи (может быть, ему нужен пи-фильтр? ха-ха...). Однако RS-485 или CAN — правильный путь.

Ответы (1)

Боюсь, вы сравниваете яблоки с апельсинами.

RS-485 — это просто способ управления автобусом. Вы берете свой вывод UART, транслируете его через передатчик RS-485, принимаете его с помощью приемника, а затем передаете его в UART назначения. Очень просто.

CANBus - гораздо более сложное предложение. Вы должны кормить CAN-контроллер пакетами данных. Затем контроллер передает физическую шину получателю по гораздо более сложному протоколу, и получатель создает реконструированный пакет. По сути, два контроллера заменят ваши UART.

Что касается надежности, то CANBus лучше. Весь дополнительный мусор, который использует CANBus, идет на две цели: выбор одного из множества устройств, которые все подключены к шине, и обнаружение и исправление ошибок.

Когда вы говорите, что вам нужна пропускная способность 1 Мбит/с, вы никогда не получите ее от CANBus. Это правда, что вы можете управлять CANBus на частоте 1 МГц, но если вы отправляете 1 байт за раз, вы получите эффект только 140 кбит/с. Для отправки 1-байтового кадра CANBus требуется 58 тактовых циклов. Это правда, что можно управлять шиной на частоте 5 МГц, но это дает вам только эффективные 700 кбит/с.

Хотя, честно говоря, UART, работающий на частоте 1 МГц, будет иметь пропускную способность всего 700–800 кбит/с, в зависимости от вашего выбора настройки кадра, но вы легко можете управлять им быстрее.

См. https://en.wikipedia.org/wiki/CAN_bus для обзора.

Также нормально, если один источник CANBus обеспечивает питание 5 вольт для всех остальных устройств. Это означает, что вам нужно 4 сигнала на вашей шине, и аудиокабель не сможет их разрезать.

Ваше объяснение понятно. Я не люблю подавать питание вместе с com, потому что это обременяет требования к питанию мастера, а у ведомых очень разные требования к питанию. Я был бы в порядке, если бы скорость передачи сигнала составляла около 1 МГц, а эффективная полоса пропускания не составляла бы 1 Мбит / с (это много накладных расходов для CAN!)
Мой GD32VF103 имеет периферийные устройства UART и CAN. Вы бы посоветовали использовать CAN или протокол для использования на RS485?
@ 05032MendicantBias - 5 В от ведущего устройства CANBus используется только для управления приемопередающей частью контроллера CANBus. В результате потребляемая мощность прямо пропорциональна количеству приемопередатчиков, подключенных к шине.
@ 05032MendicantBias - Я не могу дать рекомендацию. Я не знаю ваших показателей. Например, есть ли у вашего периферийного устройства UART возможность RS485? Некоторые делают, некоторые нет. Если нет, то насколько важно обеспечить физический уровень? Вы не получите 1 Мбит/с от CANBus. Сколько вам на самом деле нужно? Если скорость превышает 140 кбит/с, CANBus отключается, если только вы не можете получить устройство на 5 Мбит/с. CANBus имеет шину TWP 120 Ом — насколько она близка к вашему аудиокабелю? Есть много других вопросов, но я просто не знаю достаточно, чтобы советовать вам.