Rst7

И возвращаясь к передаче кучи переменных. Конечно, протокол обмена надо делать другим. Сначала складывать все long, потом все short. Итого код выглядит так: void Dump(long *d, long **s, unsigned int len32, unsigned int len16) { while(len32) { *d++=*(*s++); len32--; } unsigned short **_s; unsigned short *_d; _s=(unsigned short**)s; _d=(unsigned short*)d; while(len16) { *_d++=*(*_s++); len16--; } } Самое занятное - это результат компиляции такого тупого кода: Если разворота циклов, сделанных самим компилятором, недостаточно, то можно и самому выступить по написанию Duff Device, что несложно. Но и этот код, прямо скажем, хуже совсем на копейку, нежели JIT, но на порядок проще.

Вы не поверите )))) Только отладочная печать и отладочное махание ножками. Математику отлаживаю на большом брате. Так что ни эмуляторы, ни железные отладчики я не использую. Ну для формошлепов и любителей "нагуглить готовое решение" - не нужно.

Дайте я догадаюсь ;) Это же надо было исключительно на этапе отладки? Неужели настолько там все друг с другом запутано, что не получилось отладить по-модульно, например, а не собирать переменные из кучи мест? В таком ключе на Ваш вопрос нет ответа. Надо подняться с уровня гайки М3 (поступающих данных от АЦП) и посмотреть на алгоритм работы целиком. Думаю, что все эти примеры показывают только одно - достаточно поверхностное отношение к системному проектированию. И главное, Вы не думайте, что я тут пропагандирую "никакого низкого уровня". Я сам большой любитель, например: В общем - любим, умеем, практикуем, но в первую очередь стараемся не плодить кучу такого кода.

Это же и есть O(N). Т.е. время будет пропорционально количеству отсчетов. Коэффициент пропорциональности зависит от оптимизации в том числе, но куда полезнее подумать о возможности переделать алгоритм так, чтобы он превратился, например, в O(log2(N)). Думать надо вот в какую сторону - поиск максимума в отсортированном массиве - O(1). Можно считать - бесплатно. Прямой поиск - O(N). Возможно есть какие-то априорные знания о массиве, какие-то способы предсортировки данных, etc Просто может так оказаться, что завтра N будет равно не 512, а 4096, и никакой прямой поиск, написанный на ассемблере, не спасет.

Нет, если установленных в 1 бит немного. Куда быстрее, чем куча if'ов. Простите, а кто вообще этот протокол обмена придумал? Зачем такие безумные сложности?

Продолжаем разговор ;) Вот тут я бы пересмотрел вообще саму идеологию. Все эти прямые поиски - они все равно O(N), хоть на асме, хоть на Си. Как данные в массив попадают? Может быть их имеет смысл как-то предсортировать, если они попадают в массив малыми порциями, и этим вообще глобально улучшить ситуацию?

Это у программистов нынче такой новояз. Они обычно себя обзывают software product development company, но частенько слово development опускают.

Судя по 10В/м - это воздействие радиочастотных полей. Не должно нарушаться функционирование устройства. Походу местный дурачок неправильно заполнил протокол.

Кстати, господа, пардон во втором примере за безумные приведения к FiiFunc*, но я просто не соображу, можно ли описать тип указателя на функцию, в которой один из параметров - указатель на такую функцию.

