Обобщенная структура ЦОС-системы и принципы ее функционирования

Хотя процессор цифровой обработки сигналов (Digital Signal Processor, DSP) предназначен в первую очередь для эффективного выполнения специализированных вычислительных операций над сигналами, он должен содержать средства для взаимодействия с как периферийными устройствами, обеспечивающими ввод/вывод и преобразование этих сигналов (АЦП и ЦАП), так и, возможно, с другими процессорами. При этом важно, чтобы операции ввода и вывода данных также выполнялись с высокой скоростью с минимальным "задействованием" процессорного ядра.

Структура типичной системы ЦОС приведена на рис.____. Как видим, в дополнение к функциям обработки данных, поступающих с АЦП или аппаратных кодеков, процессор должен "уметь" обрабатывать управляющие и информационные сигналы, поступающие от хост-процессора или средств контроля пользователя. Обычно процессор функционирует синхронно с АЦП или кодеком в целях согласования регулярных временных интервалов дискретизации.

Рис.___ Обобщенная структура системы ЦОС

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

Для реализации такого способа взаимодействий могут использоваться следующие подходы.

1. Ввод/вывод с последовательным опросом. DSP-процессор опрашивает внешние устройства путем анализа состояния своих сигнальных выводов или определенных ячеек памяти. Если считается, что событие произошло (например, получено новое слово данных), то вызывается соответствующая процедура обработки. Данный подход очень прост, однако его главным недостатком является затрата больших ресурсов процессора на постоянную регулярную проверку каких-либо условий (вне зависимости от того, произошли они в действительности или еще нет), что, естественно, снижает его возможности по выполнению "полезной" работы.

2. Управление по прерываниям. Данный режим возможен, если сигнальным ножкам процессора поставить в соответствие вектора прерывания и области памяти, в которых будут размещаться соответствующие обработчики. В этом случае процессор "отвлекается" от вычислительной обработки только том случае, когда внешние событие действительно произошло. Такой подход требует более тщательного программирования, но существенно повышает количество "полезного" времени, идущего на обработку данных.

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

10. Особенности программной организации ввода-обработки-вывода данных в системах ЦОС, работающих в реальном времени. Работа по прерываниям. Использование буферов.

1. Особенности разработки и отладки программного обеспечения для систем реального времени

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

Рис.____ Принцип традиционного структурного подхода к разработке программ

Наиболее целесообразным для приложений реального времени считается такая структура программы, при которой фрагменты кода выполняются при вызове процедур обработки прерываний (Interrupt Service Routine, IRS). До разрешения прерываний система должна быть "инициализирована" – приведена в определенное начальное состояние (сконфигурированы управляющие биты и регистры, порты ввода/вывода, таймеры). После разрешения прерываний процессор обычно переводится в состояние простоя и ожидает, когда произойдет разрешенное системное событие (прерывание). После обработки прерывания процессор возвращается в состояние простоя (рис.____).

Рис.____ Принцип функционирования приложения реального времени

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

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

В качестве решения данной проблемы ведущие производители DSP и средств разработки для них предлагают унифицированные программные ядра реального времени Real-Time Operating Kernel (иногда сами разработчики их все же называют операционными системами реального времени Real-Time Operating System, RTOS), которые представляют собой прослойку между уровнем реальных прерываний и пользовательскими программами для их обработки и обычно предоставляют разработчику примерно следующий перечень сервисов (рис.___):

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

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

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

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

Практически, это оптимизированная для ЦОС-приложений мультизадачная операционная система реального времени, которая входит в состав интегрированной среды разработки DSP/BIOS для Code Composer Studio (для TMS-процессоров), VDK для VisualDSP++ (для процессоров фирмы Analog Devices), OSE_ck или RTXC^TM для CodeWarrior (для процессоров фирмы Motorola).

Рис.____ Принцип функционирования программного ядра реального времени

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

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

Одной из задач, решаемых DSP/BIOS и VDK, является предоставление разработчику уровня аппаратной абстракции, то есть единого логического интерфейса работы с аппаратной частью системы ЦОС, при этом учет особенностей работы аппаратных узлов того или иного DSP возлагается на инструментальные средства. Неотъемлемой частью RTOS обычно имеется стандартный интерфейс для организации каналов ввода/вывода, включающий в себя драйверы периферийных устройств, драйверы портов, к которым они подключаются, и средства организации стандартных потоков ввода/вывода. При этом вполне достижим уровень аппаратной абстракции, при котором получается полная межплатформенная переносимость приложения. Фактически, сбывается очень давняя мечта разработчиков – если на конечной стадии разработки выяснится, что ресурсов выбранного ЦСП не хватает или, что ещё более болезненно, законченная и с таким трудом упакованная задача требует расширения, то можно просто перейти на более мощный ЦСП, при этом можно даже поменять платформу, ничего не меняя в написанном, проверенном и отлаженном коде. Ещё одно преимущество переносимости - обратный процесс оптимизации. Можно взять мощный ЦСП, спокойно написать и отладить задачу, имея запас производительности для сервиса и отладки, на обкатку вариантов реализации и на оптимизацию участков кода, а затем, отладив и оптимизировав задачу, перенести её на оптимальный по параметрам и цене ЦСП для серийного выпуска устройства. С учётом наличия ЦСП различной мощности и объёма памяти в совместимых корпусах, возможности практически безболезненного переноса позволяют производить как функционально-стоимостную оптимизацию, так и модернизацию устройства без дорогостоящих затрат на модернизацию аппаратных составляющих устройства, например, на переразводку печатных плат.

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

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