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.
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 ;-)
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€.
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:
1
>"f 1000<CR>\n"
2
>
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.
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.
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)?
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.
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?
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:
Wo meldet das DDS diesen Fehler? Display, LED, zweite Schnittstelle oder gar auf der Schnittstelle zum Mega32?
wenn HTerm mit dem DDS spricht, dann kann HTerm (bei gleicher Einstellung) auch die Baudrate(nsettings) des Mega32 prüfen
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).
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)
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.
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!
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.
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.
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.
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.
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?)
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
}
}
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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).
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.
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):
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.
main_c.PNG
(18 KB)
USART_C.PNG
(42 KB)
USART_H.PNG
(24 KB)
DDS_zeichen.PNG
(13 KB)
