wersja mobilna | kontakt z nami

Osobliwości kompilatora AVR-GCC i mikrokontrolerów AVR (1)

Numer: Marzec/2017

Kompilator AVR GCC jest chętnie stosowany do kompilowania programów dla mikrokontrolerów AVR. Jak każdy kompilator ma swoje wady i zalety. Specyfika kompilatorów może być istotna, gdy program ma działać szybko lub zajmować mało miejsca w pamięci. Bałagan w definicjach rejestrów czy ich funkcjonalność zmieniana przez producenta w niektórych typach procesorów nie ułatwia pisania programów.

Pobierz PDFMateriały dodatkowe

Najwięcej materiałów do artykułu dostarczyło pisanie programu funkcjonującego z wykorzystaniem przerwań, emulującego układy 1-Wire pracujące w trybie overdrive. W tym trybie trzeba w ciągu maksymalnie 2 ms od opadającego zbocza sygnału odczytu wystawić transmitowany bit. Czas wykonania jednego rozkazu przy zegarze 16 MHz to około 0,0625 ms. Biorąc pod uwagę fakt, że gdy pisze się aplikację w GCC, przy wejściu w przerwanie operacje na stosie zajmują około 2 ms (na stos jest odkładana zawartość 20 rejestrów), wydaje się niemożliwe obsłużenie tego trybu. A jednak się udało, o czym dalej.

Zakres zmiennych

Wydawałoby się, że wynikiem mnożenia dwóch liczb unsigned int będzie unsigned long. Czy na pewno? Spróbujmy:

unsigned int a=10000, b=10;
unsigned long w;

Program działa poprawnie, jeśli wynikiem mnożenia jest liczba typu unsigned int. Gdy jest większy, nieoczekiwanie otrzymujemy dziwne rezultaty. Bliższe przyjrzenie się wynikom operacji w debuggerze ujawnia, że starsze bajty zmiennej są zerem. Jak rozwiązać problem? Trzeba wykonać jawną konwersję typu i operację zapisać tak:

w = (unsigned long)a * b;

Dlaczego tak niewielka zmiana spowodowała poprawne działanie programu? Otóż kompilator wykonuje następujące działania:

a * b -> w

A więc mnoży zmienną „a” przez zmienną „b”, zapisując wynik w zmiennej „a”, po przepisuje go do zmiennej „w”. Gdy zmienna „a była zadeklarowany jako unsigned int, kod wynikowy programu w asemblerze wyglądał następująco:

„w = a * b;”

1c74:   20 91 02 01     lds    r18, 0x0102
1c78:   30 91 03 01     lds    r19, 0x0103
1c7c:   80 91 00 01     lds    r24, 0x0100
1c80:   90 91 01 01     lds    r25, 0x0101
1c84:   ac 01           movw   r20, r24
1c86:   24 9f           mul    r18, r20
1c88:   c0 01           movw   r24, r0
1c8a:   25 9f           mul    r18, r21
1c8c:   90 0d           add    r25, r0
1c8e:   34 9f           mul    r19, r20
1c90:   90 0d           add    r25, r0
1c92:   11 24           eor    r1, r1
1c94:   a0 e0           ldi    r26, 0x00    ; 0
1c96:   b0 e0           ldi    r27, 0x00    ; 0
1c98:   80 93 05 02     sts    0x0205, r24
1c9c:   90 93 06 02     sts    0x0206, r25
1ca0:   a0 93 07 02     sts    0x0207, r26
1ca4:   b0 93 08 02     sts    0x0208, r27

Wyraźnie widać, że najstarsze bajty są wyzerowane. Gdy zmienną rzutujemy na unsigned int, wynik pracy kompilatora wygląda następująco:

„w = (long)a * b;”

1c74:   60 91 02 01     lds    r22, 0x0102
1c78:   70 91 03 01     lds    r23, 0x0103
1c7c:   80 e0           ldi    r24, 0x00    ; 0
1c7e:   90 e0           ldi    r25, 0x00    ; 0
1c80:   20 91 00 01     lds    r18, 0x0100
1c84:   30 91 01 01     lds    r19, 0x0101
1c88:   40 e0           ldi    r20, 0x00    ; 0
1c8a:   50 e0           ldi    r21, 0x00    ; 0
1c8c:   0e 94 4e 20     call   0x409c    ; 0x409c <__mulsi3>
1c90:   60 93 05 02     sts    0x0205, r22
1c94:   70 93 06 02     sts    0x0206, r23
1c98:   80 93 07 02     sts    0x0207, r24
1c9c:   90 93 08 02     sts    0x0208, r25

