Связь между несколькими микроконтроллерами

Я хотел бы начать реализацию системы, состоящей из N микроконтроллеров (N> = 2 микроконтроллеров), но я хотел бы знать возможности, позволяющие им общаться друг с другом.

В идеале (N-1) микроконтроллеры размещаются внутри дома, выступая в качестве клиентов, а последний («серверный») подключается к ПК через USB. Проблема, с которой я столкнулся сейчас, заключается в том, как подключить эти (N-1) микроконтроллеры к «серверу». Клиентские микроконтроллеры выполняют очень простые задачи, поэтому использование ARM для выполнения таких простых задач может оказаться не лучшим решением только потому, что они предоставляют CAN / PHY-MAC .

Связь будет происходить не чаще, чем раз в несколько минут для большинства устройств и по запросу для других. Скорость не очень критична (сообщение короткое): 1 Мбит / с. Я думаю, что это ПУТЬ излишним для моих целей.

MCU, которые я планирую использовать, следующие.

• Atmel AVR Tiny / Mega
• TI MSP430
• ARM Cortex M3 / M4
• (Возможно Atmel AVR UC3 - 32-разрядная версия)

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

Я знаю, что некоторые ARM обеспечивают функциональность CAN, и я не уверен в других.

Прямо сейчас я придумал эти возможности:

1. Простой GPIO для отправки данных (скажем,> 16 битов в HIGH, чтобы указать начало сообщения,> 16 битов в LOW, чтобы указать конец сообщения). Однако он должен быть на стандартной частоте << (Frequency_Client, Frequency_Server), чтобы иметь возможность обнаруживать все биты. Требуется только один кабель для каждого клиентского MCU.
2. RS-232 : Я думаю, что это наиболее часто используемый протокол связи, но я не знаю, насколько хорошо он масштабируется. Я рассматриваю до 64 клиентских микроконтроллеров прямо сейчас (возможно, позже)
3. USB: AFAIK это в основном как RS-232, но я не думаю, что в этом случае он очень хорошо масштабируется (хотя USB поддерживает множество устройств - 255, если я правильно помню - это может быть слишком сложно для этого приложения)
4. RJ45 / Ethernet: это то, что я действительно хотел бы использовать, потому что он позволяет без проблем передавать на большие расстояния (по крайней мере, с экранированным кабелем > 6 ). Проблема в стоимости (PHY, MAC, трансформатор, ...). Я не знаю, можете ли вы действительно хорошо спаять это дома, хотя. Таким образом, мне не нужен клиент MCU
5. Wireless / ZigBee : модули очень дороги, хотя это может быть путь, чтобы избежать "спагетти" за столом
6. РЧ-модули / приемопередатчики: я говорю о тех, кто работает в полосе 300 МГц - 1 ГГц, поэтому их трудно припаять дома. Все модули встроены, но они такие же дорогие, как ZigBee (по крайней мере, модули RF в Mouser, в Sparkfun, кажется, дешевле).
7. МОЧЬ? Это кажется очень надежным. Несмотря на то, что я не планирую использовать его в автомобильной промышленности, он все еще может быть хорошей альтернативой.
8. I²C / SPI / UART ? Опять же - лучше избегайте "спагетти" с кабелями, если это возможно
9. ПЛК на самом деле не вариант. Производительность снижается довольно быстро, так как длина увеличивается и зависит от емкостной нагрузки электросети. Я думаю, что цена примерно такая же, как Ethernet.

Кроме того, какой протокол будет «лучше» в случае одновременных передач (допустим, редкий случай, когда в одно и то же время начинают передавать два устройства: какой протокол обеспечивает наилучшую «систему управления конфликтами» / «систему управления конфликтами»?

Подводя итог : я хотел бы услышать, что может быть лучшим решением для распределенной клиентской системы, которая обеспечивает очень легкую передачу данных, учитывая гибкость (максимальное количество устройств, система управления конфликтами / коллизиями, ...), цену Легко сделать дома (пайка), ... Я бы хотел не тратить 20 $ только на коммуникационный модуль, но в то же время иметь 30 проводов за столом было бы плохо.

Решение, которое я сейчас себе представляю, состоит в том, чтобы выполнить базовую связь между соседними MCU с помощью GPIO или RS-232 ( дешево !) И использовать Ethernet / ZigBee / Wi-Fi по одному MCU на «зону» для связи с сервером ( дорого). , но это все еще намного дешевле, чем один модуль Ethernet на каждый клиентский MCU).

