Open-Source USB транспорт на PIC32MZ

[dortonyan]

Проект делался для личных нужд, поэтому публикуется как есть, в том виде как сейчас зашит в моем транспорте.

Причина разработки своего транспорта - отсутствие в продаже USB транспортов с I2S входом для использования АЦП. Кроме того, те транспорты что есть в продаже не устраивали по тем или иным причинам (либо плохо сделана плата, либо большое потребление).
Раньше сдерживающим фактором было отсутствие uac2 драйверов. Однако с переходом на win10 с нативным драйвером данная проблема была решена.
Ну и вообще, т.к. на дворе 21-ый век, то для меня не понятно - почему uac2 еще не перекочевал в открытый доступ. Данная публикация призвана исправить такое досадное упущение.

Почему PIC32MZ: Преимущество перед ARM процессорами - встроенный USB HS мост и одновременно удобный компактный корпус с удобной распиновкой. А по сравнению с кмосом - низкое потребление: порядка 70..80мА максимум.

Изначально планировал использовать фреймворк (harmony configurator), однако по ходу выяснилось, что данный фреймворк генерирует только USB AUDIO приложение для формата Class 1.
Кроме того по форумам полно отзывов по касякам в фреймворке. Дорабатывать фреймворк оказалось крайне контр-продуктивно из-за жесточайшей инкапсуляции, громоздкого стека и отсутствия его описания.

Намаявшись с фреймворком принял решение писать свой код с нуля. Но очень скоро обломался, т.к. выяснилось что для PIC32 процессоров описание USB моста полностью отсутствует! Т.е. микрочип предлагает только пользоваться их кривыми фреймворками.
Однако на форуме микрочипа нашлись добрые люди, которые поделились исходниками своих проектов USB девайсов на PIC32MZ: https://www.microchip.com/forums/m1083508.aspx
Пользуясь данными примерами, а так же методом тыка, удалось написать свой достаточно эффективный код (итоговый размер с оптимизацией gcc компилятора уровня 2 - менее 16кБт).
Конечно код не такой красивый как в фреймворках, слабовата инкапсуляция. Зато, разобраться в нем и доработать под свои нужды гораздо проще. А главное проще обходить касяки периферии, которые как оказалось имеют место быть.
В частности есть не описанные в эррате проблемы с DMA модулями.

Что в итоге удалось реализовать на самом чипе, без обвеса дополнительными микросхемами:
1. Вывод стандартного стерео: 32bit 768kHz (Правда драйвер не отображает частоты выше 384к, но по факту 768к выводит). И сам модуль I2S пика позволяет выводить данные с частотой не выше 384к. 768к вывести тоже можно, но каким-то нестандартным интерфейсом, типа QSPI или параллельным портом.
2. Вывод многоканала: 8-каналов 32bit 192kHz (опробовал только в отладочном режиме, подробнее ниже).
3. Стерео вход: 32bit 768kHz (опробовал по факту только 192, т.к. мой АЦП больше не выдает).
4. Распознавание DoP формата и вывод из него стерео DSD-битстрима частотой до DSD256 включительно.
5. До кучи - добавлено CDC устройство (виртуальный COM-порт) для обмена данными с транспортом (в проекте используется в отладочном виде, на любые принятые данные отвечает строкой "CDC is works").

Вывод многоканала физически не реализован, т.к. изначально в транспорте он не предусматривался. Работу проверял в отладочном режиме, переключая на выход пары каналов по очереди (остальные каналы выводили данные в отладочные буферы).
Весь описанный выше функционал реализован на DMA модулях, благодаря чему хватает небольшой тактовой частоты процессора (160МГц для работы многоканала + стерео-входа).
Причем изначально вывод данных в I2S модули выполнялся на DMA с прерываниями. Однако, выяснилось, что прерывания DMA работаю криво, из-за чего модуль может самопроизвольно вырубаться.
Описал проблему на форуме микрочипа (в конце ветки), но - глухо как в танке: https://www.microchip.com/forums/FindPost/1219136

