Каков обычный подход к отладке? Запускаем, потом смотрим, что получается. Если получается не то, что надо, то разбираемся в оставшихся ошмётках, пытаясь по ним определить, что произошло.
Если отлаживается ПО, которое двигает брутальными рычагами при помощи киловаттных двигателей, то такой метод не подходит. Хорошо, если дело обойдётся заделыванием дыры в стене.
В текущей установке цена не столь высока, но риск что-нибудь поломать -- реальный. Поэтому приходится при отладке максимально увеличивать безопасность всех действий. Хотя с движущимися железками я имел дело и до этого, но они всегда были довольно маленькими. По большим железкам -- я начинающий. Если у вас есть опыт такой отладки -- прошу поделиться советами.
Вот что я придумал, пока пытался ничего не сломать:
1. Точки останова и интерактивную отладку вообще следует использовать с большой осторожностью. Пока программа остановлена, движущиеся части могут продолжать двигаться. Поэтому точки надо ставить ПОСЛЕ команд, которые всё останавливают, а не до. Важно помнить, что если точка стоит на строчке с командой Stop(), то команда выполнена не будет! Надо ставить на следующей строке. Если вам нужно поставить точку там, где нет тотальной остановки, её надо туда временно добавить.
2. Тем не менее, запускать весь алгоритм целиком -- опасно. Тут есть два метода:
а) Алгоритм надо разбить на отдельные этапы, между которыми программа будет вставать на паузу, а все движущиеся части останавливаться. По кнопке программа должна выполнять следующий кусок, если предыдущий прошёл успешно. А если нет -- как раз в этот момент можно будет покопаться в памяти при помощи интерактивного отладчика. Таким образом отладка будет состоять не из серии прогонов и разборов полётов, а из серий прогонов кусков 1, 1+2, 1+2+3 и т.д.
б) Начальные точки движения частей надо расположить подальше от препятствий, а диапазоны перемещений сделать маленькими, поэтому даже если система поедет не туда, она ничего не вывернет.
3. Отладка должна вестись одной рукой. Вторую надо держать на выключателе, который всё обесточивает (система должна быть разработана так, чтобы при пропадании питания по инерции ничего не ехало, но это задача не программиста; ещё одна задача не программиста -- минимизировать риск столкновения частей при штатной работе, например механически ограничить зоны деятельности разных деталей так, чтобы они никогда не пересекались).
4. Во время правки кода система должна быть выключена, а программа не должна выполняться, т.к. пока код не отлажен, что-то может поехать, пока вы отвернулись и уткнулись в монитор. У меня так поехало, причём я до сих пор не знаю, когда поехало и почему.
5. Удобство интерфейса отладочной многокнопочной утилиты (или что вы там используете) очень важно. Чем понятнее для вас всё сделано, тем меньше шанс по ошибке нажать не ту кнопку. Очевидно, что надо перед нажатием чего бы то ни было вообще по два раза проверять, что вы нажимаете. Непонятное расположение кнопок, двусмысленные надписи, разные единицы измерения в разных полях ввода -- это всё очень опасно.
6. Выдавать окошечки с кнопкой ОК для информирования вас о чём-либо -- плохая идея. Они перекрывают главное окно, а могут вообще его блокировать. Таким образом, вы теряете контроль над установкой.
7. Отдельного трактата достойна обработка исключительных ситуаций. Это дело я пока вообще только обдумываю. Например, управляющая программа может УПАСТЬ, а любые подчинённые микроконтроллеры -- зависнуть или умереть. Какие части будут продолжать двигаться после этого? Насколько долго? Сколько промасленных котов намотает на вал? Как можно от этого защититься?
Меня утешает, что тем, кто пишет ПО для спутников, приходится гораздо хуже.
Если отлаживается ПО, которое двигает брутальными рычагами при помощи киловаттных двигателей, то такой метод не подходит. Хорошо, если дело обойдётся заделыванием дыры в стене.
В текущей установке цена не столь высока, но риск что-нибудь поломать -- реальный. Поэтому приходится при отладке максимально увеличивать безопасность всех действий. Хотя с движущимися железками я имел дело и до этого, но они всегда были довольно маленькими. По большим железкам -- я начинающий. Если у вас есть опыт такой отладки -- прошу поделиться советами.
Вот что я придумал, пока пытался ничего не сломать:
1. Точки останова и интерактивную отладку вообще следует использовать с большой осторожностью. Пока программа остановлена, движущиеся части могут продолжать двигаться. Поэтому точки надо ставить ПОСЛЕ команд, которые всё останавливают, а не до. Важно помнить, что если точка стоит на строчке с командой Stop(), то команда выполнена не будет! Надо ставить на следующей строке. Если вам нужно поставить точку там, где нет тотальной остановки, её надо туда временно добавить.
2. Тем не менее, запускать весь алгоритм целиком -- опасно. Тут есть два метода:
а) Алгоритм надо разбить на отдельные этапы, между которыми программа будет вставать на паузу, а все движущиеся части останавливаться. По кнопке программа должна выполнять следующий кусок, если предыдущий прошёл успешно. А если нет -- как раз в этот момент можно будет покопаться в памяти при помощи интерактивного отладчика. Таким образом отладка будет состоять не из серии прогонов и разборов полётов, а из серий прогонов кусков 1, 1+2, 1+2+3 и т.д.
б) Начальные точки движения частей надо расположить подальше от препятствий, а диапазоны перемещений сделать маленькими, поэтому даже если система поедет не туда, она ничего не вывернет.
3. Отладка должна вестись одной рукой. Вторую надо держать на выключателе, который всё обесточивает (система должна быть разработана так, чтобы при пропадании питания по инерции ничего не ехало, но это задача не программиста; ещё одна задача не программиста -- минимизировать риск столкновения частей при штатной работе, например механически ограничить зоны деятельности разных деталей так, чтобы они никогда не пересекались).
4. Во время правки кода система должна быть выключена, а программа не должна выполняться, т.к. пока код не отлажен, что-то может поехать, пока вы отвернулись и уткнулись в монитор. У меня так поехало, причём я до сих пор не знаю, когда поехало и почему.
5. Удобство интерфейса отладочной многокнопочной утилиты (или что вы там используете) очень важно. Чем понятнее для вас всё сделано, тем меньше шанс по ошибке нажать не ту кнопку. Очевидно, что надо перед нажатием чего бы то ни было вообще по два раза проверять, что вы нажимаете. Непонятное расположение кнопок, двусмысленные надписи, разные единицы измерения в разных полях ввода -- это всё очень опасно.
6. Выдавать окошечки с кнопкой ОК для информирования вас о чём-либо -- плохая идея. Они перекрывают главное окно, а могут вообще его блокировать. Таким образом, вы теряете контроль над установкой.
7. Отдельного трактата достойна обработка исключительных ситуаций. Это дело я пока вообще только обдумываю. Например, управляющая программа может УПАСТЬ, а любые подчинённые микроконтроллеры -- зависнуть или умереть. Какие части будут продолжать двигаться после этого? Насколько долго? Сколько промасленных котов намотает на вал? Как можно от этого защититься?
Меня утешает, что тем, кто пишет ПО для спутников, приходится гораздо хуже.
