Arduino->WS2812B-> Arduino

[Al. K. (alterknacker)]

Hallo,
Arduino nach WS2812B ist ja problemlos.

Jetzt aber der Arduino NANO als Protokollempfänger und Auswertung,
z.B. auf 12 Ausgänge des Arduinos.
Dateneingang auf Pin2 oder 3.

Ist das machbar?

Edit:
Oder ESP32 Mini D1

Danke

[Oliver S. (phetty)]

Machbar ist das sicherlich, man muss ja nur das Protokoll mitlauschen.
Aber wozu?
Einfacher wäre es doch an der Datenquelle einzugreifen.

[Sascha R. (srt2018)]

Zumal doch jede WS2812B "ihre" Daten vom Beginn des Datenstroms entfernt 
und nur den Rest weitergibt (nach meinem Verständnis). Dann käme beim 
empfangenden Arduino nur das an, was der steuernde Arduino zusätzlich 
schickt, was also von keiner der vorhandenen WS2812B beachtet wurde.

[Al. K. (alterknacker)]

Der Arduino soll am letzten WS2812B angeschlossen werden und 
verschiedene Schaltvorgänge realisieren.
Im einfachsten Falle, ein Byte  zur Portausgabe.
Keine Weiterleitung des Datenstroms.

[MaNi (Gast)]

Ich würde es wenn es unbedingt sein muss mit einem ESP und der RMT 
Perepherie probieren:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/rmt.html

Dann brauchst du erst nach der Idle RX Erkennung den Prozessor und hast 
Zeit den durch die Perepherie erfassten Datenstrom zu zerlegen. Die 
restliche Zeit kann er vermutlich in den Sleep.

Wobei dann die Frage ist warum du bei einem ESP nicht einfach WLAN/BT 
verwendest?

[Markus (Gast)]

Ich könnte mir vorstellen, dass es für einen Atmega bassierten Arduino 
vom Timing her schwierig werden könnte.
Ein ESP sollte es von der Rechenleistung und Peripherie schaffen.

Da die WS2812 Signale pulslängenkodiert sind, könnte man die einzelnen 
Impulse vielleicht damit vermessen:

https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/

[Falk B. (falk)]

Al. K. schrieb:
> Der Arduino soll am letzten WS2812B angeschlossen werden und
> verschiedene Schaltvorgänge realisieren.
> Im einfachsten Falle, ein Byte  zur Portausgabe.
> Keine Weiterleitung des Datenstroms.

Ist machbar, wenn gleich nicht rein per "Arduino IDE, da muss man wohl 
mit Assembler ran. GGf. mit ein wenig Hardware, welche die 
Pulsdekodierug macht, dann wird es entspannter. Mittels Monoflop die 
Pulsbreite messen und auf der fallenden Flanke abtasten bzw. speichern. 
Aber alles in allem ist das eher ein Krampf. Eine einfache 
UART-Verbindung ist 100x einfacher, selbst bei hohen Baudraten.

[Stefan F. (Gast)]

Markus schrieb:
> Ich könnte mir vorstellen, dass es für einen Atmega bassierten Arduino
> vom Timing her schwierig werden könnte.
> Ein ESP sollte es von der Rechenleistung und Peripherie schaffen.

Ich true das einem Atmega locker zu. Beim ESP könnte hingegen das 
Betriebssystem (die WLAN Teile) stören. Da läuft dein eigenes Programm 
nicht ruckelfrei kontinuierlich durch und Interrupt Routinen werden 
nicht immer sofort ausgeführt.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Ich true das einem Atmega locker zu.

Ja, das kann er (angenommener Systemtakt 16Mhz). Aber es wird eng. Wenn 
nebenbei noch was anderes interruptgesteuert laufen soll (was in der 
konkreten Anwendung, soweit beschrieben, allerdings nicht der Fall ist), 
wird es sogar sehr eng. Da muss man schon ganz ordentlich "tricksen", um 
das zuverlässig hinzubekommen.

[Markus (Gast)]

>Ja, das kann er (angenommener Systemtakt 16Mhz).

Jetzt wo Ihr's erwähnt: Ich würde sagen, das geht auch in C mit Polling 
und direkter Pinabfrage. Die Interrupts kann man vorher mit CLI(); 
blockieren.
Der Compiler wird so gut sein und die paar Befehle optimieren.

[Sebastian (Gast)]

Markus schrieb:
>> Ja, das kann er (angenommener Systemtakt 16Mhz).
>
> Jetzt wo Ihr's erwähnt: Ich würde sagen, das geht auch in C mit Polling
> und direkter Pinabfrage. Die Interrupts kann man vorher mit CLI();
> blockieren.
> Der Compiler wird so gut sein und die paar Befehle optimieren.

Denk ich auch. Ein Bit ist 1,2us lang. Man pollt z.B. immer bis zur 
fallenden Flanke, wartet dann bis zur Mitte des Bits, und wertet dann 
den Portstatus aus. Oder man benutzt ICP1. Für ganz wenige Bits könnte 
man vielleicht auch die UART missbrauchen.

LG, Sebastian

[B. W. (yesitsme)]

Könnte man vielleicht mit einem Timer/PWM die Clock fürs SPI erzeugen? 
Angelehnt an den "one-shot Modus" der AVR Timer.

[Stefan F. (Gast)]

B. W. schrieb:
> Könnte man vielleicht mit einem Timer/PWM die Clock fürs SPI erzeugen?

Im Master Modus kann der ATmega328 den SPI Takt nur vom 
System-Oszillator (mit Vorteiler) ableiten. Im Slave Modus muss der Takt 
extern zugeführt werden. Diesen Eingang kann man bestimmt auch mit dem 
Ausgang eines Timers verbinden, aber wie synchronisierst du den Takt 
dann mit dem Signal?

Außerdem glaube ich, dass du immer 8 Takte brauchst, vorher gibt es für 
die Software kein Bytes zum Auslesen.

[B. W. (yesitsme)]

Auf die Steigende Flanke vom WS2812 Signal ein Interrupt setzen. Im ISR 
dann einen Startwert vom Timer setzen. Mit dem Timer im PWM dann die CLK 
fürs SPI erzeugen lassen. Clear wird benutzt, damit der Timer nur einmal 
läuft.

Hmm... vielleicht übersehe ich da gerade auch etwas.

Stefan ⛄ F. schrieb:
> Außerdem glaube ich, dass du immer 8 Takte brauchst, vorher gibt es für
> die Software kein Bytes zum Auslesen.

Da das Protokoll vom WS2812 Byte-orientiert ist, seh ich da noch nicht 
mal ein Problem drin,

[Stefan F. (Gast)]

B. W. schrieb:
> Hmm... vielleicht übersehe ich da gerade auch etwas.

Ich denke das dauert zu lange. Bedenke dass die ISR nicht immer sofort 
aufgerufen wird und einige Takte braucht, um den Stack zu beschreiben.

Wenn das die Einzige Aufgabe wäre, dann geht das vielleicht noch. Aber 
du brauchst mindestens noch eine Timeout Erkennung, sonst kommst du mit 
dem Zählen der Bits rasch durcheinander.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Außerdem glaube ich, dass du immer 8 Takte brauchst, vorher gibt es für
> die Software kein Bytes zum Auslesen.

