Общий протокол для передачи данных из одной системы в другую?

18

Каков общий протокол для отправки информации из одной системы в другую? Например, предположим, у нас есть некоторая информация, собранная с микроконтроллера за определенный промежуток времени, который мы хотим отправить другому микроконтроллеру. Я слышал об интерфейсах SPI и I2C, но мне неясно, когда вы используете один метод поверх другого и как вы его реализуете. Существуют ли другие методы, помимо SPI и I2C, которые являются общими? Схож ли процесс внедрения для разных микроконтроллеров? Это в основном парсинг байтов данных, которые я делаю на принимающем микроконтроллере?

i2c spi data

— О_О
источник

4

Что конкретно вы хотите сделать?

— звездный синий

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

— O_O

2

это не то, что люди обычно называют системой. Это то, что я бы назвал подсистемами. Они составляют часть того, что вы могли бы считать единой системой, выполняющей единый набор задач. Это семантика, но я думаю, что многие из ваших ответов очень широки, потому что они не имеют идеального представления о том, что вы ищете из вопроса.

— Кортук

1

в соответствии с тем, что сказал Кортук, это помогает определить проблему. Один важный вопрос, который следует задать себе, заключается в том, намереваетесь ли вы заменить отдельные подсистемы различными реализациями одной и той же функции, или это единовременный проект «как есть». Если вы используете реальную шину и выставляете детали реализации подсистем для вашего процессора, то изменение подсистемы требует изменения как / w для вашего контроллера, тогда как если вы используете интерфейс связи, то не имеет значения, как вы реализуете (замена ) подсистемы, если она соответствует одному и тому же протоколу сообщений.

— JustJeff

Не проще разделить функциональность по нескольким устройствам ни по какой другой причине, кроме разделения задач. Связь и синхронизация сложнее, чем два процесса в одном микро. Теперь, если эти процессы имеют особенно несовместимые профили задержки (один должен быстро обновляться, в то время как другому может потребоваться некоторое время для завершения блока), тогда МОЖЕТ быть веская причина для их разделения. Даже в этом случае более распространенным решением является использование прерываний или поиск способа разбить более длинную задачу. С тем, что вы описали, я склоняюсь к мысли, что вы должны переосмыслить это.

— Даррон

10

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

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

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

— JustJeff
источник

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

— Кортук

@Kortuk - поскольку что-то вроде 232 имеет своего рода симметрию между равноправными узлами, в то время как 1553 или МОЖЕТ навязывать отношения хозяин / раб, да. Я не думаю, что сказал, что ethernet прост, просто он не накладывает различие между контроллером шины и устройством шины на конечных точках.

— JustJeff

Кроме того, полное раскрытие - мое мнение о CAN полностью от тангенциального воздействия; это было неиспользуемое дополнительное периферийное устройство в нескольких системах, над которыми я работал, но после сотен проходов по документации вы немного осознаете неиспользуемые опции. Поэтому я работаю в предположении, что CAN является архитектурой типа контроллер / управляемое устройство.

— JustJeff

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

— Даррон

11

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

Самый нижний уровень - это физический уровень , который фактически перемещает биты.

SPI и I²C предназначены для коротких расстояний внутри устройства, где не так много шума, который может помешать передаче.
Для не слишком быстрой связи на расстояниях до нескольких десятков метров последовательная связь по RS-232 является хорошим выбором.
Если имеется больше шума или используются более длинные дистанционные дифференциальные сигналы, например, в RS-485. Для более быстрой передачи данных есть Ethernet, который становится все более популярным.
Тогда есть также различные беспроводные стандарты.

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

— starblue
источник

7

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

Что касается протоколов, то все с определенными байтами команд и некоторой схемой контрольной суммы будет работать хорошо. На самом деле не существует стандартного протокола, охватывающего все типы коммуникаций. I2C имеет стандарты сигнализации (определение адресации, остановок, запусков и т. Д.), Но протокол того, что фактически передается, зависит только от разработчика.

PMBus , например, является протоколом связи источника питания, который использует I2C в качестве своей физической среды.

— Адам Лоуренс
источник

6

