USB аудио транспорт York Pico

[eclipsevl]

Для моих проектов мне требовался USB транспорт для вывода звука и еще один канал для управления устройством. Например, для управления DSP.

В прошлый раз я решил эту задачу с использованием USB хаба и USB to Serial конвертера. Таким образом, из 3 чипов собирался нужный мне интерфейс:
https://forum.vegalab.ru/showthread.php?t=87081

Попытка объединить все в одном чипе была с проектом от maxssau на XMOS. Тоже рабочее решение, но большая проблема с доступностью чипов, особенно в нужном корпусе.

Таким образом вариант развития транспорта на pic32mz показался мне самым логичным. Первый прототип модуля был основан на проекте Алексея: по схемотехнике он практически полностью повторял оригинальный проект и был рассчитан на вывод двухканального аудио, плюс последовательный интерфейс. В процессе тестирования прошивки на основе оригинального исходного кода было выявлено несколько проблем при работе в разных ОС. Также не был до конца реализован последовательный порт.
Свою версию прошивки с исправлениями я выкладывал в оригинальной теме и на гитхаб: https://github.com/eclipsevl/york_pic32mz_uac2_osfw/

https://forum.vegalab.ru/showthread....=1#post3173229

После этого продолжил работу над нужными мне функциями. И понеслось Были реализованы:
1. Бутлоадер. Необходим для обновления прошивки по USB, без программатора.
2. Гибкая конфигурация устройства с помощью утилиты для ПК (она же используется для обновления прошивки)
3. HID интерфейс для передачи служебной информации и конфигурации устройства. Изначально я планировал использовать последовательный порт, но HID подходит куда лучше.
4. Последовательный интефейс, может быть включен опционально.
5. Различные дополнительные варианты вывода аудио: s/pdif, 8 канальный tdm, двойной i2s (для использования некоторых ЦАП поканально в моно режиме)
6. Различные варианты тактирования: генераторы модуля, внешний клок (слейв режим), тактирование от внутренней PLL.
7. I2C порт и библиотека для интеграции с SigmaStudio: для одновременного ввода/вывода аудио и программирования DSP ADAU.

Последнее на данный момент является уникальной комбинацией и удачно вписывается в проекты DSP: https://www.diyaudio.com/community/t...6#post-7522832

Утилита для конфигурации и обновлентя прошивки выглядит так:

Настройка имени устройства и PID/VID

Аудио интерфейс:

Возможности на данный момент:
1. Ввод до 2 каналов PCM, до 192кГц (384кГц при внешнем тактировании 1024fs)
2. Вывод 2 каналов PCM, до 192кГц
(384кГц при внешнем тактировании)
3. Вывод 8 каналов в режиме TDM8 (до 96кГц, при тактировании от PLL)
4. Вывод 2 каналов S/PDIF, до 192кГц при тактировании от PLL


Ну и конечно в самом простом варианте этот модуль может работать аналогично Аманеро, в слейв или мастер режиме.
DSD еще не тестировал.

Фото модуля, вторая версия.

Дополнительный 4 пиновый разъем может быть конфигурирован как i2c/uart/gpio, также используется для принудительного входа в бутлоадер (в случае неудачного обновления ПО).

Доступен в двух вариантах: USB-C и USB-B. Сам транспорт довольно компактен: уместится на площади около 2х2 см - некоторым важно для интеграции в другие устройства.

Сейчас партия едет с производства в РФ, как будут готовы - повешу объявление в толкучке. Ну и документацию тоже нужно написать

Эту тему создаю для обсуждения/обратной связи.

P.S. выражаю огромную благодарность:
1. Алексею Dortonyan за публикацию проекта. Его работа легла в основу и без нее этот проект никогда бы не состоялся
2. Всем бета-тестерам первой версии

[eclipsevl]

Прошу прощения, пропустил сообщения в теме.

eclipsevl, Можно ли взять готовый модуль на тест с возвратом?

Да, можно. Напишите адрес в личку.

Есть вариант вывода 8 каналов в i2s ? И цену в личку, если можно.

Да, есть. Сегодня будет тема в толкучке.

Но обещали допилить.

Уже начал, возможно в следующем релизе прошивки.

А с большим количеством каналов не планируется?

Пока в планах нет. Но в i2s больше 8 точно не выйдет

[antecom]

Уже начал, возможно в следующем релизе прошивки.

Спасибо. Ждем.
Ещё хорошо бы добавить выдачу по UART частоты дискретизации. Достаточно одного байта как в этой версии:
https://forum.vegalab.ru/showthread....=1#post3220552
Просто передается одно число при каждом изменении состояния Play/Stop:
1 - 44.1к
2 - 48к
3 - 88.2к
4 - 96к
и т.д.
Сюда же можно добавить и DSD форматы.
У некоторых ЦАП нет автомата выбора частоты дискретизации и нужно переконфигурировать регистр(ы) самостоятельно. Оказалось очень удобно принимать ЧД через UART, т.к. достаточно одного отпрона для развязки от транспорта. И по этим же данным можно переключать генераторы.