Das wäre kein Problem. Das Problem ist vielmehr, dass die SPI-Einheit 
nicht gepuffert ist. Wenn überhaupt, geht's mit der UART im 
SPI-Master-Modus. Dann entfällt auch das Geraffel mit dem Timer, die 
UART versorgt sich selber mit einem Takt.

Dass der SPI-Takt dann natürlich nicht synchron mit den Daten ist, muss 
man halt dadurch ausgleichen, dass man höherer Bitrate abtastet, das 
zehrt aber natürlich einen Teil des gewonnenen Vorteils gleich wieder 
auf. Ich denke mal, man bräuchte mindestens 4x den Takt der der 
WS28xx-Datenstrippe, um das hinreichend gut abzutasten, also 3,2MHz 
SPI-Takt. Die Interrupts würden dann mit 3.2M/8=400kHz erfolgen, bei 
16MHz hätte man also bis zu 32 Nutztakte für jede ISR und durch die 
Doppel-Pufferung der UART könnte eine Latenz von bis zu ca. 5µs 
ausgeglichen werden, jedenfalls so lange sie nur verhältnismäßig selten 
auftritt.

Also in Asm auf jeden Fall machbar. Arbeitintensiv ist dabei vor allem 
der Decoder, der das asynchron gelesene Gesülze in Bits übersetzt. Das 
Ding müßte ziemlich sicher tabellenbasiert sein, sonst gibt es wohl 
keine Chance, das in unter 32 Takten abzufackeln. Zum Glück hat der 
Arduino 32k Flash, da passt einiges an Tabellen rein. Nur müssen sie 
halt erstmal "konstruiert" werden.  Al. K. traue ich das keinesfalls 
zu...

[Joachim B. (jar)]

c-hater schrieb:
> Zum Glück hat der
> Arduino 32k Flash,

und es gibt mehr als einen

Nachbau Arduino ATmega1284p 128k flash z.B. Bobuino mighty mini 1284p
Original Arduino ATmega2560 256k flash

[Al. K. (alterknacker)]

Hallo,
habe natürlich alles verfolgt und es ist recht interessant.
Ich habe seit 20 Jahren ASM Programmierung aufgegeben und möchte mir das 
nicht mehr antun.
Damals war DMX für die Band aktuell.
In den 80 zigern der U880.

Habe jetzt mal auf die schnelle 8 WS2812B angesteuert.
Mit vorhandenen Lib.
Wenn ich den Daten Steuereingang Abschalte bleiben die Lichtmuster 
erhalten.
Sende ich nur für 7 LEDs , kann ich die Lichtmuster ändern ohne das die 
achte Led beeinflusst wird.

Das bedeutet, wenn ich jetzt 9 Leds definiere und anspreche, das nur 3 
Byte
aus dem letzten Led Datenausgang ausgewertet werden müssen.
Oder eben nur ein Byte um es einfacher zu machen.

Mit dem ESP32 bei abgeschalteten Wifi und Bluetooth, sollte es doch dann 
möglich sein dies auszuwerten.
,,mit der Arduino IDE.


Die Bitlänge könnte doch mit einen Monoflop selektiert werden, wie oben 
schon geschrieben.
Wenn jetzt noch ein 8Bit Schieberegister eingesetzt wird könnte es noch 
einfacher werden.
Ohne den Geraffele wäre es natürlich besser.

MfG
alterknacker

[Johannes S. (Gast)]

Das einfachste wird sein das IC WS2811 zu nehmen, dann hat man 3x PWM 
pro Chip der wenige ct. kostet.
Das gibt es sogar schon ausgegoren für Modellbahn Anwendungen:
https://wiki.mobaledlib.de/

[Al. K. (alterknacker)]

Johannes S. schrieb:
> Das einfachste wird sein das IC WS2811 zu nehmen, dann hat man 3x PWM
> pro Chip der wenige ct. kostet.

Hat der das gleiche Protokoll, so das man es einfach zwische/anhängen 
kann?

[Johannes S. (Gast)]

das ist afaik der gleiche Chip wie in den LED, nur eben ohne LED. Muss 
man sich mal durch die genannte Website hangeln.

[Joachim B. (jar)]

Al. K. schrieb:
> Hat der das gleiche Protokoll

Johannes S. schrieb:
> das ist afaik der gleiche Chip wie in den LED

hey keine Fakenews!

1. WS2812B Nur Data, eine Leitung in DI und eine raus DO zu +5V und GND
2. WS2811 Din & CLKin sowie Dout & CLKout zu weiteren Chips

Wie dann die einzelne LED ist müsste aus der PWM ergründet werden.
Einziger Vorteil, es gibt ein Clk den man nutzen kann, falls das 
überhaupt ein Vorteil ist denn man muss den CLK bei der WS2812B raten 
wissen oder sonst was, die Toleranz ist riesig groß, ob in der WS2812B 
nun 800kHz eingehalten wird weiss niemand, könnte man aber nach den Bits 
ausknobeln.

[Al. K. (alterknacker)]

Johannes S. schrieb:
> das ist afaik der gleiche Chip wie in den LED, nur eben ohne LED. Muss
> man sich mal durch die genannte Website hangeln.

Werde ich mal machen.
Bei Am..relativ teuer!

Joachim B. schrieb:
> hey keine Fakenews!

Dann passen die nicht zusammen!

[Johannes S. (Gast)]

Joachim B. schrieb:
> 2. WS2811 Din & CLKin sowie Dout & CLKout zu weiteren Chips

http://www.led-studien.de/datasheet/WS2811.pdf
da sehe ich keinen getrennten clk und Datenpin.

bei eBay in kleinen Mengen ca. 30 ct./Stück, bei Ali ca 8€ für 100 
Stück.
Ja, verdammt teuer.

[Al. K. (alterknacker)]

Johannes S. schrieb:
> Ja, verdammt teuer.

Da bestellt mein Kumpel nicht, nur AMA..

[B. W. (yesitsme)]

Joachim B. schrieb:
> 2. WS2811 Din & CLKin sowie Dout & CLKout zu weiteren Chips

Hast du mal das Datenblatt dazu?

[Johannes S. (Gast)]

Al. K. schrieb:
> Da bestellt mein Kumpel nicht, nur AMA..

aber sonst gehts noch?
Ich habe wirklich lange überlegt die Tipps zu posten, du machst deinem 
Namen wieder alle Ehre.

[Al. K. (alterknacker)]

Johannes S. schrieb:
> Ich habe wirklich lange überlegt die Tipps zu posten, du machst deinem
> Namen wieder alle Ehre.

..jeder hat seine Prinzipien, das hat mit dem fachlichen nichts gemein.

[Falk B. (falk)]

Johannes S. schrieb:
> Das einfachste wird sein das IC WS2811 zu nehmen, dann hat man 3x PWM
> pro Chip der wenige ct. kostet.

Das nützt aber nix, denn der OP will ja das 8 Bit Wort im AVR haben, umd 
damit irgendwas zu machen.

