Кто писал под Win CE ? Это вообще реально ?

[RX1AL]

rus013:

Уважаемый, такое заявление насчет RTOS, высказанное вами, просто неуместно, так как непонятно за какие уши притянуто. Я работаю в области Embedded Systems уже без малого лет так 17... и как-то не представлял, что всего только 2 системы имеются.

На мой взгляд, вы наверное просто не в курсе, или не знаете предмета обсуждения, но существует также VxWorks, которая широко применяется для многих гражданских и военных нужд. А также и другие RTOS, как например: SMX ARM RTOS; Atmel JBOSN High-Performance RTOS; On Time RTOS-32 где ядро всего 16 килобайт занимает и бежит спокойно на 32/64 битных х86 без проблем; тот же охаянный здесь QNX Neutrino, который сейчас одна из самых перспективных систем для автоматиации газовых установок и производства, где повышенные уровни безопасности; Microware OS-9; LinxOS на базе линуксового ядра. Таки не будем...

KulibinV:

Говоря о программировании под СЕ, необходимо сначала определить задачи и цели. То есть что надо/хотелось бы получить, а затем как. Исходники СЕ поставляются ОЕМ, но в реалиях они и не нужны. Все делается на основе конкретного SDK. Я бы посоветовал обратить свой взор сначала к выбору железа, а затем уже к СЕ или другой RTOS. Посмотрите на системы от:

1. www.kontron.com - поддерживается ХРе, СЕ и другие RTOS.
2. www.coreexpress.com - здесь найдете небольшую Embedded РС размером с кредитную карточку.

Также советую почитать что-то на тему SoC - System On Ship, RSoC - Reconfigurable System On Ship, NoC - Network On Ship (например фирма www.hilscher.com/netx.html) - семейство netХ, работает под СЕ.

Если в плане создания чего-то для цифрового трансивера или для управления им, то кое-какие наработки тоже есть.
Будут конкретные вопросаммированию или по конфигурации, готов ответить.

[rus013]

RX1AL
Да я имел ввиду оси которые свободно доступны для домашнего использования и те которые достаточно на слуху.А так я не спорю полно различных систем но они как правило не так распространены как указанные мной ОСи.

[KulibinV]

rus013:

Говоря о программировании под СЕ, необходимо сначала определить задачи и цели. То есть что надо/хотелось бы получить, а затем как. Исходники СЕ поставляются ОЕМ, но в реалиях они и не нужны. Все делается на основе конкретного SDK. Я бы посоветовал обратить свой взор сначала к выбору железа, а затем уже к СЕ или другой RTOS. Посмотрите на системы от:

1. www.kontron.com - поддерживается ХРе, СЕ и другие RTOS.
2. www.coreexpress.com - здесь найдете небольшую Embedded РС размером с кредитную карточку.

Также советую почитать что-то на тему SoC - System On Ship, RSoC - Reconfigurable System On Ship, NoC - Network On Ship (например фирма www.hilscher.com/netx.html) - семейство netХ, работает под СЕ.

Если в плане создания чего-то для цифрового трансивера или для управления им, то кое-какие наработки тоже есть.
Будут конкретные вопросаммированию или по конфигурации, готов ответить.

Второй сайт проглядел . Сколька такая материнка может стоить .
По поводу ОС - заказчит хочет , чтоб лазание по файловой системе и подключение
к сети для внешнего обмена было похоже на винду.
Разработка под промышленный контроллер .
Главный вопрос - является ли вин се действительно RTOC ,
то есть какова вероятность (минус какая степень в час), что эта ОС
не подзависнет и возникнет задержка реакции на прерывание .
Можно ли на материнки со второго сайта поставить вин се (похоже , что да)?
Из первых вопросов :Насколько сложно залить в эту материнку ос до состояния
"картинки на экране и работы клавиатуры " (в моем понимании это первый и
самый сложный этап ,
дальше чуть попроще)?

[RX1AL]

Для KulibinV:

По заданным вопросам. Давайте мы с вами переведем наше общение на более понайтный, профессиональный язык. Мне так будет проще понять задачу или ее постановку. Потому как обычно пляшут от требований, а-ля спецификация, а уж потом нарисовывается и все остальное... Насчет того, что заказчик хочет, чтобы "лазание по файловой системе" было похоже на винду. Да за ради бога! Какой интерфейс ему сделаете, так и будет. Но об этом еще рано. Отсюда по пунктам:

1) Что за промышленный контроллер? Какие протоколы должны поддерживаться: EtherCAT, CANbus, CANopen, I2C, S7, Fieldbus, Modbus - что конкретно?
2) Какова должна быть минимальная частота опроса сенсоров/датчиков и другого оборудования, так как я понимаю, что вам неоходимо иметь Data Aquisition (систему сбора данных)? Время реакции также важно.

Исходя из требований к системе и ее параметрам и выбирается та или иная система RTOS - не ранее. Потому, что говоря о СЕ, да система реального времени, но для определенных задач и уровня применения.

