Rst7

Ответил в ЛС.

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

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

а) Так один фиг я не умею что в 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 динамика там. А если у Вас многополосная АС с пассивным кроссовером, то все еще усложняется. Меня всегда поражают люди, которые рассказывают про "сцену", "воздух" и прочую фигню, но при этом не слышат изменения АЧХ на несколько дБ. И, повторюсь, фотографии комнаты, в которой это все прослушивалось - в студию. Для работы с АЧХ системы этого вполне достаточно.

1.pdf

Да запросто. Вы же забрели на инженерный форум. Критика тут может быть только одна: без двойных слепых тестов - это все так, аудиофилия головного мозга. И даже черт с ними, можно и без них. Я не знаю, чем Вы там слушаете, но не услышать подъема НЧ на резонансной частоте из-за увеличения выходного сопротивления усилителя может только глухой. Либо у Вас там помещение имеет такую кучу паразитных резонансов, что бубнеж на резонансе АС просто теряется среди стояков в комнате. Фотографию КДП слабо показать?

Так схема с одним ОУ не годится для заземленной средней точки. Надо два ОУ и брать разность. Просто я схему нарисовал до того, как узнал, что средняя точка заземлена. Но если уж рассматривать схему с одним ОУ, то проблемы с НЧ-наводкой возможно непринципиальны по той причине, что берутся два отсчета рядом и разность между ними. НЧ помеха будет подавлена во столько раз, во сколько ее частота ниже частоты семплирования. Да и "синфазные НЧ-наводки из канала возбуждения" - это нечто мифическое, ведь канал возбуждения - это генератор напряжения. Другое дело, что обычные 50Гц могут через емкостную связь проникать в суммирующую точку - это да. Но точно так же они могут проникать и в суммирующую точку двух отдельных усилителей. Причем, с разным уровнем. А вот тут в дело вступает другой момент в схеме с заземленным измерительным конденсатором. Это емкость монтажа с суммирующей точки на землю. Она прибавляется к измеряемой емкости. Насколько эта емкость стабильна - это отдельный вопрос. А вот схема с плавающей емкостью не имеет такой проблемы (ну пока там емкости на землю более-менее адекватны), потому может быть очень хорошо заэкранирована. Очень занятно. Надо будет поизучать на досуге.

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

Вот как-то так. Осциллограммы в уже устоявшемся режиме. Смысл фильтра после зарядового усилителя - это ведь почти согласованный фильтр для сигнала (он ведь меандр, а для него согласованный фильтр - это интегратор, а такой ФНЧ - ну в таком приближении более-менее интегратор). Потому при точках семплирования АЦП прямо на фронтах сигнала возбуждения как раз будет измеряться среднее значение за пол-периода.

Ну вот я такое и предлагаю. Только еще резистор в пару мегаом надо включить между выходом ОУ и его инвертирующим входом. И у Вас на схеме слишком уж высокая частота возбуждения, 10МГц - это много. Потому на самом деле на выходе тут не нужный сигнал, а "издержки производства". Щас нарисую, как должно быть.

Вот тут я не в курсе дела, поделитесь для общего развития подробнее, почему ему плохо от меандра?

Все равно не понимаю, зачем именно синусом? Да и квадратурные сигналы там излишество, достаточно только одного канала. В общем, считаю, что ТС'у надо бы немного подробнее рассказать про сами датчики, что они из себя представляют.

А в чем проблема?

По нынешним временам я бы даже особо не раздумывая делал так - сигнал возбуждения на датчик - меандр, после чего просто усиливал зарядовым усилителем до удобного для АЦП уровня, потом бы цифровал с частотой 2Fвозбуждения, и брал разности между двумя соседними выборками. Между зарядовым усилителем и АЦП можно включить RC ФНЧ как псевдо-интегратор, соответственно, выборка АЦП должна происходить в момент переключения полярности сигнала возбуждения. Фильтрация полезного сигнала 5кГц - это уже выполнять в цифре. Прелестей много: а) Зарядовый усилитель позволяет подключить датчик достаточно длинным кабелем без потери чувствительности. б) Упрощается схема возбуждения (логический инвертор вполне подойдет). в) Резко уменьшается количество аналоговой обвязки.

Ну тогда Вам в стандарт 802.3 - там для Вас будем много новостей в смысле ограничений. На самом деле PHY должен выполнять все требования этого стандарта. А больше он ничего не должен ;)

Я думаю, что это ответ на Ваш вопрос. Я когда делал давно софтовый MAC, на подобное поведение при отладке наступал. Ограничьте время нахождения в состоянии TX разумным значением (например, соответствующее максимальной длине фрейма Ethernet).

Если вот так сделать, как выше - то все зависит от поведения pvTaskGetThreadLocalStoragePointer. Если его можно позвать не в потоке - то вполне.

Ну Вам просто надо сделать вот что. Вместо int TickCounter; написать #define TickCounter ((int*)pvTaskGetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX)[0] И Ваш код заработает. Ну да, надо еще инициализацию сделать в каждом потоке. #define InitTickCounter vTaskSetThreadLocalStoragePointer(NULL,TICK_COUNTER_INDEX,(void*)malloc(sizeof(int))) Тут, конечно, круто использовать alloca() и инитить переменную прямо в стеке, если Ваш компилятор это позволяет.

Если Вы посмотрите на внутренности setjmp/longjmp - то они ничем не отличаются, по-большому счету.