[MSP430F 0]

конечно можно! За отдельную плату готов предоставить готовую реализацию на 4096 точек B)

 

P.S. Протестировано на MSP430F47197 в проекте счётчика электроэнергии.

 

Вопрос такой. Какова точность целочисленного 32-разрядного БПФ (вся арифметика не должна выходить за пределы 32 разрядов) ?

Если у меня данные честные 16-битные и я хочу получить на выходе спектр с диапазоном тоже в 90 дБ, то целочисленных вычислений в 32 разрядов для этого не достаточно, не так ли ?

[Zelepuk 0]

Вопрос такой. Какова точность целочисленного 32-разрядного БПФ (вся арифметика не должна выходить за пределы 32 разрядов) ?

Если у меня данные честные 16-битные и я хочу получить на выходе спектр с диапазоном тоже в 90 дБ, то целочисленных вычислений в 32 разрядов для этого не достаточно, не так ли ?

почему недостатачно? как вы считаете? у меня всё было достатачно точно, единственное что: нужно данные масштабировать в нужных местах.

Изменено 23 августа, 2013 пользователем Zelepuk

[MSP430F 0]

почему недостатачно? как вы считаете? у меня всё было достатачно точно, единственное что: нужно данные масштабировать в нужных местах.

 

Вот над этим я сейчас и бьюсь. Вот здесь человек пишет:

" Перед автором стояла задача написать преобразование Фурье на 2048 точек при разрядности исходных данных 16 бит. Из-за отсутствия арифметического сопроцессора пришлось делать целочисленное преобразование, что создало некоторые трудности. При разрядности исходных данных 16 бит разрядность коэффициентов должна быть не менее 16, чтобы не происходило потери точности. Их произведение содержит 32 разряда. 2048 точек дают еще 11 дополнительных разрядов, а это значит, что в 32-разрядное процессорное слово промежуточные данные не помещаются. Вычисление каждой “бабочки” ведется с точностью 64 разряда, а результат округляется до 32 разрядов. "

 

И как же можно тогда все посчитать в 32 разрядах без потери точности ?

[Zelepuk 0]

Вообще проще взять и проверить. Код есть. За полчаса можно всё прикинуть. Сгенерить массив 16 битных данных и подставить.

 

Изменено 23 августа, 2013 пользователем Zelepuk

[Maverick_ 15]

 

посмотрите это

и это

а также это

и это тоже

и вот это

[Corner 0]

Вот над этим я сейчас и бьюсь. Вот здесь человек пишет:

" Перед автором стояла задача написать преобразование Фурье на 2048 точек при разрядности исходных данных 16 бит. Из-за отсутствия арифметического сопроцессора пришлось делать целочисленное преобразование, что создало некоторые трудности. При разрядности исходных данных 16 бит разрядность коэффициентов должна быть не менее 16, чтобы не происходило потери точности. Их произведение содержит 32 разряда. 2048 точек дают еще 11 дополнительных разрядов, а это значит, что в 32-разрядное процессорное слово промежуточные данные не помещаются. Вычисление каждой “бабочки” ведется с точностью 64 разряда, а результат округляется до 32 разрядов. "

 

И как же можно тогда все посчитать в 32 разрядах без потери точности ?

 

С учетом Cortex-M3 можно использовать 32 битное умножение со знаком и 64 бит накопление - SMLAL инструкция. Для signed long long компилер сам подставит.

Вот если нет 64 бит аккумулятора, то можно использовать отдельно знаковое умножение с арифметическим сдвигом на 32 (взятие старшей части от умножения), тогда коэффициенты придется обрезать по модулю (считать за 1), чтобы они не превышали ((64 - Х)/2) бит, где Х - log N по основанию 2, а N - число точек (максимум 16384 точки). Это лишь вопрос к правильной табличке синусов. Уровень шума не вырастет больше чем на 1 дБ. При этом использовать максимальное отрицательное число для выбранного размера нельзя. Например, для 24 бит синус должен лежать в диапазоне от -8388607 до +8388607.

Обрезать результат сильнее нельзя, так как если, к примеру, использовать 16 бит знаковые данные и 16 бит знаковый синус, то динамический диапазон уже ни при каком числе точек не превысит 87 дБ (3 дБ "съедает" формат синусов), даже если результат накапливать в 64 битном аккумуляторе без потерь.

[MSP430F 0]

