Материал: 6798

0 — запись содержит данные двоичного файла.

1 — запись обозначает конец файла, данных не содержит. Имеет характерный вид «:00000001FF».

2 — запись содержит начальный адрес сегмента памяти.

4 — запись расширенного адреса.

Байты данных, которые требуется сохранить в EPROM (их число указывается в начале записи, от 0 до 255 байт).

Последний байт в записи является контрольной суммой. Рассчитывается так чтобы сумма всех байтов в записи была равна 0.

Строка заканчивается стандартной парой CR/LF (0Dh 0Ah).

После успешной сборки проекта был получен текстовый файл (HEX-фа) LR2_BIT.hex рисунок 39:

:1000000000040020C10000008700000087000000FD

:10001000870000008700000087000000000000004B

:100020000000000000000000000000008700000049

:10003000870000000000000087000000870000002B

:1000400003B405B409B411B421B441B481B42DE9A9

:1000500001012DE901022DE901042DE901082DE935

:10006000011003BC05BC09BC11BC21BC41BC81BC56

:10007000BDE80101BDE80102BDE80104BDE80108D9

:10008000BDE801107047FEE70120C046002801D0FE

:10009000C046C046002000F002F800F002F8FFF76A

:1000A000CFBF00F001B800000746384600F002F864

:1000B000FBE7000001491820ABBEFBE72600020069

:1000C000C046C046C046C046FFF7DEFF0120801C88

:0400D0007047000075

:04000005000000C136

:00000001FF

Рисунок 39 Пример содержимого hex-файла

Рассмотрим структуру одной из записей получившегося hex-файла: :1000400003B405B409B411B421B441B481B42DE9A9

: - начало записи; 10 - количество байт данных (16 байт);

0040 - адрес памяти, куда будет помещена запись;

00 - тип записи — данные; 03B405B409B411B421B441B481B42DE9 – данные; А9 - Контрольная сумма записи.

Контрольная сумма вычисляется как дополнение по модулю 256 до нуля суммы всех байт. Т.е. нужно последовательно сложить все байты, так, чтобы результат каждого сложения занимал также один байт, при этом переполнение не учитывается и просто отбрасывается, - это и будет операция сложения по модулю 256. Далее нужно от 256 отнять полученный байт или можно сделать инверсию полученного байта и увеличить результат на 1 – это будет вычисление дополнения по модулю 256 до 0. В результате получается, что сумма по модулю 256 всех байт вместе с контрольной суммой дает ноль. Так проверяется целостность и безошибочность записи при считывании.

Посчитаем контрольную сумму для разобранной ранее записи hex-файла и сравним правильность наших расчетов.

Складываем все байты по модулю 256: 10+40+03+В4+05+В4+09+В4+11+В4+21+В4+41+В4+81+В4+2D+Е9 = 57;

Инвертируем полученный результат: not(57) = A8; Прибавляем 1: А8+1=А9.

Мы видим, что полученная контрольная сумма совпадает с той, которая была

ТУСУР, "Миландр" Каф. ЭСАУ Недяк С.П., Шаропин Ю.Б Февраль 2017 г.

сформирована в hex-файле, значит можно сделать вывод, что мы посчитали верно.

Если сравнить hex-файл с кодом сформированным дизассемблером, то мы видим, что представление порядка байтов немного разное. В hex-файле сначала идет младший байт, затем старший, а в дизассемблере наоборот, сначала старший, потом младший. Например, запись команды PUSH {R0,R1} в дизассемблере будет выглядеть следующим образом b403, а hex-файле 03B4.

6.Исследование назначения битовых полей машинного кода заданной команды.

Заданы команды Push и Pop. Необходимо исследовать битовые поля этих команд,

меняя их операнды.

Разберемся в логике построения команды в битовом поле. Возьмем для примера команду Push, продублируем ее около 10 раз с разными операндами регистра, заданными по порядку, начиная с нуля. Поставим точку останова рядом с первой командой и запустим Disassembly (рис. 40).

Рисунок 40 Отображение команды в Disassembly

Обратив внимание на изменение байтов 0xb401 , 0xb402, 0xb404, 0xb408 и т.д., где b4

– байт самой команды, проследим логику изменения младшего байта, т.е.последних двух цифр. Ей соответствует следующее пояснение:

01 есть 0000 0001 в двоичной системе для регистра R0

02 есть 0000 0010 в двоичной системе для регистра R1

04 есть 0000 0100 в двоичной системе для регистра R2

08 есть 0000 1000 в двоичной системе для регистра R3

10 есть 0001 0000 в двоичной системе для регистра R4 и т.д.

Т.е. повышение номера регистра на 1 соответствует изменению порядка единички в двоичном коде на 1 шаг влево. И переводя двоичный код в Шестнадцатеричный(HEX), мы получаем подобный порядок чисел. Но что будет, если произойдет переполнение байта?

Исходя из рисунка 41, мы видим, что вместо команды Push подключается встроенная команда сохранения регистров STR с окончанием “.W”, что значит “расширенный”. Данная команда (помимо выполнения той же цели, что и PUSH) добавляет следующий байт, чтобы старшим регистрам было, куда продолжать движение единички в двоичном коде. Но так как команда PUSH заменилась на STR, то само построение немного отличается - изменение

будет происходить уже не с двумя последними цифрами первого байта, а уже в старшем байте (рис. 41):

Рисунок 41 Изменение в старшем байте

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

Рассмотрим пример посложнее, где в команде будет уже не по одному операнду, а несколько (рис.42).

Рисунок 42 - Усложненный пример

01 есть 0000 0001 в двоичной системе для регистра R0

03 есть в двоичной системе для регистров R0,R1

07 есть в двоичной системе для регистров R0,R1,R2 0f есть в двоичной системе для регистров R0-R3