Первый-Второй курс института. Угадал?

zltigo
Если вы из того что я в свое время отказался от вот этой схемы

решили что я


то Вам виднее вы же Гуру. Вообще то гадают на кофейной гуще.

А я теперь буду знать, что Гуру может ЭСЛ логику тупой диковинкой назвать

ну чем же вам ПЛИС так насолили у них вообще другая область применения - это малотиражное производство. и применять их лучше для поточных алгоритмов(небольшая интенсивность ветвления потока управления, или зависимости по данным).
правда не знаю как устроены принтеры, но то что набор задач у него ограничен и стабилен за жизненный цикл устройства, наверное вопросов не вызывает. к тому же кажется мне что там как и в любой комплексной системе должна быть иерархия: врядли обработкой USB протокола и подсчётом чернил в катридже занимается центральный процессор, так же как и врядли ЦПУ в вашем ПК занимается управлением COM-портом. скорее там хорошо сбалансированная распределённая система. я даже сомневаюсь, что для сигнала об окончании чернил выделен какой-то специалный вектор отличный от какой-либо другой критической ошибки.
однако, я действительно этого не знаю, было бы интересно для примера почитать. подобную инормацию где-нить нарыть можно?

Важны не эти формулировки, а их последующее толкование.
Спросите и многие с пеной у рта будут доказывать, что Windows это не система реального времени.
Хотя все знают что в масштабе минуты или часа Windows гарантировано даст отклик на любое событие
Почемуже она не realtime? Ваши формулировки не дают ответа на это вопрос.

Ищем ответы в практической литературе:
"Real-Time Concepts for Embedded Systems" by Qing Li and Carolyn Yao
"Introduction to real-time operating system" by Robert Betz
"Realtime Operating Systems" by Dr. Jürgen Sauermann
"Real-Time Systems" by Albert M.K. Cheng

НИКТО не пытается дать формулировку системам реального времени наподобии тех что привели вы.
Все отсылают к примерам реализаций и просто пытаются искать различия.
И различия эти есть и довольно явные, но их не сформулировать одним предложением.
Вообщем как ни крути, а realtime в современном понимании это сложная технология одно из свойств которой - предсказуемость реакции (с неопределенными доверительными интервалами )






Весь набор задач то известен, но если они все сразу начнут работать, то принтер даже не включится.
Задачи создаются и уничтожаются динамически! Состояние принтера меняеться каждые 10 мс. Каждый такт операционки. Когда каретка справа выполняються одни задачи, когда слева набор задач может быть уже другим.
Конечно там стоит не голый проц, а SoC, на движки есть контроллер, на картриджи тоже контроллеры шин (ктож потянет 5-ть мегабитных потоков да еще full speed USB программно отлавливать ) но это сильно дело не облегчает. Все потоки данных все равно обрабатывает центральный процессор и разве что только маркеры кадров в протоколах сам не выставляет.

почему же не реального - смотря для каких задач она используется - если для печатания документов в Ворде - то оч даже реального(главное чтоб отклик этот не был выработан слишком поздно), а если для управления каким-нибудь аппаратом - то может уже и "не реального" - всё зависит от требований этого аппарата. и формулировка моя очень даже на это ответ даёт - время отклика не должно превышать некоего критического времени (критического для штатного функционирования системы) - почитайте внимательней
кстати это не только моё мнение вот, пожалуйте, подобное :

и ещё там похожие в данном топике были


