Я хотел бы начать реализацию системы, состоящей из 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, и я не уверен в других.
Прямо сейчас я придумал эти возможности:
- Простой GPIO для отправки данных (скажем,> 16 битов в HIGH, чтобы указать начало сообщения,> 16 битов в LOW, чтобы указать конец сообщения). Однако он должен быть на стандартной частоте << (Frequency_Client, Frequency_Server), чтобы иметь возможность обнаруживать все биты. Требуется только один кабель для каждого клиентского MCU.
- RS-232 : Я думаю, что это наиболее часто используемый протокол связи, но я не знаю, насколько хорошо он масштабируется. Я рассматриваю до 64 клиентских микроконтроллеров прямо сейчас (возможно, позже)
- USB: AFAIK это в основном как RS-232, но я не думаю, что в этом случае он очень хорошо масштабируется (хотя USB поддерживает множество устройств - 255, если я правильно помню - это может быть слишком сложно для этого приложения)
- RJ45 / Ethernet: это то, что я действительно хотел бы использовать, потому что он позволяет без проблем передавать на большие расстояния (по крайней мере, с экранированным кабелем > 6 ). Проблема в стоимости (PHY, MAC, трансформатор, ...). Я не знаю, можете ли вы действительно хорошо спаять это дома, хотя. Таким образом, мне не нужен клиент MCU
- Wireless / ZigBee : модули очень дороги, хотя это может быть путь, чтобы избежать "спагетти" за столом
- РЧ-модули / приемопередатчики: я говорю о тех, кто работает в полосе 300 МГц - 1 ГГц, поэтому их трудно припаять дома. Все модули встроены, но они такие же дорогие, как ZigBee (по крайней мере, модули RF в Mouser, в Sparkfun, кажется, дешевле).
- МОЧЬ? Это кажется очень надежным. Несмотря на то, что я не планирую использовать его в автомобильной промышленности, он все еще может быть хорошей альтернативой.
- I²C / SPI / UART ? Опять же - лучше избегайте "спагетти" с кабелями, если это возможно
- ПЛК на самом деле не вариант. Производительность снижается довольно быстро, так как длина увеличивается и зависит от емкостной нагрузки электросети. Я думаю, что цена примерно такая же, как 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 потому что:
Манчестерское кодирование потому что:
Для целостности данных сообщение может включать в себя длину и поле CRC.
Пример функции CRC:
CRC_INIT
иCRC_POLY
являются произвольными значениями, которые используются для вычисления CRC.Пример сообщения с полями длины и CRC:
источник
Позвольте мне сравнить ваш предпочтительный выбор, Ethernet, с моим предпочтительным выбором, CAN.
Необходимые компоненты:
Вы говорите о микроконтроллерах за 1 доллар. Существует гораздо больше, чем стоимость шины, чем MCU. Вам нужно будет сложить общую стоимость каждого решения, чтобы узнать, какое из них на самом деле дешевле. Сложите стоимость MCU, разъемов, трансиверов, пассивных компонентов, печатных плат, кабелей и т. Д.
источник
LPC11C24 от NXP также имеет встроенный CAN-приемопередатчик и CANOpen, поддерживаемый в ПЗУ (без потери флэш-памяти 32 Кбайт). Плата LPCXpresso 11c24 стоит 20 евро (есть место для разъема DB9), так что вы просто добавляете провода :-)
источник
Репост от другого подобного вопроса. Недорогая простая связь между двумя микроконтроллерами
TLDR : Не особенно дешево, но надежно подходит в некоторых случаях.
Если взглянуть за пределы коробки, то здесь могут быть и другие решения, такие как следующий чип, который я недавно натолкнул. Конечно, все зависит от того, что вы хотите сделать. Нечто подобное UART приходит на ум, если вы установили оба MCU на одной плате или даже планируете ESD защитить их вручную, если они разделены.
Мастер и устройство решение для приложений IO-Link
Когда бы вы рассмотрели такое решение:
Vcc(in) 7~30v, Vdd(out) 3.3/5v
Это звучало интересно для меня, так что я подумал, что выложу это туда.
источник
Это зависит от масштаба вашего приложения и ваших микроконтроллеров. Вы упомянули Atmel Tiny / Mega, они довольно маленькие. В их случае преимущество I2C / SPI / UART состоит в том, что они реализованы аппаратно и поэтому просты в использовании.
источник