USART Kommunikation zwischen ATMega32 und ATMega328p

[Sascha B. (blank)]

Hallo,

Ich versuche gerade mit einem ATMega32 über TX und RX mit einem 
ATMega328p (DDS Generator) zu verbinden. An sich klappt alles, aber wenn 
ich versuche die Frequenz einzustellen bekomme ich nur ein Syntax Error 
raus. Den Code an den DDS Generator kann man nicht einsehen oder 
verändern. Über HTerm klappt alles mit dem Befehl f 1000<CR>.

Beigelegt habe ich die Befehle für den DDS Generator und mein Code mit 
den Libs.

Was Ich bereits versucht habe:
Andere Boards zu nutzen.
Im String, Hex und Bits zu übertragen.
Andere codes.

und trotzdem gibt es ein Syntax error raus.

Blank

[Adam P. (adamap)]

Sascha B. schrieb:
> Befehl f 1000<CR>

Du darfst dann natürlich nicht wirklich "f 1000<CR>" senden.
CR bedeutet "carriage return".

Versuch das mal:

"f 1000\r"

Oder laut deiner kurzen Erklärung "DDS_Zeichen.png", kannst auch das mal 
versuchen:

"f 1000\r\n"

Wobei ich eher vermute, dass diese <\r><\n> Angaben das Dokument ansich 
formatieren sollten. Somit sollte mein erster Vorschlag ausreichen.

[Sascha B. (blank)]

Habe es ausprobiert. Leider ist das der selbe Fehler mit Syntax Error

Ich habe es auch mit f 1:1000\r und \n
so wie
f 1:1000<\r><\n>
und
f 1000<\r><\n>

[Rainer W. (rawi)]

Sascha B. schrieb:
> Habe es ausprobiert. Leider ist das der selbe Fehler mit Syntax Error

Dann guck dir mit dem Logikanalysator an, was über die Schnittstelle 
läuft und vergleiche das mit der Bedienung über HTerm, statt blind im 
Nebel zu stochern ;-)

[Adam P. (adamap)]

Rainer W. schrieb:
> vergleiche das mit der Bedienung über HTerm

Was hast du denn bei HTerm eingestellt für den Versand der Daten?

[Rainer W. (rawi)]

Adam P. schrieb:
> Was hast du denn bei HTerm eingestellt für den Versand der Daten?

Das ist doch egal.
Entscheidend ist der Unterschied zwischen der Aussendung des Programms 
und der (funktionierenden) Aussendung von HTerm.

[Adam P. (adamap)]

Rainer W. schrieb:
> Das ist doch egal.

Na wenn er kein LA hat, dann kann man es evtl. so herausfinden, was 
funktioniert und welche Einstellungen er hatte.

[Sascha B. (blank)]

Bei HTerm hatte ich 8Datat 1Stop Parity-none Newline at LF

Mit dem Type ASC habe ich einfach f 1000<CR> eingegeben.

[Rainer W. (rawi)]

Adam P. schrieb:
> Na wenn er kein LA hat ...

Bevor man dann noch 1/2h in die Forschung investiert, wäre es eher 
höchste Zeit, einen zu bestellen, damit der Weihnachten noch unter dem 
Christbaum liegt ;-)
Es reicht einer für unter 10€.

[Adam P. (adamap)]

Sascha B. schrieb:
> Bei HTerm hatte ich 8Datat 1Stop Parity-none Newline at LF
>
> Mit dem Type ASC habe ich einfach f 1000<CR> eingegeben.

Dann Versuch das:

"f 1000<CR>\n"

[Sascha B. (blank)]

Adam P. schrieb:
> Sascha B. schrieb:
>> Bei HTerm hatte ich 8Datat 1Stop Parity-none Newline at LF
>>
>> Mit dem Type ASC habe ich einfach f 1000<CR> eingegeben.
>
> Dann Versuch das:
>
>

> "f 1000<CR>\n"
>

Nein hat leider auch nicht funktioniert. Kann es an was anderes liegen? 
Ich habe bereits alles was mit meiner Recherche und Wissen 
herausgefunden habe ausprobiert. Jedoch erfolglos.

[Adam P. (adamap)]

Bekommst du vom DDS eine Rückantwort?
Weil dann dürfte deine ISR stören, wenn die die Antwort zurück an den 
DDS schickt.

Sonst kann es noch ein falscher Init. sein (Baud).
und und und...

Dann bestell dir echt mal lieber ein Logic Analyser, damit wäre das 
Problem in 2-3 Minuten eingegrenzt gewesen und schon gelöst ;-)

Sascha B. schrieb:
> Bei HTerm hatte ich 8Datat 1Stop Parity-none Newline at LF

Das betrifft jedoch nur den Empfang, was hast du unten beim Versenden 
eingestellt (das was ich rot eingekreist habe)

[S. L. (sldt)]

Frage (eines Assemblerprogrammierers): wie ist das zu verstehen '#define 
MYUBRR (16000000  16  9600 - 1) = 103'?