Man kann es vermutlich per ASM im AVR hinkriegen, aber das ist schon 
sportlich. Man kann es aber auch zumindest in Hardware vorverarbeiten. 
Dazu könnte ein Monoflop reichen, das die Bits dekodiert und per 
Flanke zur Verfügung stellt. Man kann das auch in einem extra AVR, z.B. 
ATtiny2313 machen, der dann die 8 Bits parallel ausgibt und per 
Handshake an den "echten" Empfänger weitergibt. So eine Art WS2812 UART. 
In einem CPLD wäre das einfach, ein paar Zähler und ne State machine. 
Aber das ist deutlich mehr Hard- und Softwareaufwand.

Wer die sportlich Herausforderung liebt, kann das machen. Wer ein 
paraktisches Problem lösen will, nimmt normales UART.

[Stefan F. (Gast)]

Falk B. schrieb:
> Man kann das auch in einem extra AVR, z.B.
> ATtiny2313 machen, der dann die 8 Bits parallel ausgibt und per
> Handshake an den "echten" Empfänger weitergibt.
> So eine Art WS2812 UART.

So in der Art dachte ich mir das auch. Man könnte die Daten auch seriell 
ausgeben (fire and forget), die UART/USI arbeitet ja von ganz alleine.

[Joachim B. (jar)]

B. W. schrieb:
> Hast du mal das Datenblatt dazu?

https://www.alldatasheet.com/datasheet-pdf/pdf/1132633/WORLDSEMI/WS2811.html

selber suchen wäre nett!

aber bei der Suche fiel mir auf das ich WS2811 mit WS2801 verwechselte

der WS2801 hat Data und Clock, der WS2811 nur Data, sollte also doch 
passen, nur wozu?

Wer wirklich für jede LED den Dimmstatus auswerten will muss parallel 
alle Daten aufzeichnen. Es fällt mir kein Szenario ein wozu man diesen 
Chip am Ende einer WS2812B Kette brauchen soll!

[Christian M. (christian_m280)]

Sascha R. schrieb:
> Daten vom Beginn des Datenstroms entfernt und nur den Rest weitergibt

Wäre es eventuell denkbar, dass der "Rest" nach der letzten LED ein 
anderes Datenformat ist, dass einfacher auszuwerten ist, aber trotzdem 
weitergeleitet wird... Nur so eine Überlegung...

Gruss Chregu

[Stefan F. (Gast)]

Christian M. schrieb:
> Wäre es eventuell denkbar ...

Nein. Die LEDs sind ja gerade dazu gemacht, dass man sie miteinander 
verketten kann. Eingang und Ausgang "sprechen" das gleiche 
Übertragungsprotokoll.

[Christian M. (christian_m280)]

Stefan ⛄ F. schrieb:
> Nein

OK. Ich dachte nur, wenn man nach der letzten LED ein anderes Protokoll 
reinwürgt, wird das dann ausgegeben?

Gruss Chregu

[Mario M. (thelonging)]

Ich könnte mir vorstellen, dass das funktioniert. Die WS2812 werden, 
nachdem sie ihre Daten empfangen haben, den Eingang auf den Ausgang 
weiter leiten, bis 50us L-Pegel einen Reset einleiten. So könnte man 
unter Vermeidung dieser Zeit auch ein (invertiertes) UART-Signal 
durchschicken.

[Stefan F. (Gast)]

Christian M. schrieb:
> Ich dachte nur, wenn man nach der letzten LED ein anderes Protokoll
> reinwürgt, wird das dann ausgegeben?

Wie willst du denn in den Ausgang der letzten LED etwas "rein würgen"?

Das ist ein Ausgang, kein Eingang.

[Christian M. (christian_m280)]

Stefan ⛄ F. schrieb:
> Wie willst du denn in den Ausgang der letzten LED etwas "rein würgen"?
> Das ist ein Ausgang, kein Eingang.

Mario M. schrieb:
> Die WS2812 werden, nachdem sie ihre Daten empfangen haben, den Eingang
> auf den Ausgang weiter leiten, bis 50us L-Pegel einen Reset einleiten.

Gruss Chregu

[Stefan F. (Gast)]

Stefan ⛄ F. schrieb:
> Wie willst du denn in den Ausgang der letzten LED etwas "rein würgen"?
> Das ist ein Ausgang, kein Eingang.

Christian M. schrieb:
> Mario M. schrieb:
>> Die WS2812 werden, nachdem sie ihre Daten empfangen haben, den Eingang
>> auf den Ausgang weiter leiten, bis 50us L-Pegel einen Reset einleiten.

So einfach geht das nicht. Die Chips leiten das Signal nicht einfach 1:1 
durch sondern dekodieren es und erzeugen es neu. Deswegen muss man sich 
da schon ans Übertragungsprotokoll halten.

Ohne diese Aufbereitung des Signal wäre es nicht möglich, unendlich 
viele dieser LEDs hintereinander zu schalten.

[Christian M. (christian_m280)]

Stefan ⛄ F. schrieb:
> dekodieren es und erzeugen es neu.

War nur ne Idee...

Gruss Chregu

[Al. K. (alterknacker)]

Al. K. schrieb:
> Habe jetzt mal auf die schnelle 8 WS2812B angesteuert.
> Mit vorhandenen Lib.
> Wenn ich den Daten Steuereingang Abschalte bleiben die Lichtmuster
> erhalten.
> Sende ich nur für 7 LEDs , kann ich die Lichtmuster ändern ohne das die
> achte Led beeinflusst wird.
>
> Das bedeutet, wenn ich jetzt 9 Leds definiere und anspreche, das nur 3
> Byte
> aus dem letzten Led Datenausgang ausgewertet werden müssen.
> Oder eben nur ein Byte um es einfacher zu machen.

Ist meine Schlussfolgerung richtig?


Wenn ich also 12 LEDs definiere bei 8 LEDs extern werden 4*3 Byte aus 
dem 8 LED Ausgang geschickt?

[Stefan F. (Gast)]

Al. K. schrieb:
> Ist meine Schlussfolgerung richtig?

Ja ist richtig. Schau doch einfach mal ins Datenblatt der WS2812, da 
steht das drin.

[Al. K. (alterknacker)]

Stefan ⛄ F. schrieb:
> Ja ist richtig. Schau doch einfach mal ins Datenblatt der WS2812, da
> steht das drin.

Wenn ich durch logische Schlussfolgerungen auf ein Ergebnis komme,
was sich dann auch bestätigt,
dann bin ich richtig Stolz auf mich und kann mir ständig auf die 
Schulter klopfen.
;--)))

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> So einfach geht das nicht. Die Chips leiten das Signal nicht einfach 1:1
> durch sondern dekodieren es und erzeugen es neu. Deswegen muss man sich
> da schon ans Übertragungsprotokoll halten.

Ja. Allerdings "regenerieren" die WS28xx nicht wirklich das gesamte 
Timing (dazu müssten sie die Daten buffern), sondern nur die beiden 
Zeiten T0H und T1H.

Die Zykluszeit hat hingegen weitgehend derjenigen unter Kontrolle, der 
den Kram ansteuert, so lange er nur weit genug weg bleibt von Trst.

D.h.: das Konzept von Mario M. geht grundsätzlich und ist bezüglich der 
Verringerung der Anforderungen an den Empfänger so dermaßen attraktiv, 
das es sehr wohl lohnt, weiter darüber nachzudenken.