Пока в планах нет. Но в i2s больше 8 точно не выйдет

У PIC32MZ в 100-ногом корпусе шесть I2S модулей, что позволяет сделать 12-ть каналов. Понятно что это спрос на такой транспорт будет мал (хотя мне тоже нужен).

[eclipsevl]

Ещё хорошо бы добавить выдачу по UART частоты дискретизации.

Пока что мой план - добавить это в регистровый файл, доступ к которому можно получить по I2C. Т.е. можно будет читать текущую частоту дискретизации с другого МК.
Принципиально арт тоже можно, но вариант с I2C более универсален, плюс можно еще что-то интересное выдавать на чтение.

У PIC32MZ в 100-ногом корпусе шесть I2S модулей, что позволяет сделать 12-ть каналов. Понятно что это спрос на такой транспорт будет мал (хотя мне тоже нужен).

Да, это так. Но обычно спрашивают про 16 каналов

А схему nano глянуть можно?

В первом посте в толкучке

Тема в толкучке создана:
https://forum.vegalab.ru/showthread....7697&p=3344066

[Alex]

Пока что мой план - добавить это в регистровый файл, доступ к которому можно получить по I2C. Т.е. можно будет читать текущую частоту дискретизации с другого МК.

Если есть "другой МК", то зачем ему ее выдавать? Он ее и сам померять может, если конечно не совсем примитив стоит.

[antecom]

Пока что мой план - добавить это в регистровый файл, доступ к которому можно получить по I2C. Т.е. можно будет читать текущую частоту дискретизации с другого МК.
Принципиально арт тоже можно, но вариант с I2C более универсален, плюс можно еще что-то интересное выдавать на чтение.

Это хуже, чем выдача по UART при Play/Stop.
1. Гальванразвязка сложнее.
2. Не понятно в какой момент внешний МК должен прочесть эти регистры. Если по изменению сигнала Mute (предположу что Mute активируется в Stop), то это уже третья гальванразвязанная линия управления.
3. Выдавать что то ещё можно по тому же UART даже одним байтом. Для передачи всех мыслимых частот дискретизации PCM и битрейта DSD достаточно 5 бит. Остается 3 бита для остального.

Если есть "другой МК", то зачем ему ее выдавать? Он ее и сам померять может, если конечно не совсем примитив стоит.

Это не просто, если МК почти всегда в слипе. Ну либо будить дополнительным сигналом - лишнее усложнение.

[eclipsevl]

Если есть "другой МК", то зачем ему ее выдавать? Он ее и сам померять может, если конечно не совсем примитив стоит.

Так ведь и UART принимать - тоже МК надо

[Alex]

Так ведь и UART принимать - тоже МК надо

Ну да.
Собственно, если есть второй проц, он может сам и семплрейт померять, и РСМ/ДСД определить. Вопрос только в его слипе.
(хотя как по мне - это блаж, современные малопотребляющие процы, PIC16,STM32L1/4, etc., фактически ничего в воздухне излучают и при правильно схемотехнике и разводке, помех по питаниюне создают). Так что слип полезен в девайсах типа регуляторов антекома, питающихся от батарейки-пуговицы, для меньшния потрбления.
Смысл может быть в передаче не UART/I2C/SPI а просто битами -тогда можно хоть индикацию сделать без проца.
В моих первых USB-интерфейсах (xVeloci) были на выходе после изоляции, биты семплрейта и РСМ/ДСД, и была отдельная плата для индикации светодиодвами. Но в ЦАПах типа 10, 10S биты семплрейта не использовались.

ИМХО тут нужно начинать с того, как эти сигналы будут использоваться - индикация, перенастройка ЦАПа, ?
По минимуму, можно вообще никуда ничего не передавать, а тем-же процом что в USB делать и индикацию и перенастраивать ЦАП. Т.е. второй проц тут не нужен.

Я ставлю отдельный проц только потому, что гальванически развязанный USB-интерфейс у меня сам записан он USB, и если туда не подано 5в, то не будут работать ни индикация, ни управление, ни остальные входы.
Но там где вообще все питается от USB, или от одного источникаи(ATDAC-8*), там проц USB индикацию и перестройку ЦАПа делает сам, через развязку.

[antecom]

ИМХО тут нужно начинать с того, как эти сигналы будут использоваться - индикация, перенастройка ЦАПа, ?

Именно так (индикация и/или перенастройка) и будут использоваться большинством.
Для индикации без отдельного проца они, как я понял, уже выводятся на f0-f3 пины транспорта (при обычном двухканальном стерео).
При использовании отдельного проца, принимать от транспорта всю служебную информацию через UART - самый логичный и простой вариант.
Ну а требовать от универсального транспорта конфигурирования всех микросхем ЦАП - малореальная задача. Конфигурировать одним МК можно если софт для транспорта и ЦАП пишет один человек, как в твоем случае.

