avr-gcc ignoruje volatile?

[bobo87]

Zdravim, mam podozrenie na to, ze avr-gcc (4.8.2) ma bug v jednom pripade pouzitia volatile. Ma niekto iny napad co som mohol prehliadnut a sposobuje to moj problem? Mam zapojenie, v ktorom je ATmega128A, XTAL 8MHz, na PORTC je zavesenych 8 LED.

Testovaci program je tu : https://pastebin.com/197Q3c6p

Pokusne som si chcel nechat vysvietit hodnotu systemTimer na PORTC, ale akosi sa nedeje nic, vsetky LED zhasnute. Zapojenie je OK, ak sa hodnota na PORTC nastavi natvrdo, LED svietia ako maju. Ak som skusil zmenit ISR priamo na manipulaciu s portom, napr:

Kód: Vybrať všetko

ISR(TIMER1_COMPA_vect){
    PORTC = ~PORTC;
}

a slucku v main() som upravil na

Kód: Vybrať všetko

while(1){
    ;
}

tak v 1s intervaloch sa LED pekne vypinaju a zapinaju, taze casovac je urcite nastaveny OK. Vychadza mi to, ze v main() v loope kompilator necita realnu hodnotu systemTimer, ale pouziva stale hodnotu 0 z inicializacie. Je to tou vecernou hodinou, alebo uslo nieco mne, alebo je to naozaj bug kompilatora?

EDIT:
Ak som deklaraciu systemTime zmenil na:

Kód: Vybrať všetko

register Time systemTime asm("r3");

tak sa to tvari funkcne, ale takto by to byt nemalo. + Program sa sprava inak pri zapnutych/vypnutych optimalizaciach.

[peterple]

Skompiloval som to a kukol na to ako je to preložené. A z pohľadu kompilátora je to OK. Premenná sídli v SRAM a je v main korektne čítaná. Takže bug v kompilátore hlásiť nemusíš.
Version: 3.4.0.663 - GCC 4.6.2

Kód: Vybrať všetko

ISR(TIMER1_COMPA_vect){
0000002F  PUSH R1		Push register on stack 
00000030  PUSH R0		Push register on stack 
00000031  IN R0,0x3F		In from I/O location 
00000032  PUSH R0		Push register on stack 
00000033  CLR R1		Clear Register 
00000034  PUSH R24		Push register on stack 
	systemTime++;
00000035  LDS R24,0x0060		Load direct from data space 
00000037  SUBI R24,0xFF		Subtract immediate 
00000038  STS 0x0060,R24		Store direct to data space 
}
0000003A  POP R24		Pop register from stack 
0000003B  POP R0		Pop register from stack 
0000003C  OUT 0x3F,R0		Out to I/O location 
0000003D  POP R0		Pop register from stack 
0000003E  POP R1		Pop register from stack 
0000003F  RETI 		Interrupt return 

Kód: Vybrať všetko

		PORTC = systemTime;
0000004F  LDS R24,0x0060		Load direct from data space 
00000051  OUT 0x15,R24		Out to I/O location 
00000052  RJMP PC-0x0003		Relative jump 

[bobo87]

Hlasit to zatial nehlasim, ale nerozumiem preco tomu tak je a preco ak tu premennu napasujem priamo do registra, tvari sa to OK? +preco to funguje inak pri optimalizaciach? Jednoducho mi nejako unika, PRECO je to tak?

[peterple]

Nevidím nikde problém. Kompiloval som ten tvoj original program s O1 a potom aj s O3. vždy to bolo rovnaké a simulácia ukázala že to funguje. Tak si to odsimuluj keď sa ti zdá že niečo je zle.

[bobo87]

Skusal som to v simulatore z AtmelStudia 7 a tvarilo sa to OK. Mohol by som ta poprosit o HEX subor, ktory ti to vyplulo? Nech to skusim hodit na HW, co to spravi.

[peterple]

Tu je hex. Včera sm to kompiloval pre ATmega8. Preto sú tam použité zlé adresy. Priložený súbor je už pre mega128A.

[bobo87]

Ahoj, dakujem. Prave som to dal dnu a - nic... Premyslam, co dalsie by to mohlo byt. ATmega je kupena na eBay, takze predpokladam iba fake, ale moze sa to prejavit takto?

EDIT:
Nieco je asi velmi zle, deju sa tu take podivnosti, ze ak napr priradene tlacidla natvrdo vysvietim v hlavnom cykle v style PORTC = PIND; tak to funguje, ale akonahle PIND je volanie fcie, ktora PIND vracia, nejde to. Tak to som este nevidel...

[bobo87]

Nemal som vela casu, tak az teraz. Riesenie vyzera byt to, ze bol zapnuty mod kompatibility s atmega103 (preto to asi aj slo v simulatore). Takze CLOSED, kazdy sa obcas utne.

[peterple]

Vidíš, to ma nenapadlo. Fajn že si dal info čo bolo vo veci.