7-Segmentanzeige mit Farbsteuerung

[hardware.bas]

Ich werde die Problematik der Ansteuerung von RGB-DIGITs
nicht weiter verfolgen. Siehe Threed SHIFTOUT mit AVR-Clock
im BASCOM-Forum
VG Micha

[hardware.bas]

Nun, von der softwäremässigen Ansteurung werde ich mich
verabschieden. Mit dem DIGITALSIMULATOR ist jetzt ein
Projekt, leider noch nicht mit dem Lötkolben bestätigt,
entstanden, welches rein hardwaremässig mit eigenem
Quarzoszillator von 4,8 MHz funktioniert.
Der AVR braucht nur noch über 4 Portouts die Segment-
information inklusive 7-Farbsteuerung (mehr ist für das
Projekt nicht notwendig) alle ca 50000 nS 64x für
8 Stellen quasiparallel übertragen. Alles weitere, wenn
mein Netz wieder mal stabiler läuft.
VG Micha

[Crazy Harry]

Habt ihr euch mal den DIAMEX DIGI-DOT-BOOSTER angeschaut? Der steuert bis zu 256 WS2812-LEDs via SPI.

[hardware.bas]

Liest sich gut. Für eine 8-stellige Anzeige mit RGBDIGITs braucht man
sowieso nur 64 LEDs bedienen. Hab mir das Datasheet angeschaut,
scheint ja kein properitäres Protokoll zu haben anscheinend auch
ziemäich schnell vom AVR rüberzuschicken. Wäre da dann auch
eine gezielte Stellenadressierung vom AVR machbar?
VG Micha

[Crazy Harry]

Soweit mir bekannt, werden die Farbwerte der WS im Modul gespeichert bzw. verändert und durch den refresh komplett raus geschickt. D.h. du ändert eine Stelle und der Zustand der anderen Stellen ist ja noch im Modul vorhanden. Ich hab mir vor einiger Zeit mal 3 dieser Module besorgt und ein bisschen damit rumgespielt: funktioniert, wie beschrieben. Leider bin ich noch nicht dazu gekommen meine richtige Zielschaltung zu bauen: ein Türrahmen füllendes Tetris

[Siro]

DIAMEX DIGI-DOT-BOOSTER
Gefällt mir sehr gut, den kannte ich auch noch nicht

Da ist ein Prozessor von ST Microelectronics drauf mit ARM Cortex M0
Das Board bekommt man ja für unter 10 Euro.

Ganz Echtzeitfähig ist es zwar auch nicht, macht aber einen wirklich guten Eindruck
So wie es scheint, schiebt man die Daten zunächst mittels SPI Protokll zum DIAMEX Booster
dann folgt der Befehl zum Aktualisieren. BOOSTER_SHOW
Jetzt muss man ein geringe Zeit warten ca. 8ms.
Diese Zeit benötigt der Controller um alle Daten Timinggerecht auszuschieben,
Während dieser Zeit scheint er nicht den SPI Interrupt auszuschalten, deshalb
kann es zu Problemen kommen wenn man innerhalb der Ausschiebung zu den LEDs
erneut Daten sendet.
Das gleiche Problem hatte ich auch mit meinem PIC Controller.
Was aber nicht wirklich ein Problem darstellt.

Hier bekommt man unter anderem die Datenblätter:
https://www.led-genial.de/DIGI-DOT-B...elle-ansteuern


Würde sagen, absolut empfehlenswert, habe aber auch gelesen, dass es Softwarebugs geben soll.
Das kann ich aber nicht beurteilen, habe es selbst nicht ausprobiert.

Siro

[hardware.bas]

Das bedeutet, nach einem Flash von zB 64 Datenpaketen a 24 bit,
welche nicht weiter als 50 Mikrosekunden auseinanderliegen,
werden 64 RGBs bedient. Am Ausgang der letzten RGB sind dann
also alle Datenpakete "verbraucht", so ersichtlich im Datasheet.
Dabei dürften die einzelnen RGBs jedoch erst NACH Ablauf der
50 Mikrosekundenpause in ihrer "eigenen, aktualisierten" Farbe
aktiv werden, um "Falschflimmern" zu vermeiden, danach hält
die RGB ihren Leuchtstatus OHNE Nachflash.
Sollten zwischen den 24 bit Datenpaketen wesentliche längere
Pausen vorhanden wären, wäre Dieses ein neuer Nachflash.
Hoffe, ich habs jetzt geschnallt.
Da eine gezielte, direkte LED- oder DIGIT-Adressierung auf
Grund dieses "Datendurchschiebens" offensichtlich nicht
möglich ist, andererseits den Hauptprozessor der Anwendung
so zu entlasten, dass Dieser nur Anzeigeaktualisierungen
vornehmen muss, müsste die Anzeigeansteuerung den
gegenwärtigen Status der Anzeige speichern. Nach
Aktualisierung des/der LED(s) bzw DIGIT(s) müsste die
Anzeigeansteuerung entweder komplett oder zumindest
bis zur letzten zu aktualisierenden LED nachflashen.
Unter der Vorraussetzung, keinen Denkfehler gemacht
zu haben, da ich es noch nicht praktisch erprobt habe,
stellt sich jetzt, als Alternative zu einer reinen
Hardwarelösung mit nicht wenigen, jedoch schnellen
Digitalbausteinen und auch noch parallel ladbar eventuell
die Frage, mit den DIAMEX DIGI-DOT-BOOSTER, ohne
lästigen Programmierstress für diesen Einsatzzweck
schnelle praktische Ergebnisse zu erzielen.
Dann sind mir die 10 EUR das wert.
VG Micha

