STM32, первые впечатления.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3888048#p3888048"]В ARM есть MAC-команды. Но нет команд выполняющих одновременно АЛУ-операцию с доступом к памяти. Это - ограничение архитектуры ядра.[/uquote]
Это не считается?

Спойлер

[jcxz]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3888051#p3888051"]Это не DSP МАС.[/uquote]Вот!!! Вот мы и вернулись к тому, с чего начали. Именно поэтому я и написал:
[uquote="jcxz",url="/forum/viewtopic.php?p=3887934#p3887934"]Это смотря что называть "DSP-инструкциями". [/uquote]
Так как ARM-архитектура в принципе не умеет распараллеливать доступ к операндам в памяти одновременно с АЛУ-операциями. Это архитектурное ограничение. Но тем не менее во всех мануалах про ARM говорится о том, что они "имеют набор DSP-инструкций" (старшие ядра >= Cortex-M3; а также классические ARM7/9).

[uquote="КРАМ",url="/forum/viewtopic.php?p=3888051#p3888051"]Таким образом, построить на их основе фильтр или бабочку FFT, мягко говоря, невозможно.[/uquote]Почему же? Вполне себе можно - загрузка/выгрузка отдельными командами. Работать будет медленнее конечно.


[uquote="КРАМ",url="/forum/viewtopic.php?p=3888051#p3888051"]Но Вы намекнули, я так понимаю, на архитектуру DSP Аналог девайса и ТИ. Расскажите как там Си интерпретируется в DSP MAC?[/uquote]В смысе как? Нормально. У меня под рукой нет CCS, но например для VLIW-процессоров получается очень эффективный код. В котором множество загрузок распараллеленых с вычислениями. Там это позволяет архитектура ядра.
Да даже и на старом C5000 ядре насколько помню - компилятор знал про эти инструкции. Другое дело, что про аппаратные циклы он в те времена не знал (когда я им пользовался лет 15 назад), но вроде как с тех пор CCS даже аппаратные циклы для C5000 освоил (для VLIW он сразу умел аппаратные циклы).

[uquote="КРАМ",url="/forum/viewtopic.php?p=3888051#p3888051"]Вообще то мой исходный комментарий не содержал упоминания об ARM, а напротив говорил о DSP процессорах.[/uquote]Вообще-то мы находимся в ветке форума называющейся "ARM".

Добавлено after 6 minutes 55 seconds:
[uquote="Reflector",url="/forum/viewtopic.php?p=3888059#p3888059"][uquote="jcxz",url="/forum/viewtopic.php?p=3888048#p3888048"]В ARM есть MAC-команды. Но нет команд выполняющих одновременно АЛУ-операцию с доступом к памяти. Это - ограничение архитектуры ядра.[/uquote]
Это не считается?

Спойлер

[/uquote]Это видимо говорит о том, что во время выполнения предыдущей MAC-инструкции CPU может начать выполнение следующей инструкции загрузки данных. Т.е. - это уже другая инструкция, а не MAC. Это в Cortex-M7 видимо?
И предыдущие ядра Cortex-M умели подобное, но не для MAC, а для инструкций LDR: если две LDR выполнять последовательно, то вторая может быть укорочена на один такт, при соблюдении каких-то дополнительных условий.

Но вот чтобы это было в одной инструкции - такого насколько мне известно в ARM нет.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3888069#p3888069"]Это видимо говорит о том, что во время выполнения предыдущей MAC-инструкции CPU может начать выполнение следующей инструкции загрузки данных. Т.е. - это уже другая инструкция, а не MAC. Это в Cortex-M7 видимо?[/uquote]
Да, но фактически за такт выполняется два обращения к памяти и две операции ALU.

И предыдущие ядра Cortex-M умели подобное, но не для MAC, а для инструкций LDR: если две LDR выполнять последовательно, то вторая может быть укорочена на один такт, при соблюдении каких-то дополнительных условий.

Нет, это обычное конвеерное выполнение команд, при котором иногда можно сэкономить лишний такт. До M7 не было ни сдвоенного ALU, ни двухканального доступа к памяти, для этого как минимум нужна 64-х битная шина...

[КРАМ]

