2*18*50Гц=1.8КГц
ты еще забыл кванты для прерывания по таймеру.. дискретизация выходного сигнала
Но даже если 500 КГц это не смертельно, у нас система в данной задаче должна четко генерировать импульсы, все остальное оно хоть час может считать так как это не специфицировано
ПК чаще дергается между приложениями в винде.
Какие там издержки на переключение задач нынче в RTOS?
зависит от задачи, от того с какой точностью система должна обеспечивать риал тайм. Какие то задачи допускают часы, какие то требуют микросекунды.
Советую все таки хотя бы с краткой теорией о RT системах ознакомится.
Добавлено спустя 12 минут 22 секунды:Может пример задачи даст понимание все-таки зачем RT ос вобще,
Дано делать замер величин А, Б, С (темперантура, влажность, содержание кислорода) в каком то лабораторном стенде с интервалом 100 мс +/-2 мс, плюс контроллер подключен к интранету комплекса, конфигурируется через веб, а данные скидывает раз в сутки по запросу сервера по UDP лбо TCP протоколу.
По моему РТ ос тут самое оно, несколько задач на устройстве
можно отдельно конечно сделать контроллер что по таймеру будет результаты считвать, и держать мк который с сетью работать будет, а можно на одном сделать.
Очевидный вопрос а зачем ОС? можно железно записать без ос в мощный контроллер, поиграться с прерываниями все вылизать...
А потом придет манагер/заказчик/начальство и скажет, а давайте мерять еще 3 величины и не 100 мс а с 60 мс инитервалом...
И проект оптимизированный под предыдущие параметры можно положить в архив и заново играться с таймигнгами...
Использование RT ОС на определенной стадии сложности проекта это существенно упросит