Debugging with ICSP programmer?

I typically prototype a project on the arduino uno and when it is working, I solder it up on perf board and do any further programming through ICSP connection. This works pretty well, but because of my limited understanding, I lose the ability to see debug info through serial output when I go to this second method. I think it is because I don't know how to access the data that might be sent out through the MISO / pin 18 to the computer (if that is even how I should do it?!?). Probably very simple but still beyond me. Can anyone direct me to any tutorials that show how to do this, or is this the price I pay for going from the Uno to the stand alone atmega328P?


You could unplug the 328 on the Arduino.
Add a wires form RX, TX, Reset and 0 Volts from the perf board to the
RX, TX, Rreset and 0 Volts on the Arduino.

Most definitely not something that needs to be given up. For most projects that I move to a standalone board, I include both an ICSP header and an FTDI header. Connect an FTDI cable or use one of these to connect the µC to the serial monitor or any other serial terminal program. If the µC has a bootloader, then it can continue to be programmed over the serial FTDI interface as well. Typical schematic attached.

Edit: Note the µC in the schematic is a surface-mount part, so pin numbers are different if you're using the DIP. Go by the pin names.

I add an FTDI header in my projects as well for serial port debugging.

I have used FTDI Basic, FTDI Breakout Board with 6-pin adapter cable, this FTDI module from with 6-pin adapter cable
(at $11 I believe it is the least expensive FTDI module around outside of e-bay)
and also easy to build onto a board, like this protoboard

and CP2102 modules from e-bay with RESET trace to header cut and wired to DTR pin instead (needs different driver).

Thank you all.
LarryD: Yes, I could use the uno without the chip. I was trying to avoid that because I only have two Unos and both are being used in other parts of the project. Good suggestion though!.

CrossRoads: Thank you. The link seemed to be dead, but I will try to find the board you recommended. I do have the FTDI Breakout board that I use sometimes in other projects. Just never figured out how to get that serial output from the device on the computer side. Tried sending data and then scanning all the comm ports, but did not find it. Gave up easy though because I wasn't sure that what I was doing was even plausible.

Jack: You're schematics will be VERY helpfull.

With all this, I should be able to put together a solution. Thanks again for the responses. I'm sure I will be back with more questions.


Link is not dead, I just tried it.
mikroe483 is a nice little board.

You're right. I should have waited awhile and tried again. Thanks.

CrossRoads: I ordered the board you suggested. Not sure what advantage it will have over the FTDI basic board, but I guess I will find out.

