Подключение Raspberry Pi Zero к датчику (с интерфейсом шины I²C или SPI) на большом расстоянии

КРАТКОЕ СОДЕРЖАНИЕ:

Вот что работает:

Raspberry Pi (I²C) <-> кабель 1 м <-> датчик (I²C)

Вот что я пытаюсь сделать (не работает, отсюда и вопрос):

Raspberry Pi (I²C) <-> кабель 30 м <-> датчик (I²C)

Таким образом, «уравнение» для решения:

Raspberry Pi (I²C, SPI и др.) <-> X <-> кабель 30 м <-> Y <-> датчик (I²C/SPI)

Решите для X и Y

ДЕТАЛИ:

Я работаю с кучей датчиков, сконфигурированных в звездообразной сети/топологии.

Введите описание изображения здесь

Raspberry Pi Zero используется как центральный «концентратор», где собираются и обрабатываются все данные датчиков. Все датчики одинаковы и используют протокол I²C (они также предлагают интерфейс шины SPI). При этом у меня в настоящее время есть мультиплексор I²C, подключенный к Raspberry Pi Zero, чтобы включить несколько устройств, настроенных с одним и тем же аппаратным адресом I²C. Все датчики подключены к Raspberry Pi Zero с помощью экранированного кабеля 26/4. На данный момент все работает как задумано.

Имея доказательство концепции, я теперь хочу увеличить радиус действия звездообразной сети/топологии на 20-30 м для каждого соединения датчика с концентратором. Я думал, что могу просто использовать более длинный провод, но, видимо, протокол I²C ограничивает длину удлинителя провода. Я читал различные приемы/решения о том, как увеличить длину, такие как снижение частоты, замена резисторов и т. д.

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

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

  • P82B96, у которого, видимо, есть преемник: PCA9600?
  • P82B715

Сравнивая два, я читал, что первый пункт более универсален. Я также читал, что второй элемент старше и требует много энергии , что делает удаленное развертывание (питание от батареи) менее практичным. Недавно я наткнулся на другое решение, в котором вы используете преобразователь I²C в 1-wire, поскольку протокол 1-wire не так чувствителен к увеличению длины провода.

  • DS28E17 (и, возможно, добавить DS2484 в концентратор)

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

В любом случае, опять же, я не инженер-электрик, поэтому мне действительно не помешал бы совет. Похоже, что протокол I²C — это то, что используют многие датчики (по крайней мере, на рынке встраиваемых систем «сделай сам»), поэтому я полагаю, что я не единственный, кто сталкивается с проблемой расширения связи I²C .

Вот мои требования к решению:

  • выдвинуть каждый датчик из центральной втулки на 20-30 м
  • должно быть проводное соединение
  • низкое энергопотребление (работаю в сети от батареи)

РЕДАКТИРОВАТЬ: я еще немного покопался на выходных и наткнулся на этот набор микросхем (MCP25 *), который звучит как интерфейс CAN-to-SPI. ЭТО НЕ РАБОТАЕТ... СМОТРИТЕ комментарии @Maple ниже.Я, конечно, не говорю, что это единственный набор микросхем, предлагающий такое преобразование, просто он первый, с которым я столкнулся. Датчики, которые я использую, имеют интерфейс шины SPI, поэтому я думаю, что смогу напрямую подключить один из этих чипов к каждому датчику? У меня есть только 5 сенсорных узлов, подключенных к Raspberry Pi в моей звездообразной топологии, поэтому я полагаю, что я хорошо укладываюсь в ограничения на количество узлов, которые может поддерживать шина CAN. Тогда возникнет вопрос, как настроить остальную часть шины. Могу ли я просто подключить один конец кабеля Cat 5 к одному из чипов CAN-to-SPI? Затем провод протянется на 20-30 м к Raspberry Pi. Могу ли я затем добавить еще один чип в Raspberry Pi, чтобы «инвертировать» преобразование и общаться с Raspberry Pi? Есть ли способ подключить все пять узлов к одному интерфейсу/чипу? я не Не думаю, что Raspberry Pi имеет встроенную поддержку шины CAN, но, очевидно, имеет SPI (я думаю, вы можете подключить только два устройства?). Если бы эти чипы можно было добавить на сенсорные узлы, что потребовалось бы для взаимодействия с Raspberry Pi?