[uquote="jcxz",url="/forum/viewtopic.php?p=3888069#p3888069"]В смысе как? Нормально. У меня под рукой нет CCS, но например для VLIW-процессоров получается очень эффективный код.[/uquote]
Зайду немного с другой стороны.
У ТИ в компиляторах под DSP процессоры есть библиотеки и среди них есть (очевидно) типовые функции DSP - IIR, FIR, FFT всех разновидностей и типов данных.
Вопрос. Если открыть исходники на эти функции (если конечно они доступны), то на чем они написаны? На Си или на АСМе?

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3888088#p3888088"]Да, но фактически за такт выполняется два обращения к памяти и две операции ALU.[/uquote]А где Вы там прочитали про "за один такт"? Там про такты ничего не сказано. Этот double-load вполне возможно что за 2 такта выполняется.
"double load with one instruction" - это думаю имеется в виду команда типа LDRD, которая была и в CM4 и выполнялась за 2 такта.
Хотя может в CM7 она стала выполняться за один такт, если D-bus в CM7 64-битная. Надо мануал читать.

[uquote="Reflector",url="/forum/viewtopic.php?p=3888088#p3888088"]Нет, это обычное конвеерное выполнение команд, при котором иногда можно сэкономить лишний такт. До M7 не было ни сдвоенного ALU, ни двухканального доступа к памяти, для этого как минимум нужна 64-х битная шина...[/uquote]Предыдущие ядра (CM4) уже умели частично конвееризировать команды LDR/STR. Сокращая их на 1 такт. Шина 64 для этого не нужна, если вспомнить что штатное время выполнения LDR/STR - 2 такта.

Добавлено after 21 minute 16 seconds:
[uquote="КРАМ",url="/forum/viewtopic.php?p=3888096#p3888096"]У ТИ в компиляторах под DSP процессоры есть библиотеки и среди них есть (очевидно) типовые функции DSP - IIR, FIR, FFT всех разновидностей и типов данных.
Вопрос. Если открыть исходники на эти функции (если конечно они доступны), то на чем они написаны? На Си или на АСМе?[/uquote]Для C5000 ядра, когда я им плотно занимался, эти библиотеки были и были они на асме. И это было оправданно, так как в те времена си-компилятор генерил ужасный код и многого не умел (но MAC-инструкции он умел; главное чего не умел - аппаратные циклы). Было это давно (~15лет назад) и сейчас (как я слышал) компилятор C5000 стал намного умнее. Но я не проверял так как проектов на нём давно не имею (хотя и отладки и девайсы и эмуляторы - есть).
Но даже эти штатные библиотеки были написаны индусами так криво, что самостоятельное переписывание их (на асм) давало ускорение выполнения в 2-3 раза.

Другая картина с VLIW (ядро C674x, DSP TMS320C674x, OMAP-L137/L138). Для них уже лет 10 назад компилятор выдавал вполне приемлемый результат. Да, там были библиотеки, но если написать на си такую же функцию, написать её грамотно (не мешая компилятору оптимизировать, понимая как работает конвеер DSP, применяя разные квалификаторы указателей типа restrict; строя код вычисления так, чтобы по-возможности было как можно меньше зависимостей вычислений следующей операции от результата предыдущей и пр.), то потом скорость выполнения была точно такой-же как и у библиотечной функции.
Я для теста делал две ветки кода: с библиотечными функциями и чисто на си, сравнивал время их выполнения (по таймеру) и получал точное совпадение в пределах погрешности измерений. Из чего я вообще сделал вывод, что и сами библиотеки эти видимо написаны на си. Так что на VLIW использовать либы для ускорения - не имеет смысла.
Ещё читал, что на VLIW трудно (и почти невозможно) писать на ассемблере человеку из-за того что там другой принцип выполнения инструкций: выполнение идёт не-покомандно, а из команд формируются fetch-пакеты, которые как единое целое выбираются из памяти и как единое целое выполняются. И си-компилятор строит эти fetch-пакеты.

[Reflector]

[uquote="jcxz",url="/forum/viewtopic.php?p=3888097#p3888097"]А где Вы там прочитали про "за один такт"? Там про такты ничего не сказано. Этот double-load вполне возможно что за 2 такта выполняется.
"double load with one instruction" - это думаю имеется в виду команда типа LDRD, которая была и в CM4 и выполнялась за 2 такта.
Хотя может в CM7 она стала выполняться за один такт, если D-bus в CM7 64-битная. Надо мануал читать.[/uquote]
Там сдвоенная 32-х битная DTCM, у CPU к ней эксклюзивный доступ, плюс двухканальный Load Store Unit и ALU, у M4 ничего этого нет, еще и конвеер всего 3-х стадийный, против 7-ми у M7. К тому же M7 может распараллеливать не только загрузку данных и операции ALU, а в принципе любые команды, если выполнены определенные условия.

