Ćwiczenie D2:
P
AKIET
OPROGRAMOWANIA
C
ODE
C
OMPOSER
S
TUDIO
DLA
PROCESORÓW
SYGNAŁOWYCH
TMS320
SERII
28
XX
-
WPROWADZENIE
opracował:
mgr inż. Roman Niestrój
Roman.Niestroj@polsl.pl
Cele ćwiczenia:
–
poznanie podstawowych właściwości pakietu CCSv3.3PL;
–
poznanie obsługi urządzeń peryferyjnych w języku C;
–
poznanie struktury obiektów programowych;
–
poznanie podstawowych możliwości emulacji sprzętowej
w trybie czasu rzeczywistego.
Wstęp
Code Composer Studio to zintegrowane środowisko programowe, umożliwiające opracowywanie
i uruchamianie programów w języku asembler oraz C dla procesorów sygnałowych produkowanych
przez firmę Texas Instruments. Środowisko to łączy w sobie wszystkie elementy potrzebne do
utworzenia i uruchomienia programu wykonywalnego, czyli: edytor tekstowy, kompilator, asembler,
linker, archiwer, sterowniki emulacyjne, narzędzia wspomagające tworzenie systemów operacyjnych
czasu rzeczywistego, narzędzia do programowania pamięci Flash, zestawy sterowników dla różnych
urządzeń dołączanych do procesorów sygnałowych, itd. Wybrane elementy głównego okna programu
Code Composer Studio przedstawiono na rysunku 1. Podstawowe właściwości tego środowiska
zostaną przedstawione na przykładzie prostego programu, opracowanego na potrzeby ćwiczenia.
Program ten wykorzystuje jedno przerwanie, a jego działanie polega na obsłudze diody LED,
umieszczonej na płytce zestawu uruchomieniowego. W czasie ćwiczenia program ten zostanie
rozbudowany o obsługę stycznika. Do obsługi diody LED i stycznika wykorzystany zostanie system
uniwersalnych wejść i wyjść cyfrowych (GPIO – General Purpose Input Output). Programowa
obsługa diody LED i stycznika zrealizowana będzie za pomocą obiektów programowych,
utworzonych w języku C. Do uruchomienia programu zostanie wykorzystana emulacja sprzętowa.
Rys. 1. Wybrane elementy głównego okna CCS
Okno do
szukania
symboli
Kontrola
poleceń
GEL
Edytor kodu
źródłowego
Menedżer
projektu
(plików)
Okno
informacyjne
Polecenia
menu GEL
Emulacja sprzętowa - wprowadzenie
Procesory sygnałowe z rodziny C2000 wyposażone są w specjalną jednostkę sprzętową,
umożliwiającą zaawansowaną emulację, która jest pomocna przy uruchamianiu i testowaniu
programów. Emulacja ta odbywa się przez port JTAG ze specjalnym rozszerzeniem firmy Texas
Instruments. Kontroler portu JTAG zainstalowany na płytce eZdspF2812 jest podłączony do
komputera nadrzędnego przez port równoległy (LPT). Podstawowe cechy emulacji sprzętowej to:
•
możliwość nieinwazyjnego dostępu do pamięci wewnętrznej i zewnętrznej oraz do wszystkich
rejestrów jednostki centralnej CPU i urządzeń peryferyjnych;
•
możliwość przerwania działania programu (ang. background code) bez zatrzymywania obsługi
przerwań czasowo-krytycznych (ang. foreground code, time-critical interrupt) poprzez
wprowadzenie procesora w stan wstrzymania (ang. debug-halt state) za pomocą specjalnego
zdarzenia emulacyjnego (ang. break-event);
•
nieinwazyjne określenie statusu (stanu pracy) procesora;
•
szybki transfer danych pomiędzy pamięcią procesora a komputerem nadrzędnym;
•
kontrola czasu wykonywania fragmentów programu za pomocą licznika cykli maszynowych.
Praca z emulacją sprzętową odbywa się przez wymuszanie w środowisku CCS różnych zdarzeń
emulacyjnych (ang. debug-events). Sekwencje zdarzeń emulacyjnych można zapisywać za pomocą
specjalnej składni w plikach skryptowych z rozszerzeniem .gel. Umożliwia to automatyzację zadań
emulacyjnych i łatwy do nich dostęp poprzez menu GEL w środowisku CCS.
Przy pracy z emulacją sprzętową dostępne są dwa tryby pracy procesora:
•
Stop Mode, który umożliwia przejęcie pełnej kontroli nad procesorem, łącznie z możliwością
zablokowania systemu przerwań do czasu, aż wykonywanie programu zostanie wznowione;
•
Real-Time Mode, który umożliwia wstrzymanie działania programu z jednoczesną, pełną
obsługą przerwań czasowo-krytycznych; tryb ten włącza się w menu Debug środowiska CCS;
jest on wykorzystywany na przykład przy uruchamianiu układów sterowania maszyn
elektrycznych, urządzeń energoelektronicznych, itp., czyli wszędzie tam, gdzie wymagana jest
pewna sekwencja zdarzeń (działań procesora) następujących w równych odstępach czasu.
Do komunikacji z pamięcią procesora oraz rejestrami jednostki centralnej CPU i urządzeń
peryferyjnych wykorzystywany jest „mechanizm” DT-DMA (ang. Debug-and-Test Direct Memory
Access). DT-DMA korzysta z tych samych magistral procesora co jednostka centralna CPU.
Dostępne są dwa tryby pracy DT-DMA:
•
nieinwazyjny, w którym DT-DMA czeka, aż magistrale procesora zostaną w sposób naturalny
zwolnione przez jednostkę centralną CPU (tzn. kiedy pojawi się „dziura” w wykorzystaniu
magistral, ang. hole) i dopiero wtedy przeprowadza transfer danych;
•
inwazyjny, w którym DT-DMA wymusza na jednostce centralnej CPU zwolnienie magistral
i przeprowadza transfer danych.
Emulację sprzętową wykorzystuje się w środowisku CCS na różne sposoby między innymi przy
korzystaniu z dodatków takich jak Watch Window, wyświetlacze graficzne, podglądu zawartości
pamięci i rejestrów, zrzutu zawartości pamięci do pliku, oraz przy obsłudze w programie punktów
testowych (ang. break-point, probe-point), wymuszaniu pracy krokowej procesora, itp.
Rys. 2. Wybrane elementy CCS do testowania i uruchamiania programów
Podgląd
zawartości
pamięci
Interpretacja
zawartości
pamięci
programu
Podgląd
zmiennych
(Watch Window)
Podgląd
rejestrów
rdzenia
Podgląd
rejestrów
statusowych
Wyświetlacz
graficzny
Polecenia
menu Debug
Menedżer
punktów
testowych
Punkt
testowy
w kodzie
źródłowym
Wybrane elementy CCS w ćwiczeniu D2*
W ćwiczeniu zostaną wykorzystane następujące elementy okna głównego:
•
menu File/Workspace/Load Workspace – załadowanie przestrzeni roboczej programu
(z pliku .wks);
•
menu File/Load Program – załadowanie programu do pamięci procesora sygnałowego
(z pliku .out);
•
menu Edit/Find i menu Edit/Find/Replace – wyszukiwanie i wyszukiwanie z zamianą w kodzie
źródłowym, pomocne przy edycji kodu źródłowego;
•
menu View/Memory, View/Disassembly, View/Registers/CPU Registers, View/Registers/Status
Registers, View/Graph/Time/Frequency, View/Watch Window, View/Symbol Browser,
View/Project, View/Mixed Source/ASM – otwiera okna odpowiednio: podglądu pamięci,
podglądu programu w języku asembler (odczytanego z pamięci programu), podglądu rejestrów
rdzenia, podglądu rejestrów statusowych, wyświetlacza graficznego, podglądu zmiennych
w programie, wyszukiwarki symboli, menedżera projektu (plików dołączonych do projektu),
podglądu kodu źródłowego w trybie języka C lub w trybie mieszanym (polecenia języka C
i odpowiadające im instrukcje asemblera);
•
menu Project/Add Files to Project – dodaje pliki do projektu;
•
menu Project/Build – kompilacja aktualnego pliku źródłowego;
•
menu Project/Rebuild All – kompilacja całego projektu;
•
menu Project/Scan All File Dependencies – skanuje wszystkie zależności pomiędzy plikami
i dołącza do projektu pliki nagłówkowe, wykorzystywane w plikach źródłowych (przez dyrektywę
#include);
•
menu Debug/Breakpoints – otwiera okno menedżera punktów testowych;
•
menu Debug/Run i Debug/Halt – uruchomienie i zatrzymanie programu;
•
menu Debug/Reset CPU – reset procesora sygnałowego (przez emulację);
•
menu Debug/Real-time Mode – włącza tryb emulacji w czasie rzeczywistym;
•
menu GEL – uruchamianie poleceń zdefiniowanych w plikach skryptowych .gel
wspomagających uruchamianie programu przez automatyzację niektórych zadań emulacyjnych;
w każdym ćwiczeniu dostępny będzie odpowiedni plik .gel z definicją poleceń wspomagających
wykonanie ćwiczenia (np. „lab_d2.gel” dla ćwiczenia D2) zebranych w menu
GEL/Ćwiczenie Dx (gdzie: x=2,5,6);
•
menu Help/User Manuals – uruchamia system pomocy z podręcznikami dla procesorów
sygnałowych i narzędzi do programowania.
Okno menedżera projektu zawiera następujące elementy:
•
katalog GEL Files – lista wczytanych plików skryptowych .gel;
•
katalog Projects – lista otwartych projektów (plików .pjt);
•
podkatalog nazwany nazwą projektu, opisany wytłuszczoną czcionką (np.
lab_d2_eZdspF2812_CCS3x.pjt dla ćwiczenia D2) – zawiera listę wszystkich składników
projektu (tych, które stanowią elementy programu, jak również elementów dodatkowych),
posegregowanych w podkatalogach; zawiera również listę wykorzystywanych plików
konfiguracyjnych linkera (plików .cmd – u dołu listy);
•
podkatalog Dependent Projects – zawiera listę projektów zależnych;
•
podkatalog Documents – zawiera listę dokumentów dodatkowych (nie podlegających
kompilacji);
•
podkatalog DSP/BIOS Config – zawiera konfigurację systemu DSP/BIOS wspomagającego
tworzenie systemów czasu rzeczywistego (nie używane w ćwiczeniu);
•
podkatalog Generated Files – może zawierać pliki generowane podczas kompilacji projektu;
•
podkatalog Include – zawiera listę wykorzystywanych plików nagłówkowych (plików .h);
•
podkatalog Libraries – zawiera listę wykorzystywanych bibliotek (plików .lib);
•
podkatalog Source – zawiera listę wykorzystywanych plików źródłowych (plików .c i .asm).
Wybrane właściwości edytora kodu źródłowego:
•
kolorowanie składni (definiowane przez użytkownika);
•
system podpowiedzi dla typów strukturalnych, ułatwiający wyszukiwanie pól struktur;
•
system podpowiedzi ułatwiający odnajdywanie definicji funkcji, typów zmiennych i sprawdzanie
wartości stałych preprocesora;
Wybrane właściwości okna podglądu zmiennych w programie (Watch Window):
•
zakładka Watch Locals – umożliwia podgląd zmiennych lokalnych;
•
zakładka lad_d2 (dla ćwiczenia D2) – umożliwia podgląd zmiennych globalnych;
•
kolumny Name, Value, Type, Radix – zawierają nazwę, wartość, typ, format wybranych
zmiennych; wartości tych zmiennych można edytować w komórkach tabeli zmiennych;
•
funkcje Refresh, Continuous Refresh w menu kontekstowym – odświeżenie jednorazowe lub
ciągłe odświeżanie okna (ponowne odczytanie wartości wszystkich zmiennych z pamięci
procesora sygnałowego); funkcje te dostępne są też dla wyświetlaczy graficznych w ich menu
kontekstowych;
•
funkcja Freeze Window w menu kontekstowym – „zamrożenie” zawartości okna;
•
funkcje Add Tab, Edit Tab, Delete Tab w menu kontekstowym – dodaje, zmienia nazwę lub
kasuje zakładkę w oknie Watch Window;
•
funkcja Add to Watch Window w menu kontekstowym – dodaje podgląd zmiennej, zaznaczonej
w oknie edytora kodu źródłowego;
•
funkcja Add Globals to Watch – otwiera listę umożliwiającą wybór zmiennych globalnych do
podglądania w oknie Watch Window.
System uniwersalnych wejść i wyjść cyfrowych
Wykorzystywany podczas ćwiczenia procesor sygnałowy TMS320F2812 ma wewnętrzny, bardzo
rozbudowany system uniwersalnych wejść i wyjść cyfrowych. Przeznaczenie tego systemu nie jest
z góry określone. Może on posłużyć do obsługi, za pomocą sygnałów cyfrowych, różnych zadań
w cyfrowym układzie sterowania. Każde wejście lub wyjście cyfrowe w tym systemie reprezentowane
jest przez jeden bit w odpowiednim rejestrze procesora. Wszystkie wejścia lub wyjścia cyfrowe
podzielone są na grupy oznaczone literami A, B, C, ...,G. Każdą grupę obsługuje osobny zestaw
rejestrów. Ze względu na ograniczoną liczbę końcówek zewnętrznych procesora, sygnały systemu
GPIO są multipleksowane z innymi sygnałami, wyprowadzonymi na te końcówki. Na rysunku 3
przedstawiono schemat blokowy systemu GPIO. Elementy systemu GPIO pełnią następujące funkcje:
•
MUX – służy do przełączania końcówki procesora (PIN) pomiędzy sygnałami systemu wejść
i wyjść cyfrowych (Digital I/O) a sygnałami systemu wewnętrznych urządzeń peryferyjnych
(Peripheral I/O).
•
GPxMUX – zestaw rejestrów służących do sterowania multiplekserami MUX; jeżeli dowolny bit
w którymś z tych rejestrów jest ustawiony na 0, to odpowiadający mu PIN przyłączony jest do
systemu wejść i wyjść cyfrowych (Digital I/O). Jeżeli bit ten ustawiony jest na 1, to PIN
przyłączony jest do systemu wewnętrznych urządzeń peryferyjnych (Peripheral I/O).
•
GPxDIR – zestaw rejestrów służących do sterowania kierunkiem transmisji danych przez PIN
przyłączony do systemu wejść i wyjść cyfrowych. Jeżeli dowolny bit w którymś z tych rejestrów
jest ustawiony na 0, to odpowiadający mu PIN jest wejściem cyfrowym. Jeżeli bit ten ustawiony
jest na 1, to PIN jest wyjściem cyfrowym.
•
GPxDAT/SET/CLEAR/TOOGLE – zestawy rejestrów związanych z danymi przesyłanymi przez
uniwersalne wejścia i wyjścia cyfrowe. Do rejestru GPxDAT zapisuje się stany wyjść cyfrowych
i odczytuje się z niego stany wejść cyfrowych. Rejestry GPxSET/CLEAR/TOOGLE służą
odpowiednio do: ustawienia na 1, ustawienia na 0, zmiany na przeciwny stanu wyjść cyfrowych
przez zapisanie 1 do odpowiednich bitów tych rejestrów.
•
Input qualification – jest to „mechanizm” zabezpieczający przed odbieraniem przypadkowych,
bardzo krótkich impulsów (zakłóceń) przez system wejść cyfrowych. Impuls zostanie
zaakceptowany, jeżeli czas jego trwania będzie dłuższy od 6 okresów sygnału SYSCLKOUT
(zegara systemowego).
•
GPxQUAL – zestaw rejestrów decydujących o okresie próbkowania wejść cyfrowych.
Końcówki zewnętrzne procesora, w zależności od sytuacji, mogą pozostawać w stanie wysokiej
impedancji. Gdy końcówki te ustawione są jako wejścia cyfrowe, trzeba pamiętać o wewnętrznych
rezystorach podłączonych pomiędzy te wejścia a masę lub napięcie zasilające (pullup, pulldown).
Rys. 3. Struktura systemu GPIO
Aby wykorzystać system GPIO (lub jakiekolwiek inne wewnętrzne urządzenie peryferyjne procesora),
trzeba ustawić wartości w jego rejestrach konfiguracyjnych. Dla jednego urządzenia może istnieć
kilka różnych rejestrów o ściśle określonych funkcjach. Wszystkie te rejestry są rozmieszczone
w pewnym obszarze wewnętrznej pamięci RAM procesora, to znaczy fizycznie stanowią one komórki
pamięci danych (mówi się, że są mapowane w pamięci danych). W języku C opracowano wygodny
sposób konfigurowania tych rejestrów. Każdy rejestr reprezentowany jest przez odpowiednią
strukturę o nazwie takiej, jak nazwa tego rejestru, przy czym każde pole tej struktury reprezentuje
jeden bit rejestru (lub w szczególnych przypadkach kilka bitów jednocześnie). Nazwy pól
odpowiadają nazwom poszczególnych bitów. Dzięki utworzeniu dla każdej takiej struktury unii
składającej się z dwóch pól: „all” i „bit”, istnieje możliwość zapisu lub odczytu tylko wybranych
bitów rejestru lub jednocześnie całego rejestru. Dla zwiększenia wygody poszczególne unie zebrano
w grupy. Grupy te także są strukturami i przechowują w kolejnych polach unie, odpowiadające
rejestrom dla poszczególnych urządzeń peryferyjnych a ich nazwy są intuicyjne, związane z nazwami
tych urządzeń. Dla każdej grupy uni tworzy się odrębną sekcję, którą później umieszcza się
w wyznaczonym obszarze pamięci procesora (tam, gdzie są mapowane rejestry reprezentowane przez
te struktury). Oczywiście ważna jest kolejność ułożenia poszczególnych pól w strukturze
i poszczególnych unii w grupie. Musi ona odpowiadać kolejności ułożenia odpowiadających im
rejestrów w pamięci procesora tak, żeby po załadowaniu programu każda struktura trafiła na
odpowiednie miejsce. Struktury, unie i grupy dla systemu GPIO, dla wszystkich rejestrów,
zdefiniowane są w pliku nagłówkowym „DSP281x_Gpio.h”. Utworzone zostały dwie grupy. Pierwsza
nazwana „GpioMuxRegs” grupuje rejestry GPxMUX/DIR/QUAL. Druga grupa, nazwana
„GpioDataRegs” grupuje rejestry GPxDAT/SET/CLEAR/TOGGLE (gdzie x to A, B, C, ...,G).
W pliku „DSP281x_GlobalVariableDefs.c” dla tych grup utworzono sekcje nazwane
„GpioDataRegsFile” i „GpioMuxRegsFile”. Przydział obszarów pamięci dla tych sekcji określono
w pliku konfiguracyjnym linkera „DSP281x_Headers_nonBIOS.cmd”. Sekcja „GpioDataRegsFile”
jest ładowana do obszaru pamięci „GPIODAT” zaczynającego się od adresu 0x0070E0 a sekcja
„GpioMuxRegsFile” jest ładowana do obszaru pamięci „GPIOMUX” zaczynającego się od adresu
0x0070C0 (każdy obszar o długości 0x000020 słów bitowych). Strukturę wymienionych plików
przedstawiono na rysunku 4.
Rys. 4. Struktura plików wspomagających obsługę rejestrów urządzeń peryferyjnych
DSP281x_Gpio.h
(definicja struktur,
unii i grup)
DSP281x_GlobalVariableDefs.c
(utworzenie sekcji
dla grup)
DSP281x_Headers_nonBIOS.cmd
(przydział obszarów pamięci
dla sekcji)
Zawartość pliku nagłówkowego „DSP281x_Gpio.h” (fragmenty):
//----------------------------------------------------
// GPIO A mux control register bit definitions
//
//
struct
GPAMUX_BITS
{
Uint16 PWM1_GPIOA0
:
1
;
// 0
Uint16 PWM2_GPIOA1
:
1
;
// 1
Uint16 PWM3_GPIOA2
:
1
;
// 2
Uint16 PWM4_GPIOA3
:
1
;
// 3
Uint16 PWM5_GPIOA4
:
1
;
// 4
Uint16 PWM6_GPIOA5
:
1
;
// 5
Uint16 T1PWM_GPIOA6
:
1
;
// 6
Uint16 T2PWM_GPIOA7
:
1
;
// 7
Uint16 CAP1Q1_GPIOA8
:
1
;
// 8
Uint16 CAP2Q2_GPIOA9
:
1
;
// 9
Uint16 CAP3QI1_GPIOA10
:
1
;
// 10
Uint16 TDIRA_GPIOA11
:
1
;
// 11
Uint16 TCLKINA_GPIOA12
:
1
;
// 12
Uint16 C1TRIP_GPIOA13
:
1
;
// 13
Uint16 C2TRIP_GPIOA14
:
1
;
// 14
Uint16 C3TRIP_GPIOA15
:
1
;
// 15
}
;
union
GPAMUX_REG
{
Uint16 all;
struct
GPAMUX_BITS bit;
}
;
//----------------------------------
// GPA Qualregister bit definitions
struct
GPAQUAL_BITS
{
Uint16 QUALPRD
:
8
;
// 0:7
Uint16 rsvd1
:
8
;
// 15:8
}
;
union
GPAQUAL_REG
{
Uint16 all;
struct
GPAQUAL_BITS bit;
}
;
//-----------------------------------------
struct
GPIO_MUX_REGS
{
union
GPAMUX_REG GPAMUX;
union
GPADIR_REG GPADIR;
union
GPAQUAL_REG GPAQUAL;
Uint16 rsvd1;
union
GPBMUX_REG GPBMUX;
union
GPBDIR_REG GPBDIR;
union
GPBQUAL_REG GPBQUAL;
Uint16 rsvd2[
5
];
union
GPDMUX_REG GPDMUX;
union
GPDDIR_REG GPDDIR;
union
GPDQUAL_REG GPDQUAL;
Uint16 rsvd3;
union
GPEMUX_REG GPEMUX;
union
GPEDIR_REG GPEDIR;
union
GPEQUAL_REG GPEQUAL;
Uint16 rsvd4;
union
GPFMUX_REG GPFMUX;
union
GPFDIR_REG GPFDIR;
Uint16 rsvd5[
2
];
union
GPGMUX_REG GPGMUX;
union
GPGDIR_REG GPGDIR;
Uint16 rsvd6[
6
];
}
;
//------------------------------------------
// GPI/O External References & Function Declarations:
extern volatile struct
GPIO_MUX_REGS GpioMuxRegs;
Definicja
struktury
GPAMUX_BITS
dla rejestru
GPAMUX
Budowa
rejestru
GPAMUX
Budowa
rejestru
GPAQUAL
Bity
rsvd1
zarezerwowane
(niedostępne)
Budowa grupy
rejestrów
GPIO Mux
Definicja struktury
GPIO_MUX_REGS
dla grupy rejestrów
GPIO Mux
Definicja unii
GPAMUX_REG
dla rejestru
GPAMUX
Definicja unii
GPAQUAL_REG
dla rejestru
GPAQUAL
Deklaracja
zmiennej globalnej
GpioMuxRegs
typu
GPIO_MUX_REGS
przechowującej
ustawienia
rejestrów
Rejestr
rsvd1
zarezerwowany
(niedostępny)
Grupa
rsvd2
pięciu rejestrów
zarezerwowanych
(niedostępnych)
Definicja
struktury
GPAQUAL_BITS
dla rejestru
GPAQUAL
Pole
PWM1_GPIOA0
jest jednobitowe
Pole
QUALPRD
jest ośmiobitowe
Zawartość pliku źródłowego „DSP281x_GlobalVariableDefs.c” (fragment):
#include
"DSP281x_Device.h"
//---------------------------------------------------
#ifdef
__cplusplus
#pragma
DATA_SECTION(
"GpioMuxRegsFile"
)
#else
#pragma
DATA_SECTION(GpioMuxRegs,
"GpioMuxRegsFile"
);
#endif
volatile struct
GPIO_MUX_REGS GpioMuxRegs;
W przedstawionych fragmentach programów przyjęto następujące konwencje zapisu:
•
nazwy struktur, unii i pól bitowych pisane są wielkimi literami
(np.: GPIO_BITS, PWM1_GPIOA0);
•
nazwy definiowanych typów zmiennych pisane są wielkimi literami
(np.: GPIO_MUX_REGS);
•
nazwy zmiennych oraz nazwy sekcji pisane są na przemian wielkimi i małymi literami
(np.: GpioMuxRegs, GpioMuxRegsFile);
•
nazwy obszarów pamięci w plikach konfiguracyjnych linkera pisane są wielkimi literami (np.:
GPIOMUX);
•
dla licz heksadecymalnych obowiązuje następujący format zapisu:
0xwwwwwwww (dla liczb 32-bitowych) i 0xwwww (dla liczb 16-bitowych), gdzie w to wartość
jednej cyfry heksadecymalnej; przykłady: 0x000070C0, 0x12AB;
•
w liczbach ułamkowych obowiązuje kropka dziesiętna (a nie przecinek);
•
znak mnożenia zapisuje się ze spacją ponieważ zapisany bez spacji traktowany jest jak wskaźnik
( a
∗
b – mnożenie, a *b – próba interpretacji przez kompilator jako wskaźnik).
Firma Texas Instruments udostępnia biblioteki plików nagłówkowych i programów konfiguracyjnych
dla wszystkich rejestrów urządzeń peryferyjnych i pozostałych rejestrów, oraz dla konfiguracji
tablicy wektorów przerwań. W bibliotekach tych zastosowano nazwy bitów, rejestrów, grup
rejestrów, obszarów pamięci, i inne takie, jak w dokumentacji procesora sygnałowego, co ułatwia
korzystanie z tych bibliotek.
Struktury, unie i pola bitowe w języku C – definicje i wyjaśnienia
„Struktura jest obiektem złożonym z jednej lub kilku zmiennych, być może różnych typów, dla wygody zgrupowanych pod jedną
nazwą. (W niektórych językach, takich jak Pascal, struktury są nazywane „rekordami”.) Struktury ułatwiają zorganizowanie
skomplikowanych danych, szczególnie w dużych programach, ponieważ grupę związanych ze sobą zmiennych pozwalają
traktować jak jeden obiekt, a nie jak zestaw oddzielonych obiektów. (...)”
„Unia jest zmienną, która (w różnych momentach) może zawierać obiekty różnych typów i rozmiarów, przy czym to kompilator
dba o zadośćuczynienie wymaganiom dotyczącym rozmiaru i położenia w pamięci. Unie pozwalają manipulować danymi różnego
rodzaju w tym samym miejscu pamięci bez wprowadzania do programu informacji o ich cechach zależnych od maszyny
(komputera, procesora – przyp. autora). Unie są podobne do rekordów wariantowych w Pascalu. (...) Taki właśnie jest cel unii –
udostępnić jedną zmienną, która jest uprawniona do przechowywania wartości kilku różnych typów (np.: dla unii GPAMUX_REG:
typu Uint16 w polu „all” i typu strukturalnego GPAMUX_BITS w polu „bit” - przyp. autora). Składnia unii jest wzorowana na
strukturach. (...)”
„Polem bitowym, lub krócej polem, jest zbiór przylegających do siebie bitów, znajdujących się w jednej, zależnej od
implementacji, jednostce pamięci zwanej „słowem”. Składnia definicji pola i odwołania do pola jest wzorowana na strukturach. (...)
Liczba występująca po dwukropku oznacza rozmiar pola w bitach. Pola zadeklarowano jako unsigned int (w niniejszej instrukcji
jako Uint16 jak np. dla PWM1_GPIOA0 – przyp. autora), aby zagwarantować, że są wielkościami bez znaku. (...)”
Źródło cytatów: B.W.Kernighan, D.M.Ritchie: „Język ANSI C”. WNT, Warszawa 1999.
Składnia dla C++
Składnia dla C
Utworzenie sekcji
DATA_SECTION
(sekcji danych)
za pomocą
dyrektywy
#pragma
Nazwa sekcji
danych
Nazwa zmiennej
umieszczanej
w sekcji danych
Kompilacja zależna od
użytej składni
(dla języka C lub C++)
Dołączenie pliku
nagłówkowego biblioteki
konfiguracyjnej
Umieszczenie
zmiennej globalnej
GpioMuxRegs
w utworzonej
sekcji danych
Zawartość pliku konfiguracyjnego linkera „DSP281x_Headers_nonBIOS.cmd” (fragment):
M
E
M
O
R
Y
{
P
A
G
E
0
:
/
*
P
r
o
g
r
a
m
M
e
m
o
r
y
*
/
P
A
G
E
1
:
/
*
D
a
t
a
M
e
m
o
r
y
*
/
S
C
I
A
:
o
r
i
g
i
n
=
0
x
0
0
7
0
5
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
X
I
N
T
R
U
P
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
7
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
G
P
I
O
M
U
X
:
o
r
i
g
i
n
=
0
x
0
0
7
0
C
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
G
P
I
O
D
A
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
E
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
A
D
C
:
o
r
i
g
i
n
=
0
x
0
0
7
1
0
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
}
S
E
C
T
I
O
N
S
{
/
*
*
*
P
e
r
i
p
h
e
r
a
l
F
r
a
m
e
1
R
e
g
i
s
t
e
r
S
t
r
u
c
t
u
r
e
s
*
*
*
/
S
c
i
a
R
e
g
s
F
i
l
e
:
>
S
C
I
A
,
P
A
G
E
=
1
X
I
n
t
r
u
p
t
R
e
g
s
F
i
l
e
:
>
X
I
N
T
R
U
P
T
,
P
A
G
E
=
1
G
p
i
o
M
u
x
R
e
g
s
F
i
l
e
:
>
G
P
I
O
M
U
X
,
P
A
G
E
=
1
G
p
i
o
D
a
t
a
R
e
g
s
F
i
l
e
:
>
G
P
I
O
D
A
T
P
A
G
E
=
1
A
d
c
R
e
g
s
F
i
l
e
:
>
A
D
C
,
P
A
G
E
=
1
}
W
pl
ik
u
ź
ródł
ow
ym
„
D
SP
281x
_G
lobal
V
ar
iabl
eD
ef
s.
c”
je
st
:
#
p
r
a
g
m
a
D
A
T
A
_
S
E
C
T
I
O
N
(
G
p
i
o
M
u
x
R
e
g
s
,
"
G
p
i
o
M
u
x
R
e
g
s
F
i
l
e
"
)
;
v
o
l
a
t
i
l
e
s
t
r
u
c
t
G
P
I
O
_
M
U
X
_
R
E
G
S
G
p
i
o
M
u
x
R
e
g
s
;
(32)
1
0
=
(0x000020)
1
6
Mapa pamięci
procesora
sygnałowego
TMS320F2812
Obszar w pamięci
danych, gdzie
umieszczone są
rejestry urządzeń
peryferyjnych
(Frame 2)
Zawartość
obszaru Frame2
w pamięci danych
Sekcja
MEMORY
pliku *.cmd
zawierająca definicję
mapy pamięci procesora
sygnałowego
Sekcja
SECTIONS
pliku *.cmd
zawierająca informację
o rozlokowaniu sekcji
programu w pamięci
procesora sygnałowego
Adres
początku
obszaru
Długość
obszaru
Nazwa
obszaru
PAGE
=
0
– pamięć programu
PAGE
=
1
– pamięć danych
Nazwy sekcji
programu
umieszczanych
w pamięci
Ta, z pozoru skomplikowana, obsługa rejestrów urządzeń peryferyjnych, jest jednak bardzo prosta
i wygodna w użyciu. Aby, na przykład, ustawić w programie wyjście cyfrowe GPIOF14 na 1 piszemy
po prostu:
GpioDataRegs.GPFDAT.bit.GPIOF14 = 1;
Podobnie, aby ustawić wszystkie wyjścia grupy B wejść lub wyjść na 0, piszemy:
GpioDataRegs.GPBDAT.all = 0;
CCS ma wbudowany system podpowiedzi, wspomagający operowanie na nazwach grup i struktur.
Użyta w zestawie uruchomieniowym dioda LED podłączona jest do wyjścia GPIOF14. Układ
sterowania stycznika jest podłączony przez układ izolacji galwanicznej modułu mocy DMC1500 do
wyjścia cyfrowego GPIOB0. Kontrolę załączenia stycznika można zrealizować przez wejście cyfrowe
GPIOE0 również podłączone przez moduł DMC1500.
Obiekty programowe
Obiekt programowy składa się z danych i funkcji dostępu do tych danych (metod). Graficzną
reprezentację obiektu programowego przedstawia rysunek 5.
Rys. 5. Obiekt programowy
Obiekty reprezentowane są w programie przez struktury, których pola zawierają zarówno dane tych
obiektów, jak i wskaźniki do funkcji operujących na tych danych (przy czym wskaźnik do funkcji to
adres początku tej funkcji w pamięci programu). W obrębie jednego programu może współistnieć
wiele obiektów tego samego typu, ale operujących na innych zestawach danych za pomocą tych
samych funkcji (to znaczy w polach struktur przechowujących dane będą inne wartości, ale wskaźniki
funkcji do operowania na tych danych będą takie same we wszystkich obiektach). Obiekty definiuje
się w języku C zazwyczaj za pomocą dwóch plików. Pierwszy z nich to plik nagłówkowy, zawierający
definicję typu struktury (określający nazwy i rodzaj pól struktury), definicję typu wskaźnikowego dla
struktury (ułatwiającego posługiwanie się tą strukturą w programie), definicję stałej preprocesora
służącej do inicjalizacji obiektu (ustalenia jego początkowego stanu), oraz prototypy funkcji, które
będą powiązane z obiektem (będą operować na jego danych). Drugi plik (źródłowy) zawiera definicje
(programy) tych funkcji. Sposób definiowania obiektu zostanie przedstawiony na przykładzie obiektu
obsługi diody LED. Obiekt ten będzie miał 5 danych i 4 funkcje operujące na tych danych (czyli
w sumie 9 pól o różnej długości słów bitowych). Dane obiektu są następujące:
•
Threshold – wartość progowa licznika opóźnienia, po przekroczeniu której stan diody ulega
zmianie (liczba Uint32, czyli 32-bitowa całkowita bez znaku).
•
Step – skok (jednorazowe zwiększenie wartości) licznika opóźnienia (liczba Uint32, czyli 32-
bitowa całkowita bez znaku).
•
Counter – licznik opóźnienia migania diody; jest wprowadzony po to, żeby program obsługi
diody LED, działający w cyklu przerwań (o znacznej częstotliwości), nie powodował zbyt
szybkiego migania diody (liczba Uint32, czyli 32-bitowa całkowita bez znaku).
•
Enable – załącza (jeśli 1) lub wyłącza (jeśli 0) miganie diody (liczba Uint16, czyli 16-bitowa
całkowita bez znaku).
•
State – aktualny stan diody (a raczej wyjścia GPIOF14) (liczba Uint16, czyli 16-bitowa
całkowita bez znaku).
Funkcje operujące na danych obiektu są następujące:
•
init – funkcja inicjalizacyjna, ustawia rejestry systemu GPIO.
•
update – funkcja obsługi diody; obsługuje licznik opóźnienia (pole Counter) i zmienia stan
diody (pole State).
Nazwa
grupy
rejestrów
Nazwa
rejestru
Zapis
bitowy
Nazwa pola
bitowego
rejestru
Wartość
wpisana
Dane obiektu
Funkcja 1
Funkcja 2
Fu
nk
cj
a
3
Fu
nk
cj
a
4
•
enable – funkcja włączająca miganie diody (ustawia pole „Enable” na 1).
•
disable – funkcja wyłączająca miganie diody (ustawia pole „Enable” na 0).
Wskaźniki do wyżej wymienionych funkcji to 32-bitowe adresy początków tych funkcji w pamięci
programu. Typ obiektu zostanie nazwany „LEDSUPPORT”. Definicja obiektu do obsługi diody LED
została przedstawiona poniżej.
Zawartość pliku nagłówkowego „led_eZdspF2812.h”:
#ifndef
__LED_H__
#define
__LED_H__
/
*-------------------------------------------------------------------
Definicja typu obiektu LEDSUPPORT.
--------------------------------------------------------------------
*/
typedef struct
{
Uint32 Threshold;
Uint32 Step;
Uint32 Counter;
Uint16 Enable;
Uint16 State;
void
(*init)();
void
(*update) ();
void
(*enable) ();
void
(*disable) ();
}
LEDSUPPORT;
typedef
LEDSUPPORT *LEDSUPPORT_handle;
/
*-------------------------------------------------------------------
Domyślna inicjalizacja obiektu LEDSUPPORT.
--------------------------------------------------------------------
*/
#define
LEDSUPPORT_DEFAULTS
{
0
,
0
,
0
,
0
,
0
, \
(
void
(*)(Uint32))led_init, \
(
void
(*)(Uint32))led_update, \
(
void
(*)(Uint32))led_enable, \
(
void
(*)(Uint32))led_disable
}
/
*-------------------------------------------------------------------
Prototypy funkcji znajdujących się w LED_eZdspF2812.C
--------------------------------------------------------------------
*/
void
led_init(LEDSUPPORT_handle);
void
led_update(LEDSUPPORT_handle);
void
led_enable(LEDSUPPORT_handle);
void
led_disable(LEDSUPPORT_handle);
#endif
// __LED_H__
Zawartość pliku źródłowego „led_eZdspF2812.c” (skrót):
// Dołączenie plików nagłówkowych
#include
"DSP281x_Device.h"
#include
"led_eZdspF2812.h"
#include
<
stdlib.h
>
// Funkcja inicjalizacyjna
void
led_init(LEDSUPPORT *l)
{
(Tutaj program funkcji)
}
// Funkcja obsługi diody LED
void
led_update(LEDSUPPORT *l)
{
(Tutaj program funkcji)
}
Nazwa typu obiektu
Typ wskaźnikowy dla
obieku
Nazwy i typy pól
danych obiektu
Pola wskaźników
funkcji obsługi (metod)
obiektu
Wstępne wypełnienie
pól danych obiektu
Umieszczenie wskaźników
do funkcji obsługi (metod)
w polach wskaźników
Stała preprocesora
(konstruktor) do
inicjalizacji obiektu
Prototypy funkcji obsługi
operujących na danych
obiektu (metod)
Definicje (programy)
funkcji obsługi
operujących na danych
obiektu (metod)
Dyrektywy zapewniające
jednokrotne przetworzenie pliku
podczas kompilacji
// Funkcja włączająca miganie diody LED
void
led_enable(LEDSUPPORT *l)
{
l
->
Enable
=
1;
}
// Funkcja wyłączająca miganie diody LED
void
led_disable(LEDSUPPORT *l)
{
l
->
Enable
=
0;
}
Zapis „l
->
Enable
=
0;” widoczny w dwóch ostatnich funkcjach oznacza wpisanie wartości 1
lub 0 do pola „Enable” obiektu, którego wskaźnik został przekazany jako argument funkcji (obiekt
ten wewnątrz funkcji widoczny jest jako „l”) . W celu użycia obiektu o zdefiniowanym typie
w programie głównym należy dołączyć do niego plik nagłówkowy z definicją typu obiektu (raz, na
początku pliku z programem głównym) a następnie utworzyć obiekt, nadając mu nazwę (na przykład
„led1”) i wypełniając jego pola wartościami początkowymi w następujący sposób:
// Dodanie pliku nagłówkowego obiektu LEDSUPPORT
#include
"led_eZdspF2812.h"
// Utworzenie obiektu dla obsługi diody LED
LEDSUPPORT led1
=
LEDSUPPORT_DEFAULTS;
Następnie należy skonfigurować utworzony obiekt, na przykład w następujący sposób:
// Konfiguracja obiektu led1;
led1.Step
=
262144
;
// skok licznika opóźnienia
led1.Threshold
=
2147483648
;
// wartość progowa licznika opóźnienia
led1.init(&led1);
// inicjalizacja obiektu
led1.enable(&led1);
// włączenie migania diody LED
W razie potrzeby można utworzyć inny obiekt tego samego typu (ale o innej nazwie), który może być
inaczej skonfigurowany:
// Utworzenie obiektu dla obsługi diody LED
LEDSUPPORT led2
=
LEDSUPPORT_DEFAULTS;
Po utworzeniu i skonfigurowaniu obiektu obsługa diody LED polega na cyklicznym wydawaniu co
jakiś czas (w pętli lub w podprogramie obsługi przerwania) następującego polecenia:
// Obsługa migania diody LED
led1.update(&led1)
W analogiczny sposób można utworzyć obiekty opracowując program cyfrowego układu sterowania,
gdzie kolejne obiekty mogą stanowić na przykład: regulatory, bloki transformacji, generatory
przebiegów, sterowniki współpracujące z układami pomiarowymi, itd. Obiekty te mogą być
sterownikami ułatwiającymi korzystanie z urządzeń peryferyjnych (jak na przykład obsługa diody
LED przez system GPIO), lub mogą mieć charakter czysto obliczeniowy (jak na przykład regulator,
filtr cyfrowy, generator przebiegów).
Elementy interfejsu użytkownika w menu GEL
W języku skryptowym General Extension Language dla plików .gel istnieje możliwość definiowania
podstawowych elementów wirtualnego interfejsu użytkownika, które dają możliwość interaktywnego
wpływania na pracę procesora sygnałowego z poziomu CCS przez przypisywanie wartości zmiennym
w programie wykonywanym przez procesor. Dostępne są następujące elementy:
Typ obiektu
Nazwa obiektu
Wartości
początkowe pól
obiektu
(konstruktor)
Wskaźnik do struktury
przechowującej obiekt
Zapisanie
pól danych
obiektu
Wywołanie funkcji
obsługi (metody)
obiektu
•
polecenie menu GEL;
przykładowy wygląd:
przykładowa składnia:
menuitem
"Ćwiczenie D2"
;
// Definicja polecenia menu GEL
// Pasek rozdzielający
hotmenu
_______________________1________________________()
{}
// Polecenie menu „Ćwiczenie D2”
hotmenu
Odblokowanie_programu()
{
EnableFlag
=
1;
// Przypisz 1 do zmiennej EnableFlag
}
•
suwak;
przykładowy wygląd:
przykładowa składnia:
// Argumenty: min., maks., krok1, krok2, zmienna wyjściowa
slider
Czestotliwosc_migania(
10000
,
400000
,
1000
,
1000
, step)
{
led1.Step
=
step;
}
•
okno dialogowe;
przykładowy wygląd:
przykładowa składnia:
// Argumenty: zmienna wyjściowa 1, opis pola 1,
// zmienna wyjściowa 2, opis pola 2.
dialog
Otworz_plik(filename
"Nazwa ('\\'->'\\\\'):"
, filetype
"Typ pliku (1-5):"
)
{
GEL_Halt();
GEL_ProbePtDel(ramdumplabel);
GEL_AddOutputFile(ramdumplabel, filename, filetype,
"&databuffer"
,
"0x1000"
,
1
);
GEL_Reset();
GEL_Run();
}
Plik „lab_d2.gel” opracowany dla ćwiczenia D2 wykorzystuje polecenia menu GEL, między innymi
do ładowania i uruchamiania programu oraz suwaki do regulacji częstotliwości migania diody, czyli
zmiany zawartości pola „Step” obiektu „led1” oraz, w analogiczny sposób, do zmiany częstotliwości
pracy stycznika.
Struktura katalogów projektu do ćwiczenia D2
Projekty opracowywane w środowisku CCS zapisywane są w drzewie katalogów o specjalnej
strukturze. Strukturę tego drzewa i zawartość niektórych katalogów przedstawiono na rysunku 6.
Katalog „tidcs” mieści się na dysku „C:\” w katalogu głównym. Po zakończeniu ćwiczenia należy
zrobić kopię CAŁEGO katalogu „tidcs” w katalogu „C:\Dydaktyka”, uprzednio zmieniając nazwę
na właściwą danej sekcji. Katalog „tidcs” można archiwizować w formie skompresowanej, co
przyśpieszy ten proces (kopiowanie wielu pojedynczych plików wchodzących w skład struktury
projektu jest powolne). Wszystkie pliki edytowane w czasie ćwiczenia zapisywane są w formacie
tekstowym (z różnymi rozszerzeniami). Można je modyfikować w dowolnym edytorze tektu (na
przykład w notatniku systemu operacyjnego).
Rys. 6. Struktura katalogów projektu do ćwiczenia D2
Zachowanie w niezmienionej formie struktury katalogów przedstawionej na rysunku 6 jest konieczne
ze względu na ustawienia kompilacji, wykonane dla każdego projektu.
Podczas realizacji zadań związanych z ćwiczeniem D2, będą wykorzystywane następujące pliki
wchodzące w skład przygotowanego projektu „lab_d2_eZdspF2812_CCS3x.pjt”:
•
„build.h” – plik nagłówkowy projektu, definiujący najważniejsze parametry realizowanego
systemu;
•
„led_eZdspF2812.h” – plik nagłówkowy z definicją obiektu obsługi diody LED;
•
„led_eZdspF2812.c” – plik źródłowy zawierający programy funkcji (metod) obiektu dla obsługi
diody LED;
•
„lab_d2.c” – główny plik źródłowy projektu;
•
„lab_d2_eZdspF2812.cmd” – plik konfiguracyjny linkera dla projektu.
Pliki te zostały szczegółowo skomentowane, co ułatwia zrozumienie ich struktury i działania. Dla
każdego projektu przygotowany został plik przestrzeni roboczej, który wczytuje się do CCS przez
menu „File/Workspace/Load Workspace”. Dla ćwiczenia D2 plik ten nosi nazwę
„lab_d2_eZdspF2812_CCS3x.wks”. Wczytanie pliku przestrzeni roboczej powoduje otwarcie
właściwego projektu i elementów CCS, skonfigurowanych na potrzeby ćwiczenia (wyświetlaczy
graficznych, okna Watch Window, itd.). Opcjonalnie można otworzyć wyłącznie sam projekt przez
załadowanie pliku projektu „lab_d2_eZdspF2812_CCS3x.pjt” w menu „Project/Load”.
Wszystkie pliki projektu można otwierać przez dwukrotne kliknięcie na ich nazwie w oknie menedżera
projektu. Nowe pliki źródłowe dodaje się do projektu przez menu „Project/Add Files to Project”.
Pliki nagłówkowe dodawane są automatycznie po uruchomieniu skanowania zależności pomiędzy
plikami („Project/Scan All Files Dependencies”). Po dodaniu do projektu, plik pojawi się we
właściwym katalogu w oknie menedżera projektu. W przypadku utworzenia nowego pliku .gel należy
go dołączyć do przestrzeni roboczej CCS przez menu kontekstowe katalogu „GEL Files” w oknie
menedżera projektu, uruchamiając polecenie „Load GEL”. W przypadku, gdy istniejący plik .gel
zostanie zmodyfikowany, należy go przeładować poleceniem „Reload”, dostępnym w menu
kontekstowym pliku .gel w oknie menedżera projektu.
katalog główny
biblioteki konfiguracyjne dla procesorów 281x
procedury konfiguracyjne procesora (także dla przerwań)
przykłady konfiguracji procesora
pliki nagłówkowe
katalog bibliotek
katalog projektów
katalog projektów do Laboratorium Procesorów Sygnałowych
katalog projektu do ćwiczenia D2
pliki: projektu (*.pjt), przestrzeni roboczej (*.wks), wykonywalny (*.out)
pliki konfiguracyjne linkera (*.cmd) specyficzne dla projektu
pliki skryptowe menu GEL (*.gel) specyficzne dla projektu
pliki nagłówkowe (*.h) specyficzne dla projektu
pliki obiektowe (*.obj) tworzone przez asembler
pliki źródłowe (*.c, *.asm) specyficzne dla projektu
dokumentacja projektu
Zadanie 1.
Uruchomić przykładowy program w środowisku Code Composer Studio.
Należy uruchomić środowisko CCS a następnie wczytać przygotowany plik przestrzeni roboczej.
Następnie należy zapoznać się z poleceniami dostępnymi w menu GEL dla projektu do ćwiczenia D2,
skompilować i uruchomić program (w trybie Real-Time) sterujący diodą LED na płytce zestawu
uruchomieniowego. Po uruchomieniu programu należy odczytać i zmienić wartości wybranych
zmiennych programu za pomocą okna Watch Window i dostępnych poleceń menu GEL.
Wskazówki do wykonania zadania 1:
Do wykonania zadań w ćwiczeniu D2 została przygotowana przestrzeń robocza zapisana w
pliku „lab_d2_eZdspF2812_CCS3x.wks”. Przestrzeń robocza zawiera skonfigurowane elementy
środowiska CCS, takie jak Watch Window lub Graph. Wszystkie działania określone w zadaniu
1 można uruchomić, wykorzystując standardowe menu CCS (zgodnie z opisem w rozdziale
„Wybrane elementy CCS w ćwiczeniu D2”) lub przez menu GEL (konfigurowane przez
użytkownika za pomocą języka skryptowego GEL). Po załadowaniu i uruchomieniu programu
„lab_d2.out” należy obserwować zawartość okienka Watch Window w trybie ciągłego
odświerzania - „Continuous Refresh” (tryb uruchamiany prawym klawiszem myszki w oknie
Watch Window). Widoczne będą tylko zmiany zmiennej BackTicker. Program działa, ale czeka
na decyzję, którą podejmuje się za pomocą zmiennej EnableFlag. Po wprowadzeniu wartości 1
dla tej zmiennej (w okienku Watch Window), program uruchomi się we właściwy sposób.
Widoczne będą zmiany kilku zmiennych: BackTicker (sygnalizują działanie pętli głównej
programu), IsrTicker (sygnalizują działanie systemu przerwań) oraz zmiennej (obiektu)
led1, który służy do obsługi migania diody LED na płytce zestawu eZdsp. Należy rozwinąć
podgląd pól obiektu led1 (znak „+” obok nazwy obiektu) i zaobserwować zmiany zawartości
pól danych. Następnie należy wypróbować możliwości wpływania na pracę programu przez
emulację sprzętową, zmieniając zawartość pola led1.Step (wpłynie to na częstotliwość
migania diody). Zmianę można wykonać ręcznie (w okienku Watch Window) lub przez suwak
dostępny w menu GEL\Ćwiczenie_D2\Czestotliwosc_migania.
Zadanie 2.
Przeanalizować obsługę urządzeń peryferyjnych i obiektów programowych.
Należy przeanalizować zawartość plików wskazanych w rozdziałach „System uniwersalnych wejść
i wyjść cyfrowych” oraz „Obiekty programowe” w celu poznania obsługi rejestrów urządzeń
peryferyjnych i obiektów programowych.
Wskazówki do wykonania zadania 2:
W okienku Watch Window wpisać w wolne pole nazwy przykładowych struktur obsługujących
rejestry
peryferyjne
(np.
„EvaRegs.T1CNT”
dla
licznika
GPT1,
„GpioDataRegs.GPFDAT.bit.GPIOF14” dla wyjścia systemu GPIO, sterującego diodą LED).
Wystarczy wpisać tylko nazwę struktury (pierszy człon nazwy). Resztę uzyskuje się przez
rozwijanie struktur i unii w okienku Watch Window (znaki „+” przy nazwach struktur i
unii). Zaobserwować zmiany w polach struktur i unii.
Zadanie 3.
Opracować program w języku C dla procesora TMS320F2812, realizujący obsługę stycznika.
Opracowany program powinien zawierać definicję typu obiektu obsługi stycznika (plik
nagłówkowy .h oraz źródłowy .c dołączony do projektu). Ponadto należy utworzyć obiekt i
zrealizować jego obsługę w głównym pliku źródłowym projektu „lab_d2.c”. Obsługa stycznika
powinna być zrealizowana w podprogramie obsługi przerwania głównego i powinna polegać na jego
cyklicznym załączaniu i wyłączaniu w ustalonych odstępach czasu. Opracowany program należy
uruchomić i przetestować wykorzystując emulację sprzętową. Ponadto należy rozbudować menu GEL
o dodatkowe polecenia do obsługi stycznika (podobne jak dla diody LED). Rozbudowa menu GEL
powinna być wykonana w pliku „lab_d2.gel” lub w osobnym pliku .gel dołączonym do przestrzeni
roboczej CCS.
Wskazówki do wykonania zadania 3:
Opracowując program obiektu obsługi stycznika należy wykorzystać pliki definiujące obiekt
obsługi diody LED, zapisując je z innymi nazwami (np. „stycznik.h”, „stycznik.c”)
i dołączając do projektu. Następnie należy w nich przeprowadzić niezbędne modyfikacje,
czyli zmienić nazwę typu obiektu oraz nazwy funkcji (metod) dla obiektu. Nazwy pól danych
i wskaźników funkcji powinny pozostać bez zmian. Modyfikacje głównego pliku źródłowego
można uprościć, kopiując fragmenty programu obsługujące obiekt dla diody LED i dokonując
w nich niezbędnych modyfikacji. Analogicznie można wykonać rozbudowę poleceń menu GEL
w pliku „lab_d2.gel”.
Do wykonania ćwiczenia potrzebny jest komputer z CCS i zestaw uruchomieniowy eZdspF2812 wraz
z modułem mocy DMC1500. Dodatkowo: stycznik z elektronicznym układem sterującym. W czasie
wykonywania ćwiczenia uczestnicy mogą korzystać z literatury dostarczanej przez prowadzącego,
oraz systemu pomocy CCS z podręcznikami dla wykorzystywanego procesora sygnałowego
i środowiska do programowania.
Sprawozdanie z ćwiczenia
Sprawozdanie z ćwiczenia powinno zawierać kody źródłowe programów napisanych w trakcie
ćwiczenia wraz z komentarzami opisującymi ich działanie.
Źródła literaturowe:
[1]. Dokumentacja procesora sygnałowego TMS320F2812. Texas Instruments.
[2]. Dokumentacja zestawu eZdsp i modułu DMC1500. Spectrum Digital.
[3]. C281x C/C++ Header Files and Peripheral Examples. Texas Instruments.
Wszystkie wymienione źródła literaturowe dostępne są na stronie internetowej firmy Texas
Instruments (
www.ti.com
).
opracowano dnia 06-11-2008, (v3.1)
Rys. 1. Wybrane elementy głównego okna CCS
Rys. 2. Wybrane elementy CCS do testowania i uruchamiania programów
Zawartość pliku nagłówkowego „DSP281x_Gpio.h” (fragmenty):
//----------------------------------------------------
// GPIO A mux control register bit definitions
//
//
struct
GPAMUX_BITS
{
Uint16 PWM1_GPIOA0
:
1
;
// 0
Uint16 PWM2_GPIOA1
:
1
;
// 1
Uint16 PWM3_GPIOA2
:
1
;
// 2
Uint16 PWM4_GPIOA3
:
1
;
// 3
Uint16 PWM5_GPIOA4
:
1
;
// 4
Uint16 PWM6_GPIOA5
:
1
;
// 5
Uint16 T1PWM_GPIOA6
:
1
;
// 6
Uint16 T2PWM_GPIOA7
:
1
;
// 7
Uint16 CAP1Q1_GPIOA8
:
1
;
// 8
Uint16 CAP2Q2_GPIOA9
:
1
;
// 9
Uint16 CAP3QI1_GPIOA10
:
1
;
// 10
Uint16 TDIRA_GPIOA11
:
1
;
// 11
Uint16 TCLKINA_GPIOA12
:
1
;
// 12
Uint16 C1TRIP_GPIOA13
:
1
;
// 13
Uint16 C2TRIP_GPIOA14
:
1
;
// 14
Uint16 C3TRIP_GPIOA15
:
1
;
// 15
}
;
union
GPAMUX_REG
{
Uint16 all;
struct
GPAMUX_BITS bit;
}
;
//----------------------------------
// GPA Qualregister bit definitions
struct
GPAQUAL_BITS
{
Uint16 QUALPRD
:
8
;
// 0:7
Uint16 rsvd1
:
8
;
// 15:8
}
;
union
GPAQUAL_REG
{
Uint16 all;
struct
GPAQUAL_BITS bit;
}
;
//-----------------------------------------
struct
GPIO_MUX_REGS
{
union
GPAMUX_REG GPAMUX;
union
GPADIR_REG GPADIR;
union
GPAQUAL_REG GPAQUAL;
Uint16 rsvd1;
union
GPBMUX_REG GPBMUX;
union
GPBDIR_REG GPBDIR;
union
GPBQUAL_REG GPBQUAL;
Uint16 rsvd2[
5
];
union
GPDMUX_REG GPDMUX;
union
GPDDIR_REG GPDDIR;
union
GPDQUAL_REG GPDQUAL;
Uint16 rsvd3;
union
GPEMUX_REG GPEMUX;
union
GPEDIR_REG GPEDIR;
union
GPEQUAL_REG GPEQUAL;
Uint16 rsvd4;
union
GPFMUX_REG GPFMUX;
union
GPFDIR_REG GPFDIR;
Uint16 rsvd5[
2
];
union
GPGMUX_REG GPGMUX;
union
GPGDIR_REG GPGDIR;
Uint16 rsvd6[
6
];
}
;
//------------------------------------------
// GPI/O External References & Function Declarations:
extern volatile struct
GPIO_MUX_REGS GpioMuxRegs;
Zawartość pliku nagłówkowego „DSP281x_Gpio.h” (fragmenty):
//----------------------------------------------------
// GPIO A mux control register bit definitions
//
//
struct
GPAMUX_BITS
{
Uint16 PWM1_GPIOA0
:
1
;
// 0
Uint16 PWM2_GPIOA1
:
1
;
// 1
Uint16 PWM3_GPIOA2
:
1
;
// 2
Uint16 PWM4_GPIOA3
:
1
;
// 3
Uint16 PWM5_GPIOA4
:
1
;
// 4
Uint16 PWM6_GPIOA5
:
1
;
// 5
Uint16 T1PWM_GPIOA6
:
1
;
// 6
Uint16 T2PWM_GPIOA7
:
1
;
// 7
Uint16 CAP1Q1_GPIOA8
:
1
;
// 8
Uint16 CAP2Q2_GPIOA9
:
1
;
// 9
Uint16 CAP3QI1_GPIOA10
:
1
;
// 10
Uint16 TDIRA_GPIOA11
:
1
;
// 11
Uint16 TCLKINA_GPIOA12
:
1
;
// 12
Uint16 C1TRIP_GPIOA13
:
1
;
// 13
Uint16 C2TRIP_GPIOA14
:
1
;
// 14
Uint16 C3TRIP_GPIOA15
:
1
;
// 15
}
;
union
GPAMUX_REG
{
Uint16 all;
struct
GPAMUX_BITS bit;
}
;
//----------------------------------
// GPA Qualregister bit definitions
struct
GPAQUAL_BITS
{
Uint16 QUALPRD
:
8
;
// 0:7
Uint16 rsvd1
:
8
;
// 15:8
}
;
union
GPAQUAL_REG
{
Uint16 all;
struct
GPAQUAL_BITS bit;
}
;
//-----------------------------------------
struct
GPIO_MUX_REGS
{
union
GPAMUX_REG GPAMUX;
union
GPADIR_REG GPADIR;
union
GPAQUAL_REG GPAQUAL;
Uint16 rsvd1;
union
GPBMUX_REG GPBMUX;
union
GPBDIR_REG GPBDIR;
union
GPBQUAL_REG GPBQUAL;
Uint16 rsvd2[
5
];
union
GPDMUX_REG GPDMUX;
union
GPDDIR_REG GPDDIR;
union
GPDQUAL_REG GPDQUAL;
Uint16 rsvd3;
union
GPEMUX_REG GPEMUX;
union
GPEDIR_REG GPEDIR;
union
GPEQUAL_REG GPEQUAL;
Uint16 rsvd4;
union
GPFMUX_REG GPFMUX;
union
GPFDIR_REG GPFDIR;
Uint16 rsvd5[
2
];
union
GPGMUX_REG GPGMUX;
union
GPGDIR_REG GPGDIR;
Uint16 rsvd6[
6
];
}
;
//------------------------------------------
// GPI/O External References & Function Declarations:
extern volatile struct
GPIO_MUX_REGS GpioMuxRegs;
M
E
M
O
R
Y
{
P
A
G
E
0
:
/
*
P
r
o
g
r
a
m
M
e
m
o
r
y
*
/
P
A
G
E
1
:
/
*
D
a
t
a
M
e
m
o
r
y
*
/
S
C
I
A
:
o
r
i
g
i
n
=
0
x
0
0
7
0
5
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
X
I
N
T
R
U
P
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
7
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
G
P
I
O
M
U
X
:
o
r
i
g
i
n
=
0
x
0
0
7
0
C
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
G
P
I
O
D
A
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
E
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
A
D
C
:
o
r
i
g
i
n
=
0
x
0
0
7
1
0
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
}
S
E
C
T
I
O
N
S
{
/
*
*
*
P
e
r
i
p
h
e
r
a
l
F
r
a
m
e
1
R
e
g
i
s
t
e
r
S
t
r
u
c
t
u
r
e
s
*
*
*
/
S
c
i
a
R
e
g
s
F
i
l
e
:
>
S
C
I
A
,
P
A
G
E
=
1
X
I
n
t
r
u
p
t
R
e
g
s
F
i
l
e
:
>
X
I
N
T
R
U
P
T
,
P
A
G
E
=
1
G
p
i
o
M
u
x
R
e
g
s
F
i
l
e
:
>
G
P
I
O
M
U
X
,
P
A
G
E
=
1
G
p
i
o
D
a
t
a
R
e
g
s
F
i
l
e
:
>
G
P
I
O
D
A
T
P
A
G
E
=
1
A
d
c
R
e
g
s
F
i
l
e
:
>
A
D
C
,
P
A
G
E
=
1
}
Zawartość pliku konfiguracyjnego linkera „DSP281x_Headers_nonBIOS.cmd” (fragment):
M
E
M
O
R
Y
{
P
A
G
E
0
:
/
*
P
r
o
g
r
a
m
M
e
m
o
r
y
*
/
P
A
G
E
1
:
/
*
D
a
t
a
M
e
m
o
r
y
*
/
S
C
I
A
:
o
r
i
g
i
n
=
0
x
0
0
7
0
5
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
X
I
N
T
R
U
P
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
7
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
1
0
G
P
I
O
M
U
X
:
o
r
i
g
i
n
=
0
x
0
0
7
0
C
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
G
P
I
O
D
A
T
:
o
r
i
g
i
n
=
0
x
0
0
7
0
E
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
A
D
C
:
o
r
i
g
i
n
=
0
x
0
0
7
1
0
0
,
l
e
n
g
t
h
=
0
x
0
0
0
0
2
0
}
S
E
C
T
I
O
N
S
{
/
*
*
*
P
e
r
i
p
h
e
r
a
l
F
r
a
m
e
1
R
e
g
i
s
t
e
r
S
t
r
u
c
t
u
r
e
s
*
*
*
/
S
c
i
a
R
e
g
s
F
i
l
e
:
>
S
C
I
A
,
P
A
G
E
=
1
X
I
n
t
r
u
p
t
R
e
g
s
F
i
l
e
:
>
X
I
N
T
R
U
P
T
,
P
A
G
E
=
1
G
p
i
o
M
u
x
R
e
g
s
F
i
l
e
:
>
G
P
I
O
M
U
X
,
P
A
G
E
=
1
G
p
i
o
D
a
t
a
R
e
g
s
F
i
l
e
:
>
G
P
I
O
D
A
T
P
A
G
E
=
1
A
d
c
R
e
g
s
F
i
l
e
:
>
A
D
C
,
P
A
G
E
=
1
}
W
pl
ik
u
ź
ródł
ow
ym
„
D
SP
281x
_G
lobal
V
ar
iabl
eD
ef
s.
c”
je
st
:
#
p
r
a
g
m
a
D
A
T
A
_
S
E
C
T
I
O
N
(
G
p
i
o
M
u
x
R
e
g
s
,
"
G
p
i
o
M
u
x
R
e
g
s
F
i
l
e
"
)
;
v
o
l
a
t
i
l
e
s
t
r
u
c
t
G
P
I
O
_
M
U
X
_
R
E
G
S
G
p
i
o
M
u
x
R
e
g
s
;
(32)
1
0
=
(0x000020)
1
6
Zawartość pliku konfiguracyjnego linkera „DSP281x_Headers_nonBIOS.cmd” (fragment):