Не совсем понятно, что значит "файловой системы" - какая там может быть задача в плане "ползать", да еще в реальном времени? Не совсем я уловил. Так как любая файловая система в любой системе, никогда не поддерживает режим реального времени в том понятии, которым он является - так как операция с файлами чтение/запись всегда квази-реальное время, даже если операции производятся синхронно. Исключением является запись на специальные носители информации типа SSD или Dual Port Flash, но там нет никакой файловой системы - совершенно иной принцип.

В сути своей, поставьте задачу, я тогда смогу поточнее вам ответить. А что касается ответа на вопрос о стоимости контроллера с кредитную карточку, то всего 290 евро стоит кит вместе с SDK под СЕ 6.0.

И по СЕ. Сама система очень стабильна. За многолетнюю практику сама ни разу не сыпалась. Если у программистов руки не из одного места растут, то все ОК...

Добавлено через 4 минуты
Залить не сложно, гораздо сложнее создать SDL (системно-независимый лайер), оттестировать все времменые последовательности и переходы и програнть стресс-тест. А прошивка системы - дело двух-пяти минут. То есть понимание задачи и умение писать под систему - сиречь главная сложность.

[KulibinV]

1) Что за промышленный контроллер? Какие протоколы должны поддерживаться: EtherCAT, CANbus, CANopen, I2C, S7, Fieldbus, Modbus - что конкретно?

RS485 (можно RS232, преобразователь есть), рассматриваются также варианты CAN и USB.

2) Какова должна быть минимальная частота опроса сенсоров/датчиков и другого оборудования, так как я понимаю, что вам неоходимо иметь Data Aquisition (систему сбора данных)? Время реакции также важно.

4 канала быстрых -частота опроса 1 кГц , при этом повторный запрос при ошибке CRC
через 50E-6 [c] , время обратного ответа с вычислительной обработкой - 250E-6 [c].
Разрядность -20 бит +CRC.
Данные опроса полностью не сохраняются , сохранению в файл ошибок подлежат лишь превышения
с меткой времени (примерно раз в час ).
16 каналов медленных (логических 0-1)- частота опроса 20 Гц , время ответа50У-3 [c].
Данные опроса полностью не сохраняются , сохранению в файл ошибок подлежат лишь превышения
с меткой времени (примерно раз в час ).

Исходя из требований к системе и ее параметрам и выбирается та или иная система RTOS - не ранее. Потому, что говоря о СЕ, да система реального времени, но для определенных задач и уровня применения.

Не совсем понятно, что значит "файловой системы" - какая там может быть задача в плане "ползать", да еще в реальном времени? Не совсем я уловил. Так как любая файловая система в любой системе, никогда не поддерживает режим реального времени в том понятии, которым он является - так как операция с файлами чтение/запись всегда квази-реальное время, даже если операции производятся синхронно. Исключением является запись на специальные носители информации типа SSD или Dual Port Flash, но там нет никакой файловой системы - совершенно иной принцип.

Задача частично похожа на обращения к двухпортовой памяти .
Сначала (не в реальном масщтабе времени) берется файл исходных данных (точнее, открывается для чтения
и считывается в ОЗУ некоторая его часть ),
производится его интерполяция и запись в програмный кольцевой буфер (аналог двухпортовой памяти) с указателем наполнения . когда буфер наполнен до некоторого значения , начинается работа в прерываниях
в реальном масштабе времени . Кольцевой буфер ограничен , производится его подкачка(включая считывание
в из файла очередного фрагмента для обработки). Это низкоприоритетная задача. При этом обработчик прерываний берет ближайшее в очереди значение и
сдвигает указатель заполнения на 1 , давая возможность подкачивать буфер .
Информация о текущем состоянии выводится на экран оператору .

Собственно из за необходимости удобного для пользователя поиска и открытия файла данных
и отображения промежуточных результатов на экран оператору ориентировался на CE.
Потенциальные входные носители в порядке важности: USB флаш , жесткий диск , сеть , 3.5' дискета,
оптический диск . " Верхиий" формат данных на сменных носителях - совместимый с виндой .

В сути своей, поставьте задачу, я тогда смогу поточнее вам ответить. А что касается ответа на вопрос о стоимости контроллера с кредитную карточку, то всего 290 евро стоит кит вместе с SDK под СЕ 6.0.

И по СЕ. Сама система очень стабильна. За многолетнюю практику сама ни разу не сыпалась. Если у программистов руки не из одного места растут, то все ОК...

Речь не о глобальном зависании системы (процессора , моста и др.).
Обсуждается вероятность " подзависания " , то есть единичной сверхнормативной задержки
реакции на прерывание .

Добавлено через 4 минуты
Залить не сложно, гораздо сложнее создать SDL (системно-независимый лайер), оттестировать все времменые последовательности и переходы и програнть стресс-тест. А прошивка системы - дело двух-пяти минут. То есть понимание задачи и умение писать под систему - сиречь главная сложность.

возможно я не совсем в теме и терминологии , но предвижу сложность в перекомпиляции
аппаратно зависимой OC под материальную часть и загрузку её на носитель , с которого она потом
в месте установки будет грузится .

