[AlexZabr 0]

Просьба просветить:

есть большой массив данных, скажем 3000 samples сохраненных как float (по 4 байта на каждый).

Нужно весь массив прогнать через систему фильтров (filter bank) состоящую из длинного FIRа и множества коротких простых IIRов. Работаем с C5402 DSK.

Массив данных уже готов в файле данных содержимое которого считывается в array в С сорсе (обработка записанной инфы, не real time). Сама фильтрация делается ассемблерными рутинами вызываемыми из C.

Меня тут пробило: ведь массив из 3000 samples в float это 12 kB, а я думал все уместить во внтренний RAM процессора (C5402). Видимо закрузка 12 kB буффера одним махом для обрабоатки - крайне не практична.

 

Посему буду благодарен за советы насчет более рационального подхода обработки таких массивов. Может быть стоит его разбит на множество мелких массивов и их подгружать в мапять процессора и обрабатывать ? Но тогда нужно будет применать что-то типа техники overlap-add или overlap-save (что-бы избежать проблем фильтрации на стыках мелких массивов). Что говорит практика ?

 

Заранее благодарен за ответы.

[anton 0]

В твоем случае помоему 54 камень работает с int16. В нем и загружай массив получи 6кб.

Подгрузки довольно сложно организовать не разрушая конвейер (скорее всего избежать сильного падения производительности не удастся).

[AlexZabr 0]

В твоем случае помоему 54 камень работает с int16. В нем и загружай массив получи 6кб.

Подгрузки довольно сложно организовать не разрушая конвейер (скорее всего избежать сильного падения производительности не удастся).

 

Спасибо.

В принципе возможное падение производительности меня не сильно волнует ибо и так обработка не в real time и лишние десятки msec в демо погоды не сделают. Что делается - post-processing данных сохраненных предварительно в файлах. Результаты тоже будут отгружатся в отдельные файлы (которые затем читаются в МАТЛАБ и до-обрабатываются там).

 

В принципе у меня 2900 sampes данных, в формате float, т.е. каждый занимает 4 последовательных байта в файле. При чтении в C получаем массив 2900*4 = 11600 bytes (массив int, содержит данные по-байтно), затем я его компоную в words получаю массив 5800 words с которым и работаю, но физически это все-равно занимает около 12 kB). Хмм, тут кажется будет загвоздка: процессор-то действительно 16 bit fixed point, кажется это означает что перед обработкой я должен маштабировать данные в 16-бит fixed point и лишь затем их обрабатывать. Я не прав ?

 

Сорри, поправка:

только что проверил форматность данных: считывается WAV файл. Он записан в 16-бит формате (один канал - моно, 16 бит на sample), а не в 32х битном как я думал. MATLABоский wavread читает data из WAV файла в 32х битном фомате заполняя нулями половину (один их 2х words). Посему и имеем "искуственный" 32х битный формат данных считанных из WAV в матлаб. Ежели я потом пытаюсь вырезать куски данных в формате int16 из считанных из WAV данных, то читаются исключительно нули, т.е. не тот word что нужен.

Это означает что мен нужно во первых, после считывания мне нужно данные форматировать в 16 бит fixed point в МАТЛАБе, писать их в файл для процессора, т.е. в С, на процессоре мне уже не понадобиться форматировать между 32 <-> 16 fixed point.

[AlexZabr 0]

Да, действительно наткнулся на проблемы в памятью - в програме 2 массива по int 11600, один массив float 2900, + массив чаров примерно на 200-300 байт. При компиляции падает линкер - не хватет памяти:

 

error: can't allocate .stack, size 00000400 (page 1), in IDATA (avail: 000003f6)

 

подробно:

http://electronix.ru/forum/index.php?showt...mp;#entry252392

 

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

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

 

Что говорит опыт ?

[BratherLU 0]

Да нет, проблем на стыке быть не должно. Нужно сохранить контекст фильтра после обработки предыдущего кадра.

Под контекстом фильтра имею ввиду -> линию задержки и указатель внутри этой линии задержки

а сам вызов фильтра можно оформить примерно так

 

void ExampleFIR(unsigned short xFrameLen, short **pBuffer, short *pIn, short *pOut);

 

xFrameLen - длина входного/выходного кадра

pBuffer - указатель на ячейку где будет храниться указатель внутри линии задержки (передача параметра по ссылке в С)

pIn - указатель на входной кадр

pOut - указатель на выходной кадр

 

Или загляните в хелп для DSPLIB там тоже разрисованы некоторые особенности реализации алгоритма

 

Еще рекомендую ознакомиться -> spra556b.pdf (A Multichannel/Algorithm Implementation on the TMS320C6000 DSP)

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

 

По поводу размещения данных в конкретных областях памяти - посмотрите в хелпе директивы компилятора

#pragma CODE_SECTION и #pragma DATA_SECTION

[AlexZabr 0]

Да нет, проблем на стыке быть не должно. Нужно сохранить контекст фильтра после обработки предыдущего кадра.

Под контекстом фильтра имею ввиду -> линию задержки и указатель внутри этой линии задержки

а сам вызов фильтра можно оформить примерно так

 

void ExampleFIR(unsigned short xFrameLen, short **pBuffer, short *pIn, short *pOut);

 

xFrameLen - длина входного/выходного кадра

pBuffer - указатель на ячейку где будет храниться указатель внутри линии задержки (передача параметра по ссылке в С)

pIn - указатель на входной кадр

pOut - указатель на выходной кадр

 

Или загляните в хелп для DSPLIB там тоже разрисованы некоторые особенности реализации алгоритма

 

Еще рекомендую ознакомиться -> spra556b.pdf (A Multichannel/Algorithm Implementation on the TMS320C6000 DSP)

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

 

По поводу размещения данных в конкретных областях памяти - посмотрите в хелпе директивы компилятора

#pragma CODE_SECTION и #pragma DATA_SECTION

 

 

Большое спасибо, буду разбираться....