GCC i funkcje o zmiennej liczbie argumentów

admin — Wed, 08 Jul 2009 22:52:48 +0000

Niniejszy wpis jest poświęcony zagadnieniu wykorzystania funkcji o zmiennej liczbie argumentów w swoich projektach. Najpopularniejszym przykładem funkcji posiadającą taką właściwość jest funkcja printf, której prototyp wygląda mniej-więcej tak:

int printf(char *fmt, ...);

Notacja ‘…’ w polu argumentów funkcji informuje kompilator o tym, iż funkcja może przybierać dowolną liczbę argumentów. Powstaje podstawowe pytanie: w jaki sposób takie argumenty są przekazywane do funkcji skoro ich liczba nie jest wprost określona? Jak się do nich odwoływać?

Twórcy kompilatora GCC rozwiązali sprawę przekazując takie parametry w formie obszaru pamięci zorganizowanego w specyficzny sposób. Na potrzeby rozważań ustalmy, iż funkcja, którą będziemy badać będzie posiadała następujący prototyp:

void foo(char *arg, ...);

Jeżeli kolejne argumenty funkcji oznaczymy przez arg0 … arg n to zostaną one umieszczone w pamięci w sposób przedstawiony na poniższym rysunku:

Wyjaśnienia wymaga zapis a_sizeof(x). Jest to makro zwracające rozmiar zmiennej (w bajtach) będącej jego argumentem w postaci ‘wyrównanej’ do architektury dla której kompilujemy oprogramowanie. Przykładowo, jeśli architektura jest 32 bitowa to wartość dla zmiennej 1-bajtowej wynosi 4, a dla zmiennej 5-bajtowej wynosi 8. Powyższy rysunek mówi nam, iż każdy kolejny argument jest umieszczony po poprzednim w odległości równej a_sizeof(x), gdzie x to argument poprzedni.

Skoro wiemy już jak zmienne są rozmieszczone w pamięci to możemy zdefiniować sobie makra do poruszania się po nich i odczytywania ich wartości. Zestaw makr przygotowanych przeze mnie ma następującą postać:

#define __a_size(n)           ((sizeof(n) + sizeof(char *) – 1) & ~(sizeof(char *) – 1))
#define va_start(ptr, v)        (ptr = (va_list)(&v) + __a_size(v))

#define va_arg(ptr, t)          ( *(t *)((ptr += __a_size(v)) – __a_size(t)))

#define va_end(ptr)             (ptr = (va_list) 0)
typedef char * va_list

Makro __a_size(n) jest odpowiednikiem notacji a_sizeof(n) z rysunku. Makro va_start(ptr, v) ustawia wskaźnik ptr, tak aby wskazywał na pierwszą zmienną ze zbioru. Aby poprawnie ustawić wskaźnik niezbędny jest adres ostatniej ‘normalnej’ zmiennej (na rysunku jest zmienna arg). Makro va_arg(ptr, t) powoduje zwrócenie zmiennej wskazywanej przez ptr oraz ustawienie ptr tak by wskazywał na następną zmienną. Parametr t makra określa typ zmiennej jaką chcemy zwrócić. Jest on niezbędny, gdyż od niego zależy ‘odległość’ do następnej zmiennej w pamięci. Makro va_end(ptr) służy do wyczyszczenia wartości wskaźnika ptr.

Wyposażeni w taki zestaw makr możemy zacząć naszą przygodę z funkcjami o zmiennej liczbie argumentów. Dla przykładu napiszemy funkcję wypisującą wartość wszystkich zmiennych typu int podanych jako argumenty. Listing funkcji jest następujący:

void foo(int num_ints, …)
{
int i, x;

va_list va;
va_start(va, num_ints);
for(i = 0; i &lt; num_ints; i++) {

x = va_arg(va, int);

printf("arg: %d, val: %d\n", i, x);

}

}

Przykładowe wywołanie:

foo(3, 1, 2, 3);

I jego rezultat:

arg: 0, val: 1
arg: 1, val: 2
arg: 2, val: 3

USB JTAG i OpenOCD 0.1.0 + Eclipse

admin — Wed, 08 Jul 2009 16:24:00 +0000

Jakiś czas temu światło dzienne ujrzała nowa wersja popularnego oprogramowania OpenOCD, służącego do programowania i debugowania uC. W związku z tym, jakże wspaniałym, wydarzeniem uznałem za zasadne przedstawienie Czytelnikowi treści skryptów, służących do programowania pamięci flash mikrokontrolerów AT91SAM7S64. Wybór mikrokontrolera jest podyktowany tym, iż znalazł on zastosowanie w dużej części wykonanych przeze mnie urządzeń. W roli JTAG’a wykorzystałem, własnoręcznie wykonany, klon Turtelizera 2.

