Statystyki: Napisane przez andrews — 8 paź 2018, o 18:56

Statystyki: Napisane przez Januszkk — 7 paź 2018, o 19:30

Statystyki: Napisane przez mopsiok — 4 cze 2017, o 15:21

andrews

Statystyki: Napisane przez andrews — 18 gru 2016, o 09:37

Statystyki: Napisane przez IUVOit — 17 paź 2016, o 07:44

Statystyki: Napisane przez PITERK — 15 paź 2016, o 23:05

Statystyki: Napisane przez j23 — 15 paź 2016, o 21:36

Statystyki: Napisane przez andrews — 15 paź 2016, o 16:49

Statystyki: Napisane przez Daro69 — 15 paź 2016, o 15:17

Statystyki: Napisane przez SIND — 15 paź 2016, o 14:40

Statystyki: Napisane przez maverick_as — 14 paź 2016, o 21:55

Statystyki: Napisane przez andrews — 14 paź 2016, o 19:33

Statystyki: Napisane przez MirkoT — 14 paź 2016, o 19:21

Statystyki: Napisane przez mirekk36 — 14 paź 2016, o 19:21

• Zasadność mieszania kodu ASM i C
  
  Właściwie to potrzeba wstawiania kodu asemblera do kodu w języku C nie zdarza się zbyt często. Obecnie kompilatory C potrafią naprawdę bardzo dobrze optymalizować kod. Zwykle robią to równie dobrze lub nawet lepiej niż programista, szczególnie w przypadku tych bardziej skomplikowanych funkcji.
  
  Zdarzają się jednak sytuacje, kiedy (moim zdaniem) takie wstawki mają sens. Przypuśćmy przykładowo, że potrzebujemy wydajnej (szybkiej) funkcji lub procedury obsługi przerwania, w której optymalnym typem danych będzie liczba całkowita np. 40-bitowa (5 bajtów). Język C nie wspiera wprost operacji na takich liczbach.
  
  Można wprawdzie zastosować typ nadmiarowy 64-bitowy (8 bajtów zamiast 5), ale to spowoduje (mowa oczywiście o mikrokontrolerze 8-bitowym), że każde ładowanie zmiennej z pamięci do rejestrów i odwrotnie, wszelkie operacje dodawania, odejmowania, porównania i logiczne (nie wspominając o ewentualnej konieczności maskowania nieużywanych bajtów) będą zajmowały kilka (3, 6 lub nawet 9) taktów więcej, niż byłoby to konieczne dla operacji na pięciu bajtach, zamiast na ośmiu. W przypadku operacji mnożenia lub dzielenia te różnice mogą sięgać nawet kilkudziesięciu taktów, szczególnie w mikrokontrolerach nie obsługujących instrukcji mul, muls itp.
  
  Można też ewentualnie próbować obejść problem stosując jakieś triki ze strukturami i/lub uniami i/lub tablicami, ale to z kolei gmatwa kod i w dodatku wcale nie daje gwarancji, że będzie on optymalny. Dlatego (przynajmniej dla mnie) łatwiej rozwiązać zadanie za pomocą funkcji napisanej w asemblerze.
  
  Pewnie znalazłyby się jeszcze inne argumenty do stosowania wstawek, ale pozostawmy może te rozważania. Pokażę po prostu jak to technicznie wykonać, a każdy sam zdecyduje, czy i kiedy wstawki stosować. Oczywiście nie polecam nadużywania, ponieważ to na prawdę w niektórych przypadkach może nawet pogorszyć sprawę. Można najpierw poeksperymentować, pisząc takie same funkcje w języku C i w języku ASM sprawdzając, kto wygeneruje wydajniejszy kod wynikowy - programista ASM czy kompilator C.
  
  
• Preprocesor
  
  W AVR GCC pliki zawierające kod asemblera mają rozszerzenia *.s (małe s) lub *.S (duże S). Aplikacja tłumacząca kod asemblera na wynikowy kod maszynowy (avr-as.exe) podczas procesu budowania nie jest wywoływana bezpośrednio, lecz poprzez aplikację avr-gcc.exe, która przed uruchomieniem avr-as.exe decyduje o użyciu lub nie użyciu preprocesora. Kiedyś decyzja ta podejmowana była właśnie na podstawie rozszerzenia pliku. W przypadku dużego S preprocesor był używany, a w przypadku małego s – nie.
  
  Podobno w systemach operacyjnych, które nie biorą pod uwagę wielkości liter w nazwach plików (np. Windows) były z tym jakieś problemy, więc z tego i/lub z innych powodów zasada ta została zmieniona. Obecnie opcja programu avr-gcc.exe
  -x assembler
  oznacza przekazanie pliku bezpośrednio do asemblacji, natomiast
  -x assembler-with-cpp
  wymusza wcześniejsze użycie preprocesora.
  
  Dlaczego właściwie preprocesor C ma przetwarzać plik z kodem ASM? Otóż skoro już miksujemy kod C i ASM, to przecież fajnie byłoby mieć pewne zdefiniowane stałe w programie dostępne jednocześnie w obu kodach. Trochę niewygodnie byłoby definiować stałą w dwóch miejscach (ryzyko pomyłki) i później jeszcze pamiętać, żeby ją w razie potrzeby zmienić w dwóch miejscach. Program asemblujący nie rozumie jednak tych wszystkich komentarzy, dyrektyw typowych dla języka C i będzie generował błędy składni. Jednak dzięki preprocesorowi możemy dołączyć ten sam plik nagłówkowy do obu kodów, a preprocesor przed asemblacją pliku z kodem ASM zamieni wszystkie symbole na ich zdefiniowane wartości, po czym pousuwa dyrektywy preprocesora i komentarze C-style, dzięki czemu asembler będzie mógł prawidłowo wygenerować kod wynikowy.
  
  Preprocesor będzie więc nam potrzebny. W Atmel Studio 7 opcja użycia preprocesora jest domyślnie włączona zarówno dla plików typu „Assembler File (.s)” jak i dla „Preprocessing Assembler File (.S)”. Zgodnie z moją wiedzą nie można tej opcji wyłączyć inaczej, jak tylko poprzez ręczne edytowanie pliku Makefile. Dopóki więc będziemy używać automatycznie generowanego Makefile, nie powinno być problemów.
  
  W Eclipse preprocesor dla plików z ASM również powinien być domyślnie włączony, ale tutaj można go wyłączyć (choć my nie powinniśmy tego robić, chyba że mamy uzasadniony powód) wyłączając opcję „Use preprocessor” we właściwościach projektu:
  Project->Properties->C/C++ Build->Settings->zakładka Tool Settings->AVR Assembler->General (jeśli dołączymy kilka plików z kodem ASM, można tę opcję włączyć lub wyłączyć dla każdego pliku osobno we właściwościach pliku). Tutaj też nie powinno być problemu, dopóki ktoś tej opcji nie wyłączy.
  
  Mimo tego, że w obu środowiskach opcja preprocesora jest domyślnie włączona, postanowiłem o tym napisać, bo moim zdaniem dobrze jest wiedzieć o co chodzi z tym preprocesorem, szczególnie gdyby ktoś korzystał ze starszej wersji avr-gcc (w dodatku w systemie unixowym), ewentualnie uruchamiał kompilację z wiersza poleceń lub zechciał ręcznie edytować plik Makefile.
  
  
