genauer Code im Anhang

student Gast #2616350
Lesenswert?
• ▲
▼ 
Hier ist der Code:

1
[...]

2
u32 startTime = 0;

3
  u8 scanMode = 0;

4
  while (1)//scannen

5
  {

6
    if (ledCounter%10000 == 0)

7
    {

8
      clearOutputPin(led1);//led an

9
    }

10
    if (ledCounter%10000 == 899)

11
    {

12
      setOutputPin(led1);//led aus

13
    }

14


15
    if (scanMode == 0)

16
    {

17
      setAsOutputPin(srf05);

18
      setOutputPin(srf05);

19
      startTime = ledCounter;

20
      scanMode = 1;

21
    }

22
    else if (scanMode == 1)

23
    {

24
      if (ledCounter >= startTime + 1)

25
      {

26
        clearOutputPin(srf05);

27
        setAsInputPin(srf05);

28
        startTime = ledCounter;

29
        scanMode = 2;

30
      }

31
    }

32
    else if (scanMode == 2)

33
    {

34
      if (getInputPin(srf05))

35
      {

36
        startTime = ledCounter;

37
        scanMode = 3;

38
      }

39
    }

40
    else if (scanMode == 3)

41
    {

42
      if (!getInputPin(srf05))

43
      {

44
        scanTime = ledCounter - startTime;

45
        breakStatus = 1;

46
      }

47
      if (ledCounter >= startTime + 300)

48
      {

49
        scanTime = 300;

50
        breakStatus = 1;

51
      }

52
    }

53


54
    _delay_us(100);

55
    ledCounter++;

56
    if (scanTime != 0)//abbruch sobald scan fertig

57
    {

58
      breakStatus = 1;

59
    }

60
    if (breakStatus)

61
    {

62
      breakStatus = 0;

63
      ledCounter = 0;

64
      startTime = 0;

65
      scanMode = 0;

66
      //break;

67
    }

68
  }

69
[...]
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Karl H. #2616372
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
student Gast #2616381
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #2616411
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
student Gast #2616433
Lesenswert?
• ▲
▼ 
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)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Peter D. #2616652
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
student Gast #2616724
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren