[okela 0]

Подскажите, плс, как далеко можно пулять по шине I2C в стандартном и

быстром режимах (интересует максимальная длина линии без потерь инф-ции)

[Alexandr 0]

Длина соединительных линий в стандартном режиме может достигать 2-х метров, скорость передачи до 100 кбит/с. http://www.rs232.ru/docs/i2c/iic_rus.pdf

Но на то он и стандартный режим ;) На самом деле конечно больше, где-то на 5м делал

[belousov 0]

Ограничение по расстоянию можно снять с помощью буферов, например:

P82B96

P82B715

 

Philips предлагает две статьи по этому поводу:

One_mile_long_I2C_communication_using_the_P82B715.pdf

Philips_I2C_bus__extending_its_reach.pdf

[Xenia 35]

У меня совсем короткий вопрос про ... SMBAL. У STM32 бывает по штуке на каждом I2C: I2C1_SMBAL, I2C2_SMBAL и т.д.

По описанию это линия активации прерывания от каких-то SLAVE-устройств. Однако у CubeMX номер прерывания для нее не задает.

Тем не менее, I2C "подминает" этот пин под себя, например не дает таймеру TIM3_CH2 с этим пином работать.

Мой вопрос: можно ли использовать SMBAL-пин в качестве выхода, как обычный GPIO? Не повредит ли это работе I2C, если оно в это время работает?

[HardEgor 66]

29 минут назад, Xenia сказал:

можно ли использовать SMBAL-пин в качестве выхода, как обычный GPIO? Не повредит ли это работе I2C, если оно в это время работает?

Это SMBus alert, если у вас не SMBus , а простой I2C , то можно использовать как заблагорассудится)

[Xenia 35]

А почему тогда I2C его для себя резервирует? А и откуда ему знать, какая у меня шина - SMBus или нет? А раз есть SMBAL, то вероятно I2C должна как-то на него реагировать, а иначе зачем он?

[HardEgor 66]

38 минут назад, Xenia сказал:

А и откуда ему знать, какая у меня шина - SMBus или нет?

По-идее должно  выбираться при конфигурации и там выбрать - или I2C или SMbus.

Надежнее банально посмотреть в код куба.

[Xenia 35]

5 минут назад, HardEgor сказал:

По-идее должно  выбираться при конфигурации и там выбрать - или I2C или SMbus.

Согласна, действительно это задается в конфигурации.

[Xenia 35]