• Deklaracje kontra etykiety - używanie słowa kluczowego .extern
  
  Kompilator języka C wymaga od programisty precyzyjnego zadeklarowania zmiennych i funkcji. Potrzebuje tych informacji głównie w celu wygenerowania poprawnego kodu maszynowego (np. użycie właściwych instrukcji ASM w zależności od tego, czy zmienna całkowita jest ze znakiem, czy bez) oraz analizy semantycznej (np. kontrola typów podczas przypisania wartości jednej zmiennej do innej lub argumentów przekazywanych do funkcji).
  
  W przypadku asemblera to na programiście spoczywa obowiązek prawidłowej obsługi poszczególnych zmiennych, przekazywania prawidłowych argumentów do funkcji i wykonywania wszystkich innych zadań, które wykonuje kompilator C. Tutaj deklaracja zmiennej czy funkcji odbywa się poprzez nadanie im etykiet, które po zakończeniu budowania aplikacji stają się liczbami reprezentującymi adres komórki pamięci RAM lub FLASH. Etykiety nie mówią nic o typie zmiennej, o ilości i typach argumentów przekazywanych do funkcji, o wartości zwracanej przez funkcję. Ba, na podstawie samej etykiety nie można nawet stwierdzić, czy dotyczy ona zmiennej, stałej w pamięci programu czy może funkcji.
  
  Piszę o tym, ponieważ czasami spotykam próby deklarowania w pliku ASM konstrukcje tego rodzaju:
  .extern uint8_t nazwa
  co oczywiście nie ma większego sensu z dwóch powodów. Po pierwsze dla asemblera typ uint8_t i tak jest niezrozumiały - liczy się tylko słowo 'nazwa' będące dla asemblera etykietą (symbolem zmiennej). Po drugie samo użycie .extern jest przez GCC assembler akceptowane ze względu na kompatybilność z innymi asemblerami, nie jest jednak wymagane, gdyż program as (w naszym przypadku avr-as) traktuje wszystkie niezdefiniowane (w danym pliku) symbole jako .extern. Jeśli tylko w innym pliku naszego projektu lub w bibliotekach standardowych istnieje taki symbol (nazwa zmiennej lub funkcji), asemblacja przebiegnie bez błędów. Czy kod będzie działał prawidłowo, to już inna sprawa. Zależy to tylko od tego, czy programista nie pomyli np. typów zmiennych lub nazwy funkcji z nazwą zmiennej itp.
  
  
• Kwestia optymalizacji kompilatora C
  
  W czasie wykonywania każdej funkcji używane są (przynajmniej niektóre) rejestry - nie da się tego uniknąć. Należy więc liczyć się z tym, że zawartość niektórych rejestrów po wykonaniu funkcji może być inna, niż przed jej wykonaniem. Jeśli nie chcemy utracić zawartości jakichś rejestrów, należy je przed wywołaniem funkcji zapamiętać (np. na stosie) lub przechować te wartości w rejestrach, o których wiemy, że nie zostaną zmienione. Zapamiętywanie rejestrów na stosie wiąże się z zaangażowaniem pewnych zasobów (np. czasu procesora, zajętości RAM), więc lepiej więc tego unikać.
  
  Jedną ze strategii optymalizacyjnych kompilatora C jest właśnie takie dobieranie rejestrów w trakcie wykonywania programu, aby zminimalizować potrzebę zapamiętywania ich wartości. Niestety dołączając do projektu pliki ASM, w których "na sztywno" definiujemy rejestry użyte wewnątrz funkcji, zawężamy mu nieco pole manewru, przez co optymalizacja może być mniej skuteczna. Lepsze efekty pod tym względem daje inline assembler, gdyż pozostawia kompilatorowi dobór rejestrów wykorzystywanych we funkcji, jednak jak dla mnie jego składnia jest stosunkowo trudna, a kod mało czytelny i osobiście nie lubię go stosować, chyba że do definiowana naprawdę prostych funkcji.
  
  Istnieje jeszcze jeden problem podobnej natury. Zdarza się, że chcąc przyspieszyć dostęp do jakichś newralgicznych danych, zechcemy zarezerwować dla jakiejś zmiennej (lub kilku) rejestr (rejestry) mikrokontrolera. Można to oczywiście zrobić używając słowa kluczowego 'register' deklarując zmienną globalną (stosunkowo bezpiecznie jest używać do tego celu rejestry z zakresu r2-r7):
  [syntax=c]register uint8_t my_var asm("r2");[/syntax]
  jednak trzeba mieć świadomość, że to zablokuje dostęp do tego rejestru kompilatorowi, również utrudniając mu zadanie optymalizacji.
  
  Nie należy się tym oczywiście zniechęcać. Dobrze jest jednak o tym wiedzieć i pamiętać, aby nie przesadzać z długością i ilością funkcji pisanych w ASM oraz z ilością używanych w nich rejestrów.
  
  Na koniec mam też dobrą wiadomość. Przerwania w mikrokontrolerze występują w zupełnie przypadkowych momentach. Skoro nie da się przewidzieć tych momentów, kompilator i tak nie będzie mógł zoptymalizować kodu poprzez taki dobór rejestrów, by nie trzeba było ich zapamiętywać, gdyż (ze względu na tę przypadkowość) procedura obsługi przerwania musi zawsze zapamiętać wszystkie rejestry oraz rejestr statusowy SREG na początku procedury i przywrócić ich stan przed powrotem do programu głównego. Dlatego też napisanie procedury obsługi przerwania w ASM nie wpłynie na możliwości optymalizacyjne kompilatora C. Ewentualne użycie nadmiernej liczby rejestrów wpłynie jedynie na czas wykonania samej procedury, ale nie wpłynie na optymalizację kompilatora C. W związku z tym właśnie w procedurach obsługi przerwań będziemy mieli prawdziwe pole do popisu.

• Dołączanie plików z definicjami mikrokontrolera:
  
  
  Code:
      Atmel assembler (avrasm2)    |     GCC assembler (avr-as)
  ---------------------------------|--------------------------
  .include "m644pdef.inc"          | #include <avr/io.h>
  #include "m644pdef.inc"          |
  
  
• Nadawanie rejestrom nazw symbolicznych:
  
  
  Code:
      Atmel assembler (avrasm2)    |     GCC assembler (avr-as)
  ---------------------------------|--------------------------
  .def my_reg=r16                  | #define my_reg r16
                                   | my_reg = 16
  
  
• Definiowanie stałych:
  
  
  Code:
      Atmel assembler (avrasm2)      |     GCC assembler (avr-as)
  -----------------------------------|--------------------------
  .equ mask=0x21 ; nie można zmienić | #define mask 0x21
  .set mask=0x21 ; można zmienić     | .equ mask, 0x21
        ; w dalszej części programu  | .set mask, 0x21
  
  
• Wydobywanie poszczególnych bajtów ze stałych wielobajtowych.
  
  Kiedy zdefiniujemy stałą, której wartość wykracza poza 8 bitów, i będziemy chcieli ją załadować do kilku rejestrów, musimy wydobyć jakoś poszczególne bajty z takiej stałej. Służą do tego specjalne instrukcje dla preprocesora umieszczane w kodzie:
  
  
  Code:
     bity   |    Atmel assembler (avrasm2)    |    GCC assembler (avr-as)
  ----------|---------------------------------|------------------------------
    0 - 7   |   low(expression)               |   lo8(expression)
  ----------|---------------------------------|------------------------------
    8 - 15  |   high(expression)              |   hi8(expression)
            |   byte2(expression)             |
  ----------|---------------------------------|------------------------------
   16 - 23  |   byte3(expression)             |   hh8(expression)
            |                                 |   hlo8(expression)
  ----------|---------------------------------|------------------------------
   24 - 31  |   byte4(expression)             |   hhi8(expression)
  
  
  Przykład dla GCC assembler:
  
  [syntax=asm]#define moja_stala_32bit 1258453 ; hex 00 13 33 D5
  
  .section .text
  
  load_const_to_registers:
  ldi r16, lo8(moja_stala_32bit) ; r16 = 0xD5
  ldi r17, hi8(moja_stala_32bit) ; r17 = 0x33
  ldi r18, hlo8(moja_stala_32bit) ; r18 = 0x13
  ldi r19, hhi8(moja_stala_32bit) ; r19 = 0x00
  ret[/syntax]
  
  AVR GCC assembler oferuje dodatkowo instrukcje, które są przydatne przy pobieraniu adresu, gdyż przetwarzają adres bajtu we flash na adres słowa. Jest to przydatne na przykład, gdy chcemy wywołać funkcję poprzez wskaźnik za pomocą instrukcji ASM icall (indirect call) lub wykonać skok do określonej przez rejestr wskaźnikowy lokalizacji w programie za pomocą instrukcji ijmp (indirect jump).
  
  
  Code:
     bity   |    GCC assembler (avr-as)
  ----------|-----------------------------------------------------------
    0 - 7   |   pm_lo8(expression)
  ----------|-----------------------------------------------------------
    8 - 15  |   pm_hi8(expression)
  ----------|-----------------------------------------------------------
   16 - 23  |   pm_hh8(expression)  ; tylko w przypadku pamięci flash
            |                       ; powyżej 64K słów (128KB)
  
  
  Przykład:
  
  [syntax=asm].section .text
  
  funkcja_1:
  ldi zl, pm_lo8(funkcja_2)
  ldi zh, pm_hi8(funkcja_2)
  icall
  ret
  
  funkcja_2:
  ret[/syntax]
  
