Загальний протокол передачі даних з однієї системи в іншу?

Який загальний протокол для передачі інформації з однієї системи в іншу? Наприклад, скажімо, у нас є деяка інформація, зібрана від мікроконтролера протягом тривалого часу, який ми хочемо надіслати іншому мікроконтролеру. Я чув про інтерфейси SPI та I2C, але мені незрозуміло, коли ви використовуєте один метод над іншим і як ви його реалізуєте. Чи існують інші методи, крім SPI та I2C, які є загальними? Чи схожий процес впровадження для різних мікроконтролерів? Це в основному розбір байтів даних, які я роблю на приймальному мікроконтролері?

SPI та I2C подібні тим, що вони справді використовуються більше для приєднання периферійних пристроїв до контролера чи процесора, ніж для фактичної передачі даних між системами. USB - це ще один інтерфейс, який люди, схоже, хочуть розглядати як систему зв'язку, яка насправді є периферійною шиною приєднання.

Спілкування між системами не зовсім схоже на приєднання пристрою до шини. Приєднання до шини дозволяє процесору безпосередньо базіти на регістри в пристрої, тоді як комунікаційний інтерфейс дозволяє надсилати / приймати потоки даних. Пристрій, підключений на шині, як правило, потребує драйвера пристрою, тоді як для комунікацій це не має значення, що підключено на іншому кінці, що стосується хост-комп'ютера.

Звичайно, це стає постійно межею. Такі речі, як PCI та ISA - безперечно автобуси; I2C, SPI, USB - це, мабуть, шини; тоді як RS232, RS485 та Ethernet - безумовно, комунікаційні інтерфейси. Але є такі речі, як шина CAN та 1553, які, безумовно, стосуються переміщення даних, але дуже втягнутим чином.

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

Найнижчий шар - це фізичний шар , який фактично переміщує біти навколо.

• SPI та I²C знаходяться на невеликих відстанях всередині пристрою, де не так багато шуму, який може порушити передачу.

• Для не надто швидкого зв'язку на відстані до десятків метрів послідовний зв’язок через RS-232 - хороший вибір.

• Якщо шум більше або використовуються великі відстані, то, наприклад, в RS-485. Для більш швидкої передачі даних існує Ethernet, який стає все більш популярним.

• Тоді також існують різні бездротові стандарти.

Зверху на фізичному шарі є більше шарів, що впорядковують спосіб надсилання даних, для виявлення та виправлення помилок у передачі, маршрутизації в мережі та багато іншого. Наприклад, Інтернет-протокол - це досить складний стек з декількох шарів, як правило, поверх протоколу Ethernet.

Можна використовувати простий серійний UART (одна лінія Tx та одна Rx без дискретного годинника) і їх можна легко адаптувати для перетину між різними потенціалами (навіть первинними та вторинними ланцюгами) за допомогою оптоізоляторів чи магнітних ізоляторів .

Що стосується протоколів, все, що має визначені байти команд та якусь схему контрольної суми, буде добре працювати. Насправді не існує стандартного протоколу, який підходить для всіх типів зв'язку. I2C має стандарти сигналізації (визначає адресацію, зупинки, запуски тощо), але протокол того, що насправді повідомляється, залежить виключно від розробника.

Наприклад , PMBus - це протокол зв'язку джерела живлення, який використовує I2C як своє фізичне середовище.

Насправді не існує «загального» протоколу, те, що ви в кінцевому підсумку використовуєте, дуже залежить від програми. Для того, щоб ми дали вам кращу відповідь, нам потрібно зрозуміти ваші вимоги трохи краще. Ви згадуєте, що ви хотіли б мати окремі мікроконтролери, які розмовляють між собою як підсистеми.

Деякі запитання щодо цієї програми:

1. Чи буде в цьому проекті більше 2 мікроконтролерів?
2. Які ваші вимоги до швидкості та пропускної здатності? Як швидко потрібна інформація потрапляє туди і як часто ви надсилаєте / отримуєте дані?

Якщо ви відповіли "НІ" на питання 1:

Якщо в цьому проекті є лише 2 мікроконтролера, ви можете точно використовувати UART між ними. Якщо їм обом потрібно ініціювати зв’язок, скористайтеся керуванням потоком, інакше слід тривіально надсилати дані в одному напрямку. Здебільшого це повинно бути "досить швидким", враховуючи, що ви виберете одну з більш високих швидкостей передачі. I2C і SPI, як правило, корисні лише для master / slave архітектури.

Якщо ви відповіли ТАК (більше 2 контролерів) на питання 1:

• Якщо у вашому проекті є більше двох мікроконтролерів, який ініціює зв'язок? Чи буде це лише один головний контролер (тобто архітектура master-slave)? Або будь-яка з підсистем змогла б говорити в будь-який час?
• Чи є необхідність у будь-якій із підсистем спілкуватися між собою? наприклад: для пристроїв A, B і C: A може надсилати до B і C, а B може надсилати і A, і C і т.д.

Отже, зараз вам потрібно щось масштабніше, де ви можете переносити адреси, що адресовані, на загальну шину. Відповідь на ці подальші запитання допоможе вам вибрати між I2C та SPI (master-slave) або чимось на кшталт CAN (multi-master).

Мікроконтролер, швидше за все, має периферійну мережу UART, інші (особливо CAN) можуть бути доступні лише на більш чистих кінцевих чіпах. В будь-якому випадку повинно бути багато документації щодо використання цих периферійних пристроїв для переміщення байтів.