PS:
Die Schrägstriche vor und nach der '16' stehen zwar in der Vorschau, 
sind dann aber verschwunden, bitte hinzudenken.

[Bruno V. (bruno_v)]

Sascha B. schrieb:
> Nein hat leider auch nicht funktioniert. Kann es an was anderes liegen?
> Ich habe bereits alles was mit meiner Recherche und Wissen
> herausgefunden habe ausprobiert. Jedoch erfolglos.

Schaue bitte in die Funktion, ob sie \r oder \n nicht selbst schon 
generiert.

Falls nein, dann ist "f 1000\r\n" Dein String. nichts mit < oder > oder 
Leerzeichen oder sonstwas.

[Martin B. (martin_b563)]

Der Fehler, Syntax Error (siehe Eröffnungsbeitrag), ist ja von S. L. 
schon erkannt worden.

UBBRH =( (16000000  16  9600 -1) = 103  >> 8) ist syntaktisch falsch.

Also erst mal das define für MYUBBR  korrigieren.

und auch hier die Schrägstriche hinzudenken ...

[Bruno V. (bruno_v)]

Martin B. schrieb:
> Der Fehler, Syntax Error (siehe Eröffnungsbeitrag)

Moment, der TO hat kein Problem mit dem Uart oder was darüber geht, 
sondern sein C-Compiler meldet "Syntax-Fehler" beim Compilieren und der 
TO hat weder die Fehlermeldung noch irgendwie die Fehlerhafte Zeile 
genannt (gepostet wäre sie dann ja)?

Hut ab an Dich und S.L.

[Georg G. (df2au)]

Bruno V. schrieb:
> sein C-Compiler meldet "Syntax-Fehler" beim Compilieren

Wie kommst du auf dieses schmale Brett?

Der "DDS" meldet im Betrieb den Fehler. Ohne Logikanalysator ist die 
Fehlersuche ein stochern im Dunkeln, vor allem, weil offenbar das 
DDS-Programm nicht zu Debug Ausgaben überredet werden kann.

Als erstes sollte mal die Baudrate mit einem Scope geprüft werden.

[S. L. (sldt)]

> Als erstes sollte mal die Baudrate mit einem Scope geprüft werden.

Das kann nicht schaden, aber - wenn der Compiler mit dem eingangs 
Gezeigten 'Syntax Error' meldet, dann ist doch alles, was Sascha B. 
ausprobiert und uns hier vorstellt, recht fragwürdig, nicht wahr?

[Bruno V. (bruno_v)]

Georg G. schrieb:
> Der "DDS" meldet im Betrieb den Fehler. Ohne Logikanalysator ist die
> Fehlersuche ein stochern im Dunkeln, vor allem, weil offenbar das
> DDS-Programm nicht zu Debug Ausgaben überredet werden kann.
>
> Als erstes sollte mal die Baudrate mit einem Scope geprüft werdena

Wenn das DDS "Syntax-Fehler" meldet, dann der Reihe nach:

1) Wo meldet das DDS diesen Fehler? Display, LED, zweite Schnittstelle 
oder gar auf der Schnittstelle zum Mega32?

2) wenn HTerm mit dem DDS spricht, dann kann HTerm (bei gleicher 
Einstellung) auch die Baudrate(nsettings) des Mega32 prüfen

3) Wenn der TO noch eine freie Schnittstelle hat, kann er die 
Kommunikation binär mitlesen, also was genau an CR oder LF gesendet 
wird.

Wenn HTerm "müll" liest, dann lässt sich auch daraus auf Baudratenfehler 
schließen, solange binär mitgelesen wird. Z.B. durch senden einer 
einzelnen '1' (0x31).

[Ralph S. (jjflash)]

Martin B. schrieb:
> Der Fehler, Syntax Error (siehe Eröffnungsbeitrag), ist ja von S. L.
> schon erkannt worden.
>
> UBBRH =( (16000000  16  9600 -1) = 103  >> 8) ist syntaktisch falsch.
>
> Also erst mal das define für MYUBBR  korrigieren.
>
> und auch hier die Schrägstriche hinzudenken ...

Richtig!

mit:

#define MYUBRR (16000000 / 16 / 9600 - 1) = 103

Wird versucht, einer Konstante (das Rechenergebnis) den Wert einer 
anderen Konstanten (hier 103) zuzuweisen. Das kann nicht funktionieren.
Der Compiler meckert mit:

error: lvalue required as left operand of assignment

