The internal speaker and 3.5mm audio jack require a driver. The easiest solution here is to use what they call an "Audio Codec" IC, that are used in mobile phones. They have drivers for internal and external audio sources, and often also allow termination of an external microphone, e.g., for 3.5mm audio headset.
1. Requirements Analysis
There is only one requirement we have to address here:
Requirement 3.2.1: Audio CODEC or equivalent that has output channels for loud speaker (mono is ok), 3.5mm audio output (stereo) ear piece, and input channel for 3.5mm microphone.
Implied in this, is that it supports I2S or similar audio interface, so that we can have the MEGAphone's FPGA drive it using the existing audio infrastructure that we have there.
2. Key Component Selection
We can use something like this: https://www.ti.com/product/TAC5112
I've previously used the ALC5616, but they seem to be end of life (EOL) now.
What I'd really like, is one that has a speaker amplifier built in, so that I don't need a separate component for that. The alternative option is to not have a 3.5mm jack, and only support bluetooth for external microphone and headset.
This looks like an option:
This one has two class-D 1.29W speaker drivers for stereo internal audio, as well as stereo line-drivers for 3.5mm line out jack, and also an analog microphone input line. In short, this can drive both the internal speakers, as well as the 3.5mm audio jack. It also supports I2S for the digital side of the audio.That's more than enough to get us out of trouble for the current stage -- Bluetooth can wait until the time-critical period is over.
3. Schematic Layout
Further in the datasheet in sections 8 -- 10 we find a typical schematic:
The suggested layout is interesting, too:
Our module system effectively provides a means of separation of the analog and digital grounds, with just a single point of connection. Pleasingly, this all looks like it needs relatively few passives.
What I am considering, is whether I put the 3.5mm jack on this module, or whether it should be mounted on the main board. I really want to keep as few components as possible on the main board, partly so that I can easily update it as I go along.
This does mean that I need a way to have one of my modules that has one edge that can be aligned to the edge of the carrier board. I'll need this, in any case for various other modules, such as those carrying the SIM card and SD card, or thumb-wheel potentiometers. So I'll need to tackle that anyway -- so we might as well put the 3.5mm audio jack on the module with the audio codec IC.
Okay, so I'm going through the schematic now. One thing I've just noticed that is mildly annoying, is that the device requires a 1.8V supply, as well as whatever the IO voltage is (most likely 3.3V to match the rest of the system), and VBAT for powering the speaker amplifiers. The 3.3V and VBAT I had counted on, but 1.8V is going to require a 2nd DC:DC converter. I'm going to see how much current the 1.8V supply needs. It might be simpler and acceptable to use a linear regulator to derive the 1.8V from the 3.3V -- but only if it won't cause too much heat / wasted power.
Also, ideally the power rails should come up in a particular order. We're going to take the minor liberty of powering them up effectively simultaneously. The datasheet does say that it has been designed to be tolerant of power sequencing, so given that our power supplies should come on fairly simultaneously -- with the exception of VBAT which remains on at all times, unless I make that switchable for this module -- we should be okay.
Now, back to that 1.8V power rail, having read through the datasheet I can't find a clear indication of the total power consumption. It talks about the power requirements for various blocks, but doesn't have a convenient "maximum power consumption" line anywhere that I can find. So I'm probably going to have to assume the worst, that it could be ~250mA.
Probably something like a ADP5301ACBZ-1-R7 is a good option for this. It's a buck converter, so will be much more efficient than a linear regulator. And any noise will be on the digital 3.3V rail, rather than the VBAT analog rail. It's fairly easy to setup, and can be set to 1.8V using a single resistor:
The PWM/Hysteresis mode of this regulator selects between a more efficient (hysteresis) mode, but is limited to 50mA, or a less efficient PWM mode, which can supply up to 500mA. This is a bit annoying, as depending on my reading of the CODEC datasheet, the draw on the 1.8V rail is either about 30mW max, or about 150mW max -- i.e., spanning the two modes ranges. The PWM mode can do both, but is particularly inefficient at lower current draw levels.
I think the best solution here is to connect the SYNC/MODE pin to GPIO1 of the CODEC, and then we can talk to the CODEC, and switch modes based on how we configure it... except that the GPIO1 pin is not, despite it's name, actually a GPIO. DOUT can be configured as a GPIO, though... which sounds a bit odd. Perhaps the datasheet is wrong?
Here's the register description for controlling DOUT:
Nope, looking through the rest of the datasheet, it really looks like GPIO1 is really just a Multi-Purpose Pin, rather than a true GPIO. So all we can do is connect the PWM/Hysteresis pin to either a pad on the module, to allow the board to select it elsewhere, or just strap it to PWM, and accept the efficiency loss. Given that the efficiency at 20mA draw should still be ~70%, that's probably the most sensible option. I'll do that using a 100K pull-up, and expose the mode pin on a pad of the module, so that it can be controlled externally, if desired.
Okay, so with the 1.8V rail solved, I can go back to the rest of the schematic layout...
I've now got it mostly set out, except for the module outline. A quick count suggests that I'll need 20 signals visible on external pads, so a 2x11 with one key pin feels like it should do the trick. What I don't yet know, is whether the existing format of that module will fit all the components in the available cut-out area. So it's probably a case of adding the module footprint, and then trying to fit everything into the area. I don't yet have a strong sense of whether this module will need to be 4 layer or not.
Well, the initial scale of the module to the CODEC IC gives me a bit of hope -- but there are a bunch of passives, and also that 1.8V regulator to be added yet:
4. Passive Component Selection
Okay, so to go to the next step, I need all the passives, so that I can work out if it really will all fit in a sensible way.
I can't find any restrictions on capacitor types or particular voltage requirements for the codec. The 1.8V regulator does provide specific guidance in their example layout, which I'll follow.
A quick hunt through Digikey found suitable passives, almost all of which are 0603, which gives me hope.
2.1K 0603 Resistor - RMCF0603FT2K10
100K 0603 Resistor - ERJ-3EKF1003V
19.6K 0603 Resistor - ERJ-3EKF1962V
0.1uF 0603 Capacitor - 0603B104K500XD (X7R, 50V)
10uF 0603 Capacitor - CL10A106MP8NNNC (X5R, 10V)
22uF 0603 Capacitor - CL10A226MP8NUNE (X5R, 10V)
47uF 0603 Capacitor - GRM188R60J476ME15D (X5R, 6.3V)
2.2uH 0805 Inductor - WCLA2012V1-222-R
5. PCB Layout
Okay, so I have managed to lay it out with just 2 layers, which is great... except I realised right at the end that I hadn't flipped the module footprint to the rear, which is what you have to do if you want the components to go on in the cut-out in the module recepticle.
It shouldn't be too hard to flip it, but I will have to switch the pin assignments from left to right, and vice-versa -- which means that the pin that is opposite the key pin will have to be re-routed. I hope I won't have to do much to sort that out. It's only the GPIO1 pin, which I can see will be easy to sort out.
Oh, except that I also have to re-route the VBAT and GND pins. GND is easy, but VBAT might cause me some problems. Well, unexpectedly the routing ended up being simpler.
This is what the board looks like now:
As usual, I've added the values for all parts, so that if field repair is required, it can be done.
6. Requirements Verification
Here's our requirement again:
Requirement 3.2.1: Audio CODEC or equivalent that has output channels for loud speaker (mono is ok), 3.5mm audio output (stereo) ear piece, and input channel for 3.5mm microphone.
We have stereo internal speaker outputs, as well as headset output and input for microphone, so we have everything we need.
7. Milestone Mapping
Together with the blog post detailing the MEMS Microphone module, this satisfies:
2.5.2 Internal microphone and speaker module : Schematic
2.5.3 Internal microphone and speaker module :PCB Layout
The source is, as usual here: https://github.com/gardners/megaphone-r5-modular/tree/main/modules
No comments:
Post a Comment