[RX1AL]

RS485 (можно RS232, преобразователь есть), рассматриваются также варианты CAN и USB.

...[SKIP]...

ОК, с этим ясно. По сути своей нормальный Modbus или Profibus. Теперь по параметрам, у меня уже есть кое-какие вопросы... так как не все гладко... Смотрим: "4 канала быстрых -частота опроса 1 КГц , при этом повторный запрос при ошибке CRC
через 50 микросекунд , время обратного ответа с вычислительной обработкой - 250 микросекунд".

То есть датчики опрашиваются с частотой 1 КГц = 1 мс, и при этом мы хотим получить ответ датчика через 50 мкс. Хорошо! Примем на веру, что есть такой быстродействующий датчик, и зададимся вопросом: почему частота поллинга датчиков выбрана меньшей, чем время ответа? Какой резон? Никакого. Датчик будет простаивать 90% времени - это раз, а два, как раз тут и начинаются подводные камни с синхронизацией низкой частоты поллинга с быстродействующими датчиками. Почему камни или грабли? Очень просто: простая ситуация - на момент времени Т0 производится чтение данных датчика 20 бит + CRC, при этом время на чтение, согласно спецификации - 50 мкс. А у нас цикл в 1 мс. То есть на момент времени Т0 + 50мкс по логике, мы должны иметь уже готовый ответ от датчика и далее система должна с ним что-то сделать, скажем вычисления или вывод на дисплей. Моменты тут такие:

а) Любой датчик, а у нас RS-485 - имеет handshake. Это время нигде не учитывается. Почему? Даже, если мы будем оперировать с датчиком при скорости 8 kbps (самой низкой), то время для handshake будет значительно выше, чем 50 мкс. И практикой докзано.
б) У нас не один датчик, а много. Соответственно наш 1 КГц или 1 мс надо поделить на их количество для одного канала (все остальные каналы идентичны), то есть имеем 1 мс / N датчиков и получаем реальное Т для поллинга по всем датчикам. Это и есть наш основной цикл. При этом учитываем, что время сбора данных Т2 со всех N датчиков равно N * 50 мкс. Плюс учет самого handshake также принимаем во внимание.
в) Также отсюда мы находим время Т1 для реакции самой системы, ввод/вывод, вычисления и так далее. Это надеюсь понятно. Вот это время и есть наш камень преткновения.

Попробуйте, смоделировав вашу временную диаграмму (sequence diagram) в любом бесплатном редакторе UML-RT, подсчитать реальное время и вы сами все это увидите. Если пришлете мне такую диаграмму, готов разобрать ее по "косточкам" и дать рекомендации. Ссылки на редакторы:

www.magicdraw.com
www.visual-paradigm.com

Что ещё вызывает вопросы, так что такое "с меткой времени"? Откуда она берется, если у вас датчик гарантированно должен отдать свой ответ в 50 мкс или в 250 мкс, если ошибка CRC. И низкий опрос в 20 Гц при времени ответа в 50 мс? Как это согласуется? Есть теорема Котельникова о частоте дискретизации, и на практике обычно берут 4 или 6 раз выше, чтобы учесть всё. В реальных системах сбора информации, по RS-485, обычно используется 4-х кратное увеличение частоты поллинга, для того, чтобы в случае невозможности получить данные от датчика иметь возможность так называемых повторных запросов - retry. И только в случае полной невозможности такой датчик маркируется, как non-responding, оператору выдается соответствующий alarm или просиходит автоматическое переключение на дублирующий датчик, в случае full redundant и fault tolerant системы.

Про файловую систему мне все понятно. Это уже не относится к самому процессу поллинга и сбора информации. С такой задачей справится любая мультизадачная ОС.

Под вашу задачу могу рекомендовать несколько устройств, которые мы сами тоже используем, подумайте, может не стоит слишком заморачиваться и взять готовое решение, а к нему лишь дописать весь графический интерфейсный с выводом данных по мониторингу? Ссылки я привожу ниже:

а) www.infocon-technology.com - EasyIO-30Р контроллер сбора по RS-485. Мы его используем именно под СЕ .NET 6.0. Нужен будет готовый написанный стек под Modbus для СЕ - пришлю на приватный е-майл.

б) http://www.exar.com/Common/Content/P...ils.aspx?ID=18 - Exar XR19L400 или XR16L580 может вас заинтересует, так на сегодняшний день эта фирма лидер по таким решениям. Для СЕ у них есть (да и у меня тоже) весь SDK.

По поводу перекомпиляции. Не сосвем вы меня поняли. Вы создаете свою системно-независимую модель (безо всякой оглядки на RTOS) в терминах UML-RT и SDL. Потом эту модель компилируете (смотрите на Executable Modeling UML-RT) и получаете код на языке, который вы выбрали и также WCET (Worse-Case Execution Time) для своей модели. В случае СЕ - С++ или С. Далее этот исходный код просто компилируете в СЕ вместе с SDK для своего железа. И полученный модуль прожигаете или записываете на нужный носитель. Изменилась что-то - меняете только модель UML-RT и все.

