79181 Image95 (3)

■ Programowanie

Tabela 11 Znaczenie sekcji .initO-9

Sekcja	Znaczenia
.initO	Jeśli p-ogramista stworzy funkcję_init() zostano ona wywołana wła§nie z tej sekcji. Po jej zakończeniu ub w przypadku jej braku program przechodzi dalej.
.initl	Do wykorz/stania przez orogramistę.
Init2	Inicjacja stosu 1 zerowanie rejestru_zero_reg_(rl)
.Init3	Do wykorz/stania przez programistę.
.Inlt4	inicjacja zmiennych globalnych oraz statycznych w sekcjach .data oraz bss
.lnit5	Do wykorz/stania przez programistę.
Init6	Wykorzystywana przez programy w C++ do wywołania niezbędnych konstruktorów.
.In!t7	Do wykorz/stania przez programistę.
.Init8	Do wykorz/stania przez programistę.
Init9	Skok do funkcji main()

Listing 151 Makro skoku do aplikacji

#define IMPjOO asm volatile("jmp 0"::)

Listing 149 Przesunięcie sekcji programu do obszaru BLS

♦ ---Linker Optiors------

k -Wl,...:    tell GCC to pass th-is to linker.

k -Map:    create map file

k -cref:    add cross reference to map file

LDFLAGS -Wl,-Map=$(TARGET).map,-cref LDFLAGS +- S(EXTMEMOPTS)

LDFLAGS += S(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

#    Przesuniecie sekcji programj do obszaru BLS LDFLAGS += -wl,-SeCtion-Start=.text=$(BOOTSTART)

Listing 159 Przeniesienie wektorów przerwań /} Aktywacja przesuwania wektorów przerwań gjcr * i«ivcb;

// Przeniesienie wektorów przerwań do BLS G3CR - i«ivsel;

Listing 152 Bufor a pamięci RAM na przesyłane dam: uint8_t g_pag©buff[SFM_PAGESI2E];

Listing 153 Obsługa zerowania WDT

VOid _init(void)_ottribute_((naked));

_actribute_((naked));

void imt(void)

{

1f(KCUCSR & 1«WDRF)

jmp oO;

domyślna inicjacja. Zajrzyj do tabeli 11. Opis sekcji .initO-9 pokazuje jednocześnie, co dzieje się z naszym programem po uruchomieniu. Zapamiętaj tę tabelkę. Zauważ jednocześnie, że co druga sekcja jest wolna. Umożliwia nam to umieszczenie własnej funkcji na dowolnym etapie uruchamiania systemu. Przekonamy się w przyszłości, że bywa to bardzo ważne.

To co jest dla nas ważne teraz, to fakt, że przy utworzonym przez nas programie, gdy uruchamiamy go w trybie bootloadera, przed wywołaniem funkcji boot nie jest wykonywana inicjacja stosu! Nasz program działa zgodnie z oczekiwaniami tylko dlatego, że jest bardzo prosty. Już wywołanie jakiejkolwiek innej funkcji z poziomu funkcji boot może sprawić, że procesor odmówi pracy. Nie jest to jedyna wada rozwiązania, ale wszystkie wynikają z tego, że staramy się pisać jednocześnie program bootioadera oraz samą aplikację. Takie działanie ma sens tylko w jednym przypadku: Jeśli chcemy, aby aplikacja mogła zapisywać do pamięci programu, możemy gdzieś na końcu sekcji bootloadera umieścić funkcję dająca taką możliwość (przypominam, że instrukcja SPM działa tylko z sekcji BLS). Do pisania funkcjonalnego bootloadera wygodnie jest podejść trochę inaczej.

Tym razem bootloader będziemy pisać jako samodzielną aplikację. Namówimy jedynie linker, aby umieścił cały program w wy-ranym miejscu pamięci. Można to zrobić w bardzo prosty sposób: przenieśmy całą sekcję ,text zgodnie z listingiem 149.

Teraz program bootloadera możemy pisać identycznie jak każdą inną aplikację. Niektórzy docenią także możliwość wykorzystania przerwań w bootloaderze.

Zanim uruchomimy przerwania

Bootloader to zwykle prosty program i zaprzęganie do jego działania przerwań często okazuje się zbędne. W przykładowych programach nie będziemy korzystali z tej możliwości. Chcę jednak zaznaczyć, że aby przerwania działały prawidłowo w programie ładującym, trzeba koniecznie przesunąć ich wektory na początek sekcji BLS. Musimy to

zrobić jeszcze przed ich aktywacją - najlepiej na samym początku funkcji main. W razie potrzeby, przesunięcie przerwań umożliwi prosty kod z listingu ISO.

Idea rozwiązania

Komunikacja z bootloaderem

Zanim zaczniemy tworzyć aplikację bootloa-dera, powinniśmy zastanowić się, jak chcemy się z nim komunikować. W naszym przypadku wykorzystamy interfejs RS232. Aby uruchomić bootloader, komputer musi, w czasie nie dłuższym niz sekunda od zerowania procesora, wysłać bajt tworzący znak *! \ Jeśli bajt taki zostanie odebrany, bootloader odpowiada znakiem potwierdzenia W tym momencie, aby wejść w tryb bootloadera konieczne jest przesłanie ciągu boot\n\ Bootloader odpowiada w taki sam sposób i od tej chwili przyjmuje już polecenia. Skomplikowanie wejścia do bootloadera. ma na celu uniknięcie przypadkowego jego włączenia.

Komendy mają postać pojedynczych liter. Obsługiwane będą następujące komendy: q wyjście z programu bootloadera i skok do aplikacji.

I - identyfikacja, mikrokontroler odpowiada łańcuchem z nazwą urządzenia; nazwa kończy się znakiem ‘\n\

v - wersja bootloadera; sterownik odpowia

Części wspólne

dla naszych bootloaderów

W naszym bootloaderze wykorzystamy utworzony w części 7 kursu prosty moduł obsługi portu RS232. Ze względu na zajmowane miejsce nie będę przedstawia! tutaj całego programu, posłużę się jedynie fragmentami. Cały kod jest dostępny na Elportalu.

Na listingu 151 widzimy makro wykonu jące skok do aplikacji Nie ma w nim nic magicznego, ale wygodniej w programie korzystać z makra niż powtarzać jawnie odpowiednią wstawkę asemblerową. Na listingu I52 tworzymy bufor na dane strony pamięci. Do obliczenia jego rozmiaru wyko rzystujemy stałą deklarowaną dzięki dołączeniu nagłówka <avr/io.h>, która określa roz miar strony pamięci w bajtach.

Chwilki wyjaśnienia wymaga listing 153. Utworzona w tym miejscu funkcja zapewnia, że jeśli wystąpiło zerowanie spowodowane przepełnieniem licznika WDT, natychmiast zostanie uruchomiona aplikacja. Gdy w programie pojawia

da dwoma bajtami w kodzie binarnym m - informacja o pamięci; sterownik podaje, w kodzie binarnym: rozmiar strony, liczbę stron możliwych do zaprogramania oraz licz bę stron w pamięci eeprom. w - zapis danych do bufora; dar.e przesyłane w postaci binamei.

r odczyt danych z bufora; dane przesyłane w postaci binarnej, f zapis bufora do pamięci flash e - zapis bufora do pamięci eeprom

Zwracam uwagę na brak możliwości odczytywania pamięci - to najlepsze zabezpieczenie przed kopiowaniem naszego kodu. Istnieje natomiast możliwość sprawdzenia danych wpisanych wcześniej do bufora. Daje to możliwość sprawdzenia, zanim prześlemy bufor do zapisania, czy w transmisji nie pojawiły się przekłamania

Jeśli sterownik wykryje nieznaną komendę, odpowiada znakiem zapytania. W programie przyjęto zasadę, żc tam gdzie należy potwierdzać dane, oznacza prawidłowe działanie a oznacza wystąpienie błędu (brak potwierdzenia).

42 Październik 2006 Elektronika dla Wszystkich