EDIT_2: Собрав дополнительные сведения из отзывов всех (спасибо), я решил продолжить копать. Неудивительно, что я наткнулся на еще одно потенциальное решение! Я читал комментарии к одной из ссылок, на которые я указал выше , и кто-то упомянул чип PCA9615 . Быстрый поиск в Google по этому чипу вводит «дифференциальный I²C». С точки зрения непрофессионала, это звучит как решение, которое не потребует от меня изменения моего программного обеспечения. Кроме того, я не полностью знаю плюсы и минусы и соответствует ли это моим трем перечисленным требованиям. Я буду читать дальше в таблице данных, но если у кого-то есть отзывы об этом решении, я весь внимание!

20-30 м - это немного для шины I2C, если только вы не используете ее с тактовой частотой 1 кГц. И иметь централизованное питание от того же корневого концентратора. И используйте экранированные кабели. Это большая натяжка.
Мощность сигнала необходимо сравнить с мощностью соседнего шума и коэффициентом сопротивления связи с шиной.
@NickAlexeev Да, я думаю, что наткнулся на этот перекресток, и я пытаюсь избежать ошибки, связанной с чрезмерным использованием i2c.
@ThatsRightJack Повторно РЕДАКТИРОВАТЬ. Не существует такого понятия, как интерфейс «spi-to-can». Это контроллеры CAN с интерфейсом SPI. Ваш MCU отправляет команды SPI на контроллер, заставляя его отправлять / получать данные по CAN. По сути, CAN-контроллер является ведомым устройством, как и ваш датчик SPI. Вы не можете соединить два датчика вместе, даже если они оба имеют интерфейсы SPI.
@Maple Вы говорите, что Raspberry Pi (SPI) <-> CAN-контроллер <-> 30-метровый кабель <-> CAN-контроллер <-> Датчик (SPI) - это слишком много «ведомых устройств», связанных вместе?
Я говорю, что «контроллер CAN <-> датчик (SPI)» не имеет никакого смысла. Контроллер CAN точно такой же, как и сам датчик. Вы не можете соединить два датчика вместе. Вы можете подключить устройство SPI только к MCU, потому что оно должно контролироваться вашим кодом. Датчик не имеет кода, он не может управлять CAN-контроллером.
Также (хотя в данном случае это не имеет значения) нельзя подключить CAN-контроллер напрямую к кабелю. Вам нужны микросхемы приемопередатчика CAN между контроллерами и кабелем. Тот, который я предложил вам в своем ответе.
Повторный чип PCA9615. Это просто еще один трансивер с несимметричным на дифференциальный. И не очень хороший, имхо. Максимальная скорость быстро падает после длины кабеля 3 м, а энергопотребление довольно велико. Кстати, большинство из предложенных вам решений до сих пор не требовали каких-либо программных изменений.

Ответы (4)

Решение Onewire с DS28E17 — это решение, которое в основном работает сразу после установки. Вы даже можете использовать битбанговый хост (например, на GPIO4) и обойтись практически без дополнительного оборудования. Каждый DS28E17 на шине автоматически отображается как хост-адаптер I²C, никаких изменений программного обеспечения не требуется. Недостатки:

  • Onewire должен быть автобусом, а не звездой. Если у вас звездообразная схема, используйте лепестки, чтобы сделать ее физической шиной. Или используйте несколько шин Onewire, DS2482-800 предлагает восемь.
  • Это низкая скорость, всего около 15 кбод, с большими накладными расходами. Вы не можете использовать его для датчиков с высокой пропускной способностью.

Забудьте о DS2484 за идеей DS28E17 . Это просто возводит в квадрат накладные расходы, поэтому отправка нескольких байтов занимает секунду или около того. (DS28E17 за DS2484 или DS2482-800, напротив, предназначен для использования по назначению и позволяет избежать битовых ударов.)