Як зазначав @Jon, одне питання у виборі комунікаційного інтерфейсу полягає в тому, чи завжди одна організація несе відповідальність за ініціювання комунікацій, чи може бути більш ніж одна організація такою відповідальною. Пов'язане питання полягає в тому, чи завжди одна організація буде готова отримувати непотрібні повідомлення. SPI часто використовується в програмах, де одна сторона завжди буде готова приймати повідомлення. Наприклад, щось подібне до 74HC595 зсувного регістра, ніколи не "зайняте". Хоча SPI хороший для зв'язку між мікроконтролером та обладнанням, яким мікроконтролер повинен керувати, він дійсно не корисний для зв'язку між двома мікроконтролерами. Коли два процесори з обладнанням I2C використовують його для спілкування, програмне забезпечення може зайняти стільки часу, скільки воно хоче (в межах дуже щедрих обмежень), щоб вирішити, що відбувається, не спричиняючи втрати даних. Якби процесору потрібно було витратити 100 мікросекунд, щоб обробити кожен вхідний байт, це суттєво обмежило б пропускну здатність, але відправник сповільниться достатньо, щоб приймач не вийшов. Єдиний спосіб, який, як правило, може статися з SPI - це якщо у кожного є окремий провід для рукостискання.

I2C - це справді чудовий протокол. Найбільші обмеження, які не дозволяють йому бути найдосконалішим протоколом, можна уявити

1. Його швидкість дещо обмежена; SPI може йти набагато швидше, і навіть UART іноді можуть йти трохи швидше
2. (2) Хоча дуже зручно, що I2C потребує лише двох проводів, обидва дроти повинні бути здатні до двонаправленого зв'язку з відкритим колектором. Це ускладнює передачу I2C через ретранслятори.

Особисто мені хотілося б, щоб постачальники контролерів підтримували трижильний варіант SPI, який включав рукостискання. Я не знаю жодного контролера, який це робить.

Ні в якому конкретному порядку, здається, що найпопулярніші екземпляри фізичного рівня для 2 процесорів у тому ж полі:

• SPI ланцюга ромашок (наприклад, використовуваних JTAG)
• SPI Select-per-slave SPI
• "TTL-рівень RS-232" aka "асинхронний послідовний зв'язок старт-стоп" (безпосередньо підключення штифта UART TX одного процесора до штифта UART RX іншого процесора)
• I2C
• 8-бітні дані + строба (наприклад, паралельний порт принтера IEEE 1284)
• спільна пам'ять (лише один процесор одночасно керує шиною адреси / даних / управління)

Ці екземпляри фізичного рівня (як і інші екземпляри фізичного рівня для 2 процесорів в окремих полях), як правило, забезпечують потік байтів до програмного забезпечення, яке реалізує більш високі рівні системи зв'язку.

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

Протокол для передачі інформації з одного процесора до іншого процесора майже завжди включає інтерпретацію потоку байтів як серії пакетів:

1. преамбула
2. заголовок
3. (можливо, уникнути) серіалізованих даних
4. причіп

Деякі люди, схоже, полюбляють складати абсолютно нові, нестандартні, несумісні протоколи шляхом змішування та узгодження (2) одного з багатьох видів структури заголовків із (3a) одним із багатьох видів серіалізуючих даних із (3b) одним із багатьох видів уникаючи цих серіалізованих даних за допомогою (4) одного з багатьох видів трейлера.

Деякі з найпростіших протоколів інкапсуляції даних у пакет включають:

• три байта протоколу Mini SSC
• формат мережі

Трохи складніші протоколи для інкапсуляції даних у пакет включають:

• vscp - дуже простий протокол управління
• IP через послідовне з'єднання

Перелік протоколів на сайті

• загальні протоколи, що використовуються у вбудованих системах
• Послідовне програмування: Формування пакетів даних

Вам може сподобатися, читаючи "Фольклор дизайну протоколу" Радіа Перлман, який описує, як дизайн протоколу може піти не так.

Немає жодного "загального" протоколу. Вибір може (наприклад) залежати від:

• відстань
• необхідна пропускна здатність
• наявність спеціальної периферії
• рівень шуму
• потреба в оптичній ізоляції
• критичність (допустимий показник відмов)
• потужність центрального процесора на обох кінцях
• доступні штифти вводу / виводу на обох кінцях

У багатьох випадках ви повинні відключити фізичний рівень (рівень сигналу) від рівня каналу передачі даних (+/- спосіб кодування даних) (перевірте модель OSI, нижній 2,4 шари). Можливі фіаскальні шари, наприклад:

• прості 5V або 3.3V або навіть 1.8V TTL
• будь-яке з перерахованого вище, але відкритий колектор замість натискання
• врівноважена сигналізація напруги низької напруги (часто використовується з FPGA)
• збалансований більш високий волат (RS485, RS432)
• однокінцеві вищі напруги (RS232)
• збалансований трафік (різні версії Ethernet, PDIF-аудіо)
• оптичний (оптичний Ethernet, toslink)

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

Є багато способів кодування даних і годинника на лінії. RS232 традиційно використовує NRZ, існує кодування Machester, а також різні формати, що використовуються на жорстких дисках з цікавими іменами рядка 2.7 RLL.

Підсумовуючи це: існує газильйон способів спілкування між системами. І я навіть не згадував про роз'єми або такі аспекти вищого рівня, як виявлення та відновлення помилок, кодування даних, стиснення та шифрування ...