Организация обмена информацией между микроконтроллером семейства MCS-51

Страница: 3/14

На обоих этапах разработки необходимо тестировать программное обеспечение не только на эмуляторах, но и на «живом» МК, с целью выявления специфических ошибок (неправильная логика работы устройства, ошибки, связанные с эмуляцией). Это требует многократного перепрограммирования МК, что связанно с большой затратой времени (время стирания информации в ПЗУ с ультрафиолетовым, или электрическим стиранием может достигать нескольких десятков минут). Это время можно сократить используя в качестве памяти программ не ПЗУ, а ОЗУ.

Разрабатываемое устройство значительно упростит оба этапа разработки, позволяя отлаживать программное обеспечение непосредственно на «живом» МК и позволит сэкономить время, связанное с записью и стиранием тестируемых программ.

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

После получения объектного кода программы неизбежно наступает этап отладки, т.е. установления факта ее работоспособности, а также выявления и устранения ошибок. Без этого этапа разработки никакое программное обеспечение вообще не имеет права на существование.

Обычно отладка прикладного программного обеспечения осуществляется в несколько этапов. Простые (синтаксические) ошибки выявляются уже на этапе трансляции. Далее необходимо выполнить:

автономную отладку каждой процедуры в статическом режиме, позволяющую проверить правильность проводимых вычислений, правильность последовательности переходов внутри процедуры (отсутствие «зацикливания») и т.п.;

комплексную отладку программного обеспечения в статическом режиме, позволяющую проверить правильность алгоритма управления (по последовательности формирования управляющих воздействий);

комплексную отладку в динамическом режиме без подключения объекта для определения реального времени выполнения программы и ее отдельных фрагментов.

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

С использованием разрабатываемого устройства можно будет выполнять рассмотренные этапы отладки уже непосредственно на «живом» МК, подключая к нему реальные физические объекты. Эти этапы отладки можно будет объединить со следующими этапами разработки устройства – отладка отдельных фрагментов программного обеспечения на отладочном модуле в режиме реального времени. Можно будет исключить этап комплексной отладки прикладного программного обеспечения на инструментальной микроЭВМ с внутрисхемным эмулятором.

Разрабатываемое устройство должно обеспечить все необходимые возможности, доступные в кросс системах:

доступ к любому ресурсу МК;

пошаговое исполнение программ.

Разрабатываемое устройство позволит промоделировать практически все возможные варианты работы программы и тем самым убедиться в ее работоспособности. Здесь возможна проверка работоспособности программы при нештатных ситуациях в условиях поступления некорректных входных воздействий.

Можно будет моделировать среду обитания МК, т.е. различного рода объекты и датчики, подключаемые к нему.

Реферат опубликован: 16/06/2007