С учетом Cortex-M3 можно использовать 32 битное умножение со знаком и 64 бит накопление - SMLAL инструкция. Для signed long long компилер сам подставит.

Вот если нет 64 бит аккумулятора, то можно использовать отдельно знаковое умножение с арифметическим сдвигом на 32 (взятие старшей части от умножения), тогда коэффициенты придется обрезать по модулю (считать за 1), чтобы они не превышали ((64 - Х)/2) бит, где Х - log N по основанию 2, а N - число точек (максимум 16384 точки). Это лишь вопрос к правильной табличке синусов. Уровень шума не вырастет больше чем на 1 дБ. При этом использовать максимальное отрицательное число для выбранного размера нельзя. Например, для 24 бит синус должен лежать в диапазоне от -8388607 до +8388607.

Обрезать результат сильнее нельзя, так как если, к примеру, использовать 16 бит знаковые данные и 16 бит знаковый синус, то динамический диапазон уже ни при каком числе точек не превысит 87 дБ (3 дБ "съедает" формат синусов), даже если результат накапливать в 64 битном аккумуляторе без потерь.

 

Вот здесь приведена функция расчета БПФ на ассемблере для ARM 9E (AT91SAM9260). Как Вы считаете, можно этот код напрямую использовать для Cortex M3 или нужно переделывать ? Не пинайте сильно, в ассемблере я не силен.

[Corner 0]

Как Вы считаете, можно этот код напрямую использовать для Cortex M3 или нужно переделывать ? Не пинайте сильно, в ассемблере я не силен.

 

А самому тяжело подсунуть этот код компилятору, сделать вызов ассемблерной функции из main.c без оптимизации и посмотреть, что на это скажет компилятор?

[alex_os 0]

Вот над этим я сейчас и бьюсь. Вот здесь человек пишет:

" Перед автором стояла задача написать преобразование Фурье на 2048 точек при разрядности исходных данных 16 бит. Из-за отсутствия арифметического сопроцессора пришлось делать целочисленное преобразование, что создало некоторые трудности. При разрядности исходных данных 16 бит разрядность коэффициентов должна быть не менее 16, чтобы не происходило потери точности. Их произведение содержит 32 разряда. 2048 точек дают еще 11 дополнительных разрядов, а это значит, что в 32-разрядное процессорное слово промежуточные данные не помещаются. Вычисление каждой “бабочки” ведется с точностью 64 разряда, а результат округляется до 32 разрядов. "

 

И как же можно тогда все посчитать в 32 разрядах без потери точности ?

Ужас какой :cranky: ! При 16 бит входных данных сплошной long long.

Вы определитесь для себя что такое "без потери точности". Можно сделать ФФТ с 16ти битными данными и 16ти битными

поворачивающими множителями, можно сделать с 32 битными данными и 16 ти битными поворачивающими множителями,

кажется АRMы умеют делать умножения 16 * 32 бит c сохранением старших 32 бит.

[Corner 0]

можно сделать с 32 битными данными и 16 ти битными поворачивающими множителями,

кажется АRMы умеют делать умножения 16 * 32 бит c сохранением старших 32 бит.

 

16 битные поворачивающие множители не позволяют обрабатывать более чем 16 бит данные. Шум представления знаете-ли.

[DASM 0]

Ужас какой :cranky: ! При 16 бит входных данных сплошной long long.

Вы определитесь для себя что такое "без потери точности". Можно сделать ФФТ с 16ти битными данными и 16ти битными

поворачивающими множителями, можно сделать с 32 битными данными и 16 ти битными поворачивающими множителями,

кажется АRMы умеют делать умножения 16 * 32 бит c сохранением старших 32 бит.

UMULL 32x32 = 64 полных во всех с индексом М армах

[Corner 0]

UMULL 32x32 = 64 полных во всех с индексом М армах

В M0/M1 такой инструкции нет

[DASM 0]

Странно, дока говорит иное.Вы уверены, что это не проблемы компилятора/ассемблера / ключей?

[Corner 0]

Странно, дока говорит иное.Вы уверены, что это не проблемы компилятора/ассемблера / ключей?

 

Только умножение 32*32=32 - MULS

 

Изменено 19 сентября, 2013 пользователем Corner

[DASM 0]

Посмотрю завтра, с телефона неудобно. И что, в эксепшейн валится от такого опкода?