SPI или I2C: что использовать для длинной шины


36

Я обдумываю проект, который потребовал бы, чтобы несколько AVR разговаривали друг с другом по шине. Они будут разделены на целых 6 футов.

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


Однажды я проводил шину I2C через кабель. Оглядываясь назад, я должен был использовать вместо этого CAN или RS-485 (микроконтроллеры были на обоих концах).
Ник Алексеев

Ответы:


19

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

Основными альтернативами (которые дадут лучшую помехоустойчивость) являются RS485 и CAN . Оба из них используют дифференциальные линии для минимизации шумовых проблем и лучше подходят для такой длины передачи данных, чем I2C или SPI. Тем не менее, я не думаю, что многие (какие-либо?) AVR поставляются со встроенными периферийными устройствами CAN, которые значительно упрощают использование CAN.

Я бы сказал, что самое важное при выборе шины - это убедиться, что протокол, который вы используете для обмена данными между устройствами, содержит CRC или эквивалентный код, чтобы вы могли определить, было ли сообщение получено правильно (CAN имеет это как часть пакет). Учитывая это, также полезно иметь ответ типа ACK / NACK как часть протокола, так что поврежденное сообщение может быть повторно передано.


Похоже, любой из них будет работать. Я в основном думаю об этих двух конкретных протоколах, потому что большинство AVR поддерживают их изначально, без добавления дополнительных компонентов. В противном случае, RS485 или CAN будет хорошим выбором.
edebill

Если вы не ограничены пакетами со сквозными отверстиями, то у ST есть свои экономически эффективные и мощные микроконтроллеры STM32 и STM8 с CAN, NXP имеет ряд микроконтроллеров LPC17xx, и есть еще несколько других. CAN становится все более распространенным (и доступным) на многих микроконтроллерах.
DrAl

1
Действительно, есть некоторые AVR со встроенными CAN-приемниками, но, как и у других производителей, они только в ограниченном подмножестве своих чипов.
Давр

1
Микрочип имеет несколько PIC с CAN. microchip.com/wwwproducts/Devices.aspx?dDocName=en010302 . Я признаю, что они немного «напуганы» для программирования, особенно в библиотеках Microchip C18 / C30. В обзоре кода мы наблюдали некоторый библиотечный код, который было очень трудно прочитать из-за особенностей реализации - буфер передачи, который используется в качестве буфера приема, имена флагов, которые фактически противоположны тому, что они представляют. Конечно, это не то, что я бы порекомендовал для кого-то новичка в разработке микроконтроллеров.
Дж. Полфер

2
CAN и RS-485 действительно яблоки и апельсины. CAN определяет протокол битового уровня, а также физический электрический уровень (PHY). RS-485 - это просто спецификация физического уровня, она ничего не определяет в протоколе. Было бы полностью зависеть от вас, чтобы найти или реализовать действующий протокол поверх RS-485 PHY. CAN был разработан для сред с высоким уровнем шума, в основном он используется в автомобильной и обрабатывающей промышленности. Его протокол является довольно сложной системой передачи сообщений и имеет очень высокие издержки (низкая фактическая скорость передачи данных), но имеет высокую целостность данных.
Марк

10

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

Могут ли микроконтроллеры AVR работать с подчиненными режимами I2C и SPI, а также с основными режимами? (вам нужны оба)


2
витые провода ?? НИКОГДА не перекручивайте линии данных и тактовой частоты I2C! С SPI это, вероятно, меньшая проблема, но я бы никогда не скрутил сигнальные линии, если бы это не была сбалансированная пара, и в этом случае скручивание - очень хорошая идея.
Воутер ван Оойен

никогда не говори никогда; Я бы взял небольшую емкостную связь (из-за скручивания) между данными и часами в любое время вместо незначительной индуктивной связи с шумной силовой электроникой (из-за не скручивания)
Jason S

4
Извините, я совершенно определенно не согласен. В состоянии 1 линии имеют довольно высокое сопротивление. Видел, что сделано, видел, что это не удалось. Лучше всего иметь слаботочные линии заземления между или даже лучше по обе стороны от линий I2C.
Вутер ван Оойен

