Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

P82B96

P82B715

 

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

One_mile_long_I2C_communication_using_the_P82B715.pdf

Philips_I2C_bus__extending_its_reach.pdf

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня возник еще один животрепещущий вопрос.
Контроллер (у меня это 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 не зависал, если на ней нет подтяжки?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 hours ago, Xenia said:

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

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

 

 

9 hours ago, Xenia said:

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 выглядят в моих глазах более перспективными.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...