W pakiecie OpenOCD dołączono wiele skryptów opisujących sposób pracy interfejsów JTAG, jak również dla poszczególnych układów docelowych (targetów). Nic nie stoi na przeszkodzie aby je wykorzystać i znacząco ułatwić sobie życie. Przykładowy skrypt flashujący uC plikiem main.hex wygląda następująco:

source [find openocd-0.1.0/src/target/interface/turtelizer2.cfg] # (1)
source [find openocd-0.1.0/src/target/target/sam7s64.cfg]        # (2)

init                                  # (3)
reset halt                            # (4)
flash write_image main.hex 0          # (5)
reset run                             # (6)
shutdown                              # (7)

Pierwsza linia zawiera ściężkę prowadzącą do opisu użytego interfejsu JTAG, zaś linia (2) wskazuje na plik z opisem układu docelowego. Jeśli Czytelnik w swej pracy wykorzystuje inne uklady docelowe należy przejrzeć katalog target w folderze instalacyjnym OpenOCD w poszukiwaniu odpowiedniego pliku. Z każdym dniem społeczność pracująca nad OpenOCD uzupełnia zbiór plików konfiguracyjnych o nowe targety. Pozostałe linie mają składnię podobną do znanej z poprzednich wersji OpenOCD. Powodują one inicjalizację komunikacji z targetem oraz jego zresetowanie i wstrzymanie (3, 4). Flashowanie odbywa się dzięki komendzie zawartej w linii (5), której pierwszym parametrem jest operacja jaką wykonujemy na pamięci flash, po niej następuje nazwa pliku oraz offset od początku przestrzeni adresowej uC pod jaki zostaną zapisane dane. Linie (6, 7) kolejno resetują mikrokontroler i “wprawiają go w ruch” oraz kończą pracę OpenOCD. Jak wynika z załączonego przykładu skrypty, dzięki gotowym zbiorom plików konfiguracyjnych, uległy znacznemu uproszczeniu.

Skrypt służący do debugowania jest równie prosty co powyższy, używany do flashowania. Jego treść przedstawia się w sposób zgodny z przdestawionym na listingu:

source [find ./openocd-0.1.0/src/target/interface/turtelizer2.cfg] # (1)

# Change the default telnet port...
telnet_port 4444                     # (2)

# GDB connects here
gdb_port 3333                        # (3)

# GDB can also flash my flash!
gdb_memory_map enable                # (4)
gdb_flash_program enable             # (5)
gdb_breakpoint_override hard         # (6)

source [find ./openocd-0.1.0/src/target/target/sam7s64.cfg]        # (7)

init                                 # (8)

Przeznaczenie linii (1, 7) jest znane z poprzedniego skryptu. Linia (2) służy do konfiguracji portu na którym będzie nasłuchiwać OpenOCD. Linia (3) ustawia port pracy samego debuggera GDB. Linie (4, 5) umożliwiają programowanie pamięci flash uC z wykorzystaniem GDB. Linia (6) ustawia rodzaj stosowanych breakpoinów na breakpointy hardwareowe. Opcja ta jest niezbędna w momencie gdy firmware został zlinkowany tak by pracować w pamięci flash a nie w pamięci ram. Należy mieć świadomość, iż liczba jednocześnie stosowanych breakpointów hardwareowych jest bardzo ograniczona, a w przypadku AT91SAM7S64 wynosi dokładnie dwa. Linia (8) służy do uruchomienia procesu debugującego.

Tak przygotowany skrypt wyśmienicie współpracuje ze środowiskiem Eclipse. Konfigurację Eclipsa z doinstalowanym pluginem Zylin Embedded CDT rozpoczynamy od dodania nowej Debug Configuration typu Zylin Embedded Debug (Native). Należy wybrać nazwę projektu dla którego konfigurujemy debug oraz plik wykonywalny w formacie elf, który zawiera m. in. symbole niezbędne dla debugu. Plik taki powstaje każdorazowo w wyniku zlinkowania skompilowanych źródeł projektu.

Następnie przechodzimy do zakładki Debbuger, gdzie ustawiamy jako aplikację debugującą arm-elf-gcc lub innym, w zależności z jakich kompilatorów korzystamy. W zakładce Commands ustawiamy komendy wysyłane podczas inicjalizacji oraz samego uruchomienia trybu debug. Komendy, jakie należy umieścić w sekcji Initialize commands są następujące:

target remote localhost:3333
monitor reset halt

Sekcję ‘Run commands’ pozostawiamy pustą. Tak przygotowany Eclipse jest gotowy do odpluskwiania (ech…), zaraz po uruchomieniu opisanego wcześniej skryptu uruchamiającego debug mode.

Truly Integrated » SW

GCC i funkcje o zmiennej liczbie argumentów

USB JTAG i OpenOCD 0.1.0 + Eclipse