genauer Code im Anhang

[student (Gast)]

Hier ist der Code:

[...]
u32 startTime = 0;
  u8 scanMode = 0;
  while (1)//scannen
  {
    if (ledCounter%10000 == 0)
    {
      clearOutputPin(led1);//led an
    }
    if (ledCounter%10000 == 899)
    {
      setOutputPin(led1);//led aus
    }

    if (scanMode == 0)
    {
      setAsOutputPin(srf05);
      setOutputPin(srf05);
      startTime = ledCounter;
      scanMode = 1;
    }
    else if (scanMode == 1)
    {
      if (ledCounter >= startTime + 1)
      {
        clearOutputPin(srf05);
        setAsInputPin(srf05);
        startTime = ledCounter;
        scanMode = 2;
      }
    }
    else if (scanMode == 2)
    {
      if (getInputPin(srf05))
      {
        startTime = ledCounter;
        scanMode = 3;
      }
    }
    else if (scanMode == 3)
    {
      if (!getInputPin(srf05))
      {
        scanTime = ledCounter - startTime;
        breakStatus = 1;
      }
      if (ledCounter >= startTime + 300)
      {
        scanTime = 300;
        breakStatus = 1;
      }
    }

    _delay_us(100);
    ledCounter++;
    if (scanTime != 0)//abbruch sobald scan fertig
    {
      breakStatus = 1;
    }
    if (breakStatus)
    {
      breakStatus = 0;
      ledCounter = 0;
      startTime = 0;
      scanMode = 0;
      //break;
    }
  }
[...]

[Mystifizierer (Gast)]

Sehr schön.

[anderer student (Gast)]

Wo ist die Frage?

[Krapao (Gast)]

Unn?

[student (Gast)]

Sorry, das sollte eine Antwort auf www.mikrocontroller.net/topic/253981 
sein.
Der srf05 liefert bei der ersten Messung ein Korrektes Ergebnis, bei der 
2. Messung hängt er...

[Krapao (Gast)]

Beitrag "srf05 an atmega32 liefert nur eine Messung"

[Karl H. (kbuchegg)]

if (scanTime != 0)//abbruch sobald scan fertig
    {
      breakStatus = 1;
    }
    if (breakStatus)
    {
      breakStatus = 0;
      ledCounter = 0;
      startTime = 0;
      scanMode = 0;
      //break;
    }


scanTime wird (zumindest in diesem Ausschnitt) nicht wieder auf 0 
gesetzt. Damit wird ständig in weitere Folge die 'Initialisierung' 
durchlaufen und das ganze Werkl beginnt nicht mehr zu laufen.

Persönlich denke ich, dass du zu viele Flag-Variablen (noch dazu mit 
schlecht gewählten Namen) verwendest und dadurch den Überblick verloren 
hast, welche Variable wie stehen muss damit was passiert. In diese Falle 
manövrieren sich alle irgendwann mal. Abhilfe: rigoros ausmisten.

breakStatus und die Abfrage auf scanTime brauchst du doch in 
Wirklichkeit  gar nicht.

>    _delay_us(100);
Schade. Bis zu dieser Zeile las sich das alles gar nicht so schlecht.

[student (Gast)]

Karl Heinz Buchegger schrieb:
> scanTime wird (zumindest in diesem Ausschnitt) nicht wieder auf 0
> gesetzt. Damit wird ständig in weitere Folge die 'Initialisierung'
> durchlaufen und das ganze Werkl beginnt nicht mehr zu laufen.

Ja, das ist gewollt, um unendlich viele Testergebnisse zu bekommen (zu 
Testzwecken). Das Problem ist, dass im 2. Schleifendurchlauf nur der 
HighPegek als Ausgangsimpuls gesetzt wird, aber nicht mehr auf low geht.

Karl Heinz Buchegger schrieb:
> Persönlich denke ich, dass du zu viele Flag-Variablen (noch dazu mit
> schlecht gewählten Namen)

Ja, mag sein. Überblick habe ich aber eigentlich nicht verloren.

Karl Heinz Buchegger schrieb:
>>    _delay_us(100);
> Schade. Bis zu dieser Zeile las sich das alles gar nicht so schlecht.

Inwieweit ist es ab da schlecht?

[Karl H. (kbuchegg)]

student schrieb:


>>>    _delay_us(100);
>> Schade. Bis zu dieser Zeile las sich das alles gar nicht so schlecht.
>
> Inwieweit ist es ab da schlecht?

Weil du genaue Timingsachen nicht mit einem _delay erreichen kannst. In 
den Zeiten, die du misst ist dann immer auch die Durchlaufzeit durch den 
Code in der Schleife enthalten. Timingsachen macht man mit einem Timer. 
Dazu ist er da.

[student (Gast)]

Ok. Merkt man dann um so mehr, je kleiner die Wartezeiten sind
Dann schreib ich mir noch eine time.c mit Funktionen wie
getTime() und setTime(u32)
die ich dann über timerinterrupts manipuliere.

Ist alle 10us die Variable manipulieren zu viel?
Ich meine ich will nicht 99% der CPU-Zeit für die Uhr verschwenden...
Dann würde er glaub ich ~160 Instruktionen abarbeiten, während er ein 
mal die Zeit manipuliert. (16MHz)

[Peter D. (peda)]

student schrieb:
> Ist alle 10us die Variable manipulieren zu viel?
> Ich meine ich will nicht 99% der CPU-Zeit für die Uhr verschwenden...
> Dann würde er glaub ich ~160 Instruktionen abarbeiten, während er ein
> mal die Zeit manipuliert. (16MHz)

Der AVR ist ein RISC, d.h. alles braucht viele Zyklen (Load, Operation, 
Store).
Ein Interrupthandler <50 ist sportlich, 100 ist kurz, 160 ist noch lange 
nicht viel.

Alle 160 Zyklen einen Interrupt muß man sich daher sehr gut überlegen. 
Andere Interrupts und das Main wollen ja auch ein kleines bischen 
CPU-Zeit haben.


Peter

[student (Gast)]

Danke für die Info!
Für mich ist jedoch auch wichtig, dass ich das Signal des srf05 
möglichst genau messe.
Jede Millisekunde ein Interrupt ist absolute Pflicht!
Und 100µs wäre wünschenswert, 10µs ziemlich genial.

[Peter D. (peda)]

student schrieb:
> Für mich ist jedoch auch wichtig, dass ich das Signal des srf05
> möglichst genau messe.

Dazu ist das Input-Capture gedacht. Dann spielen Interruptlatenz und 
Ausführungszyklen keinerlei Rolle mehr.


Peter