Application.ProcessMessages oder TThread

[Maik81SE]

Moin @ll,

Was ist eure Meinung?

Hintergrund?
Ich baue mir gerade eine Kommunikation (PC/PI4 <-> MCU) mit Permanenten Austausch auf.
Da mir ein Timer mit 1ms zu langsam ist brauch ich eine andere Methode um die Daten für bis zu 12 mal 500 WS2812W zu senden. (MCU läuft mit 8MHz)

Zugegeben sind beide Themen der Prozessverwaltung Neuland für ich und ich würde erst mal eure Erfahrungen in diesem Zusammenhang Sammeln wollen.TThread)

Mein Ziel in diesem Kontext soll sein das Wenn die Daten bereit sind alle gesendet werden, OHNE den MCU zu überlassten bzw Daten zu verlieren.

Alternativ wäre mir geholfen wenn ich mit einer Ähnuchen funktion (USB.Recvstring(1)) arbeiten könnte.

Sprich.
Datenpaket 1 zu MCU --> ca 1µS warten --> Datenpaket 2 zu MCU --> Letztes Datenpaket senden.

[af0815]

Redest du von PC/RPi4 oder MCU?

PC nimm einen Thread.

[kupferstecher]

Da mir ein Timer mit 1ms zu langsam ist brauch ich eine andere Methode um die Daten für bis zu 12 mal 500 WS2812W zu senden. (MCU läuft mit 8MHz)

Ein Thread ist auch nicht "schneller" wie die 1ms (auf Win eher 10ms). Das Betriebssystem kann die Abarbeitung nämlich jederzeit unterbrechen und dann ist für mindestens die 1 bzw. 10ms der Thread pausiert.

Die MCU ist ein Atmega328P? Da wird es vor dem Hintergrund der blockierenden WS2812W-Ansteuerung m.E. schon sehr schwierig eine direkte Kommunikation mit akzeptablen Datenraten zum PC zu unterhalten. Wie viel Zeit kannst du denn zwischen Zwei Ansteuerungen zur Datenübertragung pausieren?

[Maik81SE]

Redest du von PC/RPi4 oder MCU?

PC nimm einen Thread.

PC/PI4 zu MCU und umgedreht

Ein Thread ist auch nicht "schneller" wie die 1ms (auf Win eher 10ms). Das Betriebssystem kann die Abarbeitung nämlich jederzeit unterbrechen und dann ist für mindestens die 1 bzw. 10ms der Thread pausiert.

Autsch...
Das bescheiden...
ich Plane ja noch einen MCU mit einem Micro und da wird das Timing noch Kritischer...

Die MCU ist ein Atmega328P? Da wird es vor dem Hintergrund der blockierenden WS2812W-Ansteuerung m.E. schon sehr schwierig eine direkte Kommunikation mit akzeptablen Datenraten zum PC zu unterhalten. Wie viel Zeit kannst du denn zwischen Zwei Ansteuerungen zur Datenübertragung pausieren?

Für das Masterband verwende ich einen ATMega328p.
Für meine 4 Slavebänder will ich einen ATTinyx5 verwenden.

Die Zeit zw den Ansteuerungen sollte so Kurz wie möglich sein...
Richtet sich aber am ende genau an die Blockierung der WS Steuerung...
also max 10 bis 30 µS Pause sollten drin sein, richtet sich aber am ende nach dem Lied, welches aktuell läuft...

Genre: NDH, Metal, Gothic, EBM, Techno und co sind abzudecken.

[af0815]

Unter einem normales BS wie Linux oder Win bekommst du maximal eine 'weiche' Echtzeit. Daher ist es nicht deterministisch wann was verschickt wird. Dazu gibt es Realtime Extensions.

[kupferstecher]

Die Zeit zw den Ansteuerungen sollte so Kurz wie möglich sein...
Richtet sich aber am ende genau an die Blockierung der WS Steuerung...
also max 10 bis 30 µS Pause sollten drin sein, richtet sich aber am ende nach dem Lied, welches aktuell läuft...

Genre: NDH, Metal, Gothic, EBM, Techno und co sind abzudecken.

Man sollte erstmal die anfallenden Datenmengen ausrechnen und wie lange die Ansteuerung der WS2812W überhaupt braucht.

Ich nehm mal die parallele Ausgabe an, also 500 Pixel mal 24 bit = 12000bit. Eine Periode braucht 1,25µs, ein "Refresh" also 15ms. Richtig?