Użyta procedury mnożenia __mulsi3 jest dosyć długa, dlatego zainteresowanych zachęcam do obejrzenia wyniku kompilacji na własnym komputerze. Ważne, że procedura ta operuje na 32 bitach.

Przerwanie programowe

Mikrokontrolery AVR nie mają możliwości wywoływania przerwań z aplikacji użytkownika. Pomijam tu asemblerową instrukcję BREAK, której działanie nie jest szeroko opisane. Jeśli istnieje potrzeba wygenerowania takiego przerwania i mamy wolne wejście przerwań zewnętrznych, można poradzić sobie w następujący sposób:

Skonfigurować wejście INTx jako wywołujące przerwanie opadającym zboczem sygnału.

Ustawić pin jako wyjście.

Aby wywołać przerwanie, wykonać rozkaz PORTx &= ~_BV(y);. W programie obsługi przerwania wykonać PORTx |= _BV(y); i obsłużyć przerwanie. Rozwiązania tego używałem w celu emulowania impulsatora za pomocą UART obsługiwanego z terminalu na komputerze PC.

Przerwanie od WDG

W niektórych mikrokontrolerach AVR układ czasowy watchdog (WDG) może generować przerwanie. Jeśli w obsłudze tego przerwania nie ustawimy flagi WDIE (kasowana automatycznie przez przerwanie od WDG), to kolejne zadziałanie WDG spowoduje restart CPU. Aby funkcjonalność przerwań od WDG zadziałała, nie może być ustawiony bit WDTON w bitach konfiguracyjnych. Funkcjonalność IRQ od WDG włączamy, ustawiając WDIE poleceniem WDTCSR |= (1<<WDIE);. Oczywiście, należy ustawić globalne zezwolenie na przerwania instrukcją sei(), w przeciwnym wypadku po dwukrotnym przepełnieniu timera nastąpi reset mikrokontrolera.

W przerwaniu od WDG możemy poznać adres, z którego program skoczył do obsługi IRQ. Każde CPU, skacząc do procedury obsługi IRQ, odkłada na stos adres powrotu, a niektóre także rejestr stanu. Dodatkowo jest zapamiętywany stan flagi „I”. Jeśli przerwanie jest zadeklarowane jako INTERRUPT lub ISR z atrybutem NOBLOCK, pierwszym rozkazem w obsłudze przerwań jest sei(). Umożliwia to obsługę kolejnego przerwania podczas obsługi aktualnego. Używając INTERRUPT, trzeba pamiętać, że nie wszystkie przerwania po wejściu do procedury obsługi automatycznie zerują bit powodujący ich zgłoszenie, dlatego użycie  INTERRUPT dla przerwań od UART czy wejścia INT wyzwalanego poziomem spowoduje przepełnienie stosu. Jeśli zależy nam na obsłudze innych przerwań podczas obsługi przerwania od np. UART, to można to zrobić na przykład tak:

SIGNAL ( INT_UART_vect )
{
    unsigned char a, b, d;
    a = UCSRA;
    b = UCSRB;
    d = UDR;
    sei();
//tu obsługa IRQ

}

Instrukcja sei() pojawia się po odczycie rejestru UDR. Odczyt UDR kasuje flagę RXC (UDRE), dlatego kolejne przerwanie od UART nie będzie wywołane (chyba że pojawi się kolejny znak). Rejestry UDRa, UDRb, UDRc muszą być zapamiętane przed odczytem UDR, ponieważ tak jak rejestr UDR, flagi RXB8 (błędów) są zaopatrzone w FIFO (w AVR – 2 bajty).

Trochę odbiegliśmy od głównego tematu. Jak więc poznać adres, z którego nastąpił skok do obsługi przerwania? Należy odjąć od wskaźnika stosu (SP) 2 lub 3 bajty. Tu należy wiedzieć, że adres powrotu dla mikrokontrolerów AVR z pamięcią Flash większą niż 128 kB jest 3-bajtowy. Niestety, zanim zostanie wykonany kod obsługi przerwania, kompilator odłoży na stos rejestry używane w przerwaniu (chyba że użyjemy flago NAKED). To, ile rozkazów push zostanie użytych, zależy od kodu procedury przerwania. Nie ma tu uniwersalnej metody – należy obejrzeć wynik kompilacji w asemblerze i wpisać odpowiednią wartość. Na szczęście, jeśli nie będziemy modyfikować naszej procedury, liczba rozkazów push nie zmieni się. Jako pierwszej instrukcji obsługi przerwania można by oczywiście użyć rozkazu nop(), w obsłudze przerwania odliczyć liczbę rozkazów push i zmodyfikować wskaźnik stosu. Można też użyć atrybutu ISR_NAKED. Wtedy rejestry nie będą odkładane na stos. Z procedury przerwania nie można wyjść, ponieważ program główny „pójdzie w maliny” z powodu zmiany stanu rejestrów. Ponadto, samemu trzeba by procedurę zakończyć rozkazem reti(). Przykładową procedurę obsługi przerwania od czasomierza WDG pokazano na listingu 1.

