Так как ARM-архитектура в принципе не умеет распараллеливать доступ к операндам в памяти одновременно с АЛУ-операциями. Это архитектурное ограничение. Но тем не менее во всех мануалах про ARM говорится о том, что они "имеют набор DSP-инструкций" (старшие ядра >= Cortex-M3; а также классические ARM7/9).
Но Вы намекнули, я так понимаю, на архитектуру DSP Аналог девайса и ТИ. Расскажите как там Си интерпретируется в DSP MAC?
В смысе как? Нормально. У меня под рукой нет CCS, но например для VLIW-процессоров получается очень эффективный код. В котором множество загрузок распараллеленых с вычислениями. Там это позволяет архитектура ядра. Да даже и на старом C5000 ядре насколько помню - компилятор знал про эти инструкции. Другое дело, что про аппаратные циклы он в те времена не знал (когда я им пользовался лет 15 назад), но вроде как с тех пор CCS даже аппаратные циклы для C5000 освоил (для VLIW он сразу умел аппаратные циклы).
В ARM есть MAC-команды. Но нет команд выполняющих одновременно АЛУ-операцию с доступом к памяти. Это - ограничение архитектуры ядра.
Это не считается? Спойлер
Это видимо говорит о том, что во время выполнения предыдущей MAC-инструкции CPU может начать выполнение следующей инструкции загрузки данных. Т.е. - это уже другая инструкция, а не MAC. Это в Cortex-M7 видимо? И предыдущие ядра Cortex-M умели подобное, но не для MAC, а для инструкций LDR: если две LDR выполнять последовательно, то вторая может быть укорочена на один такт, при соблюдении каких-то дополнительных условий.
Но вот чтобы это было в одной инструкции - такого насколько мне известно в ARM нет.
Это видимо говорит о том, что во время выполнения предыдущей MAC-инструкции CPU может начать выполнение следующей инструкции загрузки данных. Т.е. - это уже другая инструкция, а не MAC. Это в Cortex-M7 видимо?
Да, но фактически за такт выполняется два обращения к памяти и две операции ALU.
Цитата:
И предыдущие ядра Cortex-M умели подобное, но не для MAC, а для инструкций LDR: если две LDR выполнять последовательно, то вторая может быть укорочена на один такт, при соблюдении каких-то дополнительных условий.
Нет, это обычное конвеерное выполнение команд, при котором иногда можно сэкономить лишний такт. До M7 не было ни сдвоенного ALU, ни двухканального доступа к памяти, для этого как минимум нужна 64-х битная шина...
В смысе как? Нормально. У меня под рукой нет CCS, но например для VLIW-процессоров получается очень эффективный код.
Зайду немного с другой стороны. У ТИ в компиляторах под DSP процессоры есть библиотеки и среди них есть (очевидно) типовые функции DSP - IIR, FIR, FFT всех разновидностей и типов данных. Вопрос. Если открыть исходники на эти функции (если конечно они доступны), то на чем они написаны? На Си или на АСМе?
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Да, но фактически за такт выполняется два обращения к памяти и две операции ALU.
А где Вы там прочитали про "за один такт"? Там про такты ничего не сказано. Этот double-load вполне возможно что за 2 такта выполняется. "double load with one instruction" - это думаю имеется в виду команда типа LDRD, которая была и в CM4 и выполнялась за 2 такта. Хотя может в CM7 она стала выполняться за один такт, если D-bus в CM7 64-битная. Надо мануал читать.
Нет, это обычное конвеерное выполнение команд, при котором иногда можно сэкономить лишний такт. До M7 не было ни сдвоенного ALU, ни двухканального доступа к памяти, для этого как минимум нужна 64-х битная шина...
Предыдущие ядра (CM4) уже умели частично конвееризировать команды LDR/STR. Сокращая их на 1 такт. Шина 64 для этого не нужна, если вспомнить что штатное время выполнения LDR/STR - 2 такта.
У ТИ в компиляторах под DSP процессоры есть библиотеки и среди них есть (очевидно) типовые функции DSP - IIR, FIR, FFT всех разновидностей и типов данных. Вопрос. Если открыть исходники на эти функции (если конечно они доступны), то на чем они написаны? На Си или на АСМе?
Для C5000 ядра, когда я им плотно занимался, эти библиотеки были и были они на асме. И это было оправданно, так как в те времена си-компилятор генерил ужасный код и многого не умел (но MAC-инструкции он умел; главное чего не умел - аппаратные циклы). Было это давно (~15лет назад) и сейчас (как я слышал) компилятор C5000 стал намного умнее. Но я не проверял так как проектов на нём давно не имею (хотя и отладки и девайсы и эмуляторы - есть). Но даже эти штатные библиотеки были написаны индусами так криво, что самостоятельное переписывание их (на асм) давало ускорение выполнения в 2-3 раза.
Другая картина с VLIW (ядро C674x, DSP TMS320C674x, OMAP-L137/L138). Для них уже лет 10 назад компилятор выдавал вполне приемлемый результат. Да, там были библиотеки, но если написать на си такую же функцию, написать её грамотно (не мешая компилятору оптимизировать, понимая как работает конвеер DSP, применяя разные квалификаторы указателей типа restrict; строя код вычисления так, чтобы по-возможности было как можно меньше зависимостей вычислений следующей операции от результата предыдущей и пр.), то потом скорость выполнения была точно такой-же как и у библиотечной функции. Я для теста делал две ветки кода: с библиотечными функциями и чисто на си, сравнивал время их выполнения (по таймеру) и получал точное совпадение в пределах погрешности измерений. Из чего я вообще сделал вывод, что и сами библиотеки эти видимо написаны на си. Так что на VLIW использовать либы для ускорения - не имеет смысла. Ещё читал, что на VLIW трудно (и почти невозможно) писать на ассемблере человеку из-за того что там другой принцип выполнения инструкций: выполнение идёт не-покомандно, а из команд формируются fetch-пакеты, которые как единое целое выбираются из памяти и как единое целое выполняются. И си-компилятор строит эти fetch-пакеты.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
А где Вы там прочитали про "за один такт"? Там про такты ничего не сказано. Этот double-load вполне возможно что за 2 такта выполняется. "double load with one instruction" - это думаю имеется в виду команда типа LDRD, которая была и в CM4 и выполнялась за 2 такта. Хотя может в CM7 она стала выполняться за один такт, если D-bus в CM7 64-битная. Надо мануал читать.
Там сдвоенная 32-х битная DTCM, у CPU к ней эксклюзивный доступ, плюс двухканальный Load Store Unit и ALU, у M4 ничего этого нет, еще и конвеер всего 3-х стадийный, против 7-ми у M7. К тому же M7 может распараллеливать не только загрузку данных и операции ALU, а в принципе любые команды, если выполнены определенные условия.
Предыдущие ядра (CM4) уже умели частично конвееризировать команды LDR/STR. Сокращая их на 1 такт. Шина 64 для этого не нужна, если вспомнить что штатное время выполнения LDR/STR - 2 такта.
Допустим пара LDR выполняется на M4 за 2+1 такта, а будь у него 64-х битная шина могло бы хватить одного чтения выполняемого за 2 такта, так что выгода от 64-х битности безусловно есть.
Там сдвоенная 32-х битная DTCM, у CPU к ней эксклюзивный доступ, плюс двухканальный Load Store Unit и ALU, у M4 ничего этого нет, еще и конвеер всего 3-х стадийный, против 7-ми у M7. К тому же M7 может распараллеливать не только загрузку данных и операции ALU, а в принципе любые команды, если выполнены определенные условия.
Да, классно, это хороший шаг вперёд для ARM! Но у меня пока нет проектов на CM7.
Допустим пара LDR выполняется на M4 за 2+1 такта, а будь у него 64-х битная шина могло бы хватить одного чтения выполняемого за 2 такта, так что выгода от 64-х битности безусловно есть.
Да, Вы правы. Но всё-таки: чтобы в одной команде обращение к памяти + АЛУ-операция - такого и в CM7 нету. Да и вообще - далеко ему ещё до ядра C674x.
PS: Да даже на C5000 симметричный КИХ-фильтр можно посчитать тратя всего 1 такт на каждые два порядка фильтра (фильтр 300-го порядка - ~150 тактов). Правда с 16-битными коэффициентами. И шина к ОЗУ там не 64-битная, а 5 шт. 16-битных шин (2 - для кода, 3 - для данных) + 2-портовая память. А сколько тактов потребуется на Cortex-M7?
Таки ДА! Перестройка частоты программно одним коэффициентом.
Милейший Линьков, не смешите мои тапочки. Вы в очередной раз опубликовали код экспоненциального фильтра В ФИКСПОЙНТАХ приведенных к общему множителю. Итого в сухом остатке - таки НЕТ!!!
Реальность такая, какая она есть. Дробные числа в рекурсивных фильтрах - неизбежное следствие дробных коэффициентов. Стандартный метод работы с дробными числами с фиксированной точкой - умножение их до целого, а при выводе - деление для восстановления порядка. Что собственно в Вашем коде и наблюдается.
КРАМ, это Ваши фантазии вокруг голимой теории, в реальности я операции Float заменил операциями с целыми. У меня нет ни одной дробной переменной. В результате быстродействие выросло на порядок. Это реальность!
КРАМ, от добра добра не ищут, и так лишнего хватил. Степень двойки тут не прокатит, там пять связанных коэффициентов. Я вот думаю вместо преобразований Фурье сделать сканирование и получить спектр нужного диапазона. Что скажете?
Степень двойки тут не прокатит, там пять связанных коэффициентов.
Шозабред? ЛЮБОЕ дробное число может быть представлено в формате фикспойнт при домножении его на степень двойки. Естественно, как и флоат, дробное число будет представлено с конечной точностью. Причем точность фикспойнта при 32 разрядах выше точности флоата, у которого мантисса имеет лишь 24 разряда. В моем предложении выше речь шла о формате фикспойнта 14.18 (иногда пишут 14q18). При 12 разрядах сигнала - это запредельная избыточность по точности-разрешению.
Я вот думаю вместо преобразований Фурье сделать сканирование и получить спектр нужного диапазона. Что скажете?
Еще одна фееричная глупость. Спектр получают либо дискретным преобразованием Фурье (ДПФ-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) компоненты комплексных операндов.
Спектральный анализ в виде иголок у меня осциллы выдают, но это не то. Реальные приборы имеют избирательность, интересно видеть диапазон их глазами, или слушать их ушами. Еще 40 лет назад получил на радиоцентр целую стойку, которая печатала эти гребенки - толку реального никакого. Пока в наушниках не просканируешь диапазон реальным приемником, не найдешь хорошего места для работы. Ради спортивного интереса, может и займусь на досуге.
Любезный Линьков, Вы плохо себе представляете что такое спектральный анализ и для чего он вообще нужен. Поэтому не умеете пользоваться анализаторами спектра, независимо от того, аналоговый он или цифровой. "Иголки", как Вы изволили выразиться на спектрограмме получаются тогда, когда полоса анализа много меньше полосы обзора. Но в любом типе анализатора спектра полоса анализа может переключаться. Причем полоса анализа может изменяться как по входу, так и по выходу анализатора. Кроме того, спектр сигнала ПО ОПРЕДЕЛЕНИЮ не оперирует понятием времени. Поэтому в зависимости от скорости изменения спектра сигнала реальная спектрограмма может принимать самые странные формы. Для получения спектра наиболее близкого реальному нужно понимать какие параметры анализа следует устанавливать. Избирательность анализатора спектра, как я ранее уже сказал, определяется полосой пропускания приемника анализатора для аналогового прибора с последовательным анализом и временем накопления (количеством отсчетов с учетом частоты Найквиста) для цифрового анализатора реализующего FFT. И последнее. FFT в обычном цифровом осциллографе - это пародия на анализ. Чисто рекламный трюк. Даже если бы задаться целью сделать на его основе что то более-менее приемлемое, то 8 битный АЦП даст не более 48 дБ мгновенного динамического диапазона, что для прибора даже начального уровня - это НИ О ЧЕМ..., пустышка. Ригол делает аналоговые и в общем недурные анализаторы спектра. На прибор с частотами от 9 кГц до 1,5 ГГц и динамикой порядка 80...90 дБ цена примерно четверть миллиона рублей. Это практически начальный уровень для такого измерительного прибора. Анализаторы спектра реального времени (FFT) только стартуют с 1,5...2 миллионов рублей.
Это смешно называть игрушку на десяток фильтров и на десяток дискретов по амплитуде анализатором спектра. Посчитайте на досуге сколько фильтров FFT нужно для реализации третьоктавного анализатора спектра звукового диапазона частот. Намекаю. Фурье-анализ дает ЛИНЕЙНУЮ шкалу частот...
Если планируете использовать mikroC лучше сразу перейти на другую IDE с нормальным компилятором, потому что оптимизатор у компиляторов микроэлектроники не эффективный. Получите тоже что у GCC с -O0 и без LTO. А это скажется на скорости выполнения и размере прошивки.
Я бы Вам посоветовал прежде ознакомится с теорией спектрального анализа, а перед этим с теорией сигналов. Хотя бы поверхностно. Иначе проку с затеи не будет никакого. Ну если не считать малопонятных картинок. ЗЫ. К слову, анализатор спектра звукового диапазона частот достаточно неплохо реализуется на звуковой карте и соответствующем ПО. Даже на H7 будет хуже.
Сейчас этот форум просматривают: Юрий48 и гости: 22
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Вот мы и вернулись к тому, с чего начали. Именно поэтому я и написал:
Там про такты ничего не сказано. Этот double-load вполне возможно что за 2 такта выполняется.
