Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Настройки FreeRTOS
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Jenya7
Создаю таски
Код
FRTOS1_xTaskCreate((TaskFunction_t)operation_task, (signed char*) "tx", 1024, NULL, 1, NULL);  
FRTOS1_xTaskCreate((TaskFunction_t)log_managment_task, (signed char*) "rx", 512, NULL, 1, NULL);
Все работает.Но если увеличиваю размер стэка
Код
FRTOS1_xTaskCreate((TaskFunction_t)operation_task, (signed char*) "tx", 1024, NULL, 1, NULL);  
FRTOS1_xTaskCreate((TaskFunction_t)log_managment_task, (signed char*) "rx", 1024, NULL, 1, NULL);
Заходит в исключение FRTOS1_vApplicationMallocFailedHook.
А где увеличить стэк?
В FreeRTOSConfig.h есть #define configMINIMAL_STACK_SIZE (200) /* stack size in addressable stack units */ - это для каждого таска или общий размер?
SyncLair
Цитата(Jenya7 @ Jul 25 2018, 13:28) *
В FreeRTOSConfig.h есть #define configMINIMAL_STACK_SIZE (200) /* stack size in addressable stack units */ - это для каждого таска или общий размер?


HeapSize
juvf
Цитата(Jenya7 @ Jul 25 2018, 14:28) *
В FreeRTOSConfig.h есть #define configMINIMAL_STACK_SIZE (200) /* stack size in addressable stack units */ - это для каждого таска или общий размер?
так мануалов полно в инете....

configMINIMAL_STACK_SIZE - это размер стека ТОЛЬКО для IDLE таска.
общий размер, который ртос отьест для всех задач, семафоров, очередей и т.п, задается параметром configTOTAL_HEAP_SIZE
Jenya7
тогда я ничего не понимаю - у меня - #define configTOTAL_HEAP_SIZE (24576) /* size of heap in bytes */
juvf
а что дает xPortGetFreeHeapSize() до xTaskCreate()?
Arlleex
Цитата(Jenya7 @ Jul 25 2018, 15:18) *
тогда я ничего не понимаю - у меня - #define configTOTAL_HEAP_SIZE (24576) /* size of heap in bytes */

Ну дык может это говорит о том, что имеет смысл увеличивать? Создали семафор - заняли heap, создали задачу - заняли heap и т.д.
Ваши 2 задачи уже 8кБ памяти будут отжирать сразу.
Jenya7
Цитата(juvf @ Jul 25 2018, 17:33) *
а что дает xPortGetFreeHeapSize() до xTaskCreate()?


меня такого не - xPortGetFreeHeapSize()падает тут
Код
       StackType_t *pxStack;

       /* Allocate space for the stack used by the task being created. */
       pxStack = ( StackType_t * ) pvPortMalloc( ( ( ( size_t ) usStackDepth ) * sizeof( StackType_t ) ) );



Цитата(Arlleex @ Jul 25 2018, 17:37) *
Ну дык может это говорит о том, что имеет смысл увеличивать? Создали семафор - заняли heap, создали задачу - заняли heap и т.д.
Ваши 2 задачи уже 8кБ памяти будут отжирать сразу.


увеличил до 32кило - он не заходит в FRTOS1_vApplicationMallocFailedHook но где то бродит по функциям FreeRTOS. Иногда попадает в функции тасков но программа не работает.

ой. заработало. спасибо.
juvf
какой хип? heap_1.c, heap_2.c...or heap_4.c?
Jenya7
Цитата(juvf @ Jul 25 2018, 17:57) *
какой хип? heap_1.c, heap_2.c...or heap_4.c?


#define configUSE_HEAP_SCHEME 4 /* either 1 (only alloc), 2 (alloc/free), 3 (malloc), 4 (coalesc blocks), 5 (multiple blocks), 6 (newlib) */

а какой лучше?
x893
Отладчиком религия не позволяет пользоваться ?
Jenya7
Цитата(x893 @ Jul 25 2018, 18:04) *
Отладчиком религия не позволяет пользоваться ?


отладчик плохо работает с фриартосом. нужно ставить плагин.
Grigorij
Чтобы бездумно не увеличивать размер стека под задачи и, соответственно, размер кучи, посмотрите столько реально каждая задача у вас сейчас потребляет. На хабре есть очень интересная статья по этому поводу - ссылка на статью
juvf
какая-то кастомная FreeRTOS. Добавлена какая-то configUSE_HEAP_SCHEME , нет xPortGetFreeHeapSize()....

Цитата
а какой лучше?
лучше та, которая вам нужна. Я обычно использую heap_1.c, мне не нужно динамически задачи создавать и удалять. не будет фрагментации. почитайте про схемы, выберете себе подходящую.

Вот тут про память, кучи, стеки разжованно. Если после запуска планировщика не создаете/удаляете задачи/симафоры/очереди, то heap_1.
Jenya7
Цитата(Grigorij @ Jul 25 2018, 18:06) *
Чтобы бездумно не увеличивать размер стека под задачи и, соответственно, размер кучи, посмотрите столько реально каждая задача у вас сейчас потребляет. На хабре есть очень интересная статья по этому поводу - ссылка на статью


спасибо. интересная статья.

Цитата(juvf @ Jul 25 2018, 18:14) *
какая-то кастомная FreeRTOS. Добавлена какая-то configUSE_HEAP_SCHEME , нет xPortGetFreeHeapSize()....

лучше та, которая вам нужна. Я обычно использую heap_1.c, мне не нужно динамически задачи создавать и удалять. не будет фрагментации. почитайте про схемы, выберете себе подходящую.

Вот тут про память, кучи, стеки разжованно. Если после запуска планировщика не создаете/удаляете задачи/симафоры/очереди, то heap_1.


спасибо. у меня были сомнения - не люблю динамическую алокацию. попробую heap_1.
x893
Цитата(Jenya7 @ Jul 25 2018, 15:06) *
отладчик плохо работает с фриартосом. нужно ставить плагин.

Даже не знаю, что и сказать на это замечание.

Наверное так - отладчику наплевать на FreeRTOS.
Как и всё остальное. Что скажешь, то и делает.
Arlleex
Цитата(x893 @ Jul 25 2018, 16:54) *
Даже не знаю, что и сказать на это замечание.

Наверное так - отладчику наплевать на FreeRTOS.
Как и всё остальное. Что скажешь, то и делает.

Полностью согласен.
Ну если пользоваться какими-нибудь халокубами, то, наверное, какой-то плагин и нужен... В Keil же есть какой-то Software Package при старте проекта. Похоже на что-то подобное.
juvf
В чем ртос поставяется? в исходниках? тогда для дебага не нужны ни какие плуги.

Цитата
Ну если пользоваться какими-нибудь халокубами то, наверное, какой-то плагин и нужен..
в кубе чистая фриртос, без FRTOS1. И куб добавляет в проект фриртос в виде исходников (как и остальные компаненты).
Jenya7
Цитата(juvf @ Jul 25 2018, 19:50) *
В чем ртос поставяется? в исходниках? тогда для дебага не нужны ни какие плуги.

в кубе чистая фриртос, без FRTOS1. И куб добавляет в проект фриртос в виде исходников (как и остальные компаненты).


у меня проект создан с ProcessorExpert (дерьмо редкостное). у него своя обертка под FreeRTOS.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.