Uruchomienie WDG przebiega w następujący sposób:

InitWdgI(WDTO_500MS, &IrqWdg); // Inicjowanie przerwania od WDG
sei();  // sei() konieczne, aby działały przerwania; w przeciwnym
       //wypadku, po 2-krotnym przepełnieniu timera WDG, nastąpi
       //restart mikrokontrolera

Deklaracja #define WDGI_NAKED zmniejszy rozmiar kodu wynikowego procedury i wywoła reset po obsłudze przerwania od WDG.

W funkcji InitWdgI() adres funkcji użytkownika nie jest konieczny – można wpisać zero. Nie ma to jednak większego sensu, bo przeważnie chcemy poznać adres, na którym zadziałało przerwanie. Funkcja użytkownika może wyglądać następująco:

void IrqWdg()
{
    PrintString_P( (char*)PSTR(CRLF”********”CRLF) );
    if ( IdSoftReset == DEF_RST_SOFT )
        PrintString_P( (char*)PSTR(„Soft Reset”) );
        else PrintString_P( (char*)PSTR(„Wdg Error”) );
    PrintLongHex( adrCallWdg );
    PrintString_P( (char*)PSTR(CRLF”********”CRLF) );
}

Funkcja odróżnia przerwanie wywołane przez WDG od resetu programowego, w tem celu należy zadeklarować  IdSoftReset (najlepiej jako long). W procedurze main() nadać wartość zmiennej IdSoftReset:

IdSoftReset =  DEF_RST_SOFT ^ 0xFFFFFF;

Aby wywołać reset programowy, należy wykonać:

IdSoftReset =  DEF_RST_SOFT; while( true ) ;

Jeśli nie korzystamy z funkcji IrqWdg(), adres, z którego nastąpiło zadziałanie WDG, będzie znajdował się w zmiennej adrCallWdg. Adres będzie ważny, jeśli flaga WDFR w MCUSR będzie ustawiana.

Adres powrotu z funkcji

Podczas debugowania przydatna jest znajomość adresu powrotu z funkcji. W asemblerze jest to proste – wystarczy sprawdzić adres PC na stosie. W języku C, zanim zostanie wykonany pierwszy rozkaz funkcji na stosie mogą być odkładane rejestry. Aby nie sprawdzać po każdej kompilacji liczby odłożonych danych, można posłużyć się fragmentem kodu umieszczonym pomiędzy „gwiazdkami” na list. 1. Ten fragment można zawrzeć w funkcji, ale należy pamiętać, że adres powrotu zwiększy się o adres powrotu i ewentualnie odkładane rejestry. Odkładania adresu powrotu można uniknąć, deklarując funkcję jako inline.

Wywołanie funkcji nie musi powodować odłożenia adresu powrotu na stosie. Nie zostanie on zapamiętany, jeśli:

- Funkcję zadeklarowano jako inline.
- Funkcji użyto tylko raz (!).
- Jest to ostatnie (niekoniecznie) użycie funkcji w kodzie programu.

Skupmy się na drugim przypadku, dlaczego tak może się stać? Przy włączonej optymalizacji, jeśli funkcja jest użyta raz, kompilator zamiast skompilować kod C:

    main()
    {
    // polecenia main
        funkcja()
    // rozkazy main
    }

    void funkcja()
    {
    //rozkazy funkcji
    }

do postaci symbolicznej:

    main:
    …rozkazy main…
    call funkcja
    …rozkazy main…

    funkcja:
    …rozkazy funkcji…
    ret

wygeneruje kod asemblerowy w postaci:

    main:
    ...rozkazy main
    ...rozkazy funkcji
    ...rozkazy main

Natomiast w trzecim wypadku, program w języku C w postaci:

    main()
    {
    ...rozkazy main
        funkcja()
        funkcja()
       funkcja()
    }

    void funkcja()
    {
    ...rozkazy funkcji
    }

skompiluje do:

    main:
    ...rozkazy main
        funkcja()
        funkcja()
    funkcja:
    ...rozkazy funkcji
    ret

