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 модуля я постарался подробно описать комментариями, но если у кого-то найдутся другие проблемы - можно обсудить в ветке ниже.

[Audiomaniac]

Ну вот если бы кто-то сделал транспорт, в котором был бы реализован механизм проверки целостности данных во всех форматах, как я описал для MSB - было бы реально круто. Сразу понятен УРОВЕНЬ изделия. Причем, это не особо-то и сложно, алгоритмически достаточно тривиальная вещь, я подобные штуки на ассемблере писал еще в 1990е под мс-дос, когда делал граббер CDDA с контролем правильности считывания. Это уж точно проще, чем выдрачивать аналоговую часть цапа.

[hippo64]

Ну вот если бы кто-то сделал

К счастью среди разраработчиков очень мало идиотов аудиофилитиков.

[Alex]

Меня интересует не столько правильность передачи по усб (это действительно скорее всего будет слышно как щелчки/помехи),

Щелчки/помехи - это уже совсем крайний случай.
Бывает что в спектроаанализаторе весь график периодически прыгает на 30-50дБ вверх. На слух это заметно на синусе, но далеко не на всякой музыке.

Если они воспроизводятся верно, то цап их опознает и тихо пишет на дисплее, что все ок,

Я такое делал в полном JKill, не для USB конечно.

---------- Сообщение добавлено 09:38 ---------- Предыдущее сообщение было 09:37 ----------

Ну вот если бы кто-то сделал транспорт, в котором был бы реализован механизм проверки целостности данных во всех форматах, ... Это уж точно проще, чем выдрачивать аналоговую часть цапа.

Проще, только в отличие от аналоговой части - нахрен никому ненужно.

[Audiomaniac]

Щелчки/помехи - это уже совсем крайний случай.
Бывает что в спектроаанализаторе весь график периодически прыгает на 30-50дБ вверх. На слух это заметно на синусе, но далеко не на всякой музыке.

Бывает! И такое тоже можно отловить тем методом, который я описал.

Проще, только в отличие от аналоговой части - нахрен никому ненужно.

Ну как не нужно-то, нужно! Надо чтобы была возможность у юзера без приборов проконтролировать правильность воспроизведения путем простых и понятных действий, а не конопатить тебе мозги "пачиму цап не так играет, хотя вчера с другим компом играл так?!"
Энергетик делал функцию проверки битперфекта во фламенко, а вот в новых девайсах на аманеро уже не делал, а зря!

[Alex]

Энергетик делал функцию проверки битперфекта во фламенко, а вот в новых девайсах на аманеро уже не делал, а зря!

По причине, описанной выше

P.S. Я в своих тоже мог бы сделать, но - та-же причина

[Audiomaniac]

Вот из-за такого подхода и процветает всякая шизотерия, которой народ занимается, вроде "подбора версии линукса по звуку"

[Alex]

Так а толку с того? Ну проверишь отсутствие ошибок, так удифилы найдут еще писсот причин.
(и кстати,отчасти будут правы).

P.S. Я делал проверку ошибок, но несколько более жестокими методами и не для оперативых проверок а в плане экспериментов - делал на I2S обратную петлю (loop back), затем посылал и принимал, и сравнивал посланное и принятое.

[Audiomaniac]

Так а толку с того? Ну проверишь отсутствие ошибок, так удифилы найдут еще писсот причин.

Ну это все просто отговорки, ты и сам это понимаешь

[antecom]

Если вывод через Wasapi или ASIO, то нужно постараться что бы нормальный транспорт (XMOS, Аманеро, сабжевый на PIC32MZ) выдавал не битпёфект.
Но если прикрутить проверку не сложно, почему бы и нет. Например набор специально сгенерированных WAV файлов с разной частотой дискретизации в которых идет последовательность нулей для синхронизации и далее короткий закольцованный набор данных для сравнения с таким же в памяти транспорта.

[dortonyan]

Ну вот если бы кто-то сделал транспорт, в котором был бы реализован механизм проверки целостности данных во всех форматах, как я описал для MSB - было бы реально круто. Сразу понятен УРОВЕНЬ изделия. Причем, это не особо-то и сложно, алгоритмически достаточно тривиальная вещь, я подобные штуки на ассемблере писал еще в 1990е под мс-дос, когда делал граббер CDDA с контролем правильности считывания. Это уж точно проще, чем выдрачивать аналоговую часть цапа.

Так это вопрос драйвера, а не транспорта. В транспорте никакой обработки точно нету.
Если я на своем транспорте уже запустил вывод DoP через васапи драйвер и убедился, что все битперфектно, то зачем еще делать какую-то проверку? В чем смысл?
MSB - понятно, им продавать надо побольше и подороже. Вы когда покупаете USB-флешку, тоже тестируете - портятся ли на ней данные при копировании?
Интересно - почему для аудиофильских флешек никто не сделал проверку?

[stratov]

Ну это все просто отговорки, ты и сам это понимаешь

Аудиоманьяк, скажите а а ваши взгляды по поводу параллельных цап относительно дельтасигм поменялись? Что на сегодняшний день для вас в топе? Вы человек явно компетентный в этом вопросе, как и многие тут, очень интересно ваше мнение и т д. Спасибо. Или тут или в личку, если можно.

[Audiomaniac]

Если вывод через Wasapi или ASIO, то нужно постараться что бы нормальный транспорт (XMOS, Аманеро, сабжевый на PIC32MZ) выдавал не битпёфект.
Но если прикрутить проверку не сложно, почему бы и нет. Например набор специально сгенерированных WAV файлов с разной частотой дискретизации в которых идет последовательность нулей для синхронизации и далее короткий закольцованный набор данных для сравнения с таким же в памяти транспорта.

