https://opennet.ru/openforum/vsluhforumID3/40827.html Представлен (http://linuxdevices.com/news/NS8393438079.html) проект Xenomai/SOLO (http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=blob;f=README), являющийся реализацией режима эмуляции RTOS систем, при использовании стандартного Linux ядра. В отличие от других проектов, таких как Xenomai (http://www.xenomai.org/index.php/Main_Page), нет необходимости в наложении патчей или в установке дополнительных модулей ядра, - все реализовано на пользовательском уровне.<br><br><br>Для работы Xenomai/SOLO требуется свежая версия библиотеки glibc с поддержкой NPTL нитей и режима PTHREAD_PRIO_INHERIT. Желательна, но не обязательно, установка Linux ядра с включенными real-time расширениями PREEMPT_RT (http://rt.wiki.kernel.org).<br><br><br>Проект позволит значительно упростить процесс портирования RTOS приложений, например, первым достижением Xenomai/SOLO стала возможность пересборки с новым фреймворком эмулятора VxWorks.<br><br>URL: http://linuxdevices.com/news/NS8393438079.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num https://opennet.ru/openforum/vsluhforumID3/40827.html#21 Tue, 25 Mar 2008 20:28:53 GMT А вот как раз и интересует полный реал тайм, когда ЦПУ только и занят потоком видео. В общем то грамотно написанный и использующий SSE3 алгоритм может с точностью до герца расчитать требуемую частоту процессара, учитывая конечно же и архитектуру системы в целом...<br>Другое дело, что HDTV проприетарщина :(<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#20 Tue, 25 Mar 2008 07:00:29 GMT &gt;Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов <br>&gt;всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким <br>&gt;dvd пепельницам <br><br>Софт против аппаратно реализованного кодека всё равно не канает.... Купите видюху поприличнее - не будет ничего логать - у меня в VLC на х800 HDTV почти не лагает.<br><br><br> https://opennet.ru/openforum/vsluhforumID3/40827.html#19 Mon, 24 Mar 2008 22:29:30 GMT &gt;"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет. <br><br>Не вполне согласен - "мягкое" РВ - это фактически отсутсвие РВ.<br>РВ вполне измеряемо, и если гарантированное время реакции в VxWorks допустим 10 мс, а в Linux 30, то очевидно, что VxWorks по этому параметру лучше.<br>Собственно именно это я и имел ввиду, когда говорил о лучшем РВ.<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#18 Mon, 24 Mar 2008 19:12:21 GMT Ну мож хоть видео можно будет 99.9% заставить без рывков и артефактов всяких показывать. А то софтверные проигрыватели сливают в этом плане всяким dvd пепельницам<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#17 Mon, 24 Mar 2008 12:21:30 GMT А смысл то в чем переносить? Это нужно, как среда разработки для новых проектов, хотя сомнительно, что удастся создать полную эмуляцию (личное мнение).<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#16 Mon, 24 Mar 2008 07:07:08 GMT Вряд ли тот кто десятилетиями разрабатывал систему под VxWorks реально захочет все переписывать с нуля телько для того, чтобы перенести свой продукт на Linux. Для масштабных проектов всегда требуется время. Одним из примеров является Nortel - большинство их PABX (включая IP тел. станции) работаеют по VxWorks.<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#15 Sun, 23 Mar 2008 22:05:35 GMT &gt; ... или это у вас стеб такой?<br><br>Дошло?! А то я уж боялся что у тебя как у павлина чувство юмора в нокауте...<br>"Реальное время" оно либо есть (будь то жёсткое или мягкое), либо нет. И со "скоростью реакции", "латентностью" и прочим оно соотноситься как с цветом - это перпендикулярные понятия. Так же как и красный цвет в графическом редакторе - нельзя нарисовать "лучший" просто потому, что его либо можно нарисовать, либо нет: оно не бывает лучше\хуже.<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#14 Sun, 23 Mar 2008 21:14:47 GMT А что, были замечены негативные последствия этих связей? Все только на пользу.<br> https://opennet.ru/openforum/vsluhforumID3/40827.html#13 Sun, 23 Mar 2008 13:26:39 GMT Немного не так. <br>В ОС реального времени каждая обработка должна выполняться в строго заданое время. В Linux хоть и меньше латентность, но нет никакой гарантии, что требуемая операция будет выполнена в строго заданое время. В реальных задачах в системах не реального времени (Linux и т.д.), приходится расчитывать так опрос, например датчика, чтобы он начинался гарантировано раньше поступления с него данных, при этом процесс ожидает прихода данных. После получения данных идет уже обработка. Вот и получается, что более короткую латентность и процессорное время тратят на ожидание и переключение между процесами. В РТОС все заранее просчитывается и для получения адекватного результата нужно меньшую частоту процессора и все вытекающие из этого последствия.<br>Офисные приложения, фотошопы и т.п. не требуют реально времени выполнения, это не те цели.<br>