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?
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.
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.
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.
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?
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".
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.
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.
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.
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.
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
ständig irgendwelche bekannten Zeichen sendet (0xaa und 0x55 sind da beliebte Muster), und parallel dazu
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.
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
ständig irgendwelche bekannten Zeichen sendet (0xaa und 0x55 sind da
beliebte Muster), und parallel dazu
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.
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!
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.
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.
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.
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!!!
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:
Was hat eine LPT-Schnittstellenkarte mit dem Problem des TO zu
tun?
Lies doch richtig:
Karl B. schrieb im Beitrag #7835594:
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:
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.
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!
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.
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.
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"
