Zitierenich 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 von Ceos
Bleibt also doch nur ein TFT, ggf mit "nachgemachten" LED-Schriftbalken...?
HaWe, mach dir doch bitte mal die Mühe zu lesen was vorher geschrieben worden ist. Du propagierst hier gerade unpassende Informationen.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.
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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...?
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.
Geändert von Ceos (15.05.2018 um 13:49 Uhr)
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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 ...
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
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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
Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...
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
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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
Ü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.
Geändert von Siro (16.05.2018 um 19:32 Uhr)
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
Was brauche ich für Werkzeug - in dieser Reihenfolge seht ihr es:
Vorschlaghammer, Notebook, BASCOM, Lötequipment, Rohrzange, Bolzenschneider ...
Berechtigungen
Lesezeichen