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]

Попробуйте так:
sra $t6, $t6, 31
xori $t6, $t6, 0x00ffffff

О, отлично! Спасибо.

В одну инструкцию не придумал как, нужно вникать в алгоритм модулятора.

Так однобитное квантование от алгоритма модулятора не зависит.
А схема самого модулятора вот:

В документации на набор инструкция процессора. Есть такая шпаргалка еще:

В шпаргалке не все инструкции, а в доках микрочипа ссылаются на мануал MD00374, в котором я такого что-то не нахожу.

P.S.
Пооптимизировал еще первую ступень 5842. Все таки придумал как использовать св-во симметрии, и увеличил размер копируемого блока данных до 15 семплов (чтобы сократить кол-во инкрементов адреса при обсчете ЦФ).
На 200МГц один проход первой ступени сократился до 2,34мкс. Правда за счет довольно трудоемкого кода с расчетом адресов симметричных отводов.
Конечно для 5842 не очень-то и надо, а вот ради более длинных фильтров есть смысл помучаться.

---------- Сообщение добавлено 20:40 ---------- Предыдущее сообщение было 20:25 ----------

sra $t6, $t6, 31
xori $t6, $t6, 0x00ffffff

Попробовал такой вариант, только через XOR. Время получилось наоборот больше. Вот и пойми этот ассемблер. ))

[eclipsevl]

В шпаргалке не все инструкции, а в доках микрочипа ссылаются на мануал MD00374, в котором я такого что-то не нахожу.

В нем только реальные инструкции.

На 200МГц один проход первой ступени сократился до 2,34мкс.

Вот ведь, а я сейчас на 3.2 А сколько за проход 6 стерео семплов в целом?

---------- Сообщение добавлено 21:45 ---------- Предыдущее сообщение было 21:45 ----------

Попробовал такой вариант, только через XOR. Время получилось наоборот больше. Вот и пойми этот ассемблер. ))

2 инструкции дольше чем 3?

[dortonyan]

Вот ведь, а я сейчас на 3.2 А сколько за проход 6 стерео семплов в целом?

Можно умножить на 6, все проходы примерно одинаковые. Пока что полное время могу посмотреть только для всего х8 апсемплера.
Но у меня еще, после каждой 512-ой записи нового семпла на входе, выполняется копирование сектора из хвоста в заголовок (16 семплов). Хотя конечно если усреднить на время записи 512 входных семплов, то это ерунда.

2 инструкции дольше чем 3?

Да.
Но я попробовал по другому: загрузил маску предварительно в регистр. Вот тогда получил выигрыш.
Походу загрузка 32бит константы требует два такта, как и для LI инструкции.

[eclipsevl]

Можно еще пару инструкций убрать из модулятора:

 // quantize output
#    SHLL_S.W $t6, $t6, 31
#    SRA $t6, $t6, 2
#    // get output bit
#    SRL $v0, $t6, 31
#    // shift and load new bit in output bitsream register
#    SLL $t7, $t7, 1
#    OR $t7, $t7, $v0 # 
    
    sra $t6, $t6, 31                 # saturation
    xor $t6, $t6, $reg(0x3fffffff)   # gain correction
    append $t7, $t6, $reg(1)         # t7 = t7 << 1 | t6[0]

Первые две то что я предложил для сатурации, а для получения выходного бита можно применить append. Только константу (1) нужно тоже поместить в какой-нибудь регистр

[dortonyan]

eclipsevl, спасибо, то что надо. Еще и вывод бита как раз без инверсии получается.
Тоже собирался что-то такое опробовать, но сходу не нашел аппенд инструкцию. Инструкций наделали, что все не упомнишь.

В общем на новом оптимизированном коде с минимальным разгоном по частоте (260МГц) пик обсчитывает х16 апсемплер с длинной первой ступенью (223 тапка) с ослаблением 44дБ на частоте Найквиста + соневский модулятор (DSD64).

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

Добавил новый код в модулятор. Только на этот раз 3-ий параметр наоборот должен быть константный.
Теперь еще быстрее работает: описанную выше обработку успевает даже на частоте чуть ниже штатной (248МГц).

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

