Нужно преобразовать выход 16 PDM микрофонов в SPI. Опции

[163264]

Нужно решение, преобразующее 16 выходов PDM микрофонов в SPI.
Важно минимальное потребление, небольшая стоимость решения.
Плюсом будет возможность масштабирования решения до 32, 64 каналов.
Частоты дискретизации от 8 до 48 кГц, выходная разрядность 24 бита.
Антиалайзинговый фильтр, особенно на низких частотах дискретизации, очень желателен.
Но этот момент обсуждаем ибо понятно, что это требует доп. ресурсов и потребления.
Выходной последовательный формат тоже обсуждаем. Интересует простота ввода данных в контроллер.
Цель устройства - запись звука, в основном речи.
Объем работы:
Подбор оптимального решения (требования не жесткие, обсуждаемые), схема, разводка макетной ПП,
(те без жёстких требований по габаритам),
изготовление пары макетов, прошивка ПЛИС и/или контроллера, дока.
Предложения с примерными характеристиками решения, ценой работы и сроками в личку, плиз.

[jcxz]

Выходной последовательный формат тоже обсуждаем. Интересует простота ввода данных в контроллер.

Контроллер то какой? А то поди абдурина.
И что мешает все эти микрофоны прямо к этому контроллеру и подцепить без всяких промежуточных SPI-костылей?

в spi как уже отметили не пролезет,

Пока ТС не озвучил свой контроллер это слишком смелое утверждение. Хотя может это только я тут не телепат?
SPI бывает quad к примеру. А некоторые производители его делают ещё и DDR.

[_pv]

И что мешает все эти микрофоны прямо к этому контроллеру и подцепить без всяких промежуточных SPI-костылей?

наверное то, что если даже захватить 32 битовых PDM потока (от 64х микрофонов DDR) на ~4МГц через dma, контроллер только и будет заниматься тем что переворачивать эти битовые матрицы (из параллельного в последовательный) чтобы данные по каналам разделить.
хотя у некоторых LPC есть sgpio которые это и сами сделать могут, но больше 16ти каналов не встречал.

Пока ТС не озвучил свой контроллер это слишком смелое утверждение. Хотя может это только я тут не телепат?
SPI бывает quad к примеру. А некоторые производители его делают ещё и DDR.

судя по озвученному, так сказать "ТЗ", слишком смело как раз рассчитывать на то, что там будет quad spi c DDR. скорее уж действительно абдурина

[jcxz]

хотя у некоторых LPC есть sgpio которые это и сами сделать могут, но больше 16ти каналов не встречал.

Я как раз и имел в виду SGPIO
А насчёт нагрузки на CPU: так в тех LPC где есть SGPIO, там есть и по 3 ядра (правда два - M0) на 204МГц.
А кроме SGPIO я ещё имел в виду например McASP в OMAP-L1xxx: 16+12+4 сериализаторов + 4 мощных ядра CPU (из них одно - DSP) - вычислительных ресурсов вполне хватит и для обработки.
А если на дохлый ARM будет приходить (пускай даже в одном SPI) 64 потока - то пускай они уже будут разложены на сэмплы - производительности может не хватить.

PS: Так что 64 потока - два шт. OMAP-L137 (в каждом 32 сериализатора) и одна (одинаковая!) программа для обоих. И обработка на мощном VLIW DSP.
А преобразовать число импульсов ШИМ из каждого канала в аналоговое значение сигнала - для этого в каждом OMAP есть два PRU-ядра - они должны справиться. + в довесок ARM-ядро.

[_pv]

дык на простом GPIO не выкрутиться ?
к примеру на STM32, есть 69 тактов ( 80e6/(24*48e3) ) чтобы значение с четырех портов закинуть в память, откуда по DMA в SPI
А всякие фильтры уже на приемной стороне.

закинуть-то можно, а разбирать по каналам кто будет данные, они же "параллельно" в памяти лежат, а не "последовательно", тоже приёмная сторона? а кто там будет принимать - ТС молчит как партизан, а вдруг действительно ардуина какая-нибудь?

PS: Так что 64 потока - два шт. OMAP-L137 (в каждом 32 сериализатора) и одна (одинаковая!) программа для обоих. И обработка на мощном VLIW DSP.

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

не, достаточно одного только безмозглого FT601Q в него напрямую можно воткнуть все 64 микрофона (под два на линию L+R), клоки с неё же взять на всех, надо только поделить 66МГц на 16 для микрофонов и на 8 для захвата обоих фронтов в ФИФО, и по usb в любой фруктовый-Pi, там и usb2 хватит, просто у ft601 шина сразу 32 разряда, выйдет гораздо проще и дешевле чем один только камушек OMAP-L137.
а можно даже и ft232h + самая мелкая cpld: несколько демультиплексоров на шину 8->32, и немного логики, чтобы клоки на всех поделить как надо.

[jcxz]

поделить 66МГц на 16 для микрофонов и на 8 для захвата обоих фронтов в ФИФО, и по usb в любой фруктовый-Pi, там и usb2 хватит, просто у ft601 шина сразу 32 разряда, выйдет гораздо проще и дешевле чем один только камушек OMAP-L137.

А преобразование 64-х ШИМов в числа не нагрузит фруктового по самую нехочуху?
В OMAP массивную, но простую до безобразия работу можно равномерно размазать по нескольким ядрам. А тут....

Следует читать "из них только одно - DSP, еще два - стероидные PIC'и, и последнее - ARM, почти достигший совершеннолетия".

Для обратного преобразования ШИМ -> число кучи данных они вполне себе хороши. Собственно одно из изначальных предназначений PRUSS как раз - многочисленная, но тупая обработка потоков данных приходящих с интерфейсов (переставление байт, бит и т.п.).