Российский производитель и разработчик сертифицированного измерительного оборудования с 1987 года


L-502 realtime - шаг прерывания

Вы не вошли.

 Поиск | Регистрация | Вход 

Михаил
11.07.2013 16:54:42
#1

Гость

L-502 realtime - шаг прерывания

Реально ли установить на L-502 шаг прерывания в 1 сэмпл при частоте дискретизации порядка 40КГц?

Поясню. Речь идет о создании системы обработки звукового сигнала realtime, причем задержка вход-выход не более одного сэмпла. Принят сэмпл - щелкнуло прерывание - отработал, выдал на выход.

Вообще позволяет ли архитектура писюка в принципе с таким реалтаймом работать, или мне лучше смотреть в сторону DSP?
Кстати, при использовании DSP Blackfin в составе L-502 можно ли его настроить подобным образом: на обработку прерывания после каждого сэмпла без участия писюка?

11.07.2013 21:12:07
#2

Инженер-электронщик
Откуда: "Л Кард"
Здесь с 21.04.2014
Сообщений: 4,597

Re: L-502 realtime - шаг прерывания

Михаил, лучше смотреть в сторону DSP. Интерфейс L-502 с PC оптимизирован под блочные пересылки. На одиночных пересылках будут большие накладные расходы. 

По аппаратным возможностям L-502 при работе с DSP:
- Задержка при передачи данных  вход АЦП -> DSP составит около 3 мкс.
- Задержка при передачи данных  DSP -> выход ЦАП составит около 10 мкс.
Времена пишу ориентировочные, можно будет уточнить при необходимости.
Итого, из 25 мкс (40 кГц) остаётся 12 мкс на обработку в ADSP. На частоте ядра 530 МГц это 6360 тактов процессора на сэмпл. Но ADSP  работает с SDRAМ на частоте 133 МГц (1596 циклов SDRАM).
ЦАП в L-502 не интерполирующий, он работает на частоте 1 МГц. Если "кормить" ЦАП с периодом 25 мкс, то будет на выходе ступенчатый сигнал с периодом 25 мкс. Для звукового приложения по-хорошему понадобится интерполяция в ADSP.
По прерываниям и программной идеологии мои коллеги напишут...

12.07.2013 11:22:22
#3

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 1,326

Re: L-502 realtime - шаг прерывания

Думаю, Вам в любом случае следует надо будет использовать DSP. Хотя прерывание в один семпл Вы поставить можете и при обработке с ПК, но весьма сомнительно, что Вы сможете получить задержку вывода в один семпл даже если на ПК будет стоять какая-нибудь RTOS.

При написании программы на DSP Вы можете все обрабатывать внутри BlackFin’а (единственное начальную инициализацию надо все же выполнить с ПК) и тут уже Ваша задача вполне реальна, но потребует соответствующих навыков. За основу Вы можете взять штатную прошивку, разве что для обработки по одному семплу Вам логичнее будет прием данных переписать, чтобы он шел без использования DMA (так как при одном семпле от DMA только дополнительные накладные расходы)

Если будут вопросы по программированию DSP - пишите

Михаил
12.07.2013 12:36:31
#4

Гость

Re: L-502 realtime - шаг прерывания

А товарищ выше писал, что при использованиии Blackfin-a на этой плате имеют место быть задержки передачи сэмпла (контролируемые) - это так?
   Переход на DSP будет, но мне хотелось бы сначала скоренько написать прототип на писюке. А у вас никто из разработчиков не пробовал устанавливать прерывание в 1 сэмпл? Что комп при этом будет практически висеть, это мне не страшно, это лишь прототип.
   Задержка передачи сигнала при этом может быть реализуема, если прерывание от АЦП-платы будет иметь высокий приоритет, нет? Отработал пользовательский код прерывание от сэмпла, поставили в буфер ЦАП, вернулись. Кстати, в "синхронном" режиме пользовательский код обработки сэмплов вызывается из обработчика прерывания или надо поллинговать буфер?

12.07.2013 13:40:00
#5

Сотрудник "Л Кард"
Здесь с 17.04.2014
Сообщений: 1,326

Re: L-502 realtime - шаг прерывания

Задержки естественно в любом случае есть. Но при обработке в DSP они меньше и их максимальные значения определены, как описал Александр выше. Поэтому при описанных Александром условиях Вы можете добиться выполнения требования “задержка вход-выход не более одного сэмпла”.

В случае работы с ПК эти задержки будут существенно больше (за счет времени передачи по шине PCIe, времени реакции ПК на прерывание + доп. буфер в модуле) + жестко не определены.

Использовать ПК для отладки алгоритмов Вы можете, но вот насчет жесткого реалтайма и задержки не больше одного семпла – сомнительно.

Также не очень понятно, что Вы собираетесь использовать на ПК в качестве ОС. Для ОС общего назначения реалтайма строго говоря ожидать сложно… Если Вы хотите использовать стандартное API под Windows/Linux, то Вы будете работать на пользовательском уровне, обработчики прерывания выполняются только на уровне ядра, соответственно из обработчика драйвер может уже послать событие приложению о том что появились данные и приложение по событию примет эти данные.

12.07.2013 14:19:44
#6

Инженер-электронщик
Откуда: "Л Кард"
Здесь с 21.04.2014
Сообщений: 4,597

Re: L-502 realtime - шаг прерывания

Михаил, задержки абсолютно контролируемые на аппаратном уровне (в FPGA). Эти задержки не могут быть больше тех времён, которые я указал. Как лучший товарищ smile, я про аппаратный уровень (окружение ADSP) рассказал в контексте Вашей задачи.
Вообще, логика FPGA - в нашей власти, сможем что-то доделать, если будут интересные предложения по поводу нового функционала, если эти идеи будут носить достаточно универсальный характер (потенциально интересные и для других задач).

Михаил
12.07.2013 14:45:51
#7

Гость

Re: L-502 realtime - шаг прерывания

> Вы будете работать на пользовательском уровне,
> обработчики прерывания выполняются только на
> уровне ядра
   Идея такая. Драйвер науськиваем на пользовательский обработчик - например, dll-ку. Каковую он вызывает из своего обработчика прерывания. А в самой dll-ке и заложен весь прикладной код обработки. Идея далеко не новая.
   Впрочем, нет так нет. Сейчас запрашиваю у дилера Analog Devices в нашей деревне эмуляционные доски для Blackfin-ов; если ваша плата окажется дешевле, попробую заюзать её в этом качестве.

12.07.2013 16:31:48
#8

Сотрудник "Л Кард"
Откуда: Москва
Здесь с 23.04.2014
Сообщений: 3,727

Re: L-502 realtime - шаг прерывания

задержка будет на порядок или два больше и плавающая... Очень давно проверялось на NT системах
вызов обработчика в драйвере 100мкс, DPC процедура до 1 мс, событие на уровне пользователя до 100мс. сейчас на порядок быстрей наверное....