• Sekcje / segmenty.
  
  
  Code:
      Atmel assembler (avrasm2)      |     GCC assembler (avr-as)
  -----------------------------------|--------------------------
  .dseg                              | .section .data
  .cseg                              | .section .text
  .eseg                              | .section .eeprom
  
  
• Deklarowanie stałych w pamięci FLASH lub EEPROM:
  
  Oczywiście deklaracje należy umieszczać w odpowiedniej sekcji (.section .text lub .section .eeprom) oraz przed każdą deklaracją musi znajdować się etykieta, ponieważ tylko w ten sposób będzie można określić adres, pod którym dane się znajdują.
  
  
  Code:
      Atmel assembler (avrasm2)     |     GCC assembler (avr-as)
  ----------------------------------|--------------------------------------
                ciąg znaków (zakończony znakiem '\0')
  .db „example text”, 0             | .asciz „example text” // znak '\0'
                                    |       // jest dodawany automatycznie
  -------------------------------------------------------------------------
                           stałe 1-bajtowe
  .db 0, 0x26, 0b01101001           | .byte 0, 0x26, 0b01101001
  -------------------------------------------------------------------------
                           stałe 2-bajtowe
  .dw 0, 5846, 0x15AF               | .word  0, 5846, 0x15AF
  -------------------------------------------------------------------------
                           stałe 4-bajtowe
  .dd 15, 158933, 0x056A0D2E        | .long 15, 158933, 0x056A0D2E
  -------------------------------------------------------------------------
                           stałe 8-bajtowe
  .dq 689958741, 0x54A6d32F5011AE1C | .quad 689958741, 0x54A6d32F5011AE1C
  -------------------------------------------------------------------------
  
  
• Deklarowanie zmiennych w pamięci RAM:
  
  Tak jak poprzednio należy również pamiętać o umieszczeniu deklaracji w odpowiedniej sekcji (tym razem w .section .data) i opatrzeniu ich etykietami.
  
  
  Code:
      Atmel assembler (avrasm2)     |     GCC assembler (avr-as)
  ----------------------------------|--------------------------------------------------
                ciąg znaków (zakończony znakiem '\0')
  .byte 13  ; liczba oznacza ilość  | .asciz „example text” ; znak '\0'
            ; znaków w ciągu (+1)   |        ; jest dodawany automatycznie
  -------------------------------------------------------------------------------------
                         zmienne 1-bajtowe
  .byte 3  ; rezerwuje 3 bajty      | .byte 0, 0x26, 0b01101001 ;3 bajty
  -------------------------------------------------------------------------------------
                        zmienne 2-bajtowe
  .byte 6  ; rezerwuje 3*2 bajty    | .word  0, 5846, 0x15AF ; 3*2 bajty
  -------------------------------------------------------------------------------------
                        zmienne 32-bitowe
  .byte 12 ; rezerwuje 3*4 bajty    | .long 15, 158933, 0x056A0D2E ; 3*4 bajty
  -------------------------------------------------------------------------------------
                        zmienne 64-bitowe
  .byte 16 ; rezerwuje 2*8 bajtów   | .quad 689958741, 0x54A6d32F5011AE1C ; 2*8 bajtów
  -------------------------------------------------------------------------------------
  
  
  Tutaj jednak różnice nie dotyczą tylko składni. W przypadku projektu napisanego tylko w języku asemblera (Atmel assembler), z przyczyn oczywistych na programiście spoczywa obowiązek zainicjowania zmiennych odpowiednimi wartościami przed ich użyciem.
  
  Jeśli tworzymy projekt w języku C, to kompilator powinien zainicjować za nas zmienne zadeklarowane w kodzie ASM wartościami, które podamy przy deklaracji, np.:
  [syntax=asm].section .data
  my_asm_var: .byte 7 ; to polecenie rezerwuje miejsce dla zmiennej jednobajtowej
  ; i przypisuje jej wartość 7
  my_asm_var: .byte 7, 19, 121 ; to polecenie rezerwuje miejsce dla tablicy trzech
  ; elementów jednobajtowych i przypisuje im wartości 7, 19 i 121[/syntax]
  
  Z moich doświadczeń wynika jednak, że nie zawsze to robi (nie udało mi się znaleźć odpowiedzi na pytanie, czy jest to działanie zamierzone).
  
  Jeśli w kodzie C będziemy mieli zadeklarowaną co najmniej jedną zmienną statyczną z przypisaniem wartości niezerowej, np.:
  [syntax=c]// globalnie, czyli poza funkcjami
  uint8_t my_c_var = 5;
  // lub wewnątrz jakiejś funkcji
  static uint8_t my_c_var = 5;[/syntax]
  to kompilator C wygeneruje kod, który podczas startu mikrokontrolera zainicjuje zarówno zmienne zadeklarowane w kodzie C, jak i te zadeklarowane w kodzie ASM.
  
  Jeśli w kodzie C nie będziemy mieli zadeklarowanej takiej zmiennej, o której mowa powyżej, to kompilator zwyczajnie podczas startu mikrokontrolera wyzeruje tylko wszystkie komórki pamięci przeznaczone na zmienne (zadeklarowane w kodzie C), uwzględni wprawdzie miejsce na zmienne zadeklarowane w ASM, ale pominie tworzenie kodu inicjującego wartości.
  
  Jeśli wystąpi taka sytuacja, a zależy nam na zainicjowaniu zmiennych zadeklarowanych w kodzie ASM konkretnymi wartościami podczas startu, mamy dwa sposoby rozwiązania problemu:
  
  1. Przeniesienie deklaracji zmiennej do pliku C i tam przypisanie jej wartości (później opcjonalnie zadeklarowanie w pliku ASM jako .extern, choć nie jest to wymagane). Jeśli jednak nie będzie to zmienna współdzielona przez oba kody, nie jest to (moim zdaniem) dobre rozwiązanie, dlatego że zmienna używana tylko w pliku ASM powinna być tylko dla tego pliku widoczna (osiągalna).
  2. Dopisanie w kodzie ASM procedury wpisującej wartości do odpowiednich komórek pamięci, i umieszczenie jej np. w sekcji .init1, której kod jest wykonywany podczas startu mikrokontrolera, jeszcze przed wejściem do funkcji main().
     
     Przykład:
     [syntax=asm]#include <avr/io.h>
     ; ewentualne definicje
     
     .section .data
     ; zmienna, która ma być widoczna tylko w pliku asm
     moja_zmienna_asm: .byte 0x21
     
     ; zainicjowanie wartości zmiennej
     .section .init1,"ax",@progbits
     
     ldi r16, 0x21
     sts moja_zmienna_asm, r16
     
     .section .text
     
     .global moja_funkcja_asm
     
     moja_funkcja_asm:
     ; tutaj kod funkcji
     ret[/syntax]
  
  
