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

О-о-о-о! Прошу прощения за задержку с ответом : ) 1. Посмотрел на документацию, и в п. 2.5.4. и в п. 2.5.5. указано "от 0 до 0xFFFFF". 2. Последним установит вход процесс, описанный позже. 3. Отсутствие циклов было вызвано потребностью конструктивно обеспечить невозможность зависания... на практике, понятно, необходимость в циклах возникает, редко, но все-же, циклы реализуются в подпрограммах (функциях). 4. По запуску в активном состоянии находится только первый процесс (описанный первым), все остальные процессы находятся в пассивном состоянии. 5. ТАКТ един для всех процессов, но, есть проработка того, как такты для процессов устанавливать индивидуально. Кстати, сейчас появился еще один процесс-ориентированный язык -- IndustrialC, ориентированный на программирование микроконтроллеров. На нем уже выполнено несколько проектов, если загуглить, то на статьи об IndustrialC можно легко. Еще раз тысячу извинений за задержку с ответом.

Вот я и говорю, что ни человек, то свое мнение по поводу ОС РВ... И как это во встраиваемых системах Виндовоз используют и Линукс... хоть кол им на голове чеши, не убедишь QNX изучить... Кстати, "многозадачные ОС" это широко распространенный термин. Разночтений не вызывающий. В отличие от РВ, например, именно попытка определить ОС РВ испортило напрочь впечатление от весьма неплохого текста http://citforum.ru/operating_systems/sos/glava_3.shtml Что же касается исходной темы, то как мне представляется, дело тут не в алгоритмах планирования (весьма неказистых, если судить по названиям: FIFO, RoundRobin и проч.), а именно в возможности поддерживать параллелизм на уровне задач, в наличии планировщика. Имеется ввиду threads? какие еще потоки? thread в переводе с английского это нить, а не поток... единственно, что можно сказать по этому поводу, что англоязычная терминология не продумана, а русскоязычные пользователи при переводе еще больше запутали все дело... нет, чтобы просто сказать, main-thread (главная нить), как выделенная нить (thread)... так нет, вводятся какие-то процессы... а наши программисты thread еще как поток переводят... а как они "stream" переводят? Все это очень грустно... Это не вопрос эквивалентности, а вопрос последовательности при постановке проблемы. Ну, все-таки было бы логично сначала ответить на вопрос "а нужен ли планировщик вообще?"... и если вдруг окажется, что нужен, только тогда уже задаваться вопросом "а какой же планировщик тут нужен?"... С FIFO, RoundRobin-ом или с каким-нибудь действительно экзотическим алгоритмом планирования... Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.

Так. Раньше было "ОС РВ -- это QNX"(или что-то такое), теперь уже "ОС РВ -- это стандарты POSIX..." В принципе, достаточно конструктивно, только я бы не концентрировался на POSIX. Как Вам такое определение: "ОС РВ -- это ОС с планировщиком задачи", или просто "многозадачная ОС"? Тогда и тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет. Или, другими словами, в каких задачах нам нужен многозадачный параллелизм, а в каких многопоточный. И сразу к ответу приблизимся.

Теперь стало понятно, что под поллингом подразумевается в POSIX, это вполне сочетается с моим пониманием, но проблема в том, что это не единственное определение поллинга. Поэтому, как мне представляется, это слово лучше вообще не употреблять. Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще? Увы, я встречал только попытки дать определения... К слову, по Вашей ссылке никаких определений я не обнаружил... и вообще про "реальное время" там только Ваша загадочная (для меня) фраза: То, о чем Вы говорите, называется определение WCET... погуглите по фразе "worst case execution time"... В общем-то согласен, неактуально, даже скажу почему: потому, что там нет никаких мьютексов, семафоров и приоритетов, а, значит, конструктивно исключены инверсии приоритетов, дед-локи и прочие мексиканские узлы... ;)

