SPI або I2C: який використовувати для довгої шини

Я розглядаю проект, який потребував би декількох AVR-файлів, які розмовляли між собою по шині. Їх розділило б цілих 6 футів.

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

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

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

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

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

Чи можуть мікроконтролери AVR керувати веденими режимами I2C та SPI, а також головними режимами? (вам потрібно обоє)

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

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

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

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

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

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

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

Як багато хто запропонував, I2C та SPI найкраще використовувати на коротких відстанях. Хоча можливо реалізувати рішення за допомогою цих інтерфейсів, я б настійно рекомендував шукати інше, "більш стандартне" рішення (наприклад, Ethernet, RS485, CAN тощо). - Особливо, якщо ви плануєте використовувати кабелі для досягнення відстані 6 футів між мікроконтролерами.

Просто FYI, інтерфейс між бездротовим пультом Nintendo Wii та його компаньйоном по Nunchuck використовує I2C по кабелю довжиною близько 3 футів. Існують також трифутові розтяжні кабелі, які продовжують загальну довжину приблизно до 6 футів. Не зовсім такий, як у ваших налаштуваннях (лише два пристрої, з'єднані разом), але це приклад I2C по кабелю у широко використовуваному споживчому продукті.

Я працював над проектом за участю близько 80 вузлів на основі AVR в зірковій мережі, що спілкуються через I2C. Це був загальний безлад і врешті не спрацював. Оновлення всіх вузлів зайняло секунди, і одне несправне з'єднання викине всю мережу. Востаннє я розмовляв із хлопцем, який зробив вузли, він сказав, що перестав використовувати I2C для подібних проектів. На жаль, я не знаю, чому конкретно I2C тут був неадекватним.

З цими короткими відстанями повинно бути легко. Що ви можете зробити, це зрозуміти, що означає ці відстані та ваш кабель з точки зору ємності та імпедансу ліній, і подивіться, які частоти (часи підйому / падіння) ви можете пройти через них. Поза певним моментом найкраще трактувати їх як лінії електропередачі. Якщо це виглядає погано, ви дійсно можете перейти на якусь іншу серійну лінію, наприклад, EIA-232 або 422. Це може означати додатковий чіп з обох кінців, але розтягнеться далеко. Якщо вам дійсно потрібно йти швидко і далеко, вам знадобиться щось більше (ethernet, не рахуйте радіо чи лазера :).

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