Комментарии 72
всегда восхищался внутренним строением подобных микросхем - симбиоз электроники и механики созданый в кремнии на нанометровых масштабах.
"Стандартное («нормальное») значение, принятое при построении систем единиц, составляет 9,80665 м/с" (с) Википедия.
Дело в том, что I2C шина имеет свойство зависать, да так, что помогает только перезагрузка по питанию.
Это не шина имеет такое свойство, а конкретная ее реализация.
Тем не менее в спеке про константу 9,80665 ничего не сказано...
Видимо, они считают, что ±0.02g не погоды не делают при том, что погрешность нуля датчика ±0.04g, поэтому можно не уточнять значение g до четвертого знака после запятой, а положиться на общепринятые 9.8 м/с2.
9,8 серьезно? Десятичная запятая? А если поискать с десятичной точкой, как принято в англоговорящих и пишущих странах?
Логично предположить, что величина g - это ускорение свободного падения в точке измерения: там же вроде как грузик используется? Или я что-то пропустил?
PS: спасибо за описание
Это не шина имеет такое свойство, а конкретная ее реализация.
Именно так. У меня несколько десятков проектов с i2с, - все там норм. Да и в каждом компе/ноуте и т.д есть шина i2c - и вроде ничего даже работает. Ну а про сервера (и их блоки питания) и вообще даже не заикаемся..
Вы наверное просто сами написали драйвер для аппаратного I2C трансивера.
А если брать стандартный от вендора, то могут быть осечки.
В большинстве случаев - сам. Но % так 30 - вполне себе библиотечные функции, не висло (при нормальной схемотехнике, при плохой разводке - было такое дело). Ну и я редко на 1 МГц гоняю шину.
Но при чем тут сама шина-то? :)
Интерфейс I2C много сложнее, чем интерфейс SPI. А все сложное ломается как раз в первую очередь.
Чем? Апаратно - там 2 провода. У SPI - 3/4. Протокольно - да, сложнее. Скорости передачи меньше значительно (я на SPI достигал 62,5 МГц, на i2c - где-то пробегало что-то на 4 МГц, но,типично, 100-400 кГц, много реже 1 МГц). Ну и на SPI есть дуплекс. И QSPI.
Сложнее, но не так уж много. Есть и гораздо более сложные интерфейсы, которые тоже успешно работают и не виснут.
Вы наверное просто сами написали драйвер для аппаратного I2C трансивера.А если брать стандартный от вендора, то могут быть осечки.
Вендор, который знает о своем продукте буквально все, не может. Зато мимо крокодил, на помойке datasheet нашедший, тот может. Чудеса какие то.
Вы не забывайте, что производители микроконтроллеров это не софтверные компании, а железячники. Я сам в такой работал и прекрасно знаю их внутреннюю кухню.
Hal там пишут либо студенты ,либо аутсорсинг.
Поэтому нет ни тестов ни скриптов сборки. Глядя на исходники , становится очевидно, что авторы кода даже не знают, что такое конечный автомат.
Поэтому Hal от вендора чипа- это обычно Филькина грамота.
Вы не поверите, но во всех изделиях, критичнее поделок с Али нормальные люди так и делают (пишут софт самостоятельно). А виснет I2C только у тех, у кого ардуино головного мозга и слепая вера в HAL от ST и т.п.
У меня несколько десятков проектов с i2с, - все там норм.
Аналогично. Месяцы и даже года непрерывной работы.
Ну а про сервера (и их блоки питания) и вообще даже не заикаемся..
Да практически любой ноутбук имеет связь с контроллером батареи по шине SMBus, которая по сути - I2C :)
Еще про мультиконтроллер надо сказать....
Для мультиконтроллеров тоже нужна прошивка?
Не совсем понял о чем именно Вы говорите.
Ну а про сервера (и их блоки питания) и вообще даже не заикаемся..
На серверах не совсем I2C, а SMbus и PMbus.
SMbus
это практически тот-же i2c, еще и с более низким уровнем шины (3,3В), что делает ее менее защищенной, в общем-то.
PMbus
Это фактически SMbus. Собственно у меня есть проекты, где диагностика и управление блоками питания по ней идет. С контроллера юзается i2c модуль.
Вот CAN и uCAN - эт посложнее уже, но она диф, поэтому там лучше помехозащищеность. И ее длиннее можно делать.
Это не шина имеет такое свойство, а конкретная ее реализация.
Наверное Луна-25 разбилась как раз потому, что зависла шина I2C на которой висел акселерометр.
Там просто дорожка питания к акселерометру отгорела.
Или потому что прошивку писал программист, для которого I2C - это сложно и у которого она виснет :)
Акселерометры используемые для стабилизации работают по SPI в реальном времени.
По I2C работают акселерометры с микропотреблением и глубоким FIFO для носимых гаджетов.
Вообще показания акселерометра было бы лучше передавать непрерывно, как звук по интерфейсу TDM (Time Division Multiplexing). Передавать как трёхканальный звук. Ведь ускорение это же непрерывная величина.
Какой смысл измерять мгновенное ускорение? Разве, что для статических измерений типа наклон столба.
Да, ускорение – это непрерывная величина, но в цифровых системах данные всегда дискретизируются, будь то звук или показания акселерометра. В этом смысле акселерометр работает аналогично микрофону, измеряя физические величины с определенной частотой выборки. Однако передача данных по интерфейсу, как TDM, предполагает высокие требования к пропускной способности и, возможно, избыточна для многих задач.
Мгновенные значения ускорения имеют смысл, когда мы рассматриваем динамические процессы, такие как шаги, удары, вибрации и т.п. Даже для статических измерений, как наклон, важны не только текущие, но и прошлые значения, чтобы оценить изменения со временем. Преимущества дискретных измерений в том, что они дают возможность эффективной обработки и анализа данных, как, например, выделение особенностей движения или других паттернов.
Передача данных в виде 'трёхканального звука' возможна, но это больше вопрос удобства интерфейса и способа обработки. К тому же в системах с низким энергопотреблением, таких как носимые устройства, часто важна не только точность данных, но и экономия ресурсов (памяти, пропускной способности и энергии), что и достигается за счет использования оптимизированных алгоритмов обработки дискретных значений.
Здесь может иметься ввиду "clock stretching", являющийся частью спецификации I2C шины, когда ведомое устройство именно "подвешивает" шину в случае неготовности данных. Как раз всякие IMU грешат подобным.
Подобное наблюдается, например с BNO055 и малинкой.
Так не нужно запрашивать данные когда они еще не готовы. Как правило, устройства имеют регистр статуса, в котором в том числе отражается и готовность данных.
И он что, настолько жестко вешается, что ничего кроме отключения питания не выводит его из этого состояния? Тоже как-то слабо верится. Но даже если так, то это все равно не свойство шины, а криво спроектированный девайс :)
Но даже если так, то это все равно не свойство шины, а криво спроектированный девайс :)
А вот это глубокое заблуждение.
I2C единственная в своем роде шина, где на уровне официальной доки признается факт ее зависания.
Например в одном из мануалов читаем:
36.12
Bus HangingIf the clock signals from the master and slave devices are out of synchronization because of noise or other factors, the I2C bus might hang with a fixed level on the SCLn or SDAn line. To manage bus hanging, the IIC has:
- A timeout function to detect hanging by monitoring the SCLn line
- A function for the output of an extra SCL clock cycle to release the bus from a hung state because of clock signals being out of synchronization
- The IIC reset function
- An internal reset function.
Т.е. как минимум будете встречать частые очень длительные таймауты.
По опыту, мониторинг SCL приводит к ложноположительным ошибкам. Мониторинг SCL приходится отключать. Экстраклок на SCL вооще непонятный финт. Когда его надо делать и сколько раз? Выходит что сброс единственный надежный вариант. А если завис слэйв, то сбрасывать надо уже питание.
I2C единственная в своем роде шина, где на уровне официальной доки признается факт ее зависания.
Это не признание типа "характерная особенность шины I2C - она может зависнуть" и тем более речь не идет о том, что зависает наглухо до отключения питания. Это просто предупреждение о возможной рассинхронизации, нужно быть готовым к такому случаю и предусмотреть соответствующие меры.
Ну и это не из официальной документации на шину, а из описания периферии какого-то МК.
Экстраклок на SCL вооще непонятный финт. Когда его надо делать и сколько раз?
Это указывается в даташитах на I2C-устройства. Например:
3.5 Software Reset
After an interruption in protocol, power loss, or system reset, any 2-wire part can be protocol reset by
following these steps:
Create a Start condition (if possible).
Clock nine cycles.
Create another Start condition followed by a Stop condition as seen in Figure 3-2. The device should be ready for the next communication after above steps have been completed.
Ну если вы думает что в любой ситуации можете сделать супернадежный I2C, то объясните эту оговорку:
Create a Start condition (if possible).
Что тут значит "if possible" . И пройдут ли последующие пункты если not possible
Да просто наличие таких мутных оговорок должно уже погасить уверенность в некой надежности этой шины.
Или еще забавный факт из даташита:
Обратите внимание на сноску 1.
Т.е. чипы даже не тестируют по указанным параметрам.
Ну если вы думает что в любой ситуации можете сделать супернадежный I2C, то объясните эту оговорку:
Create a Start condition (if possible).
Что тут значит "if possible" . И пройдут ли последующие пункты если not possible
Понятия не имею что они имели в виду под "if possible". И про супернадежность в любых условиях речи не шло, это для любого интерфейса/протокола та еще задачка.
Т.е. чипы даже не тестируют по указанным параметрам.
И? Регулярно вижу такие сноски. Разверните вашу мысль, расскажите нам какой скрытый смысл они несут.
Что тут значит "if possible"
Start condition это переход из двух состояний high в high scl, low sda. Но слейв может прижать scl к земле, если не успевает за мастером. А может прижать sda, например, если пропустил тактовый импульс и пытается передать 0. Соответственно, мастер не может организовать Start condition. Поэтому "if possible".
И пройдут ли последующие пункты если not possible
Да, пройдут.
В первом случае после того, как слейв обработает текущий бит, он отпустит линию и все заработает дальше. Если не отпускает, значит кривой слейв. Это не проблема шины, это проблема слейва (если он действительно не отпускает SCL) или выбора компонентов для шины и ее скорости.
Во втором случае после подачи девяти тактовых импульсов передача данных слейвом гарантированно завершится и слейв освободит шину.
А если слейв действительно работает не так, как описано в спецификации, то он любую шину повесит и шина в этом не виновата.
Это не шина имеет такое свойство, а конкретная ее реализация.
Вы не забывайте, что I2C это общий коллектор.
Какой-н I2C Slave возьмет и притянет SCL или SDA в GND.
И тут никакая ваша прошивка не починит баг на стороне ASICа. Только перезагрузка платы.
Поэтому I2C-самый ненадёжный интерфейс.
Какой-н I2C Slave возьмет и притянет SCL или SDA в GND.И тут никакая ваша прошивка не починит баг на стороне ASICа.
Какой-нибудь SPI slave возьмет и не отпустит линию MISO при деактивации сигнала CS. Какой-нибудь девайс на полудуплексной шине RS-485 возьмет и не перейдет в прием после отправки данных.
Во всех этих случаях, так же как и в случае с I2C, решение общее - не использовать ASIC-и с багами в реализации интерфейса.
Но такие баги встречаются достаточно редко. В подавляющем большинстве случаев причиной зависания шины являются косяки в прошивке, работающей с устройствами на этой шине. И почему-то очень многие программисты уверены, что раз шина остается слишком долго в состоянии BUSY, то это конец света и спасет только передергивание питания. Вот как вы, например.
Недавно выяснилось, с глюками в новом чипе raspberry pico 2350.
И с главной фишкой - PIO, State machine и тоже с состоянием выводов gpio.
Не говоря о состоянии ПО.
Слава Гуглу и его жестким полугодовым релизам с забыванием, а не решением, ошибок.
И практически почти всё активно используемое ПО перешло в режим анекдота - этих умоем, причешем или новых наделаем...
Использовал такие акселерометры в качестве датчика вибрации.
Минусы:
Нет внешнего тактирования.
По даташиту частота измерения 400 Гц, но может выдавать и 395, и 405 Гц.
Побороли путём измерения времени между прерываниями от FIFO.
Слабый антиалайзинговый фильтр.
Никак не исправить.
Довольно шумный на небольших значениях ускорения.
Ловить сотые в константе g нет никакого смысла.
Плюсы:
Прибор получается дешёвый.
Акселерометр цепляется напрямую к микропроцессору.
Несколько уточнений по тексту.
Чем выше чувствительность, тем лучше для нас
Лучше, когда чувствительность такая, что интересующий нас диапазон физической величины оптимально укладывается в диапазон измерений датчика. Нам не нужен датчик, который не реагирует на существенное изменение параметра, и не нужен датчик, зашкаливающий от малейшего колебания. Перегиб в обе стороны - плохо.
Данные передаются младшим битом вперед
Все-таки наоборот, MSB First: на шину вначале выталкивается старший бит.
Линия SCL у девайса тоже 'io', она не чистый вход: slave-устройство может приостановить тактирование, удерживая SCL в низком уровне, если не успевает подготовить данные для передачи (благодаря clock stretching).
В табличке с чувствительностью mg/digit наверное опечатки? Я имею в виду значения 192, 48 и две двойки в High-resolution.
Благодарю Вас, Алексей @f-tech, за найденные недочеты. Исправил.
Все бы писали такие внимательные комментарии.
Обзор Акселерометра LIS3DH