Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FreeRTOS в Nordic nRF52
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Axel
В связи с упражнениями с nRF52832 и евойным SoftDevice пришлось обратиться к FreeRTOS. Естественно возникли вопросы, например: при компиляции проекта возникает куча жалоб типа "Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement...". Суть понятна, но поскольку отследить использование этих volatile'ов в коде ОС непросто, присутствует "неприятный осадок". Стоит ли переживать по этому поводу?
juvf
Можно заглушить этот ворнинг. Но не должно быть ни каких ворнингов изначально. У меня не разу не выскакивал подобный ворнинг, специально его я не глушил. А можете показать в каком месте FreeRTOS этот ворнинг и какая версия OС?
AlexandrY
Цитата(Axel @ Mar 26 2018, 03:41) *
Стоит ли переживать по этому поводу?

В коде RTOS такое невозможно. Это либо код порта либо функций периферии.
Т.е. то, что пишется менее квалифицированными людьми.
Исправлять надо обязательно.
Axel
"...в каком месте FreeRTOS этот ворнинг и какая версия OС?"
Версия довольно старая - 8.2.1 (она идет в составе последнего SDK от Nordic). Обновлять до последней (10-й) версии для меня - ввязаться в процесс починки непонятного неизвестным. Не вдохновляет (пока)... Ворнинги - по поводу компиляции файла "task.c" в ситуациях типа "portRESET_READY_PRIORITY( pxCurrentTCB->uxPriority, uxTopReadyPriority );"


Цитата(AlexandrY @ Mar 26 2018, 09:29) *
В коде RTOS такое невозможно. Это либо код порта либо функций периферии.
Т.е. то, что пишется менее квалифицированными людьми.
Исправлять надо обязательно.

"Да, уж..."©
AlexandrY
Цитата(Axel @ Mar 26 2018, 14:20) *
Ворнинги - по поводу компиляции файла "task.c" в ситуациях типа "portRESET_READY_PRIORITY( pxCurrentTCB->uxPriority, uxTopReadyPriority );"

Похоже у вас в структуре tskTaskControlBlock переменная uxPriority объявлена как volatile.
Нужно просто чуть чуть подправить макрос portRESET_READY_PRIORITY
Axel
Цитата(AlexandrY @ Mar 26 2018, 15:57) *
Похоже у вас в структуре tskTaskControlBlock переменная uxPriority объявлена как volatile.
Нужно просто чуть чуть подправить макрос portRESET_READY_PRIORITY

Ну да, объявлена, и не она одна. Но для того, чтобы их осознанно "разволетайлить", надо точно представить себе их использование в других фрагментах кода, что, как минимум, не быстро.
AlexandrY
Цитата(Axel @ Mar 26 2018, 16:25) *
Ну да, объявлена, и не она одна. Но для того, чтобы их осознанно "разволетайлить", надо точно представить себе их использование в других фрагментах кода, что, как минимум, не быстро.

В макрос можно вставить локальную переменную чтобы упорядочить чтение из volatile переменных.
Axel
Цитата(AlexandrY @ Mar 26 2018, 16:46) *
В макрос можно вставить локальную переменную чтобы упорядочить чтение из volatile переменных.

Я пока так и сделал, спасибо.
juvf
Цитата(AlexandrY @ Mar 26 2018, 17:57) *
Похоже у вас в структуре tskTaskControlBlock переменная uxPriority объявлена как volatile.
Нужно просто чуть чуть подправить макрос portRESET_READY_PRIORITY

У меня в проекте FreeRTOS V8.2.1. Глянул на этот макрос - оба аргумента объявлены как volatile.
Код
PRIVILEGED_DATA static volatile UBaseType_t uxTopReadyPriority         = tskIDLE_PRIORITY;
PRIVILEGED_DATA TCB_t * volatile pxCurrentTCB = NULL;


ребилд олл.... выхлоп компилятора

Код
tasks.c  
iccarm.exe D:\Work\ip\terem5\github\terem5\freertos\tasks.c -D USE_STDPERIPH_DRIVER -D STM32F401xx -D USE_USB_OTG_FS -o D:\Work\ip\terem5\github\terem5\Debug\Obj --no_cse --no_unroll --no_inline --no_code_motion  
--no_tbaa --no_clustering --no_scheduling --debug --endian=little --cpu=Cortex-M4 -e --char_is_signed --fpu=VFPv4_sp --dlib_config D:\Program Files (x86)\IAR Systems\Embedded Workbench 7.4\arm\INC\c\DLib_Config_Normal.h -I D:\
Work\ip\terem5\github\terem5\freertos\ -I D:\Work\ip\terem5\github\terem5\ -I D:\Work\ip\terem5\github\terem5\Libraries\STM32F4xx_StdPeriph_Driver\inc\ -I D:\Work\ip\terem5\github\terem5\Libraries\Usb\inc\ -I D:\Work\ip\terem5\
github\terem5\Libraries\Usb\ -I D:\Work\ip\terem5\github\terem5\Libraries\CMSIS\Device\ST\STM32F4xx\Include\ -I D:\Program Files (x86)\IAR Systems\Embedded Workbench 7.4\arm\CMSIS\Include\ -I D:\Work\ip\terem5\github\
terem5\Libraries\STM32F4xx_StdPeriph_Driver\inc\ -I D:\Work\ip\terem5\teremSrc\Libraries\usb2\ -On
  
6 130 bytes of CODE  memory
    28 bytes of CONST memory
   252 bytes of DATA  memory

Errors: none
[b]Warnings: none[/b]


Специально какие либо настройки компилятора не делал. Может IDE какие нить особые ключи компилятору передала?

Axel
Цитата(juvf @ Mar 27 2018, 05:59) *
Специально какие либо настройки компилятора не делал. Может IDE какие нить особые ключи компилятору передала?


Не поэтому. Я C++ пользую, а он к этим моментам относится более трепетно...
juvf
Цитата(Axel @ Mar 27 2018, 09:14) *
Не поэтому. Я C++ пользую, а он к этим моментам относится более трепетно...
С этого тему начинать нужно было.
Я тоже с++ использую везде и всюду. Но FreeRTOS написана на Си. У меня проект(ы) собирает файлы *.с компилятором си, *.срр компилятором с++.
Если указать, чтобы FreeRTOS собрать компилятором с++, не тошто куча ворнингов, куча ошибок в коде ртос, проект вообще не собирается.

ФрииРТОС написана на пуре си, собирайте её невдумчего сишными компиляторами. Зачем туда вообще g++, если код написан и отлажен на си? Или же вдумчего перелопачевайте фриртос на с++.
Axel
Цитата(juvf @ Mar 27 2018, 07:25) *
... проект вообще не собирается.

ФрииРТОС написана на пуре си, собирайте её невдумчего сишными компиляторами. Зачем туда вообще g++, если код написан и отлажен на си? Или же вдумчего перелопачевайте фриртос на с++.

Вдумчивость - она по способнастям, так что я уж как могу... Проект у меня собирается, и даже начинает шевелиться в железе. А на счет что С не замечает ворнингов... "Вот ты суслика не видишь, а он есть! ©". Но Вашему совету вероятно последую. Спасибо.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.