вообщем, хочу реализовать быстрый контроль памяти стека для RTOS.
сейчас сделано тупо - перед переключением контекста проверяется самый первый int области стека ( соответственно последний если исходить что в cm3 голова в хвосте )
в функции printf стек используется нелинейно и у меня практически получилось, что проскочило мое контрольное слово и потер уже за стеком.
напрашивается контроль к примеру 16 слов. Проверять ручками это не камильфо - долго, интересуют именно быстрые варианты

какие есть быстрые ?

Я пока надумал:
1. экслюзивный доступ
2. мои предположения что авось есть спец регистр, который можно настроить за наблюдение за другим регистром и запоминает его минимальное значение. В данном случае натравить на PSP
3. Какие еще варианты ?

вот пример как у меня произошел выход за пределы
Нажмите для просмотра прикрепленного файла

upd: "экслюзивный доступ" увы но медленный. Я думал что можно указать регион мониторинга. Но нет, там для каждого WORD выставляется общий признак. То есть перед передачей управления задаче, нужно сначала пометить первых N-слов, и потом перед возвратом проверить экслюзивный доступ (да еще вопрос как поведет себя обычная запись по этим регистрам). Конечно есть небольшой плюс - можно отказатся от magic word.

upd2:
еще порылся в отладчике, и поразило, какой жадный этот printf в режиме Large Without Multibytes, сразу 132 байта под себя требует !


Еще для справки: tiny = 0x10, small without multibytes = 0x4C, full Without Multibytes = 0x84

А статический анализатор стека применить не судьба?

Что вы называете "экслюзивным доступом"?



MPU - Memory protection unit? Или не подходит?

а какой вы применяете ? Я не совсем понимаю как они понимают что это preemptiveРТОС а не однозадачная ОС



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


оказывается, есть такое. Завтра гляну, а то сегодня уже башка не варит

Это что-то мало у вас... У меня в каком-то режиме до полукилобайта занимал.


Как она может быть побайтовой (или вообще привязанной к адресам) если там нигде адрес не указывается?
Если логически подумать, то там скорее всего определяется факт срабатывания прерывания внутри секции эксклюзивного доступа
(по LDREX взводится флаг в CPU, который сбрасывается если возникло прерывание, а потом он проверяется STREX).

Когда у меня была аналогичная проблема с расходованием стека в RTOS sprintf-ом, я просто сделал переключение стека, на стек для sprintf (с семафором ессно).

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

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

Но скажу, что хорошие RTOS не используют библиотечный printf как достаточно опасный для многозадачности.
Например RTOS MQX заменяет printf своей надежной версией и вообще большинство функций из <stdio.h> заменяет.
Мало того, MQX проверяет занятость стека в каждом сервисе RTOS как для задач так и для прерываний.
Для еще большей надежности MQX имеет функции проверки целостности в реальном времени всех объектов RTOS.
Рекомендуется это делать в отдельной фоновой задаче.
Ну и естественно в MQX есть защита ядра от повреждения задачами с помощью MPU.