Имеет ли смысл переход на FreeRTOS (или другую RTOS)

BuguRTOS.

а какие преимущества это даст?

Давай код, посмотрим.

Проект следует реализовывать на RTOS в случае если, есть минимум 2 параллельно работающие функции, работоспособность которых страдает от delay’ев в соседней. RTOS в данном случае позволит на время работы delay в одной задаче отдавать тики (считай, процессорное время) соседней. Аналогичное можно реализовать и без использования RTOS (например, с помощью конечных автоматов или «стэйт машины»), но когда задач и состояний сновится много, разруливать логику становится сложней. Так же RTOS упрощает управление доступом к общим ресурсам и многое другое..

По ситуации в общем стоит смотреть, что проще, RTOS прикрутить или конечник накидать и тд

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

Использую RTOS (в моем случае chibios, а то от венгерской нотации freertos хочется блевать) даже для моргания светодиодом. Какая разница занятьі ресурсьі или будут мертвьім грузом висеть.

Ну если что-то большее чем гирлянда, и мощи свободной СТМа хватает то да, так как уберет кучу специального кода. Типа возможность мейтейнить улучшится, так как всякую рутину сбросишь на ХАЛы

Вот это вот

https://github.com/nort-cnc-control/cnccontrol_rt/tree/master/arch/stm32f103

В моем коде есть 1 задача, которая работает на прерываниях от таймеров, и она в любом случае так останется, т.к. таймеры rtos слишком медленные, задача, где подготавливаются данные для первой задачи (немного расчетов) и работа с сетью. Сейчас две последние задачи крутятся в цикле

есть смысл то распаралеливать эти функции или можно их последовательно в одном цикле обработать и не ломать себе голову?

protothreads не достаточно?

Есть два принципиальных момента, когда «многозадачность» полезна:

1. Тебе надо написать длинную асинхронную бизнес логику без конских switch, которые через месяц сможешь прочитать только ты, а через два вообще никто.
2. У тебя > 2 тасков, и один слишком долго блочит процессор (тяжелые вычисления).

На практике я постоянно сталкиваюсь с (1) и еще никогда не сталкивался с (2).

Я обычно вешаю прерывания на все срочное, из них по ETL пуляются сообщения в прототаски, и хватает за глаза.

С rtos проще статистику пособирать, всякие режимы сна привернуть. Но стеки руками размечать, плюс переключения контекста… буэээ…

Вот как-то так.

у меня есть немного (2), но сейчас быстродействия хватает, чтобы вычисления не блокировали работу сети

Обязательно RTOS, рекомендую FreeRTOS, а для сети FreeRTOS+TCPIP

Плюсы перехода на RTOS:

Ты можешь вести разработку в терминах параллельных взаимодействующих процессов. Допустим, процесс сбора данных, процесс обмена с ПК по последовательному порту, процесс записи данных в файл на карту памяти, процесс индикации состояния на дисплее/светодиодах. Задачи обмениваются при помощи средств оси (мьютексы, флаги, очереди и т.п.). Задача может заснуть в ожидании нужного события/поступления данных/просто на заданное число миллисекунд). И так далее.

Я сейчас даже простейшие задачи делаю с использованием оси.

Если не противник плюсов, то рекомендую scmRTOS.

ну вот у меня самый главный код может быть только на аппаратных таймерах реализован…

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

RTOS гарантирует (ну, может, не совсем гарантирует, но по крайней мере получше, чем другие ОС), что если ты на определённой конфигурации потестил определённые задачи, и результат тебя устроил, то они с высокой степенью вероятности так и будут работать. Т. е. процессорное время между ними будет делиться более-менее равномерно (если приоритет задач одинаковый), алгоритмы распределения памяти будут работать с одинаковой скоростью при практически любых условиях и т. д. В общем, надёжность и стабильность. Если на АЭС время реакции должно быть не более 1/10 сек., ты потестил, и оно действительно < 1/10, то так и будет меньше, — аварии не случится, можешь спать спокойно. Но это не значит, что RTOS быстрее. Обычно — наоборот, — за синхронизацию и стабильность приходится платить общей производительностью. Т. е. если на АЭС у тебя 5 процессов, каждый из которых должен реагировать за 1/10 сек. или быстрее, и они все успевают передать друг другу управление ровно за это время, то на обычной не RT OS они скорее всего будут работать быстрее и успевать не за 1/10, а за 1/15 сек., например. Но синхронность снизится. Так, в какой-то момент (возможно, не так уж и часто) какой-то процесс может проработать 1/5 сек., и остальные не успеют среагировать за заданное время. Поэтому если тебе важна синхронность и надёжность, то используй RTOS, а если общая производительность с возможностью проседания время от времени каких-то процессов или нитей, то используй обычную OS.

Если ресурса CPU достаточно для приемлемого отклика, значит (2) у тебя нет :).

Вместе с RTOS ты в неявном виде получаешь очереди сообщений и всякие обмотки на атомики. Если возьмешь это в явном виде, например из ETL, добавив прототреды, то вроде и без RTOS неплохо.

Я тебя не отговариваю от RTOS, просто раскладываю на части, где какие ноги растут, и как их можно перекомбинировать.

Но, если RAM не впритирку и хочется с RTOS поиграться - бери и не парься. Просто не жди чуда :).

а там, где возникают сомнения rtos, не rtos - вообще можно думать о втором процессоре с выделенными задачами