Спасибо за ответ, но для меня это очень туманно... и фраза "на несколько миллисекунд", и фраза "а WinCE - нет"... то ли WinCE вообще ничего не прерывает (?), то ли все-таки прерывает, но на несколько микросекунд, и сколько это "несколько микро/миллисекунд"? сотни? десятки? или единицы? и что немаловажно, как часто прерывает?

Это все-таки не к Вам, понятно, вопрос, а к автору этой странной характеристики... чего хотел сказать, какую информацию сообщить... туман.

Староваты все же ссылки, да и один треп без конкретики.
Насчет скорости реакции обычной WinXP Sp2, я мерил на устройствах непрерывного сбора инфы с датчиков в течении нескольких часов. Статистика:
-регулярные отклонетия при частоте опроса 50мс -<5мс,
-одиночные отклонения на интервале 3сек -<70мс,
-других отклонений не замечено.
Комп обычный 2Ггц, лишние службы и сервера отключены, приоритет софта- высший.
Для многих задач автоматики такие времена вполне достаточны, что и определено заголовком темы (Когда не нужна ОС РВ?).
На Embedded результаты должны быть лучше просто потому, что там лишний мусор просто не ставится в сборку.

Парни, а ведь это ключевой момент супермегафлейма.

Давайте задумаемся. Проц с тактовой 2 ГГц, жрущий ватт 50 энергии, с 512м ОЗУ смог с трудом обеспечить опрос нескольких (сколько их у Вас было? Едва ли 100 шт) датчиков с частотой 20 гц. Аминь.

Вот я приглядываю за дискуссией, и никак не могу догнать элементарную вещь. Почему нельзя взять простую плату, воткнуть ее в PCI (PLX & Co нам всегда помогут), поставить на нее простой embedded проц с периферией (баксов 50 макс, сейчас это будет 200 Мгц проц - не такой уж и примитивный), сделать на этом проце real time часть обработки датчиков, а всю остальную обработку (сеть, графика, SQL и пр.) вынести в винДазЫ. Хотя бы просто буферизация результатов синхронного опроса с меткой времени, когда именно этот факт опроса имел место - обработать можно и потом. Внешнее устройство с быстрым интерфейсом (USB | FireWare | Ethernet (100 | 1000 | 10000) Mbit | SCSI) тоже ок - даже лучше.

Обратный процесс - установка на embedded устройство ГУЯ с рюшечками и финтифлюшками, портирование Office на PLC - столь же маразматичен.

Нет ответа. И не будет. Я убедился, что промавтоматика - это религия. Если люди уверовали в винДаЗ всемогущий - они и будут его в "контроллеры светодиодов" ставить. Если они любят постегать себя плетью (я не знаю, как это назвается, но в клипе Ramstain смотрится круто) - они и клиент-сервер с БД будут писать на ASM под управлением оси BigLoop.

А за "включение головы" следует немедленное "развоплощение" как в Дозорах.

Кошмар какой-то. И ведь все это продается и покупается. И бабло в этом мире крутится нехилое. Вот точно революцию в этой "тихой гавани" надо устроить. Чтобы неповадно было маразмом заниматься.

Сорри за полемичность.

С "простой платой" не все просто -
вопросы такие:
серийность,
универсальность,
отличие от существующих решений.
Кто ее делает и с чем она соединяется снаружи (протоколов - тьма, физический сигнал <ток/напряжение, диапазон, схема подключения термопары/термосопротивления>, кодирование (ШИМ, ЧИМ), типа HART, филдбасы (не счесть)). Ну, а УСО на PCI - очень много... см. www.prosoft.ru
Возможно есть и с буферизацией.
А вообще, то, о чем Вы говорите, очень похоже на data logger-ы (коих тоже много встречается).

Кстати, проблема в простейшем случае решается и без спец.средств типа логгеров, а просто через прерывания.

P.S. Отклонения от номиналов при обмене датчиков могут быть вызваны и внешними по отношению к ОС причинами... например помехой при передаче пакета или конфликтом, приводящими к повторной посылке.