Die 12 Stränge müssen auf 2 Byte aufgeteilt werden, also braucht es für einen Refresh 12k*2 Byte Daten.

Nehmen wir die von dir genannten 30ms Übertragungszeit, das ergäbe eine Bildwiderholrate von 1/(30ms+15ms) = 22Hz. Außerdem eine Datenrate von 24kB/30ms = 800kB/s = 6,4Mb/s. Mit 8MHz SPI (bei 16MHz CPU-Takt), wird man das ohne DMA nicht schaffen.

Wenn ich mich nicht verrechnet habe

[Warf]

Wenn ich dich richtig verstehe ist dein Problem das folgende, du generierst Daten auf dem PC, und der soll diese dann an die MCU senden, das problem ist das der PC diese Daten in (großen) Bursts erstellt, und wenn diese direkt versucht würden in solchen bursts zu senden würde die MCU nich nachkommen. Du bist natürlich nicht der erste der dieses Problem hat, im Computer Networking ist das ein ziemlich bekanntes Problem, das nennt man traffic shaping. Und die entsprechende Lösung zu deinem Problem ist ein Algorithmus names "Leaky Bucket" (es hilft denke ich immer zu nächst einmal zu wissen wie das Problem überhaupt heist).
Der Algorithmus funktioniert in etwa so, du hast einen großen Buffer, der wird dann in den Bursts gefüllt, und auf einem timer wird dieser regelmäßig entzladen, somit wird aus burst traffic ein stetiger Strom an daten, sodass möglichst wenige daten verloren gehen (natürlich wenn mehr burst reinkommt als der Buffer groß ist, sind die Daten auch weg).
Die Frage ist also wie du diesen stetigen Sendemechanismus bauen kannst. Router im internet machen das über dedizierzte Hardware.

Ein "normales" betriebsystem wie Windows oder Linux ist nicht Echtzeitfähig, da kannst du keine Zeitgarantien bekommen. Wenn der OS scheduler entscheidet das dein Prozess genug Zeit auf der CPU verbracht hat, und andere Prozesse warten, kann der einfach den Prozess runter nehmen ob du willst oder nicht.
Das gesagt, das OS versucht natürlich trozdem prozesse so wenig wie möglich zu reschedulen, wenn deine CPU also nicht ausgelastet ist, sodass du immer ein paar kerne frei hast, werden Langläufige Prozesse eine CPU bekommen und da sehr wahrscheinlich nicht runtergeschmissen werden. Das heist du kannst mit busy waiting und hoffen das der Scheduler dich nicht runter wirft es zumindest mal versuchen.
Das heist TThread mit Spinlocks (also locking mechanismen die nicht den Prozess schlafen legen) auf einer Maschiene mit wenig auslastung und vielen CPUs kann funktionieren.

Garantien hast du bei einem nicht Echtzeitfähigen Betriebsystem aber nicht. Was du aber noch machen köntest, wäre das ganze auf OS-Level zu bauen, wie Treiber das machen. Du kannst in Linux relativ einfach ein eigenes Kernel modul bauen, wo du mittels timer, Work queue oder Tasklet dann den Leaky bucket implementieren könntest. Dafür stellst du dann einen Buffer in den Userspace bereit stellt, in den deine Anwendung Daten schreiben kann, was dann durch einen regelmäßigen code (Timer oder Tasklet auf Hardwar timer basis)
Vor einigen Jahren hab ich so etwas mal in der Uni als Teil des Network Engineering kurses gebaut, und auch wenn ich keine Spezifika mehr weiß, war er allgemein gar nicht so schwer.
Ich habe grade nochmal in den Unterlagen nachgeschaut, und ein simples kernel modul ist einfach:

Code: Alles auswählen

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>

MODULE_AUTHOR("AUTHOR");
MODULE_LICENSE("GPL");

int init_module_function(void) {
  // Initialize timer/tasklet
  // Initialize Buffer, map into user space
  return 0;
}

void cleanup_module_function(void) {
  // Cleanup time/tasklet
}

module_init(init_module_function);
module_exit(cleanup_module_function);

Was du dann mit

Code: Alles auswählen

make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

bauen und mit rmmod laden kannst. Ist also im Grunde kein Hexenwerk. Der Linux Kernel ist vor allem hervorragend Dokumentiert und man findet extrem viele Resourcen im Internet. Zum Thema Timers und Tasklets habe ich z.B. auf die schnelle das gefunden: https://linux-kernel-labs.github.io/ref ... _work.html

