STM32 - проблемы с тактированием

[VladimirVladimirovitch]

Латентность флэша и конвейер никто не отменял. Главное что вам нужно запомнить, что время выполнения недерминировано. Можете НОПами поиграться, для интереса. Или вообще загрузить прогу в ОЗУ.

То есть на stm32 системы, критичные по времени выполнения, реал-тайм тобиш RTOS - вещь не выполнимая?

Мне вот товарищ Мурик дал скомпелированную прошивку 72.hex - в сравнении в моей - все чисто:

А у меня куда-то такты выпадают:


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

[Oxford]

считайте такты (хотя и это напрасный труд)

[offtopic]налицо последствия "современного уровня" развития вычислительной техники: зачем считать такты, если можно взять кристалл на 100500 гигагерц и не парить мозг? зачем думать об оптимизации, если памяти немеряно, мегагерцев несчитано? дураки те, кто до сих пор сидит на 8-битниках, в то время как весь прогрессивный мир заглядывается на 64-битные микроконтроллеры...[/offtopic]

Заблуждающиеся рассуждения. Есть четкие границы и понимание когда нужно думать об оптимизации и когда нет.

Добавлено after 2 minutes 3 seconds:

Латентность флэша и конвейер никто не отменял. Главное что вам нужно запомнить, что время выполнения недерминировано. Можете НОПами поиграться, для интереса. Или вообще загрузить прогу в ОЗУ.

То есть на stm32 системы, критичные по времени выполнения, реал-тайм тобиш RTOS - вещь не выполнимая?

Мне вот товарищ Мурик дал скомпелированную прошивку 72.hex - в сравнении в моей - все чисто:

А у меня куда-то такты пропадают:


Получается, что компилятор мой, гад, виноват - код то один и тот же...

Для начало ознакомьтесь что STM32 это Cortex-M профиль со своими плюшками и тараканами.

[VladimirVladimirovitch]

Для начало ознакомьтесь что STM32 это Cortex-M профиль со своими плюшками и тараканами.

То что там есть тараканы, как говорится, уже показал эксперимент
Другое дело - как бы их вывести, чтоб насладится плюшками..
Вот я думаю: неужели чтобы понять, в чем проблема в настройках моего компилятора (как понятно из темы - виноват в пропаже тактов - КОМПИЛЯТОР ) придется заучить стопятьсот страниц текста описания архитектуры CortexM и его частной реализации в виде stm32 на языке потенциального противника?

[scorpi_0n]

То есть на stm32 системы, критичные по времени выполнения, реал-тайм тобиш RTOS - вещь не выполнимая?

А причём здесь РТОС? Что вы знаете о синхронизации и джиттере? СТМ32 как раз под РТОС и заточены.

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

Всегда так было. Но в данном случае компилятор ни при делах.

Добавлено after 5 minutes 21 second:

То что там есть тараканы, как говорится, уже показал эксперимент
Другое дело - как бы их вывести, чтоб насладится плюшками..

Не считать такты там где это не нужно. Плюшки не в подсчёте тактов и не в темперированном ногодрыге, а в железе.

[Oxford]

Если вы хотите высокую надежность, отказоустойчивость и прочее есть Cortex-R, но это не означает что Cortex-M ненадежный.
Архитектура это не только ножка GPIO. Микроконтроллер выполняет ровно то что вы ему скажете делать с помощью программного кода. Ни больше ни меньше. Поэтому то что генерит ваш компилятор микронтроллеру глубоко насрать, это все ложиться на ваши плечи, а не МК. За программный код отвечает разработчик встраиваемых систем, он должен иметь определенную квалификацию. Это профессия, опыт постоянно повышается, постоянно учиться. Вся жизнь на это уходит.

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

Есть таймеры у микроконтроллера которые могут генерировать сигнал аппаратно.

[Мурик]

То есть на stm32 системы, критичные по времени выполнения, реал-тайм тобиш RTOS - вещь не выполнимая?

Настолько критично что не допустима погрешность меньше микросекунды? RTOS внесет еще большую погрешность, т. к. задачи по умолчанию переключаются каждые 1 мс.

