Verstümmelte serielle Ausgabe vom Steckbrett ATmega328 über FTDI-Breakout

Ich habe einen ATmega328P-PU auf einem Steckbrett,

und ich versuche, die serielle Kommunikation durch einen dieser bösen Jungs zum Laufen zu bringen:

Der 328P wird mit einem modifizierten Blink-Sketch geladen, der am Ende jeder Iteration nur eine Serial.print() ausführt.

int led = 13;
int count = 0;

void setup() {
  pinMode(led, OUTPUT); // initialize the digital pin as an output.
  Serial.begin(9600);
}

void loop()
{
  count++;
  for (int i = 0; i < 2; i++)
  {
    digitalWrite(led, HIGH);
    delay(150);            
    digitalWrite(led, LOW); 
    delay(150);          
  }
  delay(350);      

  Serial.print("abcdefghijklmnopqrstuvwxyz");
}

Die gute Nachricht ist, dass ich etwas bekomme , aber die schlechte Nachricht ist, dass alles verstümmelt ist.

Hier ist ein Beispiel von der Linux-Befehlszeile für das Zeug, das ich bekomme. Ich sehe auch eine ähnliche verstümmelte Ausgabe über Arduinos seriellen Monitor und Minicom:

$ (stty 9600 cs8 -parenb -cstopb;od -a )<  /dev/ttyUSB0
0000000 ack ack   `   f   ` ack   x   f ack   x   ~ ack  rs ack  rs can
0000020  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000040   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f
0000060   ` ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `
0000100  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f
0000120 ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f   ` ack   x   f
0000140 ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `  rs   f  rs   x
0000160  rs   ~  rs nul   f ack   x   f   x ack   ~   f ack   ~   ~ ack
0000200   f ack   ~   ~ ack ack   `   f   ` ack   x   f ack   x   ~ ack
0000220  rs ack  rs can  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul
0000240   f ack   x   f   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~
0000260 ack ack   `   f   ` ack   x   f ack   x   ~ ack  rs ack  rs can
0000300  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000320   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f
0000340   ` ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `
0000360  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f

Ich habe den Atmega_Board_Programmer-Sketch von Nick Gammon verwendet, um den Bootloader erfolgreich zu schreiben, insbesondere habe ich ein paar verschiedene Sicherungskonfigurationen (mit und ohne das Bit zum Teilen durch 8) ausprobiert, aber das Ergebnis ist immer dasselbe: verstümmelter Müll. Nun, eigentlich war das Blinzeln beim Teilen durch 8 super LANGSAM und offensichtlich nicht richtig.

Würde mich über Feedback oder Ideen zu möglichen Wegen freuen. Welche Einstellungen zu tweek? Ist die Schaltung sinnvoll?

BEARBEITEN / AKTUALISIEREN

Basierend auf dem Vorschlag von MarkU habe ich meine modifizierte Blink-Skizze erfolgreich auf einem Arduino Uno ausgeführt. Dadurch habe ich auch überprüft, ob das Breakout-Board FT232RL wie erwartet funktioniert. Ich bemerkte auch, dass die Blinksequenz auf dem Uno schneller zu sein schien als die gleiche Skizze, die auf meinem Steckbrett ausgeführt wurde. Hmmm...

Stellen Sie also das Steckbrett erneut auf und erhalten Sie eine verstümmelte Ausgabe. Dann habe ich an das langsamere Blinken im Vergleich zum Betrieb auf dem Uno gedacht und die Baudrate auf der Linux-Seite auf 9600 -> 4800 geändert. Hey! Es ist nicht mehr verstümmelt!

Die Skizze glaubt, dass sie bei 9600 sendet, also sieht es so aus, als wäre ich irgendwo um den Faktor 2 daneben. Hat mein Quarz 4 MHz statt 8? Ich habe keine Sicherung oder andere Einstellungen bemerkt, die das Timing um den Faktor 2 ändern würden.

Hier ist, was meiner Meinung nach das Problem ist: Ich kompiliere mit dem auf "Arduino Uno" eingestellten Zielboard, von dem ich glaube, dass dies eine konstante F_CPU = 16000000UL verwendet. Dann lade ich auf mein Steckbrett hoch, auf dem ein 8-MHz-Oszillator läuft, die Hälfte des erwarteten Werts.