Мне кажется, Вы сильно загоняетесь. Решение в лоб: unsigned long vars[64]; #define PROC(B,T,N) \ if (mask&(1UL<<B)) {T *_d; _d=d; *_d++=vars[N]; d=_d;} void f(unsigned long mask, void *d) { PROC(0,long,0); PROC(1,short,1); PROC(2,long,2); PROC(3,long,3); PROC(4,short,4); PROC(5,short,5); PROC(6,long,6); PROC(7,short,7); } дает вполне вменяемый результат: Тут, конечно, может возникнуть вопрос другого характера. Например, если почти все параметры используются, то грузить их в регистры при помощи LDM будет малость эффективнее. А вот у IAR'а с использованием LDM как-то не сложилось, черт его знает, почему. Но возможен другой вариант. Допустим, что из всего списка в реальности надо вообще всего пару-тройку параметров генерить. Тогда куда более эффективным решением будет такое: typedef void (*FillFunc)(void *, void *, long *); #define GLUE(A,B) A##B #define FillParam(T,N) \ void GLUE(FillParam,N)(void *functab, void *d, long *s) \ { \ T *_d; \ _d=d; \ *_d++=s[N]; \ FillFunc *_functab=functab; \ FillFunc nf=*_functab++; \ nf(_functab,_d,s); \ } FillParam(long,0) FillParam(short,1) FillParam(long,2) FillParam(short,3) void FillParamEnd(void *functab, void *d, long *s) { } FillFunc FillerTask[]= { FillParam0,FillParam1,FillParam2,FillParam3, FillParamEnd }; void FillParamBegin(void *d, long *s) { FillFunc *functab=FillerTask; FillFunc nf=*functab++; nf((void*)functab,d,s); } Результат как на асме: Естественно, FillerTask можно сгенерить с нужной Вам периодичностью из редко изменяемой маски. Ну и, конечно, возможна вообще циничная генерация самомодифицирующегося кода из команд LDR R2,[R0,#+disp] и STR(H) R2,[R1],#4(2). Его генерация отлично на Си пишется. И как бы не смешно это звучало, но это будет самый оптимальный вариант (ну, правда, максимум может понадобится 64*6+2=386 байт ОЗУ для хранения генерируемого кода.

Moderator: Пока закреплять особо нечего. Наполнится - сделаю.

Простите, кто кому что должен? Тут так не принято, тут помогают на добровольной основе. Либо Вы 1. можете собрать такой материал и выложить его в общий доступ на добровольной основе. 2. можете задавать прямые вопросы в отдельных темах и получать на них ответы "гуру" на добровольной основе. 3. можете заплатить профессионалам, они сделают для Вас "дорожную карту" по борьбе за ЭМС. Заплатить, конечно, на добровольной основе.

Не знаю, возможно и да. Решение конкретно этой проблемы пока отложено на будущее.

Все, повеселились и хватит. Закрыто.

Вот тот самый Pianoteq есть для Linux под ARM, работает на Raspberry Pi. Это, конечно, не M4F, но таки ARM ;)

Есть и чисто софтовые. Имеется в виду в виде VSTi. Есть, например, Pianoteq (https://www.modartt.com/), довольно давно его уже пилят. Это рояль моделирующий. Правда, вроде там самые атаки именно семплами сделаны, но сустейн именно моделирование. А еще есть ребята Audio Modeling SWAM (https://audiomodeling.com/). Там столько параметров, что приходится специальные контроллеры использовать для прописывания партий, одной клавиатурой (имеется в виду MIDI-клавиатура) не обойдешься: Некоторые целую струнную группу БСО ухитрились вот так прописать Только не спрашивайте, как и что там сделано, не дизассемблировал ;)

Moderator: Простите, а причем тут Matlab?

Moderator: Пусть повисит тема немного, а потом снесем. Я бы сразу ее в оффтопик перенес, но тогда ТС утратит возможность доступа к теме.

Я имею в виду к какой области относится Ваше изобретение или что там. Для чего применяется? Одно дело - несущую в телеграфном передатчике умножать, а другое - музыку питчшифтить.

В области обработки аудио-сигналов есть такой термин, как pitch shift. Тоже самое, но с другого боку (оставить частоты теми же, а изменить длительность) - это time stretching. Вам в каком вообще контексте термин нужен?

Вариант проверки чего? АЦП? Вы шутите? Там 120дБ ДД. С выхода какого ЦАП предлагаете взять такую пилу? И каким "высокоточным" вольтметром измерить ее "ступеньки"? 6 знаков минимум надо, а лучше бы 7. И да, там ухудшаются характеристики на постоянном токе. Полоса ниже 20Гц в аудио-применениях не волнует от слова совсем.

В самом начале я про него говорил:

Я так думаю, что если сдуру там и сделано 32 бита только, то можно писать не 0 и 0xFFFF, а 0 и 0xFFFFFFFF почти наверняка.

Самый быстрый способ могу предложить только такой: SBFX R1,R0,#0,#1 STRH R1,[R2,#0] SBFX R1,R0,#1,#1 STRH R1,[R2,#2] .... SBFX R1,R0,#7,#1 STRH R1,[R2,#14] По два такта на пиксель. Это вполне и при помощи GCC inline asm делается, так что можно обойтись без отдельного модуля на ассемблере.

Это просто диалектика. Развитие по спирали, вся фигня.