Hallo! Ich habe ein seltsames Problem mit meinem neuen USB TTL Konverter (basierend auf dem CP2102N Chip). Wie der Titel schon sagt, kann ich keine Daten von meinem Atmega88 aus senden, sobald das TXD Ende des Kabels am RXD Eingang des MC anschließe. Am MC empfangen funktioniert jedoch wenn beide Enden angeschlossen sind. Nach längerem herumprobieren hab ich rausgefunden, dass TXD am Kabel immer HIGH zu sein scheint und der Atmega88 vermutlich deswegen nicht sendet, was für mich aber nicht schlüssig ist. Nachstellen kann ich dieses Szenario auch: ich schicke in einer Endlosschleife Nachrichten vom MC an den UART, diese erhalte ich ganz normal, sobald ich aber ein HIGH Signal an den RXD des Atmega88 anlege, empfange ich nichts. Der Code ist aus dem Datenblatt und hat mit meinem vorherigen USB TTL Konverter (CP2102 ohne N) problemlos funktioniert. Angeschlossen sind lediglich RXD/TXD/GND - konfiguriert sind 4800 BAUD, 1 Stoppbit, 8 Datenbits, kein Paritybit - auch am Terminal am PC genau so eingestellt. Selbst mit anderen BAUDs, mit/ohne externen Clock etc. konnte ich kein anderes Verhalten feststellen. Hat irgendjemand eine Idee was es hier auf sich hat?
Christian schrieb: > Hat irgendjemand eine Idee was es hier auf sich hat? Ja du hast einen Fehler eingebaut... Welchen keine Ahnung. kein Schaltplan, kein Foto vom Aufbau, kein Code, kein Mitleid
Habe mir Schaltbild von https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf angeschaut. Viele Möglichkeiten USB zu TTL zu wandeln. Welche nun genau? "Mein" Usb-Wandler wandelt auf V24 um. Und Max232 dann auf TTL. Hier liegen Fehler oft darin, dass Pegel im Programm verdreht sind. Also im Programm ein High, muss ein Low sein. Und im Terminalprogramm zum Test so einiges zum Einstellen z.B."Echo", und keine Software-Flowcontrol. Wie sieht Dein UART-Programm aus? Ein Primitiv-Test-Programm mit Polling im Dateianhang. ciao gustav
:
Bearbeitet durch User
Christian schrieb: > Hat irgendjemand eine Idee was es hier auf sich hat? Ich würde jetzt mal ein Messgerät (in diesem Fall ein Oszilloskop) zur Hand nehmen und messen, was da passiert. Und lies mal deine "Fragestellung" so, wie wenn du nichts von deinem Problem wüsstest. So geht es uns nämlich auch. Mit den bisherigen Daten kann keiner eine belastbare Antwort geben. Es gibt so wieder nur eine heitere Ratestunde.
Christian schrieb: > Nach längerem herumprobieren hab ich rausgefunden, dass TXD am Kabel > immer HIGH zu sein scheint Das gehört so, Ruhelage ist High-Pegel. Christian schrieb: > sobald ich aber ein HIGH Signal an den RXD des Atmega88 anlege, empfange > ich nichts. Kurzschluss zwischen TXD- und RXD-Pin?
Karl B. schrieb: > "Mein" Usb-Wandler wandelt auf V24 um. Und Max232 dann auf TTL. nein dein Wandler macht offensichtlich gar nichts. Zeige deinen Schaltplan und deinen Aufbau. Ist doch nicht so schwer zu verstehen oder?
Thomas Z. schrieb: > nein dein Wandler macht offensichtlich gar nichts. > Zeige deinen Schaltplan und deinen Aufbau. Ist doch nicht so schwer zu > verstehen oder? Doch. die meisten PCs haben keine COM1 oder LPT1 Schnittstellenkarte mehr. Muss über einen USB-RS232 aka V24-Wandler-Dongle gehen. Da kommt aber kein TTL-Pegel raus, sondern V24, sprich ca. +-12V. Der TO will direkt auf TTL-wandeln. So versteh ich das. Also nochmal: direkt vom PC über irgendeinen USB-Anschluss direkt auf den ATmega. Dazwischen der USB-TTL-Wandler. Und der machts nicht so, wie er soll. ciao gustav
Karl B. schrieb: > die meisten PCs haben keine COM1 oder LPT1 Schnittstellenkarte mehr. > Muss über einen USB-RS232 aka V24-Wandler-Dongle gehen. > Da kommt aber kein TTL-Pegel raus, sondern V24, sprich ca. +-12V. Bei einem Computer mit normaler RS232-Schnittstelle wäre das nicht anders. Was hat eine LPT-Schnittstellenkarte mit dem Problem des TO zu tun? Karl B. schrieb: > Und der machts nicht so, wie er soll. Falls der CP2102N prinzipiell nicht so arbeiten würde, wie er soll, hätte man davon bestimmt schon ein bisschen mehr gehört, also wird es am Aufbau des TO oder an einem zerschossenen IC liegen.
Der einfach(st)e Test des seriellen Wandlers, waere erst einmel der Loopback-Test. Man schaltet RX auf TX, und prueft mit einem Terminalprogramm ob es "echot".
Motopick schrieb: > Der einfach(st)e Test des seriellen Wandlers, waere erst einmel > der Loopback-Test. Man schaltet RX auf TX, und prueft mit einem > Terminalprogramm ob es "echot". Das hab ich bereits gemacht und funktioniert auch korrekt.
Karl B. schrieb: > Habe mir Schaltbild von > https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf > > angeschaut. > Viele Möglichkeiten USB zu TTL zu wandeln. > Welche nun genau? > > "Mein" Usb-Wandler wandelt auf V24 um. Und Max232 dann auf TTL. > Hier liegen Fehler oft darin, dass Pegel im Programm verdreht sind. > Also im Programm ein High, muss ein Low sein. > > Und im Terminalprogramm zum Test so einiges zum Einstellen z.B."Echo", > und keine Software-Flowcontrol. > > Wie sieht Dein UART-Programm aus? > Ein Primitiv-Test-Programm mit Polling im Dateianhang. > > ciao > gustav Ich habe den USB zu TTL Konverter nicht selbst erstellt, es ist ein fertiger gekaufter Wandler in Form eines Kabels (https://www.amazon.de/DSD-TECH-SH-U09BL-serielle-CP2102N/dp/B08JLRP6YV/), falls das falsch in meinem Post rüberkam. Dein Programm teste ich heute Abend. Schaltplan hab ich keinen angehängt da der Aufbau lediglich die 3 Pins TXD,RXD,GND (TXD und RXD überkreuzt) verbindet.
Christian schrieb: > Motopick schrieb: >> Der einfach(st)e Test des seriellen Wandlers, waere erst einmel >> der Loopback-Test. Man schaltet RX auf TX, und prueft mit einem >> Terminalprogramm ob es "echot". > > Das hab ich bereits gemacht und funktioniert auch korrekt. Dann wäre der nächste Schritt, RxD und TxD am CP2102-Modul korrekt zu identifizieren. Auf TxD sendet es Daten. Also nimm eine LED oder einen Logikprüfstift zur Hilfe und prüfe, welcher der beiden Anschlüsse wackelt wenn du am Terminal etwas sendest. Das Modul ist ja sicher "made in China", da kann man sich nicht darauf verlassen, daß es richtig beschriftet ist. Ruhepegel ist H. Evtl. braucht das Modul auch einen Pullup an TxD.
Christian schrieb: > Der Code ist aus dem Datenblatt Genau der Code aus dem unbekannten Datenblatt wäre interessant. Denn sinnvollerweise solltest du keinen Code verwenden, der ein Zeichen empfängt und das dann wieder zurücksendet, denn dann wird nichts gesendet, wenn entweder das Empfangen **oder** das Senden nicht funktioniert. Sondern du solltest einen Code verwenden, der 1. ständig irgendwelche bekannten Zeichen sendet (0xaa und 0x55 sind da beliebte Muster), und parallel dazu 2. die empfangenen Zeichen auf einer Anzeige (z.B. 8 LEDs) ausgibt. Aber wie gesagt: zum Debuggen von seriellen Schnittstellen aller Art (RS232, I2C, SPI, WS2818, ...) ist ein Oszilloskop das richtige Werkzeug. Denn dann kannst du an den vorgeschlagenen Bitmustern z.B. sehr leicht messen, ob die Baudrate des µC passt.
Lothar M. schrieb: > Christian schrieb: >> Der Code ist aus dem Datenblatt > Genau der Code aus dem unbekannten Datenblatt wäre interessant. > > Denn sinnvollerweise solltest du keinen Code verwenden, der ein Zeichen > empfängt und das dann wieder zurücksendet, denn dann wird nichts > gesendet, wenn entweder das Empfangen **oder** das Senden nicht > funktioniert. > > Sondern du solltest einen Code verwenden, der > 1. ständig irgendwelche bekannten Zeichen sendet (0xaa und 0x55 sind da > beliebte Muster), und parallel dazu > 2. die empfangenen Zeichen auf einer Anzeige (z.B. 8 LEDs) ausgibt. > > Aber wie gesagt: zum Debuggen von seriellen Schnittstellen aller Art > (RS232, I2C, SPI, WS2818, ...) ist ein Oszilloskop das richtige > Werkzeug. Denn dann kannst du an den vorgeschlagenen Bitmustern z.B. > sehr leicht messen, ob die Baudrate des µC passt. Danke für den Input. Ich habe unterschiedliche Programme ausprobiert, sowhol nur senden als auch nur empfangen, das Ergebnis war immer das selbe: Daten an den PC Senden funktioniert sobald ich TXD des Kabels aus dem RXD am MC entferne, schließe ich es wieder an kommt nichts an. Leider hab ich kein Oszilloskop um mir die Signale genauer anzusehen.
Axel S. schrieb: > Christian schrieb: >> Motopick schrieb: >>> Der einfach(st)e Test des seriellen Wandlers, waere erst einmel >>> der Loopback-Test. Man schaltet RX auf TX, und prueft mit einem >>> Terminalprogramm ob es "echot". >> >> Das hab ich bereits gemacht und funktioniert auch korrekt. > > Dann wäre der nächste Schritt, RxD und TxD am CP2102-Modul korrekt zu > identifizieren. Auf TxD sendet es Daten. Also nimm eine LED oder einen > Logikprüfstift zur Hilfe und prüfe, welcher der beiden Anschlüsse > wackelt wenn du am Terminal etwas sendest. > > Das Modul ist ja sicher "made in China", da kann man sich nicht darauf > verlassen, daß es richtig beschriftet ist. Ruhepegel ist H. Evtl. > braucht das Modul auch einen Pullup an TxD. Danke für den Input! RxD und TxD habe ich ziemlich sicher schon korrekt identifiziert, und stimmen mit der Beschriftung überein. Senden/Empfangen funktioniert wie erwartet wenn ich nur den jeweiligen Pin an den ATmega88 anschließe. Das Modul wird vermutlich sehr sicher aus "made in China" sein. Einen Pullup an TxD habe ich nicht versucht, das werde ich heute Abend gleich ausprobieren!
Dann reicht es ja einmal ein H an den RX zu legen. Statt des Wandlers. Sendet er dann auch nicht? Dann ist wohl das "Brogramm" schuld...
Lothar M. schrieb: > Aber wie gesagt: zum Debuggen von seriellen Schnittstellen aller Art > (RS232, I2C, SPI, WS2818, ...) ist ein Oszilloskop das richtige > Werkzeug. Früher (TM) hat man, sobald die Signalpegel überprüft waren, zu einem Logikanalysator gegriffen. Der kann die Signale auch direkt dekodieren. Heutzutage bekommt man den in einer für viele Fälle ausreichenden Variante bereits für unter 10€ und gehört als Standardausrüstung an jeden Elektronikbastelplatz, der sich mit Digitaltechnik beschäftigt, falls nicht leistungsfähigeres Equipment vorhanden ist.
:
Bearbeitet durch User
Motopick schrieb: > Dann reicht es ja einmal ein H an den RX zu legen. > Statt des Wandlers. > Sendet er dann auch nicht? > > Dann ist wohl das "Brogramm" schuld... Das habe ich bereits getan, ja: Christian schrieb: > ich schicke in einer Endlosschleife Nachrichten > vom MC an den UART, diese erhalte ich ganz normal, sobald ich aber ein > HIGH Signal an den RXD des Atmega88 anlege, empfange ich nichts. Die Logik zum Senden ist 1:1 aus dem ATmega88 Datenblatt: void USART_Transmit (unsigned char data) { /* Wait for empty transmit buffer */ while (!(UCSR0A & (1<<UDRE0))) ; /* Put data into buffer, sends the data */ UDR0 = data; } Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon getestet.
Christian schrieb: > Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon > getestet. Wo bleibt des Programm dann hängen? Läuft der µC weiter oder startet er erst wieder, wenn du los lässt.
:
Bearbeitet durch User
Christian schrieb: > Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon > getestet. Hast Du denn mal geprüft, ob es eine ungewollte Verbindung zwischen TXD und RXD gibt?
Anstelle eines Oszis oder Logikanalyser kann man auch zwei weitere USB-Seriell-Wandler verwenden (nur den RX-Teil) und die an die beiden seriellen Signale legen und mit einem Modemprogramm die Zeichen anschauen, die da so kommen.
Hmmm schrieb: > Christian schrieb: >> Nach längerem herumprobieren hab ich rausgefunden, dass TXD am Kabel >> immer HIGH zu sein scheint > > Das gehört so, Ruhelage ist High-Pegel. > > Christian schrieb: >> sobald ich aber ein HIGH Signal an den RXD des Atmega88 anlege, empfange >> ich nichts. > > Kurzschluss zwischen TXD- und RXD-Pin? Hmmm schrieb: > Christian schrieb: >> Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon >> getestet. > > Hast Du denn mal geprüft, ob es eine ungewollte Verbindung zwischen TXD > und RXD gibt? Ich hab deine erste Antwort nicht übersehen, konnte es aber erst jetzt prüfen und du hast in der Tat recht! Der Aufbau befindet sich auf einem Steckboard, die beiden Reihen des TxD/RxD Pins haben einen Durchgang. Damit hätte ich nicht gerechnet! Ich teste das Programm alsblad und berichte vom Ergebnis. Vielen Dank schon mal für den Tipp!!!
Rainer W. schrieb: > Früher (TM) hat man, sobald die Signalpegel überprüft waren Was man zur Beurteilung der Flanken und der Signalqualität am besten mit einem Oszilloskop tut... > zu einem Logikanalysator gegriffen. Der kann die Signale auch direkt dekodieren. Das kann das billigste Picoscope auch. Christian schrieb: > Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon > getestet. Dann lass doch einfach mal das irgendwie blockierende Prüfen des Registers raus und mach ein simples Delay mit 10ms rein, denn bei 4800Bd ist dein Zeichen nach ca. 2ms sicher raus. So in etwa sieht ein Testprogramm für das Senden mit der seriellen Schnitte aus:
1 | void main(void) { |
2 | // Init UART0
|
3 | ...
|
4 | |
5 | for(;;) { |
6 | // Wait for 10ms
|
7 | delay_ms(10); |
8 | // Put data into buffer, sends the data
|
9 | UDR0 = 0xaa; |
10 | }
|
11 | |
12 | }
|
Christian schrieb: > Leider hab ich kein Oszilloskop Ändere das. Es wird dir das Leben langfristig unheimlich erleichtern, wenn du elektronisch gesehen mehr als nur plug&pray machen willst.
:
Bearbeitet durch Moderator
Rainer W. schrieb: > Was hat eine LPT-Schnittstellenkarte mit dem Problem des TO zu > tun? Lies doch richtig: Karl B. schrieb: > die meisten PCs haben keine COM1 oder LPT1 Schnittstellenkarte mehr. Habe noch einen alten XP-Rechner, der hat eine Schnittstellenkarte mit COM und LPT. Die sind steckkartenmäßig beide kombiniert. Kenne keinen PC, der nur eine COM-Karte als solche "solo" hätte. Parallelschnittstele war "gratis" mit dabei, da sonst Platzverschwendung. MOS Chip MCS9950. https://www.eetimes.com/moschip-mcs9950-multi-function-pci-express-pcie-connectivity-with-display-controller-chip/ Wurde beim "neuen" PC nicht mehr eingebaut. Geht über USB und Dongle. Wie meistens heute. Und da können Probleme liegen: Axel S. schrieb: > Das Modul ist ja sicher "made in China", da kann man sich nicht darauf > verlassen, daß es richtig beschriftet ist. Ruhepegel ist H. Evtl. > braucht das Modul auch einen Pullup an TxD. ciao gustav
:
Bearbeitet durch User
Hmmm schrieb: > Christian schrieb: >> Nach längerem herumprobieren hab ich rausgefunden, dass TXD am Kabel >> immer HIGH zu sein scheint > > Das gehört so, Ruhelage ist High-Pegel. > > Christian schrieb: >> sobald ich aber ein HIGH Signal an den RXD des Atmega88 anlege, empfange >> ich nichts. > > Kurzschluss zwischen TXD- und RXD-Pin? Das war die Lösung! Die TxD- und RxD-Pins des ATmega88 waren kurzgeschlossen (gemessener Widerstand: 200 Ohm). Mit einem anderen Exemplar funktioniert die UART-Kommunikation wieder einwandfrei. Herzlichen Dank! Ich möchte mich an dieser Stelle bei allen Teilnehmern dieses Threads bedanken und mich bei jenen entschuldigen, die durch meine ungenaue Problembeschreibung Frust empfunden haben!
Christian schrieb: > Das war die Lösung! Die TxD- und RxD-Pins des ATmega88 waren > kurzgeschlossen (gemessener Widerstand: 200 Ohm). Einen noch: solche Buskollisionen kann man mit einem Oszilloskop ganz prächtig erkennen. Christian schrieb: > durch meine ungenaue Problembeschreibung Wegen dieses Kurzschlusses wird dein µC übrigens sicher nicht an der von dir berichteten Stelle im Programm hängen bleiben. Denn der Sendeeinheit des µC ist es schnurzegal, was am µC-Pin passiert. Sie schiebt einfach Bit für Bit raus und wen sie fertig ist, wird das UDRE Flag gesetzt.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Christian schrieb: >> Das war die Lösung! Die TxD- und RxD-Pins des ATmega88 waren >> kurzgeschlossen (gemessener Widerstand: 200 Ohm). > Einen noch: solche Buskollisionen kann man mit einem Oszilloskop ganz > prächtig erkennen. > Ein ordentliches Oszilloskop kostet mir zu viel für mein Hobby, vor kurzem habe ich von Handoszilloskopen erfahren welche im Vergleich sehr günstig sind, z.B.: https://www.reichelt.at/at/de/shop/produkt/handheld-oszilloskop_200_khz-364853 Sind solche brauchbar? > Christian schrieb: >> durch meine ungenaue Problembeschreibung > Wegen dieses Kurzschlusses wird dein µC übrigens sicher nicht an der von > dir berichteten Stelle im Programm hängen bleiben. Denn der Sendeeinheit > des µC ist es schnurzegal, was am µC-Pin passiert. Sie schiebt einfach > Bit für Bit raus und wen sie fertig ist, wird das UDRE Flag gesetzt. Ich glaube du hast das "nicht" überlesen: Christian schrieb: > Der Code bleibt nicht! in der while Schleife hängen, das habe ich schon > getestet.
Christian schrieb: > Sind solche brauchbar? Auf jeden Fall besser, als gar keins zu haben. Das Vorgängermodell DSO-150 (ohne Akku) bekommst du deutlich günstiger.
:
Bearbeitet durch User
Christian schrieb: > Sind solche brauchbar? Mit 200kHz Bandbreite siehst Du nicht viel. Besser das hier: https://www.pollin.de/p/owon-lcd-oszilloskop-mit-multimeter-hds242-2-kanal-40-mhz-830955 Dazu gibt es hier auch schon ein paar Threads.
> oszilloskop_200_khz-364853 > Sind solche brauchbar? [] Brauchbare Oszilloskope erkennt man an: "HP", "Tektronix" & "Rhode&Schwarz". Alles andere sind nur pillike Imitationen.
:
Bearbeitet durch User
Motopick schrieb: > Brauchbare Oszilloskope erkennt man an: "HP", "Tektronix" & > "Rhode&Schwarz". Wo hast du denn diese angestaubte Herstellerliste ausgegraben?
Rainer W. schrieb: > Wo hast du denn diese angestaubte Herstellerliste ausgegraben? Wie kommst du auf "angestaubt"? :) Koennen 400 MHz Bandbreite ueberhaupt einstauben? Das ist deutlich mehr als die angepeilten "200 kHz". Und sicher angenehmer in der Handhabung, als eine "Plasteschachtel" mit einem "Maeusekino".
Damit der nächste Atmega nicht gleich wieder Durchbrennt: Beschäftige dich mit Potentialunterschieden durch ungeerdete Netzteile. Wenn dein Computer oder deine Schaltung an so einem hängt, entlädt sich die energie der Entstörkondensatoren beim anstecken unter spannung in deine Atmega-Pins und brennt diese durch. Solche nackten chips und dev-Boards sind im gegensatz zu schnittstellen wie USB oder Ethernet, nicht zum anstecken unter spannung geschützt. Solange GND sicher verbunden bleibt ist aber alles tutti. Aber bitte kommt jetzt niemand wieder mit "Gleichtakt-Störungen"
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.