Сообщение отредактировал Владимир Е. Зюбин - Jun 15 2006, 06:03

Или мышкой, клавиатурой Или винде диском пошуршать захотелось

Я говорил о принципе. Пример:
http://opalkelly.com/

Есть плата. Она идет вместе с ядром софта и железа. Кустомер пишет свою специфическую часть в процессоре платы, а затем пишет обработчик на пЫсюке. Причем все это базируется на готовом фундаменте, и кустомер работает с высокоуровневыми примитивами.

В идеале кустомер должен и мыслить, и писать в пространстве объектов, характерных для своей предметной области. Как тут уже справедливо замечали, спец. по ЖД автоматике должен мыслить не так, как С программист. И с моей точки зрения тратить "лишнине" ресурсы аппаратуры на неоптимальность такой объектной модели допустимо, а вот тратить их только на то, чтобы запустить винДаЗ всемогущий - нет.

И вообще, в моем понимании, в любой задаче подобного класса работа с данными (сбор и первичная обработка) должна быть отделена от работы с каналами связи, юзеровской обработки (ГУИ) и накопления данных (БД и пр.) Но все это должно быть в рамках одной идеологии, и единого инструментария.

Черт, все равно как-то сложно получается...

Датчиками являлись 3 ПЗС RGB матрицы 320х240 20fps, те входной поток около 15мбайт/c плюс покадровая обрабтка выделения и динамики перемещения объектов. Загрузка процессора 70%.
На другой базе будет ИМХО сложнее.

Ваши последние 2 поста являются хорошим описанием РТ идеологии и инструментария фирмы "National Instrumehts" и её клонов, включая и особенности разработки подобных систем конечным пользователем. Кстати, на этой базе ( NI Labview с примочками) все и тестировалось.

Да нет, как раз не слишком и сложно. Примерно так и работаем - получается не плохо :-)
Просто то о чем вы говорите - это вопросы не программирования, а проектирования. Ведь идея разделения критических/некритических модулей очевидна до безобразия.... только если сначала подумать, а потом браться за клавиатуру, а не наоборот :-)
Вот есть система логирования - нужен SQL, или XML, все дела... Вот есть GUI пользователя, и он очень хочет видеть его на Винде - если это не критическая управляющая логика - да ради бога, пусть все это хозяйство крутится в винде с каким нибудь MS SQL Server, с красивыми картинками из-под DirectX и все такое прочее... а PLC, SCADA сервер, управляющая логика клиентов - все такие это же серьезные вещи, хочется положить их в простое и надежное, и главное - понятное место. :-) Ведь жалко же... стараешься, корпишь над ними, вылизываешь, а потом бабах тебе 50-70 мс выбрасы.... откуда они могут взяться на таких частотах?

Вот ради примера - заказчику хочется видеть SCADA сервер с 1мс циклом и временем отклика для клиента не более 2 мс. Сеть - гигабит, машины - не менее 2 ГГц процессоры (причем не меньше 2 штук на каждую :-) )- что такой системе 1 мс? Тьфу... а попробуйте такую штуку на Винде учудить? На линухе еще как то работает, хотя все равно 2 мс отклик обеспечить - ой как трудно. При тех же машинах в QNX или VxWorks - нет проблем...

И не надо говорить что такие задачи - большая редкость... да редкость... но это показательно...

Сообщение отредактировал Goroshko Egor - Jun 15 2006, 13:16

Вау!!! Да, это сильное приложение. Тут всякие мелкопоганистые ARM и близко не лежали (из тех, что можно пойти и купить как микрухи, а не из тех, что на сайте ARM описаны )Я не очень знаком с NI (по прине "неправильных" цен). Но вот opalkelly мне очень понравились соотношением цены и возможностей (практического опыта работы с ними пока не имею).

О!!!! Это вечная проблема - вовремя "включить голову". Причем желательно когерентно - и у Заказчиков, и у финансистов, и у разработчиков.Помню замечатльный пост в листе по eCos. Какой-то чел спрашивает:

