Truly Integrated » ARM

GPS Tracker

admin — Thu, 09 Jul 2009 08:47:46 +0000

Niedawno zakończyłem prace nad urządzeniem, które nazwałem GPS Tracker. Urządzenie to służy do raportowania pozycji samochodów ciężarowych lub osobowych, z wykorzystaniem pozycji z GPS, przesyłanej przez sieć GSM. Wykonanie zostało zlecone przez indywidualnego klienta.

Urządzenie wykorzystuje moduł SIM300D do wysyłania danych przez GPRS. Sam moduł jest rozwiązaniem dedykowanym zarówno do transmisji danych z wykorzystaniem wspomnianego GPRS jak również do transmisji głosu. Komunikacja z modułem odbywa się przy wykorzystaniu RS232 w pełnej 9-sygnałowej wersji. Umożliwia to sprawowanie kontroli nad szybkością transmisji. Do modułu podłączono złącze karty SIM z wyrzutnikiem. Antena jest przyłączona za pomocą gniazda SMA. Moduł został zakupiony w TME.

W roli uC zastosowałem AT91SAM7S64, gdyż takowy zalegał u mnie w warsztacie. Firmware został napisany z wykorzystaniem przerwań i timerów (i innych fajnych rzeczy..), tak aby uniknąć stosowania wielu procedur blokujących. Taka metoda pisana firmware w ostateczności przyczynia się do zmniejszenia awaryjności całego urządzenia, co jest szczególnie istotne w przypadku urządzenia do którego dostęp będzie później utrudniony.

Wykorzystany moduł GPS to FGPMMOSL1 zakupiony z Maritexu. Wybór został podyktowany tylko i wyłącznie ceną (: jednak zapewniam, iż moduł spisuje się bardzo dobrze, wraz z aktywną anteną można obierać sygnał z satelity w kamienicy (5m od okna), w której mieszkam. Moduł jest gotowy do pracy po ok. 30 sekundach od włączenia zasilania. Prędkość transmisji wynosi 9800 baud, jest więc dwukrotnie większa od standardowej prędkości protokołu NMEA. Z racji tego, że zastosowany AT91SAM7 dysponuje tylko dwoma USARTami, z czego jeden (USART1) jest podłączony do modułu GSM to linia TXD została wykorzystana do wysyłania komunikatów debugujących podczas gdy RXD jest podłączona do GPS. Takie współdzielenie linii jednego USART powoduje to, że debug pracuje z taką samą prędkością co GPS, zatem większa prędkość GPS oznacza w ostateczności przyspieszenie transmisji debugu.

Urządzenie zostało również wyposażone w złącze USB, które umożliwia konfigurację parametrów pracy całości. Firmware zapewnia obsługę urządzenia klasy CDC będącego, tym przypadku, zwykłym portem szeregowym. Warto zaznaczyć, że nie posiłkowałem się biblioteką Atmela dla USB, lecz klasę CDC napisałem całkowicie samodzielnie. (Nie jest to jedyna rzecz jaką implementowałem samodzielnie, nawet printf do debugu jest mój, co prawda nieco zubożony, ale taki właśnie miał być (: ).

Krótka specyfikacja:

Wymiary płytki: 64×50 [mm]
Wysokość najwyższego elementu: 12 [mm]
Średni pobór prądu: ~40 [mA]
Napięcie zasilania: od 5 do 35 [V]
Złącza: USB, Zasilanie, 2x SMA (GPS, GSM), JTAG (przystosowany do pracy z moim programatorkiem).
3 Diody sygnalizacyjne (NET – GPRS, PWR – Zasilanie, STAT – Status pracy)

Podstawowe problemy techniki

Najważniejszym elementem każdego urządzenia elektronicznego jest zasilacz, gdyż jak wiadomo 90% urządzeń działa lepiej gdy są poprawnie zasilone (:. Należy mieć na uwadze fakt, że podczas nadawania komunikatu przez moduł GSM pobór prądu może w szczycie osiągnąć 2A, dlatego konstrukcja zasilacza musi być dokładnie przemyślana. Ponadto należy uwzględnić to, że napięcie w instalacji ciężarówki wynosi 24V, zaś w samochodach osobowych występuje 12V. Wybór padł na układ LM2594 będący przetwornicą step-down. Wykorzystano wersję nieregulowaną, o napięciu wyjściowym wynoszącym 5V. Wykorzystanie wersji 3,3V nie wchodziło w grę, gdyż moduł SIM300D do poprawnej pracy wymaga przynajmniej 3,6V. Napięcie z przetwornicy jest obniżane do poziomu ok 3,8-3,9V za pomocą układu LM1117-3,3V, którego wyprowadzenie GND jest dołączone do masy urządzenia za pośrednictwem diody krzemowej. Aby umożliwić chwilowe pobranie dużych prądów urządzenie zostało wyposażone w baterię kondensatorów tantalowych 330uF. Na płytce przewidziano miejsce dla trzech takich kondensatorów, jednak empirycznie stwierdziłem, że dwa w zupełności wystarczą i moduł nie uskarża się na ‘under voltage operation’. Warto zwrócić uwagę na to czy scalak przetwornicy pracuje ze stałą czy zmienną częstotliwością kluczowania dławika. W przypadku zmiennej częstotliwości może (w momencie dużych obciążeń) dochodzić do efektów dzwiękowych w dławiku (:. Wybrany układ pracuje z częstotliwością stałą, wynoszącą 150kHz, tak więc zdecydowanie ponad pasmem akustycznym.

Bardzo ważnym aspektem jest zapewnienie odpowiedniej grubości ścieżek doprowadzających napięcie do modułu GSM. W przypadku za wąskich ścieżek i dużych poborów prądu następują niepożądane spadki napięć.

Jakie są potencjalne trudności podczas realizacji takiego projektu?

Pierwszą trudnością jest poprawna implementacja procedur obsługujących błędy pracy modułu GSM. Jeżeli urządzenie wisi w momencie gdy padł zasięg, to znaczy dokładnie tyle, że programista nie zadbał o jakość firmware. Braki zasięgu się zdarzają, szczególnie w sieci Orange.

Następnym problemem są ‘ginące’ pakiety w sieci GPRS. Należy zadbać o mechanizm potwierdzeń dostarczenia pakietów z danymi. Można wykorzystać protokół TCP zamiast UDP, ale nastręcza to dodatkowych problemów w momencie utraty zasięgu (trzeba na nowo ustanawiać połączenie socketów, a na serwerze socket cały czas zostaje otwarty) Na dobrą sprawę wystarczy UDP z prostym komunikatem potwierdzającym ze strony serwera.

Należy buforować dane, czasem utrata zasięgu może potrwać kilka minut, nie można dopuścić by dane nam wyparowały! w momencie powrotu zasięgu należy wysłać zgromadzoną paczkę danych. Serwer musi obsługiwać komunikaty zawierające informacje o kilku lokalizacjach. Komplikuje to protokół, ale tylko nieznacznie.

W przypadku utraty sygnału GPS, należy to sygnalizować do serwera jakimś prostym komunikatem (po co tracić pieniądze na nadmiarową ilość przesyłanych danych). Co nam daje taka informacja? Serwer wie, że urządzenie żyje, a problemy są przejściowe. Ponadto może wyświetlić komunikat o problemach z GPS.

Należy zaimplementować obsługę PIN. Kierowcy mają ciągoty do korzystania z kart SIM, znajdujących się w urządzeniu do wykonywania prywatnych rozmów (:.

Zaprojektowane urządzenie współpracuje aktualnie z aplikacją wykorzystującą Google Maps. Jest to najprostsza i dość niedoskonała metoda wizualizacji zgromadzonych informacji (niedokładność map). Warto zatem zastanowić się nad zakupem innych mapek.

Pytania? Wątpliwości?

To tyle ode mnie, jeśli ktokolwiek z Czytelników jest zainteresowany projektem to proszę o kontakt mailowy. Możliwe jest wykonanie większej liczby urządzeń, na specjalne zamówienie. Na zakończenie zamieszczam zdjęcie strony wierzchniej (GSM i GPS są przylutowane od spodu):

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.