[Crazy Harry]

Nun daß diese WS2812 & Co. verflucht schnell sind, sieht man ja in zahlreichen Videos im Netz: hier bauen manche Bildschirme mit mehreren tausend dieser LEDs auf und zeigen auf diesen Videofilme.

Ich selber habe mir mit APA102 ein Ambilight gebaut (ca. 200 LEDs), das auch 25x/sek aktualisiert wird. Zugegeben das Protokoll der APA gefällt mir für eine Ansteuerung durch ein eigenes Programm auf einem µC wesentlich besser.

[Ceos]

Nun daß diese WS2812 & Co. verflucht schnell sind, sieht man ja in zahlreichen Videos im Netz: hier bauen manche Bildschirme mit mehreren tausend dieser LEDs auf und zeigen auf diesen Videofilme.

das stimmt nur, wenn man mehrere gruppen parallel ansteuert

vergleiche einfach mal die grunddaten

APA102: 4Mhz Baudrate (angeblich funktionieren die bis 10Mhz, nicht getestet, mir fehlt immernoch ein ausreichend schneller Pegelwandler)
WS2812: 800kHz Baudrate

Okay wir reden hier von 32bits(APA) statt 24bits(WS), also verlieren wir ein wenig, aber schon bei 1Mhz SPI Clock hat man das schon fast raus und nach oben gibt es noch mind. 4 mal mehr Steigerungspotential

Zumal man auch sog. D/QSPI benutzen kann, bei dem mit jedem Takt an CLK 2(DSPI) oder 4(QSPI) Bits gleichzeitig auf unterschiedlichen Pins ausgegeben werden. Mit einem QSPI fähigem Controller kann man also noch ein paar Stufen effizienter werden wenn man nur eine Transferroutine für 4 Ketten gleichzeitig aufrufen muss

diese APAs sind einfach die WS nur eben weitergedacht, leider verharrt arduino und co. sehr fest bei seiner Unterstützung und promotet die neopixel über den nanodots recht heftig

[Klebwax]

APA102: 4Mhz Baudrate (angeblich funktionieren die bis 10Mhz, nicht getestet, mir fehlt immernoch ein ausreichend schneller Pegelwandler)

Das sollte doch kein wirkliches Problem sein. Ein HCT14 schafft 10MHz locker, das haben ja alte LS-TTL Gatter schon geschafft. Und wenn man die Signalpolarität nicht im µC anpassen kann, zwei hintereinander.

Zugegeben das Protokoll der APA gefällt mir für eine Ansteuerung durch ein eigenes Programm auf einem µC wesentlich besser.

Wirklich entspannter ist es nicht. Wenn ich einen SPI-Controller mit 10MHz bediene, muß ich auch knapp alle µs ein Byte an den SPI-Controller liefern, sonst gibts einen Underun-Error. Das klappt genauso gut oder schlecht per Interrupt wie beim Neopixel. Gewinnen kann ich eigentlich nur mit einem Fifo am SPI oder einem DMA.

Was aber sicher richtig ist, daß man es beim Bitbanging leichter hat. Da man bei SPI als Master den Clock selbst erzeugt, ist man nicht auf ein genaues Timing angewiesen. Man kann also so schnell man kann 8 Bit raustakten und dann das nächte Byte aus dem Speicher holen. Die entstehende Pause ist unproblematisch. Wenn es aber stimmt, das man bei den WS die Länge der Low-Zeit auch etwas länger ausfallen lassen kann, geht das auch mit denen.

Für die 64 LEDs, die man auch nur einige wenige Male in der Sekunde updaten muß, ist das höchsten ein Problem für BASCOM. Da bräuchte man eine Unterstützung durch eine eingebaute Funktion, wie die Neopixel-Libraries beim Arduino. In C und sicher auch in Assembler geht das aber, wie man hier sieht. Die 57 LEDs sind nicht weit weg von 64.

MfG Klebwax