Комментарии 28
Почему был выбран именно STM? Есть же более подходящие чипы для обработки звука, если конечно планируется его обрабатывать прямо в устр-ве. К примеру, процессора Analog Devices DSP Sharc (если плавучка нужна) или DSP Blackfin (если достаточно целочисленных).
Существует готовая плата, правда на 7 микрофонов www.seeedstudio.com/Sipeed-6-1-Microphone-Array-for-Dock-Go-Bit-p-2875.html
По ссылке две платы: одна — просто текстолит с микрофонами (и светодиодами, но это неважно); вторая — SoM с двухъядерным RISC-V с блоками ускорения нейросетей и цифровой обработки. Но без USB :) Так что для исходной задачи — трансляции сигнала в USB — этот SoM плохо подходит. Плата же с микрофонами нам тоже не очень интересна, потому что микрофонные платы наших устройств точно будут другими.
Мало картинок/фоток. Выглядит как кусок вырванный из контекста.
Есть вот такое вот решение www.minidsp.com/products/usb-audio-interface/uma-8-microphone-array.
По дефолту там зашиты алгоритмы бимформинга и какие-то DOA, но преимущества в том, что у них есть прошивка, которая просто отдает сырые данные. Референсные данные они тоже дают. Т.е. можно просто плату повторить вообще без заморочек с софтом. Из приятного, драйвера работают под все ОС.
Из доп. вопросов было бы интересно посмотерть на работу с USB стеком(понятно, что использовался стек от STM, но интересно именно его использование).
Также интересно узнать как калибруете микрофоны. Или просто используются какие-то «робастные» алгоритмы на основном процессоре, которые не требуют калибровки?
По дефолту там зашиты алгоритмы бимформинга и какие-то DOA, но преимущества в том, что у них есть прошивка, которая просто отдает сырые данные. Референсные данные они тоже дают. Т.е. можно просто плату повторить вообще без заморочек с софтом. Из приятного, драйвера работают под все ОС.
Из доп. вопросов было бы интересно посмотерть на работу с USB стеком(понятно, что использовался стек от STM, но интересно именно его использование).
Также интересно узнать как калибруете микрофоны. Или просто используются какие-то «робастные» алгоритмы на основном процессоре, которые не требуют калибровки?
Плата от XMOS выглядит существенно сложнее нашей. Опять же, STM32 гораздо доступнее по сравнению с XMOS. Насчёт отсутствия заморочек с софтом — вопрос тоже спорный, потому что же придётся в этот XMOS чип как-то заливать прошивку. На отладочной плате есть встроенный программатор для этого, а на своей что делать? Возможно, можно подключиться стандартным JTAG, — но тут уже начинаются вопросы и сомнения. Пока что у нас нет стремления изучать XMOS, хотя ребята они хорошие :)
Что Вы подразумеваете под «существенно» сложнее? Там ни одной BGA микросхемы, односторонний монтаж и класс точности 3-й или 4-й на глаз. Разводится все в 2-х слоях. Даже на картинке видно что ~60% компонентов не установлено и использеются как опциональные. Можно на сайте XMOS посмотреть референсы. Там чип работает фактически из коробки. Пока что выглядит все, как «всегда использовали STM32, поэтому смотреть на что-то готовое не хочется». Если есть страх перед JTAG, так там загрузчик через USB работает (serial bootloader). Подключаете к компу, запускаете програмку для обновления прошивки и заливаете прошивку для передачи сырых данных на 8 каналов.
Тут ещё вопрос целеполагания. Потому что, как известно, «любой шаг, не ведущий к прогрессу, ведёт к деградации».
Можно, конечно, повторить плату от XMOS, изучив её схему и выкинув лишнее. Понадобится изучить ряд вопросов. Загрузчик там сразу есть, с завода, по USB? А какая микросхема FLASH подойдёт для хранения прошивки? Точно? А то они как-то подтвердили Part Number, а оно не заработало :) А как быть с микросхемой генератора частот? (Там есть нюансы, XMOS заказывает её предпрошитую, чтоб она генерировала что надо при включении питания).
То есть, это не просто срисовать схему. Потребуется её творчески переработать. Возможно, это будет быстрее, чем сделать свою плату со своим софтом, но какой опыт при этом будет получен? Разве что аппаратные особенности конкретной системы XMOS, и это не очень интересно.
Можно, конечно, повторить плату от XMOS, изучив её схему и выкинув лишнее. Понадобится изучить ряд вопросов. Загрузчик там сразу есть, с завода, по USB? А какая микросхема FLASH подойдёт для хранения прошивки? Точно? А то они как-то подтвердили Part Number, а оно не заработало :) А как быть с микросхемой генератора частот? (Там есть нюансы, XMOS заказывает её предпрошитую, чтоб она генерировала что надо при включении питания).
То есть, это не просто срисовать схему. Потребуется её творчески переработать. Возможно, это будет быстрее, чем сделать свою плату со своим софтом, но какой опыт при этом будет получен? Разве что аппаратные особенности конкретной системы XMOS, и это не очень интересно.
и это нормально. STM справляется полностью, есть в наличии, умеют работать — замечательно. В т.ч. в этом заслуга менеджеров от ST, продававших STM*Discovery дешевле себестоимости, отсутствие шакалинга по поводу клонов ST-Link и разработки GD32 и т.п.
Вот еще бы в Middlewares добавили класс video…
Вот еще бы в Middlewares добавили класс video…
Стандартные библиотеки от ST мы не используем, потому что они нам не нравятся.
В некоторых наших устройствах на STM32 используется ChibiOS в довольно урезанном виде (потому что, например, HAL от Chibios нам тоже не нравится). Но USB стек там неплохой, его мы и применяем. Тот кусок, который работает как восьмиканальный микрофон, мы писали сами. Дескрипторы сооружали тоже сами. читая кусок стандарта USB про аудиодевайсы.
В некоторых наших устройствах на STM32 используется ChibiOS в довольно урезанном виде (потому что, например, HAL от Chibios нам тоже не нравится). Но USB стек там неплохой, его мы и применяем. Тот кусок, который работает как восьмиканальный микрофон, мы писали сами. Дескрипторы сооружали тоже сами. читая кусок стандарта USB про аудиодевайсы.
А можно чуть подробнее. Если не нравится, то что именно. Часто приходится слышать, что «этот стек не нравится», «HAL у них вообще отстой», но редко кто аргументы приводит. Если получается написать свой лучше, то где-то выкладываете?
Для того, чтобы написать что-то с использованием стандартных библиотек, надо изучить:
* datasheet (+Reference Manual);
* документацию на библиотеку, если есть;
* пример использования библиотеки;
* код библиотеки (а он зачастую прям труден для понимания).
Если же писать что-то на регистрах, достаточно первого пункта.
Разработка с использованием стандартных библиотек шла ужасно медленно, и закончилась вот как. Нужно было вывести ШИМ с определённого канала таймера, при этом выполнив какой-то хитрый Remap (подробности сокрыты туманом времени, давно было дело). Было потрачено четыре часа на тщетные попытки сделать это через HAL. И тогда на регистрах всё было написано за пятнадцать минут.
То есть, на HAL становится чудовищно неудобно писать, как только появляется какая-то нестандартная задача. Точнее, так: некоторый набор задач учитывался при разработке HAL, и их решать удобно. Но если задача не закладывалась в HAL, то её решить средствами HAL либо сложно/некрасиво, либо вообще нельзя (и приходится писать в регистры).
Ещё один момент: для инициализации периферии через HAL требуется несколько экранов кода, потому что задание параметров через структуры очень громоздкое. А хочется использовать что-то вроде
В целом, конечно, тут в большой степени дело вкуса. Кому-то вполне удобно использовать HAL (или LL), плюс HAL неизбежно будет:
* известен большему количеству разработчиков
* лучше документирован
потому что исходно создаётся для общественного пользования. Наши библиотеки, увы, документированы разве что комментариями в коде.
* datasheet (+Reference Manual);
* документацию на библиотеку, если есть;
* пример использования библиотеки;
* код библиотеки (а он зачастую прям труден для понимания).
Если же писать что-то на регистрах, достаточно первого пункта.
Разработка с использованием стандартных библиотек шла ужасно медленно, и закончилась вот как. Нужно было вывести ШИМ с определённого канала таймера, при этом выполнив какой-то хитрый Remap (подробности сокрыты туманом времени, давно было дело). Было потрачено четыре часа на тщетные попытки сделать это через HAL. И тогда на регистрах всё было написано за пятнадцать минут.
То есть, на HAL становится чудовищно неудобно писать, как только появляется какая-то нестандартная задача. Точнее, так: некоторый набор задач учитывался при разработке HAL, и их решать удобно. Но если задача не закладывалась в HAL, то её решить средствами HAL либо сложно/некрасиво, либо вообще нельзя (и приходится писать в регистры).
Ещё один момент: для инициализации периферии через HAL требуется несколько экранов кода, потому что задание параметров через структуры очень громоздкое. А хочется использовать что-то вроде
PinSetupAlterFunc(GPIOB, 9, omPushPull, pudNone, AF13);В целом, конечно, тут в большой степени дело вкуса. Кому-то вполне удобно использовать HAL (или LL), плюс HAL неизбежно будет:
* известен большему количеству разработчиков
* лучше документирован
потому что исходно создаётся для общественного пользования. Наши библиотеки, увы, документированы разве что комментариями в коде.
Использование MXcube совместно с HAL сильно упрощает ситуацию с начальной инициализацией.
По большому счёту, никто не запрещает прямую запись в регистры и в случае использование HAL.
HAL серьёзным образом упрощает перенос проекта между микроконтроллерами различных серий и вторичное использование кода. Есть некоторый проигрыш в объёме кода и производительности, но при этом получаешь достаточно корректный обработчик ошибок.
В результате я таки перешёл в прошлом году на HAL, stm32CubeMX, sw4stm32 и CMSIS-RTOS2. Времени на освоение пришлось потратить немало, надеюсь оно окупится уже в этом году.
По большому счёту, никто не запрещает прямую запись в регистры и в случае использование HAL.
HAL серьёзным образом упрощает перенос проекта между микроконтроллерами различных серий и вторичное использование кода. Есть некоторый проигрыш в объёме кода и производительности, но при этом получаешь достаточно корректный обработчик ошибок.
В результате я таки перешёл в прошлом году на HAL, stm32CubeMX, sw4stm32 и CMSIS-RTOS2. Времени на освоение пришлось потратить немало, надеюсь оно окупится уже в этом году.
Вообще, параметры микрофонов достаточно похожи. На производстве каждая плата проходит через специальный стенд, который проверяет микрофоны: проигрывается синусоида меняющейся частоты, записывается сигнал каждого микрофона, а дальше этот сигнал сравнивается с образцовым. Если параметры отличаются больше дозволенного — плата считается бракованной.
Вот это довольно интересные вещи. Например, какие допустимы отклонения в собственных шумах считаете примемлимые. Или гармонические искажения. Очень интересно было бы понять как влияют эти параметры на качество алгоритмов бимформинга, echo cancellation, DOA и т.д.
Там всё проще. Можно сказать, что микрофоны или работают, или не работают. То есть, в случае проблем характеристики катастрофически хуже, и это сразу видно.
Собственные шумы и гармонические искажения влияют слабо, потому что исходно система работает в сильно зашумлённой обстановке: там же ещё в сантиметрах от микрофона играет громкая музыка! И в нашем случае мы распознаём речь, а не классическую музыку записываем, так что требования к гладкости характеристики ниже.
Собственные шумы и гармонические искажения влияют слабо, потому что исходно система работает в сильно зашумлённой обстановке: там же ещё в сантиметрах от микрофона играет громкая музыка! И в нашем случае мы распознаём речь, а не классическую музыку записываем, так что требования к гладкости характеристики ниже.
На многих платах последнее время вижу по периферии ободок со множеством via, причем не покрытый маской. Причем не только в массовом производстве, но и в DIY (можете на ошпарке глянуть).
Это необходимость (почему так много переходов?), или просто «чтобы выглядело красива и бохато»?
Это необходимость (почему так много переходов?), или просто «чтобы выглядело красива и бохато»?
ну и да, зачем клоки микрофонов выравнивать? наносекундную фазу звуковой волны ловить? =)
Вообще-то, используя модуль SAI, а не SPI, STM32 позволяют подключить 8 цифровых микрофонов напрямую.
Кроме того, конкретно ваш проц имеет ещё один аппаратный модуль для подключения PDM-микрофонов напрямую, который и обработает и проредит PDM-данные. DFSDM называется, имеет 8 каналов, на которые вешается одна стерео-пара.
Как-то вы плохо доки читали.
Кроме того, конкретно ваш проц имеет ещё один аппаратный модуль для подключения PDM-микрофонов напрямую, который и обработает и проредит PDM-данные. DFSDM называется, имеет 8 каналов, на которые вешается одна стерео-пара.
Как-то вы плохо доки читали.
познавательно, но собственно как всегда у Вас. Спасибо!
Было бы интересно взглянуть на сорс. Линк «Вторая серия» ведет на первую серию.
А можно ли как-то Яндекс-станцию использовать как хороший микрофон, со всеми этими подавлениями шумов вне луча и т.д.?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тестируем системы микрофонов на STM32: опыт разработчиков устройств Яндекса