Sprintf i scanf

Funkcja sprintf operuje na argumentach typu int. Jak wyświetlić zmienną typu long? Rozwiązaniem jest własna procedura konwersji zmiennej long na łańcuch znaków. Pokazano ją na listingu 2. Przytoczone tu funkcje działają dość szybko i zajmują mało miejsca w pamięci Flash, ponieważ nie obsługują formatowania stringów. Funkcje scannf_P i sprintf_P w drugim parametrze (string w pamięci Flash umieszczony za PSTR) adresują tylko 64 kB Flash (nie ustawiają RAMPZ). Na szczęście kompilator wszystkie stałe umieszcza na początku pamięci Flash, więc nie stanowi to problemu. Kłopoty zaczynają się, gdy przesuniemy sekcję „.text” na adres ponad 64 kB. Rozwiązaniem jest zastąpienie scannf_P i sprintf_P przez scannf i sprintf. Zajmą one więcej pamięci RAM, ale procesory z Flash mieszczącą więcej niż 64 kB danych mają jej dużo, a bootloader potrzebuje niewiele pamięci RAM.

Porównanie bitów

Porównanie bitów przez

if( (bajt1 & _BV(bit1)) == (bajt2 & _BV(bit2)) )
{
    ….
}

najczęściej nie zadziała, bo wynikiem fałszu jest zawsze zero, ale prawdą wynik różny od zera, który to – zwłaszcza przy sprawdzaniu stanu bitu w peryferiach – będzie zależał od numeru sprawdzanego bitu/bitów. Aby porównanie zadziałało prawidłowo, należy je wykonać w następujący sposób:

