Владимир Е. Зюбин 0 14 июня, 2006 Опубликовано 14 июня, 2006 · Жалоба Так в этой же статье так и написано: " Поддержка реального времени: Windows XP Embedded - Нет, Windows CE - Да" :) И опять - это реалтаймный интерфейс с пользователем - тут Win хорошо смотриться. А что, по-Вашему, это конкретно означает? На мой взгляд это означает, что Embedded может на несколько ms прерывать пользовательскую программу своими службами (если они установлены), а WinCE - нет. Спасибо за ответ, но для меня это очень туманно... и фраза "на несколько миллисекунд", и фраза "а WinCE - нет"... то ли WinCE вообще ничего не прерывает (?), то ли все-таки прерывает, но на несколько микросекунд, и сколько это "несколько микро/миллисекунд"? сотни? десятки? или единицы? и что немаловажно, как часто прерывает? Это все-таки не к Вам, понятно, вопрос, а к автору этой странной характеристики... чего хотел сказать, какую информацию сообщить... туман. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TED17 0 14 июня, 2006 Опубликовано 14 июня, 2006 · Жалоба но всё гораздо хуже ;): 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 14 июня, 2006 Опубликовано 14 июня, 2006 · Жалоба ...Насчет скорости реакции обычной 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 15 июня, 2006 Опубликовано 15 июня, 2006 (изменено) · Жалоба Вот я приглядываю за дискуссией, и никак не могу догнать элементарную вещь. Почему нельзя взять простую плату, воткнуть ее в 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 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба P.S. Отклонения от номиналов при обмене датчиков могут быть вызваны и внешними по отношению к ОС причинами... например помехой при передаче пакета или конфликтом, приводящими к повторной посылке.Или мышкой, клавиатурой Или винде диском пошуршать захотелось Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба ...С "простой платой" не все просто - вопросы такие: серийность, универсальность, отличие от существующих решений. Кто ее делает и с чем она соединяется снаружи (протоколов - тьма, физический сигнал <ток/напряжение, диапазон, схема подключения термопары/термосопротивления>, кодирование (ШИМ, ЧИМ), типа HART, филдбасы (не счесть)). Ну, а УСО на PCI - очень много... см. www.prosoft.ru Возможно есть и с буферизацией. А вообще, то, о чем Вы говорите, очень похоже на data logger-ы (коих тоже много встречается). Кстати, проблема в простейшем случае решается и без спец.средств типа логгеров, а просто через прерывания. Я говорил о принципе. Пример: http://opalkelly.com/ Есть плата. Она идет вместе с ядром софта и железа. Кустомер пишет свою специфическую часть в процессоре платы, а затем пишет обработчик на пЫсюке. Причем все это базируется на готовом фундаменте, и кустомер работает с высокоуровневыми примитивами. В идеале кустомер должен и мыслить, и писать в пространстве объектов, характерных для своей предметной области. Как тут уже справедливо замечали, спец. по ЖД автоматике должен мыслить не так, как С программист. И с моей точки зрения тратить "лишнине" ресурсы аппаратуры на неоптимальность такой объектной модели допустимо, а вот тратить их только на то, чтобы запустить винДаЗ всемогущий - нет. И вообще, в моем понимании, в любой задаче подобного класса работа с данными (сбор и первичная обработка) должна быть отделена от работы с каналами связи, юзеровской обработки (ГУИ) и накопления данных (БД и пр.) Но все это должно быть в рамках одной идеологии, и единого инструментария. Черт, все равно как-то сложно получается... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TED17 0 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба Парни, а ведь это ключевой момент супермегафлейма. Давайте задумаемся. Проц с тактовой 2 ГГц, жрущий ватт 50 энергии, с 512м ОЗУ смог с трудом обеспечить опрос нескольких (сколько их у Вас было? Едва ли 100 шт) датчиков с частотой 20 гц. Аминь. Датчиками являлись 3 ПЗС RGB матрицы 320х240 20fps, те входной поток около 15мбайт/c плюс покадровая обрабтка выделения и динамики перемещения объектов. Загрузка процессора 70%. На другой базе будет ИМХО сложнее. Ваши последние 2 поста являются хорошим описанием РТ идеологии и инструментария фирмы "National Instrumehts" и её клонов, включая и особенности разработки подобных систем конечным пользователем. Кстати, на этой базе ( NI Labview с примочками) все и тестировалось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Goroshko 0 15 июня, 2006 Опубликовано 15 июня, 2006 (изменено) · Жалоба Черт, все равно как-то сложно получается... Да нет, как раз не слишком и сложно. Примерно так и работаем - получается не плохо :-) Просто то о чем вы говорите - это вопросы не программирования, а проектирования. Ведь идея разделения критических/некритических модулей очевидна до безобразия.... только если сначала подумать, а потом браться за клавиатуру, а не наоборот :-) Вот есть система логирования - нужен 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 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба Датчиками являлись 3 ПЗС RGB матрицы 320х240 20fps, те входной поток около 15мбайт/c плюс покадровая обрабтка выделения и динамики перемещения объектов. Загрузка процессора 70%. На другой базе будет ИМХО сложнее. Вау!!! Да, это сильное приложение. Тут всякие мелкопоганистые ARM и близко не лежали (из тех, что можно пойти и купить как микрухи, а не из тех, что на сайте ARM описаны )Ваши последние 2 поста являются хорошим описанием РТ идеологии и инструментария фирмы "National Instrumehts" и её клонов, включая и особенности разработки подобных систем конечным пользователем. Кстати, на этой базе ( NI Labview с примочками) все и тестировалось.Я не очень знаком с NI (по прине "неправильных" цен). Но вот opalkelly мне очень понравились соотношением цены и возможностей (практического опыта работы с ними пока не имею). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба Да нет, как раз не слишком и сложно. Примерно так и работаем - получается не плохо :-) Просто то о чем вы говорите - это вопросы не программирования, а проектирования. Ведь идея разделения критических/некритических модулей очевидна до безобразия.... только если сначала подумать, а потом браться за клавиатуру, а не наоборот :-) О!!!! Это вечная проблема - вовремя "включить голову". Причем желательно когерентно - и у Заказчиков, и у финансистов, и у разработчиков.Вот ради примера - заказчику хочется видеть 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 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба Я не очень знаком с NI (по прине "неправильных" цен). Но вот opalkelly мне очень понравились соотношением цены и возможностей (практического опыта работы с ними пока не имею). На NI можно делать системы любой сложности вплоть до глобальных и с любыми интерфейсами. Тут цена железа играет меньшую роль, а цена среды разработки еще меньше. Хотя одна из штучек от opalkelly http://opalkelly.com/products/xem3010/ очень понравилась.Спасибо. Извиняюсь за оффтоп. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrew2000 0 15 июня, 2006 Опубликовано 15 июня, 2006 · Жалоба ... Почему нельзя взять простую плату, воткнуть ее в PCI ..., поставить на нее простой embedded проц с периферией ..., сделать на этом проце real time часть обработки датчиков, а всю остальную обработку ... вынести в винДазЫ. Во. Именно так иногда и делаем. Крейт от NI под WinXP а внем своя железяка и программа ввода/вывода + управление под РТОС. А когда надо совсем надежно - можно и ресет своего процессора от PCI отвязать, чтоб при перезагрузке Винды управление не срывалось, а если еще надежнее, то и отдельное питание подать. Т.е. управление отдельно, а Винда занимается сбором архивов, графики, .... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 16 июня, 2006 Опубликовано 16 июня, 2006 · Жалоба ... Почему нельзя взять простую плату, воткнуть ее в PCI ..., поставить на нее простой embedded проц с периферией ..., сделать на этом проце real time часть обработки датчиков, а всю остальную обработку ... вынести в винДазЫ. Во. Именно так иногда и делаем. Крейт от NI под WinXP а внем своя железяка и программа ввода/вывода + управление под РТОС. А когда надо совсем надежно - можно и ресет своего процессора от PCI отвязать, чтоб при перезагрузке Винды управление не срывалось, а если еще надежнее, то и отдельное питание подать. Т.е. управление отдельно, а Винда занимается сбором архивов, графики, .... И мы так постоянно делаЛИ... публикаций на эту тему не счесть, начиная с 1996 года... Отдельно интерфейс оператора на Виндовозных мультимедиа + высоконадежная железяка (Микро ПиСи со standalone Рефлексом). Дешево, надежно и сердито. ДелаЛИ (и пока еще делаем), т.к. сейчас склоняемся к тому, чтобы эти части совмещать в одном. По надежности вопросов не должно быть, ну и общее удешевление системы еще на пять-шесть килобаксов (реально, может, и до десяти). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TED17 0 16 июня, 2006 Опубликовано 16 июня, 2006 · Жалоба Короче, если вместо рефлекса взять язык G + NI RT, то получим то же самое без лишнего гемора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 16 июня, 2006 Опубликовано 16 июня, 2006 · Жалоба Короче, если вместо рефлекса взять язык G + NI RT, то получим то же самое без лишнего гемора. С языком G могут быть проблемы. Dataflow языки для описания алгоритма управления слабо подходят... Кстати, можете убедиться в этом сами, попытавшись запрограммировать на G алгоритм http://reflex-language.narod.ru/bottle/spec_bottle.htm ... Ну, а если решитесь, то очень было бы интересно взглянуть... для ориентировки - решение этой задачи на Рефлексе заняло около часа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться