EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Digital mic sharing on two MCUs

Started by John Speth July 31, 2017
Hi there-

I have a design inquiry that involves interfacing a pair of digital MEMs 
PDM microphones to two different MCU's (one for wake word processing and 
another for speech processing after waking).  Such a design would 
reasonably require two clock sources to the mic.

Does anybody know what design strategies exist so that PDM mics can be 
shared among different downstream audio processors?

I'm thinking that either a logical or of active MCU clock outputs or 
slaving one MCU clock to the other would do the job.  I certainly don't 
want to add mics due to unnecessary BOM costs.

Thanks - John
John Speth wrote on 7/31/2017 2:34 PM:
> Hi there- > > I have a design inquiry that involves interfacing a pair of digital MEMs PDM > microphones to two different MCU's (one for wake word processing and another > for speech processing after waking). Such a design would reasonably require > two clock sources to the mic. > > Does anybody know what design strategies exist so that PDM mics can be > shared among different downstream audio processors? > > I'm thinking that either a logical or of active MCU clock outputs or slaving > one MCU clock to the other would do the job. I certainly don't want to add > mics due to unnecessary BOM costs.
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. -- Rick C
On 8/1/2017 7:48 AM, rickman wrote:
> John Speth wrote on 7/31/2017 2:34 PM: >> Hi there- >> >> I have a design inquiry that involves interfacing a pair of digital >> MEMs PDM >> microphones to two different MCU's (one for wake word processing and >> another >> for speech processing after waking). Such a design would reasonably >> require >> two clock sources to the mic. >> >> Does anybody know what design strategies exist so that PDM mics can be >> shared among different downstream audio processors? >> >> I'm thinking that either a logical or of active MCU clock outputs or >> slaving >> one MCU clock to the other would do the job. I certainly don't want >> to add >> mics due to unnecessary BOM costs. > > 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
John Speth wrote on 8/1/2017 12:28 PM:
> On 8/1/2017 7:48 AM, rickman wrote: >> John Speth wrote on 7/31/2017 2:34 PM: >>> Hi there- >>> >>> I have a design inquiry that involves interfacing a pair of digital MEMs PDM >>> microphones to two different MCU's (one for wake word processing and another >>> for speech processing after waking). Such a design would reasonably require >>> two clock sources to the mic. >>> >>> Does anybody know what design strategies exist so that PDM mics can be >>> shared among different downstream audio processors? >>> >>> I'm thinking that either a logical or of active MCU clock outputs or slaving >>> one MCU clock to the other would do the job. I certainly don't want to add >>> mics due to unnecessary BOM costs. >> >> 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.
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. -- Rick C
In article <olqa80$1nfh$1@gioia.aioe.org>, johnspeth@yahoo.com says...

[snip]

> 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.
How about this: one mcu generates the clock for the mic AND the other mcu (I'd suggest all 3 receive an external clock). 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.
On Tue, 01 Aug 2017 12:54:53 -0400, rickman wrote:

> John Speth wrote on 8/1/2017 12:28 PM: >> On 8/1/2017 7:48 AM, rickman wrote: >>> John Speth wrote on 7/31/2017 2:34 PM: >>>> Hi there- >>>> >>>> I have a design inquiry that involves interfacing a pair of digital >>>> MEMs PDM microphones to two different MCU's (one for wake word >>>> processing and another for speech processing after waking). Such a >>>> design would reasonably require two clock sources to the mic. >>>> >>>> Does anybody know what design strategies exist so that PDM mics can >>>> be shared among different downstream audio processors? >>>> >>>> I'm thinking that either a logical or of active MCU clock outputs or >>>> slaving one MCU clock to the other would do the job. I certainly >>>> don't want to add mics due to unnecessary BOM costs. >>> >>> 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. > > 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.
He's worried about the BOM cost of a ten-cent microphone. How does that leave room for an FPGA? -- www.wescottdesign.com
Tim Wescott wrote on 8/6/2017 2:50 PM:
> On Tue, 01 Aug 2017 12:54:53 -0400, rickman wrote: > >> John Speth wrote on 8/1/2017 12:28 PM: >>> On 8/1/2017 7:48 AM, rickman wrote: >>>> John Speth wrote on 7/31/2017 2:34 PM: >>>>> Hi there- >>>>> >>>>> I have a design inquiry that involves interfacing a pair of digital >>>>> MEMs PDM microphones to two different MCU's (one for wake word >>>>> processing and another for speech processing after waking). Such a >>>>> design would reasonably require two clock sources to the mic. >>>>> >>>>> Does anybody know what design strategies exist so that PDM mics can >>>>> be shared among different downstream audio processors? >>>>> >>>>> I'm thinking that either a logical or of active MCU clock outputs or >>>>> slaving one MCU clock to the other would do the job. I certainly >>>>> don't want to add mics due to unnecessary BOM costs. >>>> >>>> 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. >> >> 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. > > 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. -- Rick C
On 01/08/2017 15:48, rickman wrote:
> John Speth wrote on 7/31/2017 2:34 PM: >> Hi there- >> >> I have a design inquiry that involves interfacing a pair of digital >> MEMs PDM >> microphones to two different MCU's (one for wake word processing and >> another >> for speech processing after waking). Such a design would reasonably >> require >> two clock sources to the mic. >> >> Does anybody know what design strategies exist so that PDM mics can be >> shared among different downstream audio processors? >> >> I'm thinking that either a logical or of active MCU clock outputs or >> slaving >> one MCU clock to the other would do the job. I certainly don't want >> to add >> mics due to unnecessary BOM costs. > > 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.
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. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk

Memfault Beyond the Launch