I think you mean length of the calbe you mean.
for both serial and TWI cable length can be quite long (I believe TWI even longer at same voltage) but the longer the cable the lower the baudrate.
TWI’s clock signal makes it more reliable.
I agree.
It’s just a matter of choosing the right value for the pullups and shouldn’t be a problem for GPIO pins.
Great idea! and we can call it ArduPi
Getting back on my erlier idea (a while ago) about mixing the serial signals with the USB signals. TWI is open collector driven meaning the signals are normaly floating (and expected to be pulled up by external resistors) and are pulled low when active.
So I don’t see any problem in hooking up SDA and SCL to USB D+ and D-. The required pullups could be put in a small gender changer USB adapter (board).
So last night I met with an audio engineer and we brainstormed.
It’s going to need a little more fiddling, but the main concept is this:
To avoid sending serial data through a headphone there a few changes to be made.
The mechanical switch will actually be a electronic set of fets to swap the signals.
The software will by default start in slave mode. In order to enter master mode, it will send a TX signal on the MIC line. So if headphones are plugged in, then obviously there is nothing there to receive it, and send the response. Only once a slave has become initialized and reports back to the master, can serial data be sent on the L or R audio channels.
The other change we could potentially make, is that when multiplayer is not initialized, to duplicate the audio signal onto both L and R channels, so you can get sound in both headphones.
So in conclusion, a GPIO will be broken out to switch a master/slave fet toggle.
No but seriously, if we want to protect the users ears we will need to do this safe initialization.
It’s not complex, it’s elegant. I’ll draw up the schematic and you will see.
Hey @dxb as far as the two pins, are they always differential signal? So when one pin is set as an output, the other is set as an input? OR are they both output, just being cycled between on and off?
OR do each pin receive it’s own unique PWM and the resulting intersections create additional edges?
ATMLib always configures those pins as being one complementary outputs i.e. when one is low the other is high and viceversa. There is an Arduboy tones library that programs the two pins as independent outputs driven by two separate PWM capable timers so in that case the two pins change state independently from each other.
I think it will work for the purposes of single channel mono on one pin. You’ll probably want to put a series capacitor there so that you limit the current going between the pins, but that is trivial.
The challange is using this system also with the ATM lib, because they will always be inverted from each other. The edges are created from the swapping of the signals. If tied directly into the amp that is fine because the amp is expecting that. But if the signals are tied together then it won’t work. That’s what that trimpot does.
I really don’t know what I was thinking the other day… Anyway, what about adding (with a half-adder) one bit and the complement of the other and then feed the result into a DAC like @Mr.Blinky proposed?
I imagine the amp’s other input pin would have to be at the same potential as the DAC output voltage for b01.
