Hallo in die Runde! Ich suche seit Tagen die Ursache für folgenden Fehler: Ich habe mit einem Arduino Nano (und Pro Micro) mittels Software-Uart problemlos die Signale eines SmartMeter-IR-Kopfs auslesen können. Keine Fehler, keinen Datenverlust. Da die Daten in meinem kleine Projekt nach der Auswertung noch gespeichert (eeprom) und dann auf SD-Karte ausgegeben werden sollen bin ich auf einen Arduino Mega 2560 (Clone) umgestiegen (echte Usart, mehr Speicher usw). Die per i2c angebundenen eeprom und RTC laufen problemlos, der SD-Kartenleser erst nachdem ich einen Levelconverter (mit TXS0108E) dazwischen geschaltet habe. Während der Programmentwicklung hab ich vom PC per Python-Programm mittels FTDI-USB-Serial-Adapter (FT232RL) einen Datenstrom vom SmartMeter simuliert. Dieser wurde auch ohne Probleme vom Atmega-Hardware-Uart eingelesen/verarbeitet (egal bei welchem). Sobald ich aber den echten Lesekopf (sowohl BitShake als auch von volkszaehler) anschließe kommt beim Atmega-Uart nur Datenmüll an. (Die Leseköpfe sind ok, denn die "kleinen" Atmegas als auch ein Rasp Pi Pico lesen (mit gleichem Kopf, gleichem Kabel) saubere Daten ein). Ein Zwischenschalten des Levelconverter (mit TXS0108E) bringt keine Verbesserung auch ein Schaltung per Mosfet bringt nichts. Es kommen nur verstümmelte Daten an (damit CRC-Fehler). Gleiches Problem mit einem anderen Board mit Atmega256! Daher meine Fragen an Euch: Ist ein problematisches Verhalten bei den Hardware-Uarts und/oder SPI-Pins vom Atmega256 bekannt? Er sollte doch "normale" 5-V-Signale analog den "kleineren" Atmegas verarbeiten können? Hat jemand eine Idee oder Erfahrung, wie eine Schaltung aussehen könnte, die saubere Daten beim Atmega256 ankommen? Vorab schon ein "Danke" für Eure Bemerkungen! Grüße Stefan
Schaltplan zeigen. Bild vom Aufbau zeigen.
Angehängte Dateien:
-
PXL_20230801_162645616.jpg
230 KB
Hallo! (Sorry für die Verzögerung - als NewBie in dem Forum hab ich eine Zeitsperre) Einen Schaltplan habe ich noch nicht gezeichnet bzw. nur als Bleistift-Skizze. Anbei der Aufbau als Bild. Per RJ11-Anschluss gehen die Daten direkt zum UART-PIN! Das gleiche Problem habe ich aber auch wenn der RJ11-Anschluss ohne Breadboard direkt an den Uart-RX-PIN geht (beide 256er-Boards)
Stefan H. schrieb: > Per RJ11-Anschluss gehen die Daten direkt zum > UART-PIN! Und wo ist das, was am RJ11-Anschluss dranhängt, mit Masse verbunden? Ohne Masse als gemeinsames Bezugpotential funktioniert keine Datenübertragung.
Masse ist angeschlossen. Unter dem Stecker/auf dem Bild nicht sichtbar.
kann ich mir nicht vorstellen! Gleicher Sensor wird mit gleicher Beschaltung (Ground, 5Volt + RX-PIN) bei Atmega32/Rasp Pi Pico korrekt ausgelesen. Der FTDI-Adapter funktioniert (Gnd+ TX FTDI an RX Controller) und übermittelt korrekte Daten - an die Schnittstelle des Atmega256!
> mit einem Arduino Nano (und Pro Micro) > bei Atmega32/Rasp Pi Pico korrekt ausgelesen > einen Datenstrom vom SmartMeter simuliert Dieser 'simulierte Datenstrom' wird auch von den Erstgenannten korrekt gelesen?
Ja, gleicher Aufbau (FTDI), gleiche Kabel, gleiche Datenstrom. Alle Boards (auch 256er) bekommen Daten und werten korrekt aus. Gleicher SmartLeser-Kopf, gleiche Kabel, gleicher Aufbau/Verkabelung: Alle Boards außer(!) die 256er bekommen Daten, werten korrekt aus und CRC stimmen! Daher meine Frage, ob jemand die Erfahrung gemacht hat, dass der Atmega256 bekannte Zicken hat oder Besonderheiten bzgl. dem Anschluss an den UARTS zu beachten sind!? Hab nirgends Hinweise dazu gefunden?! Da der RaspPi Pico kein Probleme macht und genug Speicher und PINs / Schnittstellen hat werde ich wohl meine Software für den RaspPi umschreiben.
> Atmega256 bekannte Zicken
Welcher Art könnten diese 'Zicken' sein, wenn der simulierte Datenstrom
korrekt gelesen wird? Ich vermute eher einen Verdrahtungsfehler.
...ich vermute auch ein eher "analoges" Problem auf der Leitung (Jitter, Echo, falscher Spannungslevel auf dem RX-PIN?). Was mich fuchst ist die Tatsache, dass nur die Kombination 256er und IR-Kopf nicht harmoniert - und anderen Boards mit gleichen Kabel, Stecker etc keine Probleme machen.... ?!
Wird im Programm auf Übertragungsfehler abgefragt, d.h. FEn und DORn? Und wenn ja, tritt einer der beiden auf?
Nein, bisher nicht. Wie kann ich diese abfragen? Ich nutze bisher die Arduino-Lib-Funktionen SerialX.xyz .... Mein Programm "merkt" erst beim CRC-Check, dass einzelne Bits oder ganze Bytes(?) verloren gegangen sind.
> Wie kann ich diese abfragen?
Das muss jemand beantworten, der Arduino kennt - ich gehöre leider nicht
zu diesem Kreis.
Danke trotzdem für den Tipp! Ich suche weiter :-) schönen Abend noch!
Klar - 9600/8N1 ! sowohl vom Lesekopf als auch vom FTDI
Wo kommen die +5V für den Lesekopf jeweils her? LG, Sebastian PS: Ich glaube du meinst Atmega2560 bzw. Atmega328P, nicht Atmega256 bzw. Atmega32?
:
Bearbeitet durch User
Ja, mit Atmega2560 bzw. Atmega328P hast Du Recht! War unpräzise! Stromversorgung kommt originär über USB, Sensor VCC kommt vom der Arduino- Board 5V! GND kommt auch vom A-Board
Im ersten Beitrag schreibst Du Stefan H. schrieb: > mittels Software-Uart Nutzt Du die auf dem Atmega2560 ebenfalls, oder hast Du das auf einer der Hardware-UARTs umgestellt?
Ich wüsste nicht, dass Serial1/2/3 auf dem Arduino Mega 2560 Probleme machen. Wenn du die SPI-Schnittstelle benutzt (also TwoWire.h), dann mag es nötig sein, vorher pinMode(53,OUTPUT) aufzurufen. Aber es ist lang her, dass ich was mit dem Arduino Mega 2560 gemacht habe, und womöglich wird das inzwischen auch schon von der Arduino-Bibliothek gemacht ... LG, Sebastian
Hallo! Ja auf dem Arduino Nano hab ich noch Software-Seriell genutzt und hab bei größerer Last Probleme bekommen (Puffer scheint durcheinander zu kommen,) Daher der Wechsel zum Arduino2560 mit "echten" Hardware-Seriell!
Danke Sebastian! Ich wollte mit meinem Beitrag die Runde nur rückversichern ob ich an einem allgemein bekannten Problem scheitere oder wohl eher an meinem Aufbau/Auswahl Komponenten liegt! (Was ich nun eher vermute) Ich denke, ich verschwende keine Zeit mehr mit dem Atmega sondern mach meine Portierung auf dem Rasp Pi Pico weiter! Da der Code nur an wenig Stellen wirklich Hardware-abhängig ist dürfte das bald erledigt sein und läuft schon zum Teil! Auf zu neuen Ufern :-) Danke+VG Stefan
Stefan H. schrieb: > Ich denke, ich verschwende keine Zeit mehr mit dem Atmega sondern mach > meine Portierung auf dem Rasp Pi Pico weiter! Äh, das ist nicht sinnvoll. Denn Du hast da entweder ein Hardwareproblem mit Deinem Aufbau oder aber ein Softwareproblem. Die durch Vermeidung zu umgehen, hilft zwar unmittelbar das Ziel zu erreichen, lässt Dich beim nächsten Auftreten von Problemen aber genauso hilflos zurück. Finde den Fehler. Nimm ein Oszilloskop, sieh Dir an, wie das Signal aussieht. Sieh Dir zum Vergleich an, wie Dein mit einem FT232 erzeugtes Alternativsignal aussieht. Verwendest Du auf dem RP2040 ebenfalls Softwareserial oder eine Hardware-UART? Hast Du geprüft, ob Deine Variante mit dem Arduino Nano auch mit Deiner vom FT232 erzeugten Simulation funktioniert?
Ich benutze auch die 4 UARTs des ATmega2560, sie funktionieren einwandfrei. Ich hab mir allerdings nicht irgendwas aus dem Web geladen, sondern die FIFOs selber programmiert, ist ja nicht aufwendig. Ich benutze ein Baudratenquarz 14,7456MHz, damit gehen auch hohe Baudraten ohne Rundungsfehler: 14,7456MHz / 16 / 230400 Baud = 4,0
Kann gut sein, daß Dein SmartMeter TTL-Pegel liefert, der PC liefert aber RS-232 Pegel, d.h. ein invertiertes Signal. Bei einer SW-UART kann man oft einstellen, ob invertiert oder nicht, bei der HW-UART ist das fest. Miß einfach mal die Spannnung an TXD im Ruhezustand. TTL: +3V .. +5V RS-232: -6 .. -12V
Ein Oszi hab ich noch nicht hingehängt! Hab bisher noch wenig Übung/Erfahrung... Könnte ich mal vergleichen mit dem FTDI-Signal! Zu den weiteren Fragen! Rasp Pi Pico läuft mit HW-Uart und FTDI läuft am Nano und dort SW-Uart!
Danke für die Tipps! IR-Kopf liefert keine "volle" UART-Spannung sondern "nur" die TTL-Pegel vom Arduino-Board!VCC kommt von dort.. Laut Messgerät etwa 4,6 Volt
Stefan H. schrieb: > IR-Kopf liefert keine "volle" UART-Spannung sondern "nur" die TTL-Pegel > vom Arduino-Board!VCC kommt von dort.. Das sollte nicht das Problem sein; um als High-Pegel erkannt zu werden, muss ein Signal am Atmega2560 mindestens 0.6 * Vcc betragen. Wenn der Atmega mit 4.6 V versorgt wird, sind das knapp 2.8V.
Stefan H. schrieb: > Ein Oszi hab ich noch nicht hingehängt! Ohne ist das aber ein Ratespiel mit Zufallsserfolgen. Kein Oszi, kein HW debugger, nicht mal die Rohdaten aus dem uart angesehen. Nur aufs Ergebniss nach CRC geschaut. Sende von Deinem AVR aus Daten die man leicht analysieren kann. Nur 1 nur 0 oder 01 Wechsel, 0xFF, 0xAA, 0x00. Zähle die Frames mit dem Oszi aus und überprüfe ob ALLE Parameter stimmen. (9200bps, 8n1). Sei EXAKT bei der Zeitbestimmung des Frames und lese sorgfältig wie eine Uart Übertragung aufgebaut ist. Vergleiche wie Deine Übertragung aussieht und wie die der Gegenseite. Gleiche Daten, gleiche Pegel, gleiches Timing. Fehler sollten Dir so sofort ins Auge springen. Ungefähr die Länge eines 8n1 Bytes mit 9600bps reicht nicht. Erst dann kanst Du Dir sicher sein das der AVR auch genau das empfängt. Welcher Art sind die Fehler? Störungen verhageln einzelne Frames aber hin und wieder kommt das richtige an. Falsche Übertragungsparameter produzieren konstanten Datenmüll. Nein, es liegt nicht daran das die Uart HW nicht korrekt funktionieren würde. Der Uart ist ein so zentrales Element und Du macht etwas derart triviales damit, das solche Fehler als erstes auffallen würde. Außerdem gibt es für bekannte Bugs die chip errata, wenn Du dir unsicher bist. Anfänger suchen immer gleich beim Chip, haben aber vorher alle etablieretn Methoden ausgelassen ihre eigenen Fehler zu finden.
:
Bearbeitet durch User
....das dachte ich mir auch! Fehlende Spannungslevel vom Signal ist unwahrscheinlich! Ich stöpsel am WE mal das Oszi hin und werde mich dann vermutlich mit Grausen abwenden wenn ich den Signalverlauf sehe.... :-)
1. Warum brauchst du überhaupt zwei UARTs? Warum nicht RXD0 bzw. Serial? 2. Der Atmega328PB hat zwei HW-UARTs. Ich benutze darum den (im Pro Mini Formfaktor) um meine zwei Stromzähler auszulesen. LG, Sebastian
Hallo! Die Pro Mini in meinem Bestand haben einen Atmega328P (ohne B) und damit nur einen HW-Uart! Eine Schnittstelle für die Konsole/User-Interface/Programmierung, eine für den Sensor war mein Plan! Den Anschluss Sensor an Soft-Sio, RTC und eeprom per i2c funktionierte gut, für den Export auf SD-Card (SPI) wurde mir RAM/EPROM zu eng! Daher auch der Wechsel auf ein größeres Board!
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.