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

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

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


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

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

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


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

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

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

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

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

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

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где?

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

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

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

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

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

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

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

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