Entweder lasse ich den Präprozessor selbst rechnen (wobei es kein 
schöner Stil ist, die Taktfrequenz direkt mit 16000000 anzugeben, besser 
wäre bspw. das bereits vorhandene #define F_CPU 16000000 und die 
Baudrate #define BAUD in der Berechnung zu verwenden)

#define MYUBRR  (16000000 / 16 / 9600) - 1

oder (als "magic number")

#define MYUBRR 103

oder (für mich am "besten")

#define F_CPU 16000000ul
#define BAUD
#define MYUBRR (F_CPU / 16 / BAUD) -1

[Ralph S. (jjflash)]

muß natürlich heißen:

#define BAUD 9600

(sorry)

[Heiner B. (karadur)]

Schon mal versucht mit dem E-Kommando den gesendeten String wieder zu 
lesen?

Ich hatte mal den Fehler das Kommandos mit hyperterm an einen µC 
funktionierten aber aus einem C-Programm ging es nicht. Der Fehler war: 
der µC hat die UART gepollt und war bei einem gesendeten String zu 
langsam.

[Ralph S. (jjflash)]

Heiner B. schrieb:
> Ich hatte mal den Fehler das Kommandos mit hyperterm an einen µC
> funktionierten aber aus einem C-Programm ging es nicht. Der Fehler war:
> der µC hat die UART gepollt und war bei einem gesendeten String zu
> langsam.

Er sollte mal den ATmega32 über UART mit dem PC verbinden und dort das 
HTerm starten. Dann wird er sehen, dass der ATmega32 gar nichts sendet, 
weil er kein richtiges Programm hat.

Der Compiler wird aufgrund des falschen #define kein Programm erzeugen. 
Er hat also momentan wahrscheinlich "irgendein altes" Programm im Flash!

[Adam P. (adamap)]

Oh man,

da habt ihr natürlich recht, dass hatte ich voll übersehen bei der 
ganzen Hilfestellung. (manchmal sieht man den Wald vor lauter Bäume 
nicht)

Das hier

#define MYUBRR (16000000 / 16 / 9600 - 1) = 103

ist natürlich totaler Quatsch.

Aber dann finde ich den Eröffnungsbeitrag vom TO ziemlich verwirrend,
da er sagte, andere Befehle würden funktionieren.

Aber ja, so kann das nicht funktionieren.

edit:
Ich bin ebenfalls davon ausgegangen, das "syntax error" sich auf den 
abgesetzten Befehl per UART handelt.

[Sascha B. (blank)]

Adam P. schrieb:
> Bekommst du vom DDS eine Rückantwort?
> Weil dann dürfte deine ISR stören, wenn die die Antwort zurück an den
> DDS schickt.
>
> Sonst kann es noch ein falscher Init. sein (Baud).
> und und und...
>
> Dann bestell dir echt mal lieber ein Logic Analyser, damit wäre das
> Problem in 2-3 Minuten eingegrenzt gewesen und schon gelöst ;-)
>
> Sascha B. schrieb:
>> Bei HTerm hatte ich 8Datat 1Stop Parity-none Newline at LF
>
> Das betrifft jedoch nur den Empfang, was hast du unten beim Versenden
> eingestellt (das was ich rot eingekreist habe)

Ich habe da none eingetragen im Beispiel sehe ich steht da CR. Ich habe 
kein CR ausgewählt selber aber hingeschrieben.

[Sascha B. (blank)]

Martin B. schrieb:
> Der Fehler, Syntax Error (siehe Eröffnungsbeitrag), ist ja von S. L.
> schon erkannt worden.
>
> UBBRH =( (16000000  16  9600 -1) = 103  >> 8) ist syntaktisch falsch.
>
> Also erst mal das define für MYUBBR  korrigieren.
>
> und auch hier die Schrägstriche hinzudenken ...

Dies habe ich korrigiert mit #define MYUBRR (F_CPU/16/BAUD) -1
Jedoch kommt auf dem Display des DDS Generators wieder ein Syntax Error. 
Über Hterm geht es.

[Cyblord -. (cyblord)]

Sascha B. schrieb:
> Kann es an was anderes liegen?

Natürlich. Daran dass du keinen blassen Schimmer hast was du da 
eigentlich tust. Das ist ein großes Problem.

[Adam P. (adamap)]

Dann kannst noch dein ATmega mal an PC hängen und anstatt es an den DDS 
zu senden, sendest du es an HTerm und schaust was da ASCII / HEX mässig 
so ankommt.
Sollte ja das gleiche sein wie du es per HTerm an den DDS versendest.
Sonst bestell dir ein LA. Ist immer einfacher Fehler zu finden, wenn man 
weiß was auf den Leitungen wirklich passiert.

[S. L. (sldt)]

Wie wäre es, auf dem ATmega32 eine LED blinken zu lassen? Klingt nun arg 
abgedroschen, zugegeben, zeigte aber zweierlei: dass geänderte Programme 
auch wirklich auf dem uC ankommen (das ist nämlich nach dem bisherigen 
Verlauf hier höchst zweifelhaft) und dass der uC mit 16 MHz läuft.

[Sascha B. (blank)]

S. L. schrieb:
> Wie wäre es, auf dem ATmega32 eine LED blinken zu lassen? Klingt nun arg
> abgedroschen, zugegeben, zeigte aber zweierlei: dass geänderte Programme
> auch wirklich auf dem uC ankommen (das ist nämlich nach dem bisherigen
> Verlauf hier höchst zweifelhaft) und dass der uC mit 16 MHz läuft.