Wenn man das Signal hardwaremäßig invertiert, bevor es RXD des 
Empfänger-Arduino erreicht, ist die Sache sogar ziemlich einfach 
umzusetzen. Voraussetzung ist halt nur, dass man auf der Arduino auf der 
Sendeseite auch für eine konstante Zykluszeit der WS28xx-Bits sorgt.

Das ist bei Timerhardware-basierten Umsetzungen des WS28xx-Protokolls 
kein Problem. Bei in C hingepfuschtem Bitbanging natürlich schon...

[Falk B. (falk)]

c-hater schrieb:
> Das ist bei Timerhardware-basierten Umsetzungen des WS28xx-Protokolls
> kein Problem. Bei in C hingepfuschtem Bitbanging natürlich schon...

Es gibt auch Libs mit ASM ;-)

Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

[c-hater (Gast)]

Falk B. schrieb:

> Es gibt auch Libs mit ASM ;-)
>
> Beitrag "Re: Frage zu IR-Remote+LED-Strips an AVR"

OK, man kann natürlich in jeder Sprache pfuschen. In Assembler 
allerdings könnte man zumindest AUCH auch mit Bitbanging 
REPRODUZIERBAR konstante Zykluszeiten umsetzen...

[B. W. (yesitsme)]

Joachim B. schrieb:
> selber suchen wäre nett!

Hab ich... hab aber vermutet, das es sich um 2 unterschiedliche Chips 
mit der selben Bezeichnung handeln könnte.


Joachim B. schrieb:
> aber bei der Suche fiel mir auf das ich WS2811 mit WS2801 verwechselte

Aber gut, das sich das geklärt hat.

[Mario M. (thelonging)]

c-hater schrieb:
> .h.: das Konzept von Mario M. geht grundsätzlich und ist bezüglich der
> Verringerung der Anforderungen an den Empfänger so dermaßen attraktiv,
> das es sehr wohl lohnt, weiter darüber nachzudenken.

Bei genauerer Betrachtung scheinen die Teile wirklich eine Statemachine 
mit eigenem Takt zu haben, was ein Abweichen vom vorgesehenen Protokoll 
zumindest erschwert.

https://cpldcpu.wordpress.com/2014/01/14/light_ws2812-library-v2-0-part-i-understanding-the-ws2812/

[c-hater (Gast)]

Mario M. schrieb:

> Bei genauerer Betrachtung scheinen die Teile wirklich eine Statemachine
> mit eigenem Takt zu haben, was ein Abweichen vom vorgesehenen Protokoll
> zumindest erschwert.

Haben sie. Aber effektiv tun sie halt nur eins: T0H und T1H in den Daten 
möglichst sauber separiert zu halten (also die kurzen High-Pulse, deren 
Dauer die eigentliche Information ist).

Für mehr Eingriffsmöglichkeiten fehlt der Statemachine der 
Hardware-Wumms, eben ein Buffer. Und weil das so ist, kontrolliert der 
Sender immer die Bit-Zykluszeit.

Zumindest bis zu der Grenze, die Trst setzt. Sprich: ein T0L oder T1L, 
welches Trst erreicht, mutiert zu einem tatsächlichen Reset der LED, die 
ihn erkannt hat (und aller folgenden LEDs).

[Al. K. (alterknacker)]

..zu meinen Verständnis:
wenn ich einen Sender generiere welchen nach Ausgabe eines H Pegels am 
pin
welcher zum DI der  Leds geht.
Danach Treset als Low >=50 ys ausgebe
danachfolgt 24 mal ein TOH (0,35yS) oder T1H (0,7yS) Impuls, gefolgt von 
dem
L Pegel von >2yS  50yS<  um die 3 Farbbytes R/G/B zu füllen.

Das könnte man vielleicht mit der IDE zu Fuß programmieren.

[Falk B. (falk)]

c-hater schrieb:
> OK, man kann natürlich in jeder Sprache pfuschen. In Assembler
> allerdings könnte man zumindest AUCH auch mit Bitbanging
> REPRODUZIERBAR konstante Zykluszeiten umsetzen...

Bist du blind oder auf Entzug? Das ist taktgenau reproduzierbar!

[Thomas E. (thomase)]

Al. K. schrieb:
> Der Arduino soll am letzten WS2812B angeschlossen werden und
> verschiedene Schaltvorgänge realisieren.
> Im einfachsten Falle, ein Byte  zur Portausgabe.
> Keine Weiterleitung des Datenstroms.

Hier eine kleine Anregung. Ich wollte sehen, ob ich das mit einem Attiny 
hinkriege. Obwohl das ja eigentlich gar nicht funktionieren kann, weil 
das ein AVR ist und nicht in Assembler programmiert ist, bin ich mir 
immer noch sicher, daß das funktioniert hat. Ist aber schon ein paar 
Jahre her. Was nicht funktionierte, ist das Weiterleiten an einen 
nachfolgenden WS2812. Ein weiterer WS25 funktionierte allerdings. Glaube 
ich. Wie schon gesagt, ist etwas länger her. Aber dein Controller soll 
ja auch der letzte in der Reihe sein.

Die erste while-Schleife dekodiert die Daten, die zweite leitet das, was 
danach kommt, weiter. Danach werden dann die Bits sortiert und in die 
PWM-Register geschrieben. Wenn man sie stattdessen auf einen Port 
schreibt, sollte das das sein, was du machen willst.

Dass die Delay-Zeiten gar nicht so zum WS2812-Timing passen, liegt 
daran, dass die Latenzen der jeweiligen Schleifen auch ihren Anteil 
liefern.

[Sebastian (Gast)]

Was macht der Compiler denn aus _delay_us(0.1)? Ein NOP? Oder zwei?

LG, Sebastian

[Stefan F. (Gast)]

Falk B. schrieb:
> Bist du blind oder auf Entzug? Das ist taktgenau reproduzierbar!

Mal behauptet er, dass der gcc das Programm aus immer gleichen 
vorgefertigten Bausteinen zusammenfügt, an anderen Tagen behauptet er, 
dass der gcc zufälligen Code erzeugt.

Das ist halt seine Rolle, die er hier spielt: Null Ahnung vortäuschen 
und maximal lästern. Leider schnallt er nicht, dass er der einzige ist, 
der das unterhaltsam findet.

[c-hater (Gast)]

Falk B. schrieb:

> c-hater schrieb:
>> OK, man kann natürlich in jeder Sprache pfuschen. In Assembler
>> allerdings könnte man zumindest AUCH auch mit Bitbanging
>> REPRODUZIERBAR konstante Zykluszeiten umsetzen...
>
> Bist du blind oder auf Entzug? Das ist taktgenau reproduzierbar!

Naja, genau das sagte ich doch: in Asm geht das prinzipiell, in C 
prinzipiell nicht. Ich verstehe dein Problem nicht.

Ah, jetzt ja: Du hast meine Aussage auf den konkret geposteteten 
Asm-Code bezogen. Nein, war sie nicht. Den hatte ich mir nicht einmal 
angeschaut, weil für mich uninteressant.

WS28xx steuere ich seit vielen Jahren an, mit meinem eigenen Code. Der 
allerdings je nach Target und konkreten Anforderungen der Anwendung 
durchaus massiv variiert. Von Bitbanging über Timer, USART(SPI), 
USART(native) bis hin zum USI und den SPIs der 441/841 habe ich alles 
schonmal gebraucht und umgesetzt.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Mal behauptet er, dass der gcc das Programm aus immer gleichen
> vorgefertigten Bausteinen zusammenfügt

