ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
18 мая
91890 Топик полностью
Vit (17.06.2007 22:55, просмотров: 1) ответил AlexandrY на Все правильно, очень верно сделано.
ИМХО, яма какая-то Если контрольная точка одна, то всё притягивается. Но если их несколько, то нужна объединяющая логическая функция (ИЛИ, что ли), имеющая на выходе только 1 результат. Т.е. флагов может быть много, но пока не пришло время "Ч", на выходе запрет сброса сторожа. Т.е. в общем оно как бы и хорошо, но появляется вопросик - если прерывание, в котором производится принятие решения имеет свой, асинхронный по отношению к другим процессам, характер, то либо каждый флаг имеет поле достоверности установки/снятия - типа код Грея для 2-х бит, т.е. как минимум длина флагов удваивается, либо синхронизация должна приоизводиться каким-либо другим образом. Иначе - сторож должен иметь логическую связь с приложением, а точнее с приложениями/процессами. Можно возразить, мол, период возникновения прерываний для вызова сброса сторожа сделай (а по факту период сторожа обчно достаточно большая величина) больше, чем самый длинный цикл контроля, и всё бдет хорошо. Но это одна сторона - что же делать, если контроль производится достаточно часто, а иногда(и очень на короткое время) выявляются сбои/неполадки? Какая польза от такого флага? Если он имеет триггерную функцию, то нафига, если можно попытаться подготовиться и выпасть в ресет без измучивания сторожа? (разве что хочется почитать флаг типа рестарта). Если же не триггреный, то никакого контроля, имеющего корректное воздействие на сторож, получается нету - все эти размазанные во времени флаги могут жить своей жизнью и иногда даже приводить к сбросу камня. Считаю, что если возникают неопределённости, способ не годится. Если же считать, что в основной (это который процесс?;) программе где-то логически таки реализуется решение с одним флагом, то использование этого же флага через прерывание для случая когда нельзя сбрасывать сторож, отличается аж тем, что вместо "просто не сбрасываем", потому, что где-то подвисли, появляется описательная величина - "не сбрасываем, потому как не разрешили, так как где-то подвисли". Выгода от этого, ИМХО, только в неиспользованиии критических секций при выдаче последовательности сброса, типа как в LPC2000 WDTFeed, хотя также есть спорные моменты, типа, если подвис уж в исключении высокоприоритетном, то тяжко из него вырулить чтоб всё цело осталось, скорее даже нереально