как понятно из темы - виноват в пропаже тактов - КОМПИЛЯТОР

Компилятор сгенерировал правильный код в соотсветствии с особенностями архитектуры Cortex-M. Asm вставка похоже ее не учитывает и результат соответствующий. Вывод - не нужно мешать asm вставками работе компилятора. Он генерирует более оптимальный код, учитывая все нюансы архитектуры.

[Oxford]

У компилятора еще есть настройки по оптимизации.

[scorpi_0n]

При таком коротком коде оптимизатору то и развернуться негде.

[VladimirVladimirovitch]

У компилятора еще есть настройки по оптимизации.

Кручу. Пока -Ofast не помогло. Я тут в теме скриншотил - если у кого опыт есть-плз. гляньте возможно по дефолту там чтото криво стоит.
ps задача стоит исклютельно как разобраться с тактированием и работой gpio stm32. просто абстрактно. понять так сказать потолок на что он может в ногодрыге

Добавлено after 3 minutes 45 seconds:

При таком коротком коде оптимизатору то и развернуться негде.

вот именно. что и удивительно. на простейшем мигании светодиодом не могу добиться адекватных по коду тактов.

Добавлено after 7 minutes 3 seconds:

Компилятор сгенерировал правильный код в соотсветствии с особенностями архитектуры Cortex-M.

А нельзя ли всю эти особенности куданить выключить и оставить только gpio с тактированием?

[scorpi_0n]

вот именно. что и удивительно. на простейшем мигании светодиодом не могу добиться адекватных по коду тактов.

Там и так всё адекватно. Просто вы это понять (или принять) не можете.

[Мурик]

При таком коротком коде оптимизатору то и развернуться негде.

Ну почему же? Цикл развернуть может. Добавить NOPы для выравнивания кода и т. д.

Пока -Ofast не помогло.

Ассемблерные вставки компилятор не оптимизирует.

оставить только gpio с тактированием

Чем ногодрыг таймером или др. периферийным модулем не подходит? Производится аппаратно, более предсказуемо по временным параметрам и ядро не занято "бесполезной" работой.

[VladimirVladimirovitch]

Чем ногодрыг таймером или др. периферийным модулем не подходит?

Спасибо за подсказку. попробую завтра таймером пошевелить

[Oxford]

Так аппаратные решения это первое что нужно делать.

[oleg110592]

в тему имхо будет
STM32F1 bit banging speeds
https://vjordan.info/log/fpga/stm32-bar ... speed.html

STM32F1 can achieve 18MHz on GPIO in an enrolled loop with compiler optimizations -O2

[КРАМ]

Читаю тему и диву даюсь...

Речь об M0. Там все предельно просто с исполнением - можно посмотреть дизасм, а равно посчитать циклы в пошаговом исполнении при открытом листинге дизасма (будет шагать не по исходнику на Си, а по строчкам сгенерированного кода).
Причем тут латентности, ДМА и конвейер с совершенно не к месту упомянутым кэшем?
Конвейер вообще есть у всех контроллеров, включая PIC и AVR, хотя бы потому, что выполнять код с темпом 1 команда за 1 машинный цикл без конвейера невозможно в принципе. И время исполнения команды не 1 машинный цикл, а минимум - длина конвейера.
Что касается предложений использовать таймеры и аппаратный вывод, то, насколько я понимаю, речь вообще была не об этом. Ясен пень, что хардварный вывод будет иметь меньшую латентность В ОБЩЕМ СЛУЧАЕ. Но, во первых, ногодрыг все равно должен укладываться в написанный код (латентность должна быть объяснима РЕАЛЬНЫМИ КОНКРЕТНЫМИ процессами, а не общими рассуждениями об архитектуре), а во-вторых, далеко не всегда есть смысл и хардварные ресурсы не дергать ногой софтом. Все зависит от задачи. И именно поэтому нужно четко понимать первое, чтобы по любому поводу не хватать МК на 100500 ГГц лишь потому, что не можешь понять откуда джиттер и лень в этом разбираться.

