Дешевый USB transport (для саморазвития)?

[antonluba]

Идея такая: берется STM32F4xx. У него есть USB и I2S. Проц и USB тактируется от HSE - кварц на необходимое кол-во МГц+PLL. Через USB в асинхронном режиме выводится аудио поток.
Для I2S вариантов тактирования два: от PLL с соответствующим снижением качества или от ЦАПа на специальный вход модуля I2S.
Модуль I2S поддерживает форматы Philips, RJ, LJ, PCM, 16 или 32 бит до 96 192 кГц. (Вы это всё знаете, конечно).
Теоретически, можно получить универсальный вывод (ввод тоже) I2S через USB (для многих, думаю, достаточного уровня).

Лично у меня сложности следующие:
1. Исходники асинхронного вывода (и ввода) по USB.
2. Получение от хоста параметров потока и переключение частот.
3. Аппаратная реализация работы двух генераторов на один вход.
4. Внутренняя синхронизация между I2S и USB.
Ну и еще мелочей всяких.

Набросайте ссылок по теме, пожалуйста.

P.S. Audio Widget я конечно, скачал, но, честно говоря, разобраться пока не смог.

[dortonyan]

Хотя по расчетам частота очень близко получается с передаваемым значением.

"Очень близко" - это сколько конкретно в ppm?
Чтобы буфера хватало на несколько часов отклонение частоты должно быть единицы или даже доли ppm.
По моему подстройка по заполнению буфера проще и надежнее, т.к. автоматом держит заданное заполнение фифо.

[antonluba]

"Очень близко" - это сколько конкретно в ppm?
Чтобы буфера хватало на несколько часов отклонение частоты должно быть единицы или даже доли ppm.
По моему подстройка по заполнению буфера проще и надежнее, т.к. автоматом держит заданное заполнение фифо.

По смыслу - я считаю MCLK по аппаратному сигналу SOF от модуля USB, что должно автоматически давать нужное количество переданных данных (по количеству импульсов MCLK), так же?
Соответственно хост должен это количество присылать. Если я все правильно понимаю.

Поскольку частота не кратна, у меня полученное значение прыгает в пределах нескольких единиц от измерения к измерению.
Конкретно передаваемое значение варьируется от 0x0B0650 до 0x0B0654, что при целочисленном делении дает частоту 44098, а частоту MCLK 11289250 - 11289312 (пока тактирую от встроенного PLL).

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

Надо еще разобраться с bRefresh.
Сейчас получается странно, если задать bRefresh = 5 (32мс), feedback передается 30-31 раз в секунду, как и должен.
А если задаю 6 (64мс) - только 7 раз в секунду. Хотя должен 15. Или в коде где-то задано жестко, не нашел пока

[dortonyan]

По смыслу - я считаю MCLK по аппаратному сигналу SOF от модуля USB, что должно автоматически давать нужное количество переданных данных (по количеству импульсов MCLK), так же?
Соответственно хост должен это количество присылать. Если я все правильно понимаю.

Получается вы считаете с точностью в один такт MCLK за период SOF? Это очень слабая точность.
Чтобы получить нужную точность - нужно накапливать не за один период SOF, а за много: в течение секунды, или нескольких секунд, без сброса счетчика.

Можно сразу после старта задать в переменную FB значение 44100.
А потом в течение 1 сек. накапливать более точное значение (в течение одной секунды позиция входных данных в фифо много от середины не убежит).
Затем передать значение, накопленное за 1 сек, и запустить накопление на более длинном интервале, скажем на 100сек.

Надо еще разобраться с bRefresh.
Сейчас получается странно, если задать bRefresh = 5 (32мс), feedback передается 30-31 раз в секунду, как и должен.
А если задаю 6 (64мс) - только 7 раз в секунду. Хотя должен 15. Или в коде где-то задано жестко, не нашел пока

Несоответствие может быть и на стороне хоста. Там вполне возможно не полное соответствие спецификации.

[antonluba]

Получается вы считаете с точностью в один такт MCLK за период SOF?

Нет, считаю за 64 периода SOF, это сразу дает нужное число в формате 10.14. Оно сохраняется в переменную через DMA аппаратно.
Писал выше.
Дальнейшее наращивание длительности периода измерения смысла не имеет, потому что приведение полученного значения к формату 10.14 всю точность растеряет.

Слишком все сырое. Много ошибок. Ладно, буду ковыряться потихоньку.
Спасибо.

[dortonyan]

Нет, считаю за 64 периода SOF, это сразу дает нужное число в формате 10.14. Оно сохраняется в переменную через DMA аппаратно.
Писал выше.
Дальнейшее наращивание длительности периода измерения смысла не имеет, потому что приведение полученного значения к формату 10.14 всю точность растеряет.

Т.е. получается отклонение чуть ниже 1,4ppm.
Что означает смещение буфера на семпл 44,1к каждые 16 сек. Тогда за час набегает смещение на 225 семплов. Если я правильно посчитал.
Как бы да, несколько часов должно работать без рассинхрона. Если конечно время чтения и перезапуска таймера строго детерминировано (т.е. если чтение/перезапуск таймера не добавляет погрешность).
Но все равно для надежности лучше добавить отслеживание положения FIFO.

[antonluba]

время чтения и перезапуска таймера строго детерминировано (т.е. если чтение/перезапуск таймера не добавляет погрешность)

Я на прошлой странице над этими таймерами бился.

Таймеры не останавливаются.
Один таймер считает SOF-ы, сейчас используется аппаратный сигнал на внешнюю ножку от модуля USB, при наступлении 64-го импульса сигнал триггера отправляется на другой таймер, который считает MCLK (тоже через внешнюю ножку), этот таймер сохраняет значение в регистр захвата, сбрасывается и запускается DMA, которое копирует регистр захвата в переменную.

У меня там других проблем пока хватает. Буду потихоньку разбираться, по мере поступления вопросов - писать здесь

[antonluba]

Странно, в процессе переписывания кода, уже не первый раз, перестаю попадать в DataOut. Причину не могу найти.
На компьютере все работает по видимому нормально. В анализаторе usb пакеты идут в обоих направлениях.
Никто не сталкивался?

---------- Сообщение добавлено 16.03.2025 в 12:50 ---------- Предыдущее сообщение было 15.03.2025 в 22:41 ----------

Отследил обработчик прерывания, при получении данных для out EP происходит прерывание NAK