◦ Umieszczanie danych w pamięci FLASH
Wiemy już, że zarówno makro PROGMEM, jak i kwalifikator __flash oznaczają dane do zapisu w sekcji .progmem.data, którą później linker lokuje na początku pamięci FLASH. Nie każdy chyba jednak wie, że istnieją również kwalifikatory __flash1 __flash2 __flash3 __flash4 oraz __flash5 , które oznaczają dane do zapisu w sekcjach (odpowiednio) .progmem1.data .progmem2.data .progmem3.data .progmem4.data oraz .progmem5.data Przeznaczeniem poszczególnych sekcji powinny być kolejne 64KiB segmenty pamięci FLASH, czyli tak jak sekcja .progmem.data (__flash) jest zapisywana w pierwszym segmencie 64KiB (czyli o indeksie 0), tak sekcja .progmem1.data (__flash1) powinna być zapisana w drugim segmencie 64KiB (czyli o indeksie 1), sekcja .progmem2.data (__flash2) powinna być zapisana w trzecim segmencie 64KiB (czyli o indeksie 2) itd.
Napisałem, że powinny być, dlatego że tak naprawdę domyślne skrypty linkera (te dołączone do toolchain’u) obecnie nie wspierają tej techniki. Nie wiem tak do końca jaka jest tego przyczyna, prawdopodobnie nowe skrypty są nadal w fazie testów przed dopuszczeniem do powszechnego użycia. Dokładniejsze omówienie tematu skryptów linkera wykracza jednak poza zakres tak skromnego artykułu, więc nie będę się tutaj rozpisywał (choć oczywiście można o tym poczytać gdzie indziej i poeksperymetować). Póki co powinniśmy przyjąć, że niezależnie od numeru sekcji czy też kwalifikatora, linker i tak umieszcza wszystkie dane w sekcji .progmem.data Nie należy więc używać tych numerowanych kwalifikatorów (__flashN) do deklarowania danych we FLASH, dlatego że odczyt danych może być nieprawidłowy – dane mogą zostać zapisane w innym segmencie, niż kompilator będzie się ich spodziewał. Właściwie wspomniałem o nich, ponieważ mogą się one przydać w sytuacjach, kiedy dokładnie wiemy, gdzie dane zostaną umieszczone, ale o tym później.
Kiedy deklarujemy dużo danych do zapisu we FLASH, prędzej czy później może dojść do sytuacji, że ich łączny rozmiar plus to, co linker umieszcza przed tymi danymi (czyli np. wektory przerwań, ale czasami też inne sekcje) przekroczy limit 64KiB. Ważne jest, żebyśmy o tym wiedzieli. O ile możliwe jest (choć może być kłopotliwe) policzenie, ile zajmą nasze dane, o tyle trudno będzie przewidzieć rozmiar sekcji umieszczonych przed nimi.
Jak się dowiedzieć, czy przekroczyliśmy już limit 64KiB i którego bloku danych to ewentualnie dotyczy?
Możemy oczywiście przeanalizować plik *.map wygenerowany podczas budowania programu, jednak jest to mało wygodne i dość czasochłonne. Spróbujmy więc wydobyć te informacje bezpośrednio z pliku *.elf w inny sposób, używając do tego celu aplikacji avr-objdump.exe
Najpierw utworzymy plik o nazwie np. flashsymbols.bat zawierający tekst:
Code:
avr-objdump %1 -t | find "O .text" | sort
i zapisujemy w dogodnym dla siebie miejscu.
Atmel Studio 7
Wybieramy w menu:
Tools→External tools…
Pojawi się okno do konfiguracji narzędzi zewnętrznych. Klikamy na przycisk Add i wprowadzamy:
- w polu Title: Flash objects lub jaką nazwę kto woli,
- w polu Command: podajemy pełną ścieżkę do utworzonego wcześniej pliku *.bat
- w polu Arguments: $(TargetDir)$(TargetName).elf
- w polu Initial directory: podajemy pełną ścieżkę do folderu, w którym znajduje się plik avr-objdump.exe – w przypadku Atmel Studio 7 standardowo znajduje się w folderze:
C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\
(nie musimy nic wpisywać w Working directory, jeżeli mamy już ten folder dodany do zmiennej środowiskowej PATH w systemie Windows), - zaznaczamy tylko opcję: Use Output window, pozostałe pozostawiamy niezaznaczone.
Zatwierdzamy wszystko klikając na przycisk Apply, a później na OK. W menu Tools powinna się teraz pojawić nowa pozycja o nazwie, jaką wprowadziliśmy w polu Title.
Eclipse MARS 2
Wybieramy w menu:
Run→External Tools…→External Tools Configurations…
Pojawi się okno do konfiguracji narzędzi zewnętrznych. Po lewej stronie znajduje się pole z listą. Zwykle bezpośrednio po instalacji lista zawiera jeden wpis – Program. Zaznaczamy ten wpis. Nad listą powinien znajdować się wiersz pięciu ikonek. Klikamy na pierwszą od lewej (New launch configuration), po czym wpisujemy:
- w polu Name: Flash objects lub jaką nazwę kto woli,
- w polu Location: podajemy pełną ścieżkę do utworzonego wcześniej pliku *.bat
- w polu Working Directory: podajemy pełną ścieżkę do folderu, w którym znajduje się plik avr-objdump.exe – należy go szukać w podfolderze:
[toolchain_path]\avr8\avr8-gnu-toolchain\bin\
(nie musimy nic wpisywać w Working directory, jeżeli mamy już ten folder dodany do zmiennej środowiskowej PATH w systemie Windows), - w polu Arguments: ${project_loc}/${config_name:${project_name}}/${project_name}.elf
- wybieramy zakładkę Build i usuwamy lub pozostawiamy zaznaczenie przy Build before launch w zależności od własnych preferencji – kiedy opcja ta jest zaznaczona, w momencie uruchomienia naszego narzędzia zostanie najpierw wykonane budowanie programu; w przypadku pozostawienia tej opcji zaznaczonej zalecałbym wybranie opcji The project containing selected resource,
- wybieramy zakładkę Common i na liście Display in favorites menu robimy zaznaczenie przy External tools.
Zatwierdzamy klikając kolejno przyciski Apply i Close. Teraz gdy wybierzemy menu Run→External tools... powinniśmy zauważyć nową pozycję o nazwie wprowadzonej w polu Name podczas konfiguracji.
Dzięki zastosowaniu zmiennych środowiskowych nasze narzędzie będzie uniwersalne – nie trzeba będzie go konfigurować inaczej przy każdym kolejnym projekcie. Z drugiej jednak strony należy pamiętać (dotyczy Eclipse), że w momencie uruchomienia narzędzia musimy mieć wybrany właściwy projekt (i konfigurację Debug/Release). Jeśli spróbujemy uruchomić nasze narzędzie, kiedy np. będzie akurat aktywne okno konsoli, operacja zakończy się błędem.
Efekt działania naszego narzędzia będzie widoczny w Atmel Studio 7 w oknie Output, natomiast w Eclispe w oknie Console i będzie wyglądał mniej więcej tak (oczywiście rekordów będzie zapewne więcej):
Code:
000000e4 g O .text 00000014 pgm_string
000000f8 g O .text 00000007 pgm_array
Znaczenie poszczególnych kolumn jest następujące:- adres w pamięci FLASH w postaci liczby szesnastkowej,
- literka g oznacza symbol globalny,
- literka O oznacza, że jest to obiekt (a nie na przykład jedna z funkcji, które też przecież są umieszczane w pamięci FLASH),
- .text oznacza sekcję w której znajduje się obiekt,
- liczba w postaci szesnastkowej oznaczająca rozmiar,
- nazwa symbolu, czyli nazwa stałej zadeklarowana przez nas w kodzie.
WAŻNE:
Na podstawie uzyskanych w ten sposób informacji możemy odpowiednio zmieniać definicje i sposób odczytu naszych danych. Niestety istnieje tutaj pewna niedogodność niezależna od użytej metody obsługi naszych danych (PROGMEM czy __flash). W miarę rozbudowy naszego programu, kiedy będziemy dodawali nowe bloki danych do pamięci FLASH, może zmieniać się kolejność ich rozmieszczenia, przez co może być konieczne ponowne modyfikowanie programu adekwatnie do nowych adresów początkowych i końcowych. Zwykle dane są umieszczane we FLASH w odwrotnej kolejności, niż są zadeklarowane, więc dodawanie nowych danych zawsze przed wcześniej zdefiniowanymi powinno nas uchronić od problemów, ponieważ nowe dane zostaną dołączone na końcu i adresy poprzednich się nie zmienią. Nadal jednak pozostaje problem, gdy dane będziemy deklarować w innych plikach *.c – decyduje wtedy kolejność kompilacji, której nie mamy pod kontrolą korzystając z automatycznie generowanego pliku Makefile.
Na dodatek trzeba też uważać na opcje kompilatora. Przykładowo wyłączenie optymalizacji (czyli ustawienie poziomu optymalizacji na -O0 np. na potrzeby debugowania) może spowodować zmianę kolejności rozmieszczenia danych we FLASH i co za tym idzie nieprawidłowy ich odczyt.
Zapewne skrypt linkera, który umieszczałby dane w odpowiednich sekcjach __flashN w dużej mierze wyeliminowałby powyższe problemy. Póki co trzeba sobie jednak radzić w inny sposób. Dobrym sposobem na uzyskanie kontroli nad rozmieszczenie danych może być tworzenie własnych sekcji w obszarze pamięci FLASH, ale o tym później. Najpierw spróbuję pokazać, jak to zrobić przy zastosowaniu standardowych, lepiej wszystkim znanych metod.
- Definicja przy pomocy atrybutu PROGMEM
Stosując PROGMEM, dane definiujemy tak samo, niezależnie od tego w jakim segmencie 64KiB się znajdą. Tutaj różnica będzie polegać tylko na sposobie odczytu tych danych. Jeśli choćby jeden bajt zdefiniowanego przez nas obszaru danych we FLASH znajdzie się poza pierwszym segmentem 64KiB, należy przyjąć, że obszar taki będzie wymagał specjalnego traktowania, czyli odczytu poprzez tzw. „dalekie wskaźniki” (ang. „far pointers”). „Dalekie” ponieważ ich rozmiar jest 32-bitowy, więc mogą wskazywać na adresy położone „daleko”, czyli poza pierwszym segmentem 64KiB.
Stwórzmy wstępnie taki oto przykładowy kod, nie uwzględniający jeszcze rozmieszczenia danych we FLASH:
[syntax=c]#include <avr/io.h>
#include <avr/pgmspace.h>
#define MAX_SIZE PTRDIFF_MAX
// definiujemy dwie duże tablice danych
const uint16_t pgm_array1[MAX_SIZE/sizeof(uint16_t)] PROGMEM = {0};
const uint8_t pgm_array2[MAX_SIZE] PROGMEM = {0};
int main(void)
{
uint16_t i;
while (1)
{
for (i=0; i<MAX_SIZE/sizeof( pgm_array1[0] ); i++)
{
PORTB = pgm_read_word(&pgm_array1[i]);
}
for (i=0; i<MAX_SIZE; i++)
{
PORTC = pgm_read_byte(&pgm_array2[i]);
}
}
}[/syntax]
W celu sprawdzenia rozmieszczenia danych w naszym programie, najpierw wydajemy polecenie budowania (Build→Build Solution [F7] w Atmel Studio, lub Project→Build project w Eclipse), a następnie uruchamiamy nasze narzędzie (znajdujące się w menu Tools w Atmel Studio lub w menu Run→External tools w Eclipse). W wyniku tej operacji w oknie Output w Atmel Studio lub w oknie Console w Eclipse powinniśmy otrzymać następujący tekst:
Code:
000000cc g O .text 00007fff pgm_array2
000080cb g O .text 00007ffe pgm_array1
Oznacza to, że nasza tablica pgm_array2 została umieszczona pod adresem 0xCC i ma rozmiar 0x7FFF, natomiast tablica pgm_array1 została umieszczona pod adresem 0x80CB i ma rozmiar 0x7FFE. Wszystkie wartości podane są w systemie szesnastkowym. Można oczywiście przekształcić je na system dziesiętny, jednak moim zdaniem lepiej dokonać obliczeń w systemie szesnastkowym, gdyż łatwiej wtedy ocenić przekroczenie limitu. Obecnie chyba każdy kalkulator posiada opcję obliczeń w systemie szesnastkowym, więc nie powinno to sprawić większego problemu.
„Far pointer” jest wymagany zawsze wtedy, kiedy adres końcowy zdefiniowanego przez nas bloku danych jest większy od maksymalnej wartości, jaką może przyjąć liczba całkowita szesnastobitowa bez znaku, czyli od 0xFFFF (65535). W systemie szesnastkowym jest to największa liczba, jaką można zapisać za pomocą czterech cyfr, więc każdy adres składający się z większej ilości cyfr (nie licząc poprzedzających ją zer nieznaczących) oznacza przekroczenie limitu (w systemie dziesiętnym ta granica nie jest tak oczywista).
Ze względu na to, że nasze narzędzie nie podaje adresu końcowego musimy go obliczyć. Robimy to za pomocą wzoru:
adres_końcowy = adres_początkowy + rozmiar – 1
więc dla pgm_array2 adres końcowy będzie równy (obliczenia oczywiście w systemie szesnastkowym):
CC + 7FFF - 1 = 80CA
Widzimy, że adres ten jest czterocyfrowy, co oznacza, iż mieści się w zakresie liczby szesnastobitowej, możemy w takim przypadku do odczytu takiego bloku danych używać makr z grupy pgm_read_xxx(), które jako argument przyjmują adres szesnastobitowy.
Liczymy teraz adres końcowy dla tablicy pgm_array1:
80CB + 7FFE - 1 = 1 00C8
Jak widać adres (w systemie szesnastkowym) ostatniego elementu tablicy jest pięciocyfrowy. Oznacza to, że nie da się go zaadresować za pomocą 16-bitowego wskaźnika. W związku z tym do odczytu elementów tej tablicy nie można użyć makra pgm_read_word(), ponieważ obsługuje ono tylko adres szesnastobitowy. Zamiast tego należy zastosować makro pgm_read_word_far(). Makro to jednak wymaga wskaźnika 32-bitowego, więc nie można użyć zwyczajnie operatora & do pobrania adresu odczytywanych danych, ponieważ wynikiem takiej operacji będzie wskaźnik 16-bitowy. Do pobrania adresu 32-bitowego trzeba użyć makra pgm_get_far_address().
Biorąc pod uwagę powyższe wymagania okazuje się, że napisany przez nas wcześniej kod odczytujący elementy tablicy pgm_array1 nie będzie działał prawidłowo. Powinien on wyglądać następująco:
[syntax=c]#include <avr/io.h>
#include <avr/pgmspace.h>
#define MAX_SIZE PTRDIFF_MAX
// definiujemy dwie duże tablice danych
const uint16_t pgm_array1[MAX_SIZE/sizeof(uint16_t)] PROGMEM = {0};
const uint8_t pgm_array2[MAX_SIZE] PROGMEM = {0};
int main(void)
{
uint16_t i;
// definiujemy "far pointer" i przypisujemy mu adres pierwszego elementu
uint_farptr_t array1_ptr = pgm_get_far_address(pgm_array1[0]);
while (1)
{
for (i=0; i<MAX_SIZE/sizeof( pgm_array1[0] ); i++)
{
PORTB = pgm_read_word_far( array1_ptr );
// do ‘wskaźnika’ dodajemy rozmiar elementu (wytłumaczenie poniżej)
array1_ptr += sizeof( pgm_array1[0] );
}
for (i=0; i<MAX_SIZE; i++)
{
PORTC = pgm_read_byte(&pgm_array2[i]);
}
}
}[/syntax]
Dopiero teraz tablica pgm_array1 będzie odczytywana prawidłowo.
Należy tutaj zwrócić tutaj uwagę na pewien istotny fakt. Wskaźniki w avr-gcc mają rozmiar 16 bitów, co nie jest wystarczające do zaadresowania danych znajdujących się poza granicą 64KiB. Dlatego też należałoby użyć typu o większym zasięgu, czyli np. wskaźników 32-bitowych. Jednakże uint_farptr_t (zwracany przez makro pgm_get_far_address()) tak naprawdę nie jest wskaźnikem tylko typem całkowitym 32-bitowym. Jest to istotne ze względu na arytmetykę wskaźników. W przypadku prawdziwego wskaźnika, operacja array2_ptr++ spowodowałaby zwiększenie wartości wskaźnika o 2, ponieważ elementy tablicy są dwubajtowe, więc adres kolejnego elementu jest zawsze większy o 2 od adresu poprzedniego. Jednak ze względu na to, że array2_ptr jest typu uint_farptr_t, operacja taka nie zwróci prawidłowego rezultatu – po prostu wartość zmiennej zostanie powiększona o 1, niezależnie od tego, jaki jest rozmiar elementów tablicy. Programista musi więc osobiście zadbać o prawidłowe obliczanie adresu, dlatego właśnie należy zastosować inny sposób obliczenia adresu (podczas inkrementacji wskaźnika), na przykład:
array2_ptr += sizeof( pgm_array2[0] );
Znając powyższe zasady można sobie poradzić z zapisem i odczytem danych za pomocą makr z pliku nagłówkowego pgmspace.h, choć każdy chyba przyzna, że jest to dość kłopotliwe.
- Definicja przy użyciu kwalifikatorów __flash i __memx
Podobnie jak poprzednio stwórzmy wstępnie kod, nie biorący pod uwagę granicy 64KiB:
[syntax=c]#include <avr/io.h>
#include <avr/pgmspace.h>
#define MAX_SIZE PTRDIFF_MAX
// definiujemy dwie duże tablice danych (oczywiście w rzeczywistości
// powinny one zawierać dane - tutaj dla testu inicjujemy zerami)
const __flash uint16_t pgm_array1[MAX_SIZE/sizeof(uint16_t)] = {0};
const __flash uint8_t pgm_array2[MAX_SIZE] = {0};
int main(void)
{
uint16_t i;
while (1)
{
for (i=0; i<MAX_SIZE/sizeof(pgm_array1[0]); i++)
{
PORTC = pgm_array1[i];
}
for (i=0; i<MAX_SIZE; i++)
{
PORTB = pgm_array2[i];
}
}
}[/syntax]
W celu sprawdzenia rozmieszczenia danych uruchamiamy nasze narzędzie (tak jak poprzednio – patrz wyżej), w wyniku czego w oknie Output w Atmel Studio lub w oknie Console w Eclipse powinno pojawić co następuje:
Code:
000000cc g O .text 00007fff pgm_array2
000080cb g O .text 00007ffe pgm_array1
W tym przypadku to tablica pgm_array1 wykracza poza limit 64KiB, więc trzeba zmienić kod tak, by odczyt danych był prawidłowy. Tym razem jednak będzie to o wiele prostsze. Wystarczy bowiem w deklaracji tablicy pgm_array1 zamienić kwalifikator __flash na kwalifikator __memx:
[syntax=c]const __memx uint16_t pgm_array1[MAX_SIZE/sizeof(uint16_t)] = {0};[/syntax]
i to wszystko, co musimy zrobić. Reszta kodu może pozostać bez zmian. Zastosowanie kwalifikatora __memx zamiast __flash spowoduje następujące zmiany w kodzie wynikowym kompilatora:- wskaźnik na elementy tablicy jest 24-bitowy, dzięki czemu jego zasięg się zwiększa,
- rejestr RAMPZ jest ustawiany adekwatnie do potrzeb,
- instrukcja LPM zostaje zamieniona na instrukcję ELPM, która pozwala prawidłowo odczytywać dane z całego zakresu pamięci FLASH.
