Hallo zusammen,
ich stehe mittlerweile in mehreren Anwendungen vor dem Problem, zu
verschiedenen Zeitpunkten verschiedene Aufgaben zu erledigen.
Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen
werden.
Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs
betragen.
Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den
anderen gleichzeitig ändern.
(Ein Beispiel wäre zum Beispiel ein dreiphasiger Dimmer mit mehreren
Kanälen.)
Es wäre nett, wenn Ihr mir etwas weiterhelfen könntet...
Was ich bislang betrachtet habe:
"soft FM"
In einer Timer-ISR hoher Frequenz werden mehrere Zählvariablen
dekrementiert. Bei Null wird die Aktion ausgeführt und der nächste
Zeitpunkt geladen. Nachteil: hohe CPU-Belastung, schlechte Genauigkeit
der Zeitpunkte (der genaue Wert muss auf die ISR-Frequenz "quantisiert"
werden...).
"Zeitpunkte sortieren und jeweils nächsten in das Compare-Register
laden"
Im Hintergrund wird jeder neue Zeitpunkt einsortiert oder jedes Mal das
komplette Array durchsortiert (worst case Betrachtung entscheidet). Nach
dem Update wird der Pointer für die ISR auf das neu sortierte Array
gesetzt. Nachteil: Wenn ich zu dem aktuellen Timerwert die
Verzögerungszeit addiere und es zum Überlauf kommt, arbeitet die
Sortierung falsch. (Der Timer steht aktuell auf 0xFF00 und ich möchte in
0x10F Ticks etwas tun, so wird 0x10 vor z.B. 0xFF10 einsortiert, was
aber zuerst erreicht wird...)
"verlinkte Liste"
Ich halte dies derzeit für eine elegantere Variante der eben genannten
Sortierung. Ich befürchte allerdings dasselbe Problem mit Überläufen...
Es ist allerdings gut möglich, dass ich bei dem Bilden der Offsets zu
vorigen Zeitpunkten einen Denkfehler mache.
Viele Grüße,
Hendrik
Klingt interessant, aber was passiert beim nächsten Softwareupdate?
Verschiebt sich alles, reichen die Zeiten noch?
Meine innerste Stimme sagt: Ein Atomkraftwerk würde ich damit nicht
steuern wollen, höchstens eine Puppenstube. Jedenfalls würde ich noch
irgendeine Plausibilitätsprüfung am Ende einbauen, um zu erkennen wenn
das System hängt.
@oszi: häh?
Der Zeitdauer eines Delays wird bei >100µs liegen. Von daher bleibt
etwas Zeit zum Rechnen.
Ansonsten würde 30kW nicht in eine Puppenstube einbauen.
Als Scheduler misbraucht, möchte ich einen Einsatz in "interessanteren"
Steuerungen auch nicht ausschließen.
=====
Nach dem ich den Post tippte, fiel mir auf, dass das Arbeiten mit
Offsets evtl. doch funktionieren könnte, da ich niemals den absoluten
Timerstand beim Auslösen vor der Sortierung bilden muss -> keine
Überläufe, keine Fehlsortierung...
>Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen>werden.>Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs>betragen.
Wenns im us Bereich sein muss würde ich das ganze gleich sein lassen.
Beispiele (Befehle mit mehreren Takten mal vernachlässigt):
ATMega mit 4MHz 250ns pro Befehl 4 Befehle pro us
ATMega mit 16MHz 62.5ns pro Befehl 16 Befehle pro us
So, nun rechnest du mal aus wieviele Befehle du zwischen
deinen Zeitpunkten zur Verfügung hast und schätzt dann
mal ab ob das überhaupt geht.
>(Ein Beispiel wäre zum Beispiel ein dreiphasiger Dimmer mit mehreren>Kanälen.)
Da reichen sicherlich auch ms.
@ Henne (Gast)
>Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen>werden.>Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs>betragen.>Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den>anderen gleichzeitig ändern.
Tja, das kann mn wohl auf gängigen Mikrocontrollern vergessen, wie dummy
richtig bemerkte. Das braucht echte Hardware, entweder als FPGA/CPLD
oder Timermodul. Der 683xx hat sowas glaub ich, nennt sich TPU, Time
Processing Unit.
MFG
Falk
@Falk, dummy:
Bei 50Hz beträgt die Dauer einer Halbwelle 10ms. Bei 255
Werten/Halbwelle und entsprechenden Korrekturtabellen ist man bei <40µs.
Arbeitet man mit mehreren Phasen wird es noch einmal enger...
Derzeit habe ich noch Hoffnung, da ich die Zündzeitpunkte kurz nach dem
Nulldurchgang kenne und bis zum ersten Anschnitt gut 200µs Zeit habe.
Derzeit werkelt auch schon ein 3p-Dimmer von mir nach dem zweiten
Prinzip (Sortierung). Der Nachteil war nur, dass ich mit festen
Phasenverschiebungen rechnete und alle Zündzeiten auf eine Halbwelle
runterrechnete. (So umging ich das Überlaufproblem ;-)
Einige Leute haben aber nun das Problem, dass bei extremen Belastungen
die Phasenveschiebungen variieren und somit Scheinwerfer an den
"Slavephasen" flackern, da die Nulldurchgänge nicht mehr exakt getroffen
werden.
http://www.hoelscher-hi.de/hendrik/light/dmxdimmii.htm
Ich hatte nun die Hoffnung, dass ein Forum voller Experten intelligenter
ist, als ein einzelner Maschi...
Viele Grüße,
Hendrik
@ Henne (Gast)
>Werten/Halbwelle und entsprechenden Korrekturtabellen ist man bei <40µs.>Arbeitet man mit mehreren Phasen wird es noch einmal enger...
Kann man lösen, siehe Soft-PWM.
Das ist aber MEILENWEIT von dem Problem entfernt, welches du nebulös
skizziert hast.
>Diese Zeitpunkte (16bit) müssten recht genau (wenige µs) getroffen>werden.>Der Zeitraum zwischen zwei Zeitpunkten kann ebenfalls nur wenige µs>betragen.>Es können sich einzelne oder mehrere Zeitpunkte unabhängig von den>anderen gleichzeitig ändern.>Einige Leute haben aber nun das Problem, dass bei extremen Belastungen>die Phasenveschiebungen variieren und somit Scheinwerfer an den>"Slavephasen" flackern, da die Nulldurchgänge nicht mehr exakt getroffen>werden.
Naja, dann braucht man halt für jede Phase eine Nulldurchgangserkennung.
Entweder clever über den einen ICP, denn die Phasen sind ja auf jeden
Fall ~120 Grad zueinander versetzt, oder über drei kleine 8-Pin AVRs,
die einzeln die Phasen steuern, die können ja an einem DMX- Receiver
hängen.
>Ich hatte nun die Hoffnung, dass ein Forum voller Experten intelligenter>ist, als ein einzelner Maschi...
Woraum du einen lassen kannst, selbst wenn es der beste Maschi der Welt
wäre . . .
MFG
Falk
@Falk:
Stimmt - die dritte Variante mit der Sortierung könnte funktionieren, da
auch mit Offsets gearbeitet wird. Da hatte ich mich damals verguckt und
absolute Werte in Erinnerung. Danke!
Die Annahme einer konstanten Phasenverschiebung von 120° scheint nicht
immer zuzutreffen*, da einige Leute bei starken Lastwechseln oder an
Dieselaggregaten Probleme hatten. (Ich konnte es leider nicht
verifizieren und es scheint auch nur bei Wenigen aufzutreten.)
Die nebulöse Umschreibung kam daher, dass die Geschichte wohl auch bei
anderen Aufgaben (einen Haufen Stepper, LEDs,...) nützlich sein könnte
und der Dimmer nur das Nächstliegende war ;-)
Der Ansatz einen Stapel Slave-AVRs einzusetzen ist zwar gängig - aber
irgendwie auch unsportlich...
Viele Grüße,
Hendrik
*alternativ kann auch kurzfistig die Frequenz schwanken. Das hätte
denselben Effekt, da ich mit zeitlichen Offsets von 120° bei 50Hz
Netzfrequenz rechne.
@ Sebastian B. (mircobolle)
>Ich habe den Thread nur überflogen, konnte aber dein exakten>Randbedingungen nun nicht direkt erfassen.
Dieser Fehler wird gern und häufig gemacht. Nicht gut, wie man mal
wieder sieht.
>Und du benötigst nun einen Scheduler mit Echtzeitanforderungen im us>(Mikrosekunden) Bereich.
Jaja, sonst noch was? Lies mal den Thread in RUHE.
MFg
Falk
@ Henne (Gast)
>Die Annahme einer konstanten Phasenverschiebung von 120° scheint nicht>immer zuzutreffen*, da einige Leute bei starken Lastwechseln oder an>Dieselaggregaten Probleme hatten. (Ich konnte es leider nicht>verifizieren und es scheint auch nur bei Wenigen aufzutreten.)
Nun, das sollte man schon mal abklopfen oder halt ignorieren. Es könnten
auch Probleme bei der Erkennung des Nulldurchgangs sein. Denn so dolle
ist die 0815 Optokopplerschaltung nicht.
>Der Ansatz einen Stapel Slave-AVRs einzusetzen ist zwar gängig - aber>irgendwie auch unsportlich...
Warum einfach, wenns auch umständlich geht ;-)
>*alternativ kann auch kurzfistig die Frequenz schwanken.
Das glaub ich kaum. Ausserdem muss der Dimmer sowieso JEDE Vollwelle neu
synchronisieren. In dieser Zeit läuft die Phase keinesfall um mehr als
ein paar us weg.
MFg
Falk
@Sebastian:
Es sind drei Phasen. Aber nach Deinem Post entspräche ein Kanal einem
Prozess. Rechne mit 3..12 Kanälen.
Jeder Prozess würde 100Mal/s einen Triac zünden. Allerdings ist die
Phasenverschiebung der einzelnen Prozesse zueinander variabel und
abhängig von Nulldurchgang und gewünschter Helligkeit.
Das ist aber eine sehr verdrehte Beschreibung des Ablaufes...
Ich denke, dass ich mit der 3.Soft-PWM meinen Ansatz gefunden habe.
Viele Grüße,
Hendrik
@Falk:
Es wird jede Vollwelle synchronisiert.
Ich spiele blos mit dem Gedanken, die Periodendauer zu messen und
darüber Phasenverschiebungen und Zündwinkel permanent nachzujustieren.
@Sebastian:
Prinzipiell hat Falk Recht, wie Du beim Überfliegen feststellen wirst.
Die Lösung wird wohl auch ein Hybrid aus einem Scheduler und der
Soft-PWM sein.
Es lohnt sich nicht, sich wegen sowas in die Haare zu kriegen...
@ Henne (Gast)
>Ich spiele blos mit dem Gedanken, die Periodendauer zu messen und>darüber Phasenverschiebungen und Zündwinkel permanent nachzujustieren.
Wozu? Die Netzfrequenz schankt nur im Promillebereich, das kann man in
den Skat drücken. Und wenn jemand an nen 1kW Generator 2KW Lampen hängt
und damit die Frequenz jenseits von Gut und Böse liegt ist das einfach
Pech.
MFG
Falk
@Falk:
Na ja - gegen Ende meiner Schulzeit hatten wir mal eine größere Feier in
einem Gewächshaus, das über zwei Gasturbinen versorgt wurde.
Man konnte hören, wie die Drehzahlen passend zu den Bässen der PA
schwankten und die Spannungen um >20V einbrachen. Ich befürchte, dass
Generatoren grundsätzlich mit der Nennleistung klarkommen aber mit
Lastwechseln Probleme haben.
Die Frequenzabweichungen im normalen Netz werde ich mir mal morgen auf
ein LCD ausgeben lassen. Ich habe sie kurzzeitig als deutlich größer in
Erinnerung.
Die Frequenzabweichungen im "normalen Netz" sehe ich nicht so groß, eher
fallen auf dem Oszi die versauten Sinuswellen durch Schaltnetzteile,
Tyristoren usw. auf. Wenn diese verkrüppelten Sinuswellen dann
ausgewertet werden, könnten schon merkliche Differenzen auftreten zum
Idealfall!
Och, da gibt es noch viel schönere Sachen.
Ich habe derzeit Standard-Dimmer am Laufen (Bausatz von Conrad), die
immer zu gewissen Zeiten flackern, aber nicht wenig. Man hat manchmal
den Eindruck, dass nicht nur eine Halbwelle fehlt, so extrem ist das.
Richtig extrem wird es gegen 22:00 Uhr, danach ist wieder Ruhe. Meine
Vermutung sind Rundsteuersendungen, allerdings blieb meine Anfrage beim
örtlichen Energieversorger ohne Erfolg... Deshalb hatte ich irgendwann
(wenn ich mal Zeit habe, also nie fg) mal vor, einen Dimmer mit einem
AVR zu basteln, der derartige Störungen rausrechnet
(plausibilitätskontrolle des Nulldurchgangs, Fehlerkorrektur durch
Berechnung des Zündpunkts aus den vorhergehenden)
