Главная -> Книги

(0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48) (49) (50) (51) (52) (53) (54) (55) (56) (57) (58) (59) (60) (61) (62) (63) (64) (65) (66) (67) (68) (69) (70) (71) (72) (73) (74) (75) (76) (77) (78) (79) (80) (81) (82) (83) (84) (85) (86) (87) (88) (89) (90) (91) (92) (93) (94) (95) (96) (97) (98) (99) (100) (101) (102) (103) (104) (105) (106) (107) (108) (109) (110) (111) (112) (113) (114) (115) ( 116 ) (117) (118) (119) (120) (121) (122) (123) (124) (116)

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

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

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

Главной задачей проектирования МПС является создание прикладных н системных программ. Проектирование же аппаратных средств сводится к соединениям БИС в соответствии с рекомендуемыми конфигурациями, расчетом электрических нагрузок и временных соотношений. В настоящее время отсутствуют четкие количественные критерии и характеристики оптимальности программ. Естественная традиционная оценка их по длине и, следовательно, емкости памяти может отступить на второй план по сравнению с удобством эксплуатации систем, гибкостью при расширении ее функциональных возможностей и т. п. Кроме того, удельная емкость полупроводниковой памяти постоянно уменьшается. На практике одним из нажных факторов, учитываемых при разработке программных средств, является Щ)Оизводительность системы. В общем, пока создание прикладных программ остается «более искусством, чем наукой», и здесь большую роль играют опыт и здравый смысл, которым очень трудно научить.

Разработка прикладных программ МП-систем включает в себя следующие крупные этапы, характерные для разработки любых программных средств: точную постановку решаемой проблемы и определение функциональных спецификаций; разделение проблемы на части и алго ритмизацию каждой из них - так называемое проектирование (или даже конструирование) программы; собственно программирование (коди рование); проверку и отладку программы.

Остановимся на каждом из приведенных этапов.

Разработка функциональных спецификаций. Успех проектирования в значительной мере определяется тем, насколько хорошо разработчик поиял и сформулировал решаемую проблему и трансформировал ее в рабочие характеристики системы. Общие спецификации обычно в себя



включают: четкое описание проблемы, решаемой системой; список аппаратных средств и внешних сигналов; описание связей программных модулей; полное описание системы с упором на интерфейс с ВУ; инструкцию для пользователей с описанием входных и выходных данных, реакций на особые случаи н т. п.

Практика показывает, что примерно 70 % ошибок в программах появляется из-за недостаточно полных и четких спецификаций. Такие логические ошибки трудно локализовать и исправлять. Оставшаяся треть приходится на ошибки кодирования, исправлять которые обычно проще. Разработка адекватных спецификаций на самом раннем этапе проектирования экономит много времени и средств. Здесь целесообразно использовать графические представления решаемых задач в виде блок-схемы алгоритмов, диаграмм н таблиц. Наконец, после оформления функциональных спецификаций рекомендуется строго нх придерживаться.

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

Основные блоки выделяются из функциональных спецификаций и содержат управляющий блок (основную,программу), блоки интерфейса с внешними устройствами (ВУ), блоки реакций на прерывания и блоки разнообразного преобразования данных. Особенное внимание уделяется организации ввода-вывода (ВВ).

Большое значение имеет правильная организация структуры данных. Следует задать и описать форматы входа и выхода, промежуточных и окончательных результатов, возможные варианты упаковки данных, выбрать способы размещения данных в памяти. Целесообразно каким-либо образом «регуляризировать» данные в виде таблиц, массивов, списков и т. п. Рациональная организация данных поможет сократить длину программы и уменьшить время ее выполнения.

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

При разработке алгоритмов значительное внимание приходится уделять временным ограничениям, характерным для большинства прикладных программ. Часто производительность системы можно существенно повысить за счет увеличения объема памяти (примером может служить табличная реализация функций). ,

Современная методика структурного программирования рекоменду-ет составлять программы из небольшого числа стандартных программных Структур (последовательная структура, обобщенный цикл и дихотомическое решение). Главной особенностью этих структур являетря наличие одной точки входа и одной точки выхода, что упрощает объ-



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

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

Следует тщательно спланировать программу и обратить, серьезное внимание на ее документирование. Обычно программа начинается с заголовка-комментария, содержащего основные характеристики программы: имя (название), дату составления, версию, требования к памяти, собственно функции програ.ммы и особенности ВВ. После заголовка следуют директивы определения непосредственных данных, назначения адресов портов ВВ, директивы резервирования памяти, таблицы переходов и подпрограммы ВВ. После ннх размещаются основная программа, представляющая собой последовательность инициализаций и вызовов подпрограмм, затем подпрограммы в порядке уровней вложения и таблицы данных.

Для наглядного представления размещения элементов программы можно построить карту памяти с выделением следующих областей: специальной памяти, определяемой особенностями МП; рабочей памяти стека, подпрограмм ВВ, буферных областей; общих областей для передачи параметров; памяти портов ВВ при использовании ВВ, отображенного на память; резидентной памяти для системных программ. Целесообразно назначать области памяти в пределах страниц, что упрощает дешифрацию адресов и их преобразования.

Проверка и отладка. Тесно связанные друг с другом проверка и отладка программы заключаются в локализации и удалении из программы ошибок. Проверка начинается с тщательного просмотра программы с последующим переходом к отладке подпрограмм низшего уровня, которые не вызывают других подпрограмм. Следует убедиться, что кодирование соответствует логике блок-схемы, что данные правильны, а циклы верно инициализируются и заканчиваются. Необходимо разработать конкретные примеры (тесты) для каждого блока. В тестах предусматриваются наихудшие случаи и предельные значения параметров. Закончив отладку простейших подпрограмм, можно переходить к подпрограммам следующего уровня и так до основной программы. Завершается отладка функциональным тестом, проверяющим работу программы в условиях эксплуатации. Иногда такой тест включается в прикладную программу как средство самоконтроля.

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



(0) (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41) (42) (43) (44) (45) (46) (47) (48) (49) (50) (51) (52) (53) (54) (55) (56) (57) (58) (59) (60) (61) (62) (63) (64) (65) (66) (67) (68) (69) (70) (71) (72) (73) (74) (75) (76) (77) (78) (79) (80) (81) (82) (83) (84) (85) (86) (87) (88) (89) (90) (91) (92) (93) (94) (95) (96) (97) (98) (99) (100) (101) (102) (103) (104) (105) (106) (107) (108) (109) (110) (111) (112) (113) (114) (115) ( 116 ) (117) (118) (119) (120) (121) (122) (123) (124)