Жду комментариев. Если не возражаете, можем все перенести в личню почту, не знаю насколько темя актуальна для радиолюбителсьтва? А то модераторы "фэ" могут сказать...

[KulibinV]

ОК, с этим ясно. По сути своей нормальный Modbus или Profibus. Теперь по параметрам, у меня уже есть кое-какие вопросы... так как не все гладко... Смотрим: "4 канала быстрых -частота опроса 1 КГц , при этом повторный запрос при ошибке CRC
через 50 микросекунд , время обратного ответа с вычислительной обработкой - 250 микросекунд".

То есть датчики опрашиваются с частотой 1 КГц = 1 мс, и при этом мы хотим получить ответ датчика через 50 мкс. Хорошо! Примем на веру, что есть такой быстродействующий датчик, и зададимся вопросом: почему частота поллинга датчиков выбрана меньшей, чем время ответа? Какой резон? Никакого. Датчик будет простаивать 90% времени - это раз, а два, как раз тут и начинаются подводные камни с синхронизацией низкой частоты поллинга с быстродействующими датчиками. Почему камни или грабли? Очень просто: простая ситуация - на момент времени Т0 производится чтение данных датчика 20 бит + CRC, при этом время на чтение, согласно спецификации - 50 мкс. А у нас цикл в 1 мс. То есть на момент времени Т0 + 50мкс по логике, мы должны иметь уже готовый ответ от датчика и далее система должна с ним что-то сделать, скажем вычисления или вывод на дисплей. Моменты тут такие:

а) Любой датчик, а у нас RS-485 - имеет handshake. Это время нигде не учитывается. Почему? Даже, если мы будем оперировать с датчиком при скорости 8 kbps (самой низкой), то время для handshake будет значительно выше, чем 50 мкс. И практикой докзано.
б) У нас не один датчик, а много. Соответственно наш 1 КГц или 1 мс надо поделить на их количество для одного канала (все остальные каналы идентичны), то есть имеем 1 мс / N датчиков и получаем реальное Т для поллинга по всем датчикам. Это и есть наш основной цикл. При этом учитываем, что время сбора данных Т2 со всех N датчиков равно N * 50 мкс. Плюс учет самого handshake также принимаем во внимание.
в) Также отсюда мы находим время Т1 для реакции самой системы, ввод/вывод, вычисления и так далее. Это надеюсь понятно. Вот это время и есть наш камень преткновения.

Попробуйте, смоделировав вашу временную диаграмму (sequence diagram) в любом бесплатном редакторе UML-RT, подсчитать реальное время и вы сами все это увидите. Если пришлете мне такую диаграмму, готов разобрать ее по "косточкам" и дать рекомендации. Ссылки на редакторы:

www.magicdraw.com
www.visual-paradigm.com

Под вашу задачу могу рекомендовать несколько устройств, которые мы сами тоже используем, подумайте, может не стоит слишком заморачиваться и взять готовое решение, а к нему лишь дописать весь графический интерфейсный с выводом данных по мониторингу? Ссылки я привожу ниже:

а) www.infocon-technology.com - EasyIO-30Р контроллер сбора по RS-485. Мы его используем именно под СЕ .NET 6.0. Нужен будет готовый написанный стек под Modbus для СЕ - пришлю на приватный е-майл.

б) http://www.exar.com/Common/Content/P...ils.aspx?ID=18 - Exar XR19L400 или XR16L580 может вас заинтересует, так на сегодняшний день эта фирма лидер по таким решениям. Для СЕ у них есть (да и у меня тоже) весь SDK.

По поводу поллинга . Насколько мне известно , поллинг - это тупое ожидание
ответа .
Система управления через 1Е-3 выставляет (трансмит для неё (хоста)) свои данные на датчики
(адресуемые контроллеры датчиков) по очереди , после чего они с очень небольшой
задержкой выставляют (ресив для СУ (хоста)) ответ (заранее подготовленные данные) .
Линии на прием и передачу
раздельные. СУ "на лету" проверяет CRC каждого датчика или либо делает повторный
запрос при несхождении CRC (короткая короткая ветвь обработчика прерываний RS),
либо при схождении CRC всех ответов начинает математическую обработку результатов
(длинная ветвь обработчика прерываний RS).
При этом повторный запрос в случе несхождения CRC датчика должен быть отправлен
не более чем через 50E-6 [с] , а полная математическая обработка должна быть закончена
(и данные выставлены на контроллеры датчиков) через 250E-6 [с] . Если контроллер любого датчика
обнаруживает несхождение CRC , он выставляет запрос на повторную выдачу ему (только) данных.
Повторные данные должны быть выставлены не более чем через 50E-6 [с] . Варианты двухкратного
несхождения CRC не рассматриваются , в этом случае вырабатывается аппаратный сигнал
аварийного завершения (выставляются на другой COM , LPT порт или другую дискретную периферию ).

