Lift-man - по своему опыту разработки систем управления, могу сказать, что причина наличия глюков в програмном обеспечении не в том что программы для станций пишутся на низкоуровневых языках - спросите у любого разработчика систем управления и они ответят вам, что все коды написаны на Си или Си++, которые являются достаточно высокоуровневыми языками, но ошибку, описанную вами можно совершить практически в любом высокоуровневом языке, ошибочно задав тип переменной.
Другое дело - и в этом кроется вся проблема - как эту ошибку выявить - и тут, начинаются приколы:
1. Можно пользоваться симулятором, который всю программу будет выполнять на компьютере, но когда количество сигналов начинает превышать десяток, и они взаимодействуют между собой - прогнать всю программу становится большой проблемой, потому что надо написать другую програму
, которая бы взаимодействовала с этой и скорость работы будет очень низкой. Это единственный метод, который не требует железа при отладке.
2. Можно воспользоваться маленькой программой, которая будет паралельно крутиться в контроллере и позволять сбрасывать на компьютер состояние памяти, регистров и даже иногда делать пошаговую отладку. Но эта штука требует ресурсов контроллера, таких как последовательный порт, память, прерывания - которые естественно уже используются. Также она не позволяет делать многие функции отладки, такие как точки останова в прерываниях и иногда реальную скорость выполнения программы, что для лифтов иногда очень важно(например опрос матрицы, где все должно быть синхронизированно и быстро).
3. Есть внутрисхемные эмуляторы, которые устанавливаются взамен процессора в систему, и позволяют делать реальную отладку в реальном времени. Но эти штуки настолько дороги, что не у всех они есть. А если есть, то они неуниверсальны и позволяют отлаживать только один тип процессора, а сейчас есть столько модификаций,что можно разориться покупая отладчик для каждого процессора. Лично у нас есть внутрисхемный отладчик для AT89C51, но толку с него - если мы уже давно пользуемя другими модификациями 89-ых.
4. И тут я повествую основной метод отлаживания програм в наше время - это принцип - загрузить в процессор и наблюдать как оно работает - естественно обычно проверяется только та часть алгоритма, которая была изменена, но изза особенностей компиляторов да и вообще процессоров(например выделение памяти) , при изменении одной части программы может перестать работать другая часть, что выливается в совсем левые глюки новых версий.
Проблема в том что разработчик не может "заглянуть" вовнутрь процессора и выяснить реальную причину ошибки, и работает вслепую, надеясь что код будет работать без ошибок.
5. Самым современным методом отладки на сегодншний день является JTAG, это когда в процессоре при его изготовлении создается блок, который позволяет прозрачно для основной программы ее отлаживать, останавливать, смотреть регистры и т.д. Преемуществом также является то, что этот тип отладки не требует ресурсов процессора. Но недостаток в том, что не все функции поддерживаются. Ну и проблема в том, что только новые процессоры имеют эту функцию.
Напримерт AT89 ее не имеют, но некоторые клоны например от Cygnal имеют.
Насколько я помню MSP430 в СУЛ, также должен иметь JTAG, что по моему мнению должно сделать єту систему относительно безглючной.
А вообще, я уже неоднократно сталкивался с этим - распределенные системы управления надо строить только на контроллерах, для которых у есть хорошие средства внутрисхемной отладки, иначе от глюков вы не избаветесь никогда.
Вот и выходит, что зажаты они всего лишь рамками выбранных контроллеров