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]

Сам по себе цифровой РГ без потери качества давно не проблема. Он вроде и в виндовсе беспотерьный.
Просто не все ЦАП корректно отрабатывают понижение уровня сигнала по входу. И не во всех схемах ЦАП обеспечена должная фильтрация по выходу.

[antecom]

Если ЦАП принимает 32 разряда (современные дельтасигмы), то при регулировке в цифре ему не нужен даже дизеринг, достаточно просто умножить семплы на коэффициент и выдать на ЦАП старшие 32 бита результата. Поправьте, если я ошибаюсь.

[dortonyan]

Как бы да.
Но физически шина данных в ЦАП может быть меньше заявленных 32-х бит. Т.е. цап может младшие биты просто отбросить без округления.
Поэтому в РГ результат умножения лучше округлять в 24 бита с дизером (или даже в 20..22). Арифметика в любом случае плевая: перед отбрасыванием младших бит плюсуется шум и 0.5LSB.

[Adson]

Может, лучше для регулировки громкости реализовать HID либо Hardware Mixer какой, чтоб выставленную громкость по I2C отдавал на внешний РГ?
Можно будет рулить усилителем, не ослабляя сигнал в цапе

Коллеги, не могли бы навести на какие-нибудь материалы почитать как сделать такое поведение транспорта, чтобы при изменении громкости передавал его значение? Тоже хочется РГ с хоста рулить.

[eclipsevl]

Может, лучше для регулировки громкости реализовать HID либо Hardware Mixer какой, чтоб выставленную громкость по I2C отдавал на внешний РГ?
Можно будет рулить усилителем, не ослабляя сигнал в цапе

Делал такое, ради эксперимента:
https://www.youtube.com/shorts/j6Ed8rS8Sl0

В дескриптор добавляется Feature Unit регулятора громкости

AC Feature Unit Descriptor:
------------------------------
0x12	bLength
0x24	bDescriptorType
0x06	bDescriptorSubtype
0x0B	bUnitID
0x02	bSourceID
0x0000000F	bmaControls(0)
          Mute Control              - host programmable
          Volume Control            - host programmable
0x0000000F	bmaControls(1)
          Mute Control              - host programmable
          Volume Control            - host programmable
0x0000000F	bmaControls(2)
          Mute Control              - host programmable
          Volume Control            - host programmable
0x00	iFeature

И по unit ID обрабатываются setup пакеты с громкостью/мьютом

[dortonyan]

eclipsevl, а при задании такого режима виндовский микшер байпасится или нет?
Если нет, то такой РГ будет работать только при выводе через васапи.

Разобрался с доступными DSP инструкциями в MIPS32, оптимизировал код. Теперь пик успевает обсчитать 5842 фильтр, с дополнительным х2 half-band апсемплером (т.е. суммарно х16 оверсемплинг) даже на 200МГЦ системной частоте.
А при разгоне системной частоты до 300МГц и выше можно первую ступень фильтра сделать даже более навороченной, с ослаблением 30..50дБ на частоте Найквиста.

[Turbo_man]

Поздравляю. А будет поканальный выход для старых параллельников с выбором их битности (16, 18, 20, 24)?

[dortonyan]

А будет поканальный выход для старых параллельников с выбором их битности?

Конечно. Я сейчас так и вывожу: параллельными потоками данных на PCM1792 в режиме с внешним ЦФ.
Разрядность округления можно будет выбрать произвольно, длину фрейма - 16 или 32 бита. Форму вордклока и сигнала DG можно будет задавать произвольно с дискретностью в бит данных.
Правда потребление пика получается уже немалое, около 150мА с разгоном по частоте.

---------- Сообщение добавлено 11:02 ---------- Предыдущее сообщение было 10:59 ----------

Единственное, что нельзя сделать как на FPGA - это прерывание бит-клока.
Но учитывая, что этот сигнал не коррелирует с сигналом, то в принципе и пофиг.

[eclipsevl]

eclipsevl, а при задании такого режима виндовский микшер байпасится или нет?
Если нет, то такой РГ будет работать только при выводе через васапи.

Да, все работает именно из винды на видео.

Разобрался с доступными DSP инструкциями в MIPS32, оптимизировал код. Теперь пик успевает обсчитать 5842 фильтр, с дополнительным х2 half-band апсемплером (т.е. суммарно х16 оверсемплинг) даже на 200МГЦ системной частоте.
А при разгоне системной частоты до 300МГц и выше можно первую ступень фильтра сделать даже более навороченной, с ослаблением 30..50дБ на частоте Найквиста.

Ох круто, у меня это еще только в планах
Писали сами все или использовали DSP библиотеку к pic32mz?

Единственное, что нельзя сделать как на FPGA - это прерывание бит-клока.

Можно, я делал:


Помните, есть еще SPI блоки

[dortonyan]

Да, все работает именно из винды на видео.

Отлично, получается можно еще и РГ транспортом рулить.

Писали сами все или использовали DSP библиотеку к pic32mz?

Сам пишу на ассемблере. Опубликую как будет более-менее завершенный вариант.
Если интересно, в мануале "MD00374-2B-MIPS32DSP-AFP-03.01" описаны доступные в пике MIPS32 инструкции.
У меня фильтры работают без счетчиков, с дублированием операций на каждом проходе. И с коэффициентами, задаваемыми константами прямо в регистры процессора.
А стандартные функции для универсальности используют чтение коэф-тов через указатель и работают со счетчиком циклов. Я их не пробовал, но скорее всего они будут медленнее.

Помните, есть еще SPI блоки