На самом деле не существует «общего» протокола, то, что вы в конечном итоге используете, сильно зависит от приложения. Чтобы мы могли дать вам лучший ответ, нам нужно немного лучше понять ваши требования. Вы упоминаете, что хотели бы, чтобы отдельные микроконтроллеры говорили друг с другом как подсистемы.

Некоторые вопросы об этом приложении:

Будет ли в этом проекте более двух микроконтроллеров?
Каковы ваши требования к скорости и пропускной способности? Как быстро нужно получать информацию и как часто вы отправляете / получаете данные?

Если вы ответили НЕТ на вопрос 1:

Если в этом проекте только 2 микроконтроллера, вы определенно можете использовать UART между ними. Если им обоим необходимо инициировать связь, используйте управление потоком, в противном случае отправка данных в одном направлении должна быть тривиальной. По большей части это должно быть «достаточно быстро», учитывая, что вы выбираете одну из более высоких скоростей в бодах. I2C и SPI обычно хороши только для архитектуры master / slave.

Если вы ответили ДА (более 2 контроллеров) на вопрос 1:

Если в вашем проекте более двух микроконтроллеров, какой из них инициирует связь? Будет ли это только один главный контроллер (т.е. архитектура главный-подчиненный)? Или любая из подсистем сможет говорить в любое время?
Нужно ли какой-либо из подсистем общаться друг с другом? например: для устройств A, B и C: A может отправлять B и C, а B может отправлять как A, так и C и т. д.

Так что теперь вам нужно что-то более масштабируемое, чтобы вы могли перебрасывать адресуемые устройства на общую шину. Ответ на эти вопросы поможет вам выбрать между I2C и SPI (master-slave) или чем-то вроде CAN (multi-master).

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

— Джон Л
источник

5

Как отметил @Jon, одна проблема при выборе интерфейса связи заключается в том, всегда ли один объект будет отвечать за инициирование обмена данными, или же ответственность за него может нести более одного объекта. С этим связан вопрос, будет ли одна организация всегда готова получать нежелательные сообщения. SPI часто используется в приложениях, где одна сторона всегда будет готова принять сообщение. Например, что-то вроде сдвигового регистра 74HC595 никогда не бывает «занято». Хотя SPI хорош для связи между микроконтроллером и оборудованием, которым должен управлять микроконтроллер, на самом деле он не подходит для связи между двумя микроконтроллерами. Когда два процессора с аппаратным обеспечением I2C используют его для связи, программному обеспечению может потребоваться столько времени, сколько ему нужно (в рамках очень щедрых ограничений), чтобы справиться с тем, что происходит, без потери данных. Если бы процессору потребовалось 100 микросекунд для обработки каждого входящего байта, это серьезно ограничило бы пропускную способность, но отправитель замедлился бы настолько, чтобы получатель не отставал. Единственный способ, который обычно может случиться с SPI, - это иметь отдельный провод для рукопожатия.

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

Его скорость несколько ограничена; SPI может идти намного быстрее, и даже UART иногда могут идти немного быстрее
(2) Хотя очень удобно, что I2C требуется только два провода, оба провода должны быть способны к двунаправленной связи с открытым коллектором. Это затрудняет отправку I2C через повторители.

Лично я хотел бы, чтобы продавцы контроллеров поддерживали трехпроводной вариант SPI, который включал рукопожатие. Я не знаю ни одного контроллера, который делает это, хотя.

— Supercat
источник

Забавно, что вы должны упомянуть об этом ... Мне нужно превратить интерфейс SPI в двунаправленный I2C-подобный интерфейс (первый байт - адрес), чтобы позволить гораздо большему количеству устройств участвовать в шине, чем у меня есть выбор чипов для , Это работает, если все ваши ведомые устройства - ПЛИС. :) Я тоже хотел бы, чтобы между этими двумя основными синхронными стандартами было что-то среднее.

— Даррон

О, я полагаю, я должен уточнить, что разрешения на выход на ведомых устройствах не утверждаются до тех пор, пока не будет получен адресный байт, и они остаются включенными, пока выбор одного чипа не отменен ... так что он, очевидно, немного отличается от обычного SPI + высокий уровень протокол. Однако он полностью совместим со стандартным SPI с точки зрения главного устройства. (как микропроцессор)

