okela 0 8 июня, 2005 Опубликовано 8 июня, 2005 · Жалоба Подскажите, плс, как далеко можно пулять по шине I2C в стандартном и быстром режимах (интересует максимальная длина линии без потерь инф-ции) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alexandr 0 8 июня, 2005 Опубликовано 8 июня, 2005 · Жалоба Длина соединительных линий в стандартном режиме может достигать 2-х метров, скорость передачи до 100 кбит/с. http://www.rs232.ru/docs/i2c/iic_rus.pdf Но на то он и стандартный режим ;) На самом деле конечно больше, где-то на 5м делал Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
belousov 0 8 июня, 2005 Опубликовано 8 июня, 2005 · Жалоба Ограничение по расстоянию можно снять с помощью буферов, например: P82B96 P82B715 Philips предлагает две статьи по этому поводу: One_mile_long_I2C_communication_using_the_P82B715.pdf Philips_I2C_bus__extending_its_reach.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 5 октября, 2023 Опубликовано 5 октября, 2023 · Жалоба У меня совсем короткий вопрос про ... SMBAL. У STM32 бывает по штуке на каждом I2C: I2C1_SMBAL, I2C2_SMBAL и т.д. По описанию это линия активации прерывания от каких-то SLAVE-устройств. Однако у CubeMX номер прерывания для нее не задает. Тем не менее, I2C "подминает" этот пин под себя, например не дает таймеру TIM3_CH2 с этим пином работать. Мой вопрос: можно ли использовать SMBAL-пин в качестве выхода, как обычный GPIO? Не повредит ли это работе I2C, если оно в это время работает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 75 5 октября, 2023 Опубликовано 5 октября, 2023 · Жалоба 29 минут назад, Xenia сказал: можно ли использовать SMBAL-пин в качестве выхода, как обычный GPIO? Не повредит ли это работе I2C, если оно в это время работает? Это SMBus alert, если у вас не SMBus , а простой I2C , то можно использовать как заблагорассудится) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 6 октября, 2023 Опубликовано 6 октября, 2023 · Жалоба А почему тогда I2C его для себя резервирует? А и откуда ему знать, какая у меня шина - SMBus или нет? А раз есть SMBAL, то вероятно I2C должна как-то на него реагировать, а иначе зачем он? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 75 6 октября, 2023 Опубликовано 6 октября, 2023 · Жалоба 38 минут назад, Xenia сказал: А и откуда ему знать, какая у меня шина - SMBus или нет? По-идее должно выбираться при конфигурации и там выбрать - или I2C или SMbus. Надежнее банально посмотреть в код куба. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 6 октября, 2023 Опубликовано 6 октября, 2023 · Жалоба 5 минут назад, HardEgor сказал: По-идее должно выбираться при конфигурации и там выбрать - или I2C или SMbus. Согласна, действительно это задается в конфигурации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 14 февраля Опубликовано 14 февраля · Жалоба У меня возник еще один животрепещущий вопрос. Контроллер (у меня это 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 231 15 февраля Опубликовано 15 февраля · Жалоба 2 часа назад, Xenia сказал: Вопрос: есть ли какой-то способ проверить наличие подтяжки на линиях SDA и SCL Вангую, что при длительном низком уровне на SCL, должен устанавливаться бит ARLO в регистре SR1. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
siargy 6 15 февраля Опубликовано 15 февраля · Жалоба 9 hours ago, Xenia said: линии SDA и SCL не подтянуты к питанию перед вызовом функции можно проверить, что на выводах высокий уровень 9 hours ago, Xenia said: Уже пробовала определять уровень на пинах SDA и SCL, но получаю результат такой, что оба пина имеют высокий потенциал, как и должно быть. не дочитал. а физически там высокий уровень? кстати не всегда библиотечные функции обладают заявленным функционалом Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 51 15 февраля Опубликовано 15 февраля · Жалоба Есть документ от NXP как инициализировать i2c шину. римерно 15-ти летней давности. ам точно была цифра в 80 тактов по SCL - по ней можно найти. Проверить подтяжку проще пареной репы. Включить пины на INPUT-PULL-DOWN и считать уровень. Но есть ньюнсы, если слейв зажал SCL вниз. Для решения этой проблемы - читать документ от NXP . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 75 15 февраля Опубликовано 15 февраля · Жалоба В 15.02.2024 в 05:01, Xenia сказал: Я отлично понимаю, что случай, когда линии I2C не потянуты к питанию резисторами - аномальная ситуация, в которой нельзя требовать от шины нормальной работы. Однако мне сильно хочется, чтобы обрыв в шины (а резисторы подтяжки находятся на слейве, т.к. этот контролер не умеет такую подтяжку создавать сам, а на плате она не предусмотрена) не приводил к зависанию, чтобы контроллер мог бы выдать по этому поводу вразумительное сообщение об ошибке. Типа: "Шина I2C оборвана". Уже пробовала определять уровень на пинах Включить встроенную подтяжку pullup, проверить уровень, затем включить pulldown и тоже проверить уровень. Естественно проверять в режиме gpio Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Xenia 42 15 февраля Опубликовано 15 февраля · Жалоба 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 75 15 февраля Опубликовано 15 февраля · Жалоба В 15.02.2024 в 17:51, Xenia сказал: Одно только плохо - для такого рода теста пришлось бы постоянно отключать I2C и переходить в режим обычного GPIO_MODE_INPUT, а после проведения теста вновь инициировать режим I2C. Это было бы не страшно, если делать этот тест только перед началом работы, но сильно обременительно, если обрыв линии возможен в процессе работы (сильно замедлило бы как чтение, так и запись по шине). Тем более что при переходе из режима I2C в GPIO и обратно требуется выдерживать какие-то таймауты. Так это надо делать до включения i2ç. А когда i2c включился и заработал, то только тогда, когда заканчивается нормальная работа и начинаются проблемы с ответами и запросами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться