7-Segmentanzeige mit Farbsteuerung

[hardware.bas]

Hallo ... von einem niederländischen Anbieter gibt es ein System namens rgbdigit. Hier handelt es sich um
einstelllige, jedoch kaskadierbare Siebensegmentanzeigen, deren einzelne Segmente mittel RGB-Led-Chips
individuell beleuchtet werden. Gibt es dazu schon praktische Erfahrungen, insbesonders, wie das Busprotokoll aufgebaut ist? Für Infos und nachfolgenden Erfahrungsaustausch wahre ich sehr dankbar.
Micha

[White_Fox]

Wie wäre es wenigstens mit einem Link?

[RoboHolIC]

Mittels Suchbegriff rgbdigit kriegt man neben vielen anderen eine Fundstelle bei Elektor. Dort ist auch ein Datenblatt verlinkt. Das Protokoll sieht sehr nach WS2812 aus und soll mit Adafruits neo-pixel-Library kompatibel sein.

[Ceos]

schade, mit APA102 statt WS2812 wäre das wesentlich kompakter zu programmieren, vor allem wenn man auf Arduino als Grundlage verzichten muss ... hätte echt mein Interesse für ein Projekt auf Arbeit geweckt

[Siro]

Schicki die Teile, aber etwas teuer mit knapp 8 Euro.

Da sind wohl wirklich die WS2812 Chips verbaut.
Somit ist es ja recht einfach diese anzusteuern.

Ich hatte das vor kurzem mit einem kleinem 8 Pinner PIC sogar in "C" gemacht:
Da braucht man keine Bibliothek für.

https://www.roboternetz.de/community/threads/70216-XC8-inline-Assembler/page2

Wenn man eine langfristige Verfügbar garantieren könnte wäre das sogar für ein Projekt in unserer Firma interessant.
Siro

[Ceos]

Nett gemeint, aber das geht nur wenn du Rechenzeit übrig hast, ich brauche 70-80% der Rechenzeit für wichtigeres als LED Bits zu basteln.

mit APA102 kann ich das mit SPI Peripheral und ein nem 3-Zeiler ISRs bauen

und wenn cih eine extra Controller davor hängen müsste, kann ich auch gleich die Multiplex Controller Lösung nehmen die wir derzeit verbauen XD

PS: habe dein Topic zu ende gelesen *grusel* "nop" ... kann ich mir kaum erlauben XD

[Siro]

Ich denke für Firmenanwendung sind die eh nix, ich hab grad mal geschaut. Es sind 23 Stück auf Lager und man bekommt sie vermutlich nirgendwo sonst.
Aber für Hobby Bereich find ich sie wirklich supi.

[Ceos]

Sagen wir es mal so, ich weis, dass diese LED Matrix für uns eine Auftragsgeschichte ist, wenn der gleiche Hersteller/Lieferant auch APA102-DIEs verbauen kann, fände ich das schon RICHTIG spannend :D

Sollte man sich mal ein unverbindliches Abgebot drüber machen lassen und dann auch für den Markt vorschlagen XD

[hardware.bas]

Um Anzeigen für Steuerungen industrieller Insellösungen zu realisieren setzte ich gern auf LED-basierten 7-Segmentanzegen.
Ursprünglich war ich daher auf der Suche nach einem RGB-Digit mit 8 Anschlüssen für die Segmente und 3 Anschlüssen, also RGB pro Stelle. Durch die individuelle Segmentansteuerung wird hierbei sogar noch ne Schippe draufgelegt.
Bei genauer Kenntniss des Protokolls wird es wahrscheinlich möglich sein, die komplette mehrstellige Ziffernbank durch
Verbinden eines einzigen OUTPUT des verwendeten Mikrochips mit dem INPUT des ersten rgbdits anzusteuern.
OUTPUTs für BCD-Einspeisungen bzw Stellentreiber, sowie die Hardware für Decoder bzw Multiplexing entfallen.
Da alle rgbdigits gleich sind, jedoch adressiert werden müssen, VERMUTE ich, dass die interne Elektronik jedes rgbdigits
die Nutzdaten unverändert durchreicht, jedoch den Adresswert incrementiert bzw decrementiert. Dadurch würde sich
durch die Wahl des Adresswertes das Zieldigit ansprechen lassen. Die dazu notwendige Rechenperformance dürfte
angesichts der Tatsache, dass sich praxisgerechte Anzeigen relativ langsam ändern könnten, nicht zu hoch sein.
VG Micha
Einspeisung

