After trying a lot of tutorials and manuals around the web including at least 20 solutions here on StackExchange, I don't know what to try anymore.

My goal is to write a message in the serial monitor window of the Arduino IDE from my ATMEGA328P-PU.

enter image description here

I have written the Arduino bootloader (tried 8 and 16MHz) to the ATMEGA and I use a 'blink' sketch as follows:

void setup()  {
 pinMode(9, OUTPUT);

void loop()
 digitalWrite(9, HIGH);
 digitalWrite(9, LOW);

The blinking works fine, the timing looks good, not overly fast or slow.

I connect PIN3 (PCINT17, PD1, TXD) directly to the RX on the Arduino (lower red wire) and the serial monitor responds by returning nonsense like ����������.

I have checked the baud rate. I have also tested with all other baud rates in combination with and without 8Mhz and 16MHz.

I have tested the entire setup with another ATMEGA328P-PU and using an entirely other PC. Same results.

It is not possible to upload a sketch while leaving the TXD -> RX connected, so I disconnect this cable when I upload a sketch. I have also tested with only power and TXD -> RX connected.

I have also tried a few types of resistor between the TXD and RX, one of many tutorials recommended this.

This is what I am trying: http://www.instructables.com/id/Attiny-serial-monitor-using-arduino-walkthrough/

And this is my boards.txt:


atmega328bb.name=ATmega328 (8 MHz internal clock)





  • The problem is most likely that big white component. Yes, that one. The breadboard. It has huge parasitic capacitance and will be affecting the frequency of your crystal oscillations, thus skewing your baud rate enough to break communication.
    – Majenko
    Commented Sep 19, 2016 at 15:10
  • I have tried without external oscillator..
    – Thijs
    Commented Sep 19, 2016 at 15:16
  • So you have arduino pro mini as ISP and you've connected TX pin from mega328p to pro mini RX input (which is also connected to USB->Serial TX pin). And you wonder why it returns junk data from pro mini Tx pin?
    – KIIV
    Commented Sep 19, 2016 at 15:32
  • Speaking of capacitance, I don't see any decoupling on that ATMega328 chip...
    – Majenko
    Commented Sep 19, 2016 at 15:35
  • 1
    Well, you have Arduino ISP on that arduino mini pro and if you connect output of bare chip to input of that arduino then Arduino ISP is confused and sends (possibly) some responses to its RXO pin (connected to TX Input on USB-Serial board).
    – KIIV
    Commented Sep 19, 2016 at 15:45

2 Answers 2


As you can see at image from linked instructables, they've connected TX pin from Tiny to TX pin on UNO through 220R resistor. This is extremely lousy idea as UNO and Tiny are both driving TX pins.

On the other side you've connected TX Output pin from Target CPU into RX Input of the Arduino ISP (pro mini). Arduino ISP returns some error responses from its TXO pin directly into the monitor. And it's at different speed I suppose, as default baud rate is 19200 in Arduino ISP sketch.

Also using internal 8MHz oscillator and: atmega328bb.build.f_cpu=16000000L means you are running at half speed as compiler and everything else expects. All speeds will be at half rate. Delays twice as long and so on.

Anyway, you can disconnect your USB to Serial converter and connect it directly to the target CPU. Or use two of them. Or just upload bootloader and get rid of ISP.

  • great, just wiring the FTDI to the ATMEGA gives me normal serial monitor response. it does leave me with another challenge, uploading sketches does not work.
    – Thijs
    Commented Sep 19, 2016 at 19:44

The thing is that you have 2 ATmegas for 1 uploader. You can't really remove the ATmega on the Pro Mini so I suggest removing the ATmega of an UNO and using the UNO without the ATmega to program your seperate ATmega. Tx to Rx and vice versa. 16MHz will work.

  • No change of boards is needed, it is only necessary to hold the on-board ATmega in reset, and bring the raw DTR or RTS line over to a copy of the reset circuit for the target one. However, if loading anything that uses SPI or toggles those pins it would generally be good to make sure the ISP (SPI) lines are disconnected between the two, to make sure the slave doesn't accidentally deprogram the on-board ATmega (seen that happen!) Commented Oct 7, 2016 at 21:11
  • So how's my anwser?
    – Dat Ha
    Commented Oct 7, 2016 at 21:26
  • Not very good, as you are proposing that an unnecessary purchase of different hardware be made. Commented Oct 7, 2016 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.