Работа с файлами по средствам функций языка С

Необходимо запустить ИСР CCS в режиме симуляции. Создать новый проект под именем «exp_2» в папке «laba_2».

Теперь нужно создать и добавить к проекту исходный код программы, который находится в файле «main.c» (листинг 2.1). Суть исходного кода состоит в том, что входной файл «inStereo.wav» (необходимо создать папку «Data» и скопировать этот файл в нее) открывается для чтения, а в выходные файлы «outLeftCh.wav» и «outRightCh.wav», будет записан звуковой моно сигнал, полученный разложением входного файла на левый и правый канал.

 

Листинг 2.1.

#include <stdio.h> #include "fiel_wav.h"   void main() { FILE *inFile; // File pointer of input signal FILE *outLeftFile; // File pointer of left channel output signal FILE *outRightFile; // File pointer of right channel output signal   short x[4]; char wavHd[44];   inFile = fopen("..\\data\\inStereo.wav", "rb");   if (inFile == NULL) { printf("Can't open inStereo.wav"); exit(0); }   outLeftFile = fopen("..\\data\\outLeftCh.wav", "wb"); outRightFile = fopen("..\\data\\outRightCh.wav", "wb");   // Skip input wav file header fread(wavHd, sizeof(char), 44, inFile);   // Add wav header to left and right channel output files fwrite(wavHeader, sizeof(char), 44, outLeftFile); fwrite(wavHeader, sizeof(char), 44, outRightFile);   // Read stereo input and write to left/right channels while((fread(x, sizeof(char), 4, inFile) == 4)) { fwrite(&x[0], sizeof(char), 2, outLeftFile); fwrite(&x[2], sizeof(char), 2, outRightFile); }   fclose(inFile); fclose(outLeftFile); fclose(outRightFile); }

Перед тем как записывать данные в wav файл, в него нужно записать заголовок, состоящий из 44 байт, этот заголовок по своей цели аналогичен заголовку подключаемого файла через точку зондирования, и содержит основную информацию о «теле» файла. Описание wav заголовка приведено в таблице 2.1

Таблица 2.1.

Номера байт	Описание
12 байтный заголовок RIFF файла
0 - 3	Коды символов 'R' 'I' 'F' 'F' в ASCII.
4 - 7	Длина файла минус первые 8 байт заголовка RIFF (4 байта для слова "WAVE" + 24 байтный заголовок, описывающий формат записанных данных + 8 байт для блока, описывающего данные + актуальный размер блока данных)
8 - 11	Коды символов 'W' 'A' 'V' 'E' в ASCII.
24 байтный заголовок, описывающий формат записанных данных
0 - 3	Коды символов 'f' 'm' 't' ' ' в ASCII (последний пробел).
4 - 7	Длина блока, описывающего формат записанных данных (всегда 16).
8 - 9	Заполнение файла. Всегда 1.
10- 11	Число каналов. 1 - моно, 2 - стерео.
12- 15	Частота дискретизации
16- 19	Число байт в секунду.
20- 21	Байт в образце (sample). 1 для 8 бит моно, 2 для 8 бит стерео или 16 бит моно, 4 для 16 бит стерео.
22- 23	Количество бит которыми кодируется при оцифровки сигнала.
Блок данных
0 - 3	Коды символов 'd' 'a' 't' 'a' в ASCII.
4 - 7	Длина данных в байтах.

 

Заголовок файлов «outLeftCh.wav» и «outRightCh.wav» описывается в заголовочном файле «fiel_wav.h» и представлен в листинге 2.2. Файл «fiel_wav.h» должен находится в одной директории с прокутом.

Листинг 2.2.

