Überprüfen der Auslastung/Verarbeitungsdauer?

[m_herr]

Hallo,

ich stelle mir gerade mal die Frage, wie ich überprüfen kann, ob der AVR mein Programm auch in der richtigen Zeit ausführt?

Angenommen ich habe Schleifen mit Zeit-Eintrittsbedingungen, also alle 200ms dies, alle 50ms das und so weiter.

Wie kann ich überprüfen, ob alles in der entsprechenden Zeit abgearbeitet wird? Hoffe mal nicht mit Stoppuhr...oder? Wenn er zb alle 200ms eine Schleife abarbeiten soll (ADC, Print, LCD-Ausgabe, Berechnungen ect) er aber für die Arbeit 220m braucht, kann man sich ja vorstellen, was nach einer Stunde los ist: er hängt der gewünschten Zeit ziemlich hinterher...

Wäre ja doof, wenn der vollgestopfte AVR da dem Zeitwunsch nachhängt...

Vielen Dank

[Vitis]

Dafür gibts die Timer.
Du kannst z.B. mit nem Uhrenquarz nen Mega in ne Real-Time-clock
verwandelt, der alle Sekunde exakt eine bestimmte Funktion
ausführt, die dann möglichst kürzer als eine Sekunde sein sollte.
Oder mit den Tiern dann halt alle hundertstel oder andere beliebige
Zeiträume eine bestimmte Funktion macht.
220ms sind aber auch ne halbe Ewigkeit für nen AVR.
I Zweifel kannste auch mal mit nem schnelleren Quarz probieren

[m_herr]

du hast die Frage wohl nicht verstanden. Ich will überprüfen, ob der AVR meine Instruktionen in der richtigen Zeit ausführt, also nicht überlastet ist. Denn es nützt nichts, wenn ich einen Timer einrichte, aber die auszuführende Arbeit länger dauert als die dafür vorgegebene Zeit.

Wie lange blockiert zb "print" von einem 60Zeichenstring den var? kann ich zb 5mal in der sek (also die angesprochenen 200ms) den String send und in der verbleibenden zeit noch einiges anderes machen lassen?

[Vitis]

Also die UART ist ne absolute Bremse vom µC, wird die
nicht interruptbasierend wie z.B. mit Print betrieben
ist der Controller ne halbe Ewigkeit am Daumen drehen.
Für dolche Überprüfungen gibts den Simulator.
Da steht unten die Cycles also Taktzyklen die
vergehen und auch die vergangene Zeit.

Wie lange es dauert 5 Bytes zu senden hängt von Deiner Baudrate ab.

Wenn Du den String einfach so per Print rausschickst wirds mit anderen Funktionen schwierig noch nebenher was zu machen. Dafür gibts dann den Ringpuffer, der über Config Serial out buffered etc. angelegt werden kann
oder, wie ich es meist mache, auch manuell eingerichtet werden kann.
Das Schreiben ins Senderegister UDR ist ne kurze Geschichte, die Hardware übernimmt dann das Senden in Eigenregie, braucht man bis zum nächsten Zeichen dann nix mehr machen, der weil kann der µC dann anderes tun.
Dafür gibts dann den UTXC- Interrupt, der ausgelöst wird wenn die Übertragung eines Byte abgeschlossen ist. In diesem Interrupt schreibt man dann das nächste Zeichen in die UDR und dann gehts fröhlich weiter mit anderen Dingen, bis eben zum nächsten Zeichen.
Ob die 200ms reichen für alle Deine Bytes hängt von der Baudrate ab.

[m_herr]

also bei mir steht nach einiger Zeit Cycl.=14767:18.4958
ist das jetzt gut? Gibt es irgendwo eine Erklärung für den Simulator?

[Vitis]

Das sind dann rund 15000 Zyklen, bei nem 16MHz Quarz sind das dann
rund eine tausendstel Sekunde. Kommt auf den Quarz halt an.

PS: hab meinen Beitrag oben noch erweitert

[m_herr]

38400 und arbeiten tue ich mit mit 8MHZ und dem gepufferten Senden

[Vitis]

ok, also 8n1 Codiert, rechnerisch währen dann ... hmmm ...

4266 Bytes pro Sekunde übertragbar, also 4,3 Byte pro Milisekunde,
wenn ich mich nicht verrechnet hab versteht sich.
auf 200 ms ergeben sich dann 860 Byte ... sollte also gehen

... so in etwa und auf die Schnelle

[m_herr]

Hat ein String von 60 Zeichen hat eine Länge von 60 Byte?
Oder wie lang ist er?

Nur nebenbei macht der AVR ja noch eine Menge anderer Dinge, deswegen wäre es wirklich interessant zu wissen, ob die Zeiten stimmen.

Hat das noch nie jemand nachgemessen?

[Vitis]

ein Zeichen ist im Allgemeinen ein Byte.
Der String hat noch ein Byte mehr wegen dem Stringende Zeiger

[m_herr]

also 61 byte hat ein String mit 60 Zeichen, und wenn 860 Zeichen gesendet werden können, hoffe ich,daß meine ADC-Sachen/Berechnungen (nur Integer) und Display-Ausgaben nicht allzuviel Zeit verbrauchen...