Поскольку 250E-6 [с] + 50E-6 [с] (одна ошибка приема)+ 50E-6 [с] (одна ошибка передачи) = 350E-6 [с]
более чем в 2 раза меньше чем время цикла СУ , теорема Котельникова удовлетворена и уровень
низкочастотных "биений" незначителен . Так как за 350E-6 [с] нужно передать в худшем
случае 80 байт , то потребная скорость обмена 228.6 [ kB/s] . У стандартных " мамок" бывают 250 [ kB/s],
я на контроллерах на эту скорость программы писал , работало чисто .

Что ещё вызывает вопросы, так что такое "с меткой времени"? Откуда она берется, если у вас датчик гарантированно должен отдать свой ответ в 50 мкс или в 250 мкс, если ошибка CRC. И низкий опрос в 20 Гц при времени ответа в 50 мс? Как это согласуется? Есть теорема Котельникова о частоте дискретизации, и на практике обычно берут 4 или 6 раз выше, чтобы учесть всё. В реальных системах сбора информации, по RS-485, обычно используется 4-х кратное увеличение частоты поллинга, для того, чтобы в случае невозможности получить данные от датчика иметь возможность так называемых повторных запросов - retry. И только в случае полной невозможности такой датчик маркируется, как non-responding, оператору выдается соответствующий alarm или просиходит автоматическое переключение на дублирующий датчик, в случае full redundant и fault tolerant системы.

Про файловую систему мне все понятно. Это уже не относится к самому процессу поллинга и сбора информации. С такой задачей справится любая мультизадачная ОС.

По поводу метки времени . Когда начинает работать часть программы в прерываниях , "верхняя " программа
создает на диске файл ошибок (название состоит из названия исходного файла данных + закодированоо время
из часов компьютера ) Если происходит превышение значение датчика (точнее ,его производной, вычисленной
как разность соседеих значений) , в файле делается запись , состоящая из № датчика, аномального значения,
времени из часов компьютера и символа разделителя .Если таких значений много подряд, избыток выкидывается.
По завершению обработки файл закрывается , последняя запись = время окнчания .

4 раза по Котельникову жирно будет , 2.5 вполне достаточно .

Дублирующих датчиков нет (вернее их функции выполняют редко опрашиваемые аварийные датчики).

По поводу перекомпиляции. Не сосвем вы меня поняли. Вы создаете свою системно-независимую модель (безо всякой оглядки на RTOS) в терминах UML-RT и SDL. Потом эту модель компилируете (смотрите на Executable Modeling UML-RT) и получаете код на языке, который вы выбрали и также WCET (Worse-Case Execution Time) для своей модели. В случае СЕ - С++ или С. Далее этот исходный код просто компилируете в СЕ вместе с SDK для своего железа. И полученный модуль прожигаете или записываете на нужный носитель. Изменилась что-то - меняете только модель UML-RT и все.

Жду комментариев. Если не возражаете, можем все перенести в личню почту, не знаю насколько темя актуальна для радиолюбителсьтва? А то модераторы "фэ" могут сказать...

Здесь я кажется "поплыл" . Я полагал , что надо перекомпилировать под матчасть ОС (CE 6) и загрузить
её , чтоб экран "светился" . Потом думал создать приложение "верхнего софта" (на чем нибудь
типа С++ билдер) , скомпилировать и поставить на матчасть . Затем изголится , написать перехватчики прерываний таймера и RS и вкрячить их как резеденты (как под ДОС).

Пока обсуждало более 2х человек . Думаю , можно оставить как общую .
Если остальные отпадут , перенесем в приват .

[RX1AL]

Для KulibinV:

ОК. Я прочитал все. Сегодня уже отвечать подробно не буду, просто только с остатков теста CQ WW CW вернулся с ОЕ9 (весь никакой) ... напишу завтра.
Только несколько моментов отмечу:

а) Поллинг - не всегда понимается, как пассивный опрос. Сейчас просто этим термином часто называют Publish Subscribe с гарантированной доставкой данных от датчика. Аналогия, чтобы понять смысл работы такой схемы смотрите по OLE for Process Control (ОРС). И более подробно здесь: www.opcfoundation.org

б) Вот уж чего бы я не советовал, так писать на уровнях прерываний. Почему? Да ответ простой. В системах типа СЕ или ХРе вы не всегда сможете взять себе высокий приоритет над ними. И мучений сие доставляет очень много. Поверьте на слово, зубы я уже на этом съел. Потому и придумали способ (см. выше через ОРС). Мы же все-таки работаем с сом, а не чисто с железом, да и не ассемблере, где все гораздо проще. И не в ДОС, где прерывания перехватываются на ура. А в виндовой системе или СЕ, так на ура не получится... Ну нет там наших любимых демонов, которых можно в фоновом режиме запускать...

Дальнейшее завтра. В принципе мне задача более-менее стала понятна. Можно сесть и писать на основе готовой базы.

[DL8RCB]

Можно сесть и писать на основе готовой базы.

Mike ,ты мне aprs/ce подправь, чтобы кажный раз установки не вводить
Danke,73

