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
(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)
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!
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.
...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.... ?!
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 ...
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 :-)
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
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.
....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....
:-)
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!
