D2 instrukcja nowa rn3 1

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

;

// 0

Uint16 PWM2_GPIOA1

;

// 1

Uint16 PWM3_GPIOA2

;

// 2

Uint16 PWM4_GPIOA3

;

// 3

Uint16 PWM5_GPIOA4

;

// 4

Uint16 PWM6_GPIOA5

;

// 5

Uint16 T1PWM_GPIOA6

;

// 6

Uint16 T2PWM_GPIOA7

;

// 7

Uint16 CAP1Q1_GPIOA8

;

// 8

Uint16 CAP2Q2_GPIOA9

;

// 9

Uint16 CAP3QI1_GPIOA10

;

// 10

Uint16 TDIRA_GPIOA11

;

// 11

Uint16 TCLKINA_GPIOA12

;

// 12

Uint16 C1TRIP_GPIOA13

;

// 13

Uint16 C2TRIP_GPIOA14

;

// 14

Uint16 C3TRIP_GPIOA15

;

// 15

}

;

union

GPAMUX_REG

{

Uint16 all;

struct

GPAMUX_BITS bit;

}

;

//----------------------------------
// GPA Qualregister bit definitions

struct

GPAQUAL_BITS

{

Uint16 QUALPRD

;

// 0:7

Uint16 rsvd1

;

// 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[

];

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[

];

union

GPGMUX_REG GPGMUX;

union

GPGDIR_REG GPGDIR;

Uint16 rsvd6[

];

}

;

//------------------------------------------
// 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):

{

}

{

}

ródł

„

281x

lobal

iabl

c”

(

)

;

(32)

(0x000020)

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

– pamięć programu

PAGE

– 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

•

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

{

, \

(

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)

{

Enable

}

// Funkcja wyłączająca miganie diody LED

void

led_disable(LEDSUPPORT *l)

{

Enable

}

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

// 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

, 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"

);

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

;

// 0

Uint16 PWM2_GPIOA1

;

// 1

Uint16 PWM3_GPIOA2

;

// 2

Uint16 PWM4_GPIOA3

;

// 3

Uint16 PWM5_GPIOA4

;

// 4

Uint16 PWM6_GPIOA5

;

// 5

Uint16 T1PWM_GPIOA6

;

// 6

Uint16 T2PWM_GPIOA7

;

// 7

Uint16 CAP1Q1_GPIOA8

;

// 8

Uint16 CAP2Q2_GPIOA9

;

// 9

Uint16 CAP3QI1_GPIOA10

;

// 10

Uint16 TDIRA_GPIOA11

;

// 11

Uint16 TCLKINA_GPIOA12

;

// 12

Uint16 C1TRIP_GPIOA13

;

// 13

Uint16 C2TRIP_GPIOA14

;

// 14

Uint16 C3TRIP_GPIOA15

;

// 15

}

;

union

GPAMUX_REG

{

Uint16 all;

struct

GPAMUX_BITS bit;

}

;

//----------------------------------
// GPA Qualregister bit definitions

struct

GPAQUAL_BITS

{

Uint16 QUALPRD

;

// 0:7

Uint16 rsvd1

;

// 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[

];

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[

];

union

GPGMUX_REG GPGMUX;

union

GPGDIR_REG GPGDIR;

Uint16 rsvd6[

];

}

;

//------------------------------------------
// 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

;

// 0

Uint16 PWM2_GPIOA1

;

// 1

Uint16 PWM3_GPIOA2

;

// 2

Uint16 PWM4_GPIOA3

;

// 3

Uint16 PWM5_GPIOA4

;

// 4

Uint16 PWM6_GPIOA5

;

// 5

Uint16 T1PWM_GPIOA6

;

// 6

Uint16 T2PWM_GPIOA7

;

// 7

Uint16 CAP1Q1_GPIOA8

;

// 8

Uint16 CAP2Q2_GPIOA9

;

// 9

Uint16 CAP3QI1_GPIOA10

;

// 10

Uint16 TDIRA_GPIOA11

;

// 11

Uint16 TCLKINA_GPIOA12

;

// 12

Uint16 C1TRIP_GPIOA13

;

// 13

Uint16 C2TRIP_GPIOA14

;

// 14

Uint16 C3TRIP_GPIOA15

;

// 15

}

;

union

GPAMUX_REG

{

Uint16 all;

struct

GPAMUX_BITS bit;

}

;

//----------------------------------
// GPA Qualregister bit definitions

struct

GPAQUAL_BITS

{

Uint16 QUALPRD

;

// 0:7

Uint16 rsvd1

;

// 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[

];

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[

];

union

GPGMUX_REG GPGMUX;

union

GPGDIR_REG GPGDIR;

Uint16 rsvd6[

];

}

;

//------------------------------------------
// GPI/O External References & Function Declarations:

extern volatile struct

GPIO_MUX_REGS GpioMuxRegs;

{

}

{

}

Zawartość pliku konfiguracyjnego linkera „DSP281x_Headers_nonBIOS.cmd” (fragment):

{

}

{

}

ródł

„

281x

lobal

iabl

c”

(

)

;

(32)

(0x000020)

Zawartość pliku konfiguracyjnego linkera „DSP281x_Headers_nonBIOS.cmd” (fragment):

Wyszukiwarka

Podobne podstrony:

więcej podobnych podstron