7-Segmentanzeige mit Farbsteuerung

[hardware.bas]

Nach dem Studium des PDF-Datasheetes der RGBDIGITs hats jetzt bei mir
etwas Klick gemacht. Andere sind warscheinlich schon weiter und könnten
mich korrigieren. Also, offensichtlich läuft der Spass folgendermassen ab:
- Es werden 24-bit Datenpakete mit 800kbit/s benötigt
- Jede Bitinfo beginnt mit H und endet mit L
- L- und H-Bits werden durch das unterschiedliche H/L Verhältnis bestimmt
- Ub und Takteingang haben 5V, also TTL-Pegel
Diese Informationen dürften reichen, um einige RGBDIGITs zu bestellen und
den Rest, falls nicht schon jemand mehr weiss, empirisch rauszukriegen,
ohne die Bauteile zu schädigen. Mt einem teilautomatisierten BASCOM-
Programm und einen ATiny mit 16-Bit-Timer, sollten dann folgende
restlichen Fragen zu klären sein:
- genaue Zuordnung der Bits zur Funktion
- wieviel 24-Bit-Datenpakete pro Anzeigedigit
- muss permanent mit Daten refresht werden oder nicht
- könnte man Daten aus dem letzten PinOut sinnvoll nutzen
Es wird daraufhin die Entshidung fallen, ob die komplette
Anzeige über den Hauptchip des eigentlichen Systems oder
über einen eigenen ATiny bedient wird.
VG Micha

[Ceos]

Um Siro hier nochmal zu zitieren, es ist nur wichtig dass die Zeit der H-Phase stimmt, die L-Phase kann deutlich länger ausfallen als im Datenblatt beschrieben! Du musst dir also nciht unbedingt einen abbrechen die Bits auch bei 800kHz raus zu senden, solange du nur die einzelnen H-Flanken richtig machst.

Zu deinen Fragen:

- eine 7-Segment Anzeige hat wie der Name es verrät 7 Segmente (eventuell noch ein 8tes für einen Punkt wenn denn einer verbaut ist)
- die Segmente werden über eine Standardisierte Reihenfolge angesprochen mit der Segmentbezeichnung a,b,c,d,e,f,g (evtl. h für den Punkt), wie die verteilt sind verrät die Wikipedia oder ein beliebiges Elektronik Buch
- ein refresh ist nicht nötig, solange du die Pulsleitung low hälst, das Datenblatt sagt eine Pause von mind. 50µS bevor die LEDs sich automatisch mit den eingepulsten Daten updaten!

-von welchem letzten PinOut sprechen wir hier?

Nimm dir einfach folgende Daten als Hilfestellung:

1/800kHz = 1.25µS * 24Bits/LED = 30µS/LED * 7( Segmente/7SegModul = 210(240)µS/7SegModul

Wie ich schonmal geshrieben habe, musst du also nurnoch einen Kompromiss finden, wie oft du das Display aktualisieren können willst, die Zeit zum senden der Daten in Abhängigkeit der anzahl verwendeter Module von der Zeit zwischen 2 aktualsierungen abziehen und bewerten ob die verbleibende Zeit für deine restlichen Programmaufgaben ausreicht

[hardware.bas]

Habe eben auch noch mal ins Datasheet geschaut. Pro Digit werden 24 Bit gesendet, danach mindesten 50 microsec Low.
Bei mehreren 24 Bit-Pakten wertet das höchste Digit das erste Paket aus und blendet dies dann bei der Weitersendung aus.
Für das nächste Digit ist das ursprünglich 2te dann das erste usw .
Warscheinlich wird bei 8 Stellen und 8 Datenpaketen dann beim letzten PINout nix mehr rauskommen, weil sie dann
alle benutzt und ausgeblendet wurden.
Auf Grund des Timings und der möglichen Toleranzen, sollte eine Taktfrequenz von 10MHz für den Ansteuerchip
problemlos ausreichend. Bi optimistisch, langsam lösst sich der Knoten
VG Micha

[Ceos]

danach mindesten 50 microsec Low

Vorsicht, nicht dass du das falsch verstehst:

wenn du bits sendest, schnabuliert jede einzelne LED nacheinander 24bits und sendet die nachfolgenden bits einfach weiter ohne hinzusehen (daisy chain ... von daisy duck der schnattertante)

wenn die erste LED in der reihe aber für mindestens 50µS ein low sieht, latcht sie die 24bits in das PWM register und stellt die Farbe dar udn warte auf frische 24bits ... wenn du also scho nachd er ersten LED eine 50µS pause machst, aktualisierst du immer nur die erste LED und die weiteren LEDs sehen niemals je ein bit.

Hoffe das sit so ausführlich genug erklärt

bei 10Mhz hättest du 12.5 Rechentakte pro ganzem Puls Zeit, da musst du aber schon ordentlich optimieren, geh mal lieber auf 16Mhz für 20 Takte

[Siro]

Nach deinem letzten Datenbit bleibt einfach die Datenleitung auf Low. Wie lange spielt dabei keine Rolle.
Kannst sie also auch dauerhaft auf Low lassen, wenn sich nichts in der Anzeige ändern soll.
Die Information bleibt in den Chips erhalten. Du must also erst wieder eine "komplett" neue Kette reinschieben
wenn sich etwas in der Anzeige ändern soll.
Alle LEDs schieben zunächst ihren Daten wieder raus zur nächsten LED und ändern noch NICHT den zuletzt angezeigten Wert bis die etwas längere Pause kommt.
Erst dann werden ALLE Daten übernommen und angezeigt.
Man schiebt also zuerst die Daten für die letzte LED rein, dann für die vorletzte usw.
Die Daten für die erste LED werden demnach als letztes reingeschoben. Dann folgt die lange Pause die mindestens 50us sein soll
aber auch ewig lang sein darf.

[Ceos]

Man schiebt also zuerst die Daten für die letzte LED rein, dann für die vorletzte usw.

das ist falsch! ... zumindest wenn es "normale" WS2812 sind, kann sein dass in dem modul die segmente anders herum verdrahtet sind, das habe ich jetzt nicht nachgeprüft, aber bei normalen WS2812 werden pro LED 24bits veschluckt und dann jedes weitere bit einfach weitergleitet, bis zum übernahmesignal (mind. 50µS low) und danach wartet die LED wieder auf 24 frische bits und jedes weitere wird dann wieder weiter getratscht

[Siro]

Sorry, Du hast recht Ceos, ich hab zuviel mit den 595er geschoben....

[hardware.bas]

War ein Denkfehler von mir, denn für PWM und Segmentauswahl brauche ich
ja 2 Byte pro Farbe, also müsste ein 24-BIT-Paket bei einer 8-stelligen
Anzeige 64mal gesendet werden. Es müsste in Anlehnung des Datasheets
allerdings noch mehr, als die 50 microsec als Synchronisations und Bitmuster-
trennungen geben. Für moderate 1 sec - Anzeigeänderungen immer noch
akzeptabel, da muss der AVR eben knapp 200ms extrem fleissig sein, das
erschlage ich noch mit meinem Lieblingscompiler (andere beherrsche ich
eh nicht), Bei der Taktfrequenz hatte ich folgende Berechnungen angestellt;
Ohne Toleranz brauchen wir ein Taktraster von 50ns, also 20 MHz, bei
Ausnutzung der vollen Toleranz 200ns, also 5 MHz, der Mittelwert also
10 MHz, schnellere, als laut Datasheet mögliches "Reinschiessens" des
Datenstreams funktioniert warscheinlich eh nicht.
Das ist der Stand der Dinge, zumindest bei mir.
VG Micha