[DreamTwister 0]

FreeRTOS 4.4.0

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

 

Задачи потребляют очень много стека. Хочется узнать на что они его расходуют.

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

Можно ли с этим что-то сделать?

[FormatCft 0]

FreeRTOS 4.4.0

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

 

Задачи потребляют очень много стека. Хочется узнать на что они его расходуют.

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

Можно ли с этим что-то сделать?

 

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

 

 

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

 

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

 

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

[zltigo 0]

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

 

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

[pochta 0]

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

 

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

[DreamTwister 0]

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

 

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

 

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

[pochta 0]

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

 

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

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

[HARMHARM 0]

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

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

[DreamTwister 0]

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

 

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

 

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

[pochta 0]

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

 

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

[vitko 0]

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

 

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

 

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

Изменено 26 января, 2010 пользователем vitko

[zltigo 0]

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

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

[Aurochs 0]

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

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

[zltigo 0]

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

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

[vitko 0]

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

 

В мелких процессорах (типа AVR) может и понадобиться.

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

[zltigo 0]

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

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