The names are arbitrary but I think they should continue be referenced as Speaker 1 and Speaker 2 to match the BeepPin1 and BeepPin2 classes. For now, I’m calling the DAC connection Speaker DAC.
Speaker 1 and Speaker 2 should go on opposite speaker terminals so you can get the higher volume by complimenting the two outputs, and to match the existing Arduboy wiring. (That’s why it’s good to have at least one timer common to both pins but with a different WOx for each, to allow making use of the ability to invert one WO.) For normal volume you leave one pin low while generating the sound on the other. For mixing two digital sounds you just play a different sound on each pin.
The values for the resistors and capacitor in the diagram are subject to change.
To use the DAC, you set Speaker DAC as an output and Speaker 1 as an output and hold it low. You set Speaker 2 as an input so it’s high impedance and thus doesn’t interfere with anything. (Likewise, when the DAC isn’t being used Speaker DAC must be set as an input and Speaker 2 as an output.)
You can also mix a digital sound with the DAC output by playing that digital sound on Speaker 1 instead of holding it low.
Using the two resistors as a mixer or volume control is something that would have to be experimented with. It would depend on the value of the resistors and the impedance of the speaker. We would also have to keep in mind that setting Speaker 2 and Speaker DAC both as outputs would “waste” power through the resistors whenever the these two pins weren’t at the same voltage.
Another thing to consider is that the way the Arduboy 2 library handles muting of the sound when you use the audio.off() and audio.on() functions is it sets both pins as inputs. The BeepPin classes rely on this. From the library’s BeepPin documentation:
Although there’s no specific code to handle mute control, the
Arduboy2Audio class will work since it has code to mute sound by setting the speaker pins to input mode and unmute by setting the pins as outputs. The
BeepPin1 class doesn’t interfere with this operation.
With this new circuitry, the Arduboy2Audio function will have to make sure that Speaker DAC pin is also set as an input, in order for the mute functionality to work properly. It actually gets complicated because when you unmute, (along with Speaker 1,) you only want to set either Speaker 2 or Speaker DAC as an output, not both (for the “lower volume” and “wasted power” reason described above). I don’t know how you would determine which of the two to set as an output. Perhaps:
- Save the unmuted state of the pins in EEPROM before muting, and restore to unmute?
- Maybe we need the capability to mute/unmute the DAC separately from the existing digital mute?
- Maybe we can get away with only setting Speaker 1 to input mode and not touch Speaker 2 and Speaker DAC? The Arduboy2 bootPins() function would set Speaker 2 to output and Speaker DAC to input. Anything wanting to use the DAC would first have to set Speaker 2 to input and Speaker DAC to output. If this works properly, it’s probably the best solution.
Note that some (all?) of the additional audio libraries targeted towards the Arduboy handle muting properly, by querying the state maintained by the Arduboy2 audio class and actually ceasing to generate sound. They don’t rely on the audio class controlling the input/output state of the pins (but it doesn’t affect them).
Not really. In fact, the Arduboy as shipped doesn’t have a cap at position C12. It has a 220 ohm resistor. (Why a resistor instead of a zero ohm resistor/jumper, and why 220 ohms? I’m not sure. I’ve never asked or seen a reason.)
However, for piezo speakers its usually recommended that you don’t impose a DC voltage on them. Without a cap, this is what happens when generating sounds using only one pin because one pin will always be positive (or at zero volts) with respect to the other.
The reason for not putting DC on a piezo isn’t because it could cause damage (as long as you stay within the maximum voltage rating). It’s because DC will constantly deform the speaker in one direction, thus lowering the volume/efficiency. At the low voltage that we’re running the speaker at it probably doesn’t make much of a difference, though. (It’s another thing that could be determined by experimentation.)
One more thing:
The I/O pin outputs of the SAMD21 have nowhere near the 40mA sink/source current capability of the ATmega32U4. SAMD21 outputs can be set for 2 modes; low drive strength and high drive strength. At 3.3V, the low strength (which is the default) is specified to be able to source 2mA and sink 3mA. High strength is specified to source/sink 7mA/10mA. The reason to have a low drive strength is to produce slower rise and fall slew rates, thus reducing electrical noise emmisions.
For the speaker, we likely want to set the outputs for high drive strength. (The same may be true for driving LEDs)