Rst7

Вариант проверки чего? АЦП? Вы шутите? Там 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 делается, так что можно обойтись без отдельного модуля на ассемблере.

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

Ответил в ЛС.

Конечно. Синхроимпульсами вниз, в сторону отрицательных значений.

Всем спасибо за обсуждение, человек найден.

а) Так один фиг я не умею что в WDM, что в UMDF. Все равно человек нужен. б) А в Win7 оно сможет работать?

Это лишнее. Нужен только WDM и все. Остальное - наша забота.

Ищем человека, готового разработать WDM Audio driver для нашего железа. Драйвер должен будет поддерживать Win7...Win10. Собственно говоря, непосредственно с железом драйвер работать не будет, а получать-отправлять данные будет через серверную часть с доступом к ней через shared memory. Сейчас серверная часть работает в user space. У серверной части есть и другие user space-клиенты. Работа видится состоящей из нескольких этапов: 1. Заготовка драйвера, который определяется как аудиоустройство в системе. А потоки данных (ввод и вывод) имитирует работой с файлами. Собственно говоря, примерно такая заготовка и есть в WDK Samples, но нужно будет не просто ее собрать, а понять, какие именно переделки нужны будут на втором этапе. 2. Работа с файлами заменяется на работу с серверной частью. Сами данные лежат в shared memory (точнее в терминах Windows - File Mapping Object). Тут будет тонкость, связанная с тем, что есть примитивы синхронизации с серверной частью (сейчас там именованные мьютексы используются), которые, возможно, нужно будет переделать, дабы получить к ним доступ из ядра. Код клиента для user space предоставим, живой девайс для тестирования в полном объеме - тоже. 3. Необходимая параметризация - переключение всяких частот дискретизации, количества входов/выходов и прочего. Что-то надо делать на этапах 1/2, что-то отложить на более позднее время. 4. Алгоритм инсталляции/деинсталляции драйвера в систему, чтобы мы его могли прикрутить ко всей остальной нашей инфраструктуре развертывания. 5. Тестирование нами и исправление багов (понятное дело, что начнется оно где-то прямо с п.1) и закончится тут. 6. Придется уделить какое-то время потом на поддержку. Скорее всего, основные баги мы выловим при собственном тестировании, но при попадании к расширенному кругу тестеров скорее всего какие-то огрехи вылезут. Их надо будет исправить. Территориально - крайне предпочтительно Украина. Так можно будет намного более проще решать возникающие вопросы плюс тестирование с живым девайсом. Ну и ответ на главный вопрос жизни, вселенной и всего такого будет не 42, а, скажем, $1K за всю работу (до п.5 включительно). Пункт 6 - отдельный разговор, доп. оплата вполне обсуждаема, потому как по п.5 будем гонять и в хвост, и в гриву.

Да, пардон, в большинстве случаев - P=1. Входит ли это P во время доступа к флешу или нет - вот это уже неизвестно. В общем, бенчмарк бы ответил на все вопросы, но объективно при исполнении из RAM явно должен быть переход. Так что в оптимизаторе IAR'а похоже есть недоделка.

Не совсем. Три такта - сам бранч (ну если это CM3) плюс чтение новой страницы. Итого, скажем, порядка 8ми тактов.

А Вы попробуйте этот код побенчмаркать на настоящем МК. Только не в ОЗУ, а во флеше. Какой-нибудь акселератор доступа во флеш вполне может давать куда более вменяемые результаты при последовательном доступе, нежели при переходе. Возможно, именно некой среднепотолочной статистикой работы различных акселераторов в различных МК и обусловлено такое поведение оптимизатора. Возможно, кстати, что компиляция функции с модификатором __ramfunc изменит поведение оптимизатора.

Так речь же о том, что выходное сопротивление эквивалентного источника (который суть УМЗЧ с Rвых стремящееся к 0 + Ваш делитель из резисторов) становится сильно больше нуля. Если ухом Вам не слышно - возьмите измерительный микрофон. Мало того, что будет подъем на резонансе, так еще и подъем на ВЧ из-за увеличения Z динамика там. А если у Вас многополосная АС с пассивным кроссовером, то все еще усложняется. Меня всегда поражают люди, которые рассказывают про "сцену", "воздух" и прочую фигню, но при этом не слышат изменения АЧХ на несколько дБ. И, повторюсь, фотографии комнаты, в которой это все прослушивалось - в студию. Для работы с АЧХ системы этого вполне достаточно.