целочисленное БПФ в формате 1.15

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

Перевод в float - это быдлокодерство в контексте программирования на микропроцессорах без математического сопроцессора. Коим является мой частный процессора AT91SAM9260.

Если скажете: "возьмите с мат. сопроцессорам". Такой вариант не устроит по конструкторским и ценовым критериям...

Так что надо как-то обезопаситься от переполнений и масштабировать данные правильно...

Ищу методы...

Аватара пользователя
Бахурин Сергей
Администратор
Сообщения: 1114
Зарегистрирован: 05 окт 2010, 19:55
Контактная информация:

Re: целочисленное БПФ в формате 1.15

Сообщение Бахурин Сергей »

Вообще жизнь простая штука и постоянно учит нас, что число 256 ну никак не лезет в 8 бит как его не масштабируй. Вы можете на 2 поделить конечно и оно влезит, но тогда вы никогда не представите число 257 8 битами без потерь. Поэтому в вашем случае целочисленной арифметики (или с фиксированной точкой что одно и тоже по сути) любое масштабирование равносильно делению с отбрасыванием дробной части. И если вы взялись за реализацию fft, то должны быть готовы к тому что каждое из этих масштабирований будет сказываться на результате. При этом вы очень рискуете своими масштабированиями окончательно исказить спектр, ибо округление это нелинейная операция, а нелинейные операции имеют негативное свойство разможать спектральные составляющие (поэтому применяют рандомизации при квантовании, чтобы вместо одной палки в спектре не получалось 2 или 3 на кратных частотах). Так что я бы не отбрасывал идею перейти на плавающую точку при расчете fft, если аппаратные ресурсы позволяют, только потому что это медленно. Вашу задачу я не знаю конечно, но думаю если речь зашла о fft, то вряд ли это что-то сильно реалтаймовое.

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

Ну почему же. Как раз таки сильно реалтаймовое.
Нужно посчитать алгоритм из системы фильтров и БПФ за 0,2сек. (пока другой блок не пришёл).

алгоритм требует 5 млн. умножений секунду (посчитано без учёта операций масштабирования и пр. шаманств для фикс. точки).

Аватара пользователя
Бахурин Сергей
Администратор
Сообщения: 1114
Зарегистрирован: 05 окт 2010, 19:55
Контактная информация:

Re: целочисленное БПФ в формате 1.15

Сообщение Бахурин Сергей »

а зачем бпф в реалтайме?

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

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

Аватара пользователя
Бахурин Сергей
Администратор
Сообщения: 1114
Зарегистрирован: 05 окт 2010, 19:55
Контактная информация:

Re: целочисленное БПФ в формате 1.15

Сообщение Бахурин Сергей »

Т.е. для того чтобы выяснить мощность сигнала выше заданного порога или ниже вы решили делать бпф? А зачем? Возьмите энергию вашего сигнала (сумму квадратов отсчетов) поделите на длительность выборки получите среднюю мощность. Сравните с порогом и сбрасывайте в файл если нужно. Если интересует сигнал на конкретной частоте - так и анализируйте энергию сигнала на этой частоте, для этого тоже бпф не нужно, а достаточно поставить квадратурный преобразователь с ФНЧ и далее снова сумма квадратов. А главное никакого переполнения не будет.

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

Интересует именно гармонический соства и мощность гармоник кратных основной.

Ivan Karamazov
Сообщения: 89
Зарегистрирован: 28 окт 2010, 22:31
Откуда: Москва

Re: целочисленное БПФ в формате 1.15

Сообщение Ivan Karamazov »