"Вот взял я S3C4510B ( 50 Mhz ARM7 от Samsung со встроенным Ethernet). uClinux дает мне производительность по сети 30 мбит/сек, а Ваш такой распрекрасный Real Time eCos всего 12. И что за нафиг?" И ему тогда очень грамотно "вкурили", что такое система с монолитным ядром, в котором все оптимизировано до ужаса (и модули под которую так трудно писать, еще труднее отлаживать, и на Real Time в которой проще забить сразу), и что такое eCos, где каждый драйвер можно отлаживать в GDB, и назначать ему приоритет, как и всем другим процессам.

Вопрос в векторе оптимизации. Для юзеровско-десктопных, юзеровско-мультимедийных задач XPень оптимальна (по приведенному расходу ресурсов (памяти, MIPS проца, $ юзера) на единицу "юзеровского кайфа"). Это общеизвестный факт. Базируется такая оптимальность на тиражах: для 1 м копий программеры напрягутся и напишут приложение, которое будет быстрым, и в итоге все будет достаточно дешево.

Более гибкие системы, которые не рассчитаны на тиражи 1м, естественно, будут иметь overhead за счет гибкости и "правильности".

Но времена прошли. 512М памяти стоят менее 100$ в розницу. И с точки зрения $ overhead на "правильность" уже не особо волнует. А вот overhead на программистов - это да, это может потопить любой проект. Так пошел чувак, купил книжку - "VC за 21 день". Гдядишь, через 21 день он и вправду простенькую апликуху родит - научится пользоваться иконками в IDE как кнопками на пульте от TV - "нажми на кнопку и получишь результат". И сила мелкомягких и их последователей в том, что и вправду такая апликуха будет как-то работать (отжирая мегов 100 памяти на окно с Hello, world - но кого это волнует!)

Посему эти два мира нужно совмещать через прослойку в виде embedded ядра. Я совсем не против того, чтобы использовать дешевых программистов, но не надо везде их использовать. Нужно вспомнить забытый термин "системный программист". Кстати, когда системный программист пытается делать GUI - обычно такая лажа получается - еще незвестно, что хуже...

На NI можно делать системы любой сложности вплоть до глобальных и с любыми интерфейсами. Тут цена железа играет меньшую роль, а цена среды разработки еще меньше. Хотя одна из штучек от opalkelly http://opalkelly.com/products/xem3010/ очень понравилась.Спасибо. Извиняюсь за оффтоп.

Во. Именно так иногда и делаем. Крейт от NI под WinXP а внем своя железяка и программа ввода/вывода + управление под РТОС. А когда надо совсем надежно - можно и ресет своего процессора от PCI отвязать, чтоб при перезагрузке Винды управление не срывалось, а если еще надежнее, то и отдельное питание подать.
Т.е. управление отдельно, а Винда занимается сбором архивов, графики, ....

И мы так постоянно делаЛИ... публикаций на эту тему не счесть, начиная с 1996 года...
Отдельно интерфейс оператора на Виндовозных мультимедиа + высоконадежная железяка (Микро ПиСи со standalone Рефлексом). Дешево, надежно и сердито.

ДелаЛИ (и пока еще делаем), т.к. сейчас склоняемся к тому, чтобы эти части совмещать в одном. По надежности вопросов не должно быть, ну и общее удешевление системы еще на пять-шесть килобаксов (реально, может, и до десяти).

Короче, если вместо рефлекса взять язык G + NI RT, то получим то же самое без лишнего гемора.

С языком G могут быть проблемы. Dataflow языки для описания алгоритма управления слабо подходят...
Кстати, можете убедиться в этом сами, попытавшись запрограммировать на G алгоритм http://reflex-language.narod.ru/bottle/spec_bottle.htm ...

Ну, а если решитесь, то очень было бы интересно взглянуть...
для ориентировки - решение этой задачи на Рефлексе заняло около часа.