Alternativ dazu könntest du auch ein zweites System zwischen den PC und die MCU hängen, welches dediziert für diese Aufgabe ausgelegt ist. Das könnte z.B. eine größere MCU sein, welche schnell genug taktet um über einen schnellen Kanal mit dem PC zu kommunizieren und genug buffer hat um den Leaky Bucket für die Langsame Verbindung mit der kleinen MCU zu übernehmen. Also praktisch dedizierte Hardware für dein Problem.
Alternativ kannst du natürlich auch einen weiteren PC dran hängen, mit einem Echtzeitsystem (RTOS). Z.B. könntest du dafür einen Raspi nehmen. Allerdings habe ich noch nie für ein RTOS programmiert und kann nicht sagen was das für ein Aufwand wäre

[theo]

@Warf: Kann man das Verhalten nicht auch mit nice oder chrt beeinflussen?
Wie z.B. hier angedeutet: https://unix.stackexchange.com/question ... g-in-linux

[Warf]

Linux (und auch Windows) haben keine echte Echtzeitunterstützung, also garantien das wenn du dein Programm startest es sagt wie viele Zeitslots es braucht, und die werden dann auch garantiert, sondern die Echtzeitprozesse in Linux, welche man mit chrt konfigurieren/steuern kann, haben einfach eine sehr hohe Priorität, und die (im Gegensatz zum standard Round Robin scheduling nicht reduziert wird). D.H. solang kein anderer RT Prozess mit höherer Priorität da ist, wird dein Prozess nicht runter geworfen, außer, für Kernel Prozesse.

Das kann die wahrscheinlichkeit enorm erhöhen, das dein Prozess durchläuft, grade auf einem Multi CPU system auf dem dein RT Prozess praktisch seine CPU für sich allein hat und selbst wenn es noch andere RT Prozesse gibt, die ihre eigene CPU haben (was man auch über CPU Pinning so einstellen kann, das ein Prozess nur auf einer CPU läuft). Das gesagt, der Kernel und damit Kernel Module und Treiber haben immer vorrang, und wenn du einen Treiber installiert hast der sich einfach über alle CPUs verteilt (gewollt oder ungewollt), dann wird der deinen Prozess zwangsläufig irgendwann runter werfen, und dann hast du eine downtime, selbst wenn der Kernel prozess fast nichts macht, gehen da mehrere MS drauf.

Aber ich glaube einen Versuch ist das auf jeden Fall mal wert, die chance das dein Prozess im Falschen moment runter geworfen wird existiert zwar immer, aber damit ist sie auf einem Multiprozessor system doch recht gering zu halten. Das gesagt, kommt natürlich auch an die Anforderungen an, wie Fehlertolerant das ganze sein soll. Bei einem Herzschritmacher würde ich kein Risiko eingehen wollen das der nicht rechtzeitig tickt

[theo]

Danke, so hatte ich das auch verstanden und gemeint, dass es die Wahrscheinlichkeit des "Durchlaufens" verbessern kann.
Vielleicht noch interessant dazu "man sched"
https://www.man7.org/linux/man-pages/man7/sched.7.html

[af0815]

Vor allen stellt sich Frage, was hat es für eine Auswirkung wenn eine Kommunikation nicht funktioniert.
Sollen die LED Reihen einen Bildschirm simulieren oder nur eine Art Dekobeleuchtung. Was auch zu hinterfragen ist, ob die Umsetzung Musik zu LED nicht besser auf einem schnellen MCU aufgehoben ist und der PC da dümmer gemacht wird.

[Maik81SE]

Die Zeit zw den Ansteuerungen sollte so Kurz wie möglich sein...
Richtet sich aber am ende genau an die Blockierung der WS Steuerung...
also max 10 bis 30 µS Pause sollten drin sein, richtet sich aber am ende nach dem Lied, welches aktuell läuft...

Genre: NDH, Metal, Gothic, EBM, Techno und co sind abzudecken.

Man sollte erstmal die anfallenden Datenmengen ausrechnen und wie lange die Ansteuerung der WS2812W überhaupt braucht.

Ich nehm mal die parallele Ausgabe an, also 500 Pixel mal 24 bit = 12000bit. Eine Periode braucht 1,25µs, ein "Refresh" also 15ms. Richtig?

Die 12 Stränge müssen auf 2 Byte aufgeteilt werden, also braucht es für einen Refresh 12k*2 Byte Daten.