if ( ((bajt1 & _BV(bit1) == 0) && ((bajt2 & _BV(bit2)) != 0) ||
      ((bajt1 & _BV(bit1) != 0) &&  ((bajt2 &_BV(bit2)) == 0) )
{
    ….
}

Zużycie pamięci RAM

Gdy stos mikrokontrolera zajmie obszar przeznaczony na dane, praca aplikacji zakończy się w trudno przewidywalny sposób. Warto więc wiedzieć, jakie jest bieżące i maksymalne zużycie pamięci. Przykładowy sposób określenia zużycia pamięci pokazano na listingu 3. Deklarację zmiennej DnoStosu należy umieścić bezpośrednio przed main(). Zagwarantuje to, że zmienna będzie zadeklarowana jako ostatnia i będzie zajmowała najwyższy adres w RAM. Nieprzypadkowo też jest to zmienna z atrybutem NOINIT, „zwykła” zmienna zadeklarowana przed main() wcale nie musi być umieszczona w pamięci jako ostatnia. Czy faktycznie jest ona ostatnia można upewnić się sprawdzając wyniki kompilacji.

Oszacowanie częstotliwości
taktującej mikrokontroler

Do czego może przydać się ta funkcja? Zdarza się pomylić kwarc. W dobie wszechstronnej miniaturyzacji napisy są coraz trudniejsze do odczytania. Zdarza się też trafić na kwarc overtonowy, przeznaczony do pracy na częstotliwości harmonicznej. W takim przypadku częstotliwość podstawowa jest kilkukrotnie niższa. W takiej sytuacji program może poinformować o złej częstotliwości taktującej.

Jeśli w mikrokontrolerze mamy dostępny sygnał wzorcowy, to nie ma problemu z policzeniem, ile rozkazów wykona mikrokontroler w zadanym czasie. Co jednak, gdy takiego sygnału nie ma? Jeśli mamy wolne wyprowadzenie mikrokontrolera, można do niego dołączyć obwód RC i zmierzyć czas ładowania się kondensatora. Zależność ta jest nieliniowa, ale nie zależy nam na dokładnym pomiarze, lecz oszacowaniu częstotliwości, a właściwie stwierdzeniu zbyt dużej jej odchyłki. Bez obwodu RC można pokusić się o pomiar pojemności własnej niepodłączonego wyprowadzenia. Co jeśli, wszystkie piny są wykorzystane? Manipulując bitami konfiguracyjnymi, można by przełączyć taktowanie na wewnętrzny generator RC, dokonać pomiaru i operację powtórzyć z zegarem zewnętrznym. Niestety, operacji takiej nie należy przeprowadzać zbyt często, bo przekroczymy liczbę dopuszczalnych zapisów do pamięci Flash.

Na listingu 4 pokazano procedurę, która nie wymaga zewnętrznych sygnałów wzorcowych i można ją zaimplementować w każdym współczesnym mikrokontrolerze. W tym celu wykorzystamy wewnętrzny generator RC, który służy do taktowania operacji na EEPROM, ale nie będziemy mierzyć czasu zapisu, a właściwie kasowania komórki tej pamięci, tylko skorzystamy z usług watchdog, taktowanego tym samym sygnałem. Dokładność tego sygnału nie jest rewelacyjna, zależy od wielu czynników, między innymi od napięcia zasilania, ale do naszych celów jest wystarczająca. W mikrokontrolerach z rozbudowanym układem WDG, który może generować przerwanie po przepełnieniu timera, pomiar jest stosunkowo prosty, ale stosując się do kilku reguł, można skorzystać z WDG każdego mikrokontrolera.

Funkcja fcpuCalculate zwraca częstotliwość taktowania mikrokontrolera podzieloną przez 1000. W zmiennej fcpuDeviation zwraca odchyłkę od częstotliwości nominalnej, dla której skompilowano kod – stała F_CPU. Dokładność obliczeń można zwiększyć, wydłużając czas pomiaru. Przy zmianach trzeba zadbać o to, aby nie przekroczyć zakresu zmiennych. Funkcja wykonuje się 30 ms, czas ten jest tak długi tylko przy pierwszym uruchomieniu mikrokontrolera po włączeniu zasilania.

Sławomir Skrzyński, EP

Pozostałe artykuły

Bezpieczeństwo elektryczne urządzeń (1)

Numer: Kwiecień/2017

100-procentowe zabezpieczenie projektowanego przez siebie urządzenia przed wszystkimi zagrożeniami, które mogą wystąpić w czasie jego eksploatacji, raczej nie jest możliwe. Jednak jako świadomi konstruktorzy powinniśmy redukować wpływ pewnych typowych zagrożeń, dbając o bezpieczeństwo urządzenia oraz jego użytkownika.

SKEDD - nowa koncepcja połączeń rozłącznych do PCB

Numer: Kwiecień/2017

Wśród technik montażu złączy na PCB doskonale znane są: lutowanie na fali, montaż THR, montaż SMD oraz wciskanie prasą. Technika bezpośredniego przyłączania do płytki, nazwana SKEDD, to krok naprzód w kierunku poszukiwania nowatorskich rozwiązań. Płytki drukowane są często określane mianem systemu nerwowego urządzenia elektronicznego. Dzięki postępowi technologicznemu stały się doskonalsze, bardziej dopasowane do potrzeb. ...

Jak odnaleźć wymagania EMC dla różnych typów urządzeń? Przykład: pulsometr z modułem Bluetooth

Numer: Kwiecień/2017

Redakcja Elektroniki Praktycznej zaproponowała mi napisanie artykułu dotyczącego wymagań EMC dla różnych typów urządzeń. Temat mnie zainteresował, więc postanowiłem podnieść rękawicę i zacząć nietypowo, czyli od rozwiązania konkretnego przykładu, aby w przyszłości przejść do formułowania zasad ogólnych (od szczegółu do ogółu).

Aplikacja do sterowania zasilaczem powerBank

Numer: Kwiecień/2017

W Elektronice Praktycznej 7/2015 opisałem projekt zasilacza arbitralnego, który ma możliwość generowania programowalnych przebiegów napięciowych oraz rejestrowania parametrów obciążenia, co pozwala na wyznaczanie charakterystyk odbiornika i testowanie zasilanych urządzeń w symulowanych warunkach rzeczywistych. Ten zasilacz ? powerBank ? jest obsługiwany za pomocą graficznego interfejsu użytkownika. Niemniej jednak obiecałem wtedy, ...

Identyfikacja elektroniczna. Wstęp i układy znaczników RFID oraz NFC. cz. 1

Numer: Kwiecień/2016

Wraz z postępem technicznym coraz więcej procesów uległo automatyzacji. Dotyczy to nie tylko przemysłu, ale również prób konstruowania maszyn (robotów i innych) mających ułatwić nam codzienne życie. Podstawową "umiejętnością", którą muszą mieć takie maszyny jest zdolność do rozpoznawania obiektów. W artykule omówimy podstawowe, mające zastosowanie praktyczne techniki pozwalające ocenić maszynie, z jakim przedmiotem ...

Mobilna
Elektronika
Praktyczna

Elektronika Praktyczna

Kwiecień 2017

PrenumerataePrenumerataKup w kiosku wysyłkowym

Elektronika Praktyczna Plus

lipiec - grudzień 2012

Kup w kiosku wysyłkowym