— даррон

@darron: Круто. Интересно, что должно произойти, чтобы индустрия начала использовать трехпроводную коммуникационную шину открытого стандарта, где провода активно протекают высоко и низко? Я предполагаю, что существует небольшой конфликт между отказом от пассивных подтягиваний и разрешением любому устройству сигнализировать о прерывании, хотя это можно исправить, добавив вывод прерывания, который может быть подключен к ведущему или нет для удобства подчиненных (моя нынешняя реализация протокол имеет только одно ведомое устройство, поэтому он может использовать провод возврата данных для асинхронного оповещения, когда он хочет быть обслужен).

— Суперкат

@darron: чтобы избежать необходимости использовать вывод выбора микросхемы, мастер сигнализирует о начале команды, посылая два передних фронта на провод данных, когда тактовые частоты низки; подчиненные устройства могут указать, был ли их последний байт данных действительным, путем вывода значения состояния, когда часы и данные находятся на низком уровне (в режиме ожидания); в противном случае они указывают, что они хотят внимания, когда часы низкие, а данные высокие. Если бы я разрабатывал основную аппаратуру для этого протокола, я бы добавил возможность отправлять 8 тактовых импульсов, где данные синхронизируются с проводом данных, а в ведомом оборудовании есть асинхронный счетчик числа нарастающих

— фронтов

@darron: ... байт данных. Если пять или больше, байт будет проигнорирован (ведомый предположил бы, что мастер заинтересован в получении байта данных, но не имеет ничего, что он на самом деле хотел сказать). Это было бы не так важно, как если бы подчиненное устройство сообщало о состоянии последнего байта при низком тактовом сигнале (что, если ведомое устройство было процессором, позволяло мастеру знать, что подчиненное устройство не было готово). и упустил последнюю «возможность транзакции».

— Суперкат

3

В произвольном порядке наиболее популярными экземплярами физического уровня для двух процессоров в одном блоке являются:

SPI гирляндной цепи (такой как используется JTAG)
выберите провод-на-ведомый SPI
«TTL-уровень RS-232», он же «асинхронный последовательный пуск-останов последовательной связи» (прямое подключение контакта UART TX одного процессора к контакту UART RX другого процессора)
I2C
8-битные данные + строб (например, параллельный порт порта принтера IEEE 1284)
разделяемая память (только один процессор одновременно управляет шиной адреса / данных / управления)

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

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

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

преамбула
заголовок
(возможно, экранированные) сериализованные данные
прицеп

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

Некоторые из самых простых протоколов для инкапсуляции данных в пакет включают в себя:

Несколько более сложные протоколы для инкапсуляции данных в пакет включают в себя:

Существует длинный список протоколов на

Вам может понравиться чтение «Фольклора дизайна протокола» Радии Перлман, в котором рассказывается, как дизайн протокола может пойти не так.

— davidcary
источник

3

Нет единого «общего» протокола. Выбор может (например) зависеть от:

расстояние
требуемая пропускная способность
наличие специальной периферии
уровень шума
необходимость в оптической изоляции
критичность (допустимая частота отказов)
Доступная мощность процессора на обоих концах
доступные контакты ввода / вывода на обоих концах

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

простой 5 В или 3,3 В или даже 1,8 В TTL
любой из вышеперечисленных, но с открытым коллектором вместо двухтактного
сигнализация сбалансированного напряжения (часто используется с ПЛИС)
сбалансированное высшее напряжение (RS485, RS432)
одноконтактное более высокое напряжение (RS232)
сбалансированная трафарная связь (различные версии Ethernet, аудио PDIF)
оптический (оптический Ethernet, Toslink)

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

Есть много способов кодировать данные и часы на линии. RS232 традиционно использует NRZ, есть кодировка Machester, а также различные форматы, используемые на жестких дисках со строкой любопытных имен 2.7 RLL.

Подводя итог: существует множество способов установить связь между системами. И я даже не упомянул соединители или аспекты более высокого уровня, такие как обнаружение и восстановление ошибок, кодирование данных, сжатие и шифрование ...

— Воутер ван Оойен
источник