Это я в курсе, но не разобрался как синхронизировать.
Используете синхронный режим SPI? Фреймы точно выходят синхронно?
Ну и для произвольной разрядности (18, 20, 24 бит) такой фрейм сделать все равно не получится.

[eclipsevl]

Это я в курсе, но не разобрался как синхронизировать.
Используете синхронный режим SPI? Фреймы точно выходят синхронно?

Да, это возможно. Я сейчас точно не скажу последовательность действий, но по-моему достаточно включить SPI и запустить рефклок после этого.
Я думал Вы уже это используете для вывода параллельных потоков.

На картинке я делал вывод для TDA1541 в simultaneous mode. 1 канал - latch, два для данных и еще один для формирования клока.

Пара вещей которые я пытаюсь реализовать в York:
1. Поиздеваться над периферией МК для поддержки двух независимых клоковых доменов для I2S входа и выхода. К сожалению пока не вышло, идея в каскадном применении refclk3, 4 для формирования BCK/WCK. Каким-то образом это подвешивает МК.
2. Вывод/ввод TDM с помощью одного SPI блока. Сейчас для вывода я использую 2, но это относительно легко решается. А вот для ввода я пока не разобрался.
Если SPI работает в режиме приема, он не формирует SS. Получается, нужно одновременно передавать и принимать данные. Слать, например, 0x00000000 через один DMA канал и другим выгружать данные с SPI. Вы пробовали такое делать с PIC32?

[dortonyan]

1. Поиздеваться над периферией МК для поддержки двух независимых клоковых доменов для I2S входа и выхода. К сожалению пока не вышло, идея в каскадном применении refclk3, 4 для формирования BCK/WCK. Каким-то образом это подвешивает МК.

В пике все SPI модули физически затактированы от общего клока, поэтому использовать их в мастере в разных доменах не получится.
Но это не является проблемой, если для входа I2S используется режим слейва. У меня вход так и сделан, и частоту для АЦП можно задавать отдельно.
Единственное, что тогда на плате должна быть соответствующая схема, которая будет независимо раздавать клоки с пары генераторов на ЦАП и АЦП.

Если SPI работает в режиме приема, он не формирует SS.

Странно. По идее в мастере SS должен работать в любом случае.
С TDM не работал и вообще не вникал, поэтому ничего не подскажу.

Получается, нужно одновременно передавать и принимать данные. Слать, например, 0x00000000 через один DMA канал и другим выгружать данные с SPI. Вы пробовали такое делать с PIC32?

Такое не пробовал.

[eclipsevl]

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

Это так, и очень большой недостаток пика. Возможно с иллюстрацией будет понятнее что я имею ввиду:



Сами клоки сформировать у меня получилось, но как только вывожу на те же пины (либо разные, но соединенные) что и I2S - ядро виснет Будет время еще поковыряюсь.

[Вергилий]

Конечно. Я сейчас так и вывожу: параллельными потоками данных на PCM1792 в режиме с внешним ЦФ.
Разрядность округления можно будет выбрать произвольно, длину фрейма - 16 или 32 бита. Форму вордклока и сигнала DG можно будет задавать произвольно с дискретностью в бит данных.
Правда потребление пика получается уже немалое, около 150мА с разгоном по частоте.

---------- Сообщение добавлено 11:02 ---------- Предыдущее сообщение было 10:59 ----------

Единственное, что нельзя сделать как на FPGA - это прерывание бит-клока.
Но учитывая, что этот сигнал не коррелирует с сигналом, то в принципе и пофиг.

Круто! Надеюсь хедер под DAC11001 тоже будет из коробки

[dortonyan]

Это так, и очень большой недостаток пика. Возможно с иллюстрацией будет понятнее что я имею ввиду:



Сами клоки сформировать у меня получилось, но как только вывожу на те же пины (либо разные, но соединенные) что и I2S - ядро виснет Будет время еще поковыряюсь.

А зачем вообще такое извращение? Для входа в слейве опорный клок I2S модулю вообще не нужен (его генерирует источник данных), данные можно подавать на любой частоте.
Или имеется ввиду два I2S выхода в разных доменах?

[eclipsevl]

Вход и выход в разных доменах, в мастер режиме.

[dortonyan]

Надеюсь хедер под DAC11001 тоже будет из коробки

Посмотрим.
Я вообще планировал сделать максимально просто, под типовые аудио-ЦАПики. А для 11001 можно уже и плисину отжалеть.

---------- Сообщение добавлено 13:52 ---------- Предыдущее сообщение было 13:51 ----------

Вход и выход в разных доменах, в мастер режиме.

Так сделайте для входа слейв режим и нет проблемы.
Для входа слейв в любом случае предпочтительнее, т.к. не чувствителен к задержкам на цифровой развязке.

[Turbo_man]

dortonyan, а разве PCM1792A может принимать поток 16фс от внешнего цф?

[dortonyan]

Я для этого ЦАП формирую поток с 32-мя битами на фрейм. 16 еще не пробовал.
Но если для 1792 выбрать входную разрядность 16 бит, то думаю что и 16-битный фрейм сожрет. При выдаче с плисины 1792 работал даже с прерывистым бит-клоком данных.

[Turbo_man]

Понял. Наверно 16-битный фрейм для TDA1541 как раз может сгодиться, только отключить COB нужно будет.

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

Можно будет попробовать сделать вывод для SM5865CM вместо SM5847AF.
А то валяется Lynx D47 без дела.

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

Offтопик:
dortonyan и eclipsevl, а может вам сделать такой совместимый транспорт? Уж очень не хочется самому плату делать.