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

20

Я хотел бы начать реализацию системы, состоящей из 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).

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

user51166
источник
2
Есть PIC с функцией CAN, и есть бесплатные официальные инструменты для их программирования с документацией.
AndrejaKo
@AndrejaKo PIC на самом деле не имеет компилятора с открытым исходным кодом, такого как AVR или, по крайней мере, MSP430. Это правда, что они часто предоставляют больше функций, чем MCU, которые я перечислил выше, по той же цене. Мне не очень нравятся эти большие различия между семействами 16/16/18/24/32 и тем, что у некоторых из них вообще нет бесплатного компилятора (я думаю, что это PIC18).
user51166
2
На самом деле PIC18 имеет бесплатный компилятор, как и другие. Главный бонус других семей заключается в том, что они работают с GCC. В лагере с открытым исходным кодом есть компилятор Small device C, который должен поддерживать устройства PIC 16 и PIC 18.
AndrejaKo
2
Если вы еще не знакомы ни с одним из упомянутых вами ОК, имейте в виду, что начинать с ARM гораздо сложнее, чем, например, с PIC или AVR, особенно если вы хотите использовать открытый исходный код. С ARM поставщики не проектируют ядро, а также обычно не предоставляют IDE, что может сделать все немного сложнее. Хорошо, если, например, Microchip предоставляет и поддерживает все в случае с PIC.
Оли Глейзер
@OliGlaser Ну ... правда, что инструменты с открытым исходным кодом для ARM могут быть немного сложны в использовании (я пробовал плату обнаружения STM32, и она не очень хорошо работала), многие поставщики предлагают IDE, которая - с его плюсы и минусы - основаны на затмениях и свободны от ограничений: например, LPCXpresso (NXP) и Code Composer Studio (TI) (не с открытым исходным кодом, но, по крайней мере, они поддерживаются). AVR, с другой стороны, довольно хорошо поддерживаются на стороне открытого исходного кода, а также в ATMEL STUDIO 6. Никакого опыта работы с PIC. Кодируется только AVR (ассемблер) и ARM (C, на NDS).
user51166

Ответы:

22

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.

Олин Латроп
источник
Сборка моей собственной пользовательской платы полезна при интеграции MCU с оборудованием, которое у него есть. Для целей разработки я согласен, что набор для разработки - лучший способ. Моя причина избегать PIC - это отсутствие компиляторов с открытым исходным кодом (есть некоторые бесплатные, но не для PIC18, например), а не отсутствие общедоступных схем, хотя они предоставляют некоторые дополнительные функции, которые вы можете не найти в других MCU (Ethernet, МОЧЬ, ...). А I2C это автобус AFAIK.
user51166
@ user51166 - Есть бесплатные компиляторы PIC18, предоставляемые микрочипом. Смотрите страницу продукта MPLAB XC Compilers . В нем также перечислены компиляторы для 16-битного и 32-битного uC.
PetPaulsen
@ user51166 Также есть бесплатный компилятор C18 .
AndrejaKo
@PetPaulsen Странно. Я почти уверен, что видел месяц назад страницу со списком всех свободно доступных для загрузки компиляторов (PIC16 / 24/32), за исключением PIC18, который не был вызван какой-то проблемой лицензирования. Вероятно, это было решено с переходом MPLAB C Compiler -> MPLAB XC Compiler, хотя я не уверен. Кроме того, они «только» предлагают бесплатную версию, которая не оптимизирует ваш код, а не полностью компилятор с открытым исходным кодом. Тем не менее, это лучше, чем ничего;)
user51166
@user: Я считаю, что все компиляторы Microchip имеют бесплатные версии, которые отличаются только от полных тем, что некоторые оптимизации отключены. Ассемблер, библиотекарь, компоновщик и симулятор включены в бесплатный пакет MPLAB. Здесь действительно нет проблем.
Олин Латроп
6

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

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

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

JeeShen Lee
источник
Каковы преимущества CAN над Ethernet, например? Дешевле, наверное, но кроме этого, что еще?
user51166
@ user51166 - CAN не только дешевле, но и намного дешевле. Это не только легче, но и намного проще.
Ракетный магнит
@Rocketmagnet: пожалуйста, объясните немного больше. В большинстве случаев вам все равно нужна встроенная микросхема (хотя PIC, ARM и другие - часто включают функцию CAN, они немного дороже). С аппаратной точки зрения я не вижу, как это может быть намного дешевле, поскольку IC можно найти за 0,5-1,0 $ за штуку. Я полагаю, вы имеете в виду проще с программной точки зрения, верно? Максимальная дистанция CAN составляет ~ 500 метров, что, безусловно, достаточно в моем случае, но - только для информации - будут ли аналогичные альтернативы для более длинных расстояний (возможно, оптическое волокно)?
user51166
4

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

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

AndrejaKo
источник
Чтобы не беспокоиться о слишком больших расстояниях, я не планирую проходить более 100 метров в данный момент.
user51166
Почему, кстати, сегодня стек-обмен не принимает @ <username>? Каждый раз, когда я ставлю один, он полностью удаляется (не только символ @) ...
user51166
@ user51166 - Создатель ответа автоматически уведомляется, поэтому «\ @-noise» автоматически удаляется. (Мой \ @ user51166 не был удален, поскольку вы не являетесь создателем этого ответа)
PetPaulsen
Интересно то, что я не получил ни одного уведомления здесь.
AndrejaKo
4

Я бы выбрал шину 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:

Пример сообщения

Бруно Феррейра
источник
Любое предложение для таких хороших трансиверов, возможно, дешево?
user51166
Кроме того, @AndrejaKo предположил, что RS-485 не предлагает протокол разрешения конфликтов.
user51166
Выбор трансиверов зависит от напряжения, которое вы собираетесь использовать. Разрешение конфликта должно быть сделано в программном обеспечении с проверкой CRC, мониторингом линии или обоими способами.
Бруно Феррейра
Если у вас есть один мастер, вы также можете реализовать некоторую адресацию или пошаговую передачу.
Бруно Феррейра
Не совсем мастер. Просто «сервер», который действует как интерфейс к ПК через USB. Клиенты должны отправлять ему сообщения автоматически, однако ...
user51166
3

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

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

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

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

Rocketmagnet
источник
0

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

Дражен цика
источник
0

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

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

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

Mehrad
источник
-3

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

ВСЗ
источник
3
Хорошо, но как это решает проблему ОП? IIC - это автобус, но он совсем не подходит для больших расстояний, например, по всему дому. Это несимметричный и относительно высокий импеданс. SPI является шиной, но управляется одним ведущим устройством с отдельной линией выбора ведомого устройства для каждого устройства. Вы могли бы реализовать каждую линию в виде дифференциальной пары с линейными драйверами и приемником, но у вас все еще есть точка, чтобы указать от главного до подчиненного вопроса выбора. UART строго указывает на точку. Непонятно, как вы собираетесь использовать их в ситуации ОП.
Олин Латроп