тяжело общаться, когда нет единого языка... 1. не понятно, что такое "поставщик данных"... я так понимаю, есть либо процедура считывания состояния входов, ну или процедура обработки прерывания, которые либо тупо считывают состояния входов и записывают их в ОЗУ, либо еще пытаются вычленять события (что, как мне кажется, проблематично в принципе, если события неэлементарны) 2. не понятно, что Вы имеете ввиду под "поллингом", "проверка состояния входа через непосредственное считывание"? в словарях все как-то расплывчато: To check the status of an input line, sensor, or memory location to see if a particular external event has been registered. http://foldoc.org/polling 3. Устройство ПО управляющих цифровых систем, как я понимаю, обычно строится по стандартной циклической схеме, используемой в тех же ПЛК, состоящей из трех процедур: "чтение входных данных" -> "обработка" -> "запись выходных данных"... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная. А можно привести пример? Я с интерфейсами и разнотипными устройствами не понял. Вас можно так понять, что Вы пишете модули, которые абстрагируют UARTы и Ethernet-сокеты... Я так понял, под "аларм-лист" предлагается заводить что-то типа списка чисел (а может, и еще чего-то), которые требуется загружать в компаратор после каждого прерывания... только я не понял, зачем так сложно? И почему разбросав этот "аларм-лист" по нескольким таймерам получится какой-то выигрыш? Прерывания будут следовать ровно с той же частотой, используете вы один таймер, или 100. Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ. Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino). Да, вполне возможно, в этом и проблема взаимонепонимания, надеюсь, проблема решается, когда мы сделаем необходимые уточнения по областям применения и используемым аппаратным платформам. Мне кажется, что "приоритетная многозадачность" это просто некоторое средство для решения некоторой проблемы. Мне понятно, зачем она нужна под Windows 7, и вообще зачем нужна многозадачная ОС для компьютеров общего назначения, тоже понятно... но зачем она нужна, например, для платформы Arduino, мне понять уже трудно... Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость". Ах, как сразу Вы меня вывели на чистую воду... :-) Точно! Правда, меня сейчас больше интересует ни ПЛК, а задачи "малой" автоматизации и встраиваемых систем, средствами дешевых открытых платформ, типа Arduino... Кстати, насчет 5% утилизации ресурсов Вы не совсем правы. Существует решение, исключающее простой в ожидании синхронизующего события от таймера. В каких-то случаях это может быть и полезно... не очень пока понятно в каких, правда... поскольку, чего мне пока не приходилось встречать на практике, так это нехватки ресурсов для обеспечения требуемого времени реакции системы на внешнее событие. Да, конечно, в системах массового обслуживания нужны ОС. Правда, при чем тут "реалтаймовость" так и непонятно... Я тут с удивлением узнал, что Widows 8 будет предоставлять возможность запускать Word в "облаке"... я до сих пор нахожусь в недоумении, не в силах представить работу с 100+ Мегабайтовыми docm-файлами... А почему бы и нет? Linux добротная операционная система (жаль только без продуманного WIMP интерфейса), цель которой обеспечивать взаимное уживание приложений от сотен и тысяч разных разработчиков... дополнительный уровень абстракции, обеспечивающий строгую культуру "общежития" приложения (да и аппаратуры тоже).

наверное это можно делать, даже если в системе не предусмотрены прерывания по изменению значений на входах... только в чем преимущества такого подхода и каков механизм? Каждый раз перед тем, как передать управление, задача сообщает планировщику о событии, по которому ее надо разбудить... причем, события же могут быть весьма нетривиальными, по сути произвольная последовательность суперпозиций элементарных событий в системе, как то: изменение значения логической переменной, окончание временного интервала после некоторого события, тот или иной результат выполнения некоторой задачи, и проч. Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом? Я, честно признаться, не понял идеи. Особенно про контроль равномерности загрузки... Какой смысл отрывать проверку на событие от описание реакции на это событие, да еще и с, как мне показалось, дополнительными усложнениями? Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...

Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)... Может, специалисты в "реалтаймовости" нам тут подскажут...

я говорю в контексте подходов к реализации задач в области промышленной автоматизации. Это может быть и микроконтроллер, а может быть и программируемый логический контроллер. Что касается десяти тысяч задач, то мне это представляется нереальным для ОС, как впрочем, и тысяча... Подскажите, где такое встречается, было бы интересно рассмотреть... Один из подходов. Когда события отслеживаются выделенным модулем-супервизор и решение о реакции на событие возлагается на него же... на мой взгляд, это неплохо работает, когда все события поддержаны аппаратным прерыванием. Таких событий немного, они заранее известны и алгоритм их обработки более-менее понятен. А вот если у вас в алгоритме событий десятки тысяч, то вопрос их обработки в едином месте может вызвать проблемы (я, честно признаться, даже не представляю, как это сделать рационально)... Например, у вас есть модуль на восемь логических входов... 16 примитивных событий (положительный фронт/отрицательный фронт)... казалось бы... но это же не все возможные события... а если эти входы взаимосвязаны (для простоты это 8-ми разрядный АЦП)... сразу же получаем 256*2 событий. А если на интересуют события типа "вход i-ый в нуле И положительный фронт j-го входа,состояние остальных входов не интересует"? начинается уже комбинаторика... А если вас интересуют временные интервалы и события типа "вход i-ый не сбросился по истечению трех секунд"? и т. д. При этом события, "интересные" с точки зрения конкретной задачи могут изменятся в зависимости от происходящего... это ведь тоже реалии жизни при создании управляющих алгоритмов. В общем, если кратко: управление имеет смысл передавать, когда супервизор сам не в состоянии разобраться с событиями... как предельный случай -- полная ликвидация супервизора (планировщика ОС).

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

