Дешевый 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

[user12]

Странно, в процессе переписывания кода, уже не первый раз, перестаю попадать в DataOut.

Смешно(с). В субботу всю ночь, порядка 6 часов, пытался разобраться с тем, что iso идут, а DataOut быстро (или не_быстро) отмирает. Не решено.
Наверно я бы решил и быстрее, но тут была неоценимая поддержка gpt. Прямо как цитата - " За десять дён одному не справиться! Тут помощник нужен". В результате код разодрал настолько, что он начал чувствовать пакеты j-link.
К сссути. Есть такая функция, USBD_LL_PrepareReceive и у нее последний параметр uint32_t size. Он используется в двух местах - как настройка EP(1) и как настройка буфера в Hell. И тут ровно два варианта:
- размер iso и size совпадают. Принимается ровно 1 блок и (в конце концов) вызывается USBD_AUDIO_DataOut(). В режиме 5.1 у меня через 1-20 секунд всё падало. Причем, для меньшего блока (2.0, 4.0) работало нормально. Но это уже нюансы того, что я наворотил. Так, режим вполне рабочий.
- размер iso меньше size. А вот это самое интересное. При этом неизбежно идут обращения к USBD_AUDIO_IsoOutIncomplete() и в приемный буфер сыпется 1-3-4 блока разом (вызов USBD_AUDIO_DataOut). Никаких проверок в Hell нет, блоки iso будут получаться и складироваться до выставления флага от EP(1). При этом буфер бесконтрольно растет и затирает RAM, при любом размере этого буфера. Как увидел, увеличил размер буфера на 20% - затер. Хорошо, в 2 раза - затер, в 4 раза - так-же затер. Пошел читать логику обработчика, "усталл". Т.е., вначале стоит проверить, не разрастается ли сей буфер по всему RAM. Благодаря настойчивой помощи gpt (сарказм) я раздолбал весь код, поэтому всё вышесказанное может быть прямым следствием расставленых костылей от gpt. Один нюанс - мне нужен просто буфер на один iso, а перекладывать его я буду сам. Код HAL ориентирован же на другое, в этом так-же может быть проблемы.
За время возьни отмечал переполнение буфера приема перетирание всего подряд буфером приема, остановка обработчика прерывания USB (в NVIC висит статус активен), замораживание EP1. При этом в wireshark лог вполне адекватен, iso идут. А DataOut не вызывается. Ничего не вызывается. )) При этом снижение с 5.1 на 4.0 или 2.0 проблему устраняет (но приемный буфер так-же бесконтрольно расползается).
Повторяю - решения нет.
Remark.
Это далеко не первый вариант построения 4.0/5.1 и они доведены до рабочего состояния. Но, как водится, имеют скрытые дефекты. Потому захотел сделать на типовом cubeMX с собственными доработками. Всегда могу обнулитьи перейти на них, но хочется всё-же понять, какого лешего ее не хватает. К слову, измерил время нахождения в обработчике прерывания USB, получил макс. 10 мкс. Стало еще более непонятно. )))

[antonluba]

Я пытался найти, в каких случаях контроллер может отвечать NAK на ISO пакеты.
Есть один флажок в глобальном регистре, который выбирает, что выставлять, NAK или STALL, если входящий пакет поступает при активной передаче чего-то там...
Сейчас с ходу не нашел.
То есть в моем случае, вероятно, что-то передается невовремя или постоянно.

И в целом, проблемы начинаются при организации передачи через FB EP. С учетом того, что я пытаюсь найти хитрое решение, грабли возможны.

Еще ведь каждая реализация хоть что-нибудь, но делает по-особенному. Надо во все вникать.

Если тупо возвращаю файл usbd_audio.c до версии без FB, все начинает работать нормально

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

При этом снижение с 5.1 на 4.0 или 2.0 проблему устраняет

Если можно, поделитесь кодом.
Какой контроллер у вас?

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

Действительно, с буфером связано как-то. Пока не понял, как именно