[es2]

Kod:

((uint16_t)currentOverflowCounter << 16)

zamiast

Kod:

((uint16_t)currentOverflowCounter * 65536)

nie działa,

GCC dla AVR ma wiele ułomności. Double to float, przesuwanie w lewo w granicach 16 bit, kojarzę jakieś problemy z przeniesieniem z bitu 15 na 16 przy niektórych operacjach arytmetycznych. sprintf i scanf tylko na 2 bajtach co potrafi dobić. Kiedyś long long to był long. Pewnie cały dzień można by wymieniać. Na każdy problem jest rozwiązanie ale ile to kosztuje nerwów to inna sprawa. Kiedyś zrobiłem takie "cóś":

Kod:

word wordH, wordL;
ulong wynik = 0;


    p= (word*)(&wynik);        // Wskaźnik word na wynik o rozmiarze ulong
    *p++ = wordL;            // zapisujemy młodszy uint
    *p = wordH;                // oraz starszy w wyniku


    return( wynik );

Dużo szybsze i zajmuje mniej miejsca niż mnożenie bo to tylko podstawianie bajtów. Można zrobić na uniach ale pewnie nie będzie szybsze, co najwyżej może się bardziej podobać.

Co ciekawe, ograniczeń, o których pisałem nie ma w GCC dla ARM. Im bardziej poznawałem AVR-GCC, tym bardziej mnie denerwował, a poznałem chyba dobrze. Robiłem wstawki ASM (w ARM nie ma takiej potrzeby) aby obsłużyć slave 1-Wire overdriwe w przerwaniu (trzeba odpowiedzieć w ciągu 1us). To chyba było największe wyzwanie w sensie czasu działania funkcji. Z konieczności poznałem sekcje "ini" z ciekawości "fini", zapis flach, który można zrobić tylko z sekcji boot, zapis fuses przez aplikację, bootloader, własne sekcje aby zmusić kompilator do zapisu pewnych rzeczy w ściśle określonym miejscu.
W sumie trochę niepotrzebnie, bo teraz robię na ARM.

Jak już pozna się ARM to nie chce się wracać do AVR. Większe możliwości, najczęściej niższa cena, kilka razy tańsze narzędzia, a program pisze się dużo szybciej. Nowe uC Microchip trochę ułatwią pracę (liniowa przestrzeń adresowa) ale nie mają szansy zagrozić ARM. Patrząc na to co się dzieje w świecie uC, wszystko idzie w kierunku ARM i raczej nie ma szans aby to się zmieniło.