[Ceos]

Es wäre schon fast sträflich wenn die LEDs in den Segmenten nicht nach dem klassischen abcdefg-Schema verkabelt wären und nur logisch dass ein kaskadieren auch völlig simpel ist, aber wenn cih eine Multiplex 7Segment nehme, brauche ich nicht mehr als einen Timer der mir einen Interrupt alle Nase lang feuert und dann die Portbits umschalten um die entsprechenden kathoden/anoden kombination bereit zu stellen, während sich die main gelangweilt im doo-loop dreht.

Bei der Seriellen Lösung müsstest du je nachdem wieviele Segemente du hast und welche Aktualisierungsrate du wünschst, jedesmal (1/800khZ)*24Bits * 7 balken pro Segment = 0.21mS / Segment reine Rechenzeit investieren und je nachdem was für eine Anwendung du hast beschränkt dich das schon extrem.

eine Lösung bei der ich eine Controller Peripherie wie SPI, I2C oder eben einen Timer + etliche Pins benutzen kann ist da wesentlich effizienter

[hardware.bas]

Ursprünglich suchte ich ein RGB-Digit mit 8 Kathodenanschlüssen für die Segmente und 3 Anodenanschlusse für RGB.
Das gestern gefundene kaskadierbare RGBDIGIT "erschlägt" jedoch alle Probleme und bietet weitere Vorteile.
Wichtig ist es, nunmehr das Datenprotokoll und die interne Adressmanipulation im Baustein rauszufinden.
Dann sollte es möglich sein, durch Verbinden eines einzigen Ausgangspin des verwendeten Chips mit dem Eingangspin
des ersten RGBDIGITs die komplette Ansteuerung einer mehrstelligen Ziffernkaskade mit geringem Rechenaufwand
ohne weitere Hardware zu realisieren.
VG Micha

[Ceos]

Das protokoll ist bekannt, es sind WS2812 LEDs, die eine 800kHz Pulsbreitenmodulation betreiben, kurz für 0 lang für 1

Unter Adafruit läuft das unter dem namen Neopixel und die Bibliotheken sind standardmäßig bei Arduino dabei. Einzig eine Hilfsbilbiothek die sich um das Umwandeln der Darzustellenden Zeichen in LED Muster kümmert wird von der Herstellerseite benötigt oder du baust dir deine Segmentbalken selber zu Ziffern und Buchstaben zusammen :D

[hardware.bas]

Gehört zwar nicht zum eigentlichen Thema, wenn ich jedoch im Gegensatz zur
simultanen Ansteuerung einen Haufen PINs und Decoder-ICs oder bei Multiplex-
ansteuerung die entsprechende Hardware einsparen kann - Softwaremultiplex
erachte ich wegen der Einbrenngefahr der Digits für industrielle Anwendungen
als zu gefährlich - würde ich dieses Prinzip sogar schon bei monochromen
Anwendungen hochinteresant finden.
An die erwähnte Adressmanipulation hatte ich selber mal gedacht, um eine
programmierbare Hausillumination mit 2-Drahtkabel zu realisieren, die
entsprechenden Leuchtkomponenten hätten dann noch einen kleinen ATtiny
innegehabt. Ziemlich preisgünstig pro Komponente, jedoch die Masse machts.
Daher hab ichs nicht übers Experimentierlevel realisiert.
An eine selbstgebaute Grosssichtanzeige mit sehr vielen RGB-6pin-LEDs für
unsere Produktionshalle hatte ich auch schon nachgedacht, dies wird jedoch
mit mehreren grossen LED-Bildschirmen besser gelöst werden können.
Nun konkret;
Die RGBDIGITS existieren nun mal als für den PRAKTIKER interessante Bauele-
nente deren Innenschaltung dem PRAKTIKER vollkommen egal ist.
Wichtig ist deren Funktion und damit deren kreative Handhabung!
Dem Download von www.rgbdigit.com konnte ich bis jetzt noch nix abgewinnen,
da ich bisher nicht rauskriegen konnte, von welcher "Sendehardware" diese stammt.
In Ermangelung entprechender Software wurde diese mit dem Editor als Textdatei
geöffnet, raus kommt unformatierter Kauderwelsch mit Fetzen einer Hochsprache,
eventuell sogar BASIC (das wäre toll).
Eine Kontaktaufnahme mit dem Anbieter der RGBDIGIT wäre jetzt mein nächster Part.
VG Micha