Хотелось бы подробнее узнать про "постановку запятой наместо" и "нормализуцию"
Опыт показывает, что народ сам часто изобретает сильно упрощенную / достаточно эффективную плав. точку. Пример под ARM -- ни то libmad, ни то libflac, ни то libtremor (целочисленный OGG) (не помню точно, кто из них иллюстрирует искусственную "целочисленную точку", а кто -- баланс между C /Asm для ARM'а -- но где-то там есть чего почитать по обоим пунктам).
Полагаю также, что решаемость задачи зависит не в поледнюю очередь от того, какой памятью Вы свой контроллер обвесите и какой из переферий захотите воспользоваться. Проглядев за 5 мин data sheet могу, например, почти однозначно сказать, что если (например) захотите юзать Ethernet MAC или, скажем, навесите в качестве памяти SDRAM -- о производительности, равно как и о realtime можно забыть и не париться вообще.
Вообще, Вы ранее использовали MCU на ядре ARM??
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.

Дмитрий К
Сообщения: 29
Зарегистрирован: 02 мар 2011, 09:48

Re: целочисленное БПФ в формате 1.15

Сообщение Дмитрий К »

Ранее не использовал. Но почему так категорично? Если юзаю SDRAM о производительности можно забыть?
Непонимаю... ну ограничит это скорость обработки до 100MHz. Всё от сложности алгоритма же зависит.
И потом, у SAM9260 своей-то памяти всего 4кБ. Что туда поместится???? Если не юзать SDRAM то вообще ничего не запустишь на нём...

Ivan Karamazov
Сообщения: 89
Зарегистрирован: 28 окт 2010, 22:31
Откуда: Москва

Re: целочисленное БПФ в формате 1.15

Сообщение Ivan Karamazov »

Еще раз, я не читал подробно data sheet Вашего MCU, и не знаю всех леденящих подробностей (опыт показывает, что одного data sheet'а м.б. недостаточно -- нужна полная дока, вкл систему программирования).
Коротко -- есть одно правило -- чтобы ARM7+ (у Вас - 9-й) работал "в полный рост", процессорному ядру необходимо иметь возможность читать (или писать) одно 32-разрядное слово за такт (это не значит, что этого требуют все команды; в частности умножения -- особенно smul -- 32x32=63 бита со знаком в "максимальном" варианте этого не требуют, но подавляющее большинство др. команд -- да, требуют). Это, соответственно, означает, что если процу придется работать с памятью "напрямую" -- сколько тактов ожидания Вы поставите, на столько надо поделить тактовую частоту -- правило грубое, но единственное. SDRAM обеспечивет обмен данными с заявленной частотой (например, 133 МГц) только в пакетном режиме, т.е. только после того как выполнена обалденно длинная процедура загрузки адреса совместно с одной или даже двумя (!) командами (SDRAM настолько сложна, что у нее вместо обычной "временной диаграммы" используется понятие "команда", каждая -- со своей временной диаграммой! (например, при чтении обычно требуется сначала выполнить команду "PRECHARGE", а только потом "READ"!. Т.е. в больших системах (включая "толстые" ARM'ы) это рентабельно, поскольку кэш большой, и данные в него считываются блоками ("строками"). Все известные мне MCU с ARM с кэшем или без читают за раз одно слово, тратя на это примерно столько же времени, сколько надо чтобы прочитать 16 и более. (это не значит, что так и у Вас -- в конце концов, все растут, в том числе и ARM'ы, но на это надо обратить самое серьезное внимание.)
Да, у Вас есть кэш. Но он маленький, и не всегда уживается с DMA (в силу упрощенности системы). Т.е. то, что мне известно, допускало (при использовании любой переферии с DMA) кэшировать только код и константы.
Хуже того, в известных мне системах, при работе DMA при попытке обращения к памяти ядро проца просто блокируется до завершения передачи данных и освобождения шины. (Кстати, если Вы не собираетесь использовать DMA -- не вполне понятно, зачем Вам камень с ТАКОЙ переферией -- все эти MAC/MMU/USB/море послед. интерфейсов/8CS с SDRAM/CF/TrueIDE и т.п. денег стоят!)
Заключение: (1) ARM сам себе неплох. Но оценить производительность (и пригодность для конкретной задачи) не имея железяки в руках очень сложно.
(2) Судя по развитости и структуре переферии, Ваш контроллер более подходит для установки Линуха с целью последующей эксплуатации ни то в качестве сердца модного "умного дома", ни то для продвинутого кассового аппарата -- словом, для вещей серьезных и востребованных, и где некуда спешить; и менее всего -- для фурье в реальном времени.
(3) Риск Вашей разработки огромен. На мой вкус -- безумно. Снизить его можно только заранее придумав "план-Б". По месту и обстоятельствам.
(4) Прошу прощения за очередной offtopic в смысле концепций сайта.
ДОБАВЛЕНО:
(1) Изв. за "менее всего" для фурье. Должно быть что-то вроде "не самое удачное решение".
(2) Я не хотел никого обидеть, равно как и отговаривать от использования конкретного чипа, скорее напугать и таким образом заставить максимально подробно разобраться в предложенной (вероятно, навязанной) архитектуре.
(3) Доп. проблемой, свойственной АРМ'ам яавляется очень плохая пригодность для задач, связанных с реальным временем "ОС" от разраработчиков конкретного чипа. (Линух -- тоже так себе альтернатива для реал-time, все что он дает -- более-менее устойчивую болеее менее параллельную работу развитой перефирии + стандартный набор системных вызовов).
ЕЩЕ ДОБАВЛЕНО:
Для Вашего чипа две хороших новости: (1) оно читает SDRAM по 8 32-разрядных слов за раз ("толстый АРМ") (ну здесь придется попрыгать, чтобы получить заметный выигрыш не проиграв из-за малького кэша, все равно хорошо, что есть куда прыгать -- вообще, упражнения с такой системой весьма интересны и полезны, если время для разработки не очень жмет, что спорно) и (2) CPU core имеет некий DSP instruction extension (сами команды я не нашел / не искал, но это может перевесить ранее упомянутые недостатки, а может и нет).
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.

Ответить