es2 pisze: ↑06 kwie 2022, 17:47
Co do R0, nie zawsze SREG trzeba zachowywać!
Zgoda – o ile nie ma instrukcji, które modyfikują SREG. Ten kod powinien być generowany tylko jeśli takie są, a nie zawsze.
es2 pisze: ↑06 kwie 2022, 17:47
Ponadto, czemu nie robi tego R1?
Też racja. Mogliby użyć R1 a potem wyzerować, byłby jeden push mniej.
es2 pisze: ↑06 kwie 2022, 17:47
Co do R1, nie znasz kompilatora! W R1 jest przechowywana wartość ZERO. Nie wiem czemu tak głupio wybrano rejestr dla ZERO. Czy nie mógł być R2? Zapytasz, co za różnica, R1 czy R2? Otóż bardzo duża. Rejestru z wartością ZERO kompilator "nie tyka" ale R1 używa operacja mnożenia albo dzielenia (sprawdź).
Chodziło mi o to, po co zerować rejestr, który nie jest używany.
Co do R1 – gdzieś mi się kiedyś przewinęło, że wybrali R1 jako __zero_reg__, zanim wprowadzono operację mnożenia do AVR. Nie wiem na ile to prawda.
es2 pisze: ↑06 kwie 2022, 17:47
Teraz wiesz czemu R1 jest zerowany przed wyjściem z przerwania?
Pytanie, dlaczego jest zerowany, mimo, że w przerwaniu nie był użyty?
To ewidentny błąd!
Tak, dokładnie o tym mówię.
es2 pisze: ↑06 kwie 2022, 17:47
Gdy użyjesz atrybutu NAKED, to w 99% przypadków program się "wysypie". Napisz skomplikowany kod przerwania, nie tylko R0 i R1 nie będzie odkładane na stos ale także inne używane. Efekt wiadomy.
Atrybutu NAKED używam rzadko i w wyjątkowych sytuacjach, gdy kod jest na tyle krytyczny, że piszę go jako wstawki assemblerowe. Nie pamiętam, kiedy ostatnio go użyłem.
es2 pisze: ↑06 kwie 2022, 17:53
Użyj kompilatora w wersji, której ja używałem.
Użyj jeszcze starszego i "long long" będzie tym samym co "long" tak jak zdaje się do dziś "double" to "float" - kolejna niedoróba.
Dobrze przynajmniej, że to poprawili.
es2 pisze: ↑06 kwie 2022, 17:53
Próbowałeś przesunąć o 32 bity lub więcej? Pewnie to jeszcze nie działa.
W zasadzie nigdy nie zdarzyło mi się używać (ani potrzebować) na AVR liczb 64-bitowych… ale to prawda, jeśli standard na to pozwala, to powinno to działać.
es2 pisze: ↑06 kwie 2022, 18:38
Temat błędów Arduino, AVR to temat rzeka. Warto pisać do AVT, mogę zająć się tematem. Daję co mam.
Dzięki.
Ja generalnie Arduino nie znam – jak weszło, to już znałem AVR na tyle, że do niczego go nie potrzebowałem (przerzuciłem się na AVR w 2006 r., wcześniej używałem MCU w rdzeniem '51 i pisałem na nie w assemblerze). Widziałem za to trochę kodu bibliotek dla Arduino – na tyle, żeby skutecznie się zrazić.
es2 pisze: ↑06 kwie 2022, 18:42
Ty nie masz a ja mam. Na AVR pracowałem około 10 lat, na STM32 5lat.
Znam wiele osób, które przeszły z AVR na ARM, nie znam
ANI JEDNEJ, która by
wróciła z ARM na AVR.
Nie neguję tego, że STMy są w wielu zastosowaniach lepsze, ale czy we wszystkich? Najmniejsze projekty robiłem na ATtiny4 i podobnych (malutki AVR w obudowie SOT23-6). Zadania miały na tyle prymitywne, że gdyby nie zależało mi na miejscu, to pewnie nie zaprzęgałbym do nich MCU, tylko zrobiłbym to na piechotę, na bramkach. Nie wiem, czy jest odpowiednik z rodziny STM32, który byłby do tego tańszy.
Z drugiej strony wszystko, o czym mówię, to były jedynie projekty hobbystycznie. Zawodowo mogę powiedzieć, że od 11 lat programuję ARMy, ale będzie to półprawda – tak, mój kod chodzi na rdzeniu ARM, ale to są ogromne projekty, OS jest dostarczony przez osobny zespół (przez pewien czas był własnościowy, teraz jest to zmodyfikowany Linux), nad nim jest cała ogromna warstwa abstrakcji i bibliotek, więc o ile kod chodzi na ARMach, to nie dotyka on bezpośrednio żadnych peryferiów ani nie bierze pod uwagę architektury procesora. W zasadzie to jest też powodem mojego niezadowolenia z obecnej pracy – ja chciałbym być właśnie w teamie odpowiedzialnym za OS, a nie za aplikacje.
Jeden z kolegów wypowiadających się w wątku wie, o czym mówię, bo pracował ze mną nad tymi aplikacjami (nie wiem, czy życzy sobie, żeby wskazać go konkretnie, dlatego nie wskazuję).
W zasadzie najbliższą styczność z ARMem miałem, gdy postanowiłem uruchomić współczesnego (wtedy 4.x) Linuksa na zabytkowym sprzęcie i okazało się, że kompilacja dla targetu ARMel nie ruszy, bo użyty w urządzeniu StrongARM nie obsługuje trybu thumb (który nie był używany przez binarki, ale nieobecna w związku z brakiem trybu thumb instrukcja BX już tak). Zaemulowałem ją w kernelu, ale projekt i tak zarzuciłem ze względu na sprzętową niemożliwość zrobienia porządnego usypiania (Linux był uruchamiany z RAMu, ale procesor po wybudzeniu skakał pod adres, który był fizycznie przypisany do ROMu, w którym był Windows CE) – i tak się póki co skończyła moja przygoda z ARM.
Wydaje mi się (bo nie znając STM32 wiedzieć tego nie mogę), że wszystko ma swoją niszę i ciężko jest powiedzieć, że jedna rodzina jest obiektywnie, w każdym zastosowaniu, lepsza od drugiej (podobnie jest zresztą z wieloma innymi rzeczami, choćby odwieczną walką Linux vs Windows). Czy może akurat w tym przypadku się mylę? Czy AVRy uważasz za bezwarunkowo złe lub przestarzałe, a ich popularność za zrządzenie losu?
Programowanie to jest w zasadzie odrębna, szeroka dziedzina wiedzy. Nie wiem, czy da się nauczyć programowania z kursu. Na pewno da się za to nauczyć szczegółów konkretnej platformy.