Jump to content

    

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

Свой
  • Content Count

    98
  • Joined

  • Last visited

Community Reputation

0 Обычный

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

  • Rank
    Частый гость

Контакты

  • Сайт
    http://reflex-language.narod.ru/

Информация

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

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

    Цитата(Olej @ Oct 2 2012, 04:02) По моей ссылке можно выйти на оригинальные тексты самих стандартов POSIX ... которые многие обсуждают, но мало кто видел в глаза. Я давал ссылку только с этой целью. Так. Раньше было "ОС РВ -- это QNX"(или что-то такое), теперь уже "ОС РВ -- это стандарты POSIX..." В принципе, достаточно конструктивно, только я бы не концентрировался на POSIX. Как Вам такое определение: "ОС РВ -- это ОС с планировщиком задачи", или просто "многозадачная ОС"? Тогда и тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет. Или, другими словами, в каких задачах нам нужен многозадачный параллелизм, а в каких многопоточный. И сразу к ответу приблизимся.
  4. Когда не нужна ОС РВ?

    Цитата(Olej @ Oct 1 2012, 22:57) Уже несколько раз звучит это утверждение и от разных авторов. Поллинг это: - циклический (повторяющийся) программный опрос... - идущий от POSIX poll() ... но, скорее, "срываемый" по истечению таймаута периода ожидания, - т.е. "синхронный"(с). Если кто-то имеет в виду что-то другое, то называйте его по-другому. Теперь стало понятно, что под поллингом подразумевается в POSIX, это вполне сочетается с моим пониманием, но проблема в том, что это не единственное определение поллинга. Поэтому, как мне представляется, это слово лучше вообще не употреблять. Цитата(Olej @ Oct 1 2012, 22:57) В теме обсуждения нигде не было заявлено такого ключевого слова как Arduino Да и на "малой" автоматизации"(с) никто особенно не акцентировался... Это может быть, но отдельная совсем, и более конкретная тема. Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще? Цитата(Olej @ Oct 1 2012, 22:57) Ну здесь вы лукавите... я, как помнится, не на одном обсуждении с вами пересекался, и всё вы прекрасно встречали Тот же стандарт POSIX даёт определения ... и его расширения POSIX 1003.b ... и ещё др. близкие расширения (см. http://rus-linux.net/forum/viewtopic.php?f=18&t=1542). Увы, я встречал только попытки дать определения... К слову, по Вашей ссылке никаких определений я не обнаружил... и вообще про "реальное время" там только Ваша загадочная (для меня) фраза: Цитатаhttp://www.intuit.ru/department/se/posix2/ - а это расширения реального времени POSIX, и здесь вообще - "тёмный лес"... где это более-менее внятно реализовано - это только OS QNX 6.x Цитата(Olej @ Oct 1 2012, 22:57) Вполне достаточно самой традиционной формулировки: детерминированное поведение - возможность обеспечения реакции в гарантированно заранее определённое максимальное время реакции... уложитесь ли вы в заказанный (завышенный) интервал, но с гарантией 100% из 100 млн. тестовых случаев. То, о чем Вы говорите, называется определение WCET... погуглите по фразе "worst case execution time"... Цитата(Olej @ Oct 1 2012, 22:57) Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается. Для многозадачных конкурентных ОС с приоритетами - очень даже актуально. Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности В общем-то согласен, неактуально, даже скажу почему: потому, что там нет никаких мьютексов, семафоров и приоритетов, а, значит, конструктивно исключены инверсии приоритетов, дед-локи и прочие мексиканские узлы...
  5. Когда не нужна ОС РВ?

    Цитата(_Pasha @ Sep 30 2012, 22:51) Допустим, какой-либо процесс X ожидает комбинации условий (булевых переменных) (a==1)&&(b==0)&&(b_prev==1), что означает вход a в высоком уровне, вход b - переход 1->0, от других процессов. Вопрос детский: что мы можем сделать, чтобы уменьшить количество проверок, то бишь поллинг? Мы должны сообщить поставщику данных, чтобы он разбудил процесс Х именно при наступлении указанного условия, т.е. делегировать проверки тому процессу, который отвечает за прием a,b или сам процесс Х должен быть поставщиком для себя. Во втором случае проблема решена: никакого поллинга, но есть вопрос: а когда ему брать данные? Т.е. избавились от асинхронности-пришли к временным интервалам. И что лучше из трех вариантов - асинхронная обработка с поллингом, синхронная с семафором либо вообще слияние процессов - выбирать надо по месту. тяжело общаться, когда нет единого языка... 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. Устройство ПО управляющих цифровых систем, как я понимаю, обычно строится по стандартной циклической схеме, используемой в тех же ПЛК, состоящей из трех процедур: "чтение входных данных" -> "обработка" -> "запись выходных данных"... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная. Цитата(_Pasha @ Sep 30 2012, 22:51) Это опять же диалектика проявляется: (проверка события+реакция в одном потоке) vs (отправитель - получатель). Если нам выгоднее вторая форма, т.е. отдельные потоки - значит есть другие более веские факторы. Например, поток обрабатывает пакеты какого-л интерфейса и нам лучше его оформить так, чтобы он был вещью в себе - и работал на нескольких разнотипных устройствах. А можно привести пример? Я с интерфейсами и разнотипными устройствами не понял. Вас можно так понять, что Вы пишете модули, которые абстрагируют UARTы и Ethernet-сокеты... Цитата(_Pasha @ Sep 30 2012, 22:51) Про контроль равномерности. Например, у нас есть несколько свободных таймеров с функцией компаратора и соответствующего прерывания. Тогда проще разбросать аларм-лист по всем ресурсам равномерно, чем делать одну длиннющую очередь и довольно часто обслуживать ее, перезагружая компаратор в прерывании. Во втором случае, конечно, универсальнее - "безобразно, зато единообразно" Я так понял, под "аларм-лист" предлагается заводить что-то типа списка чисел (а может, и еще чего-то), которые требуется загружать в компаратор после каждого прерывания... только я не понял, зачем так сложно? И почему разбросав этот "аларм-лист" по нескольким таймерам получится какой-то выигрыш? Прерывания будут следовать ровно с той же частотой, используете вы один таймер, или 100. Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ. Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino). Цитата(Olej @ Oct 1 2012, 14:47) Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет смешались в кучу примеры и представления из совершенно разных областей применения : Да, вполне возможно, в этом и проблема взаимонепонимания, надеюсь, проблема решается, когда мы сделаем необходимые уточнения по областям применения и используемым аппаратным платформам. Цитата(Olej @ Oct 1 2012, 14:47) 1. До тех пор, пока не нужна приоритетная многозадачность ни о какой ОС РВ разговаривать нет смысла вообще ... нет конкурентной многозадачности - и всё само собой и так становится "реалтайм", в этом смысле можете считать MS-DOS ОС РВ, и будете в значительной степени правы. Мне кажется, что "приоритетная многозадачность" это просто некоторое средство для решения некоторой проблемы. Мне понятно, зачем она нужна под Windows 7, и вообще зачем нужна многозадачная ОС для компьютеров общего назначения, тоже понятно... но зачем она нужна, например, для платформы Arduino, мне понять уже трудно... Цитата(Olej @ Oct 1 2012, 14:47) 2. Никакие абсолютные временные характеристики (латентность, времена переключения и т.п.) к реалтаймовости не имеют никакого минимального касательства - это вопросы масштаба времени. Возьмите процессор в 10 раз быстрее - и наслаждайтесь в 10 раз меньшей латентностью. Так что "реалтайм" - термин (не очень определённый) скорее из области надёжности и безотказности системы, а не из области временных характеристик. Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость". Цитата(Olej @ Oct 1 2012, 14:47) 3. К области логических автоматов в промышленных управляющих системах, к языкам МЭК 61131-3 ... и Рефлекс - куда склоняет разговор Зюбин В.Е. - терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг N входных воздействий + никакая другая конкурирующая задача не может возникнуть на процессоре, если у вас даже процесс управления занимает 5% потенциальной производительности процессора PLC (из-за ошибки или жадности проектировщика), то никакая другая задача не станет использовать остающиеся 95%. Ах, как сразу Вы меня вывели на чистую воду... :-) Точно! Правда, меня сейчас больше интересует ни ПЛК, а задачи "малой" автоматизации и встраиваемых систем, средствами дешевых открытых платформ, типа Arduino... Кстати, насчет 5% утилизации ресурсов Вы не совсем правы. Существует решение, исключающее простой в ожидании синхронизующего события от таймера. В каких-то случаях это может быть и полезно... не очень пока понятно в каких, правда... поскольку, чего мне пока не приходилось встречать на практике, так это нехватки ресурсов для обеспечения требуемого времени реакции системы на внешнее событие. Цитата(Olej @ Oct 1 2012, 14:47) 4. Т.е. реалтаймовая терминология воообще применима только к системам общего применения с асинхронно возникающими задачами, или пиковыми всплесками потребности производительности... В том числе, достаточно часто эти пиковые всплески могут происходить как следствие активности человека-оператора. Или в серверных системах массового обслуживания, в тех, которые представляют максимально популярные сейчас "облачные" сервисы. И алгоритмика "разруливания" запросов конкурирующих процессов (дисциплина диспетчеризации) может быть для обеспечения реалтайм (RT OS) и весьма замысловатой (POSIX 1003.b: спорадическая, адаптивная, ...) и уж заведомо отличающейся от дисциплины диспетчеризации системы общего использования (GP OS) Да, конечно, в системах массового обслуживания нужны ОС. Правда, при чем тут "реалтаймовость" так и непонятно... Я тут с удивлением узнал, что Widows 8 будет предоставлять возможность запускать Word в "облаке"... я до сих пор нахожусь в недоумении, не в силах представить работу с 100+ Мегабайтовыми docm-файлами... Цитата(Olej @ Oct 1 2012, 14:47) 5. Интересно, в смысле иллюстрации, в этом смысле современная (раньше было по-другому) структура сетевого стека Linux: - здесь ведь только 1-й пакет "сетевой пачки" принимается по IRQ ... - дальше модуль сетевого устройства переходит к программному поллингу всех последующих пакетов ... - до тех пор, пока интенсивность "сетевого всплеска" не упадёт, и можно снова уйти на ожидание по IRQ. Подробней см.: Модули ядра Linux. А почему бы и нет? Linux добротная операционная система (жаль только без продуманного WIMP интерфейса), цель которой обеспечивать взаимное уживание приложений от сотен и тысяч разных разработчиков... дополнительный уровень абстракции, обеспечивающий строгую культуру "общежития" приложения (да и аппаратуры тоже).
  6. Когда не нужна ОС РВ?

    Цитата(_Pasha @ Sep 30 2012, 20:00) Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер. наверное это можно делать, даже если в системе не предусмотрены прерывания по изменению значений на входах... только в чем преимущества такого подхода и каков механизм? Каждый раз перед тем, как передать управление, задача сообщает планировщику о событии, по которому ее надо разбудить... причем, события же могут быть весьма нетривиальными, по сути произвольная последовательность суперпозиций элементарных событий в системе, как то: изменение значения логической переменной, окончание временного интервала после некоторого события, тот или иной результат выполнения некоторой задачи, и проч. Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом? Цитата(_Pasha @ Sep 30 2012, 20:00) А на сей счет уже лучше не придумаешь, чем на основе имеющихся свободных таймеров создавать "аларм-листы", с контролем равномерности загрузки этих таймеров, чтобы в прерывании, в к-ром происходят проверки, не задерживаться слишком надолго. Хотя, все зависит от точности временной задержки- можно ведь и уставки сортировать и загружать новые значения в таймер по мере их поступления из очереди. Я, честно признаться, не понял идеи. Особенно про контроль равномерности загрузки... Какой смысл отрывать проверку на событие от описание реакции на это событие, да еще и с, как мне показалось, дополнительными усложнениями? Цитата(ViKo @ Sep 29 2012, 21:58) Плохо понял. У задачи есть переменная, назовем "регистр событий". События, которых задача ожидает, задаются в самой задаче, а устанавливаются в других задачах, которым требуется запустить на выполнение первую. Проверяются же события самой ОС. Если заданное событие наступило, планировщик запустит задачу, если нет более приоритетных. Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...
  7. Когда не нужна ОС РВ?

    Цитата(_Pasha @ Sep 29 2012, 21:03) Все пользователи реалтаймовости рано или поздно приходят к тому, что надо бороться с любыми элементами поллинга <...> Простой пример Кодtime = get_tick(); wait(process2->end_packet || (tick_diff(time) > TIMEOUT)); Такой вот примитив синхронизации. Процесс ждет какого-то там окончания либо таймаута, при этом, естественно, реализация этих действий поллингом, не вызывает никаких затруднений. Если же процесс засыпает намертво, т.е. до соблюдения указанных условий его и вызывать- то никто не собирается, встает закономерный вопрос: А кто будет проверять эти условия, и самое главное - когда? <...> Для этих целей все мы вынуждены порождать и использовать новые сущности. Но как быть, если при большом количестве подобных ожиданий событий код рискует оказаться либо распыленным по десятку файлов, либо стать нечитабельным, сильно затеняя "прикладной смысл", либо оказаться с неприменимо большой глубиной вложенности подпрограмм? Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)... Может, специалисты в "реалтаймовости" нам тут подскажут...
  8. Когда не нужна ОС РВ?

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

    Доброго здравия всем присутствующим! Цитата(ViKo @ Sep 27 2012, 17:42) Какая уже разница - городить собственный конечный автомат, с условиями переходов, если можно взять готовую ОС с переключениями задач по событиям? В планировщике есть: очень сложно настроить планировщик на переключение по произвольным событиям, так как это требует передачи планировщику информации о контексте задачи (управляющего алгоритма)... поэтому часто используется одно событие -- прерывание от таймера... а это непроизводительные расходы: планировщик передает управление некоторой задаче, задача проверяет факт наступления события, а событие не наступает... даже если механизм переключения несколько более сложен, чем разделение по времени, суть не меняется: каждая процедура передачи управления это сохранение контекста и восстановление контекста задачи. И еще ладно, если задач всего с десяток... а если их тысяча? В общем, "задача" это очень тяжеловесно. Поэтому разработчики просто вынуждены использовать более легковесные подходы и организовывать планирование на более низком уровне.
  10. Цитата(Thistle @ Jan 8 2007, 02:36) Гуглить по словам "МВТУ Моделирование в технических устройствах" там можно всё что вам нужно. Спасибо! Но это САРы, и их отладка... неинтересно. То же и про МатЛаб... В принципе это подмножества LabVIEW (по функциональности).. графика - как графический язык программирования, типа FBD IEC 61131-3, или VPL из глюкавого MS RS. А мне графика нужна в сценах... виртуальные миры создавать, а не в графике алгоритмы описывать. Это немного (читай, "совсем") не то. Но все равно спасибо! Кстати, есть кто, кто с MSRS играл? Какие впечатления от?
  11. Цитата(Gate @ Jan 6 2007, 20:04) SystemVision от ментора: http://www.mentor.com/products/sm/systemvision/index.cfm Есть на фтп, так что можно взять и поиграться... Спасибо за ссылку... посмотрел, сильно настораживают языки программирования (VHDL, C)... как на них виртуальный прибор описать, непонятно... в смысле, алгоритм его работы описывать - еще куда не шло, но вот его _внешний_вид_ и его _перемещения в пространстве_, изменения формы, цвета... Ну и в доках никаких виртуальных объектов не видно. Можно ли где-нибудь посмотреть на виртуальные объекты SystemVision или там все только на уровне принципиальной схемы визуализируется? Например, хочется смоделировать автомобильный перекресток и светофор, чтобы туда-сюда машинки/грузовички/автобусики ездили... и чтобы просто это было сделать. Позволяет это SystemVision делать, или нет?
  12. Ищу информацию по системам и методикам имитационного моделирования: предварительный анализ показывает, что дела в этой области обстоят плачевно: например, тренажеры для нефте-газовой промышленности пишутся на Си (!). Просьба поделиться опытом/информацией... обзоры по теме, отдельные системы, опыт использования. В первую очередь интересуют именно системы имитационного моделирования: т.е. возможность создавать виртуальные устройства / произвольные визуальные динамические сцены (машины, люди, устройства, станки) с поведенческим алгоритмом.
  13. Фундаментальня размышлизма о RTEMS.

    Цитата(Evgeny_CD @ Aug 15 2006, 16:52) Что касается основной темы этой ветки - RTEMS и "толстых контроллеров". Мне достаточно трудно описать задачу в терминад пЫсюка, ибо там она потребует больших ресурсов из-за неоптимальной архитектуры. Я же планирую сделать гибкую конфигурируемую систему, где все RT задачи выполняются действительно RT, лучше всего на специализированных сопроцессорах, а медленные задачи управления крутится под "большой осью". Например - надо мне снять MPEG4 AVC ролик в 2 минуты, как и кто входил на склад.... Загляните сюда, может покажется интересным: http://www.exponet.ru/exhibitions/online/s...ignatek.ru.html там про аудио написано, но, насколько знаю, они и с видео дело имеют, внутри ТэМээСы, телефон здесь: Ремель Иван Генрихович, ИАиЭ СО РАН, (383)3307827. ... и, слышал, подобных систем на рынке несколько.
  14. Фундаментальня размышлизма о RTEMS.

    Цитата(Evgeny_CD @ Aug 14 2006, 20:29) Владимир Е. Зюбин, что скажете по поводу http://electronix.ru/forum/index.php?s=&am...st&p=144275 Скажу следующее: nesC мне уже встречался. Как и несколько других диалектов Си, которых не так уж и мало. nesC разрабатывался как язык проектирования операционных систем (TinyOS), со всеми вытекающими: асинхронность обработки прерываний, полный доступ ко всему железу, обмен сообщениями. В общем полноценное средство работы с железом. Язык Рефлекс на это не претендует. Ориентация - на алгоритмы управления, работа ведется в унифицированном пространстве, требуются библиотеки (создающие унифицированное пространство). Синхронность исполнения... ну и т.д. если кратко, то принципиально разная ориентация языков (nesC и Рефлекс) "разбрасывает" эти языки в разные непересекающиеся области... а в общем nesC - оригинальный язык, с интересным подходом, ориентирован на создание системного ПО, возможно для распределенных архитектур. Как они сами заявляют "The nesC language is primarily intended for embedded systems such as sensor networks." Применительно к Вашей задаче: стека TCP/IP, библиотек для работы с мультимедиа я ничего не нашел. Может и есть. Первое наверняка есть,а вот второе под сомнением.
  15. Фундаментальня размышлизма о RTEMS.

    Цитата(Evgeny_CD @ Aug 14 2006, 20:19) Цитата(Владимир Е. Зюбин @ Aug 14 2006, 18:11) Туманно... Просматривается что-то типа систем идентификации (от глобальных СОРМ , ФСБ, до пропускные системы, подъездные двери)... непонятна архитектура системы, аппаратная платформа и стоимость решения, на которую ориентируетесь. Тут и Виндовоз может подойти... типа CE... или вообще, что-нибудь типа LabView + (Win/Linux).Нет, все должно быть embedded и необслуживаемо. Так что пЫсюковщина идет лесом. А по стоимости? Просто "пЫсюковщина" - это непонятный аргумент... есть же разные модификации для платформы... тем паче, что Х86 на половине ПЛК стоит... где-то с досом, а в последнее время просто с Win CE. Есть такая тенденция. Мультимедиа и все-такое прочее для работы в режиме 24х7, вроде как альтератив не много... Цитата(Evgeny_CD @ Aug 14 2006, 20:19) Цитата(Владимир Е. Зюбин @ Aug 14 2006, 18:11) А что конкуренты используют?Либо вообще ничего (нет аналогов), либо ненадежные пЫсюковые решения. А какие требования по надежности? Я просто хочу отделить мух от котлет и понять, где тут технические аргументы, а где одни эмоции...