[quote="Reflector",url="/forum/viewtopic.php?p=3888088#p3888088"]Предыдущие ядра (CM4) уже умели частично конвееризировать команды LDR/STR. Сокращая их на 1 такт. Шина 64 для этого не нужна, если вспомнить что штатное время выполнения LDR/STR - 2 такта.[/quote]
Допустим пара LDR выполняется на M4 за 2+1 такта, а будь у него 64-х битная шина могло бы хватить одного чтения выполняемого за 2 такта, так что выгода от 64-х битности безусловно есть.

[jcxz]

[uquote="Reflector",url="/forum/viewtopic.php?p=3888130#p3888130"]Там сдвоенная 32-х битная DTCM, у CPU к ней эксклюзивный доступ, плюс двухканальный Load Store Unit и ALU, у M4 ничего этого нет, еще и конвеер всего 3-х стадийный, против 7-ми у M7. К тому же M7 может распараллеливать не только загрузку данных и операции ALU, а в принципе любые команды, если выполнены определенные условия.[/uquote]Да, классно, это хороший шаг вперёд для ARM! Но у меня пока нет проектов на CM7.

[uquote="Reflector",url="/forum/viewtopic.php?p=3888130#p3888130"]Допустим пара LDR выполняется на M4 за 2+1 такта, а будь у него 64-х битная шина могло бы хватить одного чтения выполняемого за 2 такта, так что выгода от 64-х битности безусловно есть.[/uquote]Да, Вы правы.
Но всё-таки: чтобы в одной команде обращение к памяти + АЛУ-операция - такого и в CM7 нету.
Да и вообще - далеко ему ещё до ядра C674x.

PS: Да даже на C5000 симметричный КИХ-фильтр можно посчитать тратя всего 1 такт на каждые два порядка фильтра (фильтр 300-го порядка - ~150 тактов). Правда с 16-битными коэффициентами. И шина к ОЗУ там не 64-битная, а 5 шт. 16-битных шин (2 - для кода, 3 - для данных) + 2-портовая память.
А сколько тактов потребуется на Cortex-M7?

[linkov1959]

[uquote="КРАМ",url="/forum/viewtopic.php?p=3884955#p3884955"][uquote="linkov1959",url="/forum/viewtopic.php?p=3884948#p3884948"]В целые должно перевестись до 4-го порядка точно.[/uquote]
НЕТ!!!
Даже первый порядок - нет. Я объяснил почему. Только фикспойнт, как разновидность целого, но с фиксированной дробной частью.[/uquote]
Таки ДА!
Код для микроСи 7500Гц, полоса 75Гц, выборка 5мкС. Перестройка частоты программно одним коэффициентом. Покрывает весь звуковой диапазон.

си7500.txt

(1.44 КБ) 170 скачиваний

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888420#p3888420"]Таки ДА!
Перестройка частоты программно одним коэффициентом.[/uquote]
Милейший Линьков, не смешите мои тапочки. Вы в очередной раз опубликовали код экспоненциального фильтра В ФИКСПОЙНТАХ приведенных к общему множителю.

Итого в сухом остатке - таки НЕТ!!!

[linkov1959]

КРАМ, спуститесь на землю, реальность проще, чем Вам кажется!

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888456#p3888456"]реальность проще[/uquote]
Реальность такая, какая она есть. Дробные числа в рекурсивных фильтрах - неизбежное следствие дробных коэффициентов.
Стандартный метод работы с дробными числами с фиксированной точкой - умножение их до целого, а при выводе - деление для восстановления порядка. Что собственно в Вашем коде и наблюдается.

[linkov1959]

КРАМ, это Ваши фантазии вокруг голимой теории, в реальности я операции Float заменил операциями с целыми. У меня нет ни одной дробной переменной. В результате быстродействие выросло на порядок. Это реальность!

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888543#p3888543"]я операции Float заменил операциями с целыми.[/uquote]
Тут нюанс в том, что фикспойнт является разновидностью целого...

Можно жопу назвать лицом, но по факту она останется жопой.

Код: Выделить всё

newin = invar*200000/101833;

Предлагаю еще более ускорить вычисления, заменив эту строку на

Код: Выделить всё

newin = invar*514851/262144;

По поводу кода с main без while(1) я уже не говорю...

[linkov1959]