У меня возник еще один животрепещущий вопрос.
Контроллер (у меня это STM32F103C8T6) намертво виснет (оживает только по WatchDog'у) при выполнении функций:

HAL_StatusTypeDef HAL_I2C_Mem_Write(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);
HAL_StatusTypeDef HAL_I2C_Mem_Read(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint16_t MemAddress, uint16_t MemAddSize, uint8_t *pData, uint16_t Size, uint32_t Timeout);

когда линии SDA и SCL не подтянуты к питанию, вне зависимости от того, какой задаешь Timeout. Т.е. зависает на этой процедуре и по Timeout'у из нее не выходит.

Я отлично понимаю, что случай, когда линии I2C не потянуты к питанию резисторами - аномальная ситуация, в которой нельзя требовать от шины нормальной работы. Однако мне сильно хочется, чтобы обрыв в шины (а резисторы подтяжки находятся на слейве, т.к. этот контролер не умеет такую подтяжку создавать сам, а на плате она не предусмотрена) не приводил к зависанию, чтобы контроллер мог бы выдать по этому поводу вразумительное сообщение об ошибке. Типа: "Шина I2C оборвана".

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

Вопрос: есть ли какой-то способ проверить наличие подтяжки на линиях SDA и SCL, а еще лучше сделать так, чтобы контролер при операциях чтения и записи по шине I2C не зависал, если на ней нет подтяжки?

[jcxz 184]

2 часа назад, Xenia сказал:

Вопрос: есть ли какой-то способ проверить наличие подтяжки на линиях SDA и SCL

Вангую, что при длительном низком уровне на SCL, должен устанавливаться бит ARLO в регистре SR1.

[siargy 6]

9 hours ago, Xenia said:

линии SDA и SCL не подтянуты к питанию

перед вызовом функции можно проверить, что на выводах высокий уровень

 

 

9 hours ago, Xenia said:

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

 

не дочитал. а физически там высокий уровень?

 

кстати не всегда библиотечные функции обладают заявленным функционалом

[x893 35]

Есть документ от NXP как инициализировать i2c шину.
римерно 15-ти летней давности.
ам точно была цифра в 80 тактов по SCL - по ней можно найти.

Проверить подтяжку проще пареной репы. Включить пины на INPUT-PULL-DOWN и считать уровень.
Но есть ньюнсы, если слейв зажал SCL вниз. Для решения этой проблемы - читать документ от NXP .

[HardEgor 66]

В 15.02.2024 в 05:01, Xenia сказал:

Я отлично понимаю, что случай, когда линии I2C не потянуты к питанию резисторами - аномальная ситуация, в которой нельзя требовать от шины нормальной работы. Однако мне сильно хочется, чтобы обрыв в шины (а резисторы подтяжки находятся на слейве, т.к. этот контролер не умеет такую подтяжку создавать сам, а на плате она не предусмотрена) не приводил к зависанию, чтобы контроллер мог бы выдать по этому поводу вразумительное сообщение об ошибке. Типа: "Шина I2C оборвана".

Уже пробовала определять уровень на пинах

Включить встроенную подтяжку pullup, проверить уровень, затем включить  pulldown и тоже проверить

уровень. Естественно проверять в режиме gpio

[Xenia 35]

4 часа назад, HardEgor сказал:

Включить встроенную подтяжку pullup, проверить уровень, затем включить  pulldown и тоже проверить уровень. Естественно проверять в режиме gpio

Согласна с вами ... наполовину 🙂, действительно проверка в режиме gpio в режиме pulldown должна определить наличие внешней подтяжки. Причем проверка в режиме pullup для этой цели не требуется.

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

Тем не менее существует функция:

HAL_StatusTypeDef HAL_I2C_IsDeviceReady(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint32_t Trials, uint32_t Timeout)

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

Я уже лазила в сорцы. Там для HAL_I2C_IsDeviceReady довольно запутанный код, однако  выяснила, что информацию она берет через функцию __HAL_I2C_GET_FLAG(...), которая определена как дефайн:

#define __HAL_I2C_GET_FLAG(__HANDLE__, __FLAG__) ((((uint8_t)((__FLAG__) >> 16U)) == 0x01U) ? \
                                                  (((((__HANDLE__)->Instance->SR1) & ((__FLAG__) & I2C_FLAG_MASK)) == ((__FLAG__) & I2C_FLAG_MASK)) ? SET : RESET) : \
                                                  (((((__HANDLE__)->Instance->SR2) & ((__FLAG__) & I2C_FLAG_MASK)) == ((__FLAG__) & I2C_FLAG_MASK)) ? SET : RESET))

Глубоко не разбираясь в коде, здесь уже видно,  что информация вытягивается из флагов регистров SR1 и SR1.
Отсюда и следующий вопрос - какие флаги для моей цели годятся? Описание всех флагов, содержащихся в этих регистрах, я уже смотрела, но почти ничего не поняла.
Наиболее перспективными (по названию) мне показались флаги (комментарий к ним чужой):

SR1->TIMEOUT (Timeout or Tlow error) — возникает если линия SCL прижата к земле. Для master 10mS, для slave 25mS.

SR2->BUSY(Bus busy) — флаг занятости.

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

Можно ли что-то подсказать мне по этому поводу?

 

10 часов назад, jcxz сказал:

Вангую, что при длительном низком уровне на SCL, должен устанавливаться бит ARLO в регистре SR1.

Этот флаг тоже смотрела, но ясности у меня не прибавилось. Вот что про него написано:

SR1->ARLO (Arbitration lost (master mode) ) — устанавливается при потере арбитража. Для сброса нужно записать 0.

На его фоне флаги SR1->TIMEOUT и SR2->BUSY выглядят в моих глазах более перспективными.

 

[HardEgor 66]

В 15.02.2024 в 17:51, Xenia сказал:

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

Так это надо делать до включения i2ç. А когда i2c включился и заработал, то только тогда, когда заканчивается нормальная работа и начинаются проблемы с ответами и запросами.