Nehmen wir die von dir genannten 30ms Übertragungszeit, das ergäbe eine Bildwiderholrate von 1/(30ms+15ms) = 22Hz. Außerdem eine Datenrate von 24kB/30ms = 800kB/s = 6,4Mb/s. Mit 8MHz SPI (bei 16MHz CPU-Takt), wird man das ohne DMA nicht schaffen.

Wenn ich mich nicht verrechnet habe

Die Daten werden Noch Seriell auf die 2 Ports a 6 bit ausgegeben.
Wo ich aber mit Sicherheit noch ein paar ns gewinnen kann, den Takt auf 16 MHz hochzuschrauben, sodas die zeit zw Datenempfang und setzten der LED's kleiner wird.

Da die Daten für eine WS2812b 16 Byte betragen, lieg ich bei Sumar Sumaro 94Kbyte welche im Ungünstigsten fall vom PC zum MCU übertragen werden müßen.
und genau da liegt das eigentliche Problem.
Im schlimmsten Fall muß ein Colorflash alle LEDs kommen und 10ms Später der nächste Colorflash (neue Farbe) zum schieben bereitstehen.

Alternative MCU mit USB2 Unterstützgung oder Handshake müßen mit einem AT90USB
als Master und diesen dann auf weitere MCU's via SPI/RS485-UART verteilen. bzw Weitere Hardware einlesen.

Vor allen stellt sich Frage, was hat es für eine Auswirkung wenn eine Kommunikation nicht funktioniert.
Sollen die LED Reihen einen Bildschirm simulieren oder nur eine Art Dekobeleuchtung. Was auch zu hinterfragen ist, ob die Umsetzung Musik zu LED nicht besser auf einem schnellen MCU aufgehoben ist und der PC da dümmer gemacht wird.

Im übertragenen Beispiel eher Effekt-Deko.

Wäre ggf auch ein ARM ins Auge zu fassen?
Da bräuchte ich mal von dir eine Empfehlung, welcher Programmer (2x5 Pin) zu empfehlen ist.

[Maik81SE]

Wenn ich dich richtig verstehe ist dein Problem das folgende, du generierst Daten auf dem PC, und der soll diese dann an die MCU senden, das problem ist das der PC diese Daten in (großen) Bursts erstellt, und wenn diese direkt versucht würden in solchen bursts zu senden würde die MCU nich nachkommen. Du bist natürlich nicht der erste der dieses Problem hat, im Computer Networking ist das ein ziemlich bekanntes Problem, das nennt man traffic shaping. Und die entsprechende Lösung zu deinem Problem ist ein Algorithmus names "Leaky Bucket" (es hilft denke ich immer zu nächst einmal zu wissen wie das Problem überhaupt heist).
Der Algorithmus funktioniert in etwa so, du hast einen großen Buffer, der wird dann in den Bursts gefüllt, und auf einem timer wird dieser regelmäßig entzladen, somit wird aus burst traffic ein stetiger Strom an daten, sodass möglichst wenige daten verloren gehen (natürlich wenn mehr burst reinkommt als der Buffer groß ist, sind die Daten auch weg).
Die Frage ist also wie du diesen stetigen Sendemechanismus bauen kannst. Router im internet machen das über dedizierzte Hardware.

Ein "normales" betriebsystem wie Windows oder Linux ist nicht Echtzeitfähig, da kannst du keine Zeitgarantien bekommen. Wenn der OS scheduler entscheidet das dein Prozess genug Zeit auf der CPU verbracht hat, und andere Prozesse warten, kann der einfach den Prozess runter nehmen ob du willst oder nicht.
Das gesagt, das OS versucht natürlich trozdem prozesse so wenig wie möglich zu reschedulen, wenn deine CPU also nicht ausgelastet ist, sodass du immer ein paar kerne frei hast, werden Langläufige Prozesse eine CPU bekommen und da sehr wahrscheinlich nicht runtergeschmissen werden. Das heist du kannst mit busy waiting und hoffen das der Scheduler dich nicht runter wirft es zumindest mal versuchen.
Das heist TThread mit Spinlocks (also locking mechanismen die nicht den Prozess schlafen legen) auf einer Maschiene mit wenig auslastung und vielen CPUs kann funktionieren.