[Alex]

Для индикации без отдельного проца они, как я понял, уже выводятся на f0-f3 пины транспорта (при обычном двухканальном стерео).

Да у меня так и было сделано, только простая 74-я логика (дешифратор плюс несколько XOR-ов, если мне память не изменяет).

При использовании отдельного проца, принимать от транспорта всю служебную информацию через UART - самый логичный и простой вариант.

Если этот проц в слипе и просыпается по UART-у.
Иначе он сам все сделает, от транспорта желательно мьют, и рсм/дсд (хотя можно и без него).

[Turbo_man]

А как же сигнал переключения сеток х44/х48? Если клоки в цапе, то никак без него. Я про юсб подключение.

[Alex]

А как же сигнал переключения сеток х44/х48? Если клоки в цапе, то никак без него.

Я об этом сигнале не упоминал, т.к. это очевидно, если клоки в ЦАПе.

[antecom]

А как же сигнал переключения сеток х44/х48? Если клоки в цапе, то никак без него. Я про юсб подключение.

По UART принимаем ЧД и переключаем клоки. Нечётное значение - сетка 44.1, четное 48.
У меня так и сделано, работает нормально.

[Turbo_man]

Про UART всё понятно. Хочется использовать лишь 1 опто-пару вместо N.

---------- Сообщение добавлено 17:23 ---------- Предыдущее сообщение было 17:03 ----------

Мне достаточно 2-х управляющих сигналов от юсб (сетка и dsd/pcm). Остальное легко считается в МК, или в CPLD/FPGA.

[antecom]

Про UART всё понятно. Хочется использовать лишь 1 опто-пару вместо N.

Именно. UART это и есть одна линия, один оптрон. Поэтому и агитирую за него.
Один байт по UART как раз и позволяет переключать сетки, знать ЧД, режим PCM/DSD и выводить МК из слипа. При этом в любом МК есть аппаратный приемник UART, т.е. и программировать по сути ничего не нужно.
Более того UART уже реализована в прошивке Алексея. Достаточно вставить этот функционал в York.

[Alex]

Мне достаточно 2-х управляющих сигналов от юсб (сетка и dsd/pcm). Остальное легко считается в МК, или в CPLD/FPGA

Семплрейт тоже? А чего тогда и dsd/pc тоже?

[dortonyan]

UART это и есть одна линия, один оптрон. Поэтому и агитирую за него.

Тоже голосую за такой вариант.
Причем для универсальности можно сделать выбор назначения выхода: 0 - GPIO выбора сетки 44/48, 1 - Uart TX. Каждый выберет что ему удобнее, и всего один сигнал.
Можно еще добавить Uart вход: кому не нужен - не использует, кому надо - добавляет еще один оптрон и получает дуплексный режим передачи данных.

Более того UART уже реализована в прошивке Алексея.

Да там кода три строчки. Здесь больше вопрос концепции построения интерфейса.

[Turbo_man]

А чего тогда и dsd/pc тоже?

Не пробовал, как-то ленился придумывать.
Сейчас увидел у Алексея, что он тоже в DF3E сделал автоопределитель.

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

Словами напиши свой алгоритм.

[eclipsevl]

Для сетки 44/48 сейчас пин уже есть конечно.

Хорошо, технически это все сделать несложно. Тем более что в проекте уже заложен UART. Есть два режима работы:
1. Мост PC->UART, т.е. обычный виртуальный ком порт. Примерно как FTDI.
2. Режим "CLI", который по факту сейчас есть, но ничего не делает. Вот как раз в этом режиме я могу события выводить.

[dortonyan]

Offтопик:

Сейчас увидел у Алексея, что он тоже в DF3E сделал автоопределитель.

У меня он криво работает (нестабильно), поэтому в примеры не стал включать. А при публикации просто забыл вырезать из исходников.

[antecom]

Причем для универсальности можно сделать выбор назначения выхода: 0 - GPIO выбора сетки 44/48, 1 - Uart TX. Каждый выберет что ему удобнее, и всего один сигнал.

Логично. Тоже об этом думал.

Мост PC->UART, т.е. обычный виртуальный ком порт. Примерно как FTDI.

Непонятно что чего это и как использовать в ЦАП?
Если нужен в хозяйстве виртуальный COM порт, переходник USB->UART проще купить отдельный.
Перечитал шапку. Вопрос снимается "для управления DSP." Но все таки потенциальным пользователям транспорта это нужно редко, а передача служебной информации нужна постоянно.

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

Вывести, для начала, один байт: частоту дискретизации (нечетные - х44.1, четные х48) и битрейт DSD. Потом, если потребуется, добавить что нибудь ещё.
И хорошо бы завести этот сигнал на основной разъем платы (сейчас он на отдельном 4-х пиновом разъеме, как я понял).