Перейти к содержанию
    

Rst7

Модератор
  • Постов

    4 619
  • Зарегистрирован

  • Победитель дней

    2

Сообщения, опубликованные Rst7


  1. 22 minutes ago, NStorm said:

    Не вижу смысл ставить в свою систему какое-то сомнительное ПО, которое ставит свой драйвер уровня ядра.

    Это как раз нормальная софтина. Ну когда-то была, пока ее поддерживали в актуальном состоянии и другой не было. Потом появился LatencyMon, с возможностью куда более расширенной диагностики.

    В общем выяснилось, что самый кривой с точки зрения затыков в DPC драйвер - это Nvidia. Причем, на всех системах по разному: бывает хорошо, а бывают полные провалы. Кому DPC Latency действительно важно (например, обработка многоканального звука в реальном времени), тот либо по RDP без видеокарт использует комп, либо ATI туда ставит.

    Ну а по совсем нынешним временам куда более интересно и поучительно разглядывать вот такие скриншоты:

    image.thumb.png.ab31df7b1dbf79b4616c7fddf640e0ec.png

    8 minutes ago, Zoltrix said:

    И вообще не пойму зачем вы спорите? ХП-ишка работает с железом напрямую, десятка - через прокладки.

    Что за глупости? Какие еще прокладки?

  2. 2 hours ago, Zoltrix said:

    Протестировал латентность в ХП-ишке. Получаю время от 12 до 40 мкс. В основном 18...22. В семерке была цифра от 40 до 150 мкс + пики до 250...500 мкс. В десятке не тестировал, но думаю не лучше семерки.

    DPC Latency Checker покажет проблемы только если там совсем плохо. Потому что он измеряет время от инициации DPC до начала собственно выполнения отложенной процедуры. Причем делает это раз в 1мс. Куда более полное представление о происходящем можно получить при помощи LatencyMon, правда, на XP работают только версии до 5й включительно. Гарантирую, что Вы там увидите совсем другие цифры, ибо там рапортуется о максимальных временах выполнения всех DPC.

     

  3. Скорее всего у вас уже сам tcpdump - узкое горлышко. Пора писать собственный софт, для начала хотя бы просто recvfrom в бесконечном цикле. Оцените загрузку процессора. Потом будете пробовать запись на диск добавлять.

    Ну или попробуйте поиграться с параметрами типа Interrupt moderation/Interrupt coalescing/etc

     

  4. 1 hour ago, Alex77 said:

    Мне просто очень интересно как винХР 32 уделывает наповал вин10 64. в такого рода вычислениях

    Да никак не уделывает, не переживайте. Проигрывает безусловно. Причины я уже перечислил, и они совсем не в количестве доступного процессу ОЗУ, хотя в некоторых применениях это ох как важно.

     

  5. 2 hours ago, Alex77 said:

    Другими словами это не обработка видео/звука/не архивирование.

    Вы плохо думаете об обработке видео/звука ;) При нелинейном монтаже крайне желательно иметь произвольный быстрый доступ к любым данным. Как бы можно и в 32 бита, частями файлы маппить в адресное пространство, так и делали в уже доисторические времена,  но очень геморойно это, а с 64тибитной архитектурой все куда веселее и удобнее.

  6. 9 minutes ago, one_eight_seven said:

    Это инженерный опыт создания компиляторов?

    Ах простите, Xcelium - это симулятор же, да? Ну что, если уважаемым удалось распараллелить вычисления, используя всякие SSE - только честь им и хвала. Я почему-то подумал про компилятор, потому это мое возражение снимается. Значит просто перепишут, тем более, что на сайте вроде пишут, что 

    Quote

    Supports x86, Arm®, and cloud compute platforms

     

  7. 1 hour ago, one_eight_seven said:

    но это работает только там, где это пара-тройка циклов и не требуется огромный объём тестирования.

     

    Да всегда там пара-тройка циклов. А то и скорее всего вообще сторонняя библиотека типа fftw, которую давно портировали ;) А если больше - то это что-то такое специфическое, которое совсем не надо каждый день на другую архитектуру портировать. И скорее всего - вообще не надо.

    1 hour ago, one_eight_seven said:

    только x86

    Ничего, перекомпилируют, когда время придет. Сто процентов нет там привязок к x86. Ну вот не верю я (читай - мой уже, блин, немалый инженерный опыт подсказывает), что там прям нужны какие-нибудь SSE4-инструкции.

    1 hour ago, RobFPGA said:

    Ну разве что это очень дорого  - особенно для Enterprise. 

    Да ладно вам. Кодерки средней руки щас по рублю пучок. А других для этого сегмента и не надо.

  8. Just now, one_eight_seven said:

    Использование FPU, SIMD и прочих шалостей нередко требует переписывания вручную. Этого компиляторы пока ещё не умеют, но начинают уметь всё больше и больше.

    Да этого где-то в паре-тройке inner-loop'ов может есть десяток-другой инструкций. Ничего сложного в самом ручном переписывании нет.

  9. 1 hour ago, one_eight_seven said:

    У интела тоже уже очень давно RISC под капотом, а сверху аппаратная надстройка для обеспечения бинарной совместимости со старым CISC'ом.

    Это неважно. Важно то, как это выглядит с точки зрения программиста. Если нет ортогональности - компиляторы сильно проигрывают.

     

    1 hour ago, one_eight_seven said:

    операционки под AARCH64 уже имеются

    Любые *nix'ы, например. MacOS в том числе, кстати, там и так одна и та же ОС в двух таргетах работает, один из них - ПК, другой - телефоны/планшеты на AARCH64. Вот собираются и ПК перевести на унифицированную архитектуру, так сказать.

    1 hour ago, one_eight_seven said:

    серверное ПО тоже появляется во всё больших количествах

    Да как бы все это "серверное ПО" получается автоматически при сборке *nix'ов под новое ядро.

    1 hour ago, one_eight_seven said:

    а Java приложениям так и вовсе нет дела на какой операционке выполняться, JIT под AARCH64 тоже имеется.

    Да кому они нужны эти жаба-приложения?

  10. 15 hours ago, Zoltrix said:

    Я бы долго доказывал.

    Доказывали что? Наконец-то в 64й архитектуре РОНов стало не 8, а 16. И чуть более ортогональной стала система команд. В среднем компиляторы Си процентов на 20 более эффективный код генерят для x64, нежели для x86. Потому байки про "более производительную 32хбитную архитектуру" не надо нам тут рассказывать, уж чего-чего, а на своем собственном опыте много раз перемерял. Я имею в виду тестирование того софта, который я пишу под PC, например, всяческая ЦОС. Вообще, конечно, сама по себе архитектура Intel'овских процов - говнище то еще, но хоть чуть-чуть меньше содрогания испытываешь, когда смотришь в листинг для x64, а не x86. Не зря вон Apple решил таки на ARM'ы все переводить.

    Теперь о том, какие прелести более современных ОС с точки зрения более адекватной данному форуму, нежели использование PC в качестве печатной машинки. Например, появление с Win8.1 крайне полезного API для работы с сокетами под названием Registered IO. Кстати, аналогичные дела с USB тоже вроде с 8.1 только появились. Но это все, понятное дело, неинтересно тем, кому буковки шлепать в txt-файлах, а интересно только тем, у кого, скажем, широкие потоки информации надо принять и обработать.

    Ну и, кстати, лишнее, например, с Win10 отпиливается очень быстро. Реально там надо всего-то чуть более десятка запущенных служб, остальное можно выключить нафиг (вместе со всеми прекрасными обновлениями, телеметриями и прочим шлаком), правда, не под простым пользователем. Run as Trusted Installer - великая вещь для такой кастомизации, вдруг кто не в курсе.

  11. 18 minutes ago, serg_Fry said:

    Не можем найти подходящий высоковольтный (напряжение пробоя сток-исток менее -800В) P-канальный полевой транзистор.

    Как насчет в два этажа включить транзисторы? Хотя, конечно, там придется пободаться со скоростью верхнего транзистора, да.

    Можно вообще поглядеть Вашу схему выходного каскада?

  12. 1 hour ago, aaarrr said:

    Почти 480 при теоретическом пределе для HS bulk в 426Mbps?

    В смысле если пересчитать со всеми накладными расходами, то достигается почти Wire Speed. Конечно, если считать по чистым данным TCP, то меньше.

  13. 9 hours ago, AlexandrY said:

    Есть люди упорно изобретающие велосипед, с этим ничего не поделать.  

    Есть люди, упорно расказывающие байки типа:

    Quote

    Микроконтроллер семейства Renesas S7G2 (ядро Cortex-M4 ) на 240 МГц дает скрость передачи по TCP поверх USB 2.0 HS около 60 мегабит в сек

    Или

    Quote

    Т.е. вам достаточно микроконтроллера 400 Мгц чтобы сделать 100 мегабит TCP канал через USB 2.0.

    И ничего с этим не поделать.

     

    И скажите, что делать бедным самопальщикам, у которых iIMX RT1020 через USB HS почти 480Mbps продувает с загрузкой проца порядка 30%? Имеется в виду RNDIS и TCP, конечно.

  14. 3 hours ago, AlexandrY said:

    Для самопальщиков с "самописанными стеками" и кастрированной функциональностью этого может и хватает.  

    Конечно-конечно. Это как раз Вы самопальщик - ничего самостоятельно написать не можете, только из готовых кубиков слепить что-то умеете.

    59 minutes ago, AlexandrY said:

    Будет соблазн и выполнять программу из SPI Flash, но тогда я за ваши гигабиты не ручаюсь. 

    Отлично она из SPI Flash выполняется. Понятное дело, если бездумно "кубиками" засирать I-Cache и D-Cache, то толку не будет.

  15. 41 minutes ago, _Ivana said:

    если осилю волшебную индуктивную связь в цепи эммитера

    Это просто отвод от 15% витков. Просто в spice-симуляторе так удобнее. Отсчитываете от верхнего по схеме вывода L2 15% витков и припаиваете туда вывод R1. А L3 делать не надо, это просто для имитации катушки с отводом сделано.

  16. 11 hours ago, mvb said:

      У кого нибудь есть опыт работы с этим усилителем?

    У меня есть. Работают без проблем, без возбуждений и непонятных сдвигов уровней.

    Quote

    Посоветуйте какую-нибудь простую рабочую схему?

    Схема из даташита на TPA6120 вполне простая и рабочая.

    Quote

    Какое напряжение питания стоит брать?

    Я бы давал вольт по 9 на плечо. Токи, соответственно, будут до 300мА в импульсе.

    Quote

    Можно ли пытаться это сделать на мощном ОУ?

    Можно. AD8397 очень даже ничего работает.

  17. 2 minutes ago, mvb said:

    На входе усилителя постоянное смещение порядка 100 мкВ. Я так понимаю, что из отрицательного входа TPA6120 набегает ток, который на сопротивлении в цепи обратной связи создаёт смещение.

    Ну и что, что 100мкВ? Давайте-ка полную схему, чего куда Вы там насоединяли, с номиналами.

    5 minutes ago, mvb said:

    Наушники обычные, 16-30 Ом.

    А, кстати, источник питания у Вас там достаточно крепкий? Сможет сотню-другую миллиампер выдать?

  18. 1 hour ago, Plain said:

    от 12 В питания надо обязательно отказаться — легко лишиться не только наушников, но и ушей.

    Никто никого не лишится. +-9..12 вольт - вполне нормальное питание для раскачки обычных студийных наушников с сопротивлением 250ом, например популярных Beyerdynamic DT 770. Для каких-нибудь низкоомных затычек это может и многовато, но, например, я для довольно чувствительных внутриканальных наушников с очень даже вменяемой звукоизоляцией, делал усилитель в In-Ear мониторинге с питанием 12вольт (+-6В), и этого было ну в притык, если на сцене громко.

    И еще момент -  тот же самый TPA6120A2 - отнюдь не Rail-To-Rail, кстати.

  19. Как-то очень меня этот Захаровский приемник подзацепил. Когда-то в юности у меня он не поехал, терпения справиться с ним не хватило, а сейчас что-то захотелось размять мозги, а то сплошное софтописательство неспеша превращает в омерзительного "ымбеддера".

    Посидел, подумал и вот что надумал.

    Короче, работает этот приемник нифига не так, как автор описывал. На всякий случай - оригинальная схема:

    image.png.5962e8a62b5c35babb16d12cb222363b.png

    Из-за конденсатора C4 коэффициент усиления VT1 как смесителя по постоянному току равен 0. А следовательно - этот приемник не может работать как именно приемник с ФАПЧ. Он не сможет следить за частотой сигнала.

    Вообще в целом цифры, мягко говоря, не бьются - если задаться чувствительностью 1мВ (тупенький весьма), то с предлагаемыми емкостями гетеродинного контура коэффициент управления частотой будет где-то 1МГц/В, а это значит, что усиление на ПЧ нужно иметь порядка сотни: (100кГц типичная девиация) / (1МГц/В) = 100мВ типичный сигнал управления. Это еще если коэффициент преобразования - единица, а он тут никакой, прямо скажем. Коэффициент усиления транзистора - ну десять. В общем, цифры не сходятся больше чем на порядок.

    Но как-то же (хоть и хреново), но он работает. И происходит это вот как - гетеродин захватывает входной сигнал. Без этого захвата ничего не работает. Более того, захват происходит только из-за кучи разных нелинейностей. В том числе из-за изменения Cкб в течении периода частоты гетеродина, некий такой себе параметрический захват.

    А вот уже сверху прямого захвата начинает работать именно ФАПЧ - преобразование в нулевую ПЧ на второй гармонике гетеродина и изменение напряжения Cкб, а уже как следствие - изменение частоты гетеродина.

    По моим оценкам вклад прямого захвата чуть ли не больше, нежели ли характерные сдвиги частоты от, так сказать, режима ФАПЧ.

    Более того, способность гетеродина войти в прямой захват сильно зависит от добротности гетеродинного контура, что крайне трудно предсказать.

    Ну и да, прямое детектирование никто не отменял.

     

    Что можно сделать для того, чтобы эта штука была более повторяемая:

    1. Вменяемый смеситель на встречно-параллельных диодах.

    2. Полоса пропускания смесителя и усилителя - от 0. Этим сразу снимается вопрос необходимости прямого захвата сигнала.

    3. Увеличить усиление и увеличить коэффициент управления частотой.

     

    Вот такая схема нарисовалась:

    image.thumb.png.1f77e08be9368d6db62634e22d43a8e3.png

    Что тут есть занятного?

    а) Максимальный коэффициент управления частотой. Скб - единственный конденсатор контура (если не считать небольшой емкости диодов и емкость монтажа). Коэффициент получается чуть ли не порядка 20МГц/В

    б) Режим гетеродина подобран так, чтобы иметь правильный угол отсечки диодов смесителя. Причем, этот режим сохраняется в довольно широком диапазоне токов транзистора. Обратная связь (отвод с части витков) - весьма слабая для такой схемы включения, всего с 15% витков, причем, ближе к базе, нежели к общему проводу. И тогда там все автоматически получается, диоды отпираются так, как надо. При этом транзистор всегда находится в классе А (он ведь еще и усилитель постоянного тока). Диоды смесителя надо брать именно Шоттки и с небольшими собственными емкостями. Ну да нынче этого добра кругом как грязи.

    в) Правильно (ну насколько это удалось) посчитанный пропорционально-интегрирующий фильтр, чтобы расширить диапазон устойчивой работы при сильных сигналах. Конденсатор С3 - специально небольшой, иначе при сильных входных сигналах будет неустойчивость в петле.

    г) Полностью DC path. Небольшой ток базы, протекающий через нижний диод заметно меньше несинусоидальности самого напряжения гетеродина, можно забить.

    д) Поднял питание, чтобы увеличить усиление. Да и все равно по нынешним временам веселее от литиевого аккумулятора питать, кстати, вполне приемлемый размах на последующем УНЧ можно получить.

    е) Входную цепь прикинул на 50ом, соответственно, контур входной на середину диапазона 100-108МГц.

    ж) Добавил повторитель на выход, чтобы не добавлять емкость на землю в фильтре ФАПЧ, а то см. пункт в)

     

    По сравнению с оригинальной схемой в принципе добавляется два диода плюс транзистор или диод для стабилизации режимов. Выходной повторительно можно не считать, его и в схеме Захарова очень нестыдно ставить.

     

    В симуляторе этот вариант прекрасно захватывает входной сигнал в 100мкВ, при этом типичный размах сигнала на выходе - порядка 5-6мВ.

     

    В общем, я бы такое попробовал в живую собрать. Закончится карантин и попаду в мастерскую - обязательно попробую.

  20. Тут обнаружились интересные грабли. Если в вашем софте вы отключаете OCRAM (я, например, все доступное  ОЗУ переключаю в режим ITCM/DTCM), то при любом не Power On-сбросе все повиснет. Не Power On Reset - это, например, срабатывание сторожевого таймера или софтовый сброс через регистр AIRCR, или через отладчик.

    Оказывается (это отражено в документации, понятное дело мелким шрифтом на одной из 3000 страниц мануала), что не POR (в терминах мануала - Cold reset) не сбрасывает в начальное состояние IOMUXC. Т.к. конфигурация ITCM/DTCM/OCRAM находится именно в регистрах IOMUXC, то при cold reset ядро стартует с измененной конфигурацией ОЗУ, а в Boot Rom'е колхозники забыли, что надо сначала инициализировать соответствующие регистры IOMUXC, а уже потом хоть что-то делать с ОЗУ (в конкретно Boot Rom'е первый же BL приводит к фатальным последствиям).

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

    Думаю, что такая история во всей линейке i.MX RT, а может и шире. Конкретно я работал с 1020.

    В общем, не наступите на грабли. Доклад окончен.

  21. 1 hour ago, Nikkolaj said:

    Либо быстрый контроллер с встроенным контроллером USB2.0 HS  +  внешний PHY.

    Какой-нибудь i.MX RT1010...1020 Вам вполне подойдет. Там PHY под Hi Speed уже внутри есть.

    Например, каких-нибудь 60 евро - и уже можете пробовать - https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt1020-evaluation-kit:MIMXRT1020-EVK

  22. On 4/3/2020 at 6:50 PM, _Ivana said:

    можно и с остальным повозиться, и разные варианты помакетировать )

    В общем-то сама по себе идея этого приемника очень занятная, но работать нормально он не будет никогда.

    Основная проблема - плохой режим работы гетеродина (он же и смеситель). Для хорошего коэффициента преобразования на второй гармонике транзистор должен работать в классе С с углом отсечки порядка 60 градусов. В генераторе такой режим достижим, если базовым/затворным/сеточным током перезаряжается входная емкость и транзистор подзапирается. Конкретно в этом приемнике напряжение частоты гетеродина слишком мало, и транзистор все время находится в классе А. И коэффициент преобразования из-за этого слишком мал.

     

    Из-за аналогичной проблемы практически не работает схема с доп. диодом, призванная улучшить ситуацию с прямым детектированием. В классическом смесителе на встречно-параллельных диодах напряжение гетеродина выбирается таким, чтобы угол отсечки тока диодов был порядка 60 градусов. В рассматриваемом приемнике вроде бы и да, диод работает на другой полуволне напряжения гетеродина, но только он все время открыт и практически не производит "ключевание" другой полуволны. Я даже думаю, что ситуация вообще ухудшается относительно начальной схемы, ибо характеристика диода почти наверняка сильно отличается от входной характеристики транзистора.

     

    В общем, я, конечно, понимаю, что один транзистор - это очень прикольно, но лучше бы вы попробовали намакетить вот такой приемник:

    image.png.a9a2874a6f271e0d6f75d6223024bd49.png

    Тоже в общем совершенно несложный, но заработает почти наверняка с хорошим результатом. Эта схема на самом деле весьма толковая, даже очень правильно сделан момент с устранением постоянного тока через диоды смесителя. В принципе сам УПТ стоит по нынешним временам заменить на малошумящий ОУ с заметно лучшим результатом.

×
×
  • Создать...