// This wav file header is pre-calculated // It can only be used for this experiment short wavHeader[44]={ 0x52, 0x49, 0x46, 0x46, // RIFF 0x2E, 0x8D, 0x01, 0x00, // 101678 (36 bytes + 101642 bytes data) 0x57, 0x41, 0x56, 0x45, // WAVE 0x66, 0x6D, 0x74, 0x20, // Formatted 0x10, 0x00, 0x00, 0x00, // PCM audio 0x01, 0x00, 0x01, 0x00, // Linear PCM, 1-channel 0x40, 0x1F, 0x00, 0x00, // 8 kHz sampling 0x80, 0x3E, 0x00, 0x00, // Byte rate = 16000 0x02, 0x00, 0x10, 0x00, // Block align = 2, 16-bit/sample 0x64, 0x61, 0x74, 0x61, // Data 0x0A, 0x8D, 0x01, 0x00}; // 101642 data bytes

 

Следующим шагом нужно подключить к проекту командный файл «lnk.cmd» из первой лабораторной работы (никаких изменений вносить не требуется).

После того как файлы «main.c», «lnk.cmd» и «fiel_wav.h» добавлены к проекту, необходимо, добавить к проекту библиотеку «rts55.lib», находится: С:\CCStudio_v3.1\C5500\cgtools\lib\.

После всех действий проект компилируется и запускается на выполнения. Работа программы будет продолжаться некоторое время, о завершении работы будет свидетельствовать изменение надписи «ANIMATING» в нижнем левом углу на ту, что показана на рисунке 2.1

Рисунок 2.1 – Завершение выполнения программы.

 

Работа с DSP/BIOS для генерации звукового сигнала платой DSK5510

Введение в DSP/BIOS

DSP/BIOS представляет собой ядро реального времени, которое предоставляет разработчику следующие сервисы:

1) гибкий планировщик задач с возможностью мультизадачной работы;

2) уровень аппаратной абстракции для работы с периферийными устройствами процессора;

3) устройство независимого ввода/вывода для передачи потоков данных в реальном времени;

4) средства анализа поведения ЦОС-приложения и обмена с ним данными в реальном времени.

Практически, это оптимизированная для ЦОС-приложений мультизадачная операционная система реального времени.

В отличие от большинства существующих коммерческих ядер, DSP/BIOS поставляется бесплатно как составная часть среды разработчика Code Composer Studio, что весьма немаловажно, с учётом цен на продукты такого класса. При этом DSP/BIOS включает в свой состав оптимизированные для работы с конкретным ЦСП библиотеки и компоненты.

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

Для реализации этих достаточно противоречивых требований при построении DSP/BIOS была выбрана следующая модель: DSP/BIOS является статически конфигурируемым ядром реального времени со статически определяемой приоритетной моделью исполнения процессов. Что же достигается такой моделью? Во-первых, минимизация дополнительных расходов памяти, поскольку в исполняемый код включаются только модули, необходимые при реализации данной задачи, а не вся операционная среда. Во-вторых, достигается оптимизация производительности процессора, поскольку большинство статических вызовов после компиляции упаковываются в несколько команд. Далее, поскольку время выполнения команд ЦСП известно, конфигурация системы задаётся статически и тоже известна, модель исполнения и система приоритетов также задаётся статически, то мы имеем полностью предсказуемое и однозначно определённое поведение системы.

Отметим, что наравне со статическими средствами конфигурации, в стандартные средства DSP/BIOS включаются и средства динамического создания процессов и распределения памяти, что позволяет разработчику наравне с гарантированной моделью поведения основных критических узлов использовать и все преимущества полноформатной операционной системы при создании сложных и гибких систем.

Как уже говорилось, при построении любой операционной системы важным вопросом является дополнительный расход ресурсов на предоставляемые ей сервисы. В операционной системе реального времени, кроме расхода ресурсов процессора и памяти, добавляется ещё и фактор расхода времени. С учётом достаточно ограниченных ресурсов систем ЦОС, а также очень жёстких временных рамок, очень большое значение имеет правильный выбор операционной среды. С одной стороны, ОС должна предоставлять достаточно гибкий и удобный набор функциональных возможностей, а с другой - расходовать как можно меньше ресурсов. При построении DSP/BIOS была выбрана многоуровневая модель построения системных сервисов. Для каждой области имеются несколько типов вызовов, аналогичных по назначению, но различных по функциональным возможностям и, соответственно, по расходуемым ресурсам. Так, существует нить типа "прерывание" с базовыми возможностями и очень малым временем реакции и существует нить типа "задача" с гораздо большим набором предоставляемых сервисов, но и с другими временными параметрами переключения и отработки. Аналогично, существует статическое распределение памяти, которое вообще не потребляет ресурсов процессора, так как задаётся утилитами конфигурации. Кроме того, существует динамическое распределение памяти, использование которого требует включения в исполняемый код соответствующего модуля и работает через системные вызовы, но позволяет разным процессам использовать ОЗУ совместно. Такая модель, совместно с моделью конфигурирования самого ядра DSP/BIOS, когда в выходной код добавляются только используемые компоненты, позволяет сочетать быстрое время реакции и малый объём дополнительного кода с широкими функциональными возможностями операционной системы реального времени.

Одной из задач, решаемых DSP/BIOS, является предоставление разработчику уровня аппаратной абстракции, то есть единого логического интерфейса работы с аппаратной частью системы ЦОС, при этом учёт особенностей работы аппаратных узлов того или иного ЦСП возлагается на инструментальные средства. При этом имеется как интерфейс к программированию узлов ядра процессора, таким как таймер и контроллер ПДП, так и стандартный интерфейс для организации каналов ввода/вывода, включающий в себя драйверы периферийных устройств, драйверы портов, к которым они подключаются, например McBSP, и средства организации стандартных потоков ввода/вывода.

При правильном использовании средств DSP/BIOS вполне достижим уровень аппаратной абстракции, при котором получается полная междуплатформенная переносимость приложения. Фактически, сбывается очень давняя мечта разработчиков - если на конечной стадии разработки выяснится, что ресурсов выбранного ЦСП не хватает или, что ещё более болезненно, законченная и с таким трудом упакованная задача требует расширения, то можно просто перейти на более мощный ЦСП, при этом можно даже поменять платформу, ничего не меняя в написанном, проверенном и отлаженном коде. Ещё одно преимущество переносимости - обратный процесс оптимизации. Можно взять мощный ЦСП, спокойно написать и отладить задачу, имея запас производительности для сервиса и отладки, на обкатку вариантов реализации и на оптимизацию участков кода, а затем, отладив и оптимизировав задачу, перенести её на оптимальный по параметрам и цене ЦСП для серийного выпуска устройства. С учётом наличия ЦСП различной мощности и объёма памяти в совместимых корпусах, возможности практически безболезненного переноса позволяют производить как функционально-стоимостную оптимизацию, так и модернизацию устройства без дорогостоящих затрат на модернизацию аппаратных составляющих устройства, например, на переразводку печатных плат. Как пример аппаратной совместимости, приведём ЦСП семейства С5000, где в одном корпусе и совместимыми по выводам выпускаются ЦСП от ‘VC5401 (50 MIPS, 8 Кслов ОЗУ, цена менее $6) до ‘VC5416 (160 MIPS, 128 Кслов ОЗУ), причём параллельно с ЦСП выпускается и совместимая по выводам номенклатура компонентов поддержки, таких как микросхемы источников и супервизоров питания.

Использование библиотек поддержки микросхем (Chip Support Library), абстрагирующих аппаратный уровень основных функций, библиотек ЦОС-функций (DSP Library), предоставляющих оптимизированные для каждой платформы основные ЦОС-алгоритмы с единым интерфейсом, интерфейсов DSP/BIOS для управления выполнением приложения, а также оптимизирующих компиляторов с языка С для написания алгоритмов позволяет создать реально абстрагированное, "отвязанное" от конкретной платформы ЦОС-приложение. Причём это приложение не будет являться лабораторным экспериментом, а будет реальной "боевой" разработкой с достаточным для практического применения уровнем оптимальности исполнения.

