Micros() Abfrage wird immer langsamer

International Deutsch
1

Hallo,
ich bin neu hier und habe eine Frage zum micros()-Befehl. Dieser soll die Prozessorzeit nach dem Start in Microsekunden ausgeben (Datentyp: unsigned long). Ein kleines Test-Programm soll die micros() auf dem Monitor anzeigen und dieses im 'void loop' ständig wiederholen.

unsigned long time;

void setup() {
  Serial.begin(9600);
}
void loop() {
  Serial.print("Time: ");
  time = micros();
  Serial.println(time);             // gibt die Zeit seit dem Programmstart aus
//  delayMicroseconds(20);          // Warte eine Sekunde, um keine riesigen Datenmengen zu senden
}

Dieses Programm tut es auch. Jedoch was ich mich frage ist: Wieso wird die Durchlaufzeit von anfangs 164µs über 208µs hoch bis zu 14560µs. Für immer das gleiche Programm. Mir erscheint der Programmdurchlauf von 14,56 ms für den Arduino Mega2560 viel zu hoch.

Wer wüsste einen Rat, wie ich die Zeiten verkürzen kann. Oder liegt es an dem Inhalt in der unsigned long-Variable.
Differenz
Time: 56
Time: 220 164
Time: 428 208
Time: 636 208
Time: 844 208
Time: 1060 216
Time: 7316 6256
Time: 19796 12480
Time: 33316 13520
Time: 46836 13520
Time: 60356 13520
Time: 73876 13520
Time: 87396 13520
Time: 100916 13520
Time: 115476 14560
Time: 130036 14560
Time: 144596 14560
Time: 159156 14560
Time: 173716 14560
Time: 188276 14560
Time: 202836 14560
Time: 217396 14560
Time: 231956 14560
Time: 246516 14560
Time: 261076 14560

2

Hallo noiasca,
danke für die schnelle Antwort. Die Anpassung auf die höhere Datenrate hat schon etwas gebracht. Jetzt erreicht die maximale loop-Dauer nur noch 1104µs.

Jedoch ist immer noch ein Anstieg in der Durchlaufzeit von knapp 180µs über 240µs auf über 1100 µs. Kann dieses auch an den hohen Werten (große Zahlenwerte sind mit größeren zeitlichem Aufwand zu berechnen)?

3

Dieses Testprogramm:

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

void loop() 
{
  unsigned long start {micros()};
  Serial.print(Serial.availableForWrite());
  Serial.print(" : ");
  Serial.println(micros() - start);           
}}

Sagt auf einem UNO:

63 : 132
55 : 136
45 : 132
35 : 140
26 : 132
16 : 132
6 : 88
0 : 4160
0 : 4160
0 : 4160
0 : 4160
0 : 4160
0 : 4164
0 : 4160
0 : 4160

Anfangs kann der serielle Buffer noch gefüllt werden, natürlich nur, bis er voll ist, danach blockiert print um keine Zeichen zu verlieren

4

1 Zeichen braucht 1 / Baudrate * 10 Sekunden

5

Daran sieht man, dass

  1. Serial.print unheimlich schnell ist, wenn noch Platz im Puffer ist.
  2. eine Ausgabegeschwindigkeit schneller als man lesen kann zwar eine Änderung bringt, aber
  3. Serial in jedem Fall "langsam" ist.

// Warte eine Sekunde, um keine riesigen Datenmengen zu senden

Ja, das wäre gut :slight_smile:
leider nur falscher Kommentar

6

Kann dieses auch an den hohen Werten (große Zahlenwerte sind mit größeren zeitlichem Aufwand zu berechnen)?

Nein. Das Problem ist die Serielle Übertragung und nur diese.

7

addi_4:
Mir erscheint der Programmdurchlauf von 14,56 ms für den Arduino Mega2560 viel zu hoch.

Wer wüsste einen Rat, wie ich die Zeiten verkürzen kann.

Zähle doch einfach die Durchläufe von loop(). Nimm die micros() vorher und nach z.B. 1000 Durchläufen, teile die Differenz durch die Anzahl Durchläufe und gib diese Schleifendauer aus.

Oder prüfe wann 1ms vergangen ist und gib dann die Zeitdauer für jeden gezählten Durchlauf aus.

Eine sonst leere Schleife wird bei 16MHz ca. 100000 mal pro Sekunde durchlaufen (100kHz), d.h. ca. 10µs pro Durchlauf.

8

Danke für die interessanten Beiträge. So wie ich es verstehe liegt es am seriellen Buffer des Arduino Mega 2560. Dieser kann nur eine bestimmte Menge an Daten aufnehmen. Sobald dieser voll ist muss gewartet werden bis dieser von der Schnittstelle verarbeitet wurde. Dieses hängt von der Übertragungsrate ab und bremst somit die Durchlaufzeit des Programms aus.

Das ursprüngliche Programm ist nur ein Testprogramm. Das Programm, welches ich später verwenden möchte, soll neben einigen anderen Aufgaben noch ein 27 kHz Signal auf einen Ausgang legen. Dieses bedeutet, dass das Signal ca. alle 38µs einen Impuls erzeugen muss. Wahrscheinlich dürfen dann die anderen Aufgaben nicht so umfangreich sein, um diesen Impuls noch relativ regelmäßig erzeugen zu können.

Der Vorschlag von DrDiettrich ist für meine Anwendung interessant. Nach dem Beispiel habe ich noch ca. 28 µs für die anderen Aufgaben. Die Ausgabe auf den Monitor war nur zum Testen und Verständnis. Diese Ausgabe ist im geplanten Programm nicht erforderlich, sodass eine gute Chance besteht dieses so umzusetzen.

9

addi_4:
noch ein 27 kHz Signal auf einen Ausgang legen. Dieses bedeutet, dass das Signal ca. alle 38µs einen Impuls erzeugen muss. Wahrscheinlich dürfen dann die anderen Aufgaben nicht so umfangreich sein, um diesen Impuls noch relativ regelmäßig erzeugen zu können.

Sowas kann man komplett in Hardware erledigen ohne dass Code ausgeführt wird