Пришлось выкручиваться по другому. В результате получилось даже лучше, т.к. передача данных между I2S буферами и FIFO данных получилась полностью аппаратной (DMA модули перегружаются автоматически в цикле).
Кроме того, для дополнительного снижения потребления добавлено 3 режима с разной тактовой частотой, в зав-ти от кол-ва каналов и выбранной ЧД.
В результате потребление от USB шины (контроллер + развязка) с питанием через step-down получилось от 40мА (стерео-вывод), до 55мА (8-каналов + стерео вход).
Отмечу, что в режиме FS (uac1) потребление можно опустить еще ниже: до 20..30мА, что может быть актуально для портативного девайса.

Проект сделан в IDE MPLabX 6.05, с компилятором CX32 v4.1. Проверялся только на win10. Актуальная схема транспорта ниже во вложении.
Конечно, нативный uac2 драйвер в win10 достаточно корявый, легко ломается сам и еще легче ложит винду (хватает ошибки в дескрипторе). Но готовый проект значительно облегчает отладку USB девайса, достаточно выпилить лишний функционал из дескриптора и обработчика команд.
Особенности конфигурации USB моста или DMA модуля я постарался подробно описать комментариями, но если у кого-то найдутся другие проблемы - можно обсудить в ветке ниже.

[dortonyan]

А если подать сигнал полной шкалы, искажения сильно растут?

На спектре и есть сигнал полной шкалы. Это ослабление на -20дБ по входу АЦП. И еще несколько дБ ослабление дает ЦАП (у pcm1792 в DSD режиме уровень сигнала ниже, чем в PCM).
По искажениям разницы не видно ни в симуляторе, ни в живую (глубина ООС на НЧ та же). Ну может шум на ВЧ на пару децибел выше, я точно не замерял.

eclipsevl, Владислав, естественно пытался использовать векторы по максимуму. Но проще пока что не придумал.
Первый аккумулятор и выходные квантованные значения надо иметь в 32 битах.

Ну, одна инструкция PRECEQ сейчас точно лишняя

Да, точно. Левое 16бит слово в выходном векторе можно сразу двигать вправо.
Главное что сам принцип (высокая линейность на малых разрядностях) работает и позволяет гарантированно реализовать вывод DSD128 без понижения порядка модулятора.
А дальше уже можно пробовать оптимизировать.

---------- Сообщение добавлено 19:16 ---------- Предыдущее сообщение было 18:14 ----------

Первый аккумулятор и выходные квантованные значения надо иметь в 32 битах.

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

P.S.
Попробовал, но так тоже экономится только одна инструкция. Что-то ничего лучше не придумывается.
Хотя, сэкономить и одну инструкцию для х128 модулятора - не мало. Это 128 инструкций на каждый входной семпл.

[eclipsevl]

Попробовал, но так тоже экономится только одна инструкция. Что-то ничего лучше не придумывается.
Хотя, сэкономить и одну инструкцию для х128 модулятора - не мало. Это 128 инструкций на каждый входной семпл.

Можно попробовать использовать для первого интегратора аккумулятор (ac0-4), тогда можно использовать векторные инструкции для "извлечения" из запакованного регистра t6. Но это опять же будет максимум 1-2 инструкции по моим прикидкам.

CMP.EQ.PH $t6, $t6, $zero
pick.ph $t6, 0x80008000, 0xffffffff # 0x0000 ? t6 = 0x8000 : 0xffff
maq_s.w.phl $ac0, $t6, 0xffff0000 # ac0 -> channel 1
maq_s.w.phr $ac1, $t6, 0x0000ffff # ac 1 -> channel 2

...

SHRL.PH $t6, $t6, 15 # -> t6 has two words with lsb*s, 0 - pos number, 1 - neg
SHLL.PH $s0, $s0, 1 # s0 has bits for 2 channels now, shith left
or $s0, $s0, $t6 # and OR with new bits

Но нужно каким-то образом подобрать константы для pick и maq чтобы получать нужные -1/+1, если вообще получится.

[dortonyan]

eclipsevl, Владислав, что-то очень хитрое вы придумали, я так и не понял как сюда пристроить аккумуляторы.

