Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Keil uVision ARM v 5.16a странное поведение
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
__inline__
1)

Собираю проект в Keil ARM 5.16a для STM32F407 с максимальной оптимизацией по скорости Otime, O3.

По мере написания проекта столкнулся со странным поведением, при максимальной оптимизации O3 программа иногда идёт иногда нет, зависит от порядка расположения переменных, функций. Если поменять их порядок местами, то иногда удаётся получить работающий код при O3.

Опытным путём через #pragma optimize был выявлен проблемный кусок: им оказалась точка входа в main(). Если всё заоптимизировать с O3, но точку входа в main сделать O1 (выше может не пойти), то будет работать:

Код
#pragma push
#pragma Otime
#pragma O3

//Тут переменные, функции , константы, макросы............

//Точка входа в main с уровнем оптимизации не более O1, если поставить выше, то в некоторых случаях может не заработать. Глюк Keil ???
#pragma push
#pragma Otime
#pragma O1

int main(void)
{
#pragma push
#pragma Otime
#pragma O3

//тут программа.........

#pragma pop
}

#pragma pop

#pragma pop


С чем может быть связано такое поведение?

2)
Использую CMSIS-овскую функцию __REV16(), в ассемблерном листинге она вставляется в виде перехода на функцию, а не как одна ассемблерная инструкция.
Причем остальные типа: __REV() , __CLZ() встраиваются в виде инструкций.

Заменил __REV16() на :
Код
inline u32  rev16(u32 x)
{
__asm("REV16 x,x");
  return x;
}


и в листинге идёт вставка ассемблерной инструкции без перехода как на функцию.

Получается, что используя CMSIS , доверяй, но проверяй?
SasaVitebsk
Странно. Использовал _REV16 и аналогичные и в KEIL и в IAR - не замечал никаких глюков. Оптимизация максимальная по скорости.
В кейле я сейчас не работаю. Проект был на старом месте работы. Как меняет IAR эти макросы - могу посмотреть, если хотите.
Aaron
Цитата
программа иногда идёт иногда нет, зависит от порядка расположения переменных, функций. Если поменять их порядок местами, то иногда удаётся получить работающий код при O3

посмотрите map-файл, что располагается в памяти рядом с main() в нерабочих билдах, и что в рабочих билдах. Соседи меняются? Вот соседей и проверять дальше попробовать
Kabdim
1) UB, либо выход за пределы массива - 99%. Вообще 99% случаев когда говорят об ошибках в компиляторе на самом деле ошибка в исходниках. sm.gif
картошка
Думаю, если вы используете микроконтроллер - значит используете периферию. Если периферию - значит возможно прерывания. Если прерывания - то не забывайте VOLATILE ставить где надо.
__inline__
Цитата(SasaVitebsk @ Mar 12 2018, 20:19) *
Странно. Использовал _REV16 и аналогичные и в KEIL и в IAR - не замечал никаких глюков. Оптимизация максимальная по скорости.
В кейле я сейчас не работаю. Проект был на старом месте работы. Как меняет IAR эти макросы - могу посмотреть, если хотите.


С IAR-ом незнаком, смотреть лучше в любом случае, если критично по скорости.

Цитата(Kabdim @ Mar 13 2018, 09:02) *
1) UB, либо выход за пределы массива - 99%. Вообще 99% случаев когда говорят об ошибках в компиляторе на самом деле ошибка в исходниках. sm.gif


UB - undefined behavior (неопределенное поведение?). Вполне возможно, что вы правы, приходится много работать с чужими исходными кодами, в которых может быть всё что угодно.
Утечка памяти и выход за пределы массива с нечётко объявленными границами, например.

Вот недавно пришлось скрестить C + C++ + ASM sm.gif
Потому что часть исходников написаны на плюсах, с объявлением классов, а часть обработки звука на Асме sm.gif



Цитата(картошка @ Mar 15 2018, 20:19) *
Думаю, если вы используете микроконтроллер - значит используете периферию. Если периферию - значит возможно прерывания. Если прерывания - то не забывайте VOLATILE ставить где надо.

sm.gif Я очень ревностно слежу за волатайлами, чтоб они были объявлены должным образом!
Все регистры периферии, порты ввода-выводи и переменные в обработчиках прерываний, использующиеся внаружу - всё volatile sm.gif

Чтоб небыть голословным:

Дано: Keil uVision 5.16a. Более старшие не идут в WinXP. Версии компилеров: 5.06(build 20) и 5.05 upd.2 (build 169).
Оптмизация: -O3, -oTime (максимальная по скорости). Установка глобальная. В сорцах прочих прагм оптимизации нет.

Фрагмент кода:
Код
*pL++=(__REV16(G)&0xFF0000FF)|(R&0x00FF0000)|(B&0x0000FF00);


В листинге выглядит так:
Код
...
    RRS     r0,r0,r1
        STR      r0,[r4],#4
        MOV      r0,r11
        BL       __asm___6_main_c_NEXT____REV16
        BFC      r0,#8,#16
        AND      r1,r7,#0xff0000
        ORRS     r0,r0,r1
...

    AREA ||.rev16_text||, CODE
    THUMB
    EXPORT |__asm___6_main_c_NEXT____REV16|
#line 129 "C:\\Keil_v5\\ARM\\CMSIS\\Include\\core_cmInstr.h"
|__asm___6_main_c_NEXT____REV16| PROC
#line 130

