Druckbare Version
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
Wie wäre es wenigstens mit einem Link?
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.
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
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...ssembler/page2
Wenn man eine langfristige Verfügbar garantieren könnte wäre das sogar für ein Projekt in unserer Firma interessant.
Siro
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
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.
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
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
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
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
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
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
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.Zitat:
Zitat von hardware.bas
Sprichst du von einem Manual bzw. einer Dokumentation im PDF-Format - oder von einem anderen Download auf der benannten Seite ???Zitat:
Zitat von hardware.bas
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.Zitat:
Zitat von hardware.bas
Kann man doch leicht aus der Doku herausfinden: 1 (in Worten ein) digitaler Output.Zitat:
Dem Download von www.rgbdigit.com konnte ich bis jetzt noch nix abgewinnen, da ich bisher nicht rauskriegen konnte, von welcher "Sendehardware" diese stammt.
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
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
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!Zitat:
Ein Schreibfehler
im Quelltext oder ein seltener Fehlflash ... und Digit ... tschüss
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
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
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
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,Zitat:
Zitat von Ceos
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.
HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.Zitat:
Das Zauberwort heißt hier: Multithreading,
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.
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.Zitat:
Zitat von Ceos
Bleibt also doch nur ein TFT, ggf mit "nachgemachten" LED-Schriftbalken...?
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-cent...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.
Ich weiß nicht, ob das weiterhilft, für die Arduino kompatiblen Teensy Boards mit NXP-Controllern gibt es z.B. sowasZitat:
Zitat von Ceos
https://www.pjrc.com/non-blocking-ws2812-led-library/
Kann man vielleicht auf anderen Controllern ähnlich angehen ...
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
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
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.
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
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
Anhang 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
Mein LedArray sieht so aus:Code:
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.
}
aufgerufen wird dann so:Code:// 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];
ab 7,5us Low Phase flippen die LEDs bei mir ausCode:
// 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);
- - - 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.
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
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
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
Vorsicht, nicht dass du das falsch verstehst:Zitat:
danach mindesten 50 microsec Low
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
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.
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 getratschtZitat:
Man schiebt also zuerst die Daten für die letzte LED rein, dann für die vorletzte usw.
Sorry, Du hast recht Ceos, ich hab zuviel mit den 595er geschoben....:p
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
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
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
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