[Arlleex 189]

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

...всякие остановки растягивают надолго SCL, что, похоже, вводит в заблуждение как саму машину I2C, так и периферию.

Там в STM-ках в регистрах DEBUG-а модуль I2C можно, вроде, также "замораживать", как, например, таймеры. Может, поможет чем-то. А насчет ввода в заблуждение периферии - очень вряд ли, I2C построен на т.н. статической логике - минимальная тактовая равна 0. SMBUS, надстройка над I2C, эту статичность ломает, поэтому там да, просто так остановить транзакцию в любом месте, не порушив обмен, не получится. Разве что, как я говорил, через модуль DEBUG.

[KnightIgor 2]

5 hours ago, Arlleex said:

Там в STM-ках в регистрах DEBUG-а модуль I2C можно, вроде, также "замораживать", как, например, таймеры. Может, поможет чем-то. А насчет ввода в заблуждение периферии - очень вряд ли, I2C построен на т.н. статической логике - минимальная тактовая равна 0. SMBUS, надстройка над I2C, эту статичность ломает, поэтому там да, просто так остановить транзакцию в любом месте, не порушив обмен, не получится. Разве что, как я говорил, через модуль DEBUG.

Основная проблема с STM321xx и аналогично - с GD32F1xx, - разрушающее действие отладчика (not "non intrusive"). Да, да, именно так дела и обстоят, хотя и не должны. Об этом писалось 10-12 лет назад в этом форуме тоже. Самая неприятная вещь, что бит ADDR в регистре SR1 стирается, когда отладчик считывает SR1 и SR2 - именно такая последовательность описана в доке для сброса бита ADDR. Поэтому при отладке исполнение любой команды (хоть одной ассемблерной) после остановки, где еще виден этот установленный бит, тут же его сбрасывает. И понеслась: полное нарушение логики периферии.

[x893 60]

27 minutes ago, KnightIgor said:

Самая неприятная вещь, что бит ADDR в регистре SR1 стирается, когда отладчик считывает SR1 и SR2

Так и останавливатесь после чтения из этих регистров.

И не будет никакого разрушения мозга.

[Arlleex 189]

9 часов назад, KnightIgor сказал:

Основная проблема с STM321xx и аналогично - с GD32F1xx, - разрушающее действие отладчика (not "non intrusive")...

DAP подключен к адресному пространству ровно таким же способом, как и CPU (т.е. является полноценным шинным мастером), поэтому для периферии нет волшебного указания, кто сейчас работает с ней. Так сделано не только в STM32, но и во многих других МК на базе Cortex-M (хотя не только Cortex-M, потому что CoreSight DAP - это целая архитектура отладочных средств, узаконенная на бумаге ARM-ом). В целом я с Вами согласен насчет кривоватости I2C в STM-ках. Однако не такая там большая беда, как ее здесь описывали многие Попробуйте в связке с DMA работать - насколько помню (давно I2C + DMA юзал), там будет чуть проще даже.
 

8 часов назад, x893 сказал:

Так и останавливатесь после чтения из этих регистров.

Я не знаю, в какой среде работает KnightIgor, у меня, например, Keil.
В нем, если окошко с регистрами I2C открыть и запустить программу на исполнение, работа с периферией порушится.

P.S. А. Вы имеете ввиду поставить точку останова и лишь после этого открывать регистры? Может сработать, да. Но не везде удобно.

[x893 60]

13 minutes ago, Arlleex said:

Может сработать, да. Но не везде удобно.

Тут надо определиться - либо шашечки, либо ехать

[Сергей Борщ 143]

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

Самая неприятная вещь, что бит ADDR в регистре SR1 стирается, когда отладчик считывает SR1 и SR2 - именно такая последовательность описана в доке для сброса бита ADDR

У многих отладчиков регистры описаны в текстовом файле. Можно поменять местами их описания в этом файле и отладчик будет их считывать в обратном порядке. "Я так думаю".

[KnightIgor 2]

6 hours ago, Arlleex said:

DAP подключен к адресному пространству ровно таким же способом, как и CPU (т.е. является полноценным шинным мастером), поэтому для периферии нет волшебного указания, кто сейчас работает с ней. Так сделано не только в STM32, но и во многих других МК на базе Cortex-M (хотя не только Cortex-M, потому что CoreSight DAP - это целая архитектура отладочных средств, узаконенная на бумаге ARM-ом). В целом я с Вами согласен насчет кривоватости I2C в STM-ках. Однако не такая там большая беда, как ее здесь описывали многие Попробуйте в связке с DMA работать - насколько помню (давно I2C + DMA юзал), там будет чуть проще даже.
 

