Статья, 40 c.
Для кого эта статья. Статья адресована программистам PIC-контроллеров младшего и среднего семейства, пишущим на языке ассемблера. Предполагается, что читатель знаком с архитектурой, набором инструкций и набором регистров специального назначения данных контроллеров. Подход, изложенный мной в этой статье, - не единственно правильный. И, само собой, как и любой другой подход, годится не на все случаи жизни. Без труда можно придумать пример задачи, для решения которой данный подход окажется неэффективным. Но и в этом случае изложенным здесь материалом можно будет воспользоваться как шаблоном для формулирования собственных правил. Программа, ее стиль – это лицо программиста. По ее внешнему виду можно многое сказать о нем. Так что не теряйте лица! Существует распространенное заблуждение о том, что хорошее знание архитектуры контроллера – это гарантия качественного программирования. Это не так. Это все равно, что рассчитывать на то, что знание устройства стамески позволит вам заниматься резьбой по дереву. Одной из характеристик качественного программирования является оформление исходных текстов программ. Многие недооценивают ее важность. Результатом пренебрежения качественным оформлением является не только не наглядный исходный текст программы, но и сложность сопровождения кода, отладки и повторного использования наработок. А внесение модификаций в такой код часто может привести к тому, что он перестает быть рабочим и начинает сбоить. Возможно, многие уже сталкивались с последствиями плохого оформления исходников. Наверняка, заглядывая в программу спустя сравнительно большое время, чтобы внести незначительные исправления или чтобы освежить в памяти какие-то программные решения, многие сталкивались с тем, что разобраться в коде порой сложнее, чем написать все заново. Я уже не говорю о сложностях, возникающих при попытке разобраться с неаккуратным исходником, которым с вами кто-то поделился по доброте душевной (многие любят делиться своими наработками, не задумываясь об их качестве). Но самые большие неприятности возникают тогда, когда программа становится тяжело сопровождаемой, и, казалось бы, незначительные доработки (как, например, переназначение портов ввода вывода или пересчет временных задержек) требуют не только огромных трудозатрат, но и являются причинами внесения в программу трудноуловимых ошибок.