10

Для I2C на больших расстояниях вы, возможно, захотите найти некоторые решения «I2C bus повторитель». Имейте в виду, что любое максимальное расстояние, которое вы можете найти для связи I2C или SPI, в основном относится к общему расстоянию шины, а не к расстоянию между двумя узлами в шине.

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


RS485, безусловно, хороший способ пойти на такую ​​вещь.
Скотт Мерфи

Имейте в виду, что RS485 имеет два отличных от RS232 аспекта, которые несколько независимы: физические дифференциальные логические уровни и аспект с несколькими хозяевами. Вы можете выбрать и выбрать их, мы использовали переводчики LVDS и RS485 с UART (RS232) для связи «точка-точка» без многоточечного соединения RS485.
Джейсон С

2
кстати RS485 это не протокол! он определяет только физический уровень. Сказав это, вы определенно можете использовать SPI через RS485 !!! Это было бы отличным решением для поддержания связи в режиме SPI, если это необходимо (я предполагаю, что это может быть связано с удаленным АЦП или аналогичным). Используя SPI через RS485, вам нужно проверить совместимость скоростей нарастания трансивера с предлагаемыми данными SPI
smashtastic

8

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

Для моего собственного проекта я использовал 3-проводной слегка модифицированный протокол SPI и нашел результаты удовлетворительными. Я отправляю данные растрового изображения (где случайное повреждение данных не составит большого труда) со скоростью 10 Мбит / с, а другие данные - со скоростью 2,5 Мбит / с без проблем.


Это очень старый ответ, но не могли бы вы сказать, на каком расстоянии вы отправляли модифицированный протокол SPI? (В этом суть вопроса ...)
Даниэль Гриском

@DanielGriscom: Обычно около 3 футов, по не очень впечатляющим кабелям, но иногда и длиннее.
суперкат

6

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

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

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


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

6

Как многие предполагали, I2C и SPI лучше всего использовать для коротких расстояний. Хотя может быть возможно реализовать решение с этими интерфейсами, я настоятельно рекомендую вам поискать другое, «более стандартное» решение (например, Ethernet, RS485, CAN и т. Д.). - Особенно, если вы планируете использовать кабели для достижения 6-футового расстояния между микроконтроллерами.


6

Просто к сведению, интерфейс между беспроводным пультом Nintendo Wii и его спутником Nunchuck использует I2C по кабелю длиной около 3 футов. Существуют также удлинительные кабели длиной 3 фута, которые увеличивают общую длину до 6 футов. Не совсем так, как ваша установка (только два устройства соединены вместе), но это пример I2C по кабелю в широко используемом потребительском продукте.


4

Я работал над проектом, включающим около 80 AVR-узлов в звездообразной сети, взаимодействующих через I2C. Это был полный беспорядок и в итоге не сработало. Получение обновлений для всех узлов заняло секунды, и одно неисправное соединение отбросило бы всю сеть. В последний раз я говорил с парнем, который сделал узлы, он сказал, что он перестал использовать I2C для подобных проектов. К сожалению, я не знаю, почему конкретно I2C был неадекватен здесь.


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

2

Это должно быть легко с такими короткими расстояниями. Что вы можете сделать, это выяснить, что эти расстояния и ваши кабели означают с точки зрения емкости и сопротивления линии, и посмотреть, какие частоты (время нарастания / спада) вы можете пройти через них. За пределами определенного момента, лучше всего рассматривать их как линии электропередачи. Если все выглядит плохо, вы действительно можете переключиться на другую последовательную линию, такую ​​как EIA-232 или 422. Это может означать дополнительную микросхему на обоих концах, но она простирается далеко. Если вам действительно нужно идти быстро и далеко, вам нужно что-то большее (Ethernet, не считайте радио или лазер :).


2

Если вы можете контролировать тактовую частоту и вам не нужна высокоскоростная передача данных, вам следует попытаться замедлить время. Это сделает его менее восприимчивым к шуму.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.