Garantien hast du bei einem nicht Echtzeitfähigen Betriebsystem aber nicht. Was du aber noch machen köntest, wäre das ganze auf OS-Level zu bauen, wie Treiber das machen. Du kannst in Linux relativ einfach ein eigenes Kernel modul bauen, wo du mittels timer, Work queue oder Tasklet dann den Leaky bucket implementieren könntest. Dafür stellst du dann einen Buffer in den Userspace bereit stellt, in den deine Anwendung Daten schreiben kann, was dann durch einen regelmäßigen code (Timer oder Tasklet auf Hardwar timer basis)
Vor einigen Jahren hab ich so etwas mal in der Uni als Teil des Network Engineering kurses gebaut, und auch wenn ich keine Spezifika mehr weiß, war er allgemein gar nicht so schwer.
Ich habe grade nochmal in den Unterlagen nachgeschaut, und ein simples kernel modul ist einfach:

Code: Alles auswählen

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>

MODULE_AUTHOR("AUTHOR");
MODULE_LICENSE("GPL");

int init_module_function(void) {
  // Initialize timer/tasklet
  // Initialize Buffer, map into user space
  return 0;
}

void cleanup_module_function(void) {
  // Cleanup time/tasklet
}

module_init(init_module_function);
module_exit(cleanup_module_function);

Was du dann mit

Code: Alles auswählen

make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

bauen und mit rmmod laden kannst. Ist also im Grunde kein Hexenwerk. Der Linux Kernel ist vor allem hervorragend Dokumentiert und man findet extrem viele Resourcen im Internet. Zum Thema Timers und Tasklets habe ich z.B. auf die schnelle das gefunden: https://linux-kernel-labs.github.io/ref ... _work.html

Alternativ dazu könntest du auch ein zweites System zwischen den PC und die MCU hängen, welches dediziert für diese Aufgabe ausgelegt ist. Das könnte z.B. eine größere MCU sein, welche schnell genug taktet um über einen schnellen Kanal mit dem PC zu kommunizieren und genug buffer hat um den Leaky Bucket für die Langsame Verbindung mit der kleinen MCU zu übernehmen. Also praktisch dedizierte Hardware für dein Problem.
Alternativ kannst du natürlich auch einen weiteren PC dran hängen, mit einem Echtzeitsystem (RTOS). Z.B. könntest du dafür einen Raspi nehmen. Allerdings habe ich noch nie für ein RTOS programmiert und kann nicht sagen was das für ein Aufwand wäre

beim 4ten/5ten/6ten mal lesen sehe ich genau die Probllematik.

'Nen Pi wollt ich dafür nicht verwenden, da auch dieser als Mögliche Datenquelle in Frage kommen muss/darf/soll

Zum Thema Kernel/Treiber...
Der Zusatz muß dann allerdings auf einem Extra EEProm geschrieben werden, damit es sich zB unter windows erst als Laufwerk anmeldet und dann umschaltet wenn die Treiber installiert sind.

Ähnliches auch für Linux, da ich nicht davon ausgehe, das diese wenn es läuft in der Repo aufgenommen werden wenn nur ein oder 2 User dies Nutzen

[Warf]

beim 4ten/5ten/6ten mal lesen sehe ich genau die Probllematik.

'Nen Pi wollt ich dafür nicht verwenden, da auch dieser als Mögliche Datenquelle in Frage kommen muss/darf/soll

Zum Thema Kernel/Treiber...
Der Zusatz muß dann allerdings auf einem Extra EEProm geschrieben werden, damit es sich zB unter windows erst als Laufwerk anmeldet und dann umschaltet wenn die Treiber installiert sind.

Ähnliches auch für Linux, da ich nicht davon ausgehe, das diese wenn es läuft in der Repo aufgenommen werden wenn nur ein oder 2 User dies Nutzen

Also als erstes einmal würde ich empfehlen, es einfach mal ganz dumm zu versuchen, thread starten, an CPU pinnen, Priorität auf Echtzeit/Maximum setzen und hoffen das es klappt. Musst einfach nur aufpassen das wenn du locks verwendest du keine system locks (critical sections, mutex, etc.) verwendest sondern spin locks damit dein prozess nicht von der CPU genommen wird

Die Frage ist was passiert wenn du out of sync kommst, also wenn dein Prozess gerescheduled wird und du musst 1-2 pakete aussetzen. Kann das system damit umgehen oder ist dann alles kaputt. Bzw. kannst du das system so umbaun das wenn was schief geht das system zumindest wieder in einen Stabilen status zurückkehren kann Falls ja wäre das eventuell schon die beste Lösung, so lange machen wie es läuft, und bei nem fehler einfach nen Fehlercode senden und das system zurücksetzen oder so

[Sieben]

Prost!