Вместо кабелей также можно использовать оптоволоконные / оптические волокна. Хотя необходимы дополнительные преобразования, и я не уверен, что это будет лучшим решением в этом случае. Я хотел бы услышать дополнительные детали о них.

CAN звучит наиболее применимо в этом случае. С помощью CAN можно обрабатывать расстояния внутри дома со скоростью 500 кбит / с, что соответствует вашим потребностям. Последний узел может быть готовым интерфейсом USB-CAN. Это позволяет программному обеспечению компьютера отправлять CAN-сообщения и видеть все сообщения на шине. Все остальное - программное обеспечение, если вы хотите представить это внешнему миру как TCP-сервер или что-то в этом роде.

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

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

Ваши причины избегать PIC не имеют никакого смысла. Есть много проектов для программистов для создания своих собственных. Одним из них является мой LProg , схема которого доступна внизу этой страницы. Тем не менее, создание собственного не будет экономически эффективным, если вы не цените свое время в пенни / час. Это также больше, чем просто программист. Вам понадобится что-то, что поможет с отладкой. Microchip PicKit 2 или 3 - это очень недорогие программисты и отладчики. Хотя у меня нет личного опыта с ними, я слышал, что другие регулярно их используют.

Добавлено:

Я вижу некоторые рекомендации для RS-485, но это не очень хорошая идея по сравнению с CAN. RS-485 является стандартом только для электричества. Это дифференциальная шина, поэтому она позволяет использовать несколько узлов и обладает хорошей помехоустойчивостью. Тем не менее, CAN имеет все это, а также многое другое. CAN также обычно реализуется как дифференциальная шина. Некоторые утверждают, что интерфейс RS-485 прост в электрическом интерфейсе. Это правда, но так же и МОЖЕТ. В любом случае это делает один чип. В случае CAN, MCP2551 является хорошим примером.

Таким образом, CAN и RS-485 имеют практически одинаковые преимущества в электрическом отношении. Большое преимущество CAN выше этого уровня. С RS-485 нет ничего выше этого уровня. Ты сам по себе. Можно разработать протокол, который будет иметь дело с арбитражем шины, проверкой пакетов, тайм-аутами, повторными попытками и т. Д., Но на самом деле получить это право намного сложнее, чем думает большинство людей.

Протокол CAN определяет пакеты, контрольные суммы, обработку коллизий, повторные попытки и т. Д. Он не только уже существует и продуман и протестирован, но и действительно большим преимуществом является то, что он реализован непосредственно в кремнии на многих микроконтроллерах. Микропрограмма взаимодействует с периферийным устройством CAN на уровне отправки и получения пакетов. Для отправки аппаратное обеспечение выполняет обнаружение столкновения, откат, повтор и генерацию контрольной суммы CRC. Для приема он выполняет обнаружение пакетов, настройку перекоса часов и проверку контрольной суммы CRC. Да, для периферийного устройства CAN потребуется больше встроенного программного обеспечения, чем для UART, такого как часто используется с RS-485, но в целом требуется намного меньше кода, поскольку кремний обрабатывает большую часть деталей протокола низкого уровня.

Короче говоря, RS-485 относится к прошлой эпохе и не имеет большого смысла для новых систем сегодня. Кажется, что главная проблема заключается в том, что люди, которые использовали RS-485 в прошлом, цепляются за него и думают, что CAN как-то «сложен». Низкие уровни CAN сложны, как и любая грамотная реализация RS-485. Обратите внимание, что несколько известных протоколов на основе RS-485 были заменены более новыми версиями на основе CAN. NMEA2000 является одним из примеров такого нового стандарта на основе CAN. Существует еще один автомобильный стандарт J-J1708 (на основе RS-485), который сейчас сильно устарел с CAN-OBD-II и J-1939.

Я бы порекомендовал контроллер с CAN, так как эта функция предназначена именно для сетевых целей контроллера.

RS232 может быть легко реализован, но он станет очень сложным, если вы попытаетесь установить связь более чем с двумя узлами (потому что это не для этой цели).

Ethernet также может быть хорошим вариантом, так как вы упомянули некоторые соединения между хостом и клиентами, что является естественным для реализации Ethernet.

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