Das habe ich bereits gemacht die Lampe blinkt.

[Bruno V. (bruno_v)]

Sascha B. schrieb:
> Das habe ich bereits gemacht die Lampe blinkt.

Dann versuche doch mal die anderen Schritte:

 * Output per Hterm mitlesen (binär und ASCII, hier posten)
 * Hier schreiben, was genau Du in den String packst. Am Besten 
eingebettet in \[c]  oder \[code], damit man die echten Zeichen (und 
keine Umschreibung) sieht
 * Beschreiben, wie der DDS "Syntax error" meldet. Auf einem Display, 
per LED, ... (Foto?)

[S. L. (sldt)]

> die Lampe blinkt

Mit dem Rhythmus, der den 16 MHz entspricht?

[Sascha B. (blank)]

Bruno V. schrieb:
> Sascha B. schrieb:
>> Das habe ich bereits gemacht die Lampe blinkt.
>
> Dann versuche doch mal die anderen Schritte:
>
>  * Output per Hterm mitlesen (binär und ASCII, hier posten)
>  * Hier schreiben, was genau Du in den String packst. Am Besten
> eingebettet in \[c]  oder \[code], damit man die echten Zeichen (und
> keine Umschreibung) sieht
>  * Beschreiben, wie der DDS "Syntax error" meldet. Auf einem Display,
> per LED, ... (Foto?)

Das versuche ich gerade bereits seit längerem. Aber er lässt mich nicht 
über Hterm mit dem Controller verbinden. Feher heißt: Port10 konnte 
nicht initialisiert werden.

In den String habe ich :
int main(void) {
  usartInit();  // Initialisiere USART mit 9600 Baud


  const char* message = "f 15000\r\n";

  // Den String über USART senden
  while (1) {
    usart_sendString(message);// Endlosschleife, keine weiteren Aktionen 
erforderlich
  }
}

Auf Dem DDS Generator Steht auf dem Bildschirm:

Remote Controle
Syntax Error



Was meinst du mit \[c]?

[Sascha B. (blank)]

int main(void) {
  usartInit();  // Initialisiere USART mit 9600 Baud

  // Die Zeichenkette "f 1000\r" zum Senden vorbereiten
  const char* message = "f 15000\r\n";  // f = Frequenzbefehl, 1000 = Frequenzwert, \r = Carriage Return

  // Den String über USART senden
  //usart_sendString(message);*/

  while (1) {
    usart_sendString(message);// Endlosschleife, keine weiteren Aktionen erforderlich
  }
}

so?

[S. L. (sldt)]

an Sascha B.:

Können Sie Ihre Intel-Hex-Datei hier einstellen? Dann könnte ich sie 
(auf einem ATmega16) laufenlassen.

[Sascha B. (blank)]

S. L. schrieb:
> an Sascha B.:
>
> Können Sie Ihre Intel-Hex-Datei hier einstellen? Dann könnte ich sie
> (auf einem ATmega16) laufenlassen.

Die hier?

[Bruno V. (bruno_v)]

Sascha B. schrieb:
> Feher heißt: Port10 konnte
> nicht initialisiert werden.

Du hast doch HTERM mit dem DDS gekoppelt. Zieh das Kabel vom DDS ab und 
steck stattdessen Deinen Controller dran. Wenn HTERM was anzeigt --> 
hier posten, wenn nicht, versuche es erstmal, überhaupt irgendwas aus 
dem Controller rauszukriegen. Vielleicht ist es ja nur ein Pegelproblem.

[S. L. (sldt)]

an Sascha B.:

Entschuldigung, das geht leider nicht: der ATmega16 hat nur 1 KiB SRAM, 
und einen ATmega32 habe ich nicht.

[Sascha B. (blank)]

S. L. schrieb:
> an Sascha B.:
>
> Entschuldigung, das geht leider nicht: der ATmega16 hat nur 1 KiB SRAM,
> und einen ATmega32 habe ich nicht.

Dan wird diese Datei die ich für den 16 umgeschrieben habe auch 
warscheinlich nicht gehen.

[Sascha B. (blank)]

Bruno V. schrieb:
> Sascha B. schrieb:
>> Feher heißt: Port10 konnte
>> nicht initialisiert werden.
>
> Du hast doch HTERM mit dem DDS gekoppelt. Zieh das Kabel vom DDS ab und
> steck stattdessen Deinen Controller dran. Wenn HTERM was anzeigt -->
> hier posten, wenn nicht, versuche es erstmal, überhaupt irgendwas aus
> dem Controller rauszukriegen. Vielleicht ist es ja nur ein Pegelproblem.

Versuche ich die Ganzezeit bereits mit verschiedenen Kabel und Ports 
aber das einzige was ich von Hterm bekomme ist das es nicht geklapt hat 
oder der Port nicht erkannt wird. Ich habe bereits andere Controller 
genommen Funktiobiert auch nicht... Ich habe auch den Treiber neu 
Installiert.