Могу предложить еще задачку на оптимизацию.
Обсчет LFSR:

   
    // LFSR1 one shift processing with 0xa3000000 polynome
    AND $v1, $t8, 1
    MUL $v1, $v1, 0xa3000000
    SRL $t8, $t8, 1
    XOR $t8, $t8, $v1
    // Noise gain set
    SRA $a3, $t8, $t1

Т.к. шум плюсуется к сигналу на выходе, то этот код тоже работает с высокой частотой.
Само значение LFSR содержится в $t8, результат с нужным гейном сохраняет в $a3.

[dortonyan]

Посмотрел по подсказке tomtit алгоритмы генерации ПСП на LFSR+LUT.
Возможно не догоняю принцип, но получается что там после одного сдвига LFSR на каждый след. семпл выполняется перебор масок из массива, с XOR наложением на LFSR.
Для генерации большого кол-ва семплов шума подряд такой алгоритм конечно шустрее, но для генерации одиночного семпла выглядит не очень.
Но, опять же, если я правильно понял принцип.

А еще задумался - есть ли смысл копировать данные из USB буфера с помощью DMA.
Может лучше тоже процем скопировать? Тогда убирается обработчик прерывания USB_DMA, который тоже расходует немало тактов процессора.
eclipsevl, не пробовали такой вариант?

[Meta|_]

Возможно не догоняю принцип, но получается что там после одного сдвига LFSR на каждый след. семпл выполняется перебор масок из массива, с XOR наложением на LFSR.
Для генерации большого кол-ва семплов шума подряд такой алгоритм конечно шустрее, но для генерации одиночного семпла выглядит не очень.
Но, опять же, если я правильно понял принцип.

LFSR - по сутит тот же CRC. Табличный метод позволяет получить несколько бит сразу. Но если эти биты Вам нужны по одному, то придётся вытаскивать их сдвигом/маской (и да, не факт, что это выйдет быстрее "побитовой реализации" LFSR).

[dortonyan]

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

Понял.
Я-то из LFSR и так забираю сразу несколько бит, т.ч. с таблицей можно не заморачиваться.

P.S.
Запустил х32 апсемплер. Причем качественно апсемплер не хуже такового в DF3E (фильтры сделал аналогичные с небольшими улучшениями).
В общем-то можно обсчитать и х64..х128, но на пике уже нет возможности вывода такого датарейта, если только распараллеливать данные на несколько потоков через QSPI.
Сейчас даже х32 получается вывести только за счет 16-битного фрейма.
И 5842 с частотой семплирования на входе 192кГц тоже обсчитывает без проблем. Т.е. пик может легко заменить 5847.

[Turbo_man]

А конвейерно на каждый канал 2 потока по х16?
Кому нужно сможет это использовать.

[dortonyan]

С 16-битным фреймом увы, не получится. Т.к. для такого фрейма вордклок генерируется SPI модулем. У пика просто не хватит SPI модулей.
Для 32-битного фрейма сделать можно, но частота битклока будет 512Fs.

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

Ну или если как-нибудь задействовать SQI модуль и запускать его параллельно с SPI, но я не вникал можно ли так.

[eclipsevl]

А еще задумался - есть ли смысл копировать данные из USB буфера с помощью DMA.
Может лучше тоже процем скопировать? Тогда убирается обработчик прерывания USB_DMA, который тоже расходует немало тактов процессора.
eclipsevl, не пробовали такой вариант?

Я пока использую, но возможно имеет смысл убрать DMA т.к. все равно потом данные обрабатываются ядром.

С 16-битным фреймом увы, не получится. Т.к. для такого фрейма вордклок генерируется SPI модулем. У пика просто не хватит SPI модулей.

Почему же, 4 SPI есть, по два на канал, как раз.

[tomtit]

Да, я тоже подумал, что выигрыша особо нет, потому и стер сообщение.
Другое дело, что во всех новых процессорах есть аппаратные генераторы случайных чисел и аппаратные модули для
CRC. Может быть их можно приспособить? К тому же есть простые арифметические конгруэнтные RNG, оптимизированные для обычных 32-бит процессоров.

[dortonyan]

Почему же, 4 SPI есть, по два на канал, как раз.