Das macht er definitiv. So arbeiten Compiler nunmal, der GCC ist da 
keine Ausnahme.

> an anderen Tagen behauptet er,
> dass der gcc zufälligen Code erzeugt.

Das habe ich nirgendwo behauptet. Er erzeugt nur bezüglich des 
Timingverhaltens unvorhersehbaren Code. Weil von Version, 
Optimierungseinstellungen und Kontext abhängig.

> Das ist halt seine Rolle, die er hier spielt: Null Ahnung vortäuschen
> und maximal lästern. Leider schnallt er nicht, dass er der einzige ist,
> der das unterhaltsam findet.

Labersack.

[Stefan F. (Gast)]

>> dass der gcc das Programm aus immer gleichen
>> vorgefertigten Bausteinen zusammenfügt

c-hater schrieb:
> Das macht er definitiv.

Ja, du hast Recht. Und jetzt geh wieder spielen.

[Al. K. (alterknacker)]

Al. K. schrieb:
> ..zu meinen Verständnis:
> wenn ich einen Sender generiere welchen nach Ausgabe eines H Pegels am
> pin
> welcher zum DI der  Leds geht.
> Danach Treset als Low >=50 ys ausgebe
> danachfolgt 24 mal ein TOH (0,35yS) oder T1H (0,7yS) Impuls, gefolgt von
> dem
> L Pegel von >2yS  50yS<  um die 3 Farbbytes R/G/B zu füllen.
>
> Das könnte man vielleicht mit der IDE zu Fuß programmieren.

wenn nicht muss ich vielleicht doch noch ein bissel ASM
versuchen.
Habe noch genug Pics und AVRs rumliegen.
..aber erst mal mit der IDE!

[Stefan F. (Gast)]

Al. K. schrieb:
> wenn nicht muss ich vielleicht doch noch ein bissel ASM

Mann kann auch ein paar Zeilen Assembler in C einbetten, wenn es sein 
muss.

[Al. K. (alterknacker)]

Stefan ⛄ F. schrieb:
> Mann kann auch ein paar Zeilen Assembler in C einbetten, wenn es sein
> muss.

Habe ich bis jetzt über 20 Jahre erfolgreich vermieden.;-))

Ist mein Verständnis vom Sende Protokoll richtig?

[Stefan F. (Gast)]

Al. K. schrieb:
> Ist mein Verständnis vom Sende Protokoll richtig?

Das exakte Timing wurde in der Vergangenheit mehrfach geändert. Ich habe 
dort beschrieben, wie ich es heute implementieren würde, um zu allen 
Varianten kompatibel zu sein: 
http://stefanfrings.de/mikrocontroller_buch/Einstieg%20in%20die%20Elektronik%20mit%20Mikrocontrollern%20-%20Band%202.pdf#page=82

[Al. K. (alterknacker)]

@Stefan
Zitat:
Nachdem alle LEDs ihre Helligkeitswerte erhalten haben, halte die 
Daten-Leitung für mindestens
280 μs auf LOW. In diesem Moment ändert sich die Helligkeit aller LEDs 
auf den vorher
festgelegten Wert.

Du sendest sofort die Bitinformtion und danach machst du Reset/Pause
von mindestens 280 μs auf LOW.

[Stefan F. (Gast)]

Al. K. schrieb:
> Du sendest sofort die Bitinformtion und danach machst du Reset/Pause
> von mindestens 280 μs auf LOW.

Ja. Ist daran etwas falsch? Oder warum sonst hast du den Satz zitiert?

[Al. K. (alterknacker)]

Stefan ⛄ F. schrieb:
> Ja. Ist daran etwas falsch? Oder warum sonst hast du den Satz zitiert?

Weil ich immer dachte das zuerst der TResetimpuls gesendet wird.

Ich beschäftige mich seit über einen Jahr jetzt etwas ernsthafter mit 
diesen Teilen.

MfG

[Stefan F. (Gast)]

Al. K. schrieb:
> Weil ich immer dachte das zuerst der TResetimpuls gesendet wird.

Laut Datenblatt dient der Reset dazu, die übertragenen Werte in die 
internen PWM Timer zu übertragen.

Mit einem Initialen Reset wie beim Mikrocontroller hat das nichts zu 
tun. Ich finde den Begriff "Reset" an dieser Stelle deswegen auch 
ziemlich irreführend.

Dass man nach dem Einschalten der Stromversorgung eine gewisse Zeit lang 
warten muss, sollte klar sein. Dafür sorgt ja normalerweise schon die 
interne Reset-Schaltung im steuernden Mikrocontroller.

Ist dir aufgefallen, dass ich einen "1" Impuls etwas länger als 0,7 µs 
mache? Ich habe das aus den Datenblättern vom WS2812 und WS2812B v1 bis 
v5 abgeleitet.

[Al. K. (alterknacker)]

Habe ein wenig mit dem ESP32 experimentiert, mit der Arduino IDE

digitalWrite(DatOut,HIGH);    116 ns
digitalWrite(DatOut,LOW);     116 ns

Davon habe ich alles ableiten können.

Jedenfalls kann ich die LEDs definiert ansteuern.
Bis jetzt nur Vollfarben.
Morgen vielleicht mal eine Funktion machen mit Übergabe der Led Nr. und 
der Farbwerte.

MfG
alterknacker

[Christian M. (christian_m280)]

Al. K. schrieb:
> Jedenfalls kann ich die LEDs definiert ansteuern.

Ja ja, Du wolltest aber:

Al. K. schrieb:
> Jetzt aber der Arduino NANO als Protokollempfänger und Auswertung

Gruss Chregu

[Al. K. (alterknacker)]

Christian M. schrieb:
> Ja ja, Du wolltest aber:
>
> Al. K. schrieb:
>> Jetzt aber der Arduino NANO als Protokollempfänger und Auswertung

Das ist vielleicht erst möglich wenn das Sendeprotokoll vollständig
mit seinen Grenzen verständlich ist.

Es scheint so das ich das ohne Assembler Einbindung nicht hinbekomme.

Wenn ich einen WS2811 und Arduino dranhänge bekomme ich das mit der IDE 
hin, wird eben ein wenig langsamer.

MfG

[chris_ (Gast)]

Eigentlich wollte ich ja was anderes machen ... da ich aber gerade Lust 
zum Basteln habe:

Hier mal die Signale am Ende der NEOPixel-Kette.

/*
 * 
 * Sender for NeoPixel stripe
 * last LED is used as data container (24bit)
 * 
 * 21.11.2021 chris_
 * 
 */
#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
#include <avr/power.h>
#endif

#define PIN            6

#define NUMPIXELS      12

// NUMPIXEL increase by 1 because last pixel is the data transmission message
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS + 1, PIN, NEO_GRB + NEO_KHZ800);


void setup()
{
  pixels.begin();
}