Eingestellt Port10 9600 8Data 1Stop No-Parity port nicht erkannt oder 
konnte nicht initialisiert werden.

[Bruno V. (bruno_v)]

Sascha B. schrieb:
> Versuche ich die Ganzezeit bereits mit verschiedenen Kabel und Ports
> aber das einzige was ich von Hterm bekomme ist das es nicht geklapt hat
> oder der Port nicht erkannt wird.

Wie kann das sein? Wenn Du HTERM mit dem DDS gekoppelt hast, dann gibt 
es keinen Port der nicht erkannt wird.

Vielleicht solltest Du mal eine Skizze machen und alle Komponenten mit 
a, b, ... benennen, inclusive der Verbinder. Es ist nicht klar, was bei 
Dir ein, zwei oder mehrere Komponenten sind.

[S. L. (sldt)]

an Sascha B.:

Könnten Sie die aktuellen USART.C und USART.H zeigen?

[Georg G. (df2au)]

Sascha: Wie ist deine PLZ? Vielleicht wohnt jemand in deiner Nähe und 
kann messtechnisch helfen.

[Soul E. (soul_eye)]

Sascha B. schrieb:
> Versuche ich die Ganzezeit bereits mit verschiedenen Kabel und Ports
> aber das einzige was ich von Hterm bekomme ist das es nicht geklapt hat
> oder der Port nicht erkannt wird.

Wenn der Port nicht erkannt wird, hast Du ein Problem mit Deinem 
FTDI-Kabel. Dann ist es völlig egal, ob am anderen Ende des Kabels die 
DDS, Dein Controller oder beides hängt.

[Cyblord -. (cyblord)]

Soul E. schrieb:
> Sascha B. schrieb:
>> Versuche ich die Ganzezeit bereits mit verschiedenen Kabel und Ports
>> aber das einzige was ich von Hterm bekomme ist das es nicht geklapt hat
>> oder der Port nicht erkannt wird.
>
> Wenn der Port nicht erkannt wird, hast Du ein Problem mit Deinem
> FTDI-Kabel. Dann ist es völlig egal, ob am anderen Ende des Kabels die
> DDS, Dein Controller oder beides hängt.

Da fehlen einfach so viele Grundlagen...

[Björn W. (bwieck)]

Neulich hat Microsoft die Treiber für diese CH340 USB-UART Chips 
upgedatet..
Danach gingen meine "billigen" USB-RS485 mit HTerm nicht mehr.
Musste manuell die Treiberversion von 2019 installieren, dann war wieder 
OK.

[S. L. (sldt)]

an Sascha B.:

UsartforATM16.hex arbeitet mit 600 Bd.

PS:
Also Faktor 16 - da fehlt wohl, zumindest in dieser Programmversion, die 
'16' im 'define MYUBRR ...'.

[Ralph S. (jjflash)]

S. L. schrieb:
> UsartforATM16.hex arbeitet mit 600 Bd.
>
> PS:
> Also Faktor 16 - da fehlt wohl, zumindest in dieser Programmversion, die
> '16' im 'define MYUBRR ...'.

... oder der Controller läuft mit 1MHz internem Takt weil die Fuses 
nicht auf externen Quarz umgestellt sind.

Er soll einfach mal die komplette Quelldatei + Header hier posten!

[S. L. (sldt)]

> oder der Controller läuft mit 1MHz internem Takt ...

Gute Idee!
  Andererseits hätte ein Faktor von 16 eigentlich bei der blinkenden LED 
bemerkt werden müssen, zumal ich extra nochmal nachfragte:

Sascha B. schrieb:
> S. L. schrieb:
>> Wie wäre es, auf dem ATmega32 eine LED blinken zu lassen? Klingt nun arg
>> abgedroschen, zugegeben, zeigte aber zweierlei: dass geänderte Programme
>> auch wirklich auf dem uC ankommen (das ist nämlich nach dem bisherigen
>> Verlauf hier höchst zweifelhaft) und dass der uC mit 16 MHz läuft.
>
> Das habe ich bereits gemacht die Lampe blinkt.

S. L. schrieb:
> Mit dem Rhythmus, der den 16 MHz entspricht?

[Ralph S. (jjflash)]

#define F_CPU 16000000ul
#define BAUD 9600
uint16_t ubrr;

ubrr= (F_CPU/16/BAUDRATE-1);

UBRRH = (uint8_t)(ubrr>>8);                    // Baudrate setzen
UBRRL = (uint8_t)ubrr;

UCSRB |= (1<<RXEN) | (1<<TXEN);
UCSRC  = (1<<URSEL) | (1<<UCSZ01) | (1<<UCSZ00);

... produziert mir hier 9600 Bd

[S. L. (sldt)]

> oder der Controller läuft mit 1MHz internem Takt ...

