3
\$\begingroup\$

I have a project that has an array of digital microphones whose output I would like to perform some fancy signal processing on, using a high-powered ARM micro-processor.

I like the idea of using digital microphones because I don't have to faff around with pre-amps. Anyway, each digital microphone is connected to a dedicated micro-controller that converts the PDM output to PCM.

I need to be able to get each microphone's data onto my ARM micro-processor. Let's assume at this point that everything is synchronized to give the appearance of N-channel concurrent sample and hold ADC. My current thoughts are that each microphone attached micro-controller would buffer its data to some extent and flush it over SPI when its slave select is wiggled by the master. The master would simply talk to each slave in turn.

My question is, is there a more elegant way of implementing this?

This would probably be a perfect job for a FPGA but that's a little beyond my skill level at the moment.

\$\endgroup\$
9
  • \$\begingroup\$ Are you sure SPI data rate will be sufficient for this job? Anyway, slaves with chipselect inputs will do. \$\endgroup\$
    – Eugene Sh.
    Sep 17, 2015 at 16:35
  • \$\begingroup\$ Excellent question. Some initial tests resulted in getting up to 10MHz. Throughput will be somewhat less of course. Is there a faster communication protocol I could use? \$\endgroup\$
    – Sam Delaney
    Sep 17, 2015 at 16:43
  • \$\begingroup\$ For multimedia there is something called I2S (not I2C). Never used it or read about it, but perhaps you should :) \$\endgroup\$
    – Eugene Sh.
    Sep 17, 2015 at 16:45
  • 1
    \$\begingroup\$ I2S would be a perfect fit. If you have any questions about it, I use it quite regularly in my own projects so I could help out \$\endgroup\$
    – Funkyguy
    Sep 17, 2015 at 16:56
  • 3
    \$\begingroup\$ I2S is implemented on a lot of ARM families, e.g. Cortex-M parts like STM32F2/3/4. In their case, it is implemented as an extension of SPI, and usually supports 16, 24 and 32 bit transfers. AFAIK, it's main feature is to move 'proper' audio data, where it is important to synchronise sampling to a very stable clock, to minimise jitter, which is said to be audible at CD-ish sampling rates. To that end, the clock can be a much higher frequency than the actual sample rate. So you may get several x faster than SPI, but would have to use I2S-capable devices at both ends of the transfer. \$\endgroup\$
    – gbulmer
    Sep 17, 2015 at 16:57

1 Answer 1

Reset to default
1
\$\begingroup\$

Slaves with chipselect inputs are not a bad idea. This way will cost many ports of your MCU, but if you have this resources, I recommend to stay with this idea. If you are familiar with RTOS (freertos.org is a free good option) you can implement some code like a SPI driver to share and switch the communication through all slaves. I did this in some of my projects. I called my driver "SPIShared".

By using a RTOS mutex you will protect each slave to do a complete transaction with your master. After that, the mutex is released to allow a new communication.

Observation: you can make a shared SPI even though each has a different slave standard. Before each transaction you will need reinitialize your SPI peripherical with the slave communication standard.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.