Программирование DSP Форматы файлов VisualDSP++ Thu, March 28 2024  

Поделиться

Нашли опечатку?

Пожалуйста, сообщите об этом - просто выделите ошибочное слово или фразу и нажмите Shift Enter.

Форматы файлов VisualDSP++ Печать
Добавил(а) microsin   

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

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

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

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

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

Поддерживаются несколько диалектов языка C: pure (portable) ANSI C, и как минимум 2 подтипа(1) 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. Числовые форматы.

Представление числа Описание
0xnumber
H#number
h#number
Число в шестнадцатеричном формате
number
D#number
d#number
Число в десятичном формате
B#number
b#number
Число в двоичном формате
O#number
o#number
Число в восьмеричном формате

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

Заголовочные файлы. Это текстовые файлы (с расширением .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 содержит поле расширенного линейного адреса, запись данных по этому адресу, контрольную сумму строки, конец строки и маркер конца файла.

:020000040000FA Поле расширенного линейного адреса (extended linear address record), с которого начинается строка файла Intel HEX-32.
:0402100000FE03F0F9 Поле данных (data record) с контрольной суммой данных. Каждая строка после контрольной суммы содержит стандартный маркер конца строки текстового файла (CRLF).
:00000001FF Маркер конца файла (End-of-file record).

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

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

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

Поле Назначение
:020000040000FA Пример записи
: Символ начала строки
 02 Количество байт (всегда 02)
   0000 Адрес (всегда 0000)
       04 Тип записи
         0000 Адрес смещения
             FA Контрольная сумма

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

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

Поле Назначение
:0402100000FE03F0F9 Пример записи
: Символ начала строки
 04 Количество байт для этой записи
   0210 Адрес
       00 Тип записи
         00 Первый байт данных
               F0 Последний байт данных
                 F9 Контрольная сумма

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

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

Поле Назначение
:00000001FF Запись конца файла
: Символ начала строки
 00 Количество байт (всегда 0 для этой записи)
   0000 Адрес первого байта
       01 Тип записи
         FF Контрольная сумма

В комплект поставки 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 начинается с записи заголовка и заканчивается записью завершения. Между этими двумя записями находятся записи данных, по одной на строку:

S00600004844521B Запись заголовка (Header record)
S10D00043C4034343426142226084C Запись данных (Data record, S1)
S903000DEF Запись завершения (Termination record, S1)

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

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

Поле Назначение
S00600004844521B Пример записи
S0 Символы начала строки
  06 Количество байт для этой записи
    0000 Адрес для первого байта данных
        484452 Идентифицирует запись, которая идет дальше
              1B Контрольная сумма

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

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

Поле Назначение
S10D00043C4034343426142226084C Пример записи
S1 Тип записи
  0D Количество байт для этой записи
    0004 Адрес для первого байта данных
        3C Первый байт данных
                          08 Последний байт данных
                            4C Контрольная сумма

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

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

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

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

Поле Назначение
S903000DEF Пример записи
S9 Начальные символы
  03 Количество байт для этой записи
    000D Адрес
        EF Контрольная сумма

Запись завершения 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.

Поле Назначение
20008000000000080000001E Пример записи
20 Ширина адреса и длина полей (в битах)
  00 Зарезервировано
    80 Флаги PROM splitter (80 = PM, 00 = DM)
      00 Флаги, определяемые пользователем (загружаются
с помощью ключа -u)
        00000008 Начальный адрес блока данных
                0000001E Количество байт, которые идут далее

В выше приведенном примере поля начального адреса и длины блока имеют длину 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.

Число в формате HEX Число в двоичном формате Результат (с обрезкой
или заполнением)
A5A5A 1010 0101 1010 0101 1010 1010 0101 1010 0101 1010
FFFF1 1111 1111 1111 1111 0001 1111 1111 1111 1111 0001
A5A5 1010 0101 1010 0101 0000 1010 0101 1010 0101
5A5A5 0101 1010 0101 1010 0101 0101 1010 0101 1010 0101
11111 0001 0001 0001 0001 0001 0001 0001 0001 0001 0001
123456 0001 0010 0011 0100 0101 0110 0010 0011 0100 0101 0110

[Утилиты]

Вместе со средой разработки 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.

Ключ Описание
-s1 Задает выходной формат Motorola S1
-s2 Задает выходной формат Motorola S2
-s3 Задает формат по умолчанию Motorola S3. Та же самая установка
применяется, когда в командной строке не указаны опции.
-StripHex Генерирует не форматированный файл данных
-o Имя выходного файла. Если эта опция не указана, то автоматически
сгенерируется имя из входного файла с расширением *.s (input_file.s).

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.

Ключ Описание
-V Задает вывод подробной диагностики (verbose)
-r Принудительная загрузка в RAM
-k Разрешает трассировку ядра (kernel trace) при загрузке
(используется для отладки)
-s# Устанавливает размер стека приложения
-o file_name Задает имя выходного файла
-h Печатает список ключей командной строки (подсказка)
-v Выводит информацию о версии

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.

Ключ Описание
-D Выводит дамп файла, собранного для указанного процессора
-help Печатает в stdout список ключей командной строки (подсказка)
-o file_name Печатает вывод в указанный выходной файл вместо stdout
-v Выводит информацию о версии

Другие утилиты 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.

 

Добавить комментарий


Защитный код
Обновить

Top of Page