[juvf 10]

Подскажите, на 2019 год аппаратный i2c в stm32f* годный?

[ViKo 1]

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

[Arlleex 131]

Если прочитать и понять весь раздел про I2C в мануале и запрограммировать, то полет будет нормальный. Накидать из примеров незнамо чего и надеяться на то, что оно не выстрелит когда не надо, не получится. Под пиво свободным субботним вечером взлетит за пару часов со всякими обработками ошибок и прочим. Но только внятно читая мануал; я постоянно натыкался на проблемы из "примеров", пока однажды тупо не сел и написал с нуля драйвер.

Конечно, модуль этот в реалиях и понятиях STM, я бы сказал, очень так себе. Но работает. Запускал на STM32F4.

[jcxz 184]

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

Подскажите, на 2019 год аппаратный i2c в stm32f* годный?

Не бывает негодных железок, бывают негодные погромисты. имха.

[adnega 10]

1 час назад, Arlleex сказал:

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

И в ES будет не лишним заглянуть.

[AVI-crak 0]

Да кстати, к 2019 году можно было сделать полностью аппаратную физику i2c. Без этих вот дополнительных шестнадцати флагов переменной важности.

[aaarrr 63]

50 minutes ago, jcxz said:

Не бывает негодных железок, бывают негодные погромисты. имха.

Можно подумать, железки делают исключительно годные программисты.

[haker_fox 60]

6 hours ago, juvf said:

Подскажите, на 2019 год аппаратный i2c в stm32f* годный?

Работал с STM32F051 несколько лет назад. Этот интерфейс и там и тогда был годный. Но из-за обилия настроек довольно муторный в программировании.

[KnightIgor 2]

15 hours ago, juvf said:

Подскажите, на 2019 год аппаратный i2c в stm32f* годный?

На сегодняшний день за последние 10 лет ничего не изменилось, и на вопрос нельзя дать однозначный ответ: в разных stm32f* - разные I2C. Все начиналось с F1xx, где I2C такой, словно французы его запилили на пикнике, нажравшись бордо и закусив самым заплесневелым сыром. Вроде и F4xx унаследовали этот пьяный бред. Протрезвев лишь через несколько лет, на последующих моделях M0 и M0+ ребята радикально сменили спецификацию, и стало возможным работать, но и этот I2C все еще требует достаточно ручных усилий в отличие, например, от I2C на Кортексах от Atmel (ныне - часть Microchip), где I2C называлась TWI и обеспечивала полные транзакции почти полностью аппаратно.

Если под "stm32f*" имеется ввиду действительно F1xx (и, возможно, F4xx), то по нему я высказывался и предлагал решения здесь неоднократно. Основные заморочки:

• не любит I2C, когда его прерывают, поэтому обработчик прерываний I2C должен иметь наивысший приоритет в системе.
• транзакции чтения с 1 или 2 байтами (или поведение обработчика, когда осталось принять 1 или 2 байта) требуют особого алгоритма обработки.
• замечено, что можно влететь в прерывание с набором флагов, не описанных в документации, и если не прореагировать на такую смесь, транзакция рушится.

На F0xx все выглядит иначе, гораздо стабильней и проще.

[serglg 0]

если говорить только про ЕЕПРОМ по I2C, тоу меня никаких проблем с STM32F446 не было.

Но сами понимаете, что там уровень обмена мизерный. И у меня даже без прерываний.

 

[VladislavS 29]

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

[Arlleex 131]

11 минут назад, serglg сказал:

если говорить только про ЕЕПРОМ по I2C, тоу меня никаких проблем с STM32F446 не было.

Но сами понимаете, что там уровень обмена мизерный. И у меня даже без прерываний.

Для ядра, работающего на 180МГц, о загрузке CPU даже речи не может быть при любом потоке I2C (а в STM32 это максимум 400кбит/с, вроде бы). Ну, конечно, если в лоб не писать суперцикл с ожиданиями на while()-ах.

[juvf 10]

всем спасибо.

поднял и2ц из куба. с полпинка не взлетело. Бытует мнение, что аппаратный и2ц кривой. Вот и решил выяснить, прежде чем ковыряться в нем.

и2ц на ф103 заработал со второго полпинка. Не вставал флаг передачи адреса после первого байта (адрес+r/w). Разобрался. Смутила ещё осциллограмма передачи первого байта. Какие-то фронты данных почти одновременно с фронтами клока.... да и длительность "1" разная..... Но слейв вроде стабильно отвечает.

На картинке передача start + 0xA0 + ASK

[AlanDrakes 1]

Это просто у Вас попался бит "1" сразу после "START", потому его длительность и была короче - ведомый должен получить сам сигнал начала транзакции, а уже затем в состоянии SCL=0 можно менять состояние SDA. Но так как требуется сразу передать "1" - автоматика вынуждена делать такой финт на начале.

Попробуйте передать адрес, например, 0x55 - все единицы и нули будут иметь одинаковую длину.

[Velund 0]

On 5/31/2019 at 10:26 PM, juvf said:

и2ц на ф103 заработал со второго полпинка.

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