Спасибо! Но это САРы, и их отладка... неинтересно. То же и про МатЛаб... В принципе это подмножества LabVIEW (по функциональности).. графика - как графический язык программирования, типа FBD IEC 61131-3, или VPL из глюкавого MS RS. А мне графика нужна в сценах... виртуальные миры создавать, а не в графике алгоритмы описывать. Это немного (читай, "совсем") не то. Но все равно спасибо! Кстати, есть кто, кто с MSRS играл? Какие впечатления от?

Спасибо за ссылку... посмотрел, сильно настораживают языки программирования (VHDL, C)... как на них виртуальный прибор описать, непонятно... в смысле, алгоритм его работы описывать - еще куда не шло, но вот его _внешний_вид_ и его _перемещения в пространстве_, изменения формы, цвета... Ну и в доках никаких виртуальных объектов не видно. Можно ли где-нибудь посмотреть на виртуальные объекты SystemVision или там все только на уровне принципиальной схемы визуализируется? Например, хочется смоделировать автомобильный перекресток и светофор, чтобы туда-сюда машинки/грузовички/автобусики ездили... и чтобы просто это было сделать. Позволяет это SystemVision делать, или нет?

Ищу информацию по системам и методикам имитационного моделирования: предварительный анализ показывает, что дела в этой области обстоят плачевно: например, тренажеры для нефте-газовой промышленности пишутся на Си (!). Просьба поделиться опытом/информацией... обзоры по теме, отдельные системы, опыт использования. В первую очередь интересуют именно системы имитационного моделирования: т.е. возможность создавать виртуальные устройства / произвольные визуальные динамические сцены (машины, люди, устройства, станки) с поведенческим алгоритмом.

Загляните сюда, может покажется интересным: http://www.exponet.ru/exhibitions/online/s...ignatek.ru.html там про аудио написано, но, насколько знаю, они и с видео дело имеют, внутри ТэМээСы, телефон здесь: Ремель Иван Генрихович, ИАиЭ СО РАН, (383)3307827. ... и, слышал, подобных систем на рынке несколько.

Скажу следующее: nesC мне уже встречался. Как и несколько других диалектов Си, которых не так уж и мало. nesC разрабатывался как язык проектирования операционных систем (TinyOS), со всеми вытекающими: асинхронность обработки прерываний, полный доступ ко всему железу, обмен сообщениями. В общем полноценное средство работы с железом. Язык Рефлекс на это не претендует. Ориентация - на алгоритмы управления, работа ведется в унифицированном пространстве, требуются библиотеки (создающие унифицированное пространство). Синхронность исполнения... ну и т.д. если кратко, то принципиально разная ориентация языков (nesC и Рефлекс) "разбрасывает" эти языки в разные непересекающиеся области... а в общем nesC - оригинальный язык, с интересным подходом, ориентирован на создание системного ПО, возможно для распределенных архитектур. Как они сами заявляют "The nesC language is primarily intended for embedded systems such as sensor networks." Применительно к Вашей задаче: стека TCP/IP, библиотек для работы с мультимедиа я ничего не нашел. Может и есть. Первое наверняка есть,а вот второе под сомнением.

Нет, все должно быть embedded и необслуживаемо. Так что пЫсюковщина идет лесом. А по стоимости? Просто "пЫсюковщина" - это непонятный аргумент... есть же разные модификации для платформы... тем паче, что Х86 на половине ПЛК стоит... где-то с досом, а в последнее время просто с Win CE. Есть такая тенденция. Мультимедиа и все-такое прочее для работы в режиме 24х7, вроде как альтератив не много... Либо вообще ничего (нет аналогов), либо ненадежные пЫсюковые решения. А какие требования по надежности? Я просто хочу отделить мух от котлет и понять, где тут технические аргументы, а где одни эмоции...