Зв'язок між декількома мікроконтролерами

Я хотів би почати впроваджувати систему, що складається з N мікроконтролерів (N> = 2 MCU), але я хотів би знати можливості дозволити їм спілкуватися один з одним.

В ідеалі мікроконтролери (N-1) розміщуються всередині будинку, виконуючи функції клієнтів, а останній ("серверний") підключається до ПК через USB. Зараз у мене проблеми - як підключити ці (N-1) мікроконтролери до "сервера". Клієнтські MCU виконують дуже прості завдання, тому, можливо, це не вдале рішення використовувати ARM для виконання таких простих завдань лише тому, що вони забезпечують CAN / PHY-MAC .

Зв'язок не відбуватиметься не один раз кожні кілька хвилин на більшості пристроїв та на вимогу інших. Швидкість не дуже критична (повідомлення коротке): 1 Мбіт / с. Я думаю, що ВИЩО надмірний для моїх цілей.

MCU, які я планую використовувати, є наступними.

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

Я б хотів уникнути ПІК, якщо це можливо (особистий вибір), просто тому, що можливостей їх програмування менше (всі перелічені вище мають більш-менш інструменти з відкритим кодом, а також деякі офіційні засоби).

Я знаю, що деякі зброї забезпечують функціональність CAN, і я не дуже впевнений в інших.

Саме зараз я придумав такі можливості:

1. Простий GPIO для надсилання даних (скажімо,> 16 біт у HIGH, щоб вказати початок повідомлення;> 16 біт у LOW, щоб вказати кінець повідомлення). Однак він повинен бути на стандартній частоті << (frequency_client, frequency_server), щоб мати можливість виявляти всі біти. На клієнтський MCU потрібен лише один кабель.
2. RS-232 : Я думаю, що це далеко не найчастіше використовується протокол зв'язку, але я не знаю, наскільки добре він масштабується. Я зараз розглядаю до 64 клієнтських MCU (можливо, пізніше)
3. USB: AFAIK це, як правило, як RS-232, але я не думаю, що це дуже добре розширюється в цьому випадку (хоча USB підтримує безліч пристроїв - 255, якщо я правильно пам'ятаю - це може бути надто складним для цієї програми)
4. RJ45 / Ethernet: це те, що я дуже хотів би використовувати, тому що він дозволяє передавати на великі відстані без проблем (принаймні, із екранованим> кабелем Cat 6 ). Проблема - вартість (PHY, MAC, трансформатор, ...). Я не знаю, чи можна насправді добре спаяти його вдома. Таким чином, мені не знадобиться клієнтський MCU
5. Wireless / ZigBee : модулі дуже дорогі, хоча це може бути шлях, щоб уникнути "спагетті" за столом
6. РЧ-модулі / приймачі: Я говорю про тих, що знаходяться в діапазоні 300 МГц - 1 ГГц, тому вдома вони повинні бути важкими для пайки. Усі модулі вбудовані, але вони є такими ж дорогими, як і ZigBee (принаймні, модулі РФ у 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 кбіт / с, що звучить як велика пропускна здатність для ваших потреб. Останній вузол може бути відключеним від інтерфейсу CAN до інтерфейсу CAN. Це дозволяє програмному забезпеченню в комп'ютері надсилати повідомлення CAN і бачити всі повідомлення на шині. Решта - це програмне забезпечення, якщо ви хочете представити це зовнішньому світу як TCP-сервер чи щось подібне.

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

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

Ваші причини уникати ПІК не мають жодного сенсу. Існує багато проектів для програмістів, щоб створити свій власний. Один - це мій 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 є складними, але це стосується будь-якої компетентної реалізації RS-485. Зауважимо, що кілька відомих протоколів на основі RS-485 були замінені новішими версіями на основі CAN. NMEA2000 - один із прикладів такого нового стандарту на основі CAN. Є ще один автомобільний стандарт J-J1708 (заснований на RS-485), який зараз значно застарілий у порівнянні з CAN-OBD-II та J-1939.

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

RS232 можна легко реалізувати, але він стане справжньою проблемою, якщо ви спробуєте реалізувати зв’язок більше ніж 2 вузлів (тому що це не побудовано для цієї мети).

Ethernet теж може бути приємним варіантом, оскільки ви згадали про деякі взаємозв'язки хостів і клієнтів, що природно для впровадження Ethernet.

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

Якщо, наприклад, він використовується з традиційним мережевим кабелем категорії 5e, ви можете мати дві пари для передачі даних в обох напрямках (використовуючи повний дуплексний модуль), мати одну пару або, можливо, навіть один провід як загальну землю, а решта для переговорів який пристрій збирається передавати в який момент. Трохи складніше, що RS-232, але модулі коштують дешевше, ніж CAN і Ethernet, а межа кабелю - 1200 м. Мінусом є те, що вам доведеться скласти власний протокол вирішення конфлікту. Можливо, пристрій, який хоче передавати, перевірить один виділений провід і побачить, чи високий він. Якщо це не так, підніміть його високо і почніть спілкуватися, а якщо є, дочекайтеся випадкового періоду часу. Ще я не впевнений, наскільки добре це би спрацювало на великих відстанях.

Я вибрав би шину RS-485, яка працює з даними Manchester Encoding .

RS-485, оскільки:

• Це дешево
• Це легко здійснити
• Використовує lo power
• Дозволяє на великі відстані (до 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, з моїм кращим вибором, МОЖ.

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

• Ethernet: роз'єм RJ45, магнітика, чип Phy (якщо вони не вбудовані в MCU). Також потрібні вимикачі та кабель від вимикача до кожного вузла. Кожна друкована плата потребує досить кількох конденсаторів та кінцевих резисторів, можливо, і феритів. Потрібен хороший дизайн друкованої плати.
• МОЖЛИВО: мікросхема приймача (дешево), будь-який роз'єм, дешевий кабель може переходити з одного вузла на інший в петлі навколо сайту. Потрібен лише один конденсатор для приймача та один кінцевий резистор на кожному кінці шини.

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

LPC11C24 від NXP також інтегрує приймач CAN, і CANOpen підтримується в ПЗУ (не з'їдаючи 32-мільйонний Flash даних). Плата LPCXpresso 11c24 коштує 20 EUR (надала місця для роз'єму DB9), тому ви дійсно просто додаєте дроти :-)

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

TLDR : Не особливо дешева, але надійна в деяких випадках використання.

Дивлячись поза коробкою, тут можуть бути деякі інші рішення, такі як наступний чіп, на який я натрапив останнім часом. Звичайно, все залежить від того, що ти хочеш зробити. Щось на зразок UART приходить в голову, якщо ви отримали обидва MCU на одній платі або навіть плануєте захистити ESD вручну, якщо вони відокремлені.

Майстер і рішення пристрою для додатків IO-Link

L6360   Master
L6362A  Device

Коли ви розглядаєте таке рішення:

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

Мені це звучало цікаво, тому я думав, що викладу його там.

Це залежить від масштабу вашої програми та ваших мікроконтролерів. Ви згадали про Atmel крихітні / мега, вони зовсім маленькі. У їхньому випадку I2C / SPI / UART мають перевагу в тому, що вони реалізовані в апараті, і тому вони прості у використанні.