Причина, по которой чип еще мало используется другими людьми, заключается в том, что он вышел только в 2016 году, а драйвер для Linux доступен только с версии ядра 4.15.

(И предостережение: DS28E17 рассчитан только на 3,3 В.)

Я думаю, что «вы даже можете использовать хост Bitbanging» следует заменить на «вы должны использовать Bitbanging» для подключения к Raspberry Pi. Насколько я знаю, на RasPi нет двунаправленного открытого дренажного штифта. В остальном, это, безусловно, привлекательный вариант
Простое подключение GPIO4 с подтяжкой ~ 1,5 кОм к 3,3 В отлично работает. Драйвер ядра Onewire переключается между выходом и вводом с низким выходом. Это точно так же, как двунаправленный открытый сток. Драйвер ядра DS28E17 автоматически перечисляет все DS28E17 на шине и представляет их пользователю как хосты I²C.
«драйвер ядра переключается между выходом и вводом с низким выходом». он же "немного стучит"
Вы также можете, например, использовать DS2482-800 на локальной шине I²C для создания 8 шин Onewire, а затем использовать по одному или более DS28E17 на каждой из них для получения удаленных шин I²C. Единственное, что нецелесообразно, так это поставить за DS28E17 еще один мост I²C–Onewire. Я отредактировал это в своем ответе.
Я немного запутался в вашем использовании слова «позади» и в том, от чего именно вы предостерегаете. Возможны только два соединения: I2Cmaster — DS2484/DS2482-800 — 1wire или 1wire — DS28E17 — I2Cslave. Первый можно заменить битовым ударом.
@Maple Может быть, в ту же ловушку, в которую я попал? I2Cmaster <-> DS2484/DS2482-800 <-> 1wire <-> DS28E17 <-> I2Cslave. Как вы указали в моем решении CAN, это не работает?
@ThatsRightJack Это работает , потому что эти чипы не контроллеры, а мосты. Именно для этого они и созданы.
Что «работает», но сильно отстой, так это использование другого DS2484 вместо ведомого I²C на DS28E17, а затем наличие еще одного участка Onewire. Это слишком медленно. У меня сложилось впечатление, что вы планируете что-то подобное, потому что вы говорили о «хабе». Но теперь я понимаю, что вы назвали Raspberry Pi «хабом».
Кто в здравом уме станет конвертировать 1-wire в I2C, а потом обратно в 1-wire?! Имейте в виду, что DS2484 — это не просто ведомое устройство I2C. Он имеет внутренние регистры состояния и конфигурации, что предполагает подключение к хосту MCU. Я, наконец, понял, от чего вы предостерегаете, но поскольку это нереальная конфигурация, это предупреждение не помогает, оно только создает путаницу.
На самом деле это то, что кто-то хотел создать, когда попросил драйвер DS28E17 в списке OWFS. Идея заключалась в том, чтобы сделать разветвитель шины, такой.
@Janka Извините за путаницу в моей терминологии (например, использование слова «концентратор»). Как показано на рисунке, Raspberry Pi должен быть центральным узлом, который собирает все данные с 5 сенсорных узлов.
@Maple Хорошо, просто для ясности в отношении этого потенциального решения, вот как я вижу соединения для топологии звезды: Raspberry Pi (I2Cmaster) <-> DS2482-800 («мосты» i2c к 1-wire на 5 отдельных шинах) < -> кабель 30 м (каждая из 5 ножек датчика) <-> DS28E17 ("соединяет" 1-wire обратно с i2c) <-> датчик (I2Cslave). Может быть, DS2482-800 можно заменить битовым ударом, но, учитывая, что у меня 5 шин, я просто предполагаю, что использую аппаратное обеспечение. Основываясь на ваших комментариях, я считаю, что это сработает с точки зрения коммуникации.
@ThatsRightJack Наконец-то вы поняли правильно ;). Бит стука 5 шин - это большая нагрузка на процессор, даже с такой медленной шиной, как 1-Wire, лучше придерживаться железа. В крайнем случае вы можете использовать 5x чипов DS2484 на стороне Pi, все на одном аппаратном I2C. Да, это сработает, но сначала проверьте свои требования к скорости передачи данных датчика. Если вам нужно больше 16 кбит, то вам нужно что-то лучше (быстрее), чем 1-wire.
@ThatsRightJack С другой стороны, если вам нужно гораздо меньше, и некоторые из ваших датчиков расположены близко друг к другу, то вы можете поставить несколько DS28E17 на одну и ту же шину 1-wire в разных точках, создавая смешанную топологию.
@Maple Да, я собираюсь более внимательно изучить скорость передачи данных и характеристики мощности, чтобы увидеть, сработает ли решение. По крайней мере, с точки зрения конфигурации, вы очень помогли!
@Maple Можете ли вы уточнить, что вы подразумеваете под «но сначала проверьте свои требования к скорости передачи данных датчика. Если вам нужно более 16 кбит, вам нужно что-то лучше (быстрее), чем 1-wire»? Я посмотрел на техническое описание и не вижу ничего, что бросалось бы мне в глаза, предоставляя эту информацию. Может быть, вы были бы так круты, чтобы быстро взглянуть на техническое описание ( te.com/usa-en/product-CAT-BLPS0013.html ) и сказать мне, что мне следует искать?
В таблице данных указано, что преобразование занимает около 8,22 мс. Запуск преобразования через DS28E17 займет около 15 мс, чтение результата — еще 15 мс. Таким образом, это около 40 мс на выборку или 25 выборок в секунду. С чистым I²C вы можете достичь 100 выборок в секунду.
@Janka 20 бит, чтобы начать преобразование, и 38 бит, чтобы прочитать результат, поэтому числа будут немного отличаться, но примерно на том же уровне. Я получил теоретические максимальные 119 отсчетов в секунду для чистого I2C, но реальная жизнь все равно никогда не согласуется с теорией.

