FreeRTOS 4.4.0
Микроконтроллер lpc2142

Задачи потребляют очень много стека. Хочется узнать на что они его расходуют.
Просто очень странно, что задача, которая управляет зажиганием 2-х светодиодов, требует 220 байт под стек!
Можно ли с этим что-то сделать?

каким сделали такой и есть. 


Основная причина множество локальных данных. Большие массивы структуры.

У меня все потоки используют по 120байт, какими бы тяжелыми они не были.

Главное пользоваться почаще malloc(...), free(...) 

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

во FreeRTOS стек ВСЕХ задач используют обработчики прерываний

может в этом косяк?

Что-то тут не так...

Закрыл комментариями все содержимое задачи, оставил только for(;;). Потребление не изменилось. Может проблема в том, что для "измерения" потребления стека я использую vTaskList?

Может имеет смысл заменить heap_1.c на что-то более подходящее?

Да как вы не понимаете не задача ваш стек ест а обработчик прерываний

Вообще-то у ARM под прерывания отдельный стек... Да и сверхоперативных регистров тоже отдельный набор...

Вот я тоже не понимаю, если прерывание потребляет стек задачи, то получается, что если я проинициализирую еще парочку прерываний, то у меня по килобайту стека на каждую задачу уходить будет?

Вот и охота разобраться, как и на что расходуется стек во FreeRTOS.

А извините не знал. Каюсь у меня AVR

Объясните пожалуйста.

Правильно ли я понимаю, что в freeRTOS прерывания используют стек текущей задачи, и соответственно стеки задач должны иметь запас на хранение контекста(-ов) прерываний ?

В самой freeRTOS нету средств для, скажем, переключения всех прерываний на отдельный стек, как в scmRTOS ? Ддя небольших процессоров было бы нелишне.

Полностью зависит от собственно контроллера и того, как написан конкретный порт.

А зачем? Либо м/к поддерживает такую возможность на уровне архитектуры и тогда RTOS это принимает как данность. Либо не поддерживает и тогда IMHO лучше облегчать прерывания и обработку, активно кушающую стек, оформлять как отдельную задачу, чем делать программные манипуляции на грани фола связанные с переключением стека.

Ну а фол-то где? Несколько команд изменяющих и восстанавливающих указатель стека - добавляются по месту легко и непренужденно. Если, оно конечно, это надо.

В мелких процессорах (типа AVR) может и понадобиться.
А если еще и переключение контекста делать в каком-будь специально выделенном программом прерывании, а в прерывании от сист.таймера его только инициировать, то и вообще не надо по каждому тику сохранять/восстанавливать контекст. Но это уже будет совсем как в scmRTOS :-)

Поскольку в ней как класс отсутствуют задачи одинакового приоритета, то такое упрощение имеет эффект. В системах поддерживающих задачи одинакового приоритета они должны будут переключаться по КАЖДОМУ тику.

Какой фол? Было сказано "на грани фола" - согласитесь, что это не одно и то же.

Не спорю.

Вот именно. И, скорее всего, в 99 случаях из 100 будет необоснованно.

Хочу знать что за фол о нахождении на грани которого Вы говорите. 

 

На грани фола в моем понимании означает, что сильно увеличивается потенциальная опасность возникновения ошибок, приводящих к труднодиагностируемому краху системы.
Если нужен пример, пожалуйста - переключение стека в фиксированную область во вложенных прерываниях.
Хотя для отчаянных ребят, программирующих в стиле "а-ля улыбнитесь, каскадеры" это, конечно, не довод . И, честно говоря, нет ни малейшего желания вступать в дебаты по этому поводу. Хотел только предупредить, а дальше уж, как говорится, каждый выбирает для себя...

Счётчик вложености прерываний нужен хотя бы для того, чтобы не заниматься зря перепланировкой при выходе из вложенного прерывания, делать это только при выходе из всех прерываний. А при его наличии не переключать стек во вложенных прерываниях труда не составит.

Ну когда нет аргументов, а только футбольно-киношные отсылки, то это следует признать совершенно разумным желанием.

В общем смысле любая программа либо работает, либо нет. Занимается она "сложным переключением контекста" или вычислением 2+2 - совершенно без разницы с точки зрения "надежности" работы устройства. Другое дело - нагрузка на голову программиста, но это вопрос профессионализма и навыка.

начал осваивать rtos

правильно ли я понимаю что при создании задачи размер стека надо указывать в зависимости от того, сколько вложенных функций будет в самой задаче?
то есть если в задаче глубина вложенности функций будет например 10, то и размер стека надо указывать >176? то есть такая задача отожрет >704 байта оперативы. что в общем то не кашерно при наличии 8к оперативы.

или что то я не так делаю?

Про локальные переменные тоже надо не забывать.




Почему именно 176?
Каждый уровень потребляет 17,6 байта?



Контроллер слабоват. Нужен более мощный.

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

ну не 17,6 байта. Я так понял что указываемое значение - это не число байт, а число 32разрядных слов.

а 176 - экспериментальным путем получено.
указываю меньше 32 - вообще задача не запускается
а потом добавляю по 16 на каждый уровень вложенности функций, иначе вылетает в vApplicationStackOverflowHook

А какая архитектура?




ИМХО сомнительный подход.
Могу ошибаться, но мне кажется, что уровень вложенности не равен количеству вызовов функций:



Для этого кода уровень вложенности не 2, столько сколько компилятор сделает.

согласен. тогда получается лишняя заморочка по расчету того сколько же стека нужно задаче....
а камень - stm32f100rb

C чем именно согласны?


Лишняя?
Стек надо как-то учитывать....
Если стека не хватает работать не будет. А говорите - лишняя.


Понятно