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 пакеты с громкостью/мьютом