LEDschaltung im PingPong

[Quadro24]

Mag sein, mir ist auch klar, dass die beiden 4094 keine wirklichen Treiber sondern so ziemlich das schwächste dafür mögliche IC sind. Trotzdem ist diese Platine ein ziemlicher Renner gewesen und ist es immer noch - und wird von vielen als Anzeige benutzt. Das Ganze neu aufzubauen ist auch keinesfalls mein Ziel (das hätte ich anders gemacht) - ich habe eben aus meinem Fundus eine passende Platine genommen um eine Anzeige für Distanzen über 1m zu bekommen. Die - mögliche, bisher nicht erkennbare - Überlastung ist ja auch nicht das Thema meiner letzten Postings. Das aktuelle Thema ist die Funktion der seriellen Schnittstelle "mal gehts, mal nicht" - und da bin ich ziemlich sicher, dass der Grund für diese Erscheinung nicht in/an den Schieberegistern liegt.

Trotzdem danke für Deinen Kommentar, Du hast damit sicher Recht.

Sollte auch keine direkte Kritik gegen das ganze darstellen. Dass es eine tolle Idee ist und sowas unzählige Leute nachgebaut haben kann ich mir gut vorstellen, dafür auch Hut ab!

Zu dem Problem:
Leider Blick ich gerade durch die ganzen Posts nicht ganz durch. Falls du noch einmal kurz Zusammenfassen magst was GENAU nicht funktioniert und vielleicht auch das ein oder andere Bild / Schaltplan mitliefern magst, kann ich mir das ganze mal anschauen. Ich weiss ich könnte mich auch durch das ganze Thema hier lesen, aber meine Faulheit an einem Freitag Mittag ist dafür zu gross :P

Alternativ könnte ich dem roboternetz hier auch einen neuen Schaltplan zur Verfügung stellen mit einer von mir entwickelten 8x8 LED-Matrix mit Transistor ansteuerung, basieren auf einem PIC Mikrocontroller. Beispielsoftware hätte ich auch rumliegen.

Das ganze wurde vor rund 2 Jahren von mir im zweiten Lehrjahr realisiert, habe das Teil seitdem nicht mehr benutzt, liegt aber noch alles rum... Falls daran interesse bestehen sollte.
Es wäre auch relativ leicht erweiterbar um ein paar Zeilen/Spalten.

[oberallgeier]

Hallo Quadro24!

... noch einmal kurz Zusammenfassen magst was GENAU nicht funktioniert ... meine Faulheit an einem Freitag Mittag ...

Das kann ich gut nachfühlen, danke auf alle Fälle für Deine Mühe! Ach ja - ich will/werde mir keine derartige Platine/n anfertigen.

Platine 1 mit mega1284p/20 MHz sendet per UART Datentelegramme zu je 3 signifikanten Bytes an ein oder zwei LED-Display/-s ( 1 oder 2 ! ). Verfügbar sind mittlerweile drei LED-Platinen, mega8 im Original, mega168 oder 328 bei den Modifikationen(=Reparaturen), interner Oszillator 8 MHz, Kommunikation mit 56 kBd. Verbindungen NUR: Platine1<=>LED-Platine/n über Gnd-Gnd, Vcc-Vcc sowie Platine1-Tx nach LED-Display-Rx. Versorgung Netzteil 9,9 V, Strombegrenzung 1,5A. Platine 1 hat einen 78S05, frisst ohne LED-Platinen <100 mA. Die LED-Platinen benötigen einzeln lt (der trägen) Netzteilanzeige < 15 mA selbst wenn alle LEDs sichtbar sind - das ist im Introtest, siehe Video, erste Sekunde. Schaltplan der LED-Platine hier.

Gute Funktion wenn:
a) an Platine1 hängt/hängen eine oder zwei LED-Platine/n mit je einem (alten) mega8/TQFP (Originalplatine).
b) an Platine1 hängt/hängen eine LED-Platine mit nem (alten) mega8/TQFP und eine mit nem Ersatzcontroller (neu aufgelötet) mega168/TQFP
c) an Platine 1 hängt eine LED-Platine (NUR eine) mit einem Ersatzcontroller (neu aufgelötet) mega328p/TQFP