Nein - das von Sascha B. bereitgestellte Programm sendet hier bei mir 
mit 600 Bd, und mein ATmega16 läuft mit 16 MHz - da war ich eben auch 
zuerst irritiert.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Und wieder einmal eine paranormale Travestieshow zu einer 
UART-Schnittstelle – wer nicht einmal dazu in der Lage ist, mit dem 
µController seiner Wahl ein Zeichen per UART abzusenden oder zu 
empfangen, der sollte sich ernsthaft überlegen, ob er sich das richtige 
Hobby ausgesucht hat, aber falls jemand doch der Meinung ist, dass er 
die richtige Wahl getroffen habe, dann sollte er bei solchen Problemen 
systematisch vorgehen, also erstmal UART richtig einstellen incl. 
einschalten, was in der Regel nur mit dem Lesen der Bibel des Tüftlers – 
also mit dem Datenblatt – geht. Danach sollte man versuchen nur ein 
Zeichen abzusenden und falls dieses wirklich aus dem TX-Ausgang real 
rauskommen sollte, was man mit einem Oszilloskop nachprüfen kann und 
auch zwingend tun sollte, dann gleichzeitig auch die Baudrate messen – 
das geht ebenfalls sehr gut mit dem Oszilloskop. Ganz am Anfang sollte 
man aber unbedingt bei den Datentypen ansetzen, denn die passende 
Verwendung von Datentypen ist in der C-Sprache essenziell und die 
Defizite in der Hinsicht sind heutzutage sehr in Mode – und immer schön 
darauf achten, was der Compiler einem beim Build mitteilt, denn kein 
Error heißt noch lange nicht, dass es gut geworden ist, was man da in C 
fabriziert hat. Und wer selbst große UART-Probleme hier vor kurzem 
nachweislich hatte oder generell hat und meint, hier jetzt die 
Supa-Dupa-Tipps abgeben zu müssen, der sollte sich lieber mit dem Kehren 
vor der eigenen Haustür beschäftigen, denn da gibt es noch sehr viel zu 
tun.

[Adam P. (adamap)]

Sascha B. schrieb:
> Versuche ich die Ganzezeit bereits mit verschiedenen Kabel und Ports
> aber das einzige was ich von Hterm bekomme ist das es nicht geklapt hat
> oder der Port nicht erkannt wird. Ich habe bereits andere Controller
> genommen Funktiobiert auch nicht... Ich habe auch den Treiber neu
> Installiert.

Ernsthaft?

Hol dir USBTreeView
https://www.uwe-sieber.de/usbtreeview.html

Zieh dein USB-UART Kabel vom PC ab, starte das Programm, steck das Kabel 
wieder ein und schau was er als neues USB Device anzeigt inkl. COM 
Nummer.

[Sascha B. (blank)]

Ich habe das Problem gelöst. Es war kein Fehler vom String der gesendet 
wird. Im Code selber ganz am Anfang bei dieser Code Zeile:

UCSRC = (1 << UCSZ1) | (1 << UCSZ0);

hat ein weiter Bit gefehlt. Dieser hier

UCSRC = (1 << UCSZ1) | (1 << UCSZ0)| (1 << URSEL);

Nach dem hat alles funktioniert.

Ich bedanke mich bei allen die sich die mühe gegeben haben, mir bei 
meinem Problem zu helfen. Ich hoffe das es weiterhin jemanden dabei 
helfen wird.

Auch an die Kommentare die nicht so nett waren.

[S. L. (sldt)]

Wobei im eingangs gezeigten USART_C noch die richtige Zeile stand.
  Ohne gesetztes URSEL wird nicht UCSRC geschrieben, sondern UBRRH, und 
zwar mit 6, zusammen mit den 103 in UBRRL wird das zu 1639, was (bei 16 
MHz) eine Baudrate von 610 Bd ergibt.

Und noch etwas fällt auf: UCSRC wird so ja nie geschrieben, trotzdem 
stimmt das Ausgabeformat, parbleu! Denn der 'Initial Value' passt 
bereits, das zusätzliche Schreiben ist überflüssig, auch wenn es seit 
Jahren an vielen Stellen so steht.

PS:
> die Kommentare die nicht so nett waren
Welche man weder ernst nehmen sollte noch kann.

[Ralph S. (jjflash)]

Gregor J. schrieb:
> nd wieder einmal eine paranormale Travestieshow zu einer
> UART-Schnittstelle – wer nicht einmal dazu in der Lage ist, mit dem
> µController seiner Wahl ein Zeichen per UART abzusenden oder zu
> empfangen, der sollte sich ernsthaft überlegen, ob er sich das richtige
> Hobby ausgesucht hat

Ruhe und stillgestanden: Ein Gott ist zugegen!

Ah näh... irgendwie doch nicht! Grundsätzlich ärgere ich mich jetzt 
schon das ich in die Tasten greife aber bei einem Gott wie Gregor kann 
man eben nur einen gotteszustimmenden Kommentar abgeben.

