[andrewlekar 0]

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

 

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

[bek 0]

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

[dxp 34]

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

Или ОС. :)

[SergeyF 0]

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

 

А именно:

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

2. Подумать, нужен ли такой размер стека. Документация на данную ОС, как и ее исходный код и большинство портов на редкость прозрачны.

Изменено 9 января, 2010 пользователем Sergey'F

[SergeyF 0]

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

[andrewlekar 0]

В uC/OS-II перепланирование осуществляется при выходе из обработчика прерывания

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

 

Документация на данную ОС, как и ее исходный код и большинство портов на редкость прозрачны.

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

[SergeyF 0]

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

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

 

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

Изменено 9 января, 2010 пользователем Sergey'F

[andrewlekar 0]

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

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

[SergeyF 0]

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

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

 

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

[andrewlekar 0]

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

 

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

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

scmRTOS кажется написана на C++, а я его терпеть не могу. Да и компилятор не каждый выдюжит.