Jack: I added a FTDI header and tried using the FTDI basic board I have and when I try to upload the program, I am getting "stk_500_getsync(): not in sync: resp=0x00" I am including the schematic and the code. The differences I see in what I did and what you showed is that I don't have a reset button and don't couple through a 100nf cap. Also, you are pulling the SDA and SCL pins high through a resister (can't read value), and I am not. Could any of these differences be the cause of my problem.

I am able to program the chip through the ICSP port, but I can't see the serial output using that method.

I don't think it is important to my questions, but just FYI: This is for a remote for my robot and sends joystick data and micro adjustment data to the robot through xbee using a 10 byte packet starting with 255 and ending with 254.

#include <SoftwareSerial.h>

SoftwareSerial xBee = SoftwareSerial(2,3);

int hPin     = 0;   // Joystick Horizontal Pot data
int vPin     = 1;   // Joystick Vertical Pot data
int bumpPin  = 3;   // analog pin for bump movement
int bumpVal  = 0;   // to hold the bump direction selected.
int dir      = 0;   // bump direction  (for minor position adjustments)
int valV     = 0;   // Vertical data
int valH     = 0;   // Horizontal data
int V        = 0;   // remapped vertical data
int H        = 0;   // remapped horizontal data
int lastV    = 0;   // last V value
int lastH    = 0;   // last H value
int debugging    = 0;   // 1 if debugging, 0 if not

const int  greenLED=9; const int  yellowLED=10; const int  redLED=11; const int  whiteLED=12;   // LED lights
const int button1=5; const int button2=6; const int button3=7; const int button4=8;             // bump buttons

void setup() {
  pinMode(greenLED,OUTPUT);    pinMode(redLED,OUTPUT);  pinMode(yellowLED,OUTPUT);  pinMode(whiteLED,OUTPUT);  // LEDs
  pinMode(button1,INPUT);  pinMode(button2,INPUT);  pinMode(button3,INPUT);  pinMode(button4,INPUT);           // buttons
  if (debugging==1) 
      Serial.println("now Sending...");

void loop() {
    // check for bump button pushes
    if (debugging==1) { 
      Serial.print("bumpVal = ");
    if (bumpVal < 100) 
      dir = 0;
    else if (bumpVal < 300)
            dir = 3;
         else if (bumpVal < 500) 
                dir = 1;
              else if (bumpVal < 700)
                      dir = 4;
                   else dir = 2; 

    if (debugging==1) { 
      Serial.print("dir  = ");
    //if bump button has not been pushed, process joystick data               
    if (dir == 0) {
        if (debugging != 1) {
            // read the joy stick poteniometors
            //convert analog signal to the range 0 to 250
            sendStatus(V,H,0,0,0,0);   // Send out through xBee
    else // othewise bump in the desired direction

void bump(int d) {
    if (debugging==1) 
        Serial.println("in bump routine");

void sendStatus(byte V, byte H, byte s1, byte s2, byte s3, byte s4) {

  // this is the heart beat.  If the Rx does not recieve
  // this every cycle, it will automatically stop the motors
  int HB=5;   
  // Add up all the data and take the mod of that number divided by 250.  Send this
  // as sort of a checksum to verify that data was complete and correct.  I am using 
  // 250 as the modulo to avoid a result of 254 or 255 (and maybe 251..253 for later use)
  int CK = (V+H+s1+s2+s3+s4+HB) % 250;  
if ((V-lastV != 0) || (H-lastH != 0)) {  
  if (debugging==1) { 
    } else {

Opps. Forgot to remove the part below the resonator and mC. I didn't have the proper library for these parts, so I used similar.

Sorry about the pullup resistors on SDA and SCL, they were just part of the circuit I copied the schematic from and have nothing to do with this discussion, so no they are definitely not necessary.

You will need either the 100nF cap, which implements the auto-reset feature expected by the bootloader, and/or you will need a reset button. Without the cap, hold the reset button down and as soon as the "Binary sketch size" message appears in the IDE, let it go, and the upload should proceed. I most always include both.

Without either though, it should be possible to program the chip via ICSP and use the FTDI interface for serial I/O.

Actually I have a better schematic here, in that it is a complete Arduino clone with no additions. If I had half a brain I'd have thought of that in the first place, I can only plead temporary insanity!

Not sure what advantage it will have over the FTDI basic board

FTDI Basic does not provide a method to securely attach it to a board, and it costs $4 more.

FTDI Breakout Board would be better for securing to a board

while also costing $4 more.

The DTR 100nF cap makes programming a lot easier. If you can't get one on, be sure to breakout the Reset pin so you temporarily connect a reset switch to Gnd for serial downloading.

I will add both the 100nf and the reset switch and post results here. Thanks again.

Well, I got the same error! I think I am going to start all over again with a new piece of perf board. I think my schematic is ok once I add the switch and the 100 nf cap. I have made several mods and I might have screwed something up in the process. Now I can't even program with the ICSP interface.

Crap. I guess this ain't the fun part.

Thanks. At least I start the next phase with a little more info.

For some insight or reference:

Great link! Thanks Larry. Last time I kind of winged it and did the schematic as a diagram of what I intended to do (after the fact). This time, I will work in the correct in eagle, layout in Fritzing (good tool for strip board).

Nice thing about personal projects like this is that I am allowed to make my mistakes without worry about someone elses goals.