Как посчитать размеры стеков для задачи? В примерах для 128 меги ставится типовой размер стека в 240 байт и из них 64 под какой-то hard стек. Однако при таком раскладе или памяти не напасёшься под задачи или всё придётся делать на таймерах вызываемых из одной задачи. До скольки можно безопасно сокращать размеры стеков?

И ещё, нужно читать данные по uart. Если один тик равен 10 мс и скорость порта 19200, то получается что размер буфера нужен не меньше 200 байт и плюс второй такой же для заполнения во время обработки первого буфера. Получается многовато. Как лучше всего обрабатывать приём по uart при условии отсутствия прямого доступа к памяти и не очень больших резервах озу?

сменить процессор

Или ОС.

Или изучить сервисы и архитектуру ОС.

А именно:
1. В uC/OS-II перепланирование осуществляется при выходе из обработчика прерывания, поэтому причем тут тики системного таймера? Задача обычно ждет сообщения в очереди от процедуры обработки прерывания UART. Тогда длина очереди будет определяться максимальным временем блокировки данной задачи задачами с более высоким уровнем приоритета и/или наибольшим временем запрещения прерываний. А это можете сказать только Вы, и это как раз решается в процессе определения приоритетов задач.
2. Подумать, нужен ли такой размер стека. Документация на данную ОС, как и ее исходный код и большинство портов на редкость прозрачны.

3. Ну и, конечно, Вам в помощь OSTaskCreateExt и OSTaskStkChk.

О, спасибо! Действительно, время тика не при чём. Достаточно повысить приоритет.


К сожалению в данном вопросе не нашёл ответа ни в документации, ни в коде. В доке описаны загружаемые в стек параметры - можно ли приплюсовать туда локальные переменные задачи и адреса возврата из функций и считать что это будет минимальный размер стека или использование стека не настолько детерминировано? Как используется память под стеки, выделяемая линкером - может её можно прибить, если стеки поддерживаются осью? Описание в доке hard стека вообще ни о чём не говорит - что ещё за hard? Вижу что туда грузят PC, а что ещё?

Я не знаком с портом на AtMega. Что Вы имеете в виду, говоря об описанных в доке загружаемых в стек параметрах? Почти наверняка в нем сохранение регистров идет в стек текущей задачи. Плюс нужно место для сохранения контекста задачи при переключении задач. Ну а далее фреймы стека вызываемых функций в данной задаче.

Если Вы почти сразу уходите из main() в OSStart() и можете рассчитать, сколько стека потребуется в main, то так и урезайте то, что выделено в настройках линкера.

Да я об этих параметрах и говорил. Попробую урезать размер стека с выводом информации об использовании стека в терминал. Под вопросом в итоге остаётся только таинственный аппаратный стек.

Например, компилятор IAR для AtMega использует для сохранения данных отдельный стек, на который указывает регистром Y. CALL/RET/PUSH/... оперируют стеком, а который указывает SP. Возможно, это и есть "аппаратный стек". Еще раз, надо смотреть порт и настройки проекта.

Кстати, еще вариант - посмотреть что-то более легкое, например, scmRTOS, про которую на этом форуме много написано. Мне кажется, это более адекватный выбор для AtMega. Там, кстати, есть возможность выделить отдельный стек для обработчиков прерываний.

Углубился в код оси и в комментариях потвердилось, что аппаратный стек это SP. Соответственно достаточно выставить его размер исходя из количества вложенных функций у задачи.
scmRTOS кажется написана на C++, а я его терпеть не могу. Да и компилятор не каждый выдюжит.