Tak działa. Można prosić o wytłumaczenie tego zapisu i dlaczego tak się dzieje w attiny .
[syntax=c]itoa (tym2, (char*)((int)bufor & 0xff), 10);[/syntax]
Tak się nie dzieje w attiny panie kochany - a TYLKO i WYŁĄCZNIE w ATtiny26 ... w innych prockach serii ATtiny nawet mniejszych jak ATtiny13 działa to poprawnie.
Wszystko z tego powodu, że biedny ATtiny26 (staruszek) ma niby babola .... "niby" Atmel stwierdził w nocie w erracie/aktualizacji że nie działa mu rozkaz "lpm Rd, Z+" w asemblerze. Usunięto go z listy instrukcji asm jak zęba
u tego staruszka
Natomiast po wykonaniu itoa() wywoływana jest funkcja strrev(), która odwraca kolejność bajtów bo itoa() układa je wspak na początku a strrev przywraca właściwy porządek ....
Ale wskaźnik stosu w ATtiny26 jest tylko 8 bitowy (w pozostałych prockach 16-bitowy) więc brak funkcji o której mowa wyżej powoduje, że źle jest generowany kod dzięki któremu są porównywane wskaźniki do stringa dla funkcji strrev(), która nomen omen jest napisana jako wstawka asemblerowa, która zawsze liczy na to, że będzie działać ten "wyrwany ząb" czyli rozkaz omawiany wyżej - w połączeniu z 8-bitowym wskaźnikiem stosu powoduje błąd, bo próba realizacji
Z = Z + 1;
prowadzi tak na prawdę do operacji:
Z = (Z + 1) & 0x00FF;
Stąd gościu, który wyśledził tego BUG'a w ATtiny26 ... śledząc żmudnie co dzieje się w asemblerze po kompilacji - w końcu doszedł do tego, żeby zrobić taki karkołomny zapis
[syntax=c](char*)((int)text & 0xff)[/syntax]
co oznacza, żeby kompilator zanim weźmie pod uwagę wskaźnik do tekstu (char*), najpierw uznał ten wskaźnik na tekst jako liczbę typu int zamaskowaną wartością 0xFF, żeby wzięta została tylko wartość młodszego bajtu i dopiero po tym, uznał to za wskaźnik na char*
co spowoduje, że kompilator tak wygeneruje kod w asemblerze, że weźmie sobie pod uwagę to jak prawidłowo porównać wskaźniki bez użycia lpm Rd, Z+ .... To tak ogólnie i obrazowo troszkę wyjaśniam bo trzeba byłoby rzeczywiście rzucać tutaj kupą tzw "asemblerowego mięsa" żeby pokazać o co chodzi...ale wszystko dość ciekawie opisane jest w wątku: https://www.mikrocontroller.net/topic/203143 gdzie widać w jaki sposób user o nicku Joachim rozpruwa krok po kroku temat
.... Gdzie m.inn twórcy AVR GCC mówią mu po drodze, że nie można albo nie opłaca się robić specjalnego wyjątku w kompilatorze żeby obejść tę niedogodność w ATtiny26 związaną z brakiem tego rozkazu asemblerowego - że to wina procka, że to babol w procku a on na końcu im udowadnia, że w sumie to nie do końca wina procka bo i bez tego rozkazu da się to zrobić i dochodzi w ostatnim poście jak ... i dalej już ciszaStatystyki: Napisane przez mirekk36 — 7 lip 2016, o 06:24
]]>