Первые впечатления - Ртось приятная. Отличная документация, в компилированном виде мало места занимает. С шаблонами, автор, конечно, перемудрил местами...

Все понятно, кроме одного но. У атмеги8535 512 байт ОЗУ. Память закончилась уже на 4 процессе с размером стека 100. Собственно вопрос, имеет ли смысл использовать дальше RTOS, если процессов предполагается 8-9 - опрос разнотипных датчиков. Можно, теоретически, попробовать уменьшить количество процессов - но тогда весь смысл ртоси пойдет на нет.

Итак, если используем:

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

Если не используем:

1. Что из легких кооперативных ртосей посоветуете? Предпочтителен ++
2. В принципе, уже готова заготовка кооперативной ртоси - системный таймер тиков и шедулер процессов. Что еще я упустил?

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

Элементы межпроцессного обмена и взаимодействия (очереди, сообщения, семафоры, мутексы)

Возможно у меня пока еще слишком много десктопного подхода к программированию, тем не менее, на мой взгляд, подобные трюки усложняют читабельность кода и ломают общий подход структурнуго и ООП программирования. Инлайнить, согласен.

Тогда практический вопрос - 1 локальная переменная в 2 байта, один вызов фукнции. Сколько ставить размер стека в scmRTOS?


Смысл от мьютексов в кооперативной RTOS?

Обратились к "драйверу" I2C на чтение из внешней EEPROM. Пока он в прерываниях делает обмен - ждём, отдавая управление другим задачам кооперативки. Одна из них захотела что-то вывести на индикатор, который тоже на I2C.
Как тут без мьютекса?

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

На входе (и не только) может быть ещё выделение участка стека инструкциями, изменяющими указатель стека.
Плюс могут вызываться библиотечные функции, расход стека которыми не известен без исходников.

На форуме этот вопрос. причем именно при использовании scmRTOS рассматривался и давались ссылки прямо на примеры, как можно измерить потребную глубину стека. Поищите!

Да вы оптимист Вы не указали компилятор, у ИАР так вообще два стека на каждый процес. Еще учтите, что весь контекст прерываний кладется на стек текущего процесса, значит в стеке каждого процесса надо зарезервировать место под контекст самого охочего до стека прерывания. Мое мнение - или менять проц, или отказываться от ОС.

Да уж, на таких мощностях иногда стоит вопрос использовать ли си или впихивать невпихуемое на асме, как мы делали на 8253, а ОС, да ещё вытесняющая - разве что в качестве демки.
Может, и не нужна никакая ОС?
Если просто переключать задачи, без наворотов, может и прототред какой-нибудь сойдёт.
2 байта на задачу, стек общий.

Указал же - gcc. Спасибо за ответ, уже переделал на опрос датчиков в основном цикле без ОС. Увы, не так удобно и надежно, но работает