LEDschaltung im PingPong

[Quadro24]

Die Widerstände sind so, das eigentlich immer nur eine LED pro Zeile gleichzeitig Leuchten sollte. Das passt auch zum langsamen Schieden des Schieberegisters. Der Bildaufbau erfolgt also Spalte für Spalte. Wegen der relativ schwachen Treiber der 4094 (wohl 74HC4094) wird es aber mit mehr als 1 LED Gleichzeitig schon schwer.

Besser wäre es aber gewesen die Widerständen an die 4094 zu machen (halt 2 mehr) und dann Zeilenweise das Bild aufzubauen - die Treiber des AVRs sind meist etwas kräftiger als beim 4094. Dann wäre auch eine Ansteuerung per SPI Hardware besser.

Der C Code wird ggf. noch etwas schneller wenn man wenn möglich lokale Variablen in der ISR nutzt.
Es sollten auch etwa 120 Hz Widerhohlfrequenz ausreichen - die nötige Rechenzeit für die Darstellung reduziert sich damit auf etwa 1/3.

Generell ist die Schaltung ein bisschen Fragwürdig.

Wenn das Teil wirklich dafür vorgesehen ist, wie eine normale Matrix betrieben zu werden gibt es einiges zu Bemängeln.
Schaltet man Beispielsweise Spalte für Spalte, so dass die LED eigentlich immer nur kurz an und ab geht, das allerdings so schnell das ein Bild für das Menschliche Auge ersichtlich wird, so weiss ich nicht wie gut das dem ATMega tut. Denn Pulsbetrieb bedeutet auch Pulsströme und bei 12 Spalten nimmt der Strom dann auch erheblich zu.

Am schlausten wäre es die ganze high-side geschichte nicht direkt an den uC zu hängen sondern das ganze zu überarbeiten und da eine Treiberstufe dazwischen zu schalten. Einfache Transistoren würden schon reichen und man könnte auch Problemlos mehrere LED's gleichzeitig leuchten lassen.

[oberallgeier]

Generell ist die Schaltung ein bisschen Fragwürdig ... gibt es einiges zu Bemängeln ...

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.

[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