hi,
Ihr seid ja arm dran in deutschland... :o
gruß stefan
Da paßt es ja, daß ich zwei Bilder gemacht habe, hoffentlich kann der Fachmann was erkennen:
Ja - eine zu lange Belichtungszeit. 
Im Ernst: Interessant wäre exakt eine steigende / fallende Flanke und das im zeitlichen Verlauf vor und hinter dem Levelshifter.
Schon mal direkt mit 3,3V ohne Shifter probiert?
na dann mach ich das, danke.
gruß stefan
Helmuth:
Pobier mal aus, ob Deine 2812 eventuell auch ohne Shifter mit den 3,3V zuverlässig arbeiten. Manche tun das. (Ohne Schutzwiderstand in der Datenleitung.)
Das war es, was ich mich nicht getraut habe, zu probieren: Es geht mit und ohne Schutzwiderstand!
Also werde ich einen 74HCT 245 bestellen und dann berichten!
Vorläufiges Fazit:
- Sorry an Daniel, wobei ich mir die Bemerkung nicht verkneifen kann, daß ein 800 kHz Signal unabhängig von der CPU-Frequenz sein sollte. Kannst ihm ja die Bilder weiterleiten.
- Ich werde 74HCT 245 testen
- WS2812 ist empfindlich
- Diese LED-Bauform gibt es nur als WS2812, sonst werde ich die mit getrennter Daten/Taktleitungen wie APA102 bevorzugen
Danke!
PS.: Ich werde bessere Bilder versuchen.
Sorry an Daniel, wobei ich mir die Bemerkung nicht verkneifen kann, daß ein 800 kHz Signal unabhängig von der CPU-Frequenz sein sollte. Kannst ihm ja die Bilder weiterleiten.
Der 800kHz Takt IST unabhängig vom Prozessortakt. Wenn dem nicht so wäre, würden die sensiblen (zickigen) 2812 gar nicht antworten. Das Problem ist dein I2C Levelshifter.
Schön, dass es jetzt funktioniert.
Grüße!
Ich zitiere mal aus dem FastLED-Forum (ich hoffe, das ist gestattet):
PaulStoffregen 22:03
The BSS138 is not an appropriate level shifter for WS2812. It has fast high-to-low performance due to the transistors, but slow low-to-high response due to the resistors and capacitance of pins and cables. The non-symetrical speed distorts the waveform, which is terrible for WS2812 where the relative width of pulses is used to communicate!
Damit trifft er den Nagel auf den Kopf! I2C nutzt bekanntlich Pullup-Widerstände, die auf dieser Platine mit 10 kOhm vorhanden sind. Nachdem ich nun einen 2 kOhm Widerstand zusätzlich gegen 5V geschaltet habe, funktioniert es nun auch mit Levelshifter. Bis ich Ersatz habe, kann ich erstmal so weitermachen.
Bitte richte meinen Dank an Daniel, Paul und einem gewissen Stefan aus!
Wollte gerade Pauls Erklärung forwarden, aber hat sich ja erledigt.
Gruß,
Helmuth aka Stefan Petrick
Nur der Vollständigkeit halber: Wenn man öfters was mit LEDs + Teensy machen möchte und vielleicht irgendwann auch mal Paralleloutput für mehr Speed oder größere Projekte gefragt ist, sollte man sich mal Pauls Octoadapter ansehen.
Levelshifter für 8 Kanäle, Teensy wird aufgesteckt, LEDs über Cat-Kabel angeschlossen.
Sehr praktisch und das Ganze für 10$.
Eisebaer:
da wird man ja optimistisch. ich hab' gestern einen teensy 3.1 bei reichelt bestellt und will damit ca. 250 WS2812 betreiben. hoffentlich wird's was.
Ich weiß ja, in welchem Forum ich hier schreibe, aber der Teensy hat ein paar durchdachte Sachen, die mich begeistern.
Helmuth:
Der 800kHz Takt IST unabhängig vom Prozessortakt. Wenn dem nicht so wäre, würden die sensiblen (zickigen) 2812 gar nicht antworten.
Um diesen Punkt kreisen noch meine Gedanken und ich hatte ja "unterbelichtete" Bilder versprochen, die ich nun noch nachliefern möchte.
Wenn A24 das Signal des Teensy bei 24 MHz und A72 bei 72 MHz ist, dann kommt durch meine schräge Elektronik (Funktion f) bei der LED entweder A'24= f(A24) oder A'72= f(A72) an. Wenn die Funktion konstant ist, bei A'24 die LEDs funktionieren, bei A'72 aber nicht, dann müssen A24 und A72 unterschiedlich sein.
Wenn ich nun meine "unterbelichteten" Bilder richtig interpretiere, ist das auch der Fall:
Ich stelle also die These auf, FastLED liefert abhängig von der CPU-Frequenz unterschiedliche Signale, die aber beide von den LED erkannt werden.
Sollten die Macher von FastLED meine These als Anlaß nehmen, diesen Sachverhalt mit besseren Methoden zu überprüfen, würde ich mich freuen.
Einleitung: Wenn das Datensignal nicht exakt im 800kHz Raster getaktet ist, versteht der WS2812 gar nichts. Das ist ein Fakt. Es gibt keine Clockleitung zum synchronisieren. Entweder der Takt passt perfekt, oder der LED Controller versteht überhaupt nichts mehr.
Zu Deinem Oszi Bild: Das ist nicht aussagekräftig, weil wir nicht wissen, welche Daten gerade an die LEDs gesendet werden. Konkret schauen wir uns eine beliebige Folge von digitalen Nullen und Einsen an, wissen aber nicht, WIEVIELE das jeweils sind.
Anders ausgedrückt: Solange Du nicht definiert eine 01010101... Folge sendest, weisst Du nicht, was Du siehst. 000011110000? 000111000? 001100?
Zwischen den Frames sind auch noch 50 µs Reset-Time. Details siehe Seite 4 vom Datenblatt.
Die in Deinem Bild nahegelegte 30% Abweichung des Grundrasters ist eine Illusion. Wie schauen einfach auf andere Daten, das ist alles.
Ein Logic Analyzer macht es leichter, sowas zu beobachten.
Aber das Photo vom Oszi selbst ist brauchbar!
Ich stelle also die These auf, FastLED liefert abhängig von der CPU-Frequenz unterschiedliche Signale, die aber beide von den LED erkannt werden.
Dem widerspreche ich.
Nichtsdestoweniger freue ich mich sehr über Dein Interesse am Thema und Deinen Forschergeist!
FastLED unterstützt übrigens viele verschiedene Plattformen mit unterschiedlichsten Taktfrequenzen. Mit den 2812ern können sie alle erfolgreich sprechen und die Anforderungen an die Timinggenauigkeit sind hoch. Das benötigte Signal wird von einem 8MHz ATTiny genauso erzeugt, wie von einem übertakteten ARM Cortex M4.
Ich weiß ja, in welchem Forum ich hier schreibe, aber der Teensy hat ein paar durchdachte Sachen, die mich begeistern.
Ja, der Teensy ist wahrlich toll und die Arduino Boards sehen dagegen alt aus!
Grüße,
Helmuth
Danke für deine Geduld und Deinen Widerspruch! Wenn ich eine These aufstelle, erwarte ich das auch nicht anders.
Helmuth:
Ein Logic Analyzer macht es leichter, sowas zu beobachten.Aber das Photo vom Oszi selbst ist brauchbar!
Hätte ich einen Logic Analyzer, würde ich nicht meine Urlaubskamera vor ein analoges Oszi halten und die Bilder hier zeigen.
Darum: Wer einen geeigneten Logic Analyzer zur Verfügung hat, ist aufgerufen, meine Fotos durch eine gute Messung zu ersetzen. Ich habe meine Messungen direkt am Teensy ohne Levelshifter gemacht. Der Sketch ist ein Beispiel aus der FastLED Bibliothek.
Ich würde mich freuen 
hi,
saleae bei ebay weltweit eingeben. unfair der entwicklerfirma gegenüber, aber halt nur 8 euro...
gruß stefan
Nun habe ich mir ein Schätzeisen geliehen, das die Meßwerte digital anzeigt, aber leider nicht genügend Speicher hat, um interessante Stellen untersuchen zu können.
Man sieht schon, das Signal ist unterschiedlich. Kein Beweis, aber genug, um weiter zu forschen. 
(The code is unknown - so I actually don't know which data is shown.)
Hauptsächlich ein Beispiel aus der Bibliothek:
#include "FastLED.h"
///////////////////////////////////////////////////////////////////////////////////////////
//
// Move a white dot along the strip of leds. This program simply shows how to configure the leds,
// and then how to turn a single pixel white and then off, moving down the line of pixels.
//
// How many leds are in the strip?
#define NUM_LEDS 10
// Data pin that led data will be written out over
#define DATA_PIN 6
#define BRIGHTNESS 50
// This is an array of leds. One item for each led in your strip.
CRGB leds[NUM_LEDS];
void setup() {
// sanity check delay - allows reprogramming if accidently blowing power w/leds
delay(2000);
// Uncomment one of the following lines for your leds arrangement.
// FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);
// FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);
FastLED.setBrightness(BRIGHTNESS);
}
void loop() {
leds[0] = CRGB::Green;
leds[1] = CRGB::Green;
leds[2] = CRGB::Green;
leds[3] = CRGB::Green;
leds[4] = CRGB::Green;
leds[5] = CRGB::Green;
leds[6] = CRGB::Yellow;
leds[7] = CRGB::Yellow;
leds[8] = CRGB::Red;
leds[9] = CRGB::Red;
FastLED.show();
delay(2000);
// Move a single white led
for (int whiteLed = 0; whiteLed < NUM_LEDS; whiteLed = whiteLed + 1) {
// Turn our current led on to white, then show the leds
leds[whiteLed] = CRGB::White;
// Show the leds (only one of which is set to white, from above)
FastLED.show();
// Wait a little bit
delay(100);
// Turn our current led back to black for the next loop around
leds[whiteLed] = CRGB::Black;
}
}
Auf Wunsch nehme ich auch jeden anderen Sketch, der besser geeignet ist
Die "optimized" Frequenzen hatte ich bisher ignoriert, da ich noch nicht herausfinden konnte, was da optimiert wird. Wenn es aber von Interesse sein sollte, so habe ich auch Kurven dafür:
Und weil ich gerade in Aktion bin, möchte ich meine Faszination mit diesem Bild zum Ausdruck bringen (Uwe, ich hoffe das ist ok?):
Ein schönes Bild!
Daniel Garcia schreibt:
"The code uses a loop to check against a clock value to decide when to drop the line back low. This loop takes about (let's say) six cycles to run, no matter the clock speed. Which means at 72mhz the loop takes 80ns but at 24mhz it takes 250ns.
If I say I want to hold the line high for 320ns, at 72mhz that's four iterations of the loop for 320ns, or worst case scenario, 5 for 400ns. However, at 24mhz, it takes two iterations of the loop, or 500ns. And there you have the 24mhz clock holding the line high for longer.
(The actual cycle counts and timings are different, but I'm not in a spot to check them but this should get the basic idea across).
To compound this, for the very low clock speeds (48mhz and under) I use hand chosen values for the high/low timings for these chips (to best fit in the low cycles counts for the variants that use hand counted asm code). Higher clock speeds I'm converting the desired times in ns to clock cycles counts, which may mean slightly different cycles counts (more accurate for the higher speed clocks, though). "
Der teensy mit der FastLED Bibliothek liefert also von der CPU-Frequenz abhängige Signale, die aber jeweils in der Toleranz der anzusteuernden LEDs liegen.
Durch meine fehlerhafte Beschaltung hat dann das Signal bei 24 MHz zufälligerweise die LED noch richtig angesteuert, während bei 72 MHz dies nicht mehr funktionierte. Um es mit Spock zu sagen: "Das ist logisch!"
Bitte richte Daniel Garcia meinen allerherzlichsten Dank aus! Und bei Dir bedanke ich mich natürlich auch!
Das Bild habe ich für jemanden gemacht, der sein Motorrad mit einer Drehzahlanzeige ausstatten wollte. Es kam auch der Vorschlag, dies mittels WS2812 zu realisieren. Da könnte man beispielsweise alle LED rot färben, wenn die Drehzahl in den kritischen Bereich gerät. Wahrscheinlich bin ich mit meinem Bild viel zu spät, das Motorrad schon winterfest gemacht. Aber gefallen tut es mir trotzdem