void loop()
{
  static uint8_t ledPos = 0;
  static uint32_t data = 0; // data to be tranmitted after the last pixel (only 24bits available)

  for (int n = 0; n < NUMPIXELS; n++)
  {
    if (ledPos == n)    pixels.setPixelColor(n, pixels.Color(0, 150, 0));
    else                pixels.setPixelColor(n, pixels.Color(0, 0, 0));
  }
  const uint8_t dataPos = NUMPIXELS;

  pixels.setPixelColor(NUMPIXELS, data);
  pixels.show();


  data++; // increase test data transmittet after last LED

  // NeoPixel Lauflicht
  ledPos++;
  if (ledPos >= NUMPIXELS)ledPos = 0;

  delay(20);
}

[c-hater (Gast)]

chris_ schrieb:
> Eigentlich wollte ich ja was anderes machen ... da ich aber gerade Lust
> zum Basteln habe:

[...]

Der Herr bewahre mich vor Ardui...

Wenn du was dazulernen oder kompetent zum Thema dieses Threads beitragen 
willst, dann musst du dir anschauen, was pixels.show() im Detail tut. Da 
tun sich erst die Probleme auf, um die es hier geht.

Das ist garnicht so schwer: der Quelltext liegt auf deiner HD/SSD. Du 
musst ihn dir nur anschauen und verstehen, was da passiert...

[c-hater (Gast)]

Al. K. schrieb:

> Das ist vielleicht erst möglich wenn das Sendeprotokoll vollständig
> mit seinen Grenzen verständlich ist.

Wie Stefan F. korrekt angemerkt hat, gab es dazu im Laufe der Jahre 
diverse Updates der Specs.

Tatsächlich relevant sind aber nur genau zwei Sachen (eigentlich die 
Grenze, die jeweils dazwischen liegt):

T0Hmax vs. T1Hmin
TxLmax vs. Trst

die allerdings gerade nicht in den Specs stehen. Wahrscheinlich war der 
Hersteller hier der Meinung, dass dadurch sein "hochinnovatives" 
intellectual property leaken würde...

> Tatsächlich
>
> Es scheint so das ich das ohne Assembler Einbindung nicht hinbekomme.

Unter Zuhilfenahme von Peripherie ist das auch in C möglich. Senden ist 
deutlich einfacher als Empfangen (immer).

Das würde dann auch das Senden mit konstanter Bitzeit ermöglichen, was 
wiederum die Voraussetzung ist, dass dann auch für den Empfänger auch 
eine Lösung in C möglich wird. Auch hier wieder, indem die Peripherie 
benutzt wird.

Der Trick ist also im Wesentlichen immer, vorhandene Peripherie sinnvoll 
zu benutzen. Das ist allerdings gegen dieses idiotische Arduino-Konzept, 
wo jeder Pin nach Möglichkeit alles können soll...

Sprich: Mit Bitbanging hast du keine Chance, das umzusetzen, was du 
erreichen willst.

[Johannes S. (Gast)]

c-hater schrieb:
> Das ist allerdings gegen dieses idiotische Arduino-Konzept,
> wo jeder Pin nach Möglichkeit alles können soll...

Auch wenn du mit Sicherheit auf deinem hohen Roß begraben wirst, dein 
Bashing kannst du dir echt mal klemmen. Die Leute die Arduino Libs 
programmieren sind nicht alle Vollpfosten und viele Libs sind über die 
Zeit auch durch die Community verbessert worden. Arrogante Einzelkämpfer 
sitzen da heute auf dem absterbenden Ast.

Das einzig richtige war die Anmerkung das die Quellen der Arduino Libs 
frei verfügbar sind. Und wenn man da reinschaut, sieht man das die 
Adafruit Neopixel sehr wohl targetspezifische Implementierungen hat. 
Beim ESP32 wird das RMT verwendet, beim RP2040 die PIO.

[chris_ (Gast)]

Ich habe die Senderoutine noch ein wenig verändert, um die Daten im 
Oszilloscopebild besser separieren zu können.

Auf dem Oszilloscopebild ist der Dateneingang und der Datenausgang des 
12 NeoPixel LED Rings zu sehen.
Interessant dabei ist, dass die Neopixel scheinbar einen Buffer von 2 
Bit haben, da das Signal am Ausgang des letzten Pixels um 2 Bit 
verschoben ist.

/*
 * 
 * Sender for NeoPixel stripe
 * last LED is used as data container (24bit)
 * 
 * 21.11.2021 chris_
 * 
 */
#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
#include <avr/power.h>
#endif

#define PIN            6

#define NUMPIXELS      12

// NUMPIXEL increase by 1 because last pixel is the data transmission message
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS + 1, PIN, NEO_GRB + NEO_KHZ800);


void setup()
{
  pixels.begin();
}


uint32_t TestData[]={0x000000,0x0000FF,0x00FF00,0xFF0000};

void loop()
{
  static uint8_t ledPos = 0;
  static uint32_t data = 0; // data to be tranmitted after the last pixel (only 24bits available)
  static uint8_t idx=0;

  
  for (int n = 0; n < NUMPIXELS; n++)
  {
    if (ledPos == n)    pixels.setPixelColor(n, pixels.Color(0, 150, 0));
    else                pixels.setPixelColor(n, pixels.Color(0, 0, 0));
  }
  const uint8_t dataPos = NUMPIXELS;

  data=TestData[idx];

  pixels.setPixelColor(NUMPIXELS, data);
  pixels.show();

  idx++;
  if(idx>=sizeof(TestData)/sizeof(uint32_t))idx=0;
  //data++; // increase test data transmittet after last LED

  // NeoPixel Lauflicht
  ledPos++;
  if (ledPos >= NUMPIXELS)ledPos = 0;

  delay(2000);
}

[chris_ (Gast)]

Hier die Empfangsroutine.

/*
 * NeoPixel data receiver
 * 
 * connect the output of a neopixel stripe to D11 of an Arduino Nano
 * 
 * This programm will wait for a high level and than sample the input pin with maximum speed
 * After 256 bytes are sampled, they will printed to the serial output
 * 
 * 21.11.2021 chris_
 * 
*/
// compiler flags changed to O3 ( maximum speed ) line 23-28 in
// ~/tools/Arduino/arduino-1.8.5/hardware/arduino/avr$
// avr-objdump -D -S MCNET_NeoPixelReceiver.ino.elf > dump.txt


// PB3 is D11 on Arduino Nano
#define INPUTPIN (1<<PB3) //
#define PINVALUE (PINB&INPUTPIN)
#define PINLOW (PINVALUE==0)
#define PINHIGH (!PINLOW)

void setup()
{
  Serial.begin(115200);
}

#define BUFFERLENGTH 256 // must be 256
uint8_t Buffer[BUFFERLENGTH];

void recordSignal()
{
  uint8_t n = 0;
  uint8_t *pointer;
  pointer = Buffer;
  cli();
  while (PINLOW); // wait for the pin
  do {
    *pointer = PINB;
    pointer++;
    n++;
  } while (n != 0);
  sei();
}

void loop()
{
  uint8_t n = 0;

  recordSignal();
  do {
    uint8_t bitData = Buffer[n] & (1 << PB3);
    Serial.println(bitData);
    delay(1);        // delay in between reads for stability
    n++;
  } while (n != 0);

  delay(1000);
}

Ich habe den Optimierungslevel in der "platform.txt" auf O3 umgestellt, 
in der Annahme, dass das den schnellsten Code ergibt ( .. stimmt das? ).

Der Objdump ergibt folgendes:

void recordSignal()
{
  uint8_t n = 0;
  uint8_t *pointer;
  pointer = Buffer;
  cli();
 692:  f8 94         cli
  while (PINLOW); // wait for the pin
 694:  1b 9b         sbis  0x03, 3  ; 3
 696:  fe cf         rjmp  .-4        ; 0x694 <main+0x11e>
 698:  ef e1         ldi  r30, 0x1F  ; 31
 69a:  f1 e0         ldi  r31, 0x01  ; 1
  do {
    *pointer = PINB;
 69c:  83 b1         in  r24, 0x03  ; 3
 69e:  81 93         st  Z+, r24
  uint8_t n = 0;
  uint8_t *pointer;
  pointer = Buffer;
  cli();
  while (PINLOW); // wait for the pin
  do {
 6a0:  92 e0         ldi  r25, 0x02  ; 2
 6a2:  ef 31         cpi  r30, 0x1F  ; 31
 6a4:  f9 07         cpc  r31, r25
 6a6:  d1 f7         brne  .-12       ; 0x69c <main+0x126>
    *pointer = PINB;
    pointer++;
    n++;
  } while (n != 0);
  sei();

 6a8:  78 94         sei
}

[c-hater (Gast)]

Johannes S. schrieb:

> Das einzig richtige war die Anmerkung das die Quellen der Arduino Libs
> frei verfügbar sind. Und wenn man da reinschaut, sieht man das die
> Adafruit Neopixel sehr wohl targetspezifische Implementierungen hat.
> Beim ESP32 wird das RMT verwendet, beim RP2040 die PIO.

Es geht aber nunmal in diesem Thread um einen Arduino NANO, sprich: 
AVR8, siehe OT!

Dein dümmliches tendenzielles Geschwalle geht also vollkommen am Problem 
vorbei!

[c-hater (Gast)]

c-hater schrieb:

> Dein dümmliches tendenzielles Geschwalle geht also vollkommen am Problem
> vorbei!

Korrektur: als Sender war wohl auch ein ESP32 zugelassen. Insofern passt 
also deine Aussage doch.

[chris_ (Gast)]

Hier das erste funktionierende Beispiel mit zwei Arduino-Nano.

Es ist zwar ein etwas unaufgeräumter Quick-Hack und ziemlich langsam, 
aber zumindest zeigt es, dass es mit zwei Arduino-Nanos geht.

Die Datenübertragung geht über 12 NeoPixel-LEDs und der Ausgang der 
letzten LED ist an D11 des Empfänger-Arduinos angeschlossen. Die Ausgabe 
erfolgt über den seriellen Port des Arduinos. Das Ergebnis ist im 
Screenshot zu sehen.

[Al. K. (alterknacker)]

Habe den Sender mal getestet.an der überlauf LED sieht man in Weiß die 
Daten "aufblitzen"
Also 4+1 LED.

Muss nur noch den Empfänger anschliessen, testen.
Bin gespannt!?

MfG
alterknacker

[Al. K. (alterknacker)]

Empfänger funktioniert!
Jetzt muss ich mit meinen Sender ein Byte als Überlauf senden welches 
als Datenbyte ausgewertet wird.
..denke ich

[chris_ (Gast)]

>Empfänger funktioniert!

Super :-)

>Jetzt muss ich mit meinen Sender ein Byte als Überlauf senden welches
>als Datenbyte ausgewertet wird.
>..denke ich

Schau mal in der Senderoutine (Zeile 81):

sendByte(Message[counter++]);

Dort kannst Du auch

sendByte(88);
sendByte(123);

oder

sendByte(counter++); // jetzt wird nicht die Nachricht, sondern der Zähler gesendet

oder ähnliches schreiben.

Im Empfänger solltest Du dann aber die Zeile 161 auskommentieren und 
statt dessen die Zeile 160 verwenden, damit die Zahlen und nicht die 
Ascci-Zeichen sichtbar werden:

Zeile 160

Serial.print("==>");Serial.write(ReceivedByte);Serial.print(" - ");Serial.println(ReceivedByte);

[Al. K. (alterknacker)]

Das habe ich soweit schon verstanden.

Es wäre natürlich besser wenn ein "Normaler Sender genutzt werden kann.

Definiere  z.B.13 Leds, habe aber extern nur 12, damit sollen die
3 Farbbyte der Dateninhalt sein.

Mal sehen ob ich meinen ESP32 Testsenden auf dein Protokoll um setzen 
kann.
Setze  im Sender keine Lib ein, alles zu Fuß.

Aufbauend auf den Befehl
digitalWrite(DatOut,HIGH);    116 ns
digitalWrite(DatOut,LOW);     116 ns
Damit kann ich das normale Sendeprotokoll zusammenbasteln


Gibt es noch schnellere reproduzierbare Befehle?

MfG

[Sebastian W. (wangnick)]

Al. K. schrieb:
> Gibt es noch schnellere reproduzierbare Befehle?

http://fastled.io/ bzw. https://github.com/FastLED/FastLED.

LG, Sebastian

[Al. K. (alterknacker)]

Sebastian W. schrieb:
> Al. K. schrieb:
>> Gibt es noch schnellere reproduzierbare Befehle?

Welche vom ESP32 verwendet werden.
Welche Zeit brauch z.B delay(0)

[Sebastian W. (wangnick)]

Al. K. schrieb:
> Welche vom ESP32 verwendet werden.

Hast du 
https://github.com/FastLED/FastLED/blob/master/src/platforms/esp/32/fastspi_esp32.h 
angeschaut?

LG, Sebastian

[Joachim B. (jar)]

Al. K. schrieb:
> Welche Zeit brauch z.B delay(0)

schau auf einen Oszi oder LA, 2 Ports nehmen high low schalten 
nacheinander und dazwischen mit / ohne delay(0);
wobei delay(0) sinnlos ist und eigentlich auch wegoptimiert werden 
könnte.
Was weiss ich was der Compiler daraus macht.

Ich war  ja fast bereit den ESP32 anzuwerfen samt Arduino IDE.
Manches solltest du aber selber schaffen so weit wie du schon gekommen 
bist.

[Johannes S. (Gast)]

Al. K. schrieb:
> Setze  im Sender keine Lib ein, alles zu Fuß.
>
> Aufbauend auf den Befehl
> digitalWrite(DatOut,HIGH);    116 ns

kann man so machen, dann ist es halt Sch*ße. Wurde doch schon 
geschrieben das Bitganging viel schlechter ist als vorhandene hardware 
devices zu nutzen. Und das machen die ESP Libs, auch wenn es hier von 
verschiedenen immer wieder schlechtgeredet wird.

Al. K. schrieb:
> Gibt es noch schnellere reproduzierbare Befehle?

das sind keine Befehle, sondern Funktionen die aufgerufen werden. 
'Arduino Befehle' gibt es sowieso nicht.

Al. K. schrieb:
> Welche Zeit brauch z.B delay(0)

Muss man nicht messen, die Arbeit kann man sich sparen weil diese 
Funktion denkbar ungeeignet ist. Das delay(n) ruft vTaskDelay auf und 
wartet n ms. Da die ESP Arduino Implementierung das FreeRTOS als Basis 
nutzt hat man da also den Overhead des RTOS am Hals. delay(0) ist dazu 
noch ein Sonderfall der den Scheduler aufruft und dann in einem 
taskYield() endet, das macht man also nur um Rechenzeit an andere 
wartende Task gleicher Priorität abzugeben.

