Расход стека Опции

[DreamTwister]

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

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

[FormatCft]

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

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

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


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

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

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

[zltigo]

задача, которая управляет зажиганием 2-х светодиодов, требует 220 байт под стек!

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

[ddiimmaa]

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

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

[DreamTwister]

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

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

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

[ddiimmaa]

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

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

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

[HARMHARM]

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

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

[DreamTwister]

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

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

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

[ddiimmaa]

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

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

[vitko]

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

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

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

Сообщение отредактировал vitko - Jan 26 2010, 14:41

[zltigo]

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

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

[Aurochs]

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

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

[zltigo]

чем делать программные манипуляции на грани фола связанные с переключением стека.

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

[vitko]

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

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

[zltigo]

Но это уже будет совсем как в scmRTOS :-)

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

[Aurochs]

Ну а фол-то где?

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

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

Не спорю.

Если, оно конечно, это надо.

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

[zltigo]

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

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

 

[Aurochs]

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

[ReAl]

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

[zltigo]

И, честно говоря, нет ни малейшего желания вступать в дебаты....

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

[sergeeff]

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

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

[rexton]

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

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

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

[_Артём_]

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

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

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

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

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

>704 байта оперативы. что в общем то не кашерно при наличии 8к оперативы.

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

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

[kan35]

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

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

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

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

[rexton]

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

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

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

[_Артём_]

а число 32разрядных слов.

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

а потом добавляю по 16 на каждый уровень вложенности функций, иначе вылетает в vApplicationStackOverflowHook

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

Код

void f2()
{
}
void f1()
{
    f2();
}

void main()
{
   f1()
}

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

[rexton]

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

[_Артём_]

согласен.

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

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

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

а камень - stm32f100rb

Понятно