FreeRTOS?? Разобраться с демо проектом??

[-Alan-]

Нашел 2 параметра для контроля за стеком
uxTaskGetStackHighWaterMark
https://www.freertos.org/uxTaskGetSt...WaterMark.html
vApplicationStackOverflowHook
https://www.freertos.org/Stacks-and-...-checking.html

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

Только сегодня ответил на такой же вопрос про наблюдение за использованием стэка на другом форуме

У себя в проекте использую первую функцию для точного измерения требуемой глубины стэка. Получается достаточно удобно - можно запросить данные в процессе реальной работы. Функция возвращает не текущую позицию, а именно самую низкую границу, до куда добирался указатель стэка в процессе работы конкретного потока.

Вторая - vApplicationStackOverflowHook() - это скорее пост-фактум, что всё стало настолько плохо, что стэк был продавлен.

Я бы просто выставил какое-то бОльшее значение, а затем - эпизодически считывал сколько реально было занято.
Функция оказалась действительно удобной.

[Easyrider83]

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

[CERGEI1982]

кто пример напишет

[Easyrider83]

Я оказался не прав. Мы фактически не можем контролировать объем стека, используемый конкретной задачей. Есть TaskList команда, которая пишет форматированный вывод в буфер и указывает в том числе и размер стека, но это лишь тот размер, который мы сами указали при создании задачи. Сколько в реальности использовано мы не узнаем никогда. Единственный вариант - это ловить vApplicationStackOverflowHook и по нему находить задачу, которая его вызвала, чтобы добавить ей памяти в будущей. Не самый надежный способ, но честно говоря, у меня никаких проблем с этим нету. Все идеально работает даже с использованием stdio.

[NewWriter]

Можем, можем, вы были правы ) Первая переменная в блоке TCB - ока как раз и указывает на адрес вершины стека. А 13-я переменная в TCB указывает на верхнюю границу стека. Разница между ними - есть оставшееся свободное место.
Первая переменная в TCB - её адрес хранится в переменной дескриптора очереди, поэтому получить доступ к интересующим ячейкам очень просто.

[Easyrider83]

NewWriter, можно подробнее? Лучше с примером.

[NewWriter]

Я к сожалению щас со смартфона пишу. Но неделю назад мы через электронку общались с CERGEI1982, я ему отправлял там скрины со стеком задачи и блоком TCB и разъяснениями. Попросите Сергея, пусть выложит сюда их и текст пояснений. Сергей, там в письме от 10 декабря, где про процесс создания задачи.
Ну а уж как получить значение переменной по адресу, это уж Easyrider83 и сам умеет делать ))))
Кстати, Easyrider83, загляните в файл tasks.c и разгребите тип структурыtypedef struct tskTaskControlBlock узнаете кое-что интересоне

[CERGEI1982]

Ваше сообщение

Местоположение в ОЗУ конкретной задачи или очереди можно узнать по переменной дескриптора задачи, очереди, семафора. Значение этой переменной - и есть адрес TCB задачи или очереди. Причем, применительно к задаче, значение переменной по этому адресу (на который указывает переменная-дескриптор) - и есть адрес вершины стека, то есть ближайший свободный адрес, в который может быть что-то записано.

Как вообще выглядит процесс создания задачи? Рассмотрим на примере создания первой задачи в коде.
Вначале аллокатор ядра RTOS ищет ближайший свободный адрес в куче - так получается первый адрес - 0x20003AC8, равный концу стека задачи. Далее, запрашивает из кучи количество байт, равное указанному в параметре при создании размеру, умноженному на 4 - так получается начало стека задачи. На картинке стек задачи, равный 50*4=200 байт, выделен желтым фоном.
Затем, если в куче хватило места (т.е. вернулось не NULL), запрашивается еще некоторое количество байт для TCB. В случае успеха - появляется блок TCB (на картинке обведены красным, начиная от надписи *pxNewTCB). Адрес начала TCB - 0x20003B90, возвращается в переменную дескриптора задачи. Так что именно так можно и определить начало блока TCB.
Далее, в блок TCB записывается имя задачи (на скрине выделено серым фоном, а правее в ANSI-кодировке видно Green LED ). Затем в TCB записываются другие параметры, в частности, приоритет задачи - число 1 правее имени. Ну там еще кое-чего пишется, и указатель вершины стека еще смещается на величину выравнивания.
А затем в стеке задачи производится выделение места под все регистры ядра МК (на скрине выделено синим фоном), из-за чего указатель вершины стека смещается еще на 16 четырехбайтных слов выше. И теперь указатель вершины стека равен 0х20003B44, именно это число мы видим в начале TCB, а как мы помним, на начало TCB указывает дескриптор задачи. Значит, сразу после создания задачи, конкретно для этой задачи мы имеем 32*4=128 байта для нужд функций задачи.

Таким образом, прочитав значение из адреса, на который указывает дескриптор, и сравнив его с концом стека (значение адреса конца стека хранится в TCB, 13-ое слово от начала - выделено ярко-желтым фоном), можно определить, сколько места еще есть в стеке задачи в конкретный момент.

[Easyrider83]

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

[CERGEI1982]

А вот трассировка там что то может? не до шел просто до изучения

Также пару картинок из кейла по размещению задач.

Да и еще встретился при изучении очередей и симуляции в кейле : точки останова стирайте и снова ставите в дебагере или кейл застопориться на одном месте.