Das die WS Lib mit Hardwarhilfe arbeitet hat noch einen Grund: das Wifi 
im ESP verlangt strenges Timing und hat eine höhere Prio als deine 
Applikation. Also kann es dein Bitbanging beliebig durcheinanderhauen. 
Und wenn man kein Wifi benötigt ist der ESP einfach mit Kanonen auf 
Spatzen.

Selbst ein delayMicroseconds() hat nur Mikrosekunden Auflösung und 
eignet sich also nicht für 0,1 µs genaues Timing.

Ergo: völlig falscher Ansatz, gehe zurück auf Los.

[Al. K. (alterknacker)]

Joachim B. schrieb:
> schau auf einen Oszi oder LA, 2 Ports nehmen high low schalten
> nacheinander und dazwischen mit / ohne delay(0);
> wobei delay(0) sinnlos ist und eigentlich auch wegoptimiert werden

Laufzeiten von Befehlen zu ermitteln ist mir bekannt.

Es geht nur um den Aufwand.
Vor30/40 Jahren war dies zwingend zu wissen,zu messen oder zu erlesen.

Jetzt Frage ich einfach, da bestimmt auch Andere Leser die hier 
diskutierten Probleme interessieren.
Wer die Lösung parat hat, kann sie nennen. Keiner muss danach suchen.

OsZi habe ich nicht mehr, auch kein Imp,Freque,Perioden Messgerät.

Könnte mir ein Messgerät Programmieren.

Was ist ein LA?

P.S.
Das wenigste was ich teste,suche und bastle ist für mich.



MfG
alterknacker

[Stefan F. (Gast)]

Al. K. schrieb:
> Was ist ein LA?

Logic Analyzer

[c-hater (Gast)]

Al. K. schrieb:

> Was ist ein LA?

Logic analyzer. Sowas wie ein Oszi für digitale Signale.

[Al. K. (alterknacker)]

Johannes S. schrieb:
> Das die WS Lib mit Hardwarhilfe arbeitet hat noch einen Grund: das Wifi
> im ESP verlangt strenges Timing und hat eine höhere Prio als deine
> Applikation. Also kann es dein Bitbanging beliebig durcheinanderhauen.
> Und wenn man kein Wifi benötigt ist der ESP einfach mit Kanonen auf
> Spatzen.

Das ist bekannt und wurde schon mehrfach geschrieben.

Das Delay(0) war ein ersichtliches Beispiel.

Für mich war es ein Versuch zu Fuß mit dem ESP32 die WS anzusteuern.
Ist aber nicht Lebenswichtig.

Ich wollte auch nur erfragen ob es ein Befehl mit Kleinerer Laufzeit wie
0,116 yS  gibt.. wenn ja, kann man genauere Protokolle basteln.

altekinacker

[Al. K. (alterknacker)]

c-hater schrieb:
> Logic analyzer. Sowas wie ein Oszi für digitale Signale.

Schön, das ich dies jetzt richtig erklärt bekomme ;-))

Habe ich auch nicht.
..und selbst basteln ist wegen der begrenzten Lebenszeit nicht mehr 
drin.

[Johannes S. (Gast)]

Es gibt nur Maschinenbefehle in Assembler.
Als Dummy nimmt man da NOP, das ist hier per #define verfügbar und kann 
mit NOP() im Code verwendet werden.
Mit den immer noch bestehenden Nachteilen das es kein sicheres Timing 
auf einem Multicore mit RTOS ermöglicht.
Und das Bitbanging per Code ist abhängig vom CPU Takt und wenn es im 
Flash ausgeführt wird, dann noch von der Flash Latency. Also alles 
maximal ungünstig.

[Stefan F. (Gast)]

Al. K. schrieb:
> Habe ich auch nicht.
> ..und selbst basteln ist wegen der begrenzten Lebenszeit nicht mehr
> drin.

Die Dinger bekommt man als Fertig Gerät ab 8 Euro bei Amazon, und noch 
billiger bei Aliexpress. 
https://www.amazon.de/iHaospace-Channel-Analyzer-Support-support/dp/B071LFZRTZ

[Joachim B. (jar)]

Al. K. schrieb:
> ..und selbst basteln ist wegen der begrenzten Lebenszeit nicht mehr
> drin.

aber auf Antwort im Forum warten?
In der Zeit hättest du längst messen können!
Sogar ich hatte mir dies Jahr noch ein Rigol 5104 zugelegt, ich glaube 
zwar nicht das ich es noch viel nutze, aber man weiss ja nie.

Al. K. schrieb:
> Wer die Lösung parat hat, kann sie nennen.

und nun wie lange in µs dauert denn nun

Al. K. schrieb:
> Welche Zeit brauch z.B delay(0)

wo ist die Antwort?

[Al. K. (alterknacker)]

Stefan ⛄ F. schrieb:
> Die Dinger bekommt man als Fertig Gerät ab 8 Euro bei Amazon, und noch
> billiger bei Aliexpress.
> https://www.amazon.de/iHaospace-Channel-Analyzer-Support-support/dp/B071LFZRTZ

Werde mir mal so was zulegen, leider bei dem benannten Teil keine
richtige Beschreibung.

Bissel was zum Messen ist nicht unwichtig.


MfG

[Walter T. (nicolas)]

Was ist denn jetzt eigentlich der Zweck der Aktion? Die Anzahl der 
angeschlossenen LEDs zählen?

[Al. K. (alterknacker)]

Joachim B. schrieb:
> wo ist die Antwort?

Ich kenne Sie nicht!

Walter T. schrieb:
> Was ist denn jetzt eigentlich der Zweck der Aktion? Die Anzahl der
> angeschlossenen LEDs zählen?
Es werden keine Leds gezählt, die Anzahl muss nur bekannt sein.

[Stefan F. (Gast)]

Al. K. schrieb:
> Werde mir mal so was zulegen, leider bei dem benannten Teil keine
> richtige Beschreibung.

Die erkennt man am Bild, werden unter gefühlt 100 Namen verkauft. Da ist 
immer das gleiche drin. Im Grunde nur ein Mikrocontroller, ein 
Bustreiber 74LVC245 oder 74HC245, und eine primitive Schutzschaltung für 
die 8 Eingänge. Ich benutze dazu das Programm PulseView.

Weiss jemand wozu der Bustreiber gut ist? Warum hängen die Eingänge 
nicht direkt am Mikrocontroller?

[Al. K. (alterknacker)]

Stefan ⛄ F. schrieb:
> Weiss jemand wozu der Bustreiber gut ist? Warum hängen die Eingänge
> nicht direkt am Mikrocontroller?

Triggereingänge?
Überlastfähiger?

[Stefan F. (Gast)]

Al. K. schrieb:
> Triggereingänge?
> Überlastfähiger?

Das Ding hat keine Hardware Trigger.
Die Eingänge des µC sind bereits 5V tolerant.

[Al. K. (alterknacker)]

https://www.mikrocontroller.net/attachment/536774/c_la_pcb_front.jpg

Was macht  PWR ?

[Christian M. (christian_m280)]

Leuchten bei Power, vielleicht...?!

Gruss Chregu