Так а вордклок чем генерить? Для 32-х битного фрейма это будет SSO выход, а для 16-битного так не получится.
Если только SQI приспособить. Он тоже может тактироваться от внешнего клока. И если снаружи подать клок на два мультиплексора REFCLKх, то возможно удастся синхронизировать SPI и QSI. Но это не точно.

Другое дело, что во всех новых процессорах есть аппаратные генераторы случайных чисел и аппаратные модули для
CRC. Может быть их можно приспособить?

По идее можно, у меня как раз такая версия пика (EFG). Но получается не универсально: на процах pic32mz без индекса G работать не будет.

---------- Сообщение добавлено 20:11 ---------- Предыдущее сообщение было 19:43 ----------

Я пока использую, но возможно имеет смысл убрать DMA

Посмотрел диассемблер, там только на вход и выход из обработчика USB_DMA суммарно расходуется 90 инструкций. За это время ядром можно скопировать 22 семпла.
Плюс сам код в обработчике для запуска DMA - еще десяток инструкций.
Получается при небольших частотах семплирования (до 192кГц) копирование ядром однозначно выгоднее. Но если частота будет 384 или 768кГц, то тогда уже и выгоднее дма.
В общем для универсальности наверное имеет смысл DMA оставить.

P.S.
Хотя если еще учесть задержки на чтение из когерентного FIFO ядром, то возможно что и на повышенных ЧД выигрыша DMA не будет.
Для частоты 768кГц один пакет это 96 семплов, или 192 32-х битных копирования. Если на каждом время инструкции выполняется втрое дольше (судя по производительности обсчета FIR, может и в четверо), то это эквивалентно как минимум лишним 384 инструкциям.

[eclipsevl]

Так а вордклок чем генерить? Для 32-х битного фрейма это будет SSO выход, а для 16-битного так не получится.

SPI может работать в режиме 16 битных фреймов, 32 такта на период WCK

[tomtit]

Но получается не универсально: на процах pic32mz без индекса G работать не будет.

Так и сами процессоры PIC32 скорее всего безнадежно устареют через 2-3 года. После покупки Atmel и лицензии на ARM,
Microchip уже не рассматривает их, как основной продукт. Всё мире смещается в сторону ARM и RISC V, и очень быстро.

[dortonyan]

SPI может работать в режиме 16 битных фреймов, 32 такта на период WCK

Ну так речь же про вывод каналов в параллель. Для 16 битного фрейма и период вордклока тоже должен быть 16 бит.

Так и сами процессоры PIC32 скорее всего безнадежно устареют через 2-3 года.

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

[eclipsevl]

Если это для PCM цапов - можно выводить данные в режиме SPI с периодом SS в 8/16/32 бит, ширина импульса 1 бит. Я подобным образом TDM запилил. Сначала отдельным SPI генерил Latch, потом допер как одним SPI все генерить. На вввод кстати тоже разобрался с 8 каналами по TDM.

[Turbo_man]

SQI наверно имеет смысл делать только если потом мелкой плисиной перепаковывать в несколько обычных потоков х8 или х16 для параллельников.

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

Кстати, аналогично 4х битной шиной данных SONY связвала свои ЦФ с ДС-модуляторами, если в разных корпусах они шли. Причём раздельно каждый стерео канал.

[dortonyan]

Если это для PCM цапов - можно выводить данные в режиме SPI с периодом SS в 8/16/32 бит, ширина импульса 1 бит.

Понял, тогда нет вопросов (по крайней мере для 16-битных ЦАП).

SQI наверно имеет смысл делать только если потом мелкой плисиной перепаковывать в несколько обычных потоков х8 или х16 для параллельников.

Если SQI использовать только для генерации вордклока, то ничего паковать не придется: данные просто будут заливаться из константного массива.

Кстати, аналогично 4х битной шиной данных SONY связвала свои ЦФ с ДС-модуляторами, если в разных корпусах они шли.

Так и сейчас используются аналогичные интерфейсы, только большей разрядности. Например вход с модулятора в AK4499EX, или выходы с модуляторов в АЦП (PCM4222, ES9822 и т.п.).

[Turbo_man]

Нет, я про вывод наружу из Пика PCM потоков быстрее х16. Например, х64.