В общем после всех оптимизаций 5842 с дополнительным каскадом с х16 оверсеплингом + х128 соневский модулятор теперь обсчитываются даже на штатной 252МГц частоте.
Если разогнать мегагерц до 300, то можно еще и ЦФ использовать покруче, типа шапр-фильтра с ослаблением в 50дБ на частоте Найквиста (как сделано в моих проектах DF1 и DF3).

[eclipsevl]

eclipsevl, Владислав, что-то очень хитрое вы придумали, я так и не понял как сюда пристроить аккумуляторы.

Позже могу поковырять код. Я и сам не уверен что получится.

В общем после всех оптимизаций 5842 с дополнительным каскадом с х16 оверсеплингом + х128 соневский модулятор теперь обсчитываются даже на штатной 252МГц частоте.
Если разогнать мегагерц до 300, то можно еще и ЦФ использовать покруче, типа шапр-фильтра с ослаблением в 50дБ на частоте Найквиста (как сделано в моих проектах DF1 и DF3).

Попробовал сегодня ASRC с LUT и только целочисленной арифметикой - выходит 25.7 мкс/фрейм, 535нс (103 такта) на стерео семпл. 352.4->384кГц, т.е. худший по времени вариант.
Но 103 такта как-то многовато, пора переписывать на асме Хочется ближе к 50.

Переписал на асме, вышло 454нс/семпл или 88 тактов. Весь фрейм обсчитывается за 21.8мкс. Не очень большой выигрыш, к сожалению инструкции MADD занимают больше 1 такта. Загрузка одного слова из памяти тоже 3-4.
Prefetch помогает, но все равно долго

[dortonyan]

к сожалению инструкции MADD занимают больше 1 такта

Разве? В мануале писали что выполняется за один такт, это лэтенси два.
Поэтому основное время отнимают тупо загрузка данных и коэффициентов.

Загрузка одного слова из памяти тоже 3-4.
Prefetch помогает, но все равно долго

Можно попробовать сообразить fifo на регистрах и 4-х аккумуляторах,

как в моем последнем варианте

fir1_5842:
    .fir1_5842_beg:
    // load symmetric addresses & check addr overflow
    ADDU $t8, $a0, 0
    ADDU $t9, $a0, 576
    BLTU $t9, $a2, .fir1_5842_p1
    SUBU $t9, $t9, $a3
    .fir1_5842_p1:
    
    // load coef 1
    LI $v0, -12
    // load 8 data samples
    LW $t0, 0($t8)
    LW $t1, 8($t8)
    LW $t2, 16($t8)
    LW $t3, 24($t8)
    LW $t4, 88($t9)
    LW $t5, 96($t9)
    LW $t6, 104($t9)
    LW $t7, 112($t9)
    // multiply 4 samples to coef 1
    MULT $ac0, $t0, $v0
    MULT $ac1, $t1, $v0
    MULT $ac2, $t2, $v0
    MULT $ac3, $t3, $v0
    MADD $ac0, $t4, $v0
    MADD $ac1, $t5, $v0
    MADD $ac2, $t6, $v0
    MADD $ac3, $t7, $v0
    
    // load coef 2
    LI $v0, 26
    // load next samples
    LW $t0, 32($t8)
    LW $t7, 80($t9)
    // multiply 4 samples to coef 2
    MADD $ac0, $t1, $v0
    MADD $ac1, $t2, $v0
    MADD $ac2, $t3, $v0
    MADD $ac3, $t0, $v0
    MADD $ac0, $t7, $v0
    MADD $ac1, $t4, $v0
    MADD $ac2, $t5, $v0
    MADD $ac3, $t6, $v0
    
    // load coef 3
    LI $v0, -52
    // load next samples
    LW $t1, 40($t8)
    LW $t6, 72($t9)
    // multiply 4 samples to coef 3
    MADD $ac0, $t2, $v0
    MADD $ac1, $t3, $v0
    MADD $ac2, $t0, $v0
    MADD $ac3, $t1, $v0
    MADD $ac0, $t6, $v0
    MADD $ac1, $t7, $v0
    MADD $ac2, $t4, $v0
    MADD $ac3, $t5, $v0
   .......

[свернуть]