[RX1AL]

Для DL8RCB:

Толя, да подправлю... без проблем. Дай мне из Radfeld (Tirol) с одного проекта, который мы заканчиваем там, к 12-15 декабря в Линц перебраться и там пожалуйста. А то замучали буржуи окаянные... Неймется им под новый год новый проект начать, а носу уже адвент и вайнахтен. Ну не идиоты ли?

[DL8RCB]

Неймется им под новый год новый проект начать, а носу уже адвент и вайнахтен. Ну не идиоты ли?

как говаривал Мао: райзе пасс, райзе пасс,..... але брудэр, одер вас?

[RX1AL]

Для KulibinV:

Перейдем к нашим баранам... Начнём с самого контроллера (или PLC, как его называют). Данный контроллер, как было уже сказано имеет "4 канала быстрых" и "16 каналов медленных" (цифровых), поскольку имеем дело с 0 или 1. Все живёт под интерфейсом RS-485. Первый вопрос для вас, который вы должны для себя решить и понять - это то, что если вы собрались использовать СЕ, то контроллер должен иметь поддержку СЕ также. То есть, как минимум драйвер или лучше всего полноценный SDK. Есть уже у вас конкретный тип от заказчика, или вы свободны в своем выборе? Если последнее, то здесь есть уже готовые типы. Едем далее. Данный контроллер должен иметь либо Flash, SD карту или мини жесткий диск (в зависимости от типа исполнения контроллера), где собственно будет располагаться часть ПО для контроллера. В терминах автоматизации - это хост (Host). Таких хостов будет столько, сколько у вас в системе предусмотрено контроллеров. При этом каждый хост имеет свой уникальный UID (идентификатор хоста), для того, чтобы однозначно знать от какого контроллера "прилетели" данные. Основное приложение (Client), которое вы будете использовать для визуализации, обработки и.т.д. своих данных, "подписывается" на данные от каждого хоста, то есть устанавливается протокол Publish-Subscribe. Он может быть как Queued, если данные имеют какой-то приоритет в обработке , так и нет, когда приоритет не важен. Другими словами, наше клиентское приложение должно создать N "слушателей" (Listener) для каждого канала хоста. И каждый такой listener будет реагировать только на данные, которые адресованы ему. Поскольку у нас нет прерываний в "чистом" виде (мы не в ДОС), я писал уже, то хост выдает нам данные событийно (Events). Соответственно каждый наш listener (по сути объект или класс на С++) реагирует на определенный event и что-то делает, согласно логике обработки аргументов по данному event. Для организации такой модели взаимодействия, как я писал служит ОРС. В случае, если у вас будет наличие стека TCP/IP, то в этом случае задачу можно решить более просто - через мониторинг пакетов по каждому сокету от хоста. Но в любом случае, ваше клиентское приложение лишь реагирует на события (events). Итак мы подошли к тому, что нам необходимо написать две части нашего софта: а) серверную (хост) и б) самого клиента. Я упоминал ранее про SDL. Именно эта часть является наиболее ответсвенной. Ее реализуют на основе стандарта IEC 61499, который полностью отвечает протокол Publish-Subscribe и имеет множество дополнительных возможностей. Подробнее, если не знакомы:

а) http://www.fiord.com/news/new_list/new_32.html - искал что-то на русском и подоступнее.
б) http://www.microns.org/12.0.html - собственно пример реализации именно SDL на основе IEC 61499.

Когда вы создали и оттестировали всю свою модель SDL (UML-RT), то для вас наступает самый интересный момент - программирование контроллера, заливка в него софта. Делается это Boot Loader для JTAG, прямо по коду той скомпиленной модели. Ну а далее берется SDK, VS 2005/2008 и начинается написание собственно клиентской части и визуального контроля и интерфейса. Вот так, более-менее. По конкретике и написанию готов помочь, но не все 100%... ибо также на проектах занят. Но в любой части, как хоста, так и клиенсткой. Что нужно? Нужна лишь правильно описанная диаграмма переходов (Sequence diagram) и модель SDL. Все остальное дело техники. Библиотека визуальных контролей уже имеется под СЕ. Да и интерфейсы тоже. С этим никаких проблем нет.

Жду вестей с фронта...

ПЫСЫ: Не надо так много оверквотинга... Я свой текст знаю, а в вашем найду все сам. Иначе не совсем удобно читать. Ну фидошник я старый...

Добавлено через 28 минут

как говаривал Мао: райзе пасс, райзе пасс,..... але брудэр, одер вас?

[Оффтопик]

Толя, согдня навеяло картиной в "Media Markt". Так сказать лирическое отступление на тему тупости или глупости... уж как хочешь, так и назови. Надо конечно в раздел анекдотов, но такой австрийский юмор будет не всем понятен... Итак (с) "картина маслом":

