Not wasted I think, just cut the 5v line from the FTDI chip to the rest of the board and isolate the AVR TX signal. Also adding a connection as dc42 suggested is good if you want to detect the USB plug in.

They wouldn't be connected together to begin with, the FTDI would get its power from the USB bus, not the rest of the circuit.  As I mentioned, I only need it when the controller needs reprogramming, so I don't need it to remain powered up the whole time.  So I think I can get away with that, use the FTDI in a USB Powered Configuration, with a common ground shared with the rest of the circuit, which is powered by a separate 5V supply.

Should I be adding diodes on all three signal lines (TX, RX, DTR) between the FTDI chip and the Atmel to prevent the Atmel back feeding power back into the FTDI?

And what about using the FTDI's 3V3OUT pin connected to one of the Atmel's analog pins as a way to detect when a USB cable's been plugged in?  Since the FTDI only powers up when the USB cable gets plugged in, the 3V3OUT pin would only go high when it does.  So technically I should be able to read the analog pin and figure out if it's zero (OFF) or higher (ON).

OK, so you want to make it easily reprogrammable by the end user, in which case ICSP isn't suitable. Some suggestions:

1. If you base your hardware around the new Arduino Leonardo design, you can avoid the FTDI chip. See for example http://txapuzas.blogspot.com/2009/12/paperduino-leonardo-clon-de-arduino.html.

Ah yes, using an Atmel with built-in USB, sure that's an option too.

2. To detect whether USB is connected, just connect a 1K pulldown from USB +5v to ground and a 100K resistor from USB +5v to a digital input pin. This assumes that you will not actually use USB power when programming (i.e. the device will still be self-powered).

This is still based on the above, right?

Certainly something to think about.  Of course now I've invested some time on designing the FTDI circuit, but that's what this forum is about.  Coming up with clever ideas that are both functional as well as cheaper perhaps.

Thanks!

You forgot one very crucial detail about the LilyPad: input voltage.  It's limited to 5.5V.  It does not have an on-board regulator like the other full fledged Arduino boards.  LilyPad is designed to be used with 3.7V LiPo batteries, and you need to mate it with the LiPower module which has a DC-DC Step-Up on it to bring that voltage up to 5V.  Or find another way to feed it between 2.7V to 5.5V ... but don't go past that if you plan on actually using it, as opposed to watching it go up in smoke.

[I am not discounting any of the suggestions given.]

It look like you are using the FTDI breakout board ? Right ?  I did experiments using that small board. The program a ATMega chip, you need 3 signal. The Rx, Tx and Dtr <-- for the auto-reset - hope I am right ?

That was the original idea, however I have moved away from that now.  At this point, the design has an FTDI in the circuit so all I would need is just the USB cable.  Don't need the breakout board on it anymore.

My suggestion: a three-pin header on a 0.1" spacing with a two pin shunt to jumper two pins at a time. When the time comes to program the thing via FTDI, switch the shunt over to 'program' mode and hence disable access to the PSU power. When in standalone mode, move the shunt back. The center pin provides power to the board, the two outside pins are connected to USB and PSU 5V, respectively. Takes very little room, dirt simple, works every time.

While you might be able to get away with having the computer provide power while the PSU does also, think of all things that might happen if PSU power starts to creep into your computer. Not worth the risk, no matter how cheap the attached CPU.

I contemplated that solution early on, even before I started this thread.  Because of the final product being a sealed box, this wouldn't work because there would be no way of getting to that header.  And while connecting a switch to those headers which then sticks out of the box would solve that, I'm also trying to keep the final product simple and elegant.  I know, functionality versus design ... tough line to cross sometimes.

As for power creeping back in, I believe a diode would take care of that.  Yes?

Do you actually need the FTDI chip for anything other than reprogramming? If you don't, then it's simpler to do away with the bootloader and FTDI chip, and include a 6-pin ICSP header on your board for reprogramming instead.

That's certainly another possibility.  However, this now requires the end user to know how to do that.

