Hallo,
Habe leider keinerlei hinweise auf derartiges gefunden...
Wer weiss warum die markierte funktion bei allen Optimierungs Optionen
(ausser 0) einfach weg ist?
Wenn ja dann bitte eine möglichkeit wie ich es erfolgreich verhindern
kann!!
danke!
1
intmain(void)
2
{
3
BYTEchannel=3;
4
WORDdata=0;
5
BYTEtemp=0;
6
BYTEbuttons;
7
//Initialize all Ports
8
IOInit();
9
InitSwitchSampling();
10
InitADC();
11
InitDisplay();
12
while(1)
13
{
14
if(!Beat)
15
continue;
16
//process pressed buttons
17
buttons=ProcessButtons();
18
if(buttons!=0)
19
{
20
//display String by placing it to Buffer
21
if(buttons==BUTTON_TOPRIGHT_SHORT)
22
{
23
//ADC Value Channel 0
24
channel=0;
25
data=GetChannelAverage(channel);
26
DisplayStringFlash(adcsamplevalue,channel,data);
27
}
28
if(buttons==BUTTON_BOTTOMRIGHT_SHORT)
29
{
30
//ADC Value Channel 1
31
channel=1;
32
data=GetChannelAverage(channel);
33
DisplayStringFlash(adcsamplevalue,channel,data);
34
}
35
}
36
data=GetChannelAverage(channel);
37
temp=Calculate(data);
38
DisplayStringFlash(adcsamplevalue,channel,data);//<-- Das ist die Funktion die nach optimierung einfach weg ist
39
Beat=0;//Interrupt driven enabling of processing all 100ms
40
}
41
42
}
was dann im AVRStudio Dissassembly so ausssieht
1
104: if(!Beat)
2
+0000005C: 9180010E LDS R24,0x010E Load direct from data space
Reduziere das mal auf ein einzelnes Quellfile, das nicht nur für dich
kompilierbar ist. So dass also alles bekannt ist, Compiler-Optionen
inklusive.
Und mit möglichst wenig drumherum. Also alles nacheinander rauswerfen,
nur dann drinlassen wenn sonst das Problem nicht mehr auftritt.
Hallo,
Ist kein geheim projekt, deshalb hab ich alle files so belassen.
Den Code hab ich nicht zusammen gestrippt, sondern das Makefile
mitgegeben.
compilierbar sollte es dann sein.
Danke fürs Helfen...
Peter Pan wrote:
> Ist kein geheim projekt, deshalb hab ich alle files so belassen.
Das heisst du willst, dass andere Leute für dich diese Arbeit machen.
Guten Tag noch.
Hmmmm,
welche Arbeit?!
** das gilt nur für Andreas Kaiser **
ich versteh nicht warum du das so emotional siehst, von wegen arbeit
abgeben, die arbeit wartet noch, das sind nur testrümpfe und treiber die
diese applikation zusammenhalten und die testschleife is bei gott keine
app.
anstatt sich zu freuen, dass es unkompliziert und effizient über die
bühne geht, denn fragen welches setting welche files warum wieso, dem
ist am einfachsten entgegengewirkt...mit den settings wies nicht
funktioniert oder?!
** ende **
denn damit kann man im AVRStudio auf einen Blick sehen dass es so ist
wie ichs gepostet habe. aber scheinbar war das ja auch nicht genug.
ich dachte da eher an jemanden der wirklich mit GCC vertraut ist und
etwas mehr weiss als die manuals hervorbringen und mir diese eine simple
frage beantworten kann:
!! Warum Strippt/kombiniert der GCC Compiler mit der Option Os, O1, O2,
O3 mir einfach diese funktion, bzw. wie kann ich ihm klarmachen dass es
einen Codeblock gibt der nicht zu optimieren ist !!
Danke an eventuelle Hilfestellungen die nicht ausarten in ein heckmeck
Langfassung:
Eine einfache Antwort habe ich nicht gefunden. Da die aufgerufene
Funktion mehrfach darin vorkommt, ist unwahrscheinlich, dass er sie aus
irgendwelchen im Originalposting nicht erkennbaren Ursachen
wegoptimieren sollte (leere Funktion inlined, oder sowas in der Art).
Folglich ist das erste, was ich einem solchen Fall machen würde: Alles
überflüssige aus dem Testcode rauskürzen, so dass nur noch das
Essentielle übrig bleibt. Idealerweise ohne dass irgendwelche
Include-Files nötig sind.
Entweder erkennt man bei dieser Prozedur schon, wo der Hund begraben
liegt.
Oder es bleibt etwas übrig, dass tatsächlich nach Compilerfehler
aussieht. Dann sollte man das sowieso machen, denn sonst ersäuft
derjenige, der den erforschen will, im Unwichtigen.
Hallo,
ja an register und volatile hab ich nach dem posting eh gedacht und
mitlerweile hab ich volatile an allem getestet was dafür in frage käme.
eine weiter kleine entdeckung viellicht ist es ein hinweis:
alle variablen die ich übergebe scheinen starr zu sein. d.h.
mache ich aus
1
DisplayStringFlash(adcsamplevalue,channel,data);
2
DisplayStringFlash(adcsamplevalue,data++,data++);
wird mir nur der wert gezeigt, mit der die variable data anfangs
initialisiert wurde. und der ändert sich keinesfalls.
Danke nochmal ich werd noch etwas experimentieren
Da wird nichts wegoptimiert. Die Schleife wird nicht einmal
nennenswert umsortiert.
Manchmal ist es sinnvoller, sich statt des Disassemblerlistings den
generierten Assemblercode des Compilers anzusehen:
Nur so am Rande:
DisplayStringFlash(adcsamplevalue,data++,data++);
Sieht mir gefährlich aus. Ich würde mal sagen, daß der C-Standard nicht
definiert welche Werte übergeben werden (für data) und das ganze sehr
Compiler-abhängig ist.
Für data=0
könnte es
DisplayStringFlash(adcsamplevalue,0,0);
DisplayStringFlash(adcsamplevalue,0,1);
DisplayStringFlash(adcsamplevalue,1,1);
oder vielleicht
DisplayStringFlash(adcsamplevalue,1,2);
sein.
Hallo,
Danke für euer input..
habe heute viel gelernt...
Wie nehm ich den den beitrag wieder raus?
Falls es jemand interessiert:
Hab den fehler gefunden aufgrund des generierten Assembler listings.
Das problem war der bufferlock in der Display struktur. die im interrupt
gesetzt wurde um nicht gleichzeitig zu reinzuschreiben und
rauszukopieren.
tja und alles was im interrupt gesetzt wird muss scheinbar volatile
sein.
1
typedefstruct_displaybuffer
2
{
3
volatileBYTEbufferreadlock:1;//Buffer is locked in SegmentScroll -> Displayfunction
4
volatileBYTEbufferwritelock:1;//Buffer is locked in SegmentScrollStringFlash ->Write to Memoryfunction
5
char*buffer;//Pointer to SRAM Location
6
BYTEstartindex;//Where to start on String
7
BYTEscroll:5;//0 scrolls infinite
8
BYTEdone:1;//if scrolling finished bit is set
9
BYTEdirection:2;//LEFT, RIGHT, NONE
10
}chardisplaybuffer;
habs noch ein wenig angepasst, aber ohne eure hilfe hätt ich den fehler
nie gefunden...
tja wieder ein tag vers...chönert.... mit einem bug der norm. kein bug
ist.
schöne woche leute
Peter Pan wrote:
> tja und alles was im interrupt gesetzt wird muss scheinbar volatile> sein.
Nicht alles. Erstens muss natürlich alles das, was nur innerhalb
der ISR benutzt wird, nicht volatile sein. Für die Kommunikation
zwischen verschiedenen Code-Threads (also ISR vs. main(), ISR vs.
andere ISR) ist es sehr oft notwendig. Wenn man die C-Regeln über
all den Kram wie sequence points und mögliche Compiler-Umsortierung
einigermaßen kennt, kann man ggf. noch ein wenig einschränken, wo
volatile wirklich gebraucht wird.
Vorsicht!, volatile ist eine heftige Performance-Bremse. Wenn man
mehr also nur kurze Operationen mit entsprechenden Variablen
vornimmt, sollte man sie in lokalen Kopien cachen.
Thread beobachten
Seitenaufteilung abschalten