Файлы MSB сделаны так: голосовое объявление частоты дискретизации/разрядности - пачка тестовых данных - голосовое объявление "посмотрите на дисплей".
Можно прямо эти файлы и использовать, чтобы не изобретать велосипед.

https://msbtechnology.com/wp-content...erfectTest.wav

Так это вопрос драйвера, а не транспорта. В транспорте никакой обработки точно нету.
Если я на своем транспорте уже запустил вывод DoP через васапи драйвер и убедился, что все битперфектно, то зачем еще делать какую-то проверку? В чем смысл?
MSB - понятно, им продавать надо побольше и подороже. Вы когда покупаете USB-флешку, тоже тестируете - портятся ли на ней данные при копировании?
Интересно - почему для аудиофильских флешек никто не сделал проверку?

Да мне-то это все понятно, я-то сам смогу что угодно проверить.
Конечно, если девайсы делаются чисто для себя, то проблемы вообще никакой.
Я пишу о том, чтобы сделать возможность такой проверки для юзера, не отягощенного какими-либо знаниями.

[dortonyan]

Да мне-то это все понятно, я-то сам смогу что угодно проверить.
Конечно, если девайсы делаются чисто для себя, то проблемы вообще никакой.
Я пишу о том, чтобы сделать возможность такой проверки для юзера, не отягощенного какими-либо знаниями.

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

Файлы MSB сделаны так: голосовое объявление частоты дискретизации/разрядности - пачка тестовых данных - голосовое объявление "посмотрите на дисплей".
Можно прямо эти файлы и использовать, чтобы не изобретать велосипед.

Баловство.
Асио или васапи драйвер заведомо гарантирует битперфектность. Все, кто пользуются воспроизведением DSD не дадут соврать.
Кстати, спонтанный сбой передачи данных, из-за загрузки процессора или малого буферирования потока, такая проверка не покажет. Чисто маркетинговая примочка.

[Audiomaniac]

Аудиоманьяк, скажите а а ваши взгляды по поводу параллельных цап относительно дельтасигм поменялись? Что на сегодняшний день для вас в топе? Вы человек явно компетентный в этом вопросе, как и многие тут, очень интересно ваше мнение и т д. Спасибо. Или тут или в личку, если можно.

Я считаю, что основное значение для звука имеет даже не сама микросхема цап, а то, как сделано все вокруг нее.
Есть хорошо звучащие цапы на R-2R и есть на дельтасигмах и есть отвратительно звучащие и на том и на другом.
R-2R параллельники обладают рядом свойств, которых нет и никогда не будет у дельтасигмы.
Собственно, поэтому их до сих пор и производят и даже разрабатывают новые (DAC11001)

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

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

Да не транспорт, а комп, юзерский комп, в котором стоят бог знает какие драйвера, какая ос, какой плеер и как все это еще (криво) настроено пытливым аудиофильским юзверем - вот в чем главная опасность!
А ту проблему со сдвигом каналов во фламенко (это было не в болеро), таким образом, кстати и не отловить, это был косяк в прошивке самого транспорта.

[antecom]

Можно прямо эти файлы и использовать, чтобы не изобретать велосипед.

Длительность проверочного фрагмента примерно 0.35 секунды. Данные в каналах разные. Для 16/44.1 чуть больше 60кБайт. Не влезет в 512кБайт PIC-а полный набор для всех ЧД и разрядностей.

Для быстрой проверки битпёфекта сделал в редакторе .wav файлы в которых данные представляют чередующуюся последовательность нулей и единиц. На осцилле это выглядит как меандр. При проверке достаточно коснуться щупом шины данных в режиме однократной развертки.

[Meta|_]

Я если сомневаюсь в целостности передачи вывожу сигнал 0.5fs полной амплитуды. Если тишина, значит всё ок, а практически любой сбой даст щелчок (ну ок, если только младший бит перещёлкнется, то нет).
Неявную обработку в ОС это не выявит, но мне это не нужно.

Offтопик:

Вы когда покупаете USB-флешку, тоже тестируете - портятся ли на ней данные при копировании?

Я недавно протестил пару флешек с Али. Выкинул. Думал такую фигню они уже научились производить массово и дёшево, оказалось нет.

[Михаил45]

Слушайте, рассуждать о каких то битах и перфектах , флешках, потерях данных, юзерах с древними гробами на столах с хр, фламенко и болеро в 2025 году - смешно и не более. Ерунда все это уже лет 15 как устарело.

[Audiomaniac]

Длительность проверочного фрагмента примерно 0.35 секунды. Данные в каналах разные. Для 16/44.1 чуть больше 60кБайт. Не влезет в 512кБайт PIC-а полный набор для всех ЧД и разрядностей.

А и не обязательно хранить прямо целиком тестовые последовательности. Можно хранить их контрольные суммы

Михаил45,

[dortonyan]

рассуждать о каких то битах и перфектах , флешках, потерях данных, юзерах с древними гробами на столах с хр, фламенко и болеро в 2025 году - смешно и не более. Ерунда все это уже лет 15 как устарело.

Вот именно.
Транспорты с выводом DSD доступны и без проблем используются уже лет 10.
При том, что DSD без бит-перфекта невозможно слушать в принципе.

А и не обязательно хранить прямо целиком тестовые последовательности. Можно хранить их контрольные суммы

Вот и займитесь. Проект на пике опес-сорс, все доступно, если очень надо.