Многопоточность в ADAM 5510( или прерывания)

1. Ну ваще-то, программа не должна падать по определению. Если падает - то надо переписывать, пока не достигнет нужной устойчивости. Это как организм - пытается жить до последнего, даже при тяжелых повреждениях. Винда - прямая противоположность: чуть чо не так - лапки кверху.

Когда я говорил о выборе ОС то забыл одну очень интересную вещь - драйверы Реального Времени встраиваемые в стандартные ОС.  Из которых я встречал, самая серьезная -  SP RTE , входящая в состав среды CoDeSys.
Этот драйвер пролазит до самого железа, колет кирпич на две части, и делит его с Виндой.  После этого комп часть времени работает на Винду, а часть на ПЛК.  Соотношение частей можно устанавливать с шагом 0,1 мкс.
У системы  SP RTE  есть свой развитый планировщик задач, удобно строится в  CoDeSys.
О серьезности софта говорит тот факт, что когда мы подвешивали Винду  -  ПЛК-часть продолжала работать как ни в чем не бывало !

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

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

С уважением, SAN

Немного уточню. Винда очень болезненно переносит дисковые операции, особенно с CD/DVD приводами. Это сложилось исторически, и чо-та так и не смогли поправить. Эти типы зависаний довольно глубоко уходят корнями в ядро.  SP RTE  проверялась при вот этих глюках, что весьма убедительно.

С уважением, SAN

 Свои пять копеек внесу. 

Еще DOS  при выполнении файловых операций отключала все прерывания на 10 мс (примерно) при обращении к сектору.  Как результат, отставание часов машины при большом объеме файловых операций и сбои в работе последовательного обмена в момент файловых операций , когда буферизация не спасает (а буфер в 14 байт, вообще говоря, далеко не всегда спасает).  Это собственно все видели.  Скорее всего, этот же механизм перенесен и в винду - винчестеры- то что при  DOS,  что при винде одинаково с компом общаются.  Может его чуть подправили, но скорее всего нет, если было бы можно - сделали еще бы в  DOSе.  Так что, чудеса при файловых операциях во многом отсюда произрастают. Скорострельность машины выручает, но до тех пор, пока работа не связана с прерываниями.

Видел такую штуку: при неуспешной файловой операции убивался  Diskonchip.  Причем происходило это настолько достоверно и регулярно, что от него пришлось просто отказаться в компьюторе и уйти на  Diskonmodul, там то уж такого не было.

Эээ.  Вы прочитали в книжке.  Но, когда вам придеся поправлять обмен или добиваться нормальной работы часов в компе или контроллере, в котором стоит винда, вспомните не соломона, а то что я написал:)

Кстати, писатели на чистую воду выводятся очень просто.  Запускается компьютор на 3 часа без задач. Просто работает.  Смотрим его часы по внешним эталонным. Через три часа опять смотрим.  Второй подход. Все три часа должна крутиться задача которая пишет в файл без перерыва.  Вы получите отставание во втором случае примерно в 5-6 секунд.   Я уже насмотрелся на это, но вы можете посмотреть.