Problem mit Ausführungszeit bzw. micros() und delayMicroseconds()

[Moppi]

Hallo,

ich habe folgenden Testcode für den Arduino Uno.

void setup() {
  Serial.begin(115200);
  while(!Serial){}

  pinMode(3,INPUT);
}

void loop() {
  int a = micros();


  int c = digitalRead(3);
  delayMicroseconds(1);
  

  int b = micros();
  b=(b-a)*4;
  Serial.println(b);
  delay(2000);
}

Ich will wissen, wieviel Zeit der Befehlsblock

int c = digitalRead(3);
  delayMicroseconds(1);

in Anspruch nimmt. Ich erhalte eine Ausgabe, die sehr wechselhaft ist:

32
16
16
32
16
32
16
16
32
16
16
16
32
16
32
16

So weit ich das verstanden habe ist es doch auf dem UNO so, das micros() ein Vielfaches von 4 zurückgibt. Also multipliziere ich das Ergebnis mit 4. Dennoch braucht er einmal dann die doppelte Zeit zur Ausführung des Befehlsblocks? Ich denke:
- dass der Controller hier entweder zwischendurch dann was anderes macht, was Zeit benötigt
- der Mikrosekundenzähler eine relative Abweichung hat

Vielleicht weiß jemand besser darüber bescheid und kann mal eine Erläuterung dazu geben, was diese Schwankungen hervorruft?

Gruß, Moppi

[Mxt]

Hallo,

also was micros() zurück gibt sind schon Mikrosekunden. Sie werden nur nicht im Mikrosekundentakt weitergezählt, weil die Leistung der Hardware das nicht hergibt.
Letzteres kann auch ein Grund dafür sein, dass man eine Verzögerung von einer Mikrosekunde so eventuell nicht so hinkriegt.

digitalRead ist eine ziemlich fette Funktion, die macht eine Menge Sachen. Das dauert sicher viel länger, als das Warten danach. Wenn man so schnell mit IOs arbeiten will, sollte man direkt mit den Ports arbeiten, oder ein entsprechendes Gegenstück zu digitalReadFast auf dem Teensy verwenden, da kenne ich mich mit den verfügbaren Libs für den Uno nicht aus.

Zumindest theoretisch sollten bei digitalRead zeitliche Abweichungen entstehen, wenn da der Interrupt dazwischenfunkt, der die millis weiterzählt.

[Moppi]

Ja das ist ja die Frage: was zwischendurch passiert.

Ich habe jetzt eigentlich nicht gedacht, dass er anfängt über einen Interrupt die Microsekunden zu zählen. Gibt es dafür keinen Zähler, der nebenbei herläuft?

Aufgrund dieser Sache mit der Auflösung von 4 Microsekunden pro Zählerwert, müsste dann als Minimum bei delayMicroseconds() eine 4 stehen, also eigentlich müsste man so schreiben: delayMicroseconds(1*4), was dann immer ein Vielfaches von 4 Microsekunden wäre.

Nachtrag:

Wenn ich mit dem Wert von 4 arbeite delayMicroseconds(4), dann habe ich immer denselben Wert von 32. Wenn ich delayMicroseconds() weg lasse dann erhalte ich immer wechselnde Werte von 16 und 32. Dasselbe, wenn ich delayMicroseconds(1) schreibe. Dauert das vielleicht mit dem Auslesen der Microsekunden via micros() unterschiedlich lange?

[Mxt]

Er zählt die Millisekunden über einen Interrupt. digitalRead ist so groß, dass es da gelegentlich eine Unterbrechung geben kann.

Ich kenne nur die micros() Implementierung für die 32 Bit Teensys, um die für AVR zu suchen habe ich weder Lust noch Zeit.

Reduziert aufs wesentliche sieht der Code für micros() auf dem Teensy so aus:

uint32_t micros(void)
{
	uint32_t count, current;

	__disable_irq();

	current = SYST_CVR;
	count = systick_millis_count;

	__enable_irq();

	current = ((F_CPU / 1000) - 1) - current;

	return count * 1000 + current / (F_CPU / 1000000);
}

Wird also aus millis und einem schnell laufenden Zähler berechnet.

Geht wahrscheinlich auf einem AVR ähnlich.

[Moppi]

Das mit dem Multiplizieren mit 4 beim UNO Rev3 ist jedenfalls irgendwie Quatsch. Wenn ich micros auslese gibt er ganz normal micros zurück (nix mit 4 oder so) - wenn ich das mit millis vergleiche. Wenn ich millis auslese, soll er ja auch millis zurückgeben.

Na ja, entscheidend für mich ist, dass ich immer dieselbe Messeinheit dort auslese, um Verarbeitungszeiten untereinander zu beurteilen.

Danke für Deine Hilfe mxt!

[Klebwax]

Das mit dem Multiplizieren mit 4 beim UNO Rev3 ist jedenfalls irgendwie Quatsch.

Hast du schon mal 3 oder 5 oder 6 oder 7 als Ergebniss bekommen?

MfG Klebwax