Например, если он используется с традиционным сетевым кабелем категории 5e, у вас может быть две пары для передачи данных в обоих направлениях (с использованием дуплексного модуля), одна пара или, возможно, даже один провод в качестве общей земли, а остальные - для согласования. какое устройство будет передавать в какой момент. Это немного сложнее, чем RS-232, но модули дешевле, чем CAN и Ethernet, а ограничение кабеля составляет 1200 м. Недостатком является то, что вам придется создавать свой собственный протокол разрешения конфликтов. Может быть, устройство, которое хочет передать, проверит один выделенный провод и посмотрит, высоко ли оно. Если это не так, доведите его до максимума и начните общаться, а если это так, дождитесь случайного периода времени. Тем не менее, я не уверен, насколько хорошо это будет работать на больших расстояниях.

Я бы выбрал шину RS-485, работающую с данными Манчестерского Кодирования .

RS-485 потому что:

• Дешево
• Легко реализовать
• Использует энергию
• Позволяет на большие расстояния (до 1200 метров)
• Высокая скорость передачи данных (до 10 Мбит / с)
• Высокая невосприимчивость к помехам
• Есть трансиверы, которые позволяют до 256 устройств на одной шине
• Низкое количество деталей

Манчестерское кодирование потому что:

• Легко реализовать
• Самосинхронизируемый

Для целостности данных сообщение может включать в себя длину и поле CRC.

Пример функции CRC:

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITи CRC_POLYявляются произвольными значениями, которые используются для вычисления CRC.

Пример сообщения с полями длины и CRC:

Позвольте мне сравнить ваш предпочтительный выбор, Ethernet, с моим предпочтительным выбором, CAN.

Необходимые компоненты:

• Ethernet: разъем RJ45, магниты, чип Phy (если не интегрированы в MCU). Также нужны коммутаторы и кабель от коммутатора к каждому узлу. Каждой печатной плате требуется несколько конденсаторов и согласующих резисторов, возможно, и ферритов. Требуется хороший дизайн печатной платы.
• CAN: микросхема приемопередатчика (дешевая), любой разъем, дешевый кабель может прыгать от одного узла к другому в петле вокруг сайта. Нужен только один конденсатор для трансивера и один согласующий резистор на каждом конце шины.

Вы говорите о микроконтроллерах за 1 доллар. Существует гораздо больше, чем стоимость шины, чем MCU. Вам нужно будет сложить общую стоимость каждого решения, чтобы узнать, какое из них на самом деле дешевле. Сложите стоимость MCU, разъемов, трансиверов, пассивных компонентов, печатных плат, кабелей и т. Д.

LPC11C24 от NXP также имеет встроенный CAN-приемопередатчик и CANOpen, поддерживаемый в ПЗУ (без потери флэш-памяти 32 Кбайт). Плата LPCXpresso 11c24 стоит 20 евро (есть место для разъема DB9), так что вы просто добавляете провода :-)

Репост от другого подобного вопроса. Недорогая простая связь между двумя микроконтроллерами

TLDR : Не особенно дешево, но надежно подходит в некоторых случаях.

Если взглянуть за пределы коробки, то здесь могут быть и другие решения, такие как следующий чип, который я недавно натолкнул. Конечно, все зависит от того, что вы хотите сделать. Нечто подобное UART приходит на ум, если вы установили оба MCU на одной плате или даже планируете ESD защитить их вручную, если они разделены.

Мастер и устройство решение для приложений IO-Link

L6360   Master
L6362A  Device

Когда бы вы рассмотрели такое решение:

1. Граничные микросхемы поставляются полностью защищенными, что было бы важно, если бы каждый MCU располагался на отдельной плате и имел дело с открытыми контактами, например, с винтовым зажимом.
   • Обратная полярность
   • Перегрузка с функцией отключения
   • Перегретый
   • Пониженное напряжение и перенапряжение
   • GND и VCC открытый провод
2. Interoperability. Если кто-то собирается спроектировать другую сторону, все, что ему нужно знать, это направить данные через IO-Link.
3. Интегрированный регулятор Vcc(in) 7~30v, Vdd(out) 3.3/5v

Это звучало интересно для меня, так что я подумал, что выложу это туда.

Это зависит от масштаба вашего приложения и ваших микроконтроллеров. Вы упомянули Atmel Tiny / Mega, они довольно маленькие. В их случае преимущество I2C / SPI / UART состоит в том, что они реализованы аппаратно и поэтому просты в использовании.