Verbindung gestört wenn:
d) an Platine 1 hängen zwei LED-Platinen, eine mit mega8 oder mega168 und dazu eine mit mega328. Dabei wird NUR die Anzeige der 328er Platine gestört.

Im Fall a), b) und d) hängen beide LED-Platinen an ein und demselben Tx der Platine 1! Fall a) mit zwei mega8 war der frühere Zustand, ich habe nur noch eine Platine mehr mit nem mega8.

Die Störung zeigt sich nicht im lokal erzeugten Intro der 368-er-LED-Platine. Erst nach ordnungsgemäßen Ablauf des Intros (siehe Video - Schräglinie, ganzes Feld, alle Ziffern) zeigt >>nur<< die 368-er-LED-Platine unsystematisch verschiedene LEDs, reagiert nicht auf gesendete Telegramme etc. Auch der Empfang eines gesonderten Signals von einem USB-UART-Umsetzer (GND stets bei allen Beteiligten verbunden) wird nur auf den nicht-328er-Platinen ordnungsgemäß verarbeitet - d.h. dort werden auch im Verbundbetrieb stets die gewünschten Ziffern oder einige Sonderzeichen angezeigt.

Ein Test mit DSO steht noch aus, wird in den nächsten Stunden aufgebaut; ich hab nur ein analoges und hier muss ein single shot her.

Ist das Problem jetzt klarer?

Anmerkung: ich weiß schon, dass die Versorgung von zwei Rx-en an einem Tx keine vorschriftsmäßige oder spezifikationsgerechte Anschlussart ist.

[Quadro24]

Kein Problem, man versucht sich ja schliesslich zu helfen.

Eigentlich würde ich jetzt hier gerne Abschnitt für Abschnitt Zitieren, aber die Forensoftware überfordert mich noch ein bisschen, also mach ich das mal ohne.

Zu beginn: Ja, der Problem ist nun klar. Danke für die tolle Zusammenfassung.

Das hört sich schon alles sehr merkwürdig an. Also dass zwei Controller an einem TX hängen dürfte das Problem nicht ausmachen. Das UART Modul dürfte den Strom für die beiden noch problemlos treiben können.

Hört sich auch alles gut verbunden an, daran dürfte es also auch nicht liegen. Zuerst habe ich vermutet der 328 tanzt mit der Baudrate aus dem Takt und Empfängt deswegen die Daten falsch, allerdings scheint dieser ja zu funktionieren wenn nur der dranhängt.

Ich mag das Problem jetzt noch nicht zu genau analysieren. Ich warte erst einmal auf die von dir angekündigten Bilder des DSO ab, vielleicht erkennt man schon darauf einen Fehler (Keine sauberen / zu langsame Pegel).

Sobald die Bilder da sind werde ich mir das ganze auf jedenfall anschauen und ggf. dann mit der Fehlersuche beginnen. Aber so spare ich mir vielleicht unnötige Arbeit, falls man direkt etwas erkennen sollte. Also, sobald du die Bilder hast, hoch damit!

Dann melde ich mich wieder
Den Fehler finden wir!

[RoboHolIC]

@oberallgeier:

Als allererstes würde ich alle UART-Teilnehmer mit wirklich geeigneten, nämlich stabilen, Taktquellen ausstatten.
Bei einer Insellösung wie der deinen können das anstelle der klassischen Seriell-Quarzfrequenzen natürlich auch die "geraden" Frequenzen sein, wenn sie nur überall gleich bzw. kompatibel bzgl. Vorteilerwerten der Baudratenteiler sind.

Ich vermute, dass der Fehler bei der Frequenzstabilität liegt. Erlaubte Frequenzabweichungen werden bei meiner Web-Quelle (selber hab ich es noch nicht gerechnet) mit < 0,2% benannt. Dein interner Oszillator, zumindest auf Platine 1, wird diese Forderung nicht zuverlässig einhalten, da er neben der vergleichsweise großen Grundabweichung aller Wahrscheinlichkeit nach auch merkliche Temperatur-und Betriebsspannungsabhängigkeiten aufweist.