rev16 r0, r0
bx lr
    ENDP
...


Смешно и грустно одовременно. Пришлось с-инлайнить самостоятельно.
__inline__
А по первому пункту вопроса, в ходе копаний стало ясно почему программа не работала с -O3.

Не стартовал ЦАП и не происходило прерывание от него, которое синхронизировало внутренний цикл программы. Программа просто зависала и ждала снятия флага по прерыванию.

А ЦАП не стартовал из-за некорректной отработки функции инициализации ЦАП+ДМА+Таймер.
Заменил обычную память под выделяемые структуры на динамическую. Всё сразу заработало!

Вполне возможно, что SPL-ный говнокод приводит к большому потреблению памяти на структуры инициализации и переполнению стека, что при разных оптимизациях вполне возможно.
Ну и как проинитил часть железа - сразу осовобожать память.

Вот фрагмент кода в котором происходила проблема:

Код
static void DAC_DMA_IRQ_Config()
{
DMA_DeInit(DMA1_Stream5);

DMA_InitTypeDef *DMA_InitStructure=malloc(sizeof(DMA_InitTypeDef));

DMA_InitStructure->DMA_Channel           =DMA_Channel_7;
DMA_InitStructure->DMA_PeripheralBaseAddr=DAC_DHR12R1;
DMA_InitStructure->DMA_Memory0BaseAddr   =(u32)&AudioBuffer;
DMA_InitStructure->DMA_DIR               =DMA_DIR_MemoryToPeripheral;
DMA_InitStructure->DMA_BufferSize        =L<<1;
DMA_InitStructure->DMA_PeripheralInc     =DMA_PeripheralInc_Disable;
DMA_InitStructure->DMA_MemoryInc         =DMA_MemoryInc_Enable;
DMA_InitStructure->DMA_PeripheralDataSize=DMA_PeripheralDataSize_HalfWord;
DMA_InitStructure->DMA_MemoryDataSize    =DMA_MemoryDataSize_HalfWord;
DMA_InitStructure->DMA_Mode              =DMA_Mode_Circular;
DMA_InitStructure->DMA_Priority          =DMA_Priority_VeryHigh;
DMA_InitStructure->DMA_FIFOMode          =DMA_FIFOMode_Disable;
DMA_InitStructure->DMA_FIFOThreshold     =DMA_FIFOThreshold_HalfFull;
DMA_InitStructure->DMA_MemoryBurst       =DMA_MemoryBurst_Single;
DMA_InitStructure->DMA_PeripheralBurst   =DMA_PeripheralBurst_Single;

DMA_Init(DMA1_Stream5,DMA_InitStructure);

free(DMA_InitStructure);

DMA_ITConfig(DMA1_Stream5,DMA_IT_HT|DMA_IT_TC,ENABLE);

NVIC_InitTypeDef *NVIC_InitStructure=malloc(sizeof(NVIC_InitStructure));

NVIC_InitStructure->NVIC_IRQChannel=DMA1_Stream5_IRQn;
NVIC_InitStructure->NVIC_IRQChannelPreemptionPriority=0;
NVIC_InitStructure->NVIC_IRQChannelSubPriority=0;
NVIC_InitStructure->NVIC_IRQChannelCmd=ENABLE;

NVIC_Init(NVIC_InitStructure);

free(NVIC_InitStructure);

DAC_InitTypeDef *DAC_InitStructure=malloc(sizeof(DAC_InitTypeDef));

DAC_InitStructure->DAC_Trigger       =DAC_Trigger_T6_TRGO;
DAC_InitStructure->DAC_WaveGeneration=DAC_WaveGeneration_None;
DAC_InitStructure->DAC_OutputBuffer  =DAC_OutputBuffer_Enable;
DAC_Init(DAC_Channel_1,DAC_InitStructure);

free(DAC_InitStructure);
}


Но стоит только выделить под структуры статическую память (а она будет будет взята из секции стека, так как идёт из вызова процедуры), работать при -O3 перестанет.

Код работает и со статической памятью, если его вызвать не как функцию, а в main() написать всё что внутри void DAC_DMA_IRQ_Config(). Потому что память на структуры берется уже не из секции стека, а из секции DATA, которая больше. К сожалению говнокод, который в SPL приводит к таким вот неприятным вещам ...

Проблема решена. sm.gif
copov
Глюки с прагмами, как заявляет разработчик, решены только в самой последней версии компилятора 5.06 update 6 (build 750), которая даже новей, чем внутри MDK ARM версии 5.24a.
https://developer.arm.com/products/software...loads/version-5
Проще внедрить в Keil новый компилятор установив его в каталог Keil_v5\ARM\ARMCC
__inline__
Цитата(copov @ Mar 21 2018, 13:48) *
Глюки с прагмами, как заявляет разработчик, решены только в самой последней версии компилятора 5.06 update 6 (build 750), которая даже новей, чем внутри MDK ARM версии 5.24a.
https://developer.arm.com/products/software...loads/version-5
Проще внедрить в Keil новый компилятор установив его в каталог Keil_v5\ARM\ARMCC


Тут беда была не из-за прагм. Прагмы как раз работали. И компилятор свежий (версии тоже писал выше). Скачал ARM Compiler V6. Попробую его к Кейлу прикрутить (если будет клянчить лицензию - тогда fail)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.