I've started to find myself migrating away form using 'duinos in favor of bare chips to minimize space requirements on finished projects.
I have no issues burning bootloaders or programming controllers with sketches over ICSP pins.
However, I am having issues with programming a running '328 with an Adafruit FTDI cable. This is my first attempt at re-programming over such a cable.
Info: The serial monitor over the cable works JUST FINE. I can use it to monitor data.
When I tried to make some tweaks to my sketch and upload, it gets the error, out of sync message.
Specifically "avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xcc", but the resp changes every time.
I DO have the drivers downloaded, and again the Serial Monitor works over the same cable.
I use the exact same settings (except changing the port) and upload via programmer with my programmer Uno, and it works fine.
I have the '328 setup with using the internal 8mhz oscillator.
Pic attached of the setup between the FTDI headers and the '328.
The '328 runs the program on the PCB just fine, only issue is when I want to program.
Try connecting a USB hub between the computer and FTDI cable.
I don't have a USB hub per se, but my laptop is docked, so I used one of the USB ports on the docking station with the same/similar results. Every "resp" was different this time:
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x60
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x86
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x06
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x60
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x4c
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xcc
An error occurred while uploading the sketch
You didn't give us all the details, such as what bootloader you are using. For the internal oscillator, I have had better luck with ATmegaBOOT_168_pro_8MHz.hex instead of Optiboot. I'm not sure if there is a science behind that, just my observation. I think it's sometimes hard to get serial to work well with the internal oscillator. But since you mention it works fine over the serial monitor, I guess I'm still just suspecting you may need a USB 2 hub, because I have that problem with my computer. I have to use a USB hub when uploading via FTDI, but not when just using the serial monitor.
Have you verified that when you open the serial monitor the MCU restarts? It should. You could upload via ICSP the blink sketch and observe the blinking pattern as you open the serial monitor, to check. Another thing to check is are you sure the bootloader is running? Optiboot has that 3 flashes of pin 13 LED at the beginning of bootloader, and some other bootloaders do a similar thing. I'm not sure about ATmegaBOOT_168_pro_8MHz.hex, I just don't remember if there is a similar indicator.
I don't know what the resp numbers mean or if that's important.
Do you know you are using the correct baud rate with avrdude that matches your bootloader baud rate?
You can try uploading to your Uno using the FTDI cable. If you cut the RESET-EN trace on the Uno, and send the DTR signal through a 0.1uF capacitor to the reset pin, it should upload fine. If it does, that would prove your FTDI works for uploading.
Well, looks like it was a bootloader issue.
I was using the "non P" version chip, so I grabbed a "P" version, loaded up the Arduino recommended bootloader, and proceeded to program the '328P over my FTDI cable w/o issue.
I was using the MiniCore bootloader on the prior chip (supports the non-P version '328).
So to check my work, I went back to the old plain '328, loaded the bootloader ONLY, and put it in the circuit. I was then ABLE to program it over the FTDI cable.
Maybe the MiniCore was wiping out the bootloader when loading the sketch over ICSP even with bootloader option enabled?
Not sure.
Yes. If you load a sketch via ICSP it erases the chip and loads the sketch, so you don't have a bootloader anymore. If you load a sketch via FTDI, it does not disturb the bootloader.
Learn something new every day 
So if I wanted to drop raw chips onto a board prior to soldering (thinking SMD version '328 et al), I would have to include both ICSP points AND FTDI points if I want to be able to re-program them in circuit later.
Or just get a clam-shell adapter for the SMD variants, burn the bootloader, then solder them on with only FTDI headers...
I would recommend just ICSP points and just load the sketch via ICSP. You don't need to load new programs via a bootloader. Just load the sketch with a programmer. Since setting the fuses is part of the burn bootloader function of the IDE, you can burn the bootloader once, and then load the sketch in various versions or updates as often as you like.
Can you use serial monitor over ICSP pins though?
Only if you use software serial, so it would have limitations. So, it depends on what you want to use serial monitor for and whether you would want to fool around with software serial.
I guess the pinout strategy will just have to flow with the project.
Some things like my engine controllers I need full ability to monitor data and re-program, some others I don't.
