UART an ATMEGA328P-MMU

Keiner eine Idee oder Hinweise?

Peter schrieb:
> Keiner eine Idee oder Hinweise?

Klar!
Wenn sich zwei ATMega328P unterschiedlich verhalten, dann:
1. unterschiedlicher Schaltplan/Aufbau
2. unterschiedliches Programm drauf
3. einer/beide ist/sind defekt.

Deine uart Routinen habe ich nicht geprüft.
Bin da eher so ein Arduino Serial OOP Jünger.
Ich mag die möglichst asynchrone Verarbeitung mit FiFo und Interrupts. 
Ein bisschen Komfort darf schon sein.

Guten Morgen, denke nicht dass es am Schaltpkan liegt da das senden 
immer klappt, nur das Empfangen läuft nur einmal ab. DEr Code ist 
bereits soweit teduziert dass er nur noch auf Zeichen wartet um den 
Fehler einzugrenzen. Es scheint so als würde die Zähl Variable vom 
String nach einem Durchlauf und zurücksetzen auf null nicht mehr 
gezählt. Ich erhalte nur noch einen leeren String.

Hallo,

der Teststring ist maximal 4 Zeichen lang +  \n. Ein Überlauf ist somit 
ausgeschlossen.

Wenn ich die Routine so abändere, dass nicht das Empfangen Zeichen in 
den String geschrieben wird sondern ein Platzhalter ("Buchstabe T") So 
passt die Anzahl der Platzhalter im String. Somit wird das alles auch 
richtig Durchlaufen. Nur wenn ich dann wieder das Empfange Zeichen 
Einsetzen möchte funktioniert das nur nach einem Neustart.

Das habe ich nicht verstanden: das gezeigte Programm ist ja wohl das für 
den "Echo"-Controller - und womit läuft der "Sende"-Controller?

Gesendet wird einfach vom PC-Terminal.

Okay, dann fällt mir erstmal wenig ein. Wie sehen die Fusebytes aus beim 
DIP- und wie beim SMD-Controller?
  Aber eigentlich tendiere ich eher zu Punkt 2 vom Arduino Fanboy, woher 
sonst sollte ein leerer String kommen?

Also du fuses sing gleich. 2,7V Brown out, intern 8 Mhz.

Programme sind absolut identisch da ich nur einmal kompiliere und auf 
beider aufspiele.

Wäre ich in dieser Lage, würde ich ein ganz simples Echo-Programm für 
diesen zweifelhaften SMD-Controller schreiben: bei Buchstaben wird 
groß/klein umgeschaltet, alle anderen werden unverändert zurückgegeben. 
Darauf aufbauend in Richtung des jetzigen Programms erweitern, in der 
Hoffnung, dass ich irgendwann den Fehler festnageln kann.

Es ist ja schon nur ein ECHO Programm. Wie gesagt auf dem Bruder mit DIP 
Gehäuse geht alles super-

Was soll ich jetzt dazu sagen. Vielleicht, einen zweiten im DIP-Gehäuse 
zu kaufen?

Auch das ist bereits geschehen bzw. lag bereits im Schrank. die beide 
Kommunizieren lustig vor sich her. Langsam denke ich eine schlechte 
Charge erwischt zu haben.

> ... schlechte Charge ...

Kann sein.
Aber meine persönliche Erfahrung und auch die hier im Forum zeigen, dass 
dies mit hoher Wahrscheinlichkeit nicht der Fall ist.
  Tun Sie mir den Gefallen und schreiben&testen Sie kurz das 
beschriebene Einfachst-Echo, das dauert doch keine fünf Minuten. Und 
wenn Sie schon dabei sind, liefern Sie doch bitte noch die Fuse-Bytes, 
komplett, nicht nur zwei Bits daraus.

Mein erster Ansatz waere, den im Sekundentakt 0x30++ senden zu lassen.

Dann sollte auf dem PC 01234567... sichtbar werden.

wendelsberg

Hallo das senden im Sekunden Takt funktioniert ohne Probleme. Das 
Problem ist tatsächlich das Echo. Das funktioniert nur das erste mal und 
nach jedem Neustart jedoch bei Wiederholungen kommt nur ein leeren 
String.

Fuse:

Extended 0xFD
High 0xD6
Low 0xEL

Peter schrieb:
> Low 0xEL

Da ist doch schon der Fehler!
;-)

Ich könnte mir vorstellen, dass gleich nach dem '\n' noch ein Zeichen 
kommt, vielleicht ein '\0'. Dann wird das Echo einmal zurückgeschickt, 
aber danach besteht der String aus einem einzelnen '\0' am Anfang.

Versuch mal sowas:

1

  ...

2

  nextChar = UDR0;

3

4

  if (nextChar != '\0')

5

  {

6

    if (nextChar != '\n')

7

    {

8

      uartString1[zahler] = nextChar;

9

      zahler++;

10

    }

11

    else

12

    {

13

      uartString1[zahler] = '\0';

14

      zahler = 0;

15

      USARTsend(uartString1);

16

      uart_putc('\n');

17

      memset(uartString1,0,20);

18

    }

19

  }

20

  ...

Adam P. schrieb:
> Ich kann es mir auf die schnelle auch nicht erklären, wieso dies nur 1x
> funktionieren sollte.

Dann helfen keine theoretischen Überlegungen. Ausprobieren! Was sagt z. 
B. der Logikanalysator?

Kann es sein, dass du den R/C Oszillator als Taktquelle verwendest?

Habe mit internem 8Mhz probiert und externen beides ohne Erfolg. Ich 
wüsste auch Nicht was der SMDer anders macht als der im DIP Gehöuse.

Peter schrieb:
> Ich
> wüsste auch Nicht was der SMDer anders macht als der im DIP Gehöuse.

Du machst den größten Fehler, den man bei der Fehlersuche machen kann: 
Du triffst Annahmen.

Rechne mit allem, auch mit dem Unmöglichen.

> Ich wüsste auch Nicht was der SMDer anders macht als der im DIP Gehäuse.

Ich auch nicht. Hast du eventuell ein Funkmodul in unmittelbarer Nähe 
platziert?
Ist die Stromversorgung ganz sicher stabil? Vor allem bei einfachen 
Steck-Verbindungen ist das oft nicht der Fall.

Funk ist außer Handy nichts in der Nähe und als Spannungsversorgung 
dienen 5V vom PC USB. Den Aufbau treffe ich bei beiden MCUs. Ich prüfe 
nocheinmal den Anschluss des SMD auf der Platine. Eventuell fehlt da 
irgendein Kondensator.

Auf dem SMD-Board ist doch ein ISP-Anschluss, oder?

Ja da ist einer drauf

Fotos kann ich morgen versuchen zu machen. Der DIP Atmega läuft intern 
auf 8MHz oder 16 extern, der SMD mit 8 intern oder 8 extern. Beide mit 
9600 Baud. Wahlweise 5V oder 3,3V. Das macht jedoch keinen Unterschied.