- - - Aktualisiert - - -

Die Kontaktaufnahme mit dem Hersteller der RGBDIGITS ist jetzt erfolgt. Grundlage ist das Protokoll für die Ansteuerung
der Stellenkaskaden über einen PORT. Bei mir wird dies definitiv mittels AVR und BASCOM realisiert werden. Anwender
anderer Chipfamilien oder Nutzer anderer Compiler würden das dann auch hinkriegen. Ich werde feedbacken.
VG Micha

[RoboHolIC]

Die RGBDIGITS existieren nun mal als für den PRAKTIKER interessante Bauele-
nente deren Innenschaltung dem PRAKTIKER vollkommen egal ist.
So halten das wohl selbst die Profis. Dennoch kommen sie nicht daran vorbei, die Dokumentation so intensiv zu lesen, bis sie sie verstehen und anwenden können. Oder eben zu entdecken, dass es sich um einen Standard handelt, für den bereits alles Notwendige existiert.


Dem Download von www.rgbdigit.com (http://www.rgbdigit.com) konnte ich bis jetzt noch nix abgewinnen,
da ich bisher nicht rauskriegen konnte, von welcher "Sendehardware" diese stammt.
In Ermangelung entprechender Software wurde diese mit dem Editor als Textdatei
geöffnet, raus kommt unformatierter Kauderwelsch mit Fetzen einer Hochsprache
Sprichst du von einem Manual bzw. einer Dokumentation im PDF-Format - oder von einem anderen Download auf der benannten Seite ???

[Klebwax]

Softwaremultiplex erachte ich wegen der Einbrenngefahr der Digits für industrielle Anwendungen als zu gefährlich -

Hatten wir gerade in einem anderen Thread. Moderne LEDs sind so hell bei Nennstrom, daß man sie selbst im Multiplexbetrieb mit dem Maximalstrom oder weniger betreiben kann. Die Sache mit dem "Einbrennen" ist Geschichte.


Dem Download von www.rgbdigit.com konnte ich bis jetzt noch nix abgewinnen, da ich bisher nicht rauskriegen konnte, von welcher "Sendehardware" diese stammt.

Kann man doch leicht aus der Doku herausfinden: 1 (in Worten ein) digitaler Output.

Der Rest ist Software, nicht Hardware. Und damit man die noch nicht mal schreiben muß, wird sogar auf die adafruit "neopixel" library für arduino hingewiesen. Ob man das in BASIC schnell genug hinbekommt kann ich nicht sagen. Das Protokoll verlangt Zeiten von 400ns bzw 850ns mit +- 150ns. Steht aber alles in der Doku aus deinem Link.

MfG Klebwax

[hardware.bas]

Zum Softwaremultiplexing:
Beim Aufbau von Prototypen und darauffolgenden Softwareentwicklung
muss der Chip sehr oft per ISP nachgeflasht werden. Ein Schreibfehler
im Quelltext oder ein seltener Fehlflash ... und Digit ... tschüss
Zum eigentlichen Thema:
Bin selber grade beim Aufdröseln der entpackten Pseudotextdatei.
Klebwax hat ja schon einiges rausgefunden. Mit BASCOM sind derartige
Timings kein Problem, ist ja auch nur ein Compiler. Bei der Aufbereitung
der Stellen sehe ich in Sachen Rechenperformance kein Problem, zumal
für mein Projekt zusätzlich entschärfend hinzukommt, ich brauche NUR
die Farbe des gesamten Digits zwischenzuspeichern und es reichen
dafür 7 Farben, also KEINE Zwischenfarbtöne. Eine Aktualisierung der
Anzeige im Sekundenrhythmus reicht aus. Da es sich um ein zentrales
Managmentsystem für Produktionsanlagen, welche über einen 485-Bus
kommunizieren, handelt, kommt ein ATMega 162 zum Einsatz, welchem
ich nur wenige Prozente des Programmspeichers für die
Anzeigengestaltung gönnen werde.
Autarke Anzeige:
Für universelle Zwecke wäre es auch denkbar, das Digitarray auf einer
Platine zusammenzulöten und zusätzlich mit einem ATTiny 2313 zu
versehen. Dieser schafft die Rechenleistung mit links und hat
ausreichend PINs für Jumper, so dass eine Kommunikation über
UART, SPI, I2L oder benutzedefiniert kein Problem darstellt.
VG Micha

[Ceos]

Ein Schreibfehler
im Quelltext oder ein seltener Fehlflash ... und Digit ... tschüss

Schlechtes Schaltungsdesign ... oder mangelnde Erfahrung ... Wir arbeiten hier mit Multiplexing und ich debuggen regelmäßig mit stehendem Display, da brennt nichts ab wenn man seine Schaltung einfach ausreichend sicher dimensioniert ... Die Aussage zählt nicht oder es mangelt einem an Erfahrung!

Die Webseite zielt (und der Hersteller hat mir das sogar explizit geschrieben) auf Arduino Nutzer die die Neopixel library für die Ansteuerung benutzen können

https://github.com/adafruit/Adafruit_NeoPixel/blob/4d0987ede8f8c204ff333de9a2fcbb70c646b7a5/Adafruit_NeoPixel.cpp#L122
(https://github.com/adafruit/Adafruit_NeoPixel/blob/4d0987ede8f8c204ff333de9a2fcbb70c646b7a5/Adafruit_NeoPixel.cpp#L122)
Ich habe dir mal die Methode gelinkt, die setzt auf heftigst optimierten und auch Copntroller spezifischen Assembler Code und ist sicher um einiges schneller asl was du da zusammenbaust :)

Klar ich möchte dem Lernprozess nichts entgegensetzen, aber da kannst du dich mal schlau machen wie die von Adafruit das lösen

[hardware.bas]

Ceos, vielen Dank für die Links, muss jedoch gleich zur Schicht.
Deine Vermutung, dass es mir an fundierter Erfahrung in Sachen
Multiplexing fehlt, ist übrigens berechtigt, da ich mich bisher im
Wesentlichen auf Anzeigendesign, welches hell, weithin sichtbar
und flimmerfrei sein muss, also bedienerfreundlich, konzentriert
habe. Detaillierte Informationen werden eh via RS232 einem
Prozessrechner zugeführt.
Weiterhin werden Timer und Interrupts bei mir meistens für
prozesstechnische Zwecke benutzt.
Mal sehen, ob aus den jetzt verfügbaren Infos ein
entsprechender Impulsfahrplan ersichtlich wird.
VG Micha

[Ceos]

nunja, genaugenommen, langweilt sich bei unseren Applikationen der Prozessor auch relativ gut und könnte eigentlich ein 4 Stelliges Display gerade so bedienen, aber leider haben wir auch zeitkritische sachen dabei wie interrupts, die während des bitbangings nicht bedient werden DÜRFEN, das solltest du bei deiner Anwendung auch berücksichtigen

die meiste Rechenleistung verheizen wir eigentlich für den Kommuniaktionsstack für unsere Busanschlüsse ... paradox, wo die Messung und Umwandlung in z.B. ein analoges Signal geschmeidig mit diskreter Schaltung gelöst werden KÖNNTE ... aber Industrie 4.0 Ruft nu mal nach Busssystemen und deren Stacks.

Wenn ich memorymapping betreibe indem ich das Muster im RAM als Rohdaten speichere udn dann einen DMA Controller + Sende peripherie beschäftige, habe ich die CPU komplett frei, nur der Bus wird ab und an mal für einen Takt oder 2 nicht verfügbar sein und so ein winziges bisschen jitter erzeugen.

Wenn du mit DMA und SPI arbeiten kannst udn dein RAM dafür ausreicht, würde ich dir empfehlen immer 2 bits in 1 byte zu packen, dann kannst du über das bitmuster des bytes dein PPM signal erzeugen.

[HaWe]

nunja, genaugenommen, langweilt sich bei unseren Applikationen der Prozessor auch relativ gut und könnte eigentlich ein 4 Stelliges Display gerade so bedienen, aber leider haben wir auch zeitkritische sachen dabei wie interrupts, die während des bitbangings nicht bedient werden DÜRFEN, das solltest du bei deiner Anwendung auch berücksichtigen

die meiste Rechenleistung verheizen wir eigentlich für den Kommuniaktionsstack für unsere Busanschlüsse ... paradox, wo die Messung und Umwandlung in z.B. ein analoges Signal geschmeidig mit diskreter Schaltung gelöst werden KÖNNTE ... aber Industrie 4.0 Ruft nu mal nach Busssystemen und deren Stacks.

Wenn ich memorymapping betreibe indem ich das Muster im RAM als Rohdaten speichere udn dann einen DMA Controller + Sende peripherie beschäftige, habe ich die CPU komplett frei, nur der Bus wird ab und an mal für einen Takt oder 2 nicht verfügbar sein und so ein winziges bisschen jitter erzeugen.

Wenn du mit DMA und SPI arbeiten kannst udn dein RAM dafür ausreicht, würde ich dir empfehlen immer 2 bits in 1 byte zu packen, dann kannst du über das bitmuster des bytes dein PPM signal erzeugen.

Das Zauberwort heißt hier: Multithreading,
gibt es schon lange für den Arduino Due und wohl inzwischen auch für AVRs mit wenig Speicher.
Insgesamt halte ich das mit den bunten LEDs aber für eine Spielerei, hauptsächlich für Anfänger oder wo es nicht so auf Performance ankommt, ansonsten würde ich zu einem 64k-farbigen großen 2.4"-7" TFT per Hardware-SPI greifen.

[Ceos]

Das Zauberwort heißt hier: Multithreading,

HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.

Hast du dir die Timings mal angesehen und mal nachgedacht wieviele Takte du für die Flankenwechsel hast? das sind weniger als 13 Takte bei 32Mhz ... schon der Gedanke an einen "Threadwechsel" kostet deinen Prozessor mindestens 3 mal so viel. Das ist unmöglich zu schaffen!

Du kannst nur eines machen: Bitbang 800kHz oder irgendwas berechnen. Die Operationen um einen ISR vorzubereiten, den Stack Pushen, Pointer laden, all das ist unmöglich in den 13 Takten zu schaffen ohne die LEDs dabei zu verwirren, weil du alle hintereinander ohne Pause ansprechen musst oder die ersten LEDs updaten sich und du musst von vorne anfangen!

Darum habe ich extra darauf hingewiesen, dass man für jedes einzelne 7-Segment 0.21mS Zeit einplanen muss in der man nichts berechnen kann, es sei denn man stellt (wie er schon gesagt hat) einen separaten Prozessor dafür ab, der sich nur um das Umwandeln in WS2812 kümmert und in den Aktualsierungspausen dann Daten an einer Schnittstelle entgegen nimmt.

Ich wollte mir schonmal mit einem 555, einem D-FlipFlop und 3 Byte SPI Latches die Serialisierung für dieses beknackte Protokoll als DIY Peripherie aufbauen, bin aber an zu langesamen 555s gescheitert.

Wenn ich wie gesagt einen SPI hätte könnte cih einen DMA aus dem RAM damit beschäftigen (hat ein ATMega nicht, aber XMegas) die SPI zu füttern ohne dass die CPU auch nru einen Handschalg machen muss.

[HaWe]

HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.
...
Hast du dir die Timings mal angesehen und mal nachgedacht wieviele Takte du für die Flankenwechsel hast? das sind weniger als 13 Takte bei 32Mhz ... schon der Gedanke an einen "Threadwechsel" kostet deinen Prozessor mindestens 3 mal so viel. Das ist unmöglich zu schaffen!


ich hatte das zwar gelesen, aber tatsächlich nicht verstanden, dass Threadwechsel so viel Zeit konsumiert - stimmt ntl, dann macht auch das hier keinen Sinn.
Bleibt also doch nur ein TFT, ggf mit "nachgemachten" LED-Schriftbalken...?

[Ceos]

Wenn jemand mal einen SPI oder I2C WS2812 bitbanger zusammengebaut bekommt würde ich ihm sogar geld dafür nachwerfen XD

bisher verhagelt mir das WS2812 protkoll imernoch alle mein Pläne und an die APA102 kommt man zwar mittlerweile ran aber die lieferzeiten sind im vergleich zu WS2812 grausig

MHHHHHH ....

http://www.analog.com/en/design-center/reference-designs/circuit-collections/1mhz-pulse-width-modulator.html
+ mux + schieberegister + 1-2 logikgatter ... outputs über widerstandsnetzwerk für analog in und über multiplex durch die bits schalten (feedback vom PWM ausgang) und die gatter für ISR an den controller fürs nächste byte und den latch des schieberegister


Wenn ich nur für die Anbindung der LEDs mehr Leistung im Prozessor aufbringen muss als für die eigentliche Arbeit ist mir das echt zu blöd, zumal ich so einen sleep-mode komplett vergessen kann.

[Mxt]

Wenn jemand mal einen SPI oder I2C WS2812 bitbanger zusammengebaut bekommt würde ich ihm sogar geld dafür nachwerfen XD

Ich weiß nicht, ob das weiterhilft, für die Arduino kompatiblen Teensy Boards mit NXP-Controllern gibt es z.B. sowas
https://www.pjrc.com/non-blocking-ws2812-led-library/
Kann man vielleicht auf anderen Controllern ähnlich angehen ...

[Ceos]

Das entsprricht der Lösung die ich beschrieben habe (SPI um das Signal zu produzieren) allerdings braucht das ne Menge RAM (12Byte RAM pro LED) und die NEXPs haben einen DMA

[hardware.bas]

Der Meinung von HaWe, dass es sich um eine Spielerei handelt, schliesse
ich insofern an, falls man die einzelnen Segmente individuell illuminieren
sollte. Die Zielstellung ist jedoch eine Farbsteuerung des einzelnen
kompletten Segmentes und das auch nur siebenfarbig. Dies dient einzig
und allein der komfortableren Darstellung von mehrstelligen 7-Segment-
LED-Anzeigen an oder in der Nähe von Anlagenkomponenten, für Operator,
welche nicht unbedingt die technischen Details der Maschine kennen
müssen. Dazu erscheinen mit die RGBDIGITs prädestiniert. Leider bin auch
ich bisher nicht weitergekommen, was deren Ansteuerung betrifft.
Die Nutzung von Display habe ich auch schon ins Auge gefasst, bis jetzt
jedoch auf Grund des Preis-/Nutzen-Verhältnisses und den rauhen
Umgebungsbedingungen verworfen.
Trotz Hochachtung vor den vielen in diesem Threed erwähnten speziellen
Kenntnissen und Erfahrungen, wollte ich an das eigentliche Thema noch
mal erinnern. Danke für das Verständniss.
VG Micha

[Siro]

Ich habe eben mal ein paar Versuche wegen dem "kritischen" Timing gemacht.
Es hat sich herausgestellt, zumindest bei meinen LEDs,
dass die Low-Phasen doch erheblich länger sein dürfen als im Datenblatt angegeben.
Ich habe Low Phasen von bis zu 7 Mikrosekunden drin, obwohl es angeblich nur
0,45 bzw. 0,85 Mikrosekunden sein dürfen.
Wichtig ist das Einhalten der angegebenen Highphasen.

[Ceos]

Okay, das ist neu, funktioniert das auch egal wo du die pausen machst? also z.B. mitten im Byte oder nur an bestimmter Stelle? Die DOku scheint mit +/-150nS sehr strikt zu sein was das angeht

Dann könnte man auch relativ gemütlich mit SPI arbeiten, pro millisekunde ein byte a 2 bits codiert ... dann frage ich mich warum bei mir mit der SPI lösung nach 10 LEDs nurnoch mist rausgekommen war

[Siro]

Bei mir ergibt sich das Timing bedingt durch die Software,
dass ich zwischen den Bytes 7 us Low habe und
zwischen den einzelnen Bits habe ich zur Zeit 3,8us Low.
Ich habe 57 Leds dran

33462

Übrigens sieht man hier den "Fehler" in der RIGOL-Software vom MSO1104Z. Die automatische Min Max Funktionion für die Pulsbreite funktioniert nicht richtig.
Das wurde mir sogar bestätigt,......:( Die Cursorpositionen stimmen aber BX-AX = 7us



void LedShiftOut(U8* leds, U8 count)
{
U8 one_byte;
U8 bit_count;

// damit keine Multiplikation verwendet wird:
count=(count+count+count); // 3 Bytes pro Led RGB
DISABLE; // alle Interrupts sperren
while (count) {
CLRWDT(); // den Watchdog bedienen, fass erforderlich
one_byte = *leds++; // aktuelles Datenbyte laden
// 8 Bits durchlaufen:
for (bit_count = 0; bit_count < 8; bit_count++)
{
if (one_byte & 0x80) // wenn das oberste Bit 7 gesetzt ist dann
{
LATA5 = 1; // lange High Phase einleiten
NOP();
NOP();
NOP();
LATA5 = 0; // High Phase beenden
NOP(); // testweise länger auf low
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();

} else // Kurze High Phase weil das Datenbit Low ist
{
LATA5 = 1; // kurze High Phase einleiten
NOP();
LATA5 = 0; // High Phase beenden
NOP(); // testweise länger auf low
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();
NOP();

}
one_byte <<= 1; // Das Datenbyte 1 mal links verschieben
}
count--; // Anzahl auszugebener Datenbytes -1
}
ENABLE; // Interrupt wieder einschaalten
__delay_us(50); // Das Ende der Datenübertragung erreicht wenn die Leitung länger als 50us Low bleibt.
}

Mein LedArray sieht so aus:

// so viele LEDs sollen angesteuert werden:
#define LED_COUNT 57

/* Jede LED hat 3 Bytes insgesamt also 24 Bits */
typedef struct // __pack weil wir keinen Speicher verschwenden wollen
{
U8 green; /* 8 Bit fuer die Helligkeit */
U8 red; /* 8 Bit fuer die Helligkeit */
U8 blue; /* 8 Bit fuer die Helligkeit */
} TLed; /* Type Bezeichner ist TLed */

TLed LedArray[LED_COUNT];

aufgerufen wird dann so:



// Beispiel wie die Farben gesetzt werden, hier für LED Nr 4 (Zählung geht von 0..)

LedArray[3].green = 0x00; // grün aus
LedArray[3].red = 0x7F; // halbe Helligkeit für rot
LedArray[3.blue = 0x10; // bissle Blau dazu

LedShiftOut(&LedArray,LED_COUNT);

ab 7,5us Low Phase flippen die LEDs bei mir aus

- - - Aktualisiert - - -

@Ceos:
ich hatte das auch schon, dass nach einigen LEDs nur noch Blödsinn rauskam.
Bei mir war tatsächlich eine LED defekt. Die habe ich ausgetauscht und dann lief es richitg.
Hatte auch erst gedacht das es an der Software bzw. Timing liegt.

[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(8) 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....:p

[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

[hardware.bas]

Ich glaube, jetzt hats bei mir geklickt. Das Dataheet der verbauten WS2812
hatte ich mir eben nochmal angeschaut. Letztendlich besteht schaltungs-
technisch zum Beispiel eine 8-stellige RGBDIGIT-Anzeige lediglich aus einer
Reihenschaltung von 64 Stück WS2812. Man kann einen Ausgangspin nutzen
und schiesst dann 64 mal 24-BIT-Datenpakete in die Anzeige, man kann
aber auch 8 Ausgangspins nutzen und steuert die RGBDIGITS individuell an
und sendet dann bei Aktualisierung einer Stelle eben nur 8 mal 24-BIT-
Datenpakete. Sollte ich das nun richtig verstanden haben?
VG Micha

[Ceos]

Absolut korrekt :)

Deine idee multiple Pins für mehrere Segmente zu nehmen sit auch nciht ganz verkehrt

wenn ich die SPI schnittstelle nehme um 24Bits zu codieren, kann ich ja auch hingehen und mehre SPIs parallel befüttern, so klann ich die 100-200 Rechentakte die für das herausschieben eines SPI Bytes benutzt werden verwenden um das Byte für die 2te SPI SChnittstelle zu berechnen und so abwechselnd auf 2 SPI pins meine PPM senden, da die LEDs kurze Pausen ja scheinbar akzeptieren

[hardware.bas]

Ceos, insbesonders Dir und natürlich auch den anderen Beteiligten
vielen Dank für die Hilfe. Ich versuche jetzt, die finanzielle Freigabe
meines Auftraggebers zu erwirken, die geforderte komfortable
Multifunktionsanzeige zu realisieren, welche nur einen Bruchteil des
Projektes, was ich vorhabe, darstellen wird. Es soll zusätzlich das
eigentliche Vorhaben, eine komplette Produktionsverfolgung für
Pyrolysebatches (Altreifen zu hochwertigen Industrieruss) inklusive
der Extrahierung des Reifenstahls uEm realisiert werden. Gleichzeitig
wird eine Kommunikation der einzelnen Anlagenteile ermöglicht,
welches über die genannte Baugruppe läuft und die einzelnen
Anlagenteile gegenseitig anpasst. Ich weiss, das ist bezugnehmend
auf diesen Thread schon ziemlich offtopic, wenn Du jedoch für
ein Unternehmen arbeitest, welches absolutes Neuland betritt,
weltweit damit expandieren will, bist der einzige Elektroniker in
Personalunion mit Produktionsarbeit, die Verantwortlichen haben
keine Ahnung von MSR, obwohl kompetent in Chemie (ich weniger)
und Angst vor Technik, weil sie diese nicht verstehen,
dann ist es Zeit, unter dem Deckmantel eines akzeptierten
"Nurmultifunktionsdisplays" den absoluten Kracher zu landen.
Das bedeutet weitere elektronische Komponenten, die dann
auch akzeptiert werden. Hat übrigens bisher toll funkioniert!
(Erst: Darf man das wegen deutscher Spiessigkeit, dürfen das
nur Ingeneure oder Doktoren, dann kommt der Praktiker,
machts eigenmächtig und plötzlich ist das so toll, dass man
sich freut, einen angenehmen Stress zu haben, dies noch
weiter vervollkommnen zu dürfen)
Ich werde daher den leistungsfähigsten AVR im DIL-Gehäuse
für den genannten Zweck einsetzen.
Sorry, das war teilweise extrem am Thema vorbei, also ne
"Eintagsfliege" im nicht ganz richtigen Thread
VG Micha

Naja, ist man nur praktischer

[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 :D

[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-Booster-WS2812-und-SK6812-ueber-SPI-Schnittstelle-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 (https://www.roboternetz.de/community/threads/72008-7-Segmentanzeige-mit-Farbsteuerung/page3?p=644676&viewfull=1#post644676). Die 57 LEDs sind nicht weit weg von 64.

MfG Klebwax

[Ceos]

Gewinnen kann ich eigentlich nur mit einem Fifo am SPI oder einem DMA.

meine worte :)

ein XMEGA würde sich direkt langweilen bei dem job XD

[hardware.bas]

Kurze Zeit habe ich überlegt, das komplette Datenprotokoll im
Format 24 mal HXL (X ist das aktive BIT) pro RGB mit dem AVR
zu erzeugen und in ein 128 BIT-Schieberegister MC4562B seriell
einzulesen (man braucht nur 72). Die ca 50 Mikrosec Pause
sollten dafür genugen. Das notwendige Auslesen mit ca 2,4 MHz
in die LED-Kette stiess allerdings nach Studium der dynamischen
Werte im Datasheet auf grosse Skepsis.
Favorisieren werde ich jetzt das parallele Laden von 3 schnelleren
8-BIT-Schieberegistern 74FCT299B, welche die X-BITS sogar
nur noch mit 800 kHz rausschiebt und das mittlere BIT eines
durch einen "1-zu-3-Zahlers" erzeugten Bitmusters beeinflusst.
Die Anzeigeschaltung (8xRGBDIGITs) wird autark mit einem
ATMega8 betrieben. Die Farbsteuerung wird "runterreduziert",
da lediglich 7 Farben für die Anzeige notwendig sind.
Die restliche Rechen- und Speicherperformance des ATMega
bietet dann Platz für eine komfortable quasialphanumerische
Anzeigedecodierung mit nur 6 BIT.
Alles Weitere nach erfolgten Tests.
VG Micha

[Crazy Harry]

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.
Ich finde das wesentlich entspannter, da durch den separaten Clock-Pin das Timing absolut unkritisch ist. Der APA ist es egal ob sie mit 400kHz oder 2MHz angesteuert wird.

[Ceos]

Ich glaube wir reden hier mittlerweilen über "Geschmäcker" udn über Geschmack lässt sich vorzüglich streiten, sollte man aber nicht :)

Beide Wege haben Vor- und Nachteile, die einen sind etwas neuer die anderen etwas älter, es ist nur schade dass sich die Arduino Community eben so unendlich hart auf die WS eingeschossen hat und die APA einfach keine Liebe bekommen, denn technisch gesehen brauchen sie keine Liebe, sondern nur die SPI API und die ist schon fertig, eine weitere Lib wäre überflüssig, aber wenn es eben keine Lib mit dem Namen der LEDs gibt schreckt das die meisten Anfänger halt ab.