Easyelectronics.ru

.

.

Насколько я понимаю, стек под задачи распределяется из какого-то общего буфера. Если так, то можно попробовать отсортировать указатели на стек, взять между ними разницу и выровнять ее на какую-то границу (зависит от гранулярности с которой выделяется место под стек). Впрочем, это не гарантирует правильности полученного результата. Например, если гранулярность 1К, задаче выделено 2К и она уже использовала больше 1К, то при вычислении получится ошибка (использованный стек зачтется как пустой следующей задаче). А так самое простое - слегка допилить FreeRTOS и сохранять начальный размер стека в структуре задачи.

.

Это не то ?
http://www.freertos.org/Stacks-and-stac ... cking.html
http://www.freertos.org/uxTaskGetStackH ... rMark.html
Но размер стека и freertos не очень связаны.
Только при переключении задачи rtos нужно место в стеке.
А потом как вы его будете использовать - дело ваше личное.

.

А вы никогда не интересовались структурой стека задач в частности, и работой аллокатора heap1, heap2 в общности? Откройте браузер памяти, посмотрите. В начале каждого стека задачи идет блок TCB - Task Control Block. Он содержит инфу, определенную в качестве структуры при создании задачи (просмотрите исходники этой ф-ции). Размер TCB постоянен. 72 бйата на ARM. Аллокатор модели heаp1 работает последовательно, выделяя память от начала кучи (heap) и до ее конца, без промежутков. ...кароче, просто откройте браузер памяти и посмотрите.

.

Попробуйте "вклиниться" в место, где создается стек, но еще не используется, и забейте весь массив стека значением, которое хорошо видно в дебагере. Обычно это либо 0xAA либо 0x55. Потом, погоняйте программку вашу и остановите ее в дебагере. Зная значение адреса начала стека, можно очень даже и точно определить, до куда стек у вас заполняется, найдя эти самые заветные 0xAA либо 0x55.


Очередной велосипед?
Приглядитесь к Segger System Viewer. Он показывает, почти в реальном времени, какая задача, сколько выполнялась, сколько стояла, какие прерывания в этот момент вызывались, какие прерывались. Если свой код немного доинструментировать, то можно и ваши собственные ивенты глядеть.
Это все как для безОСовой системы, так и с FreeRTOS (там надо чуток ее доработать, подробно об этом в доке к проге описано), так и с SeggerOS.

Очень рекомендую.
PS. Забыл добавить, что оно, к сожалению, толко с J-Link работает. Но о том, как переделать ST-Link в нормальный J-Link, тут уже пол форума исписано.

.

Оличие System Viewer от вашего "по команде "делай раз" " в том, что у вас на это тратится драгоценное время процессора, а у System Viewer затраты минимальные, так как используется SWD интерфейс и RTT механизм, который очень даже незаметно работает, не тратя при этом никакой переферии (ну кроме SWD пинов).

Так и в чем проблема то? Знаете, где стек начинается, знаете, где заканчивается. Знаете, чем он изначально заполнен. Так и "по команде" с конца стека идете пока в нем вдруг не появятся какие то левые значения, отличные от того маркера (0xAA или 0x55), вот вам и место, до куда доходит использование. Вычитываем адрес конца от найденного адреса несоответствия, и получаем процент.

.

Я не совсем понимаю вашу проблему, если честно. При создании задачи ваш стек вам и так известен. Это параметр в функцию создания задачи. Вы же сами его туда и записали, при программировании вызова создания задачи.
Этот параметр - это размер стека, который надо умножить на 4, чтоб в байтах получить его.

А процесс использования стека именно конкретной задачи кроме как сканированием, никак больше не узнать. Ну или постоянно считывать регистр указателя стека.
Потому как при каждом вызове любой функции, указатель стека перебегает ближе к концу его, и при выходе из стека - обратно. И чем глубже идет вызов функций (при рекурсивных, особенно), тем дальше идет указатель. Вплоть до выхода за пределы, если вы указали маленький размер стека.

.

Не-не, господа, не путайте АРМ-стек функций и стек РТОС. У них разное назначение и разные точки отсчета. Стек РТОС не управляется аппаратно, в отличие от стека ядра. Стеком РТОС управляет менеджер памяти (одна из моделей heap1, heap2 и тд), и "растет" вверх от начала кучи. Я на форуме ранее несколько раз выкладывалскрины стеков, там было наглядно видно.
Во-вторых, все переменные в функции задачи, помеченные как static (либо глобальные), будут размещены не в стеке задачи, а в области статичных переменных, находящейся вне кучи (heap).
Под браузером памяти я имел ввиду другой, который в ПО отладки. И на CoIDE далеко не уедешь...

По поводу вычисления загрузки процессора - она вычисляется как процент времени нахождения в задаче Idle (бездействие). И может быть правильно вычислена только в том случае, если работой проги предусматривается остановка всех задач и нахождение в Idle.
Процент использования памяти из кучи вычисляется как наибольший адрес дескриптора задачи или очереди, семафора, назначаемый при создании, плюс выделяемый размер стека.

У меня свой менеджер памяти, из которого FreeRTOS посредством вызова malloc запрашивает для задач области памяти для стека. и в зависимости от того, в какой момент создается задача, этот стек может лежать где угодно в области, которой заправляет мой менеджер памяти.


Ozone рекомендую. От того же зеггера.


У меня менеджер памяти так же еще и обратно от проги память принимает, если прога вызвала free. И получается, что в начале кучи могут быть так же свободные куски памяти. И в конце кучи могут быть и занятые куски памяти.

Для определения свободного места у меня отдельная переменная есть, в менеджере памяти. Это конечно не шибко достоверный показатель, так как если вдруг прога "запросит" кусок памяти на всю свободную кучу, она его НЕ получит, так как не будет одного большого последовательного свободного куска, но много мелких (дефрагментация кучи, получается).

Возможно это платформенно-зависимо, но на rx600, к примеру, стеки задач "подсовываются" МК при переключении задач и ему без разницы по какому участку памяти "ходить" - по стеку супервайзора, по пользовательскому или по динамически выделенному стеку задачи. Иными словами, в конкретном случае, - нахожу больше совпадений чем различий. И, кстати, параметр ешё нужно для платформы определять portSTACK_GROWTH - либо отрицательный либо положительный, в зависимости от того как МК работает со стеком - "вверх" или "вниз". В зависимости от этого параметра последовательность выделения памяти для стека задачи и её TCB различается - чтобы стек не "переехал" свой собственный TCB и "патологоанатому" легче было постмортем аутопсиями заниматься в случае чего.

Вот тут планировщику должно быть обидно, как мне кажется. ;-) И portSTACK_GROWTH так просто из песни не выкинуть.

Любят наши люди на пустом месте дискуссию разводить.

Этак получается большая фрагментация памяти, и это может вызывать утечку памяти. То есть, однажды можно получить отказ в выделении памяти, несмотря на то, что свободного места в сумме предостаточно.


Вы не путайте платформы. Мы тут обсуждаем ARM-Cortex, конкретно на реализации STM.

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

.

Возвращаясь к теме. Возможно, автора заинтересует простая функция для определения оставшегося свободного места в куче. xPortGetFreeHeapSize() - она возвращает значение свободного места в байтах. Её функционал прописан в файле модели памяти. А так же для модели heap1 есть глобальная переменная xNextFreeByte, содержащая значение занятой памяти в байтах.

.

Да, всё в порядке, это - начальное значение. Используется модель heap2. В процессе работы переменная xFreeBytesRemaining изменяется в меньшую сторону.