Guten Tag, ich versuche gerade eine WS2811 ansteuerung mit einen ATMEGA 32 zu realisieren. Der ATMEGA 32 taktet mit 16MHz und die Ansteuerung funktioniert mit 24 LEDs einigermaßen. Ich kann die 24 RGB-LEDs ansteuern und jeder eine Farbe zuweisen. Das einzige Problem, was besteht ist, dass das erste Bit manchmal eine Eins ist anstelle einer Null. Das hat zur Folge, dass die erste LED anfängt grün zu blinken. Ich bin schon mehrmals den Quellcode durchgegangen und finde den Fehler nicht. Vielleich könnt ihr mir weiterhelfen. Hir der Quellcode: #include <avr/io.h> #include <avr/interrupt.h> #include "WS2812.h" extern unsigned char LEDs[Anzahl]; extern uint16_t HSV_LEDs[Anzahl/12][3]; extern unsigned char flag; void intpwm(){ TCCR1A = 0x00; TCCR1B = 0x00; ICR1= 40; DDRD = 0xFF; TCCR2 = (1<<CS20) | (1<<CS21) | (1<<CS22); //TIMSK |= (1 << TOIE2); sei(); } void ausgabe(){ TCNT1 = 1; TCCR1A = (1 << WGM11); TCCR1B = (1<<CS10) | (1 << WGM12) | (1 << WGM13); TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[0] & 0b10000000){ OCR1AL = 25; } else{ OCR1AL = 5; } for(uint16_t i=0; i < Anzahl; i++){ TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); TCCR1A |= (1 << COM1A1); if(LEDs[i] & 0b10000000){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b01000000){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b00100000){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b00010000){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b000001000){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b00000100){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b00000010){ OCR1AL = 25; } else{ OCR1AL = 5; } TIFR = 0b00000100; while((0b00000100 & TIFR) == 0b00000000); if(LEDs[i] & 0b00000001){ OCR1AL = 25; } else{ OCR1AL = 5; } } TIFR = 0b00000100; while(!(0b00000100 & TIFR)); TCCR1A = 0x00; TCCR1B = 0x00; }
Oder nimmst einen Arduino mit der FastSpi-Lib: http://code.google.com/p/fastspi/ Hat bei mir schnell funktioniert. http://wiki.hacdc.org/index.php/WS2811_Arduino_Howto oder ohne Arduino: http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html
Für den Lerneffekt wollte ich es selber schreiben. Es funktioniert jetzt mit einer Datenrade von 600kBit/s. Das erste Bit schalte ich jetzt mit einen Feldeffekttransistor weg.
600kBits/s ?? Die WS2811 kann man auf 400kBit/s und 800kBit/s stellen, aber bei 600kBit/s hast Du ganz bestimmt ein Timing Problem. Das überhaupt was funktioniert liegt offensichtlich an der weitreichenden Fehlertoleranz des WS2811. Versuch das timing auf 400 oder 800 kBit/s zu bekommen. Dann klappt es (vermutlich) auch mit der ersten LED.
Die FastSpi-Lib des Arduino nimmte es auch nicht so genau. Ich habe zuerst die Signale auf dem Oszi angesehen und dachte, es wird nicht funktionieren, da die Pausen deutlich zu lange waren. Allerdings ging es doch auf Anhieb. Hier wird beschrieben, dass die Datenblätter wohl auch nicht einheitlich sind: http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html Die Nullen werden als kurze Pulse, die Einsen als lange Pulse kodiert. Ich nehme an, dass die Pausen dazwischen nicht ganz so kritisch sind.
Darf ich mal kurz dazwischenfragen, was du in dem Bild als Diffusor verwendest? Ist das transluzentes Acrylglas?
Also ich habe mich auch gerade mit dem MSP430 dran versucht. In C hängt das Timing extrem davon ab, welche Compiler-Optimierungen man aktiviert. Ich habe den Algorithmus zunächst in C programmiert, mit maximaler Opimierung Compiliert und dann den Code aus der erzeugten Assembler-Datei als Assembler direkt in C eingefügt, damit ich das Timing unter Kontrolle habe. Ich habe 4 LEDs in einer Dasy Chain. Der Daten-Ausgang ist P1.7. Der Code:
1 | #include <msp430.h> |
2 | #include <stdbool.h> |
3 | #define Byte unsigned char
|
4 | ...
|
5 | Byte Daten[12] = {20,39,85, 61,0,0, 0,116,0, 0,0,255}; |
6 | static Byte Bits[96] = {false}; |
7 | Byte ByteNr; |
8 | Byte BitNr; |
9 | static Byte BitIndex; |
10 | ...
|
11 | BitIndex = 0; |
12 | for (ByteNr = 0; ByteNr < 12; ByteNr++) { |
13 | Byte Merker = Daten[ByteNr]; |
14 | for (BitNr = 0; BitNr < 8; BitNr++) { |
15 | if (Merker & 128) { |
16 | Bits[BitIndex] = true; |
17 | } else { // 3 + 9 |
18 | Bits[BitIndex] = false; |
19 | }
|
20 | Merker = Merker << 1; |
21 | BitIndex = BitIndex + 1; |
22 | }
|
23 | }
|
24 | asm(" MOV.W #96,r14"); |
25 | asm(" MOV.W #Bits$1+0,r15"); |
26 | asm("Lbl$C$L5: "); |
27 | asm(" MOV.B @r15+,r13"); |
28 | asm(" TST.W r13"); |
29 | asm(" JNE Lbl$C$L6"); |
30 | asm(" OR.B #128,&P1OUT+0"); |
31 | asm(" nop;"); |
32 | asm(" nop;"); |
33 | asm(" AND.B #127,&P1OUT+0"); |
34 | asm(" nop;"); |
35 | asm(" nop;"); |
36 | asm(" nop;"); |
37 | asm(" nop;"); |
38 | asm(" nop;"); |
39 | asm(" JMP Lbl$C$L7"); |
40 | asm("Lbl$C$L6: "); |
41 | asm(" OR.B #128,&P1OUT+0"); |
42 | asm(" nop;"); |
43 | asm(" nop;"); |
44 | asm(" nop;"); |
45 | asm(" nop;"); |
46 | asm(" nop;"); |
47 | asm(" nop;"); |
48 | asm(" nop;"); |
49 | asm(" AND.B #127,&P1OUT+0"); |
50 | asm("Lbl$C$L7: "); |
51 | asm(" SUB.W #1,r14"); |
52 | asm(" JNE Lbl$C$L5"); |
53 | asm(" nop;"); |
54 | asm(" nop;"); |
55 | asm(" nop;"); |
56 | asm(" OR.B #128,&P1OUT+0"); |
@chris Ich denke das Datenblatt ist eindeutig, aber die verschiedenen Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen. Das ist auch die Quintessenz von http://bleaklow.com/2012/12/02/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html
Also, wenn der µC wirklich nichts anderes zu tun hat (bei vielen LEDs), kann man ja eure Varianten nehmen... aber Sinnvoll wäre schon was anderes... aber dann brauch man so ne nette Sache wie DMA (sollte zB. ein besser MSP430 auch besitzen)... Mein Ansatz läuft absolut Problemlos auf nem XMega: - UART SPI auf 4*800 kHz stellen (geht sehr gut durch sehr flexible Baudraten) - UART TX (oder in dem Fall MOSI) Invertieren (muss sein, damit der Ruhepegel Low ist! - je zwei Bits mit Lookup in 1 Byte umrechnen (auch invertieren) und in einem großen Buffer ablegen (wird dann leider logischerweise 4 mal so groß) -DMA starten und im Hintergrund schon wieder die nächste Animation berechnen, oder neue Daten über USB oder Ethernet empfangen... Grüße Basti
Basti schrieb: > aber dann brauch man so ne nette Sache wie DMA (sollte zB. > ein besser MSP430 auch besitzen) Das ist ja auch eine Kostenfrage und eine Frage der Beschaffung. In der "Value Line" MSP430Gxxxx ist DMA ein Fremdwort. Ich persönlich nutze hauptsächlich die beiden MSP430-Versionen, die mit dem Launchpad geliefert werden (MSP430G2553 + MSP430G2452). Trotzden danke für den Tipp. @Besserwisser: Vielen Dank für den Link. :-) Der Code von Alan Burlison gefällt mir sehr gut. Bei meinem (s.o.) habe ich pro Bit ein Byte verbraucht, was bei insgesamt 256 Byte RAM nicht gerade ratsam ist, dann ist bei 6 bis 8 LEDs nämlich irgenwann Schluss.
@ Besserwisser Die Ansteuerung habe ich zuerst mit 400kBit/s realisierirt und der Fehler ist auch aufgetreten. Später, als es dann lief (das erste Bit mit einen Transistor weggeschaltet), habe ich die Bitrate erhöt, um zu schauen was geht. Den Fehler kann man auch in den Bildern meines ersten Posts erkennen. @Frieder S Die Ausleuchtung der Felder habe ich mit 45x45x45 mm großen Kästchen aus Pappelsperrholz gelöst. Auf den Feldern sitz mattes Acrylglas (Ich weiß leier nicht mehr zu wieviel % Durchlässig). In jeden Käschen befinden sich vier LEDs aus der Sammelbestellung: Beitrag "[Mitbestellung] SMD5050 RGB-LED mit integriertem 8-bit PWM Controller"
Alao meine WS2811-LEDs sind sehr gemütlich anzusteuern. Frequenzen zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein muss eine "1" länger als 550ns. Kritisch ist lediglich der Jitter. Wenn die Frequenz des Datensignals nur ein klein wenig wackelt, also die Bits mal früher oder mal später kommen, dann gehen bei meinen LEDs massiv Bits verloren.
Probleme mit Jitter habe ich durch die Ansteurung mithilfe der Hardware-PWM nicht. Für 800MHz ist leider mein Code zu lagsam :( Die Optimierung habe ich auf O1 gestellt. Hat schonmal irgendwer getestet, wieviele LEDs man hintereinander schalten kann? Ich plane bei meinen Projet 384 LEDs hintereinander zu schalten.
lucki schrieb: > Frequenzen > zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das > Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein > muss eine "1" länger als 550ns. Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie 500ns + 6167ns und 550ns + 6117ns? Tobias Wagner schrieb: > Hat schonmal irgendwer getestet, wieviele LEDs man hintereinander > schalten kann? Ich hab's nicht getestet, sehe aber auch keinen Grund. Du kannst ja auch Tausende hintereinander hängen. Nur die Update-Häufigkeit der Farbmuster (sozusagen "frames per second") sinkt. Aber bei Super-8-Filmen ist man ja auch mit 12,5 fps ausgekommen, und das Bild ruckelte kaum. Das ist aber nur relevant, wenn Du "kontinuierliche" Veränderungen machen willst, und das Auge keine "Sprünge" wahrnehmen soll. Und bei 384 LEDs ist das ja noch total unkritisch. Du solltest nur darauf achten, dass bei der letzten LED noch genug Spannung ankommt, also dass der Spannungsabfall auf der Versorgungsleitung nicht zu groß wird.
Torsten C. schrieb: > Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie > 500ns + 6167ns und 550ns + 6117ns? Torsten C. schrieb: > lucki schrieb: >> Frequenzen >> zwischen 150kHz und 1,15MHz verstehen sie ohne Probleme, solange das >> Bit-Timing stimmt. Damit meine ich dass eine "0" unter 500ns lang sein >> muss eine "1" länger als 550ns. > > Interessant. Also 500ns + 370ns und 550ns + 320ns geht genau so gut wie > 500ns + 6167ns und 550ns + 6117ns? nach allem was ich mit meiner Hardware ertesten konnte kann ich bei meinen LEDs folgende Specs festlegen: f_min = ca. 147kHz f_max = 1,15MHz T0H_max <= 500ns T0L_min = ?? (< 220ns) hardware limitation T1H_min >= ?? (< 560ns) hardware limitation mehr Werte haben mich nicht interessiert!
Besserwisser >Ich denke das Datenblatt ist eindeutig, aber die verschiedenen >Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen. >Das ist auch die Quintessenz von >http://bleaklow.com/2012/1202/driving_the_ws2811_at_800khz_with_a_16mhz_avr.html "The exact timings seem to vary depending on which source you believe (800KHz mode):" Siehe Tabelle
Kann TOL tatsächlich beliebig irgendwo zwischen 370ns und 6583ns sein? Ich meine getestet, also nicht nach „Datenblatt“! Bei f = 147kHz und TOH = 220ns komme ich auf T0L = 6583ns. Bei f = 1,15MHz und TOH = 500ns komme ich auf T0L = 370ns. lucki schrieb: > Kritisch ist lediglich der Jitter. Wenn > die Frequenz des Datensignals nur ein klein wenig wackelt, also die Bits > mal früher oder mal später kommen, dann gehen bei meinen LEDs massiv > Bits verloren. Was ich noch nicht verstehe: * Einerseits sollen die Low-Zeiten innerhalb des o.g. Rahmens egal sein, * andererseits darf es keinen Jitter geben. Wie häufig dürfen sich denn die Zeiten ändern? Nur nach einem Reset? Oder alle 24 Bit? Oder nach jedem Bit? Zum Vergleich: Bei 1wire (ist ja ähnlich) darf nach jedem Bit eine beliebige Pause sein, nur ist hier der Ruhe-Pegel „High“ und beim WS2811 ist der Ruhe-Pegel „Low“. Weiss denn niemand, wie der WS2811-interne Zustandsautomat funktioniert?
@Torsten C. Ich hatte nur bedenke, dass die Weiterleitung der LEDs die Qualität der Datenübertragung beeinflusst und das Signal verjittert. Das mit der Stromversurgung ist mir bewusst ich schalte maximal 16 LEDs an 4 Adern Flachbandkabel. Mit den Timings musste ich auch ein bischen rumspielen. Ich hatte mich erst an die Timings aus den Datenblatt gehalten: http://www.adafruit.com/datasheets/WS2811.pdf Jedoch wurde dort eine Null als eine Eins erkannt. Die Zeiten konnte ich hundertprozentig durch die Hardware-PWM einhalten. Auch ein Puls von 62,5 ns wird als eine Null erkannt. Ich hatte anfangs Probleme, dass bei den Setzen des Compareregisers auf 0 die Ganzen LEDs anderauernd Nullen empfangen haben. Die 62,5ns haben dafür ausgereicht.
Tobias Wagner schrieb: > Ich hatte nur Bedenken, dass die Weiterleitung der LEDs die Qualität der > Datenübertragung beeinflusst und das Signal verjittert. So wie ich Alan Burlison verstanden habe, wird das Timing am Ausgang jeder LED aufbereitet ("signal reshaping"), so wie in seinem Oszilogramm zu sehen: http://bleaklow.com/images/2012/ws2811_in_out.png Also dürfte es sich eher verbessern als verschlechtern. Das gilt sicher für Jitter-freie Eingangssignale. Wie diese Signalaufbereitung auf Jitter reagiert, wäre interessant. So war auch meine o.g. Frage gemeint: "Wie häufig dürfen sich denn die Zeiten ändern? Nur nach einem Reset?" Vielleicht ist diese Signalaufbereitung der Grund, falls sich das Timing nur nach einem Reset ändern darf. Ansonsten steht ja z.B. im Datenblatt: "When the refresh rate is 30fps, cascade number ... are not less than 1024 points."
PS: Also wie ich die bisherigen Postings interpretiere: 1. Jitter ist wegen des "signal reshapings" unbedingt zu vermeiden, also f_frame muss zwischen zwei Resets konstant sein. 2. Der Abtastzeitpunkt (s. Bild) liegt bei:
Seht Ihr das auch so? Ich habe mir einen "MiniLA" (ebay 121096923360) bestellt und werde mir - zum ersten ausprobieren des Gerätes - die 15 Signale nach jedem "reshaping" mal anschauen.
Tobias Wagner schrieb: > Vielleich könnt ihr mir weiterhelfen. Tobias, sorry, aber mit TCCR1A, ICR1, OCR1AL, TIFR usw. kann ich nix anfangen. Besserwisser schrieb: > die verschiedenen > Implementierungen zeigen vorallem eins: Versuch 800kBit/s hinzubekommen. Nein, Besserwisser, die Frequenz scheint wirklich ziemlich egal zu sein. Es geht offenbar nur um wenig Jitter und den 525s Abtastzeitpunkt nach der steigenden Flanke. Also C (ohne Assembler) geht auch gut. Um wenig Jitter zu erzeugen, kopiere ich meine Bytes in ein Array Daten[] und dann ist's egal, ob mit_ oder _ohne "Test-Verzögerung" (s. Code). Das bisschen Jitter an den Byte-Grenzen akzeptieren meine 4 Dioden.
1 | for (x = 0; x < 12; x++) { |
2 | for (bit = 0; bit < 8; bit++) { |
3 | if (Daten[x] & 128) { |
4 | P1OUT = 128; // Bit setzen |
5 | asm(" nop;"); |
6 | asm(" nop;"); |
7 | asm(" nop;"); |
8 | asm(" nop;"); |
9 | asm(" nop;"); |
10 | asm(" nop;"); |
11 | asm(" nop;"); |
12 | asm(" nop;"); |
13 | asm(" nop;"); |
14 | P1OUT = 0; // Bit spät löschen |
15 | } else { |
16 | P1OUT = 128; // Bit setzen |
17 | asm(" nop;"); |
18 | P1OUT = 0; // Bit früh löschen |
19 | asm(" nop;"); |
20 | asm(" nop;"); |
21 | asm(" nop;"); |
22 | asm(" nop;"); |
23 | asm(" nop;"); |
24 | asm(" nop;"); |
25 | asm(" nop;"); |
26 | asm(" nop;"); |
27 | }
|
28 | Daten[x] <<= 1; |
29 | // Test-Verzögerung Beginn
|
30 | asm(" nop;"); |
31 | asm(" nop;"); |
32 | asm(" nop;"); |
33 | asm(" nop;"); |
34 | asm(" nop;"); |
35 | asm(" nop;"); |
36 | asm(" nop;"); |
37 | asm(" nop;"); |
38 | // Test-Verzögerung Ende
|
39 | }
|
40 | }
|
Warum gibt es zu diesem Thema eigentlich sich ständig wiederholende Diskussionen darüber, dass die LEDs auch bei Verletzung des im Datanblatt angegebenen Timings noch funktionieren? Es ist einfach eine saubere Arbeitsweise, sich an das Datenblatt zu halten. Da dieses problemlos auf den AVRs möglich ist, gibt es wenig Gründe das nicht zu tun. Wer weis, ob dieses Gehacke auch auf den neuen Devices (WS2812B) noch funktioniert? Oder bei der nächsten Produktionscharge des Controllerchips? Für Hobbykram ist die Herangehensweise ja ok, aber professionell ist das nicht... @Torsten: Die Funktionsweise und den Abtastzeitpunkt sehe ich ähnlich wie Du. Allerdings bin ich mir nicht ganz sicher, was das "reshaping" wirklich macht. Wird es durch eine interne synchrone Logik erzeugt, oder handelt es sich um eine weitere monostabile Kippstufe? Bei letzterem sollte Jitter ziemlich egal sein...
Tim . schrieb: > Warum gibt es zu diesem Thema eigentlich sich ständig wiederholende > Diskussionen darüber, dass die LEDs auch bei Verletzung des im > Datanblatt angegebenen Timings noch funktionieren? > > Es ist einfach eine saubere Arbeitsweise, sich an das Datenblatt zu > halten. Ja. Wenn's denn eins geben würde. Aber selbst die Datenblätter widersprechen sich: http://kt-elektronic.de/wawi11/artikeldaten/strip-rgb2812_30blsk-rita/ws2811.pdf http://kt-elektronic.de/wawi11/artikeldaten/strip-rgb2812_30blsk-rita/ws2812.pdf Und selbst das "reshaping" hält sich nicht an's eigene Datenblatt (siehe Bild). Ich kann die Diskussion daher nachvollziehen. 800 KHz sind ziemlich genau der geometrische Mittelwert aus 147kHz und 1,15MHz. Das paßt also.
>Ja. Wenn's denn eins geben würde. Aber selbst die Datenblätter >widersprechen sich: Also eigentlich ist das nicht so kompliziert. Es gibt nur ein WS2812 Datenblatt. In diesem sind erhebliche Toleranzen zu den genannten Werten angegeben. In den WS2812 ist der Ansteuer-IC im Gegensatz um WS2811 beleuchtet. Wer sich schon einmal mit HL-Physik auseinandergesetzt hat, wird schnell zu dem Schluss kommen, dass sich der WS2811/2 DIE hier durchaus anders verhalten kann. Vermutlich ist das genaue Verhalten des WS2812 abhängig vom Schaltzustand der Leuchtdioden...
>800 KHz sind ziemlich genau der geometrische Mittelwert aus 147kHz und >1,15MHz. Das paßt also. Da die Bausteine keine Quarzoszillatoren eingebaut haben, dürften die Toleranzen realtiv groß sein. Meine Vermutung: Die wichtigen Zeiten, die einzuhalten sind, sind die Pulslänge für Eins und die Pulslänge für die Null. Die Pausen dazwischen dürften relativ große Toleranzen haben. Die Pausen dürfen nur nicht in die Gegend des Reset-Signals kommen.
Hier mal ein paar Oszi-Screenshots. Gelb: Eingang LED0 ( FastSpi Output des Arduino ) Blau: Ausgang LED0 ( bzw. Eingang LED1 ) Die Logik der LED scheint eine Verschiebung des Pulses um 200ns vorzunehmen.
Äh... Entschuldigung. Da ist mir ein Fehler bei den Farben unterlaufen. Auf dem Oszi-Schirm sind sie anders ... Blau: Eingang LED0 ( FastSpi Output des Arduino ) Rot: Ausgang LED0 ( bzw. Eingang LED1 )
Torsten C. schrieb: > Ich … werde mir … die 15 Signale nach jedem > "reshaping" mal anschauen. Ich habe auf die Schnelle erstmal die ersten 4 genommen, siehe Bild. Verzögerung der L-H-Flanke: 560ns, 560ns, 550ns Der erste Wert von den folgenden ist vom µC, die drei danach aus den WS2812ern: Logische 1: 830ns, 650ns, 640ns, 640ns Logische 0: 330ns, 340ns, 330ns, 330ns Die Zeiten scheinen sich durch das "reshaping" auf 640ns / 330ns einzustellen. Sample-Zeitpunkt also ca. 485ns nach der steigenden Flanke. Der LA hat 'ne 10ns-Auflösung. Brauchen wir noch mehr Messungen?
>Verzögerung der L-H-Flanke: 560ns, 560ns, 550ns Seltsam, ist mehr als doppelt so viel wie bei meinen Oszi Messungen weiter oben ( 200ns ). Ob es wohl an den LEDs liegt?
chris schrieb: > Seltsam, ist mehr als doppelt so viel Oh, stimmt. Mein Fehler: Das sind die Zeiten zwischen den zwei blauen Markern im Bild, also vor und nach 3 LEDs. Also im Mittel 184ns pro "reshaping". Sorry und danke.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.