Доброго времени суток.
Перехожу с аврок на стм32, приходится писать на С. Столкнулся с проблемой: при включении оптимизации компилятора нижеприведенный код (приведен в упрощенном виде) выщёлкивается из итогового образа напрочь.
[/color]
Если cycle_counter объявить как volatile - всё работает, но если нет, то цикл при включенной оптмизиации в итоговый код не попадает.
Как же так, условие в while(...) же не статическое, RCC->CR в коде CMSIS объявлено как __IO uint32_t CR; где __IO - алиас для того же volatile, соответственно, его значение на этапе компиляции не определено. Чтобы выкинуть кусок кода, компилятор должен быть уверен, что код никогда не будет выполнен. Здесь же он вполне себе выполняется из-за того, что значение регистра меняется извне, и об этом компилятору дана соответствующая директива (__IO uint32_t CR;).
Вопрос - в чем логика такого поведения компилятора (gcc@STM32CubeIDE).
Перехожу с аврок на стм32, приходится писать на С. Столкнулся с проблемой: при включении оптимизации компилятора нижеприведенный код (приведен в упрощенном виде) выщёлкивается из итогового образа напрочь.
Код: Выделить всё
void InitRCC_HSE() {
uint32_t cycle_counter;
cycle_counter = 0;
//Ждем заданное количество циклов флага стабильности частоты HSE
while (READ_BIT(RCC->CR, RCC_CR_HSERDY) == 0U) {
cycle_counter++;
if (cycle_counter == HSE_READY_TIMEOUT) {
//дальше обработка ошибки
}
}Если cycle_counter объявить как volatile - всё работает, но если нет, то цикл при включенной оптмизиации в итоговый код не попадает.
Как же так, условие в while(...) же не статическое, RCC->CR в коде CMSIS объявлено как __IO uint32_t CR; где __IO - алиас для того же volatile, соответственно, его значение на этапе компиляции не определено. Чтобы выкинуть кусок кода, компилятор должен быть уверен, что код никогда не будет выполнен. Здесь же он вполне себе выполняется из-за того, что значение регистра меняется извне, и об этом компилятору дана соответствующая директива (__IO uint32_t CR;).
Вопрос - в чем логика такого поведения компилятора (gcc@STM32CubeIDE).
), т.к. неоптмизированный код цикла содержал 3 лишних ассемблерных инструкции, соответственно, в абсолютном выражении работал чуть дольше. Поэтому одна версия впритирку пролазила в таймаут стабилизации HSE, а другая - валилась в ошибку. Увеличил таймаут до 2000 - всё стало ок 
.
Если изначально было: