В этой статье (перевод Приложений документа [1]) описываются форматы файлов VisualDSP++, в которых подготавливаются исходные данные, и в которых сохраняются выходные данные компиляторов и утилит для преобразования форматов. Под исходными данными подразумевается проект приложения, его модули исходного кода и настройки. Под выходными данными подразумеваются генерируемые компилятором и линкером результаты сборки.

[Исходные файлы]

К исходным файлам относятся:

• Модули исходного кода на языке C/C++
• Модули исходного кода на ассемблере
• Файлы данных инициализации на ассемблере
• Заголовочные файлы
• Файлы настроек линкера (Linker Description Files, LDF)
• Файлы командной строки линкера

Модули исходного кода на языке C/C++. Это обычные текстовые файлы (с расширениями .c, .cpp, .cxx, и т. д.) в которых содержится код C/C++, директивы компилятора, возможные вставки кода ассемблера и директив, и часто в них также присутствуют команды препроцессора.

Поддерживаются несколько диалектов языка C: pure (portable) ANSI C, и как минимум 2 подтипа⁽¹⁾ ANSI C, где добавлена поддержка расширений языка компании Analog Devices (ADI extensions). Эти расширения включают обозначение типов памяти для определенных объектов данных, директивы сегментов, используемые линкером для структурирования и размещения исполняемых файлов.

Компилятор C/C++, библиотека run-time, как и определение расширений ADI для ANSI C, подробно описаны в документе "VisualDSP++ 5.0 C/C++ Compiler and Library Manual for Blackfin Processors".

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

Модули исходного кода на ассемблере. Это тоже текстовые файлы (обычно с расширением .asm), содержащие инструкции ассемблера, директивы ассемблера и (опционально) команды препроцессора. Для получения информации по инструкциям ассемблера (системе команд) см. руководство "Programming Reference manual", относящееся к Вашему процессору (для Blackfin см. [4]).

Набор инструкций процессора снабжен поддержкой директив ассемблера. Команды препроцессора управляют обработкой макросов и сборкой или компиляцией, которой управляют определенные условия.

Для получения информации по ассемблеру и препроцессору см. руководство "VisualDSP++ 5.0 Assembler and Preprocessor Manual".

Файлы данных инициализации на ассемблере. Это также текстовые файлы (с расширением .dat), содержащие данные с фиксированной или плавающей точкой. Эти файлы предоставляют данные инициализации для директивы .VAR ассемблера, или применяются в других операциях инструментария VisualDSP++.

Когда директива .VAR использует .dat-файл для инициализации данных, ассемблер читает файл данных и инициализирует буфер в выходном объектом файле (.doj). Файлы данных содержат по одному значению данных в одной строке, и могут иметь любое количество строк.

Используемое расширение .dat чисто мнемоническое, чтобы удобнее было ориентироваться в типе исходного файла (dat это сокращение от "data", что означает данные). Директива для подключения файла #include < имя_файла > в качестве аргумента может принимать любое имя файла с любым расширением, оно не обязательно должно быть dat.

Значения с фиксированной точкой (целые числа) в файлах данных могут иметь знак (signed), и могут содержать десятичные (decimal), шестнадцатеричные (hexadecimal), восьмеричные (octal) или двоичные (binary) значения. Ассемблер использует префиксы, перечисленные в таблице A-1, чтобы отделять друг от друга разные форматы чисел.

Таблица A-1. Числовые форматы.

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

Заголовочные файлы. Это текстовые файлы (с расширением .h), которые содержат макросы или другие директивы препроцессора, подставляемые в исходные файлы. Для получения информации по макросам и командам препроцессора обратитесь к руководству "VisualDSP++ 5.0 Assembler and Preprocessor Manual".

Файлы настроек линкера. LDF-файлы (Linker Description Files, имеют расширение .ldf) это текстовые файлы, которые содержат команды для линкера на специальном скриптовом языке. Для получения подробной информации см. руководство "VisualDSP++ 5.0 Linker and Utilities Manual" (также см. [5]).

Файлы командной строки линкера. Файлы командной строки линкера (с расширением .txt) это текстовые файлы, которые содержат опции командной строки линкера. Для дополнительной информации по командной строке линкера см. руководство "VisualDSP++ 5.0 Linker and Utilities Manual" (также см. [5]).

[Файлы сборки]

Это файлы, которые генерируют инструменты разработки VisualDSP++ при сборке проекта:

• Объектные файлы ассемблера
• Библиотечные файлы
• Выходные файлы линкера
• Файлы отображения на память (Memory Map Files)
• Выходные файлы загрузчика в формате Intel HEX-32
• Выходные файлы загрузчика в формате Include
• Выходные файлы загрузчика в формате Binary
• Выходные файлы загрузчика в формате Motorola S-Record
• Выходные файлы сплиттера в формате Intel HEX-32
• Выходные файлы сплиттера в формате Byte-Stacked
• Выходные файлы сплиттера в формате ASCII

Объектные файлы ассемблера. Выходные объектные файлы ассемблера (.doj) это двоичные файлы, предназначенные для линковки (ELF). Объектные файлы содержат код, не привязанный к абсолютному адресному пространству процессора. В нем содержится перемещаемый код, которые привязывается к абсолютным адресам линкером, и также содержит в себе отладочную информацию для сегментов памяти DSP, предназначенную для поддержки отладки программы по тексту исходного кода. Линкер обрабатывает объектные файлы, выдавая в качестве результата исполняемый файл (executable file, файл с расширением .dxe) в формате ELF. Подробно про формат ELF см. документ [2].

Библиотечные файлы. Это файлы с расширением (.dlb), которые генерирует утилита архиватора библиотек (archiver). Это двоичные, объектные файлы, предназначенные для линковки готового кода (в формате ELF). Библиотечные файлы (в предыдущих релизах инструментария они назывались архивами) содержат один или большее количество объектных файлов (элементов архива).

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

Утилита библиотекаря (archiver) автоматически конвертирует входные объекты из COFF в формат ELF.

Выходные файлы линкера. Это двоичный исполняемый код (ELF), файлы получают расширения .dxe (исполняемый код), .sm (файлы общей памяти), .ovl (файлы оверлея). Исполняемые файлы содержат код программы и отладочную информацию. В исполняемом коде линкер преобразует все метки и имена объектных файлов в абсолютные адреса. Для получения информации по формату ELF, который применяется для исполняемых файлов, см. тексты "TIS Committee" в документе [2].

Утилиты загрузчика/сплиттера (loader/splitter [6]) используются для преобразования исполняемых файлов в загружаемые (boot-loadable, которые переносятся в оперативную память кодом Boot ROM) или не загружаемые (non-bootable, эти файлы содержат непосредственно исполняемый код).

Для преобразования исполняемых файлов в загружаемые (boot-loadable, .ldr) процессорами Analog Devices используют утилиту загрузчика [6]. Как только программа приложения полностью проверена и отлажена, она готова для преобразования в загружаемый файл с расширением .ldr. Загружаемый файл программируется в энергонезависимую память процессорной системы, и при включении питания код Boot ROM берет оттуда данные для исполняемого кода, помещает его в оперативную память, и после этого запускает на выполнение [7]. Загружаемый файл прошивается в энергонезависимую память обычно при помощи JTAG и плагина Flash Programmer, либо для этого может использоваться специальный программатор.

Утилита сплиттера [6] обрабатывает исполняемый файл и генерирует файл не загружаемого образа PROM. Файл PROM называется "не загружаемым", потому что он размещается в адресном пространстве процессора как есть, и сразу готов к исполнению в нем кода без каких-либо загрузок и преобразований.

Файлы отображения на память (Memory Map Files). Линкер опционально может генерировать файл, где содержится информация по размещению различных объектов программы по абсолютным адресам процессора. Этот файл называется файл карты памяти, или файл отображения на память (memory map), и он генерируется как текстовый файл в формате .xml. Этот файл .xml содержит общую информацию по использованию памяти, определенной командой MEMORY{} в файле .ldf, и в нем перечислены все абсолютные символы программы (процедуры, функции, переменные), предоставленные им абсолютные адреса и количество занимаемой ими памяти.

Выходные файлы загрузчика в формате Intel HEX-32. Это выходной файл, который генерирует утилита загрузчика [6] в формате Intel HEX-32 (файл с расширением *.ldr). Эти файлы поддерживают промышленные 8-битные устройства памяти PROM, и могут использоваться как входные данные для программатора. Т. е. их можно запрограммировать в системную память процессорной системы, из которой код Boot ROM процессора будет брать данные для загрузки [7].

Следующий пример показывает, как выглядит формат Intel HEX-32 в выходном файле утилиты загрузчика. Каждая строка файла формата Intel HEX-32 содержит поле расширенного линейного адреса, запись данных по этому адресу, контрольную сумму строки, конец строки и маркер конца файла.

Поле расширенного линейного адреса используется потому, что поле данных имеет 4-символьное (16-битное) поле адреса, но во многих случаях 16-битного адресного пространства недостаточно, чтобы в нем разместился весь требуемый код, т. е. в PROM может размещаться больше, чем 0xFFFF байт. Записи расширенного линейного адреса указывают биты 31..16 адреса для записей данных, которые идут за ним.

Таблица A-2 показывает пример декодирования поля расширенного линейного адреса.

Таблица A-2. Пример записи Extended Linear Address.

Таблица A-3 показывает пример организации поля данных.

Таблица A-3. Пример Data Record.

Таблица A-4 показывает маркер конца файла.

Таблица A-4. Пример End-of-File Record.

В комплект поставки VisualDSP++ включена утилита для преобразования файла Intel HEX в файл формата Motorola S-record или в файл данных. Подробнее см. ниже описание утилиты hexutil.

Выходные файлы загрузчика в формате Include. Утилита загрузчика может генерировать выходной файл в формате подключаемого файла (тоже имеет расширение *.ldr). Эти файлы позволяют подключение файла загрузки в программу на языке C.

Ширина слова (8 или 16 бит) файла загрузки зависит от указанного способа загрузки (boot type). Подобно выходному файлу в формате Intel HEX-32, выходной файл загрузки в формате Include имеет некоторые базовые часть с следующем порядке.

1. Код инициализации (применяется для некоторых процессоров Blackfin).
2. Boot kernel (код ядра, применяется для некоторых процессоров Blackfin, SHARC и TigerSHARC).
3. Код приложения пользователя.
4. Сохраненный код пользователя, конфликтующий с кодом инициализации.
5. Сохраненный код пользователя, конфликтующий с кодом kernel.

Код инициализации это опциональная первая часть файла загрузки для некоторых процессоров Blackfin, в то время как код kernel это часть кода для некоторых процессоров Blackfin, SHARC и TigerSHARC. Код приложения идет за сохраненным кодом пользователя.

Файлы в формате Include это текстовые файлы ASCII, которые состоят из 48-битных инструкций, по одной на строку (для процессоров SHARC). Каждая инструкция представлена тремя числами в 16-битном шестнадцатеричном формате. Для каждой 48-битной инструкции порядок следования данных такой: младшие 16 бит, средние 16 бит, старшие 16 бит. Вот пример таких строк файла в формате Include:

0x005c, 0x0620, 0x0620,
0x0045, 0x1103, 0x1103,
0x00c2, 0x06be, 0x06be

Этот пример показывает, как подключается этот файл в программе на языке C:

const unsigned loader_file[] =
{

   #include "foo.ldr"
};

const unsigned loader_file_count = sizeof loader_file
                                 / sizeof loader_file[0];

Переменная loader_file_count отражает реальное количество элементов массива, и не может использоваться для обработки данных.

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

Двоичный формат Binary использует меньше всего пространства на диске по сравнению с другими форматами файлов. Файлы Binary соответствуют тому же самому содержимому памяти, что и соответствующие файлы ASCII, но имеют двоичный формат, другого отличия нет.