Ich wollte ja (und deswegen ärgere ich mich über mich) auf Kommentare 
von Ihnen schon gar nicht mehr auslassen, aber so irgendwie etwas stehen 
lassen möchte ich dann doch nicht. Grundsätzlich dachte ich, dass man in 
ungemütlicher aber stiller Feindschaft koexistieren könnte, aber schein 
bar ist das nicht so. Dass ich Sie und Sie mich nicht leiden können ist 
nun nicht wirklich schlimm und auch kein Verlust für das Forum hier.

Aber: es gab und gibt hier einige Stänkerer und Stinkstiefel hier und 
Sie belegen hier für mich tatsächlich weit oben einen Platz in den Top 
Ten.

Huldigt jemand einem Gott nicht, wird Gott über die Maßen überheblich 
und arrogant. Wie bereits wo anderst gesagt habe ich von Gott noch 
nichts gesehen was mich vom Hocker gehauen hätte (ich lasse mich hier 
jetzt nicht darüber aus zu dem was ich gesehen habe sonst könnte man das 
mir doch glatt als geschäftsschädigend auslegen). Das was ich gesehen 
habe war besten falls solide aber mit nichten herausragend und 
"natürlich Spitzenklasse". Eben Standard (allerdings habe ich nur PCB's 
gesehen).

Hier im Forum habe ich noch keinen einzigen wirklich konstruktiven 
Beitrag gesehen, der irgendjemandem geholfen hat außer Gott selbst um 
sich selbst zu überhöhen und bewundert zu werden. Wird Gott nicht 
bewundert (wie bei dem Gott aus der Bibel) wird er ausfallend und 
bisweilen übersäät er seine Geschöpfe  mit dragonischen Strafen. Wie 
gut, dass ich nicht Ihr Geschöpf bin.

So, nun zum Grund warum ich dennoch (entgegen meinem Vorsatz schreibe) 
ist einfach, dass ich etwas so nicht darstehen lassen mag:

Gregor J. schrieb:
> nd wer selbst große UART-Probleme hier vor kurzem
> nachweislich hatte oder generell hat und meint, hier jetzt die
> Supa-Dupa-Tipps abgeben zu müssen, der sollte sich lieber mit dem Kehren
> vor der eigenen Haustür beschäftigen

Gott hat es wirklich drauf, einen zu treffen. Allerdings lügt der Gott 
aus der Bibel nicht oder schafft Fake-News (wie wo anderst nachzulesen 
ist).

Ich hatte KEINE große UART-Probleme, ich hatte Probleme mit einem 
einzigen, in Ziffern: "1" Chip, der in Kombination mit AVR-ATmegaxx8 
nicht so wollte wie ich mir das gedacht hatte. Aussagen von - um das 
jetzt mal so zu sagen - wirklich nicht die Koriphäen (denn das sind 
andere hier) muß ich nicht beachten, wenn ich haarklein weiß dass meine 
"ach so großen Probleme" nicht dort liegen, wie es der neue Gott hier 
verkündet. Der dann, wie es Götter so an sich haben, höchst beleidigt 
und ausfallend wird, wenn man seine Weisungen (und mögen sie noch so 
falsch sein) nicht befolgt. Tatsache ist: Ich hatte Probleme mit CH340N 
in Kombination mit ATmegaxx8. Ende. CH340N läuft in Verbindung mit jedem 
von mir getesteten STM32 (F030, F070, F072, F103, F303, F401, F411, 
F407, F429), STM8 und sogar mit einem PFS154 von Padauk klaglos. Da ich 
keine Ahnung habe, wie alt der Gott ist, ich aber annehme, dass Gott 
sogar jünger ist als ich (und von daher gar kein Gott sein kann) möchte 
ich anmerken: Ich habe höchstwahrscheinlich schon mit seriellen 
Schnittstellen hantiert, als Sie noch in die xyz abc gemacht haben (mit 
Graußen erinnere ich mich an i8080 in Verbindung mit einem 8255 bei dem 
mittels Bitbanging eine serielle Schnittstelle realisiert wurde, bis ich 
dann das erste mal einen 16550 eingesetzt hatte). Ich habe in meinem 
Leben ewig viele Schnittstellen in Betrieb genommen, als den großen 
Zampano würde ich mich jedoch nicht wirklich bezeichnen, denn es gibt 
hier einige Mitglieder (manche sogar mit ähnlich schlechten Manieren wie 
Sie), die hinlänglich gezeigt haben, was sie auf den Kasten haben und 
mit denen ich mich nicht messen kann. Diese... bewundere ich dann doch.

So, das ganze jedoch ist eine reine Frage der Hardware und nicht - wie 
hier - der Software. Der TO hat einen Fehler gemacht (oder wie es sich 
herausgestellt hat auch zwei). Na und? Genau hierfür ist dieses Forum 
da: UM SICH GEGENSEITIG ZU HELFEN ... und nicht um bewundert zu werden. 
Bisweilen ist das mit dem Helfen jedoch "schwierig", gebe ich zu, wenn 
der dem geholfen werden soll "beratungsresistent" ist. Bei meinen ach so 
großen Problem mit dem CH340N war die Lösung des Problems von keinem 
erkannt worden. Von den Dingen die ich im Internet gesehen habe, die 
USB2UART Bridges verwenden, habe ich keine einzige Schaltung gesehen, 
die in Kombination mit einem ATmega48 bis ATMega328 gestanden hat. Das 
muß einen Grund haben, wenn der CH340N preiswerter als der "G"-Typ ist 
und zu dem weniger Bauteile benötigt. Der "N" -Typ läuft auch klaglos an 
einem ATtiny1604 hier.