Наличие операционной среды, кроме удобства разработки, даёт ещё один плюс - все компоненты работы с аппаратным обеспечением уже отлажены и работают - не надо тратить время на их отладку.

Ещё одной важной особенностью DSP/BIOS является наличие визуальных средств контроля и протоколирования порядка и последовательности исполнения нитей, а также средств отслеживания критических мест, что позволяет легко оценить ход исполнения приложения и быстро отследить и устранить критические участки.

Компоненты DSP/BIOS

Основные компоненты DSP/BIOS в среде разработчика Code Composer Studio, показанные на рисунке 3.1.

На хост-компьютере пишутся исходные файлы проекта (на С, С++ или ассемблере), использующие интерфейсы DSP/BIOS API. Затем с помощью утилиты конфигурирования определяются те компоненты, которые будут использоваться в проекте, и их параметры. Исходные тексты, библиотека DSP/BIOS и файлы конфигурации образуют проект, из которого средствами генерации кода получается исполняемый файл, загружаемый в ЦСП. Встроенные средства анализа Code Composer Studio позволяют производить мониторинг исполнения программы.

 

Рисунок 3.1 – Компоненты DSP/BIOS.

 

DSP/BIOS - достаточно сложная статически конфигурируемая система, для задания конфигурации которой используется специальная графическая утилита, интегрированная в Code Composer Studio (рисунок 3.2). Утилита конфигурации - это специализированный визуальный редактор, который позволяет выбирать, какие модули DSP/BIOS будут включены в систему, а какие нет, а также задавать их параметры. Все параметры задаются статически до компиляции. При этом утилита конфигурации позволяет оценить объём требуемой под служебные нужды памяти, а также проверить соответствие заданных параметров, что позволяет избежать ошибок уже на начальном этапе конфигурации системы и сэкономить время на старте. Ещё одной функцией утилиты конфигурации является привязка проекта к конкретной аппаратной платформе. Именно в утилите конфигурации задаются параметры карты памяти, распределения прерываний и привязки тактовой частоты процессора к системным часам реального времени. При этом для различных ЦСП существуют уже готовые начальные схемы конфигурации DSP/BIOS.

Рисунок 3.2 – Утилита конфигурации.

 

Все модули ядра реального времени DSP/BIOS могут быть разбиты на 6 групп, каждая их которых предоставляет свой интерфейс (API) пользовательским приложениям:

1) группа функций анализа реального времени и обмена данными;

2) функции аппаратной абстракции;

3) функции ввода/вывода, независимые от аппаратных устройств;

4) функции управления выполнением нитей;

5) функции взаимодействия и синхронизации нитей;

6) прочие функции.

Графический пользовательский интерфейс (Graphical User Interface – GUI) упрощает разработку системы:

1) Автоматически подключает необходимые библиотеки

2) Автоматически обрабатывает вектора прерываний и перезапуск

3) Определяет конфигурацию системной памяти (создает CMD-файл)

4) Когда CDB-файл сохранен, инструмент конфигурирования создает 5 дополнительных файлов

Таблица 3.1

Имя_файла.cdb	Конфигурационная база данных
Имя_файлаcfg_c.c	Си-код, создаваемый инструментом конфигурирования
Имя_файлаcfg.s55	ASM-код, создаваемый инструментом конфигурирования
Имя_файлаcfg.cmd	Командный файл компоновщика
Имя_файлаcfg.h	Заголовочный файл для *cfg_c.c
Имя_файлаcfg.h55	Заголовочный файл для *cfg.s28

Когда CDB-файл добавляется в проект, ИСР CCS автоматически добавляет сгенерированные файлы в директорию проекта (таблица 3.1).