ну а можно где-нить это почитать, плииз, - интересно же
З.Ы.: 2 AlexandrY упс, кажется, немного запутался с вашим стилем цитирования : (

Нет из-за того, что такая "мысль" могла придти в голову

Вы непозволительно невнимательны ЭСЛ это вещь "дивная", а не дикая, а "тупая" это поставленная Вами задача посчитать импульсы.

вот что вы тогда сказали

тут про тупую задачу ничего не сказано тут сказано тупой счетчик.
Тоже могу сказать и про Вас. Это Вы невнимательны, я не говорил что ставил такую задачу себе и не бился над ней много лет. А всего лишь сделал поиск информации о QNX в сети, о его возможностях. А мысль использовать операционку, может возникнуть у любого кто не знаком с операционными системами реального времени и кто наслушался рекламы QNX в сети. ( ну в принципе они правы она самая быстродействующая из операционных систем реального времени). Тогда я просто оценил ее быстродействие и понял что мне это не подходит.

Жаль, что Вы так и не понимаете, что само возникновение "мысли" использовать хоть что-то процессорообразное (причем совершенно вне всякой зависимости от операционной системы и вообще ее наличия) для отработки времен реакции в ОДНУ НАНОСЕКУНДУ, говорит о многом .
Прощайте!

Вся инфа получена на основе реверсинга и реинжениринга
В принтерах бывает на плате отладочный порт по UART-у.
На том порте можно запустить Shell для просмотра состояния RTOS.
Посмотреть состав задач, объектов синхронизации, таймеров и т.д. Можно даже ими управлять.

А литературы с конкретным описанием архитектуры софта для действительно сложных дивайсов как тот-же принтер не видел. Ну и в принципе этож комерческая тайна, зачем облегчать жизнь конкурентам?

Сорри что вмешиваюсь
Кто нибудь работал с ChorusOS ? Встречал упоминания что она сравнима и даже в чем-то превосходит QNX. Открытые исходники, куча платформ, и тд (насколько я помню, по объёму и количеству файлов сравнима с QNX, лень распаковывать ). Когда я увлекался копанием исходников ОС, то ее дизайн и структура исходных файлов мне очень понравилась..

Для систем такого объема на первый план выходит не наличие исходников, кои все равно не вычитать и не исправить, или заявления о превосходных заложенных идеях, а количество систем на которых она применяется и соответственно по результатам работы на которых правилась и развивалась. Тут QNX без вариатнов превосходит очень и очень многих.

Справедливо для версии 4, но не для 6.

vshemm
[/i]Справедливо для версии 4, но не для 6.[i]

Что за операционка реального времени которая лучше 6 версии?

Можно
см. например здесь:
http://qnxclub.net/modules.php?name=Forums...topic&t=443
к примеру, - полнофункциональная сетевая ОС, умещающаяся на дискету и занимающая в RAM <4Mb...
Собрано "из этого"(с)
Весь вопрос в том, какую функциональность вы хотите нагрузить на "более-менее работающую систему"...
GUI + multimedia ?


Это неправда ... что и показывают эксперименты.
Более того, если задачу, работающую над какими-то регулярными структурвми выполнить:
- как однотредоввую задачу...
- разделив ту же работу между N тредов (N большое ... сотни и более)...
- разделив ту же работу между N процессов в изолированных MMU адресных пространствах (контекст процессора нужно переключать)...
... то время выполнения суммарной работы во всех случаях не будет различаться более, чем на 10-15%




... и не только как HMI, а как системой управления всей навигацией ... известный пример приводится при разборке случаев "критических ошибок ПО", когда при перебазировании эскадрильи F-16 в Австралию при пересечении экватора они перевернулись "вверх брюхом", и "соглашались" лететь только так - система координат поменялась ...

+ управление огнём танка "Абрамс", который считается лучшим в мире...

+ управление безопасностью всех АЭС Канады...

+ управление распределёнными сетями нефте-газо-перекачки "Газпром"...

+ АСУТП литейными и близкими к ним производствами ... Магнитогорск и др.




да? а вся система телеметрии МКС ?





Даст ...
... если к истечению этого критического интервала времени она просто не зависнет ... чему есть конечная вероятность.


Хотя бы по одной (но не единственной ) причине:
- в ней даже не предпринимаются никакие попытки препятствовать инверсии приоритетов:

- поток 1 (процесс) с низким приоритетом L захватывает мютекс, скажем...
- позже поток 2 (процесс) с высоким приоритетом H хочет тот же мютекс, но это же "потом" ... поэтому он ожидает...
- ... и всё будет нормально, когда через интервал T : а). поток 1 освободит мютекс б). поток 2 получит мютекс в). тут же вытеснит поток 1;
- но до тех пор, пока до истечения интервала T не появится 3-й поток (процесс) среднего приоритета M ... да ещё и не переходящий в блокированные состояния пассивного ожидания (оператор сел со скуки "солитёр" погонять)...
- что имеем? а). поток L владеет мютексом и вытеснен б). потоком M а в). а поток H благополучно ожидает мютекс, которым владеет L ... + г). и это может продолжаться до бесконечности... и ни "в минуты"(с) ни "в часы"(с) она теоретически не разрешается

1. эта ситуация достаточно легко моделируется в Windows...
2. проверено ... "плавали"(с)
3. можете попробовать
4. подробней можно почитать и пообсуждать здесь, например:
http://qnxclub.net/files/articles/invers/invers.html
http://qnxclub.net/modules.php?name=Forums...wtopic&t=16


... ну, много и разное говорилось... и достаточно конкретные вещи:
http://qnxclub.net/files/articles/rtos/rtos.html
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
http://qnxclub.net/files/articles/rms/rms.html
http://qnxclub.net/files/articles/rta/rta.doc
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html
http://qnxclub.net/modules.php?name=Forums...wtopic&t=36
http://qnxclub.net/modules.php?name=Forums...topic&t=116

Программисты от индустрии сильно оторваны от консамерной техники и практически мало знают о применяемых там технологиях.
Из преведенных ссылок опять же нигде не следуют четкие определения RTOS кроме той что выделил внизу.
Но там только подтверждаються некоторые мои мысли.
Как я уже показал в простом принтере могут выдвигаться требования к realtime гораздо жесче чем в каком нибудь индустриальном дивайсе.
И потери от несоблюдения realtime в принтере больше чем в индустриальном дивайсе.
Принтеров о которых я говорю выпустили несколько миллионов только этого конкретного типа. Потеря качества из-за плохого ПО там сразу приводит к миллионным убыткам.
Именно консамерская техника заставила принять закон о RoHS.
Именно она и диктует понимание RTOS, потому что производители RTOS на нее ориентируются.
И QNX как видно уже понял тренды.

Я конечно могу понять страдания вокруг ЧМА на форуме по QNX.
Но если в мобиле количество задач приближаеться к сотне и она при этом должна поддерживать несколько десятков протоколов в realtime одновременно, а собирается софт к мобиле из друг другу неизвестных кусков то тут уже не до ЧМА.