[scorpi_0n]

Читаю тему и диву даюсь...

Это только от незнаний

Речь об M0.

Где?

Что касается предложений использовать таймеры и аппаратный вывод, то, насколько я понимаю, речь вообще была не об этом. Ясен пень, что хардварный вывод будет иметь меньшую латентность В ОБЩЕМ СЛУЧАЕ. Но, во первых, ногодрыг все равно должен укладываться в написанный код (латентность должна быть объяснима РЕАЛЬНЫМИ КОНКРЕТНЫМИ процессами, а не общими рассуждениями об архитектуре), а во-вторых, далеко не всегда есть смысл и хардварные ресурсы не дергать ногой софтом. Все зависит от задачи. И именно поэтому нужно четко понимать первое, чтобы по любому поводу не хватать МК на 100500 ГГц лишь потому, что не можешь понять откуда джиттер и лень в этом разбираться.

Если вам лень разбираться с шустрым СТМ32, разберитесь с обычным СТМ8. Там с ногодрыгом не лучше. Поэтому можно сделать вывод, что вы многое чего не понимаете.

[КРАМ]

Читаю тему и диву даюсь...

Это только от незнаний

От незнаний ЧЕГО? Что КОНКРЕТНО я сказал не то?

Речь об M0.

Где?

Сорри, М3. Но к теме обсуждения это не имеет никакого отношения.

Если вам лень разбираться с шустрым СТМ32, разберитесь с обычным СТМ8. Там с ногодрыгом не лучше. Поэтому можно сделать вывод, что вы многое чего не понимаете.

Такое ощущение, что Вы бредите... Или не умеете читать литературный русский текст.
Причем тут шустрый STM32 или не шустрый STM8?
Попробуйте прочесть мой предыдущий пост еще раз и найдите хотя бы 1 пункт из моего текста на который Вы ответили. В огороде бузина, а в Киеве дядька...
В простейшей программе без всяких ДМА с известным АСМ листингом все совершенно четко определено по времени.

[scorpi_0n]

Да не смешите. Постом выше Олег дал ссылку, сами полюбуйтесь. Любые изменения в проге будут давать отклонения в тактах при ногодрыге. Поэтому для точных решений и предлагают юзать железо. Но вам это почему-то не понятно. Что вы своим постом и выразили. Не даётся вам СТМ32? Это не смертельно.

[КРАМ]

Скорпион, Вы как то все сегодня невпопад...
В каком месте я утверждал, что изменения в коде не должны приводить к изменению диаграммы?

Все что я сказал, - диаграмма совершенно четко повторит код на АСМе (дизасм). И все вопросы по этому поводу элементарно выясняются отладчиком (симулятором) по шагам дизасма. Никаких кэшей, ДМА и прерываний с конвейером в причинах дерганного вывода искать неслед.
И все.
Что это Вас так расколбасило -мне совершенно непонятно....
ЗЫ. Для предложенного простейшего кода нет никакой разницы между АРМами и любой другой архитектурой. НА ЛЮБОМ контроллере (при отсутствии прерывающих программу инструментов (ДМА, прерывания и т.п.) диаграмму так же точно будут менять любые изменения кода на Си и так же диаграмма будет определяться исключительно загружаемым кодом, который легко увидеть в символике АСМа.

[scorpi_0n]

Какая ещё диаграмма? Самый простой пример - короткий и простой обработчик прерывания. Выход из прерывания происходит раньше чем сбрасывается флаг его вызвавший со всеми вытекающими. Ну и каким боком здесь ваша диаграмма, подсчет тактов и прочее?
Если бы было все так просто то и этого топика бы небыло. И если вы такты как в АВР считаете, то это в корне не верно. Прочтите тему сначала, может и поймете о чем речь. Да и толку с этой диаграммы, если при изменении проги она сломается? Ровнять ещё после малейших изменений в проге? Удачи! Есть же доки на камень, прочтите, не поленитесь, хоть разок, чтобы понять что к чему.