Я подозреваю, что есть и другие виды удлинителей I2C, но я знаком только с двумя — буферами (такими как PCA9605, P82B715) и сплиттерами (такими как PCA9600, P82B96). Все они предназначены для изоляции более высокой емкости шины от длинных шин за счет увеличения пропускной способности выходов. Кажется, что все буферы приближаются к EOL.

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

Есть много заметок по применению, которые я бы рекомендовал прочитать, например, уже предложенные @ali-chen AN11084 или AN11075 , AN10658 . Интересно, что даже те из них, которые используют в своей топологии витые пары, по-прежнему полагаются на несимметричную сигнализацию. Я почти уверен, что любое приложение или устройство, которое вы выберете, должно работать хорошо.

Что я хотел бы предложить, так это сначала взглянуть на это устройство . Они описывают его как «удлинитель PCA9600». Однако глубоко внутри технического описания вы можете найти умное использование микросхемы приемопередатчика CAN PCA82C251 для преобразования сигналов I2C (разделенных на Tx, Rx с помощью PCA9600) в дифференциальные сигналы.

Вышеупомянутое уже имеет преимущество высокой помехозащищенности без какого-либо экранирования. И это может дать вам высокоскоростную связь на расстоянии более 100 м. Но вот вам еще одна хитрость - шина CAN может работать при напряжении 3,3 В с той же скоростью и надежностью, что и при напряжении 5 В, при этом снижая энергопотребление более чем на 50%. Я думаю, это оправдывает более пристальное внимание к вашему приложению.

В этой заметке NXP описываются методы увеличения длины шинной системы I2C до более чем 300 м при скорости 60 кбит/с, AN11084 . Решения включают в себя витые линии, повторители PCA9605 и логику генерации задержки на каждом ведомом устройстве. Удачи.

Я также предлагаю посмотреть на это . https://en.m.wikipedia.org/wiki/Низковольтный_дифференциальный_сигнал

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

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

M LVDS (multi LVDS) может быть подходящим кандидатом. Вы можете использовать отдельные каналы для часов и данных I2C.

Линия данных является двунаправленной, но ее можно обрабатывать с помощью арбитража.

Подключение Raspberry Pi Zero к датчику (с интерфейсом шины I²C или SPI) на большом расстоянии
СпросиСетьПолитика конфиденциальности1y, 0v