ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
6 мая
159035 Топик полностью
Evgeny_CD, Архитектор (14.06.2009 20:35, просмотров: 224) ответил AlexandrY на Самое прохое, что можно придумать в RTOS - это менять приоритет потоков или принцип планирования на ходу.
У всякого подхода есть исключения. Но для приведенных Вами задач я не понял, где гибкий планировщик неправилен. Спутниковый рисевер не должнен терять пакет, ибо его первичная обработка и буферизация должны делаться аппаратно в SDRAM (иначе чипсет фтопку). На долю проца будет только решать, что с пакетом делать. Принтер имеет приличное буферное ОЗУ, и никто не мешает вовремя дать время задаче наполнения этого буфера по мере его опустошения. Сихронность работы контроллеров движков и развертки головки - это действительно, специфическая задача, и решать ее надо с хорошей аппаратной поддержкой. Или на выделеном проце, который занимается только этим. В общем, не стоит до конца мир больших ОСей с тысячами потоков переносить в мир однокристальных решений. Но если сделать некие удобные простые эквиваленты "больших" решений, которые не так круты, но куда легче поресурсам - почему бы и нет. Насчет тестирования - вот когда будет сделано автоматическогое изоморфное отображение графа алгоритма на код, и будет сделана автоматическая проверка, + система мониторинга протоколирования критических событий - вот тогда да, тогда качество можно будет сильно повысить.