witam. Jest program pod atmega64 kompilowany wersj± 2006 04 21 i program wydaje sie dzia³ac poprawnie, tzn nie udalo mi sie wypatrzyc oznak jakichs blêdow, program ma kilkanascie stron. Jezeli przekompiluje go biezaca wesja avr tj. 2007 05 25 to program jak gdyby sie zacinal, dziala i przestaje odpowiadac na chwile po czym dzia³anie dalsze przebiega normalnie, (nie widac zadnych innych objawow nieprawidlowego dzia³ania) Moje pytanie jest czy ktos spotka³ sie z takimi objawami, moze ma sugestie co jest przyczyna, (pewnie bledy w programie- tylko jakie). poniewaz jest to juz moj drugi przypadek kiedy kod kompilowany jedna wersja nie dzia³a kompilowany inna pytanie jest co moze byc przyczyna.? Micha³ M
WINAVR
Nov 12, 2007
15 Replies
M M pisze:
Mam dokladnie ten sam problem ... tylko ze u mnie wogole program nie dziala :( Nie mam czasu ani checi zeby analizowac roznice i gdzie tkwi blad :(
Użytkownik Pawel K napisał:
A nie macie gdzieś w programie deklaracji obsługi przerwania typu INTERRUPT(...) ? Na tym właśnie się naciąłem przy przejściu na 20070525. Ta wersja kompiluje procedurę INTERRUPT tak samo jak SIGNAL tzn. nie wstawia rozkazu "sei" na początku.
Pozdrawiam Grzegorz
Grzegorz Kurczyk pisze:
Macro SIGNAL zostało wycofane z nowszych wersji kompilatora, teraz jak się chce odblokować przerwania to trzeba to zrobić jawnie.
formatting link
Użytkownik kpiecuch napisał:
Ja o tym miałem okazję się już dowiedzieć jakiś czas temu, ale chodzi mi o to czy Autor wątku też o tym wie ? A z tym makro INTERRUPT (chyba o to Koledze chodziło, bo SIGNAL działa tak jak w starszej wersji) to jest tak, że nie zostało ono wycofane w pełnym tego słowa znaczeniu. Program z INTERRUPT nadal się kompiluje bez błędów, tylko w kodzie wynikowym jest nie do końca to czego byśmy oczekiwali.
Pozdrawiam Grzegorz
U¿ytkownik "Grzegorz Kurczyk" snipped-for-privacy@control.slupsk.pl> napisa³ w wiadomo¶ci news:fhak88$8pp$ snipped-for-privacy@nemesis.news.tpi.pl...
Witam. Tak wiem o tym. W moim podejzeniu problem lezy po stronie mojej, chociaz to tak na 75%; tylko ze po prostu nie mam pomyslu co moze byc przyczyna i jak wykryc takie jakis blad ktory ujawnia sie w jednej wersji a w drugiej nie. Pocieszenie ze nie jestem sam jest tylko czesciowe :). dzieki za odpowiedzi. pozdrawiam. Michal M.
U¿ytkownik "M M" <no_spa snipped-for-privacy@interia.pl.uk> napisa³ w wiadomo¶ci news:fhc47q$d9c$ snipped-for-privacy@atlantis.news.tpi.pl...
Swego czasu (przy identycznej przesiadce jaka opisales) pozmienialem typy zmiennych uzywanych jako indeksy tablic (z 'unsigned char' na 'char'). I niespodzianka - w przypadku indeksow wiekszych od 0x7f z tablic pobierane byly wartosci 'pokazywane' ujemnym indeksem (czyli w rzeczywstosci nie lezace w zadeklarowanym obszarze tablicy).
Pzdr, Maciek
Maciek denied rebel lies:
A gdzie tu niespodzianka?
W artykule <fhc7kh$474$ snipped-for-privacy@nemesis.news.tpi.pl> Maciek napisal(a):
Typ char może być tożsamy z signed char albo z unsigned char. To zależy od implementacji (w WINAVR wybiera się opcją -funsigned-char).
Jeśli (dla 8-bitowego typu char) signed char i = 0xFF; char a[2]; to a[i] oznacza to samo co a[-1] i odwołuje się (niepoprawnie) poza tablicę a.
BTW na AVR użycie indeksów unsigned char może dać lepszy kod (nie ma potrzeby znakowego rozszerzania bajtu do słowa).
M M pisze:
Według mnie przy takich problemach najprościej jest porównać pliki listingu (deasemblacji) i .map, wygenerowane przez obie wersje kompilatora. Optymalizer gcc dla AVRów od dłuższego czasu się nie zmienił, w pliku mapy zobaczysz właściwie tylko inną kolejność linkowania funkcji z bibliotek standardowych, nową sekcję do międzyskoków (wykorzystywaną praktycznie tylko w największych AVRach z Flashem 256KB), zmieniło się też położenie sekcji stałych umieszczanych w pamięci programu (np. makrem PSTR("ABC")). Oczywiście jeżeli korzystasz z własnego pliku sterującego mapą linkowania, wiele z tych zmian Cię nie dotyczy.
JS denied rebel lies:
No tak. Zapomniałem, choć używam gcc (:)
Uzytkownik "MoonWolf" snipped-for-privacy@polbox.com napisal w wiadomosci news:fhcepk$6ol$ snipped-for-privacy@news.onet.pl...
Masz racje - nigdzie. Ale ja akurat zwrocilem na to uwage dopiero przy przesiadce na nowsza wersje WinAvr. A typy zmiennych pozmienialem, bo nowszy kompilator "krzyczal" o niezgodnosci 'signed char' z 'unsigned char' (np. przy wywolaniach funkcji).
Pzdr, Maciek
Uzytkownik "Maciek" snipped-for-privacy@interia.pl napisal w wiadomosci news:fhe7km$fdj$ snipped-for-privacy@atlantis.news.tpi.pl...
witam. tak. i to chyba bedzie powod, ja tez bez zastanowienia zmienilem typy by uspokoic kompilator, :), i prawdopodobie moglo to powodowac nawet takie objawy jak mialem ja by sie troszke zastanowic, wrocilem jednak do starego kompilatora i nie mam czasu by sprawdzic na 100%. dzieki. pozdrawiam. Michal M.
U¿ytkownik "M M" <no_spa snipped-for-privacy@interia.pl.uk> napisa³ w wiadomo¶ci news:fhetp3$2ej$ snipped-for-privacy@atlantis.news.tpi.pl...
Moze jednak warto - w nowszym troszke mniej kodu wychodzi.
Pzdr, Maciek
JS pisze:
Przecież przy definicji unsigned char też odwołanie będzie poza tablicę a[]. Więc gdzie tu problem?
Pzdr
W artykule <473b1449$0$23012$ snipped-for-privacy@mamut2.aster.pl> Luk@sz napisal(a):
OK. Powinienem dać char a[256];
Dla indeksu i unsigned odwołanie będzie do ostatniego elementu, dla signed - przed pierwszy.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required