Я не знаю, в какой среде работает KnightIgor, у меня, например, Keil.
В нем, если окошко с регистрами I2C открыть и запустить программу на исполнение, работа с периферией порушится.

P.S. А. Вы имеете ввиду поставить точку останова и лишь после этого открывать регистры? Может сработать, да. Но не везде удобно.

У меня как KEIL, так и CubeIDE. Текущий проект, в который втулили GD32F, - под CubeIDE, но и под KEIL наблюдается влияние отладчика (разработку поддержки для I2C я делал под ним в далекие годы). Я не разработчик микропроцессоров, но "non intrusive" - это важная характеристика. Помнится, C8051 процессоры от SiLabs имели даже JTAG (у меня был проект с таким процессором и FPGA в связке по JTAG Chain), и там SiLabs делал (маркетинговый) акцент на "non intrusive", и это работало.

Мой "драйвер" для I2C для STM32 может работать как по прерываниям, так и по DMA: определяю во время компиляции. В данном проекте эти каналы DMA используются для UART для подержки modbus, поэтому приходится только по прерываниям.

 

Актуализация по GD32F103.

Вчера потратил пол-дня и втулил пример из библиотеки поддержки для GD32F1xx с синхронной работой с I2C в проект. Заработало, но удовлетворения не принесло...

 

P.S. Как я писал, канал температуры в ADC в GD32F103 при нормальном питании в 3.3V залипает на максимуме. Тут вдруг попала в руки плата с GD32F303. Бинарник для GD32F103 взлетел на нем моментально, и температурный канал ADC работает правильно. Следом пробежала инфа от дистрибьютора, что GigaDevice рекомендует применять 303 вместо 103.

Изменено 11 октября, 2021 пользователем KnightIgor

[nanorobot 6]

On 10/7/2021 at 10:57 PM, Vasily_ said:

А что мешает взять кортекс от Майкрочип ?

Незнакомая периферия, меньшее, по сравнению с STM32, community.  Отсутствие порта ChibiOS.  Но все равно взял, пробую...

[Forger 26]

13 minutes ago, nanorobot said:

Отсутствие порта ChibiOS.

А разве там не кортекс? Порты во всех нормальных осях "затачиваются" под ядро, но не периферию.

Более того, правилом хорошем тона является писать под CMSIS, а по-хорошему надо сразу под CMSIS_OS. В таком случае проект вообще не привязан к какой-то конкретной оси.

 

[Vasily_ 59]

44 минуты назад, nanorobot сказал:

Незнакомая периферия

Пару вечеров по изучать.

 

44 минуты назад, nanorobot сказал:

меньшее, по сравнению с STM32, community.

В данный момент это большой плюс.

 

44 минуты назад, nanorobot сказал:

Отсутствие порта ChibiOS.

Не в курсе, но думаю это не проблема.

[haker_fox 61]

7 minutes ago, Vasily_ said:

Пару вечеров по изучать.

Только один-два вида периферии. Но не в этом дело, работаю с LPC/STM лет восемь с копейками. Не хочется менять нарботки. Тем не менее, без проблем перейду, если понадобится. В целом я Ваш ответ понял)

53 minutes ago, nanorobot said:

Отсутствие порта ChibiOS

А как ОС привязана к периферии? Ведь всё осезависимое у кортексов одинаковое: systic, pends, svc.

[nanorobot 6]

14 minutes ago, haker_fox said:

А как ОС привязана к периферии? Ведь всё осезависимое у кортексов одинаковое: systic, pends, svc.

ОС не привязана к периферии , я этого и не утверждал. Но в ChibiOS еще и HAL имеется.

Изменено 11 октября, 2021 пользователем nanorobot

[Forger 26]

11 minutes ago, nanorobot said:

Но в ChibiOS еще и HAL имеется.

??? 

[nanorobot 6]

5 minutes ago, Forger said:

??? 

https://www.chibios.org/dokuwiki/doku.php?id=chibios:products:hal:start

[haker_fox 61]

25 minutes ago, nanorobot said:

Но в ChibiOS еще и HAL имеется.

Это понятно. Вы имете в виду на периферию общего назначения: таймеры, порты, АЦП, ЦАП?

9 minutes ago, nanorobot said:

https://www.chibios.org/dokuwiki/doku.php?id=chibios:products:hal:start

Класс! Можно поупражняться в портировании!