• Operacje na rejestrach wejścia/wyjścia
  
  Mikrokontrolery posiadają szereg rejestrów specjalnych (tzw. rejestry wejścia/wyjścia, tutaj przyjmijmy skrótową nazwę: rejestry i/o), które służą do sterowania pracą wbudowanych w niego układów peryferyjnych. W mikrokontrolerach AVR 8-bitowych rejestry te są podzielone na dwie grupy.
  
  Pierwsze 64 rejestry mogą być odczytywane i modyfikowane zarówno przez instrukcje asemblera in oraz out operujące na przestrzeni adresowej i/0 jak i poprzez instrukcje load oraz store operujące na przestrzeni adresowej pamięci danych SRAM. Oczywiście nie ma takich instrukcji asemblera load oraz store. Pod tym pojęciem rozumiem tutaj wszystkie instrukcje czytające z pamięci (np. ld, lds) jak i zapisujące do pamięci (np. st, sts).
  
  Jeśli mikrokontroler jest rozbudowany na tyle, że musi mieć więcej niż 64 rejestry (maksymalnie może mieć 160 dodatkowych rejestrów), dodatkowe rejestry są osiągalne tylko poprzez instrukcje load oraz store.
  
  W tej chwili interesuje nas ta pierwsza grupa rejestrów. Ich adresy w przestrzeni i/o mieszczą się w zakresie 0-63 (0x00-0x3F heksadecymalnie), natomiast w przestrzeni adresowej pamięci mają adresy 32-95 (0x20-0x5F heksadecymalnie). Relacja między adresami jest taka, że te w przestrzeni pamięci są większe o 32 (0x20 heksadecymalnie) od tych w przestrzeni i/o.
  
  Z punktu widzenia szybkości wykonania programu korzystniejsze są instrukcje in oraz out, dlatego dobrze jest korzystać z nich (zamiast load oraz store) kiedy to tylko możliwe. Korzystając z Atmel assembler robimy to zwyczajnie pisząc np.:
  
  [syntax=asm]in r16, PINA[/syntax]
  
  GCC assembler korzysta jednak z tego samego pliku nagłówkowego (<avr/io.h>), co kompilator C. Wszystkie adresy rejestrów i/o są tam zdefiniowane jako adresy w przestrzeni adresowej pamięci. Kiedy kompilator uzna, że należy użyć instrukcji operujących na przestrzeni adresowej i/o, automatycznie odejmuje 0x20 od adresu podczas generowania takiej instrukcji. Niestety, jeśli piszemy wstawki asemblerowe musimy sami zadbać o użycie właściwego adresu. Jeśli więc chcemy użyć instrukcji in lub out (ewentualnie którejś z instrukcji operowania na bitach rejestru i/o, np. sbi), powinniśmy użyć do tego makra _SFR_IO_ADDR(), przykładowo:
  
  [syntax=asm]in r16, _SFR_IO_ADDR(PINA)[/syntax]
  
  Może to być nieco kłopotliwe, istnieje jednak sposób, aby pozbyć się tej niedogodności. Polega on na dodaniu na samym początku pliku ASM (jeszcze przed dyrektywą #include <avr/io.h>) definicji:
  
  [syntax=asm]#define __SFR_OFFSET 0
  #include <avr/io.h>
  ; pozostałe definicje dyrektywy
  ; jakiś kod
  in r16, PINA ; bez konieczności użycia _SFR_IO_ADDR()
  ; reszta kodu[/syntax]
  
  We wszystkich przedstawionych tu przykładowych fragmentach kodu zostało przyjęte, że powyższa definicja została umieszczona na początku pliku.

• Przekazywanie argumentów do funkcji
  
  W języku C funkcje mogą (choć nie muszą) przyjmować argumenty, czyli innymi słowami jakieś dane, którymi będą operować (wykonywać jakieś obliczenia, porównania itp.). Przekazanie argumentu do funkcji polega na podaniu ich w nawiasie po nazwie funkcji.
  
  W języku ASM samo wywołanie jest stosunkowo proste. Służy do tego celu np. instrukcja call, która ma jeden operand. Tym operandem jest etykieta, która wyznacza adres początku funkcji (dokładniej adres słowa w pamięci FLASH, w którym znajduje się pierwsza instrukcja funkcji).
  
  Skoro instrukcja call ma tylko jeden operand, to jak przekazać argumenty do funkcji?
  Można to zrobić na przykład w taki sposób:
  - najpierw do wybranych rejestrów wprowadzić dane, które chcemy przekazać do funkcji,
  - później wywołać funkcję np. za pomocą instrukcji call,
  - wywołana funkcja odczytuje dane z wybranych rejestrów i wykonuje na nich wymagane operacje.
  
  Jeśli wywoływana funkcja jest również napisana przez nas w ASM, to możemy do tego celu wyznaczyć dowolne rejestry wedle uznania. Wystarczy, że funkcję napiszemy tak, aby czytała dane z właściwych rejestrów. Jeśli jednak w pliku ASM wywołujemy funkcję napisaną w języku C, musimy wiedzieć, w których rejestrach funkcja ta oczekuje argumentów, ponieważ nie my o tym decydujemy, tylko kompilator.
  
  Na szczęście kompilator C stosuje pewne stałe reguły określające, w których rejestrach mają być przekazywane argumenty do funkcji. Zostały do tego celu wyznaczone rejestry r25 - r8. Rejestry są pogrupowane w pary. Najmniej znaczący bajt argumentu jest zawsze umieszczany w rejestrze o parzystym numerze. Kolejne bajty argumentu są umieszczane w kolejnych rejestrach o wyższych numerach. Kolejne argumenty są umieszczane w rejestrach poczynając od wyższych numerów, kończąc na niższych. Precyzyjnie sposób wyznaczania rejestrów do przekazania argumentów wygląda następująco:
  
  Za rejestr (nazwijmy go) "bazowy" przyjmujemy r26 i wykonujemy następujące kroki
  
  1. Jeśli rozmiar argumentu jest liczbą nieparzystą, dodajemy do rozmiaru 1.
  2. Tak obliczony rozmiar odejmujemy od numeru rejestru bazowego, uzyskując nowy numer rejestru bazowego.
  3. Jeśli nowy numer rejestru bazowego jest większy od r8, będzie do niego wpisany najmniej znaczący bajt naszego argumentu. Kolejne bajty będą wpisane do kolejnych rejestrów (w kierunku wyższych numerów).
  4. Jeśli numer rejestru będzie mniejszy od r8, argument zostanie umieszczony w pamięci RAM. Tutaj nie będziemy rozpatrywać takiego przypadku, ponieważ zakładamy pisanie stosunkowo prostych funkcji jak wstawek ASM. Za pomocą wyznaczonych do tego celu rejestrów możemy do funkcji przekazać maksymalnie 18 bajtów, więc w zdecydowanej większości przypadków będzie to ilość wystarczająca.
  5. Jeśli aktualny argument powinien być umieszczony w pamięci RAM, poprzestajemy na tym, ponieważ to oznacza, że wszystkie następne argumenty również muszą być umieszczone w RAM.
  6. Jeśli mamy do przekazania następny argument, wracamy do punktu 1. (oczywiście przyjmując do obliczeń nowo wyznaczony numer rejestru bazowego).
  
  Wygląda to może nieco skomplikowanie, więc podam kilka przykładów:
  
  Przykład 1:
  
  [syntax=c]void funkcja(uint32_t arg1, int8_t arg2, int16_t arg3);[/syntax]
  arg1: 4 bajty
  
  
  1. 4 jest liczbą parzystą, więc pozostaje bez zmian.
  2. 26 - 4 = 22 rejestr bazowy dla pierwszego argumentu to r22.
  3. Numer rejestru r22 jest większy od numeru rejestru r8 więc przypisujemy:
     
     Code:
     r22 = arg1[byte0]
     r23 = arg1[byte1]
     r24 = arg1[byte2]
     r25 = arg1[byte3]
  4. Nie dotyczy naszego przypadku.
  5. Nie dotyczy naszego przypadku.
  6. Kontynuujemy z następnym argumentem.
  
  arg2: 1 bajt
  
  
  1. 1 jest liczbą nieparzystą, więc dodajemy 1 i otrzymujemy rozmiar równy 2
  2. 22 - 2 = 20 rejestr bazowy dla drugiego argumentu to r20.
  3. Numer rejestru r20 jest większy od numeru rejestru r8 więc przypisujemy:
     
     Code:
     r20 = arg2[byte0]
  4. Nie dotyczy naszego przypadku.
  5. Nie dotyczy naszego przypadku.
  6. Kontynuujemy z następnym argumentem.
  
  arg3: 2 bajty
  
  
  1. 2 jest liczbą parzystą, więc pozostaje bez zmian.
  2. 20 - 2 = 18 rejestr bazowy dla pierwszego argumentu to r18.
  3. Numer rejestru r18 jest większy od numeru rejestru r8 więc przypisujemy:
     
     Code:
     r18 = arg3[byte0]
     r19 = arg3[byte1]
  4. Nie dotyczy naszego przypadku.
  5. Nie dotyczy naszego przypadku.
  6. Kończymy - to był ostatni argument.
  
  Przykład 2:
  
  [syntax=c]void funkcja(uint32_t *arg1, int8_t *arg2, uint8_t arg3);[/syntax]
  
  arg1: 2 bajty ( wskaźnik = 16 bit )
  
  Code:
  r24 = arg1[byte0]
  r25 = arg1[byte1]
  
  arg2: 2 bajty
  
  Code:
  r22 = arg2[byte0]
  r23 = arg2[byte1]
  
  arg3: 1 bajt
  
  Code:
  r20 = arg3[byte0]
  
  
  
  Przykład 3:
  
  [syntax=c]void funkcja(uint8_t arg1, uint8_t *arg2, int64_t arg3);[/syntax]
  
  Code:
  r14 = arg3[byte0]
  r15 = arg3[byte1]
  r16 = arg3[byte2]
  r17 = arg3[byte3]
  r18 = arg3[byte4]
  r19 = arg3[byte5]
  r20 = arg3[byte6]
  r21 = arg3[byte7]
  
  r22 = arg2[byte0]
  r23 = arg2[byte1]
  
  r24 = arg1[byte0]
  
  
  
• Wartości zwracane przez funkcje
  
  Jeżeli pisząc w ASM będziemy wywoływali funkcję napisaną w C lub będziemy pisali funkcję w ASM wywoływaną w pliku C, musimy znać też rejestry, w których - po wykonaniu funkcji - znajdzie się wartość zwracana przez tę funkcję (oczywiście tylko wtedy, gdy jakaś wartość ma być zwracana, bo przecież nie zawsze musi być).
  
  Tutaj sprawa wygląda prościej, gdyż zwracana wartość jest jedna, a nie kilka. Wartość zwracana przez funkcję jest umieszczana w rejestrach, jeśli jej rozmiar nie przekroczy 8 bajtów, czyli zdecydowanie mniej niż w przypadku argumentów przekazywanych do funkcji, ale i tak w większości przypadków rozmiar 64-bitowy jest wystarczający. Właściwie w avr-libc nie ma np. typu całkowitego o większym rozmiarze, a typy zmiennoprzecinkowe float oraz double mają po 32-bity. Jedynym przypadkiem przekroczenia limitu będzie więc zwrócenie przez funkcję struktury (poprzez wartość) o rozmiarze większym od ośmiu bajtów. Moim zdaniem jednak zarówno przekazywanie do funkcji, jak i zwracanie przez funkcję dużych struktur poprzez wartość w ośmiobitowych mikrokontrolerach, mających stosunkowo małe pojemności pamięci RAM, nie jest dobrą praktyką.
  
  Wyznaczanie rejestrów wygląda podobnie, jak w przypadku argumentów (rejestr bazowy to także r26), a więc przyporządkowanie rejestrów będzie wyglądać tak:
  1 bajt
  
  Code:
  byte0
   r24
  
  
  2 bajty
  
  Code:
  [byte1]   [byte0]
    r25       r24
  
  
  4 bajty
  
  Code:
  [byte3]   [byte2]   [byte1]   [byte0]
    r25       r24       r23       r22
  
  
  8 bajtów
  
  Code:
  [byte7]   [byte6]   [byte5]   [byte4]   [byte3]   [byte2]   [byte1]   [byte0]
    r25       r24       r23       r22       r21       r20       r19       r18
  
  
  
• Rejestry stałe
  
  Rejestry stałe to rejestry o specjalnym przeznaczeniu, które nie są alokowane przez kompilator wprost do operacji na danych:
  
  • r0
    Jest to rejestr do przechowywania tymczasowych danych, którego wartość nie musi być przywracana po jego użyciu. Jedynym wyjątkiem są procedury obsługi przerwań, gdzie rejestr ten - jeśli jest używany wewnątrz procedury, jego zawartość musi być zapamiętana w prologu i przywrócona w epilogu.
    W inline assembler może być używany za pośrednictwem symbolu __tmp_reg__ jako rejestr tymczasowy.
    
  • r1
    Rejestr ten jest przeznaczony do przechowywania wartości zerowej. Jego wartość musi być zawsze równa zero. Nie zawsze jednak da się to osiągnąć, choćby ze względu na to, że jest to jeden z rejestrów wyjściowych dla instrukcji mul. Jeśli jednak jego wartość zostanie zmieniona przez jakąś funkcję, musi być ponownie wyzerowana (najpóźniej przed jej zakończeniem). Nie należy jednak zerować tego rejestru, kiedy jego wartość została zmieniona w procedurze obsługi przerwania. Należy go zapamiętać w prologu i przywrócić w epilogu, gdyż nigdy nie wiadomo, w jakim momencie wystąpi przerwanie i jaka będzie w tym momencie wartość tego rejestru (po zakończeniu procedury musi być taka sama jak przed).
    Rejestr ten może być przydatny np. przy instrukcjach porównania. Nie wszystkie rejestry mają możliwość porównania z wartością stałą (instrukcja cpi obsługuje tylko rejestry r16-r31). Dzięki temu rejestrowi można szybko porównać dowolny rejestr z wartością 0x00 (przy pomocy instrukcji cp, która obsługuje wszystkie rejestry), bez konieczności wykonania najpierw operacji zerowania. Niestety nie wolno w ten sposób używać rejestru r1 w procedurze obsługi przerwania, gdyż nie można wtedy założyć, że rejestr ten ma wartość zero.
    W inline assembler można go używać za pomocą symbolu __zero_reg__ jako rejestr o wartości zerowej.
  
  
• Rejestry niszczone przez funkcje
  
  Każda funkcja musi używać rejestrów, co oznacza, że zawartość rejestrów podczas wykonywania funkcji zostaje zmieniona. Kompilator C przyjmuje, że zawartość rejestrów r18-r27, r30-r31, r0, flaga T w SREG może ulec zniszczeniu podczas działania funkcji.
  
  Jeśli pisząc wstawkę w ASM zależy nam na zachowaniu wartości któregoś z wyżej wymienionych rejestrów po zakończeniu wykonania funkcji napisanej w C, musimy przed jej wywołaniem zapamiętać tę wartość (np. na stosie).
  
  Z kolei pisząc funkcję w ASM, która będzie wywoływana w kodzie C, możemy dowolnie korzystać z tych rejestrów, nie martwiąc się o to, że zniszczymy ich zawartość. Nie trzeba ich zapamiętywać na początku i przywracać na końcu funkcji.
  
  Wyjątkiem są tutaj oczywiście (o czym pisałem już wcześniej) procedury obsługi przerwań, które zawsze muszą zapamiętywać wszystkie używane przez siebie rejestry, jak i rejestr statusowy SREG.
  
  
• Rejestry zachowywane przez funkcje
  
  Odwrotna zasada dotyczy pozostałych rejestrów, czyli r2-r17, r28-r29. Wywołując w pliku ASM funkcję C możemy założyć, że zawartość tych rejestrów nie zostanie zmieniona.
  
  Pisząc w ASM funkcję wywoływaną później w pliku C, jeśli chcemy skorzystać z tych rejestrów, musimy zadbać o zapamiętanie zawartości tych rejestrów na początku funkcji i przywrócenie na końcu.
  
  Do tej grupy rejestrów można zaliczyć również rejestr r1, jednak należy pamiętać, że rejestr ten jest rejestrem specjalnym ("zerowym") i obowiązują go trochę inne reguły opisane wcześniej.

• Współdzielenie zmiennych
  
  Wprawdzie podałem tu przykłady współdzielenia zmiennych przez zwykłe funkcje, jednak bardziej uzasadnione jest współdzielenie zmiennych np. poprzez funkcje C i procedurę obsługi przerwania napisaną w ASM. Moim zdaniem, w przypadku zwykłych funkcji, lepiej przekazywać dane poprzez argumenty i zwracanie wartości.
  
  Oczywiście w przypadku współdzielenia zmiennej pomiędzy procedurą obsługi przerwania w ASM a funkcjami C, należy pamiętać o dodaniu słowa kluczowego volatile.
  
  
  • Zmienna zadeklarowana w pliku C dostępna dla kodu ASM
    
    W pliku C deklarujemy zmienną globalną:
    
    [syntax=c]uint16_t counter;[/syntax]
    
    W pliku ASM można zadeklarować zmienną .extern, choć nie jest to konieczne:
    
    [syntax=asm].extern counter[/syntax]
    
    Przypominam, że w plikach ASM nie deklarujemy typu zmiennej. Pomimo tego, że deklaracja .extern nie jest konieczna, uważam że warto to zrobić np. w taki sposób (typ można podać w komentarzu):
    
    [syntax=asm]; zmienna globalna w pliku *.c
    ; wynik obliczeń funkcji 'moja_funkcja'
    .extern counter ; uint16_t[/syntax]
    
    Dzięki temu, bez konieczności przełączania się do pliku *.c możemy sobie przypomnieć nazwę, typ i przeznaczenie zmiennej.
    
    Przykład użycia:
    
    [syntax=asm].extern counter
    
    .global moja_funkcja
    
    moja_funkcja:
    ; tutaj ewentualny prolog, czyli zapamiętanie wartości
    ; używanych rejestrów na stosie
    lds r24, counter ; wczytujemy młodszy bajt
    lds r25, counter+1 ; wczytujemy starszy bajt
    ; tutaj obliczenia
    sts counter, r24 ; zapisujemy młodszy bajt
    sts counter+1, r25 ; zapisujemy starszy bajt
    ; tutaj ewentualny epilog, czyli przywrócenie wartości
    ; używanych rejestrów ze stosu
    ret[/syntax]
    
  • Zmienna zadeklarowana w pliku ASM dostępna dla kodu C
    
    W pliku ASM deklarujemy zmienną w sekcji .data:
    
    [syntax=asm].section .data
    
    ; ewentualny opis zmiennej
    counter: .word 0 ; uint16_t[/syntax]
    
    Tutaj należy pamiętać o możliwej konieczności zainicjowania wartości zmiennej, co opisałem w podrozdziale: "Deklarowanie zmiennych w pamięci RAM", gdyż kompilator może za nas tego nie zrobić.
    
    W pliku C deklarujemy zmienną extern:
    
    [syntax=c]extern uint16_t counter;[/syntax]
    
    Pomimo tego, że w pliku ASM zmienna counter nie ma typu (tzn. ma tylko domyślnie przyjęty przez programistę), w pliku C musimy bezwzględnie podać typ zmiennej.
  
  
• Wywoływanie funkcji napisanej w ASM z kodu napisanego w C
  
  W kodzie ASM etykiet używamy nie tylko do oznaczenia zmiennych czy też początku funkcji. Część etykiet, zwykle większa część, jest przeznaczona do oznaczenia miejsc, do których będą wykonywane skoki warunkowe (np. instrukcje brne, breq itp.), skoki bezwarunkowe (np. instrukcje rjmp, jmp itp.) lub do oznaczenia początków funkcji lokalnych, pomocniczych, które używane będą tylko w kodzie ASM. Nie jest wskazane, aby niepotrzebne etykiety były widoczne dla kodu C. Dlatego należy specjalnie oznaczyć tylko etykiety oznaczające wejścia do funkcji, które będą wywoływane z kodu C. Służy do tego słowo kluczowe .global
  
  
  • Funkcja bez parametrów nie zwracająca wartości
    
    Deklaracja i wywołanie funkcji w pliku C:
    
    [syntax=c]// deklaracja funkcji
    void clear_timer1(void);
    
    // wywołanie funkcji
    clear_timer1();[/syntax]
    
    Definicja funkcji w pliku ASM:
    
    [syntax=asm].global clear_timer1
    
    clear_timer1:
    ; jeśli korzystamy z przerwań należy zapewnić
    ; atomowy dostęp do 16-bitowych rejestrów
    cli
    ; nie jest to procedura obsługi przerwania
    ; tylko zwykła funkcja, możemy więc użyć
    ; rejestru r1 jako rejestru z wartością zerową
    ; rejestry TCNT1 w ATmega644P są poza zakresem i/o
    ; musimy użyć instrukcji sts
    sts TCNT1L, r1
    sts TCNT1H, r1
    ; jeśli korzystamy z przerwań, po wykonaniu
    ; atomowej operacji na rejestrze 16-bitowym,
    ; musimy ponownie włączyć globalne zezwolenie
    ; na przerwania
    sei
    ret[/syntax]
    
  • Funkcja z parametrami nie zwracająca wartości
    
    Deklaracja i wywołanie funkcji w pliku C:
    
    [syntax=c]// deklaracja funkcji
    void set_timer1_pwm(uint16_t period, uint16_t pulse_width);
    
    // wywołanie funkcji
    uint16_t per = 12500, width = 2000;
    set_timer1_pwm(per, width);[/syntax]
    
    Definicja funkcji w pliku ASM:
    
    [syntax=asm];
    .global set_timer1_pwm
    
    set_timer1_pwm:
    cli
    ; argument 'period' znajduje się w rejestrach r25:r24
    ; wpisujemy go do rejestrów OCR1AH:OCR1AL
    ; podczas zapisu do rejestrów 16-bit najpierw bajt starszy
    sts OCR1AH, r25
    sts OCR1AL, r24
    ; argument 'pulse_width' znajduje się w rejestrach r23:r22
    ; wpisujemy go do rejestrów OCR1BH:OCR1BL
    sts OCR1BH, r23
    sts OCR1BL, r22
    sei
    ret[/syntax]
    
  • Funkcja bez parametrów zwracająca wartość
    
    Deklaracja i wywołanie funkcji w pliku C:
    
    [syntax=c]// deklaracja funkcji
    uint16_t get_t1_input_capture(void);
    
    // wywołanie funkcji
    uint16_t icp = get_t1_input_capture();[/syntax]
    
    Definicja funkcji w pliku ASM:
    
    [syntax=asm];
    .global get_t1_input_capture
    
    get_t1_input_capture:
    cli
    ; wartość zwracana musi znaleźć się w rejestrach r25:r24
    ; podczas odczytu z rejestrów 16-bit najpierw bajt młodszy
    lds r24, ICR1L
    lds r25, ICR1H
    sei
    ret[/syntax]
    
  • Funkcja z parametrami zwracająca wartość
    
    Deklaracja i wywołanie funkcji w pliku C:
    
    [syntax=c]// deklaracja funkcji
    uint8_t get_array_element(uint8_t *array_ptr, uint8_t element_id);
    
    // wywołanie funkcji
    uint8_t my_array[] = {15,21,233,187};
    uint8_t element = get_array_element(my_array, 2);[/syntax]
    
    Definicja funkcji w pliku ASM:
    
    [syntax=asm];
    .global get_array_element
    
    get_array_element:
    ; dla treningu użyjemy rejestrów, których wartość
    ; musi być zachowana
    push yl ; r28
    push yh ; r29
    ; pierwszy argument: 16-bitowy wskaźnik do tablicy
    ; kompilator C umieści w rejestrach r25:r24
    ; drugi argument: 8-bitowy indeks tablicy
    ; kompilator C umieści w rejestrze r22
    ; by uzyskać wskaźnik do odczytywanego elementu
    ; tablicy musimy te dwa argumenty dodać
    add r24, r22
    adc r25, r1 ; wartość r1 = 0
    ; wartość rejestrów r25:r24 jest wskaźnikiem
    ; na odczytywany element tablicy
    ; przenosimy ten wskaźnik do rejestru
    ; wskaźnikowego 'y'
    movw y, r24
    ; 8-bitowa wartość odczytana z tablicy musi
    ; zostać zwrócona przez funkcję w rejestrze r24
    ld r24, y
    ; przywracamy wartości użytych rejestrów,
    ; które zapamiętaliśmy na początku
    pop yh ; r29
    pop yl ; r28
    ret[/syntax]
    
  • Procedura obsługi przerwania
    
    Procedura obsługi przerwania to specjalny rodzaj funkcji. Jest ona wywoływana automatycznie przez mikrokontroler w momencie wystąpienia zdarzenia. W przeciwieństwie do zwykłej funkcji nie da się przewidzieć, w którym momencie wykonywania programu głównego procedura zostanie wywołana, dlatego obowiązują tu inne reguły:
    
    1. O ile funkcję możemy nazwać dowolnie, o tyle nazwa procedury obsługi przerwania (w przypadku asemblera - etykieta globalna) musi być zgodna z nazwą zdefiniowaną w plikach nagłówkowych mikrokontrolera dla danego przerwania. Prościej mówiąc, musi mieś nazwę, którą wpisalibyśmy w nawiasie używając makra ISR() pisząc procedurę w języku C (oczywiście przy użyciu GCC).
    2. Wszystkie rejestry używane wewnątrz procedury oraz rejestr statusowy SREG muszą zostać zapamiętane na stosie w prologu i odtworzone w epilogu procedury. Dotyczy to również rejestrów, których zniszczenie zawartości jest dopuszczalne w normalnej funkcji jak i rejestrów stałych: tymczasowego r0 (który w normalnej funkcji nie musi być zapamiętywany i odtwarzany) oraz zerowego r1 (który w normalnej funkcji musi zostać na końcu wyzerowany, jeśli jego zawartość uległa zmianie).
       W wyjątkowych przypadkach, jeśli żadna z instrukcji wewnątrz procedury nie zmienia zawartości SREG, możemy pominąć jego zapamiętywanie i przywracanie.
       Z drugiej strony należy pamiętać, że w przypadku wywołania jakiejś funkcji wewnątrz procedury, musimy uwzględnić w prologu i epilogu rejestry przez tę funkcję niszczone.
    3. W odróżnieniu od normalnej funkcji kończonej instrukcją powrotu ret, procedura obsługi przerwania musi być zakończona instrukcją powrotu reti.
    
    Typowa konstrukcja procedury obsługi przerwania (dla przykładu przyjmijmy przepełnienie timer'a 0) powinna wyglądać tak:
    
    [syntax=asm];
    .global TIMER0_OVF_vect
    
    TIMER0_OVF_vect:
    ; ------ prolog - początek ----------
    push r16
    in r16, SREG
    push r16
    ; inne rejestry używane w procedurze
    ; przykładowo:
    push r26
    push r27
    ; ----- prolog - koniec -------------
    ;
    ; tutaj właściwy kod procedury
    ;
    ; ----- epilog - początek -----------
    pop r27
    pop r26
    pop r16
    out SREG, r16
    pop r16
    ; ----- epilog - koniec -------------
    reti[/syntax]
    
    
    W przypadku, kiedy np. chcemy w procedurze tylko ustawić flagę odpowiednio interpretowaną później w programie głównym, (w niektórych mikrokontrolerach) możemy użyć do tego rejestru i/o - GPIOR. W procedurze obsługi przerwania zmieniamy tylko jeden rejestr, jednak żadna z instrukcji nie zmienia żadnego bitu w rejestrze SREG. Cała procedura mogłaby wtedy wyglądać np. tak:
    
    [syntax=asm].global TIMER0_OVF_vect
    
    TIMER0_OVF_vect:
    push r16
    ldi r16, 1
    out GPIOR1, r16
    pop r16
    reti[/syntax]
    
    Tak naprawdę to tutaj będziemy mieli główne pole do popisu. Napisanie procedury obsługi przerwania nie wpływa na jakość optymalizacji kompilatora, o czym pisałem wcześniej. Zauważyłem za to tendencje kompilatora do odkładania (w procedurach obsługi przerwań) na stos niepotrzebnych rejestrów, szczególnie w przypadku bardziej rozbudowanych procedur wywołujących dodatkowo jakieś funkcje. Dzięki temu, pisząc w ASM, można oszczędzić kilka cennych taktów. Dodatkowo mamy szansę np. na skrócenie operacji arytmetycznych poprzez ograniczenie rozmiaru zmiennej do niezbędnego minimum.
  
  
• Wywoływanie funkcji napisanej w C z kodu napisanego w ASM
  
  
  • Funkcja bez parametrów nie zwracająca wartości
    
    Definicja funkcji w pliku C:
    
    [syntax=c]void clear_timer1(void)
    {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {
    TCNT1 = 0;
    }
    }[/syntax]
    
    Wywołanie funkcji w pliku ASM:
    
    [syntax=asm]; nie wymaga żadnych dodatkowych zabiegów
    ; wystarczy w odpowiednim miejscu
    ; umieścić instrukcję:
    call clear_timer1[/syntax]
    
  • Funkcja z parametrami nie zwracająca wartości
    
    Definicja funkcji w pliku C:
    
    [syntax=c]void set_timer1_pwm(uint16_t period, uint16_t pulse_width)
    {
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {
    OCR1A = period;
    OCR1B = pulse_width;
    }
    }[/syntax]
    
    Wywołanie funkcji w pliku ASM:
    
    [syntax=asm]; wymagane umieszczenie argumentów
    ; w odpowiednich rejestrach
    ; 'period' w rejestrach r25:r24
    ; przykładowo (wartość 12500 = 0x30D4):
    ldi r25, 0x30
    ldi r24, 0xD4
    ; 'pulse_width' w rejestrach r23:r22
    ; przykładowo (wartość 2000 = 0x07D0):
    ldi r23, 0x07
    ldi r22, 0xD0
    ; dopiero teraz wywołujemy funkcję
    call set_timer1_pwm[/syntax]
    
  • Funkcja bez parametrów zwracająca wartość
    
    Definicja funkcji w pliku C:
    
    [syntax=c]uint16_t get_t1_input_capture(void)
    {
    uint16_t icr;
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
    {
    icr = ICR1;
    }
    return icr;
    }[/syntax]
    
    Wywołanie funkcji w pliku ASM:
    
    [syntax=asm]; Funkcja nie posiada parametrów, więc w odpowiednim
    ; miejscu kodu po prostu ją wywołujemy. Jedyne
    ; co musimy ewentualnie zrobić, to zapamiętać wartości
    ; rejestrów, które chcemy zachować, a wywołanie
    ; funkcji może zniszczyć. Przyjmijmy, że chcemy zachować
    ; rejestry r19:r18, gdyż zawierają wartość z którą
    ; będzie porównywana wartość odczytana z ICR1
    push r18
    push r19
    ; wywołujemy funkcję
    call get_t1_input_capture
    ; przywracamy wartość rejestrów
    pop r19
    pop r18
    ; wartość zwrócona będzie w rejestrach r25:r24
    ; wykonujemy na niej żądane operacje, przykładowo:
    cp r24, r18
    cpc r25, r19
    brlo lable_if_lower
    ; dalsza część kodu[/syntax]
    
  • Funkcja z parametrami zwracająca wartość
    
    Definicja funkcji w pliku C:
    
    [syntax=c]uint8_t get_array_element(uint8_t *array_ptr, uint8_t element_id)
    {
    return array_ptr[element_id];
    }[/syntax]
    
    Wywołanie funkcji w pliku ASM:
    
    [syntax=asm]; zakładamy, że mamy w pliku *.c
    ; zadeklarowaną tablicę:
    ; uint8_t my_array[] = {0,1,2,3};
    ; argument pierwszy 'array_ptr'
    ; rejestry r25:r24
    ldi r24, lo8(my_array)
    ldi r25, hi8(my_array)
    ; argument drugi 'element_id'
    ; rejestr r22
    ldi r22, 2 ; pobieramy drugi element
    ; wywołanie funkcji
    call get_array_element
    ; wartość zwrócona przez funkcję (1 bajt)
    ; znajduje się w rejestrze r24
    ; wykonujemy na niej żądane operacje
    ; przykładowo
    cpi r24, 125
    brne not_equal
    ; dalsza część kodu[/syntax]
    
  • Funkcja z biblioteki standardowej C
    
    Pisząc w języku asembler możemy również używać funkcji z bibliotek standardowych C. Nie trzeba w tym celu dołączać plików nagłówkowych dyrektywą #include. Wystarczy tak jak w przypadku naszych funkcji umieścić ewentualne argumenty w odpowiednich rejestrach, wywołać funkcję i odczytać wynik z odpowiednich rejestrów.
    
    Przykładowe wyliczenie wartości bezwzględnej za pomocą funkcji abs() z biblioteki <stdlib.h>:
    
    [syntax=asm]; zakładamy zdefiniowanie w sekcji .data
    my_val: .word -5684
    ; później w kodzie w sekcji .text:
    ;
    ; umieszczamy argument typu int
    ; (będzie to nasza zmienna 'my_val')
    ; w rejestrach r25:r24
    ldi xl, lo8(my_val)
    ldi xh, hi8(my_val)
    ld r24, x+
    ld r25, x
    ; wywołujemy funkcję
    call abs
    ; teraz w rejestrach r25:r24 znajduje się
    ; wartość zwrócona przez funkcję,
    ; czyli wartość bezwzględna zmiennej 'my_val'[/syntax]
  
  
• Korzystanie ze wspólnego pliku nagłówkowego
  
  Na koniec mały projekt przykładowy, pokazujący w jaki sposób korzystać ze wspólnego pliku nagłówkowego zarówno dla C jak i asemblera, dzięki czemu można uniknąć konieczności podwójnego definiowania stałych używanych w programie.
  
  Projekt napisany został dla mikrokontrolera ATmega644P. Przedstawia wprawdzie obsługę klawiatury z debouncing'iem opartym o timer, ale nie to jest jego głównym celem. Koncentrowałem się przede wszystkim na pokazaniu ogólnej struktury projektu wykorzystującego mieszany kod ze współdzielonym plikiem nagłówkowym, więc choć program powinien działać, nie mogę zagwarantować pełnej niezawodności oraz optymalności kodu.
  
  Projekt składa się z trzech plików, które przedstawiłem poniżej (dokładniejszy opis w komentarzach):
  
  plik "main.c"
  [syntax=c]/*
  * main.c
  *
  * Created: 2016-09-12 19:35:09
  * Author : Andrews
  */
  
  #include <avr/io.h>
  #include <stdbool.h>
  #include <avr/interrupt.h>
  #include "keyboard.h"
  
  // Zmienna współdzielona z procedurą obsługi przerwania
  // napisaną w ASM. Wartość zmiennej jest aktualizowana
  // przez procedurę obsługi przerwania, kiedy procedura
  // odczyta dwukrotnie ten sam kod klawiatury
  volatile enum Key pressed_key = NO_KEY;
  
  // Funkcja konfigurująca port klawiatury
  // oraz timer
  void kbrd_init(void);
  
  int main(void)
  {
  // Ustawienie pinów portu A jako wyjść
  // by można było obserwować efekty wciskania
  // klawiszy
  DDRA = 0x0F;
  
  // Zmienna blokująca wielokrotne wykonanie
  // kodu obsługi klawisza przed jego puszczeniem
  bool key_processed = false;
  
  // Zmienna 'pressed_key' może zostać zmieniona
  // przez procedurę obsługi przerwania w dowolnym
  // momencie. Zmienna pomocnicza zagwarantuje,
  // że wartość zmiennej się nie zmieni
  // do momentu zakończenia analizy
  enum Key pk;
  
  kbrd_init();
  sei();
  
  while (1)
  {
  pk = pressed_key;
  if (key_processed)
  {
  // Oczekiwanie na zwolnienie przycisku
  if (pk==NO_KEY)
  {
  key_processed = false;
  // Tutaj ewentualny kod wykonywany
  // po zwolnieniu klawisza, przykładowo:
  PORTA = 0x00;
  }
  }
  else
  {
  // Poniższy warunek zagwarantuje,
  // że kod obsługi klawisza będzie
  // wykonany tylko raz na jedno
  // przyciśnięcie
  if (pk!=NO_KEY) key_processed = true;
  switch (pk)
  {
  // Tutaj kody obsługi poszczególnych klawiszy
  case UP:
  // przykładowo:
  PORTA = 0x01;
  break;
  case DOWN:
  PORTA = 0x02;
  break;
  case ESC:
  PORTA = 0x04;
  break;
  case ENTER:
  PORTA = 0x08;
  break;
  case NO_KEY:
  default:
  break;
  }
  }
  }
  }
  
  // Funkcja inicjująca obsługę klawiatury
  void kbrd_init(void)
  {
  // Włączenie pull-up dla pinów,
  // do których są podłączone klawisze
  KBRD_PORT = KBRD_bm;
  
  // Konfiguracja timera
  // Założenie: F_CPU=16MHz
  TCCR2A = (1<<WGM21); // tryb CTC
  TCCR2B = (7<<CS20); // prescaler 1024
  OCR2A = 155; // przerwanie co ok. 10ms
  TIMSK2 = (1<<OCIE2A); // włączenie przerwania od porównania
  }[/syntax]
  
  
  plik "keyboard.h"
  [syntax=c]/*
  * keyboard.h
  *
  * Created: 2016-09-12 19:47:56
  * Author: Andrews
  */
  
  #ifndef KEYBOARD_H_
  #define KEYBOARD_H_
  
  // *************************************************************
  // Fragment przeznaczony do edycji.
  // Można ustawić własne porty i numery pinów
  // należy tylko zwrócić uwagę, by nie kolidowały
  // z pinami portem i pinami, wykorzystanymi w pętli głównej
  // programu do sygnalizacji.
  // (przyciski podłączone pomiędzy pin mikrokontrolera a masę)
  #define KBRD_PORT PORTB
  #define KBRD_PIN PINB
  #define KEY_UP_bp 0
  #define KEY_DOWN_bp 1
  #define KEY_ESC_bp 2
  #define KEY_ENTER_bp 3
  //**************************************************************
  
  #define KBRD_bm ( ( 1<<(KEY_UP_bp) ) |\
  ( 1<<(KEY_DOWN_bp) ) |\
  ( 1<<(KEY_ESC_bp) ) |\
  ( 1<<(KEY_ENTER_bp) ) )
  
  #define KEY_UP_bm ( KBRD_bm & ~( 1<<(KEY_UP_bp) ) )
  #define KEY_DOWN_bm ( KBRD_bm & ~( 1<<(KEY_DOWN_bp) ) )
  #define KEY_ESC_bm ( KBRD_bm & ~( 1<<(KEY_ESC_bp) ) )
  #define KEY_ENTER_bm ( KBRD_bm & ~( 1<<(KEY_ENTER_bp) ) )
  
  
  // Definicja typu enum Key przeznaczona tylko dla pliku main.c
  #ifndef __ASSEMBLER__
  
  enum Key {
  NO_KEY = KBRD_bm,
  UP = KEY_UP_bm,
  DOWN = KEY_DOWN_bm,
  ESC = KEY_ESC_bm,
  ENTER = KEY_ENTER_bm
  };
  
  #endif
  
  #endif /* KEYBOARD_H_ */[/syntax]
  
  plik "timer_isr.S"
  [syntax=asm]/*
  * timer_isr.S
  *
  * Created: 2016-09-12 19:39:35
  * Author: Andrews
  */
  #define __SFR_OFFSET 0
  
  #include <avr/io.h>
  #include "keyboard.h"
  
  ; zmienna zadeklarowana w pliku main.c
  ; będziemy do niej wpisywać informację
  ; o wciśniętym klawiszu
  .extern pressed_key ; uint8_t
  
  ; ===============================================
  .section .data
  
  ; zmienna lokalna, widoczna tylko dla asm
  ; poprzednio odczytany stan klawiatury
  prev_code: .byte KBRD_bm ; enum Key
  
  ; ===============================================
  ; W pliku 'main.c' jest zadeklarowana zmienna
  ; statyczna 'pressed_key' z przypisaną wartością,
  ; więc nasza zmienna lokalna 'prev_code' powinna
  ; zostać zainicjowana prawidłowo
  ; przez kompilator C (pisałem o tym wcześniej).
  ; W innym przypadku w tym miejscu powinniśmy
  ; zainicjować naszą zmienną sami.
  ;
  ; .section .init1,"ax",@progbits
  ;
  ; ldi r16, KBRD_bm
  ; sts prev_code, r16
  ;
  ; ===============================================
  
  .section .text
  
  
  .global TIMER2_COMPA_vect
  
  ; Zdecydowanie łatwiej operować nazwami symbolicznymi
  ; niż numerami rejestrów. Możemy je zdefiniować tak,
  ; jak jest pokazane poniżej.
  ; Dyrektywa asemblera .set (w przeciwieństwie do .equ)
  ; pozwala na wielokrotne definiowanie tego samego
  ; symbolu, dzięki czemu w innej funkcji możemy
  ; przypisać inny numer rejestru do tego samego symbolu,
  ; przykładowo:
  ; .set temp, 22
  
  .set temp, 16
  .set prev, 17
  
  TIMER2_COMPA_vect:
  ; ------------------ prolog --------------------
  push temp
  in temp, SREG
  push temp
  push prev
  ; ---------------- koniec prologu ---------------
  lds prev, prev_code
  in temp, KBRD_PIN
  andi temp, KBRD_bm
  cp temp, prev
  brne not_equ
  sts pressed_key, prev
  not_equ:
  sts prev_code, temp
  ; ------------------ epilog --------------------
  pop prev
  pop temp
  out SREG, temp
  pop temp
  ; --------------- koniec epilogu ----------------
  reti[/syntax]

andrews

Statystyki: Napisane przez andrews — 14 paź 2016, o 19:11