Po bardzo długich bojach odkryłem przyczynę swoich bardzo dziwnych problemów z zmazywaniem pamięci w atmedze. Przedstawiam więc co ustaliłem.
Uwaga - ważny jest plik zapychacz.h, który zawiera tablicę w PROGMEM i służy jedynie zajęciu flasha. Bez niego jednak błąd nie wystąpi. Należy użyć pliku załączonego do tego postu. Z niewiadomych przyczyn po dopisaniu kilku linni w main trzeba będzie zmniejszyć (lub czasami zwiększyć) tablicę w zapychacz.h by problem się ponownie ujawnił
Poniższy krótki kod po skompilowaniu i zaprogramowaniu procesora wyśle uartem ciąg:
0xAA 0xAA 0xAC 0xAA 0xAA
a powinien
0xAA 0xAA 0xAA 0xAA 0xAA
Przyczyną okazała się nazwa (!) zmiennej.
Wystarczy zmienić nazwę zmiennej z div na jakąkolwiek inną by program działał poprawnie (kompilator wygeneruje inny kod wynikowy).
Uartem przyjdą wtedy tylko bajty 0xAA (prawidłowo).
uC ATmega16A
avr studio 4.13 528
gcc optymalizacja -Os
WinAvr 20100110
Dlaczego tak się dzieje - czy to rzeczywiście błąd kompilatora?
Uwaga - ważny jest plik zapychacz.h, który zawiera tablicę w PROGMEM i służy jedynie zajęciu flasha. Bez niego jednak błąd nie wystąpi. Należy użyć pliku załączonego do tego postu. Z niewiadomych przyczyn po dopisaniu kilku linni w main trzeba będzie zmniejszyć (lub czasami zwiększyć) tablicę w zapychacz.h by problem się ponownie ujawnił
Poniższy krótki kod po skompilowaniu i zaprogramowaniu procesora wyśle uartem ciąg:
0xAA 0xAA 0xAC 0xAA 0xAA
a powinien
0xAA 0xAA 0xAA 0xAA 0xAA
Kod: C / C++
Przyczyną okazała się nazwa (!) zmiennej.
Wystarczy zmienić nazwę zmiennej z div na jakąkolwiek inną by program działał poprawnie (kompilator wygeneruje inny kod wynikowy).
Uartem przyjdą wtedy tylko bajty 0xAA (prawidłowo).
uC ATmega16A
avr studio 4.13 528
gcc optymalizacja -Os
WinAvr 20100110
Dlaczego tak się dzieje - czy to rzeczywiście błąd kompilatora?
