Frage zum Ultraschall-Code^^

Hallo!

Ich habe mal versucht den Code zur Ultraschallerweiterung aus dem Buch "Mehr Spaß mit Asuro 1" zu verstehen.
Der Code wäre dabei folgender:

Code:

---

#include "asuro.h"

void LocalInit(void) {
  TCCR2 = (1 << WGM21) | (1 << CS20);
  OCR2 = 0x64;
  ADCSRA = 0x00;
  ACSR = 0x02;
  ADMUX = 0x03;
  SFIOR|= (1 << ACME);
  DDRD &= ~(1 << 6);
}

void Ping (unsigned char length) {
  count72kHz = 0;
  TCCR2 = (1 << WGM21) | (1 << COM20) | (1 << CS20);
  while (count72kHz<length) {
      OCR2 = 0x64 + length / 2 - count72kHz;
  }
  TCCR2 = (1 << WGM21) | (1 << CS20);
  OCR2 = 0x64;
}

int main (void) {
  int pos, i;
  int posmarker;
  Init();
  LocalInit();
  while(1) {
      posmarker = 0;
      Ping(20);
      for (pos = 0; pos < 100; pos++) {
        Sleep(10);
        if ((ACSR&(1<<ACI)) != 0) {
            if (posmarker == 0) {
              posmarker = pos;
            }
        }
        ACSR |= (1 << ACI);
      }
      if (posmarker > 10) {
        StatusLED(GREEN);
        MotorDir(FWD,FWD);
        MotorSpeed(200,200);
      }
      else {
        StatusLED(RED);
        MotorDir(FWD,RWD);
        MotorSpeed(0,200);
        for (i = 0; i < 100; i++) {
            Sleep(200);
        }
      }
  }
  return 0;
}

---

Speziell verstehe ich dabei diese Zeile nicht:

Zitat:

---

while (count72kHz<length) {
OCR2 = 0x64 + length / 2 - count72kHz;
}

---

Also, solange count72Hz kleiner ist als lenght, soll die Frequenz um die Gleichung OCR2 = 0x64 + length / 2 - count72kHz geändert werden.
Was wären denn dann die Maximal- und Minimalwerte für die Frequenz und warum?
Angenommen, ich suche mir für length 255 aus und count72Hz würde hochgezählt werden bis 254... dann wäre OCR2= 100 + 127 - 254= -26 und hätte damit eine negative Frequenz, was ich irgendwie einfach nich verstehe?

Und außerdem wird ja nur getoggelt, wenn ein compare match zwischen OCR2 und TCNT2 auftritt... wenn aber OCR2 die ganze Zeit verändert wird, dann ist das doch irgendwann willkürlich bei welcher Frequenz getoggelt wird, oder?

^^

Hat denn keiner ne Ahnung? o.O

Der Code kommt mir fehlerhaft vor:
Weder count72kHz noch length sind volatile deklariert, und werden in der Schleife nicht verändert. Die Schleife wird also entweder nicht (weil die Bedingung nicht erfüllt ist) ausgeführt, oder das Programm bleibt in der Schleife hängen.

Doch, es ist deklariert als einere volatile, sehe asuro.c, gleich am anfang:

Code:

---

volatile unsigned char count72kHz;

/* uses timer2 (36kHz for IR communication */
/* counts falling and rising edge => 36kHz*2 = 72kHz */
SIGNAL (SIG_OUTPUT_COMPARE2)
{
        count72kHz ++;
}

---

Mehr weis ich auch nicht davon.

Also ich habe mir neulich auch den Ultraschall Sensor zusammengebaut, und alles lief bis auf ein Paar Kurzschlüsse in der Schaltung korrekt. Auch das Testprogramm (runtergeladen von www.arexx.com/downloads/asuro/us_bauplan.zip) funktionierte gut. Die Codestelle

Code:

---

while (count72kHz<length) {
OCR2 = 0x64 + length / 2 - count72kHz;
}

---

erinnert mich jedoch an eine in der ultrasonics.c Datei der neuen Lib:

Code:

---

while(count36kHz != 20) {
        OCR2 = 100 + 20 / 2 - count36kHz;
    }

---

Mit diesem Code gibt es auch keine negativen Werte, da nur bis 20 gezählt wird. An einem Osziloskop sieht man das Ergebnis aber trotzdem irgentwie nichts. :-k

MfG
Darthmina123

Ja, das hat mich auch gewundert...
Okay, zumindest wäre damit die eine Frage geklärt^^

Ich habe mir mittlerweile zwei Möglichkeiten ausgedacht, die erklären könnten, warum der Wert von OCR2 immer geändert werden muss:
1. Man muss den Wert von OCR2 vielleicht bei jedem Durchlauf ein bisschen, weil sonst nicht mehr erneut getriggert würde.
Es soll ja jedesmal wenn ein CompareMatch zwischen OCR2 und TCNT2 auftritt ein Signal ausgegeben werden, welches durch den in OCR2 abgelegten Wert definiert und dessen Frequenz über eine Formel berechnet werden kann.
Wenn aber der Wert in OCR2 nicht variiert, vielleicht wird dann einfach kein neuer CompareMatch erkannt und es wird nicht erneut getriggert...
Wobei ich das selber eher für komisch halte o.O

2. Könnte auch sein, dass man durch minimal variierende Frequenzen des US-Signals verhindern will, dass sich zwei zeitgleich eintreffende Echos nicht überlagern können.

Klingt irgendwas davon plaûsibel? ^^

Also mit nem Osziloskop konnte ich keine großen Veränderungen in der Form des Signals von OC2 erkennen.
Komischerweise kommen die chirps in schnellerer Reihenfolge wenn der Abstand zu einem Objekt verringert wird.

o.O
Okay... Das verstehe ich jetzt nicht.
Es gibt doch an keiner Stelle in dem Code irgendwas, was dazu führen würde, dass der Chirp schneller gesendet würde, oder?