Witam zakupiłem ostatnio attiny 26 i mam problem z wyświetlaniem liczb na LCD (HD44780).
Po poleceniu

Na wyświetlaczu widzę 421. Na innych prockach jest ok.
Po podłączeniu do attiny nadajnika nrf24l01 wysłaniu zmiennej zamienionej itoa "tym2=124" do innego procka dane też są odwrócone dlaczego?
Wina procesora może to chińczyk, albo coś w eclipsie? Pomiary odczytane z ADC też są wyświetlane od tyłu.

Nie mam ATtiny26, by to sprawdzić, ale podobno takie oto rozwiązanie rozwiąże twój problem z użyciem itoa():

Tak działa. Można prosić o wytłumaczenie tego zapisu i dlaczego tak się dzieje w attiny .

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



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ż cisza

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Po prostu XORnij liczbę przez 0xFF

------------------------ [ Dodano po: 13 minutach ]

A przy 10 bitowej XORnij przez 0x3FF

_________________
Situs != Situs