Variablenname entscheidet ob Programm spinnt oder nicht?

[Paul H. (powl)]

Hi,

ich habe da grad ein seltsames Problem entdeckt. Ich habe einen 
Charlieplexer und noch 4 weitere LEDs dran hängen die ich als Lauflicht 
betreiben möchte. Über den ADC stell ich die Lauflichtgeschwindigkeit 
ein. Wenn ich bestimmte Werte einstelle kommt das irgendwie dem 
Charlieplexingalgorithmus in die Quere und eine LED Gruppe flackert 
dann.

Ich hab mich natürlich gefragt was das soll und den Fehler systematisch 
eingegrenzt bis ich auf folgendes gestoßen bin:

vor der main-function:

volatile uint8_t adc_lights;

in der main-function:

adc_lights = ADCH;

Nur durch das Belegen der Variable mit ADCH fängt das Programm an zu 
spinnen. Ich hab keine Ahnung warum. Das Lauflicht funktioniert unter 
diesen Umständen übrigens auch nicht.

Wenn ich die Variable nun überall in adc_light, also ohne das s am 
ende, umbenenne, dann funktioniert alles prima.

Ist das ein Bug im Compiler? Die Codegröße verändert sich dabei auch 
nicht.

Wenn ich mir das Assembler-file anschaue fällt an der stelle in der main 
folgendes auf:
in der lights-version:
 128:  80 93 9e 00   sts  0x009E, r24

in der light-version:
 128:  80 93 9a 00   sts  0x009A, r24

wieso nimmt er hier denn eine andere speicherposition?
mit anderen optimierunggstufen gibt es den gleichen flacker-effekt.

lg PoWl

[Oliver (Gast)]

>Ist das ein Bug im Compiler?

Nein. Das ist mit Sicherheit ein Bug in deinem Programm, der ganz 
woanders zu suchen ist. Daher, wie immer: Zeig mal den ganzen Code.

Oliver

[Paul H. (powl)]

sry, hab vergessen den dateianhang nochmal neu rauszusuchen.

hm.. aber ich habe ausser dem variablennamen rein garnichts verändert. 
nur den namen. ich könnte die variable auch bla oder moep nennen. 
ansonsten keine veränderung.

nur diese kleinigkeit, die ja mit dem programm an sich ja garnichts zu 
tun hat und sache des compilers ist, verändert das verhalten des 
programms.

meinetwegen ist der programmcode nicht ganz optimal, das hab ich auch so 
schnell da hingeschnuddelt. aber dann kann es doch nicht sein, dass er 
funktioniert / nicht funktioniert, wenn ich eine variable anders nenne?

ich habe bestimmte codeteile auskommentiert die nicht zum fehler 
beitragen.

lg PoWl

[MartinH (Gast)]

Solche Probleme klingen immer nach amokgelaufenen Zeigern, bzw. Array 
Zugriffen. Das erste was mir aufgefallen ist:

phase_DDR hast du mit 4 Elementen deklariert.
Gleich am Anfang schreibst du über das Array hinaus -> phase_DDR[4] = 0;

[MartinH (Gast)]

Und natürlich dann weiter in der Schleife bei
phase_DDR[map[a]] --> in map gibt Elemente mit dem Wert 4, also das 
gleiche Problem.
deklariere phase_DDR mal mit 5 Elementen, also phase_DDR[5].

Gruß

[Oliver (Gast)]

Und sach mal, welchen Prozessor du verwendest.

Oliver

[Paul H. (powl)]

bingo :-)

volatile uint8_t phase_DDR[5];

jetzt funktionierts. ich war irritiert weil ich es nun so gewohnt bin ab 
0 zu zählen aber hier muss man ja ab 1 zählen.

danke!

was mich dennoch interessiert, wieso entscheidet der variablenname 
darüber ob das programm trotzdem funktioniert bzw. wieso kompiliert er 
es anders? interessant ist auch, dass das die ganze zeit so gelaufen 
ist.

lg PoWl

[Oliver (Gast)]

>was mich dennoch interessiert, wieso entscheidet der variablenname
>darüber ob das programm trotzdem funktioniert bzw. wieso kompiliert er
>es anders?

Tut er nicht, und kompiliert auch nicht anders. Ich würde es ja gern mal 
nachstellen, aber dazu müsstest du schon verraten, für welchen AVR dein 
Programm ist.

Oliver

[Stefan E. (sternst)]

Paul Hamacher wrote:

> was mich dennoch interessiert, wieso entscheidet der variablenname
> darüber ob das programm trotzdem funktioniert bzw. wieso kompiliert er
> es anders? interessant ist auch, dass das die ganze zeit so gelaufen
> ist.

Weil du mit dem Schreiben nach phase_DDR[4] eine andere Variable 
überschrieben hast. Und wie du ja selbst festgestellt hast, sorgt das 
Umbenennen dafür, dass die Variablen in einer anderen Reihenfolge im 
Speicher liegen. In der einen Version hast du irgendetwas weniger 
kritisches überschrieben, so dass das Programm anscheinend funktioniert 
hat.

[MartinH (Gast)]

Das ist immer schwierig zu sagen wo der Compiler, oder besser hier 
Linker, die Variablen genau platziert.
Wie du im Assembler schon gesehen hast, platziert er sie je nach dem 
Namen, den du verwendet hast, an unterschiedliche Positionen. Evtl hat 
er in der funktionierenden ohne s Version die Variablen so im Speicher 
platziert, dass nichts mehr hinter dem phase_DDR Array liegt, und so 
beim darüber hinausschreiben nichts passiert.

Kannst ja mal schaun, welche Variable du überschreibst, wenn du über das 
Array hinausschreibst.

[MartinH (Gast)]

oh da war ich zu langsam :)

[Paul H. (powl)]

Ok, das gibt der ganzen Sache einen Sinn :-)

Das Programm ist für einen ATtiny26.

Sollte eine Binär-Uhr für mein Schulmäppchen werden, als nettes Gimmick 
sorgt dann noch ein kleines LEDlauflicht an dunklen Tagen oder im 
verdunkelten Physik-Saal vorm Unterricht für Stimmung (ich wollte nur 
einfach meine LEDs loswerden die ich mir zum Ausprobiern bestellt hab)

lg PoWl