Выходные файлы загрузчика в формате Motorola S-Record. Утилиты загрузчика (loader) и сплиттера (PROM splitter) могут генерировать выходные файлы в формате Motorola S-record (расширение файла .s_#), которые удовлетворяют стандарту Intel. Три таких формата, поддерживаемые утилитами загрузчика и сплиттера, отличаются только шириной поля адреса: S1 (16 бит), S2 (24 бита) или S3 (32 бита).

Файл S-record начинается с записи заголовка и заканчивается записью завершения. Между этими двумя записями находятся записи данных, по одной на строку:

В таблице A-5 показана организация примера записи заголовка.

Таблица A-5. Пример Header Record.

Таблица A-6 показывает организацию записи данных S1.

Таблица A-6. Пример S1 Data Record.

Запись данных S2 имеет тот же формат, за исключением того, что в начале строки находится S2, и поле адреса состоит из 6 символов. Поле данных S3 устроено так же, только в начале находится S3, и поле адреса состоит из 8 символов.

Запись завершения содержит поле адреса 16-битной, 24-битной или 32-битной ширины в том же формате, что и предыдущие записи, и начинается с S9.

Таблица A-7 показывает организацию записи завершения S1.

Таблица A-7. Пример S1 Termination Record.

Запись завершения S2 имеет тот же формат, только начинается с S8, и имеет поле адреса из 6 символов. Запись завершения S3 имеет тот же формат, только начинается с S7, и имеет поле адреса из 8 символов.

Для дополнительной информации см. ниже описание утилиты hexutil.

Выходные файлы сплиттера в формате Intel HEX-32. Это текстовые файлы с расширением .h_#. Они могут быть запрограммированы в PROM процессорной системы точно так же, как и файлы загрузчика Intel HEX-32, и имеют такой же формат.

Утилита сплиттера подготавливает набор файлов PROM, каждый из которых содержит порцию инструкций или данных, без какой-либо лишней служебной информации для загрузки. Эта конфигурация выходного файла отличается от выходного файла утилиты загрузчика.

Выходные файлы сплиттера в формате Byte-Stacked. Утилита сплиттера может генерировать файлы в формате Byte-Stacked (с расширением .stk). Эти файлы не предназначены для PROM-ов, но идеально подходят для перемещений данных микроконтроллерами.

Файл формата Byte-Stacked включает серию из одной строки заголовка, за которым идет блок (одна или несколько строк) данных. Последняя строка файла это заголовок, который сигнализирует о конце файла.

Строки состоят из текста ASCII, представляющих шестнадцатеричные цифры. 2 таких символа представляют 1 байт. Например, F3 представляет десятичное значение 243.

Таблица A-8 показывает пример записи заголовка в формате Byte-Stacked.

Таблица A-8. Пример Header Record в формате Byte-Stacked.

В выше приведенном примере поля начального адреса и длины блока имеют длину 32 (0x20) бита. Файл содержит данные памяти программ (старший бит MSB это только флаг, которые в настоящее время используется в поле флагов PROM splitter). Ни один флаг пользователя не установлен. Адрес первой ячейки в блоке 0x08. Блок содержит 30 (0x1E) байт (5 слов кода памяти программ). Количество идущих следом байт (до следующего поля заголовка или до записи завершения) должно быть не равно 0.

Блок записей данных следует за своим заголовком, 5 байт на строку для памяти данных, и 6 байт на строку для памяти программ или другой физической ширины памяти. Пример:

Секция памяти программ (код или данные):

3C4034343426
142226083C15

Секция памяти данных:

3C40343434
2614222608

Секция памяти DATA64:

1122334455667788
99AABBCCDDEEFF00

Байты идут слева направо, первым идет самый значащий, последним наименее значащий.

У записи завершения тот же формат, что и записи заголовка, за исключением того, что самое правое поле (количество записей) содержит все нули.

Выходные файлы сплиттера в формате ASCII. Утилита сплиттера Blackfin может генерировать файлы в формате ASCII с расширением .ldr. Формат ASCII это текстовое представление образов памяти ROM, которые могут получать последующую обработку пользователями.

Пример памяти данных (Data Memory, DM):

ext_data { TYPE(DM ROM) START(0x010000) END(0x010003) WIDTH(8) }

Эта секция DM даст в результате следующий код.

00010000 /* 32-битное логическое поле адреса */

00000004 /* 32-битное логическое поле длины  */

00020201 /* 32-битное слово управления: умножение 2x адреса */
         /* 02 байт логическая ширина, 01 байт физическая ширина */

00000000 /* зарезервировано */

0x12     /* 1-е слово данных, данные DM 8-битные */

0x56

0x9A

0xDE     /* 4-е (последнее) слово данных */
CRC16    /* опциональное поле, появление которого управляется ключом -checksum */

[Файлы отладчика]

Файлы отладчика предоставляют входную информацию для отладчика, чтобы определить поддержку симуляции или эмуляции выполнения кода Вашей программы. Отладчик потребляет все типы исполняемых файлов, генерируемых линкером (.dxe, .sm, .ovl). Для симуляции ввода/вывода отладчик также потребляет форматы данных ассемблера (.dat) и загружаемых файлов (.ldr).

Стандартный шестнадцатеричный формат для файла данных SPORT содержит одно целочисленное значение на строку. Шестнадцатеричные цифры не требуют наличия префикса 0x. Значение может иметь любое количество цифр, но данные из них читаются в регистр SPORT следующим образом:

• Шестнадцатеричное число преобразуется в двоичное.
• Количество прочитанных бит этого двоичного числа соответствует размеру слова регистра SPORT, и читаемые биты начинаются с младшего бита (LSB). Если количество прочитанных бит меньше, чем ширина регистра SPORT, то остальные биты заполняются нулями. Если ширина слова регистра SPORT меньше, чем количество прочитанных бит, то старшие, не поместившиеся биты отбрасываются.

В следующем примере (таблица A-9), регистр SPORT устанавливается для 20-битного слова, и файл данных содержит шестнадцатеричные числа. Симулятор преобразует шестнадцатеричные числа в двоичные, и дополняет нулями или обрезает предоставленные данные, подгоняя их под размер слова SPORT. A5A5 дополняется, и 123456 обрезается.

Таблица A-9. Пример файла данных SPORT.

[Утилиты]

Вместе со средой разработки VisualDSP++ поставляются несколько утилит, которые предназначены для запуска только из командной строки.

hexutil, преобразователь файлов из формата HEX-32 в формат S-Record. Эта утилита (консольная программа HexUtil.exe) конвертирует файл образа загрузки (.ldr) из формата Intel HEX-32 в формат Motorola S-record, или генерирует не форматированный файл данных.

Синтаксис вызова:

hexutil input_file [-s1|s2|s3|StripHex] [-o file_name]

Параметр input_file это имя входного файла .ldr, который сгенерировала утилита сплиттера VisualDSP++. Параметр file_name это соответственно имя выходного файла.

В таблице B-1 показаны не обязательные ключи, используемые в командной строке утилиты hexutil.

Таблица B-1. Опции командной строки hexutil.

elf2flt, преобразователь файлов из формата ELF в формат BFLT. Эта утилита (консольная программа (elf2flt.exe) конвертирует исполняемый файл (.dxe) из формата Executable and Linkable Format (ELF) в формат Binary Flat Format (BFLT).

Файл .bflt содержит 3 выходных секции: text, data и bss. Выходные секции определены стандартом файла ELF. Файл .bflt может быть загружен и выполнен в рабочем окружении операционной системы uClinux.

Для дополнительной информации по формату файла BFLT см. [3].

Утилита elf2flt в настоящее время поддерживает ELF-файлы, скомпилированные для архитектур Blackfin и SHARC. Утилита elf2flt реализует ревизию 5 для flat relocation type. Для дополнительной информации см. структуру BFLT relocation, определенную в flat.h.

Утилита elf2flt не поддерживает ELF-файлы с позиционно-независимым кодом и таблицей глобальных смещений (position-independent code, PIC и  global offset table, GOT). Утилита elf2flt не может сжимать сегменты text и data с помощью gzip.

Синтаксис:

elf2flt [-V|r|k] [-s #] [-o file_name] elf_input_file

Параметр elf_input_file задает имя файла .dxe, который сгенерировал линкер VisualDSP++.

Таблица B-2 показывает не обязательные ключи, используемые утилитой elf2flt.

Таблица B-2. Опции командной строки elf2flt.

fltdump, генератор дампа файла BFLT. Утилита BFLT file dumper (fltdump.exe) распаковывает данные из исполняемых файлов формата BFLT (.bflt), и выдает текст, показывающий его содержимое.

Утилита fltdump печатает все содержимое файла .bflt в шестнадцатеричном виде. Дополнительно fltdump печатает секции text как список дизассемблированных инструкций процессора.

Для дополнительной информации по формату файла BFLT см. [3].

Синтаксис:

fltdump [switch…] [object_file]

Здесь параметр object_file задает имя файла .bflt, содержимое которого распечатывается.

Таблица B-3 показывает не обязательные ключи командной строки fltdump.

Таблица B-3. Опции командной строки BFLT File Dumper.

Другие утилиты VisualDSP++, например ELF file dumper, описаны в руководстве "VisualDSP++ 5.0 Linker and Utilities Manual" или встроенном Help среды VisualDSP++.

[Ссылки]

1. VisualDSP++ 5.0 Loader and Utilities Manual site:analog.com.
2. (1993) Executable and Linkable Format (ELF) V1.1 from the Portable Formats Specification V1.1, Tools Interface Standards (TIS) Committee.
3. uClinux - BFLT Binary Flat Format site:beyondlogic.org.
4. Blackfin: система команд (ассемблер) - часть 1.
5. Использование линкера VisualDSP++.
6. Blackfin: утилита elfloader.exe.
7. Как происходит загрузка ADSP-BF533 Blackfin.
8. Типы файлов VisualDSP.