Zeilenweise keine Optimierung AVr Studio

Warum sollte der C-Compiler da was wegoptimieren?
x und z erhalten beide den Wert von y.

Floh schrieb:
> Warum sollte der C-Compiler da was wegoptimieren?
> x und z erhalten beide den Wert von y.

Wahrscheinlöich, weil ich x nur an dieser Stelle verwende und sonst 
nirgends im Code.

A. K. schrieb:
> Ausserdem wäre noch offen, ob du grad die richtige Frage stellst, oder
> schon ein Weilchen auf dem Holzweg unterwegs bist und an der falschen
> Stelle fragst.

Es handelt sich hier um eine Zeitkritische verarbeitung. Die wirklichen 
Zeilen in meinem Code lauten:

1

value = TCNT1;

2

capture._int[x*2] = value;  //Dieser Code verbraucht ca. 30 byte mehr als der obere, deutlich länger als der obere Code.

Ich möchte erst den zeitkritischen Transfer in value machen, dann den 
Zeitaufwendigerendarunter.

1

[...]

2

  unsigned int value;

3

4

  union{

5

    unsigned char _char[NULL_N*4];

6

    unsigned int _int[NULL_N*2];

7

    unsigned long _long[NULL_N];

8

  }capture;

9

[...]

10

  capture._int[x*2] = TCNT1;

11

  caapture._int[x*2+1] = (int)overflow;

12

[...]

capture._int[x*2] = TCNT1; Diese Zeile dauert viel zu lange. 30 Bytes 
(warum soviel?).

ALso es geht um Frequenzmessung. Wenn ich 55 Hz erzeuge messe ich ca. 
55,01.. Hz und bei 4000HZ messe ich 4100.

Der Timerwert spiegelt die Frequenz wieder. Es scheint ein konstanter 
Verarbeitungswert des Timerwertes um 30-40 Taktzyklen vorzuliegen, 
welcher den Timerwert verfälscht. Bei tiefen Frequenzen sind diese +30 
kaum erwähnenswert, da dem gegenüber ein Timerwert von 100.000+ steht. 
Bei sehr hohen Frequenzen liegt allerdings ein Timerwert von 4000- vor, 
da sind dann diese 30 Taktzyklen verarbeitungszeit katastrophal.

Also vom feststellen, dass ein Nulldurchgang passiert ist, bis zu dem 
Zeitpunkt, wo der Timerwert abgeseichert ist vergeht zuviel Zeit. Die 
Schleife, ob ein Nulldurchgang passiert braucht ca. 14 Byte. Das kann 
natürlich auch die Fehlerquelle sein.

Ich hab mal einen schnelleren Quarz verwendet und schon ist der Fehler 
deutlich geringer. Bin aber schon bei 16Mhz.

Dann nimm den ICP, dafür ist der da...


Ingo

Ich verwende jetzt mal den ICP, kriege aber identische Werte heraus.
Der Entsprechende Code sieht ungefähr so aus:

1

for(x = 0; x < NULL_N ; x++){    //N Nulldurchgänge messen  

2

  if(TIFR & (1<<ICF1)) TIFR |= (1<<ICF1); 

3

  TCNT1 = 0;        

4

  overflow = 0;

5

  if(TIFR & (1<<TOV1)) TIFR |= (1<<TOV1);

6

7

  do{    

8

    if(TIFR & (1<<TOV1)){    

9

      overflow++;      

10

      TIFR |= (1<<TOV1);

11

      if(overflow > 4) break;

12

    }

13

  }while(!(TIFR & (1<<ICF1)));

14

15

  capture._int[x*2] = ICR1;

16

  capture._int[x*2+1] = (int)overflow;  

17

18

  if(overflow > 4) break;

19

}

Kann vielleicht die Software die ich verwende doch ungenaue Frequenzen 
erzeugen? Oder habe ich bei der Konfiguration des ICP etwas verkehr 
tgemacht? Ich benutze den Analog Komparator als Trigger.

Pardon. Ich messe bei 4000Hz nun 4030Hz, vorher waren es 4100Hz.

Noch mehr Tipps`?

Peter Dannegger schrieb:
> Damit holst Du doch wieder nen Jitter rein.
> Du mußt den Timer durchlaufen lassen und die Differenz von einem zum
> nächsten ICP nehmen.

Natürlich kostet das Zeit, aber diese Befehle werden bei einer maximal 
zu messenden Frequenz von ca. 4400Hz doch locker innherlab einer halben 
Periode durchgeführt.

Also erst die neue Messung initialisieren, dann warten, bis das Flag vom 
ICP gesetzt wird und darauf reagieren. Bis das Warten auf das Flag 
beginnt ist doch bei weitem noch keine halbe Periode vergangen. Nach dem 
Warten wird ebenfalls wieder keine halbe Periode vergehen, bis wann auf 
den nächsten Nulldurchgang wartet.

Bzw. da der ICP auf steigende oder fallende Flanke reagiert und nicht 
auf einen Flankenwechsel, kann man nur ganze Perioden messen oder? So 
hab ich es eben gemacht.

A. K. schrieb:
> Da du den Timer nicht per Capture-Event auf 0 setzen kannst, musst du
> statt dessen die Differenz zwischen zwei Captures verwenden. Nur so wird
> das taktgenau. Der Anfang der Messung ist genauso wichtig wie das Ende.

Danke, das habe ich verstanden.

A. K. schrieb:
> Und genau da liegt bei ihm der Hase im Pfeffer, denn der Code zählt auch
> die Overflows mit, weil er sonst offenbar mit dem Frequenzbereich nicht
> klar kommt. Das geht zwar, aber weil da hässliche Gleichzeitigkeiten
> auftreten können muss man deutlich Hirnschmalz in eine Korrektur
> investieren, um nicht ab und zu Fehlmessungen zu bekommen.
>
> Weniger anstrengend für die grauen Zellen: den Prescaler adaptiv
> einstellen. Wenn mehr als ein Overflow reinrutscht, dann war der
> Prescaler zu klein, also vergrössern und nochmal messen. Wenn die
> gemessene Differenz zu klein ist, dann war der Prescaler zu gross.

So ist es. Das mit dem Prescaler wechseln, auf die IDee bin ich bis 
jetzt noch nicht gekommen. Ich habe den Code jetzt soweit verbessert, 
ohne ICP, dass ich bei 4000Hz ein Pendeln zwischen 4011-4018 angezeigt 
bekomme.