[Владимир Е. Зюбин 0]

Так в этой же статье так и написано: " Поддержка реального времени: Windows XP Embedded - Нет, Windows CE - Да" :)

И опять - это реалтаймный интерфейс с пользователем - тут Win хорошо смотриться.

 

А что, по-Вашему, это конкретно означает?

 

На мой взгляд это означает, что Embedded может на несколько ms прерывать пользовательскую программу своими службами (если они установлены), а WinCE - нет.

 

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

 

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

[TED17 0]

но всё гораздо хуже ;):

http://athena.vvsu.ru/carina/RealTime/Realtime_3.html

http://www.nautsilus.ru/products/winnt.htm

http://www.pcweek.ru/?ID=60308

http://www.rtsoft.ru/article/home_md.html?p=600308

Староваты все же ссылки, да и один треп без конкретики.

Насчет скорости реакции обычной WinXP Sp2, я мерил на устройствах непрерывного сбора инфы с датчиков в течении нескольких часов. Статистика:

-регулярные отклонетия при частоте опроса 50мс -<5мс,

-одиночные отклонения на интервале 3сек -<70мс,

-других отклонений не замечено.

Комп обычный 2Ггц, лишние службы и сервера отключены, приоритет софта- высший.

Для многих задач автоматики такие времена вполне достаточны, что и определено заголовком темы (Когда не нужна ОС РВ?).

На Embedded результаты должны быть лучше просто потому, что там лишний мусор просто не ставится в сборку.

[Evgeny_CD 0]

...Насчет скорости реакции обычной 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.

 

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

 

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

 

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

[Владимир Е. Зюбин 0]

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

С "простой платой" не все просто -

вопросы такие:

серийность,

универсальность,

отличие от существующих решений.

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

Возможно есть и с буферизацией.

А вообще, то, о чем Вы говорите, очень похоже на data logger-ы (коих тоже много встречается).

 

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

 

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

Изменено 15 июня, 2006 пользователем Владимир Е. Зюбин

[733259 0]

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

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

[Evgeny_CD 0]

...С "простой платой" не все просто -

вопросы такие:

серийность,

универсальность,

отличие от существующих решений.

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

Возможно есть и с буферизацией.

А вообще, то, о чем Вы говорите, очень похоже на data logger-ы (коих тоже много встречается).

 

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

Я говорил о принципе. Пример:

http://opalkelly.com/

 

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

 

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

 

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

 

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

[TED17 0]

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

 

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

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

На другой базе будет ИМХО сложнее.

 

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

[Goroshko 0]

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

Да нет, как раз не слишком и сложно. Примерно так и работаем - получается не плохо :-)

Просто то о чем вы говорите - это вопросы не программирования, а проектирования. Ведь идея разделения критических/некритических модулей очевидна до безобразия.... только если сначала подумать, а потом браться за клавиатуру, а не наоборот :-)

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

 

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

 

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

Изменено 15 июня, 2006 пользователем Goroshko Egor

[Evgeny_CD 0]

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

На другой базе будет ИМХО сложнее.

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

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

Я не очень знаком с NI (по прине "неправильных" цен). Но вот opalkelly мне очень понравились соотношением цены и возможностей (практического опыта работы с ними пока не имею).

[Evgeny_CD 0]

Да нет, как раз не слишком и сложно. Примерно так и работаем - получается не плохо :-)

Просто то о чем вы говорите - это вопросы не программирования, а проектирования. Ведь идея разделения критических/некритических модулей очевидна до безобразия.... только если сначала подумать, а потом браться за клавиатуру, а не наоборот :-)

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

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

Помню замечатльный пост в листе по 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 - обычно такая лажа получается - еще незвестно, что хуже...

[TED17 0]

Я не очень знаком с NI (по прине "неправильных" цен). Но вот opalkelly мне очень понравились соотношением цены и возможностей (практического опыта работы с ними пока не имею).

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

[Andrew2000 0]

... Почему нельзя взять простую плату, воткнуть ее в PCI ..., поставить на нее простой embedded проц с периферией ..., сделать на этом проце real time часть обработки датчиков, а всю остальную обработку ... вынести в винДазЫ.

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

Т.е. управление отдельно, а Винда занимается сбором архивов, графики, ....

[Владимир Е. Зюбин 0]

... Почему нельзя взять простую плату, воткнуть ее в PCI ..., поставить на нее простой embedded проц с периферией ..., сделать на этом проце real time часть обработки датчиков, а всю остальную обработку ... вынести в винДазЫ.

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

Т.е. управление отдельно, а Винда занимается сбором архивов, графики, ....

 

И мы так постоянно делаЛИ... публикаций на эту тему не счесть, начиная с 1996 года...

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

 

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

[TED17 0]

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

[Владимир Е. Зюбин 0]

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

 

С языком G могут быть проблемы. Dataflow языки для описания алгоритма управления слабо подходят...

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

 

Ну, а если решитесь, то очень было бы интересно взглянуть...

для ориентировки - решение этой задачи на Рефлексе заняло около часа.