Перечитал вниметельнее - выскажу свои мысли.
Evgeny_CD:
"
1. Ось - это совокупность стандартов и методологических подходов,
которая обеспечивает:
* разработку кода силами команды (>1 человека), причем код, написанный
одним человеком, с небольшими усилиями используется другим
* повторное использование кода от проекта к проекту
* переносимость между целевыми платформами и средами разработки
"
Нет, извините, Переносимость - да, а остальное к Оси отношение не имеет.
Грамотные "черные ящики" - сила любого проекта.
А с остальным я полностью соглашусь.
===
Vic1:
"
Можно еще эту книгу почитать (не слишком доверяя автору, но и не слишком критикуя)
http://www.natahaus.ru/2006/02/17/programm...ontrollery.html"
_не слишком доверяя автору_ - а можно подробнее? книгу читал, а где надо не доверять?
"
Это все давно известно для задач АСУТП (их основное отличие от задач ЦОС - "мягкое" реальное время,
в остальном - много похожих свойств).
"
Я думаю, "мягкое" реальное время и задачи АСУТП связывать не надо - "мягкое реальное время" -
это как систему построить, а АСУТП разные бывают.
====
Vic1:
"
Насчет Siemens и его Step7 такой уверенности нет (вроде как без ОС РВ).
И еще, очевидно что подход с интерпретатором TIC-кода для ЦОС и ИИС не подойдет
(если только не уйдем куда-нибудь совсем в сторону изменяемой системы команд процессора под свою задачу ...)
"
Вот Siemens как раз сюда и ушел - см Speed7 -
http://www.speed7.com/ 
А Vipa (брат-близнец Simatic) ставит на свои контроллеры eCOS.
Только одно _но_ - у них в одном контроллере 3 CPU: Speed7 для выполнения технологического алгоритма,
х86 (видимо он с eCOS) для связи с верхним уровнем по Ethernet и какой-нить SAB+ASPC2 для сети Profibus.
(Не уверен на 100%, но общая картина такая)
"
Хотя когда появились ПЛК и эти языки МЭК - уж такие размахивали флагом "открытых систем".
А на вопрос про переносимость и включение своего драйвера - да ОЕМ часть обязательно есть
(заплати только огромную сумму)! Ну это off-topic.
"
А Вы обратили внимание на историю МЭК языков (их корни) и какие фирмы этот МЭК между собой сделали стандартом ?
===
Olej:
"
Там ещё интереснее, если быть совсем точным...
Я не знаю как с CoDeSys ...
"
А точно так же как и с ISa, только CoDeSys компилятор, и надо смотреть поддерживает-ли он платформу.
===
Evgeny_CD:
"
имеет смысл написать свой макро-язык, который ...
"
Так МЭК стандарт так и создавался
Только фирмы, создавшие языки были крупными и сделали из внутрифирменного решения IEC.
(И как Siemens свой Profibus сделал МЭк-овским)
===
SM:
"
Кол-во ресурсов - это площадь - это доллары и центы.
"
"
Да потому, что область-то может и узкая, но внутри нее очень и очень много всего ...
"
Все-таки, тут обсуждается два разных подхода. Назовем их "ЦОС" и "АСУТП", условно.
1. "ЦОС" - Вы разрабатываете _изделие_, как правило, массовое, и сдаете его заказчику.
Сперва у Вас присутствует ОС, затем, после оптимизации уходит (а может и остается,
а может видоизменяется, не важно).
(Честно говоря, я так и живу
Сначала работают несколько задач под ОС,
а в релизе - одни прерывания и ОСь с одной задачей .... для диагностики)
Такие системы, узкоспециализированные _в конечном итоге_, выжимают из аппаратуру ~100%.
2. "АСУТП" - Вы сдаете заказчику _конструктор_, на базе которого он (а может и Вы сами)
строит систему управления производством - здесь многократный запас по производительности,
и "живая" (т.е. ПО меняется) система (добавь еще две ложки .... как в к/ф "33").
===
Vic1:
"
основное достоинство языков МЭК - введение новых элементов языка, отражающих специфику
предметной области, причем не только новых структур данных, но и структур управления
"
?????
"
Упоминаемые здесь скриптовые языки .... А как там обстоит дело с возможностью введения
новых управляющих конструкций языка, (часто требующих доступа к аппаратному уровню целевой системы)?
"
А тут (МЭК) это тоже никак не обстоит.
====
SM:
"
Самый выигрышный вариант оказался построение системы как ряда последовательно вызываемых конечных автоматом
в бесконечном цикле ...
"
"
Так как нет диспетчера. Все задачи вызываются последовательно обычной цепочкой CALL'ов на подпрограммы.
Каждая подпрограмма - задача - КА. ... , что в каждом из них программа не может находиться например
более 500 тактов CPU
"
Отличное описание работы ISaGRAF-a, точнее его целевой задачи.
Ессно, эта задача может быть запущена как без ОС, так и как процесс под ОС.
Когда не нужна ОС РВ?, навеяно постом "Я написал RTOS"
Mar 2 2006, 15:58