Dass alle Kommunikationspartner einzeln funktionieren, beweist ja, dass du SW-technisch alles (ausreichend) richtig gemacht hast.
Wahrscheinlich laufen einzelne UART-Kombinationen auf Kante und scheitern erst bei der Summe mehrerer Faktoren.

[Klebwax]

Ich vermute, dass der Fehler bei der Frequenzstabilität liegt. Erlaubte Frequenzabweichungen werden bei meiner Web-Quelle (selber hab ich es noch nicht gerechnet) mit < 0,2% benannt.

Auch wenn es eine "Web-Quelle" ist, ist es so nicht richtig. Ein UART synchronisiert bei jedem Symbol neu. Und da eine Symbol meist aus 10 Bit besteht, könnte es noch bei 10% Abweichung zwischen Sender und Empfänger funktionieren. Im praktischen Betrieb sollte man unter 3% bleiben. Ich würde zuerst woanders suchen, solange die Übertragung einzeln funktioniert.

MfG Klebwax

[Bumbum]

Hallo,

also ich habe auch nur schlechte Erfahrungen mit UART ohne Quarz gemacht. Da der Takt von einem RC-Glied erzeugt wird, könnte es ja sein, dass durch die höhere Belastung der Versorgung durch das zusätzliche Modul der Takt soweit aus der Toleranz läuft, dass es nicht mehr funktioniert.

Ich würde auch erst mal allen Platinen Quarze spendieren.

Viele Grüße
Andreas

[oberallgeier]

... Ein UART synchronisiert bei jedem Symbol neu. ... könnte es noch bei 10% Abweichung ... funktionieren ...

So sehe ich es im Prinzip auch. Die Spannung wird auch bei höherer Auslastung ziemlich konstant sein. Schaun wa mal: zwei Module statt einem oder: statt des Verbrauchs von ca. 120 mA für den Controller werden hinterm 78S05 pro Modul zusätzliche ca. 15 mA fällig; der Spannungsregler ist ausgangsseitig mit 100nF plus 220 µF abgepuffert.

Versuch einer Messung der Frequenzwanderung bei unterschiedlichen Eingangsspannungen:
Die Platine hat - wie bei mir praktisch immer - eine Heartbeat-LED. In diesem Fall blinken die LEDs unten-aussen wie immer im Sekundentakt. Dieser Heartbeat ist interruptgetrieben vom TIMER0 OVF, der 250µs-Interrupts getickert wird. Variiert wurde die Eingangsspannung, die an der Eingangsdiode bei 4,04V um 0,730V und bei 5,44V um 0,890V abgeschwächt wird.
Versorgungsspannung der Platine .......... Takte .......... Zeitbedarf
.......... 4,04 Volt ................................. 100 .......... 1min 44,77 sec
.......... 5,00 Volt ................................. 100 .......... 1min 43,66 sec
.......... 5,45 Volt ................................. 100 .......... 1min 43,32 sec

Sieht nicht sooo variabel aus, rund 1 % Änderung. Da müsste der Betrieb unter "normalen" Umständen schon sehr grenzwertig sein.

[oberallgeier]

Nur mal so, als Wochenendprojekt(chen). Die PingPong-Platine vom Posting oben (2014 ! ) liegt noch immer unbenutzt rum, weil sie nach Tausch mega8=>328p wie beschrieben nicht störungsfrei lief.

Eher als Spielerei jetzt von meinem eben eingetroffenen 50erStreifen Resonatoren CSTCE20M 20 MHz (aus dem Reich der Mitte) ein Stückchen bedrahtet (na gut, eins ist im Teppichboden auf Nimmerwiedersehen verschwunden) und mit der PingPong verlötet. Die Anschlüsse B6 und B7 sind ja XTAL1 und XTAL2. Keine Überraschung - es läuft primstens, sogar die UART tickert brav - ohne Quelltextänderung, dafür aber auf 140 kBd statt auf den 56000 Bd (Faktor 2,5: 8 MHz nach 20). Die GND-Leitung wurde in Resonatornähe mit UV-gehärtetem Flüssigkunststoff fixiert. Alles simpel und störungsfrei. Nun nur noch im Quelltext die Frequenz anpassen.

......Bild hier  

......© oberallgeier. Größeres Bild in der Vorschau verlinkt.