Rechenzeit und Sollwertvorgabe.

[Leon (Gast)]

Hallo,

Ich habe ein Echtzeitsystem mit 200kS/s Abtastrate. Ich nutze nur einen 
Eingang, könnte also alle 5 Microsekunden einen neuen Wert verarbeiten. 
Jetzt möchte ich die Werte an einen Processor weitergeben, der einen 
Algorithmus berechnet und dann wieder die Werte an den DAU übergeben und 
an den Prozess geben.
Meine Frage ist jetzt: wenn ich ein System habe, dass alle 62,5 
Microsekunden seinen Zustanf ändern kann (Schaltfrequenz) wie oft sollte 
ich dann einen Sollwert ausgeben? Genau mit 16kHz?
Und wie kann ich eine Rechenzeit abschätzen?
Wann bin ich noch Echtzeitfähig?

Hoffe ihr habt es verstanden.
Gruß, Leon

[Dergute W. (derguteweka)]

Moin,

Du wirst dir einen grossen Gefallen tun, wenn du in deiner Anhauefung 
von Systemen moeglichst nur einen einzigen Takt hast, der ueberall exakt 
gleich ist. Also guck', dass dein 200kS/s System irgendwie 
runtergebremst wird auf 16kS/s.
Sonst gibts beim Uebergang von der einen Taktdomaene auf eine andere 
jede Menge unangenehmes Zeugs, was du einfach nicht haben willst.
Zum Abschaetzen der Rechenzeit gibts 2 Ansaetze:
A.) Sehr viel Erfahrung (Wenn man B. schon 1000x auf dem selben 
Prozessor mit der selben toolchain gemacht hat)
B.) Den kompletten Algorithmus mit allen anderen Faxen auf dem 
Zielprozessor implementieren, sich das Assemblerlisting davon angucken 
und per Datenblatt des Prozessors die groesstmoeglichen Zeiten 
bestimmen, die der Algorithmus im worst case braucht. Oder, so man hat, 
das mittels Simulator feststellen.
Sonst gibt's lange Gesichter, wie z.B. hier, wo der Prozessor doch 
ploetzlich laenger braucht, als man gedacht hat...
Beitrag "FIR Filter auf PIC"

Gruss
WK

[Edi M. (Gast)]

Dergute W. schrieb:
> Also guck', dass dein 200kS/s System irgendwie
> runtergebremst wird auf 16kS/s.

Ein System wird nicht besser, wenn es runtergebremst wird, weil dadurch 
die Latenz steigt. Die Sollwertvorgabe muss so schnell wie möglich 
geschehen, idealerweise am Ende des Zyklus, um rasch einen neuen Starten 
zu können.

Wenn der Ausgabezyklus fest auf einer Frequenz ist, könnte man diese 
erhöhen, um Raum für das Hin- und Her der Daten zu schaffen und die 
16kHz zu halten.

Ganz generell brauchst Du mindestens einen Sollwert je Ausgabewert. 
Echtzeitfähig bist Du dann, wenn Du das ohne zusätzliche Verzögerung 
schaffst. Die erhöhte Abtastrate in Deinem Fall nutzt man gerne zu 
Filterung. Am einfachsten mit einem resamling Filter, das die Raten 
übersetzt. Dieses wird einfacher, wenn die Frequenzen ganzzahlig sind.

Du könntest Z.B. auf 20kHz steigern, damit es zu den 200kHz passt, oder 
Du machst den Schreibprozess asynchron, dass er wartet, bis der 
Ausgabeprozess beendet ist und sich damit auf den Ausgang 
synchronisiert. Wichtig ist, dass es eine deterministische 
Zeitverzögerung gibt, die man mit in der Berechnung berücksichtigen 
kann, weil sich die "Welt" ja weiterdreht und man immer hinten dran ist.

Was Weka im Bezug auf das Ausgucken von Assembler und dessen timing 
vorschlägt, ist meines Erachtens Schnee von 1970. Inzwischen gibt es 
Echtzeitsysteme und Synchronisationsmechanismen für Prozesse.

Die gängige Methode ist, einen Wert zu messen, die Rechnung auszuführen, 
den neuen Wert zu stellen und dann das Ergebnis abzuwarten und dann 
wieder zu messen. Damit sind zyklische Systeme von einander entkoppelt 
und es wird immer mit einem Wert hinterher gemessen und gerechnet. Das 
bedeutet einen Zeitversatz von einem Zyklus zwischen Schreiber / Rechner 
und Ausführer.
Der Ausführer ist also mit dem alten Wert unterwegs, während am 
aktuellen gerechnet wird. Es gibt also ein Delay von 2 Zyklen zwischen 
Zentrum des Messens und des Rechnens. Die Lösung des Dilemmas ist die 
Verwendung der doppelten Abtastrate für das Reglerintervall gegenüber 
dem, was man bei einer reinen Steuerung hätte. Wenn Du mit 16kHz + 
200kHz arbeitest, kommst Du auf etwa 14kHz oder landest eben bei 8kHz 
wenn Du wechselst und einen Sollwert vorgibst.