КРАМ, от добра добра не ищут, и так лишнего хватил. Степень двойки тут не прокатит, там пять связанных коэффициентов.
Я вот думаю вместо преобразований Фурье сделать сканирование и получить спектр нужного диапазона. Что скажете?

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888602#p3888602"]Степень двойки тут не прокатит, там пять связанных коэффициентов.[/uquote]
Шозабред? ЛЮБОЕ дробное число может быть представлено в формате фикспойнт при домножении его на степень двойки. Естественно, как и флоат, дробное число будет представлено с конечной точностью. Причем точность фикспойнта при 32 разрядах выше точности флоата, у которого мантисса имеет лишь 24 разряда.
В моем предложении выше речь шла о формате фикспойнта 14.18 (иногда пишут 14q18). При 12 разрядах сигнала - это запредельная избыточность по точности-разрешению.
[uquote="linkov1959",url="/forum/viewtopic.php?p=3888602#p3888602"]Я вот думаю вместо преобразований Фурье сделать сканирование и получить спектр нужного диапазона. Что скажете?[/uquote]
Еще одна фееричная глупость.
Спектр получают либо дискретным преобразованием Фурье (ДПФ-DFT), либо быстрым (БПФ-FFT)
В первом случае для получения синусно-косинусного спектра количество умножений пропорционально N^2, а во втором - N*log(N).
В зависимости от системы команд МК пересечение равных производительностей методов DFT/FFT может быть на разном количестве фильтров.
ДПФ по сути представляет из себя квадратурный приемник прямого преобразования по каждому из фильтров. С точки зрения самостоятельной реализации "от нуля" без особого изучения - это самый простой вариант. Очень похож на FIR по своей реализации. Сумма произведений отсчетов сигнала на отсчеты синуса и косинуса дают синусно-косинусную (алгебраическую) форму комплексного значения 1 фильтра ДПФ. Для получения модуля (амплитуды сигнала) находят корень квадратный из суммы квадратов синусного (Imaginary) и косинусного (Real) значений сигнала в фильтре.
БПФ - это, прежде всего, расчет элементарного узла - "бабочки". Комплексная сумма A=A+B и комплексная разность с умножением на комплексный коэффициент B=(A-B)W.
Расчет "бабочки" БПФ эффективен при наличии trueDSP инструкций в МК. Скажем, для dsPIC33 я сумел написать "бабочку" на АСМе с выполнением ее за 23 машинных цикла. Но это лишь одна "бабочка", а их N*logN, не считая загрузки указателей на данные-коэффициенты (pA, pB, pW) для функции "бабочки".

Код: Выделить всё

; W10=pA
; W11=pB
; W8=pW
; A=A+B
; B=(A-B)W
BtflCmplx:
	mov		#0x7FFF, W4				; W4=0.99999
	clr		A, [W10]+=2, W6				; W6=Ar, [W10]->Ai
	clr		B, [W8]+=2, W5, [W11]+=2, W7		; W7=Br, [W11]->Bi, W5=Wr [W8]->Wi
;--- perform A
	mac		W4*W6, A, [W10]-=2, W6			; ACCA+=(1*Ar), W6=Ai, [W10]->Ar
	mac		W4*W7, A, [W11]-=2, W7			; ACCA+=(1*Br), W7=Bi, [W11]->Br
	sac.r		A, #-1, [W13++]				; Ar(new)=ACCA.rnd->buf
	mac		W4*W6, B, [W10]+=2, W6			; ACCB+=(1*Ai), W6=Ar, [W10]->Ai
	mac		W4*W7, B, [W11]+=2, W7			; ACCB+=(1*Bi), W7=Br, [W11]->Bi
	sac.r		B, #-1, [W13++]				; Ai(new)=ACCB.rnd->buf
;--- perform B
	mpy		W5*W6, A, [W10]-=2, W6			; ACCA=Wr*Ar, W6=Ai, [W10]->Ar
	msc		W5*W7, A, [W8]-=2, W5, [W11]-=2, W7	; ACCA-=(Wr*Br), W5=Wi, [W8]->Wr, W7=Bi, [W11]->Br
	msc		W5*W6, A				; ACCA-=(Wi*Ai)
	mac		W5*W7, A, [W8]+=2, W5			; ACCA+=(Wi*Bi), W5=Wr, [W8]->Wi
	sac.r		A, #-1, [W13++]				; Br(new)=ACCA.rnd->buf
	mpy		W5*W6, B, [W10]+=2, W6			; ACCB=Wr*Ai, W6=Ar, [W10]->Ai
	msc		W5*W7, B, [W8], W5, [W11]+=2, W7	; ACCB-=(Wr*Bi), W5=Wi, W7=Br, [W11]->Bi
	mac		W5*W6, B				; ACCB+=(Wi*Ar)
	msc		W5*W7, B				; ACCB-=(Wi*Br)
	sac.r		B, #-1, [W13]				; Bi(new)=ACCB.rnd->buf