"Длинная-длинная очередь на входе... Вы думаете их тут не бывает? Ай, как вы заблуждаетсеь, Абрам..." - иду с женой далее и вижу следующее: примерно человек так 50-60 стоит в зале у столба из картонных нехилого размера, сваленных на палетте, а рядом стоит молодой феркойфер (продавец) и втюхивает что-то как обычно, размахивая проспектом. Ну думаю, надо мимо пройти. Жена, давай типа посмотрим. Ну встали. Короче идет раздача слонов, а именно телевизора LCD от Medion (ну про качество сей фирмы ты в курсе!). Короче раздают за 200 с чем-то евро, а размерчик королевский 42". Не хило так. Ну думаю, а где подвох-то? Нормально так такие телики стоят за штуку. И он нашелся, но не сразу... Короче написано контраст 800:1. Стоит демострационный телик и на нем при нормальном свете, что-то такое на экране движется... Но главное нифига не видно, даже при регулировке яркости и контраста. Я в недоумении. Вопрос на немецком к продавцу: "Почему не видно нифига?" Ответ: "Отбракованная партия,ому и дешево". Ага, думаю, мне нафиг не надо! И тут стоит в толпе один чел, ну с очками где диоптрии я так думаю -12... и выдает в толпу... обращаясь к продавцу... сидеть надо на стуле... иначе геферлих (смертельно): "Хей, я уже оплатил 7 штук, почему мне их не отгружают!" Тот ему "Да-да, херр Гридах, сейчас, сейчас!" И тут я не удержался и спросил этого в очках, а ему так лет под 60-65 наверное: "Зачем так много? Тем более на них ничего не видно и разве только на запчасти... Да и вашему зрению хуже будет." Теперь сам ответ от чела: "Мне будет плохо??? С чего? Я итак уже ничего не вижу! А телики для моей семьи! Пусть семья видит, и не говорит, что дедушка слеп, как крот!" Вот так у нас живут... Тут хочется лишь сказать, но по-немецки: "Virklich? Virklich? Od' wie?" ... О tempera, o mores...

А ты про паспорт... Мелко!

Добавлено через 38 секунд

как говаривал Мао: райзе пасс, райзе пасс,..... але брудэр, одер вас?

[Оффтопик]

Толя, согдня навеяло картиной в "Media Markt". Так сказать лирическое отступление на тему тупости или глупости... уж как хочешь, так и назови. Надо конечно в раздел анекдотов, но такой австрийский юмор будет не всем понятен... Итак (с) "картина маслом":

"Длинная-длинная очередь на входе... Вы думаете их тут не бывает? Ай, как вы заблуждаетсеь, Абрам..." - иду с женой далее и вижу следующее: примерно человек так 50-60 стоит в зале у столба из картонных нехилого размера, сваленных на палетте, а рядом стоит молодой феркойфер (продавец) и втюхивает что-то как обычно, размахивая проспектом. Ну думаю, надо мимо пройти. Жена, давай типа посмотрим. Ну встали. Короче идет раздача слонов, а именно телевизора LCD от Medion (ну про качество сей фирмы ты в курсе!). Короче раздают за 200 с чем-то евро, а размерчик королевский 42". Не хило так. Ну думаю, а где подвох-то? Нормально так такие телики стоят за штуку. И он нашелся, но не сразу... Короче написано контраст 800:1. Стоит демострационный телик и на нем при нормальном свете, что-то такое на экране движется... Но главное нифига не видно, даже при регулировке яркости и контраста. Я в недоумении. Вопрос на немецком к продавцу: "Почему не видно нифига?" Ответ: "Отбракованная партия,ому и дешево". Ага, думаю, мне нафиг не надо! И тут стоит в толпе один чел, ну с очками где диоптрии я так думаю -12... и выдает в толпу... обращаясь к продавцу... сидеть надо на стуле... иначе геферлих (смертельно): "Хей, я уже оплатил 7 штук, почему мне их не отгружают!" Тот ему "Да-да, херр Гридах, сейчас, сейчас!" И тут я не удержался и спросил этого в очках, а ему так лет под 60-65 наверное: "Зачем так много? Тем более на них ничего не видно и разве только на запчасти... Да и вашему зрению хуже будет." Теперь сам ответ от чела: "Мне будет плохо??? С чего? Я итак уже ничего не вижу! А телики для моей семьи! Пусть семья видит, и не говорит, что дедушка слеп, как крот!" Вот так у нас живут... Тут хочется лишь сказать, но по-немецки: "Virklich? Virklich? Od' wie?" ... О tempera, o mores...

А ты про паспорт... Мелко!

[KulibinV]

