uCOS переносится за день на новый процессор, если он вами хорошо изучен. В uCOS есть все механизмы межзадачного взаимодействия: семафоры, флаги, очереди, майлбоксы и т.д.
Для uCOS я с точностью до 1 мкс могу предсказать время переключения между задачами.
Для uCOS есть детерминированный менеджер памяти. Легко сделать менеджер с очередями запросов.
В uCOS нет уровня HAL, а значит драйверы не обременены лишним прокладочным кодом и их легче и быстрее писать. А ведь на новую платформу 90% времени уходит на написание новых драйверов, перенос OS-и в этом и заключается.
Процессы же могут поддерживаться только на процеесорах с MMU, в процессорах без MMU будут только потоки с общим пространством памяти и не будет никакой абсолютно разницы что програмировать под uCLinux что под uCOS. Под uCLinux только больше пропаритесь и ничего нового не получите кроме тормозов.
Цитата(PrSt @ Oct 31 2006, 11:29)

ну скажем так, бывает ряд приложений где совершенно не надо "бешанную" производительность от склейки МК+ОС, а важно не тратить много времени на написание взаимодействия между "просессами или же их бледное подобие".
На счет памяти без спору, согласен - возможно прийдется ставить внешнюю...
драйвера писать - ну скажем напишем, не умрем... на то она и ОСь чтоб все через "дрова" работало...
Разумеется - нет, не ради "файловой системы и TCP стека", есть еще такая замечательная вешь как IPC и более того многозадачность(что более важно)...
+ ко всему переносимость с проекта на проект.
а свякую бяку рассматривать типа RTOS (притянутую за уши к плоскости ОС) или еще чего то, что просто махает флагом - мол RealTime...
В контексте данного вопроса не рассматривается же REALTIME требования, а расматривается возможность как такавая применять uCLinux в данном семействе МК...