Сеть Arduino с минимумом проводов

rs485 network

Для системы управления парковкой я собираюсь создать сеть Arduino.

Arduino с ультразвуковым датчиком будет размещен над каждым парковочным местом. Если автомобиль припаркован в определенном месте, Arduino сообщит об этом мастеру (ПК) и также включит КРАСНЫЙ свет.

Я не уверен, как сделать сеть с минимумом проводов. Я думаю, что RS485 подойдет для этой цели.

В сети будет около 200 Arduino. У меня есть следующие вопросы:

  1. Стоит ли мне использовать протокол RS485 или что-то другое?
  2. Может ли RS485 поддерживать 200 устройств, поскольку будет только короткая связь (т. е. идентификатор устройства и статус парковки)?
  3. Я планирую проложить кабель CAT6. Две пары будут использоваться для передачи электроэнергии, а две пары будут доступны для связи.

, 👍3

Обсуждение

Где вопрос в третьем пункте?, @Greenonline

Подробности о кабелях приведены, так что если у кого-то есть лучший метод связи по 4 проводам, я могу легко им воспользоваться., @umair


2 ответа

3

Для меня это звучит как работа для CAN. Это текущий стандарт де-факто для промышленных межблочных кабельных соединений. Он используется не только в автомобилях, но и для управления лифтами и почти всеми другими современными промышленными распределенными приложениями.

Обратите внимание, что CAN разработан для поддержки только до 30 узлов, поэтому вам нужно будет разделить вашу сеть на секции и объединить группы узлов в одну подсеть. Для 200 узлов вам может понадобиться 10 подсетей, то есть 20 узлов, соединенных вместе в один суперузел, который затем подключается к «магистральной» шине CAN.

Однако CAN может работать на более низких скоростях передачи данных, чем обычно, и это увеличивает количество узлов, которые вы можете иметь в любом сегменте сети. Потенциально (если позволяет емкость шины) он поддерживает тысячи узлов.

Другой вариант — использовать CAN для соединения нескольких «главных» узлов в магистральную сеть, а затем эти «главные» узлы подключаются к нескольким подузлам с помощью LIN (что дешевле в реализации, чем CAN).

LIN может поддерживать максимум 15 узлов (плюс один главный узел) на сеть, поэтому теоретически можно получить максимум 29*15 (предполагая, что 1 узел CAN — это подключение к ПК) или 435 узлов.

Вы также можете использовать RS-485, но он также ограничен примерно 30 «единичными нагрузками», а количество узлов, которые вы можете разместить на одном сегменте, зависит от «нагрузки», которую накладывает каждый узел. На практике редко бывает больше 30-40 узлов на одном сегменте, и потребуется группирование узлов в подсети (как выше с CAN/LIN). Поэтому вы можете также использовать текущий стандарт для этого вида связи и использовать CAN/LIN.

,

Обратите внимание, что в то время как ограничение на количество узлов LIN является жестким, CAN будет отлично работать с невероятно большим количеством узлов, если вы выберете столь же смехотворно низкую скорость передачи данных., @Dmitry Grigoryev

@DmitryGrigoryev Я не знаком со "стандартным" протоколом CAN. Поддерживает ли он больше узлов или вам придется использовать нестандартный протокол?, @Majenko

CAN имеет 11-битное адресное поле (а расширенный CAN увеличивает его до 29), что достаточно для 200 устройств. Стандартные скорости передачи данных CAN начинаются со 125 кбит/с (поддержка ~30 узлов на расстоянии ~500 м), но большинство трансиверов можно настроить на гораздо более низкие скорости передачи данных, например, 16 кбит/с., @Dmitry Grigoryev

@DmitryGrigoryev Звучит еще более идеально., @Majenko

Хм, звучит здорово. Я не очень хорошо знаком с сетью CAN. Я проверю в Google и скоро вернусь. Но если взглянуть на это вкратце, то это выглядит как дорогостоящий выбор. Поскольку RS485 и CAN могут поддерживать почти одинаковое количество узлов в зависимости от нагрузки. Rs485 — гораздо более дешевое решение. Но, кстати, теперь я совершенно ясно понимаю, что мне нужно разделить свою сеть на небольшие части. Большое спасибо, чувак, @umair

@Majenko Лично я бы сказал, что в этом приложении (один ведущий и несколько приемников) RS485 был бы лучше. CAN более полезен, когда у вас асинхронная сеть (она так называется?), где узлы могут общаться по своему усмотрению и есть некоторые приоритеты, которые нужно соблюдать. Каковы, по вашему мнению, преимущества CAN в этом случае? RS485 намного дешевле (можно использовать периферийное устройство UART, тогда как периферийные устройства CAN не интегрированы в более дешевые uC), @frarugi87

@frarugi87 CAN — это текущий стандарт для промышленных приложений. Если вы придерживаетесь стандарта, то когда кто-то другой придет после вас, чтобы его обслуживать или обновлять и т. д., он сможет легче понять, о чем идет речь., @Majenko

0

Что касается вашего третьего пункта, кабель CAT6 может работать не так хорошо, как вы ожидаете, для подачи питания в зависимости от выбранной вами топологии. Наиболее распространенная разновидность CAT6 использует провода AWG24 с сопротивлением около 0,085 Ом/м, поэтому 100-метровый кусок такого кабеля будет иметь сопротивление около 17 Ом. Предполагая ток 100 мА, вы потеряете 1,7 В в кабеле, поэтому если вы подадите на него 5 В, нагрузка увидит только 3,3 В.

Это еще одна причина разделить вашу сеть на сегменты. Если бы я реализовал этот проект, я бы запитал «магистральный» кабель более высоким напряжением (12–24 В) и установил бы DC-DC-преобразователи, вырабатывающие 5 В локально в каждом узле верхнего уровня.

Судя по комментариям, вы ищете решения, которые позволят вам использовать стандартные UART для связи. Конечно, вы можете использовать RS485 (вам все равно понадобится несколько сегментов). В противном случае я советую вам посмотреть, как реализован LIN: по сути, сигнал UART 19200 бит/с делается с открытым стоком (чтобы объединить все пары TX/RX в один провод) и усиливается до 12 В для помехоустойчивости. С точки зрения программного обеспечения, ведущее устройство отправляет кадр, включающий адрес ведомого устройства, и ждет ответа, затем обращается к следующему ведомому устройству и так далее. Ведомые устройства отвечают только тогда, когда получают кадр со своим адресом.

Если вы не хотите тратить дополнительные усилия и внедрять что-то стандартное, то хотя бы изучение существующей спецификации при внедрении собственного решения избавит вас от множества проблем.

,

Да, вы абсолютно правы. И я тоже планировал подать питание 12 В с регулятором напряжения. В разных точках., @umair

@umair обратите внимание, что Дмитрий предложил использовать «DC-DC-преобразователи»; не используйте стандартный «регулятор напряжения» (который обычно линейный), используйте импульсный преобразователь, @frarugi87

@frarugi87 Если только автор не хочет разморозить парковку зимой :), @Dmitry Grigoryev

@DmitryGrigoryev "это не баг, это фича" ;), @frarugi87

Смотрите также: