Обмен информацией между персональным компьютером и микроконтроллером семейства MCS-51 фирмы Intel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задачей данной работы является разработка необходимого программного обеспечения и аппаратных средств сопряжения МК и ПК.

1.1 Постановка глобальных задач

Организация обмена информацией предполагает:

    • рассмотрение вопросов аппаратных средств;
    • создание необходимого программного обеспечения.

Аппаратные средства должны обеспечить:

    • физическое сопряжение портов ПК и микроконтроллера;
    • сопряжение МК с внешней памятью программ.

Программное обеспечение должно обеспечить решение следующего ряда задач:

    • запись программы, отлаженной на ПК, в память программ и данных МК;
    • выполнение программы в режиме реального времени;
    • выполнение программы в пошаговом режиме;
    • запись информации из ПК в программно-доступные узлы МК;
    • чтение содержимого программно-доступных узлов и индикация их на мониторе ПК.

1.2 Анализ предыдущей работы

Вопрос об организации обмена информацией между персональным компьютером и микроконтроллером семейства Intel MCS-51 был уже рассмотрен в бакалаврской работе [3]. В этой работе были рассмотрены проблемы аппаратного и программного сопряжения МК с ПК в составе планируемой лабораторной установки.