целочисленное БПФ в формате 1.15
Re: целочисленное БПФ в формате 1.15
Перевод в float - это быдлокодерство в контексте программирования на микропроцессорах без математического сопроцессора. Коим является мой частный процессора AT91SAM9260.
Если скажете: "возьмите с мат. сопроцессорам". Такой вариант не устроит по конструкторским и ценовым критериям...
Так что надо как-то обезопаситься от переполнений и масштабировать данные правильно...
Ищу методы...
Если скажете: "возьмите с мат. сопроцессорам". Такой вариант не устроит по конструкторским и ценовым критериям...
Так что надо как-то обезопаситься от переполнений и масштабировать данные правильно...
Ищу методы...
- Бахурин Сергей
- Администратор
- Сообщения: 1116
- Зарегистрирован: 05 окт 2010, 19:55
- Контактная информация:
Re: целочисленное БПФ в формате 1.15
Вообще жизнь простая штука и постоянно учит нас, что число 256 ну никак не лезет в 8 бит как его не масштабируй. Вы можете на 2 поделить конечно и оно влезит, но тогда вы никогда не представите число 257 8 битами без потерь. Поэтому в вашем случае целочисленной арифметики (или с фиксированной точкой что одно и тоже по сути) любое масштабирование равносильно делению с отбрасыванием дробной части. И если вы взялись за реализацию fft, то должны быть готовы к тому что каждое из этих масштабирований будет сказываться на результате. При этом вы очень рискуете своими масштабированиями окончательно исказить спектр, ибо округление это нелинейная операция, а нелинейные операции имеют негативное свойство разможать спектральные составляющие (поэтому применяют рандомизации при квантовании, чтобы вместо одной палки в спектре не получалось 2 или 3 на кратных частотах). Так что я бы не отбрасывал идею перейти на плавающую точку при расчете fft, если аппаратные ресурсы позволяют, только потому что это медленно. Вашу задачу я не знаю конечно, но думаю если речь зашла о fft, то вряд ли это что-то сильно реалтаймовое.
Re: целочисленное БПФ в формате 1.15
Ну почему же. Как раз таки сильно реалтаймовое.
Нужно посчитать алгоритм из системы фильтров и БПФ за 0,2сек. (пока другой блок не пришёл).
алгоритм требует 5 млн. умножений секунду (посчитано без учёта операций масштабирования и пр. шаманств для фикс. точки).
Нужно посчитать алгоритм из системы фильтров и БПФ за 0,2сек. (пока другой блок не пришёл).
алгоритм требует 5 млн. умножений секунду (посчитано без учёта операций масштабирования и пр. шаманств для фикс. точки).
- Бахурин Сергей
- Администратор
- Сообщения: 1116
- Зарегистрирован: 05 окт 2010, 19:55
- Контактная информация:
Re: целочисленное БПФ в формате 1.15
а зачем бпф в реалтайме?
Re: целочисленное БПФ в формате 1.15
ну мало ли может быть приложений... конкретно в моём случае - регистратор НЧ сигнала. "Чёрные дыры" (в виде пропущеных отсчётов) недопустимы.
Например если некоторые составляющие спектра вышли за пределы - сбпросить выборку в файл.
Например если некоторые составляющие спектра вышли за пределы - сбпросить выборку в файл.
- Бахурин Сергей
- Администратор
- Сообщения: 1116
- Зарегистрирован: 05 окт 2010, 19:55
- Контактная информация:
Re: целочисленное БПФ в формате 1.15
Т.е. для того чтобы выяснить мощность сигнала выше заданного порога или ниже вы решили делать бпф? А зачем? Возьмите энергию вашего сигнала (сумму квадратов отсчетов) поделите на длительность выборки получите среднюю мощность. Сравните с порогом и сбрасывайте в файл если нужно. Если интересует сигнал на конкретной частоте - так и анализируйте энергию сигнала на этой частоте, для этого тоже бпф не нужно, а достаточно поставить квадратурный преобразователь с ФНЧ и далее снова сумма квадратов. А главное никакого переполнения не будет.
Re: целочисленное БПФ в формате 1.15
Интересует именно гармонический соства и мощность гармоник кратных основной.
-
- Сообщения: 89
- Зарегистрирован: 28 окт 2010, 22:31
- Откуда: Москва
Re: целочисленное БПФ в формате 1.15
Опыт показывает, что народ сам часто изобретает сильно упрощенную / достаточно эффективную плав. точку. Пример под ARM -- ни то libmad, ни то libflac, ни то libtremor (целочисленный OGG) (не помню точно, кто из них иллюстрирует искусственную "целочисленную точку", а кто -- баланс между C /Asm для ARM'а -- но где-то там есть чего почитать по обоим пунктам).Хотелось бы подробнее узнать про "постановку запятой наместо" и "нормализуцию"
Полагаю также, что решаемость задачи зависит не в поледнюю очередь от того, какой памятью Вы свой контроллер обвесите и какой из переферий захотите воспользоваться. Проглядев за 5 мин data sheet могу, например, почти однозначно сказать, что если (например) захотите юзать Ethernet MAC или, скажем, навесите в качестве памяти SDRAM -- о производительности, равно как и о realtime можно забыть и не париться вообще.
Вообще, Вы ранее использовали MCU на ядре ARM??
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.
Re: целочисленное БПФ в формате 1.15
Ранее не использовал. Но почему так категорично? Если юзаю SDRAM о производительности можно забыть?
Непонимаю... ну ограничит это скорость обработки до 100MHz. Всё от сложности алгоритма же зависит.
И потом, у SAM9260 своей-то памяти всего 4кБ. Что туда поместится???? Если не юзать SDRAM то вообще ничего не запустишь на нём...
Непонимаю... ну ограничит это скорость обработки до 100MHz. Всё от сложности алгоритма же зависит.
И потом, у SAM9260 своей-то памяти всего 4кБ. Что туда поместится???? Если не юзать SDRAM то вообще ничего не запустишь на нём...
-
- Сообщения: 89
- Зарегистрирован: 28 окт 2010, 22:31
- Откуда: Москва
Re: целочисленное БПФ в формате 1.15
Еще раз, я не читал подробно 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 (сами команды я не нашел / не искал, но это может перевесить ранее упомянутые недостатки, а может и нет).
Коротко -- есть одно правило -- чтобы 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 (сами команды я не нашел / не искал, но это может перевесить ранее упомянутые недостатки, а может и нет).
Если ваши решения вам нравятся -- это хорошие решения. И наоборот.