Тогда только вначале загружается 8 семплов в фифо, а потом на каждые 8 инструкций МАК-а догружается только один коэффициент и пара семплов данных. Получается очень высокая эффективность: инструкции MADD занимают больше 70% времени.
Правда адресация получается нетривиальная, как запихнуть такой алгоритм в универсальный цикл я с ходу не придумал.

P.S.
Хотя для asrc менять адреса коэф-тов в принципе не обязательно, можно вместо этого перезаписывать массив, из которого берутся коэффициенты.

[eclipsevl]

Да у меня и так сейчас загрузка семплов выполняется раз на 48 семплов, в регистрах держу всегда последние 8 на канал. Догружаю только по 1 семплу когда нужно. А коэффициенты каждый раз надо 8шт грузить.

---------- Сообщение добавлено 21:42 ---------- Предыдущее сообщение было 21:06 ----------

Вот так сейчас проход на 1 семпл выглядит:

ringbuf_offset_0:    
        lw     $t1, 0($a1)       # fl1 = samples_in[0]
	lw     $s1, 4($a1)       # fr1 = samples_in[1]
	
	lw     $at, 0($fp)
	mult   $ac0, $t0, $at   # acc_l = fl0 * h
	mult   $ac1, $s0, $at   # acc_r = fr0 * h

	lw     $at, 4($fp)
	madd   $ac0, $t7, $at
	madd   $ac1, $s7, $at

	lw     $at, 8($fp)
	madd   $ac0, $t6, $at
	madd   $ac1, $s6, $at

	lw     $at, 12($fp)
	madd   $ac0, $t5, $at
	madd   $ac1, $s5, $at

	lw     $at, 16($fp)
	madd   $ac0, $t4, $at
	madd   $ac1, $s4, $at

	lw     $at, 20($fp)
	madd   $ac0, $t3, $at
	madd   $ac1, $s3, $at

	lw     $at, 24($fp)
	madd   $ac0, $t2, $at
	madd   $ac1, $s2, $at

	lw     $at, 28($fp)
	madd   $ac0, $t1, $at
	j       end_switch
	madd   $ac1, $s1, $at

[dortonyan]

Так а чего не разбить обсчет на две процедуры, как я предлагал выше?
Можно же сначала рассчитать новую таблицу коэф-тов, а потом выполнить проход обычного FIR фильтра с обсчетом в 4 аккумулятора на каждый канал.
Причем в таком случае обсчет фильтра можно делать и константными адресами (как в моем примере). Оно конечно относительно трудоемко, но делается один раз.

[eclipsevl]

В отличии от обычного FIR, здесь на каждый семпл нужен свой набор коэффициентов. Поэтому считать сразу несколько семплов не выйдет.

[dortonyan]

Можно обсчитывать по 4 таблицы коэф-тов заранее. А потом использовать обсчет FIR фильтра по 4 семпла на канал (4-мя аккумуляторами), как здесь.
Перед каждой группой 8-ми умножений загружать придется по 4 коэф-та, но все равно за счет меньшего кол-ва загрузок данных так получается выгоднее.

[eclipsevl]

Семплы я загружаю всего один раз и держу в t0-t7 и s0-s7.
Подгружается только один семпл на проход фильтра.

Попозже скину код.

[dortonyan]

Залил новый проект dsp на гит.
Все лишнее повырезал, оставил только стерео-выход.
Настройки вывода задаются условной компиляцией через хедер "system.h", в поле "User defines".
При желании изменения параметров в риалтайме (разрядность округления, шейпер, дизер) можно дописать свои ф-ии. Я пока не добавлял.
Коэф-ты для фильтров использовал свои, но если надо - можно разкомментировать ф-ии фильтров 5842 (в проекте они тоже имеются).

P.S.
Проект сильно не тестировал. Возможно найдутся касяки.

[Михаил45]

Алексей спасибо!

[dortonyan]

Offтопик:
Не, рано выложил. Пока тестил dsd что-то поломал в pcm.

P.S.
Поправил.
В общем функционал получился навороченный, с кучей режимов как для PCM, так и для DSD вывода. Не исключено, что в каком-то из сочетаний режимов найдется касяк. По мере нахождения буду комитить исправления.

[EDDiE]

Offтопик:

Offтопик:
Не, рано выложил. Пока тестил dsd что-то поломал в pcm.

P.S.
Поправил.
В общем функционал получился навороченный, с кучей режимов как для PCM, так и для DSD вывода. Не исключено, что в каком-то из сочетаний режимов найдется касяк. По мере нахождения буду комитить исправления.

Большое СПАСИБО, Алексей !

[dortonyan]

Михаил45, EDDiE, нет за что, пользуйтесь.
Я правда еще некоторое время буду комитить исправления/доработки. Как залил проект, так сразу выяснилась куча нюансов по кастомной конфигурации.
Уже залил некоторые исправления. Так что, если неахота самому допиливать проект, то лучше подождать недельку, другую.
Или можно поучаствовать в тестировании нынешнего проекта. Кто найдет касяк - пишите.
В части фильтра-апсемплера он не уступает моим проектам на fpga. Модулятор в принципе тоже, разве что предельный апсемплинг не выше х128.

[Audiomaniac]

Сорри, что не по теме, но тут люди понимающие собрались, у кого ж еще спрашивать?
В каких-нибудь из популярных платок усб-транспортов, представленных на рынке (алиэкспресс и тд) реализован механизм/режим проверки на битперфект (то есть именно корректности передачи данных из контрольного файла в транспорт), или кроме энергетика с фламенко такое никто больше не делал?

[dortonyan]

Audiomaniac, вроде проверку можно сделать и на пике. Там есть флаг валидности CRC пакета, просто я не делал для него обработку.
Но не вижу смысла заморачиваться, т.к. ни разу не сталкивался с какими-то неочевидными артефактами. Никаких сущностей там нету, тупо перекачка байтов.
Если начнутся регулярные сбои, то это сразу станет слышно как заикания или потрескивания, потому что испортится не один семпл, а сразу целый пакет (минимум 5..6 семплов). Не говоря уже про то, что это будет хорошо видно на спектральном анализе.
Поэтому если в спектраплюсе ничего не видно, то дальше искать пропуски битов - сизифов труд.
Но если принципиально надо чтоб вот прям точно без потерь, то лучше смотреть в сторону аманер. Там передача осуществляется проприетарным драйвером с балк-трансфером, который исключает потери.
Хотя у меня на длинном кабеле на транспорте энергетика все равно бывают сбои (заикания), не спасает даже балк. Похоже что 100%-ю гарантию может дать только страховой полюс.

P.S.
А чисто из практических соображений мне транспорт на пике нравится гораздо больше аманеры: меньше жрет тока, не отваливается после выхода компа из сна и не виснет при пропадании тактирования.
Не говоря уже про то, что его можно исполнить в более удобном и компактном виде на своей плате.
Ну и не говоря про то, что он еще вытягивает и аудио ЦОС при суммарном потреблении меньше, чем у аманеры.

[Audiomaniac]

Меня интересует не столько правильность передачи по усб (это действительно скорее всего будет слышно как щелчки/помехи), сколько возможная вредная обработка данных в софте на том девайсе, к которому цап подключается, в источнике аудиоданных, чтобы у юзера была возможность это выяснить без приборов. Вот, например, у MSB это реализовано и лежат на сайте специальные тестовые файлы различной разрядности и частоты дискретизации. Если они воспроизводятся верно, то цап их опознает и тихо пишет на дисплее, что все ок, а вот если нет - то юзер слышит содержимое файла, шипение и свист, которые означают, что аудиоданные были кем-то искажены по дороге от файла до цапа. Вот такое бы хотелось конечно иметь, чтобы не ломать голову "а почему не так играет?!"

[dortonyan]

Для проверки обработки в системном драйвере есть простой как репа (ну почти ) способ, если есть ЦАП с приемом DoP формата: берете и выводите DSD битсрим, упакованный в DoP через PCM формат.
Если есть хоть какая-то обработка, то вместо звука будет шум и не пойми что.
У меня на пике DoP работает нормально. Думаю и на любом другом транспорте через асио/васапи будет то же самое.

[Turbo_man]

Можно взять HDCD файл и прогнать через тракт. При отсутствии битперфекта индикатор этого режима не будет светиться.