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

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 тоже. В любом случае это делает один чип. В случае с 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), который сейчас в значительной степени устарел с появлением OBD-II и J-1939 на основе CAN.

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

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

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

Я бы выбрал шину RS-485, работающую с данными Manchester Encoding .

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:

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

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

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

Требуемые компоненты:

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

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

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

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

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

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

Решение Master и Device для приложений IO-Link

L6360   Master
L6362A  Device

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

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

Мне это показалось интересным, поэтому я решил выложить его там.

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