I figured you might ask that.

Because some of the things I'm testing and debugging are timing sensitive and are based on tweaking code behaviors that occur when the empeg power is initially applied. Under normal runtime (without the USB cable) the BGE module gets its power at EXACTLY the same time as the empeg does, and I need to test and adjust behaviors at those times. In fact, some of the code changes that I just checked in a few minutes ago are related to that very situation. In real life, I don't have the time to go trundling back to the trunk to plug and unplug that goddamn molex connector each time I want to test that.

Also, since the power is carried on the same molex connector as the I2S audio, if I had to do my debugging with it unplugged, then I wouldn't be able to debug any of the audio behaviors. Not to mention that questions like "am I frying my chip" are a lot harder to answer. The fact that I was listening to the audio when testing the changes to the I2S voltage dividers is what saved that last chip. Without the capability to connect I2S+Power and USB at the same time, I might have fried the chip, since I was trying to monitor bootup messages at the same time.


There is one interesting trick I have to do, which is that if the Arduino is already powered by the empeg over that molex connector, and then after that I plug in the USB cable, the computer doesn't detect the USB-serial device. This happens with either Macs or PCs. So I have to do an interesting little dance if I want to debug startup timing. I have to plug in the USB cable first, let the computer detect the USB port, then press the button that launches the Arduino Serial Monitor. The act of launching the serial monitor resets the Arduino chip which in turn resets the BlueGiga chip (via a software reset command). If I press that serial monitor at the same time that I apply power to the empeg, then the timing of the empeg bootup in relation to the BGE assembly bootup is very close to the same as the timing of applying all power to everything at once. It's a bit of a silly dance, but necessary for some of the stuff I've had to debug.



Thanks for that warning, that's worth being concerned about.

However, as log as I'm powering it from VIN on the Arduino, I haven't had a problem with it, at least not yet so far. Not sure if that's just because I've been lucky or if it's because the Arduino circuitry is cleverly designed for precisely this kind of situation. The fact that the computer doesn't detect the USB-serial port unless I plug it in first makes me wonder if it's because of the latter.

Thanks!

PS: New code is available at GitHub. Implements the feature where there is a global variable that keeps track of whether or not the Bluetooth is connected and streaming. Also, since the 3.3v design doesn't require the resetline pin 51 trick, I've removed that code too. If it turns out that we need that code again, we can pull it from the code history in GitHub.