;--- save result
	mov		[W13--], [W11--]			; save Bi
	mov		[W13--], [W11]				; save Br
	mov		[W13--], [W10--]			; save Ai
	mov		[W13], [W10]				; save Ar
	return

Обратите внимание на комментарии к каждой инструкции (после точки с запятой). Это действия выполняемые этой инструкцией за 1 машинный цикл. Индексы i и r в комментариях, как Вы уже поняли, это мнимая (imaginary) и действительная (real) компоненты комплексных операндов.

[linkov1959]

КРАМ, Вот я тут нашел полную программу анализа звукового диапазона, там еще прилагается 3 таблицы с целыми числами. У мужика на ATmega32 работает.

фурье.txt

(3.83 КБ) 219 скачиваний

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

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888694#p3888694"]я тут нашел[/uquote]
Любезный Линьков, Вы плохо себе представляете что такое спектральный анализ и для чего он вообще нужен. Поэтому не умеете пользоваться анализаторами спектра, независимо от того, аналоговый он или цифровой.
"Иголки", как Вы изволили выразиться на спектрограмме получаются тогда, когда полоса анализа много меньше полосы обзора. Но в любом типе анализатора спектра полоса анализа может переключаться. Причем полоса анализа может изменяться как по входу, так и по выходу анализатора.
Кроме того, спектр сигнала ПО ОПРЕДЕЛЕНИЮ не оперирует понятием времени. Поэтому в зависимости от скорости изменения спектра сигнала реальная спектрограмма может принимать самые странные формы. Для получения спектра наиболее близкого реальному нужно понимать какие параметры анализа следует устанавливать.
Избирательность анализатора спектра, как я ранее уже сказал, определяется полосой пропускания приемника анализатора для аналогового прибора с последовательным анализом и временем накопления (количеством отсчетов с учетом частоты Найквиста) для цифрового анализатора реализующего FFT.
И последнее. FFT в обычном цифровом осциллографе - это пародия на анализ. Чисто рекламный трюк. Даже если бы задаться целью сделать на его основе что то более-менее приемлемое, то 8 битный АЦП даст не более 48 дБ мгновенного динамического диапазона, что для прибора даже начального уровня - это НИ О ЧЕМ..., пустышка.
Ригол делает аналоговые и в общем недурные анализаторы спектра. На прибор с частотами от 9 кГц до 1,5 ГГц и динамикой порядка 80...90 дБ цена примерно четверть миллиона рублей. Это практически начальный уровень для такого измерительного прибора. Анализаторы спектра реального времени (FFT) только стартуют с 1,5...2 миллионов рублей.

Добавлено after 12 minutes 40 seconds:
[uquote="linkov1959",url="/forum/viewtopic.php?p=3888694#p3888694"]У мужика на ATmega32 работает.[/uquote]

Это смешно называть игрушку на десяток фильтров и на десяток дискретов по амплитуде анализатором спектра.
Посчитайте на досуге сколько фильтров FFT нужно для реализации третьоктавного анализатора спектра звукового диапазона частот. Намекаю. Фурье-анализ дает ЛИНЕЙНУЮ шкалу частот...

[linkov1959]

КРАМ, тогда выпишу stm32H750! Как раз вышла последняя версия микроЕ с его поддержкой.

[Мурик]

Если планируете использовать mikroC лучше сразу перейти на другую IDE с нормальным компилятором, потому что оптимизатор у компиляторов микроэлектроники не эффективный. Получите тоже что у GCC с -O0 и без LTO. А это скажется на скорости выполнения и размере прошивки.

[КРАМ]

[uquote="linkov1959",url="/forum/viewtopic.php?p=3888757#p3888757"]тогда выпишу[/uquote]
Я бы Вам посоветовал прежде ознакомится с теорией спектрального анализа, а перед этим с теорией сигналов. Хотя бы поверхностно. Иначе проку с затеи не будет никакого. Ну если не считать малопонятных картинок.
ЗЫ. К слову, анализатор спектра звукового диапазона частот достаточно неплохо реализуется на звуковой карте и соответствующем ПО. Даже на H7 будет хуже.