See, I always try to put myself in my daughter's shoes, or even my old man's.  What would happen if I gave them an instruction sheet and told them to go reprogram the thing?  Well, my daughter would start with, 'does this plug thingie go in this way, or that way?  where is "A-r-d-u-i-n-o-S-P-I" ?  I have to click upload again, wait, what code?'  Now, my old man can possibly go through the motions, able to fire up the IDE, configure it in SPI mode, load the new code file that I sent him, and hit the upload button ... But again, it would require extra hardware to make that work.  (At least, that's the only way I know of making that work through SPI.)

Whereas, if I include the FTDI chip in the circuit, all he would need is a standard USB cable, hell I can use the same Type B connector on the board, and tell him to use his printer cable.  No extra hardware needed, just plug and play ... in a sense.

Now, please note, I am not discounting any of the suggestions given.  They all are good and they all have their place.  I have to pick and choose which works best for what I'm trying to achieve.  With that in mind, I've decided including the FTDI chip in a USB powered mode is the best way to go.  When the USB cable isn't connected, the FTDI chip isn't powered.  I don't need it anyway - at least, I haven't found a need to use the 3V3 pin on it yet, and I doubt I will (so it's decoupled for now.)  This way, the rest of the circuit, the Atmel and LED strips, can function normally using the external 5V PSU and when I plug the USB cable in, it powers up the FTDI chip, I can upload code, disconnect the cable and go on my merry way.

What I would like to figure out is, if there is a way to tell the Atmel when a USB cable has been plugged in (like, as soon as it detects that the FTDI chip is powered up, turn the LED strips off for example.)  Not sure how to do that.  Can I use the 3V3 line from the FTDI chip as a sense input on the Atmel?  Do any of the other pins on the FTDI chip go HIGH when it's powered up?  Dunno, haven't thoroughly read the datasheet yet ...

Almost the same ... choose your poison.  Oh, I added the three variants in mine, 6mm, 8.6mm, and 11mm.  The land pattern is exactly the same, it's the silk screen that's larger for the 11mm.  The 6mm and 8.6mm are identical.

I just woke up ... got a good 10 hours of sleep at least.  Now to try and catch up.

So what happens when you've been running the whole day only 3 hours of sleep because yesterday you worked for 22 hours straight?  Yup, I fell asleep, sitting here, staring at my screen.  I can't guarantee the attached is 100% accurate.  For certain, the 3524 isn't ... datasheet shows pins 1, 2, 3, 4 in the schematic, but the package drawing shows pads 1, 2, 3, and 10 ....  So I don't know if you're supposed to connect pin 4 to pad 10, so I lef tit unconnected, which means you can't use the schematic part because of that unconnected pad.  But the 3523 should be fine.  WTF is the tip switch for anyway?!

Yeah, gimme minute, I can draw it out (if he doesn't beat me to the punch.)

Don't know of a symbol off of the top of my head, but then, those datasheets you linked has everything in it you need to create your own.  Are you not able to do that with the measurements provided, or are you trying to avoid re-inventing the wheel if a package already exists?  I can probably whip them up if you want.

If the LED goes through the hole, or just the leads, that would be on the other side, where you can mount the rest of the circuitry.  So you can either make a 3mm or 5mm (LED depending) hole and stick the LED through, OR two 1mm (or smaller) holes right next to each other, and shove the leads through to the other side of the leather.

So really I should be using the schematic for USB Bus Powered Configuration, where the FTDI chip is only powered by the USB bus when that gets plugged in.  Once removed, that should also kill the FTDI (with the addition of Nomad's suggestion of isolating the TX line, so the uController doesn't end up feeding power back into it.

I don't need the FTDI to be powered for anything other than when the uController needs to be reprogrammed, so feeding it 5V from the rest of the circuit seems like a waste to me.  So I'm thinking as long as there is a common ground along both "areas", with the FTDI only getting powered when a USB cable is plugged in, everything should work.

Hey Chris, looking at your circuit, I noticed you left CTS unconnected.  Shouldn't that be connected to ground?  I only ask because I have an actual FTDI board from SparkFun and they have the CTS signal grounded.  Datasheet simply says clear to send control input / handshake signal.  So I'm not sure if it really matters.  Thought I'd ask anyway.

Here's another question: with an FTDI chip in the circuit, is there a way to tell the micro controller when a USB cable has been plugged in?  Before anything is even transmitted through.  Plug the cable in, and the controller knows it's there ... is that possible?

Oh first, Techone, I didn't mean to completely discount your suggestions.  They are all viable solutions, just not for this particular setup.  And while the RS232 is possible, not in this particular setup.  There's no room.  There's barely 7mm of height clearance, and 1.2mm of that will be taken up by the board itself.  And almost no computer comes with an RS232 port anymore.   Sure, I can buy a USB to RS232 cable ... but why, when I can design a complete USB solution ...

As for Chris' idea, the FTDI chip doesn't need to be constantly powered, only when the USB cable is connected to program the controller.  So I don't think connecting it to the circuit's 5V is necessary.

I know how to do that Chris, that's not what my question is.  Assume it's already in the circuit (or not, doesn't matter), the question is whether it's safe to have the circuit powered with a 5V power supply, driving everything, including the controller, while also having a USB cable plugged in to the controller to reprogram it.  What safeguards should I be taking to do that, to avoid the USB getting blown, or anything else for that matter.