So, Ihr Posting jetzt hatte doch nur einen Inhalt, nämlich den, den TO 
hier zu verhöhnen und sich selbst als ach so toll darzustellen.

Wenn Sie das brauchen, bitte!
Ich wäre dennoch dankbar (allerdings bin ich kein gläubiger Mensch, ich 
glaube auch sonst nicht an Götter, und von daher auch nicht an die 
Erfüllung meiner Bitte), wenn wir in Zukunft doch bitte eine von mir aus 
feindliche aber bitte leise Koexistenz pflegen könnten.

Kurz ausgedrückt: Ich kann Sie nicht leiden (und sie mich nicht).

Gregor J. schrieb:
> dann sollte er bei solchen Problemen
> systematisch vorgehen, also erstmal UART richtig einstellen incl.
> einschalten, was in der Regel nur mit dem Lesen der Bibel des Tüftlers –
> also mit dem Datenblatt – geht. Danach sollte man versuchen nur ein
> Zeichen abzusenden und falls dieses wirklich aus dem TX-Ausgang real
> rauskommen sollte, was man mit einem Oszilloskop nachprüfen kann und
> auch zwingend tun sollte, dann gleichzeitig auch die Baudrate messen –
> das geht ebenfalls sehr gut mit dem Oszilloskop. Ganz am Anfang sollte
> man aber unbedingt bei den Datentypen ansetzen, denn die passende
> Verwendung von Datentypen ist in der C-Sprache essenziell und die
> Defizite in der Hinsicht sind heutzutage sehr in Mode – und immer schön
> darauf achten, was der Compiler einem beim Build mitteilt, denn kein
> Error heißt noch lange nicht, dass es gut geworden ist

Das hier ... sind alles Milchmädchenweißheiten und mitnichten die 
überragende "Wow-Aussage". Bei einem Fußballspiel würde es hierfür die 
rote Karte geben, weil diese Aussage in diesem Thread erst dann gemacht 
wurde, als der TO sein Problem bereits gelöst hatte. Sportlich gesehen 
nennt man so etwas "nachtreten".

Die folgende Sache hat den Fehler im Sourcecode beseitigt.

Ralph S. schrieb:
> error: lvalue required as left operand of assignment
>
> Entweder lasse ich den Präprozessor selbst rechnen (wobei es kein
> schöner Stil ist, die Taktfrequenz direkt mit 16000000 anzugeben, besser
> wäre bspw. das bereits vorhandene #define F_CPU 16000000 und die
> Baudrate #define BAUD in der Berechnung zu verwenden)
> #define MYUBRR  (16000000  16  9600) - 1
>
> oder (als "magic number")#define MYUBRR 103
>
> oder (für mich am "besten")#define F_CPU 16000000ul
> #define BAUD 9600
> #define MYUBRR (F_CPU  16  BAUD) -1

Danach muß der TO etwas in seinem Quellcode verändert haben, was zuvor 
richtig war (was ich komplett nachvollziehen kann, weil man eben 
"verzweifelt" einen Fehler sucht und dann vergißt, etwas wieder 
herzustellen, was wohl doch richtig war):

Ralph S. schrieb:
> #define F_CPU 16000000ul
> #define BAUD 9600
> uint16_t ubrr;
> ubrr= (F_CPU/16/BAUDRATE-1);
> UBRRH = (uint8_t)(ubrr>>8);                    // Baudrate setzen
> UBRRL = (uint8_t)ubrr;
> UCSRB |= (1<<RXEN) | (1<<TXEN);
> UCSRC  = (1<<URSEL) | (1<<UCSZ01) | (1<<UCSZ00);
>
> ... produziert mir hier 9600 Bd

Danach hatte sich der TO gemeldet gehabt, dass er schlicht

Sascha B. schrieb:
> UCSRC = (1 << UCSZ1) | (1 << UCSZ0)| (1 << URSEL);

das URSEL-Bit nicht gesetzt hatte. Danach hat sich sein Problem wohl 
erledigt gehabt.
Wie tief der TO in die Materie einsteigen will oder nach Ihrem 
dafürhalten fernhalten soll, obliegt Ihnen nicht. Es ist die Sache des 
TO. Es ist unsere Sache, ob wir ihm helfen oder nicht.

Sie -so ich die Threads beobachte- haben noch niemandem geholfen, 
allerdings ist Ihre Zeit, wie sie sagen, ja auch sehr knapp und kostbar.

Von daher:
Danke Gott, dass Sie diesen Thread besucht haben.