Digital mic sharing on two MCUs

John Speth wrote on 7/31/2017 2:34 PM:

The oring of the clocks will *not* work. I don't know how you would slave the two clocks, but that would work. I had not seen a PDM interface on a mic before and have not encountered a PDM interface on an MCU. What device are you considering that would have an appropriate interface? If it can be configured so one MCU would treat the clock as an input that should work.

I'm sorry I left out some details of my or'ing idea. I was expecting that two MCUs will provide PDM clocks but only one will be toggling the clock at any time. The data line from the mic will buss to both MCU inputs.

For slaving, one MCU would generate the PDM clock (typically using an internal timer) while the other MCU would be configured to receive the PDM clock and forward the clock to the PDM decoder. That's all highly dependent on which MCUs we choose, a decision yet to be made. In typical designs, the MCU generates the clock and receives the data.

I was hoping to get an answer like "We do that all the time" or "Try this better way". Both ideas should work in theory.

Thanks - JJS

You could use an FPGA to implement the CODEC yourself and use I2S, SPI, I2C, etc to send the data to the two MCUs. Or have one MCU receive the data from the mic and use I2S, SPI, I2C, etc to send binary samples from the CODEC to the other MCU.

How about this: one mcu generates the clock for the mic AND the other mcu (I'd suggest all

A simple 2:1 mux switches the DATA stream from the mic to mcu A or B. The unselected channel, receiving only 0's on each clock edge (using pulldown resistors), quickly falls silent...

Or, more simply, feed clock and data to both mcus, and just tell each mcu in turn to ignore the input and go do something else. Turn off the ISR, go sit in a do-nothing loop for awhile, that kind of thing.

He's worried about the BOM cost of a ten-cent microphone. How does that leave room for an FPGA?

I assume the microphone isn't the only component in the mix. FPGAs cost about the same as MCUs. Horses for courses.

Without knowing more of the intended MCU, I would have thought use one MCU to decode the PDM stream and send the data to the other MCU, perhaps using a conventional I2S, I2C or SPI interface.