Похоже , мы друг друга слабо понимаем . Под контроллером датчика я понимаю устройство , которое
обеспечивает преобразование специфичного и явно не воспринимаемого компьютером интерфейса датчика,
их 4 (+ один для дискретных сигналов, на некоторых видах матчасти хоста (СУ), например платформах
фирмы моторола , дискретная периферия может быть заведена прямо на процессор, только "кит" под неё
стоит 4'500 евров, а сделать свою плату поблематично , так как там бол грид аррай с шагом 0.5 мм).
Под хостом я понимаю СУ (выполненную на компьютере под СЕ ), она одна .


Контроллер датчика специфичный , СЕ на него точно не поставишь .
В протоколе (последовательность байт в посылке , коды запросов) обмена я свободен .
ПО контроллера хранится в нем самом , на внутренней ЭППЗУ (флеш). Оно автоматически
загружается (устанавливается на начальный адрес ) при подаче питания или после сброса внешним
или собственным (по отсутствию активности в течении некоторого времени) аварийным ресетом .
Заливка новых версий софта контроллера осуществляется по джитег , процесс отработан .

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

ЗЫ по поводу деда , это серьезно ?

[ER1MF]

Главный вопрос - является ли вин се действительно RTOC ,
то есть какова вероятность (минус какая степень в час), что эта ОС
не подзависнет и возникнет задержка реакции на прерывание .

Зная мелкософт я бы не стал с этим связываться...

P.S. Летел я как то самолетом - там пасажирская развлеклка была сделана на мелокософте, правда не помню это была СЕ или мобайл - висла и блускринила постоянно...

[RX1AL]

Для KulibinV:

Нет, мы нормально понимаем друг друга. По крайней мере, я читаю и вижу то, что вы пишете... "Под контроллером датчика я понимаю устройство , которое
обеспечивает преобразование специфичного и явно не воспринимаемого компьютером интерфейса датчика..." Стоп! Первый вопрос: что значит не вопринимаего компьютером интерфейса, если в самом начале речь шла об RS-485? Кажется мне, что RS-485 стандартный интерфейс, вопринимаемый компютером. Второе, я подразумеваю под контроллером именно PLC, не более, ни менее, который загружается по JTAG. То есть с этим все в порядке. "Контроллер датчика специфичный , СЕ на него точно не поставишь" - да и не надо на него-то СЕ ставить! СЕ будет с ним работать и брать от него лишь данные! Надеюсь, у вас контроллер не "глухой", то есть под него, по крайней мере через драйвер достучаться можно? Если драйвер контроллера есть, то на СЕ лишь пишется сама клиентская часть. И наконец, нету понятия драйверов верхнего или драйверов нижнего уровня... Есть один драйвер - драйвер контроллера, или на худой конец API, по функциям которого контроллер будет чего-то отдавать или делать у себя внутри. Если, как вы пишете, у контроллера есть свое ПО, то простите, как вы с ним сейчас общаетесь? Явно же за какие-то внутренние функции дергаете. Теперь о СЕ еще раз. Ей, то бишь СЕ абсолютно по барабану, что у вас за контроллер... ей нужно знать через драйвер, API, SDK, как добраться до внутренностей контроллера и "спросив" его о чем-то, получить ответ. Не более. А уж как вы будете сей ответ интерпретировать, дело ваше. И на контроллер не влияет. У вас есть описание самого контроллера, можете тип, API выложить? И задача уперлась в написание системы взаимодействия... я вам писал про ОРС - вы прочли, разобрались? Именно так с большинством контроллеров мы работаем. Кроме того, вы писали, что у вас есть возможность конвертировать RS-485 -> RS-232. Господи, да тогда любая обработка данных с такого интерфейса пишется на любом языке за 3-4 дня по уму. Надо через USB, так конвертер RS-485 -> USB делается на паре микросхем за два часа на макетке и используется стандартный драйвер. Готовых промышленных навалом.

И задача сводится к двум этапам:

1) Раз вы свободны в плане протокола, так и опишите его так, чтобы СЕ поняла. Сведите все к обычному сериал протоколу. И зажгите в контроллер.
2) А далее садитесь и пишите само клиентское ПО на СЕ.

Нужна библиотека для СЕ под RS-485, написання на С++ под "чистый" СЕ и есть С для .NET версии.

ПЫСЫ: По поводу дедуни, хера Гридаха... да, вполне серьезно... я от хохота плакал... Ну бывают у нас такие вот "кадры".

Для ER1MF:

"Зная мелкософт..." - хочется спросить "зная как"? Как пользователь, или как программист? Посему, считаю, заявление ваше ну совершенно неуместным. Хаить можно все, что по каким-то причинам не работает... и часто причины эти от наших "кривых ручек"... случаются. А если как программист, то давайте приведите мне аргументы, что там с мелкомягкими не так. А заявления типа ОБС я не люблю... не солидно.

Для тех, кто летает в самолете... Ну гнать на мелкомягких мы гоним... Но дома-то не линукс на своем домашнем РС в основном пользуем. А? Тем более игр для детей на нем не особо найдешь... Так что...

Добавлено через 1 час 23 минуты
Для KulibinV:

Вот нашел в архиве на компе статейку, которая вам поможет понять, что такое поллинг и как должно быть организовано взаимодействие между вашим контроллером(ами) и клиенской частью на СЕ. Код на С++ и все подробно разжевано. Но это лишь, как отравная точка. Будут вопросы, я здесь...

PS Админам: Будьте любезны, поправьте что-нибудь в авших скриптах для аплоада вложений... Уж больно часто скрит зависает даже на маленьких файлах. В топике "Про баги" писалось не только мной, но пока ответа нет...