1. Wprowadzenie do środowiska VisSim Embedded Controls
Transkrypt
1. Wprowadzenie do środowiska VisSim Embedded Controls
1. Wprowadzenie do środowiska VisSim Embedded Controls Developer VisSim jest typowym środowiskiem symulacyjnym. Obiekty symulacyjne, podobnie jak ma to miejsce w przypadku SIMULINK’a tworzone są z bloków funkcyjnych. Udostępniana przez Visual Solutions wersja VisSim - Embedded Controls Developer v5.0 for TI C2000 posiadała pełen wybór narzędzi ukierunkowanych na modelowanie układów napędowych i sterowania oraz wspomaganie projektowania algorytmów sterowania i aplikacji opartych na procesorach sygnałowych Texas Instruments serii 2000 (w założeniu x24x, x240x oraz x28xx) i bibliotece oprogramowania tej firmy. Projektowanie aplikacji odbywa się analogicznie do tworzenia modelu symulacyjnego, z tą różnicą, że przetestowany układ można uzupełnić o bloki realizujące podstawowe funkcje wejścia – wyjścia. Mogą być to bloki obsługi sygnałów analogowych, cyfrowych oraz enkoderowe. Rys 1.2 Zestaw funkcji DMC Blocks Rys 1.1 Zestaw funkcji obsługi c24x Na rysunku 4.1 przedstawiono menu zawierające zestaw funkcji obsługi peryferiów procesorów c24x oraz Event Menagera. Rysunek 4.2 zawiera menu biblioteki TI Digital Motion Control opartej na Digital Motion Control – Software Library (Digital Control System Group, Texas Instruments, SPRU485). Za pomocy tych funkcji można zbudować Model pełnego układu działającego na procesorze sygnałowym. Na rysunku 1.3 przedstawiono przykładowe okno programu zawierające symulacje układy DTC. Przed przystąpieniem do pracy z gotowym układem, zawierającym wszystkie bloki wejściowo wyjściowe, można przeprowadzić symulacje mieszaną. Symulacja tego typu umożliwia przetestowanie poprawności działania struktury programu na procesorze sygnałowym bez potrzeby współpracy z urządzeniami rzeczywistymi. Poprzez DSP interface udostępniany przez VisSim’a, można wejścia i wyjścia procesora połączyć z modelem symulacyjnym działającym w środowisku VisSim. Tego typu symulacje mieszaną przedstawia rysunek 4.4. Rys 1.3 Okno programu VisSim z symulacją układu DTC Rys 1.4 Okno programu VisSim w czasie symulacji mieszanej Model ten zawiera blok o nazwie „DSP – układ sterowania DTC na x24x”, jest to skompilowany program przeznaczony dla procesora sygnałowego. W momencie rozpoczęcia procesu symulacyjnego program ten jest wgrywany do pamięci procesora i uruchamiany. Dane do i z procesora transmitowane są przez JTAG interfejs za pomocą emulatora (XDS510PP). Całość układu sterowania DTC została zrealizowana w oparciu o bibliotekę matematycznych operacji stałoprzecinkowych i o TI Digital Motion Control opartej na Digital Motion Control – Software Library (Digital Control System Group, Texas Instruments, SPRU485). Środowisko to jest proste w obsłudze i bardzo funkcjonalne. Czas przeprowadzania pojedynczej symulacji dla modelu o podobnym poziomie skomplikowani i dla tego samego kroku całkowania jest znacznie krótszy niż dla modelu zrealizowanego w SIMULINK’u. 2. Code Composer Studio Code Composer Studio jest środowiskiem programistycznym przeznaczonym do projektowania i rozwoju oprogramowania dla wszystkich procesorów sygnałowych firmy Texas Instruments. Praca z tym oprogramowaniem nie różni się znacząco od pracy w innych środowiskach programistycznych. Współpraca z modułami sprzętowymi dobywa się według schematu opisanego w „Reference Framework” zeprezentowanego na rysunku na rysunku 2.1, zaleca się pisanie oprogramowania zgodnie z standardami opisanymi w strategiach programistycznych dla poszczególnych rodzin procesorów. Podstawowymi językami programowania są C/C++ oraz asembler. Budowa programu oparta jest o projekt, będący zestawem kodów programów bibliotek i funkcji obsługi oprogramowania w postaci prostych funkcji pisanych w języku skryptowym. Rys. 2.1 Współpraca Code Composer Studio z modułami sprzętowymi według „Reference Framework” Podstawowe cechy środowiska Code Composer Studio: o zarządzanie projektami z podziałam na grupy funkcyjne, o obsługa kodów programów w językach C/C++ oraz asemblerze łącznie z formantami edycyjnymi, o możliwość uzupełnienia środowiska o funkcje pisane w prostym języku skryptowym, o możliwość współpracy z zewnętrznymi narzędziami wspierającymi tworzenie projektów (na przykład CodeWright), o możliwość rozbudowy środowiska dzięki systemowi wtyczek (ang. plug-in), o wsparcie wszystkich rodzin procesorów sygnałowych produkcji Texas Instruments TMS320 i serii procesorów dedykowanych – budowanych na zamówienie, o wsparcie systemu operacyjnego DSP/BIOS oraz technologii RTDX, o wsparcie strategii programistycznej eXpressDSP oraz DSP Algorithm Standard, o wsparcie metody projektowania obiektów xDAIS, o bogata oferta bibliotek dodatkowych między innymi biblioteka wtyczek do obsługi współpracy procesorów sygnałowych z zewnętrznymi przetwornikami ADC i DAC (wyłącznie firmy Texas Instruments) oraz Signal Processing Libraries, o dobra współpraca z modułami sprzętowymi poprzez emulator – podgląd całej mapy pamięci z możliwością podglądania zdefiniowanych w programie zmiennych, markerów, breakpoint’ów i punktów próbkowania, o możliwość graficznego przedstawienia przetwarzanych zmiennych łącznie z analizą FTT, o możliwość bezpośredniego wydawania rozkazów z okna dialogowego (jeśli do projektu dołączono program monitor) łącznie z trybem pracy RealTime, o rozbudowany kompilator z możliwością profilowania i optymalizacją kodu programu według różnych kryteriów. Jak już wspomniano pisanie programu w Code Composer Studio polega na stworzeniu projektu programistycznego podobnie jak ma to miejsce w przypadku tworzenia oprogramowania na przykład w DELPHI. Podstawowy projekt musi składać się z: o o o o definicji docelowego procesora, definicji mapy pamięci, definicji wektora przerwań, funkcji podstawowej (program główny). Opcjonalnymi elementami projektu mogą być: o program monitor, o funkcje skryptowe interfejsu użytkownika, o moduł linii poleceń dla programu monitora, o biblioteki funkcji, o wykresy danych zebranych w czasie pracy za pomocą specjalnego modułu programowego. Wygląd typowego okna programu przedstawiono na rysunku 6.5. Na rysunku można zauważyć drzewo projektu zawierające wszystkie kody źródłowe biblioteki i pliki konfiguracyjne, okno stanu/komunikacji modułu EVM, okno podglądu zmiennych oraz podglądu pamięci procesora w postaci kodu asemblerowego, okno edytora kodu programu i okno wtyczki edytora rejestrów. Rys. 2.2 Wygląd okna Code Composer Studio w czasie pracy Prze przystąpieniem do pracy nad programem niezbędne jest skonfigurowanie sprzętu i driver’ów. Do pracy nad programem użyto modułu EVM oraz emulatora XDS510PP firmy Spectrum Digital. Wraz z emulatorem dostarczane jest odpowiednie oprogramowanie konfiguracyjno – diagnostyczne (wygląd okna przestawiono na rysunku 2.3). Konfiguracja polega na określeniu sposobu podłączenia modułu – port równoległy dla eZdsp i EVM z emulatora, adres emulatora w postaci karty PCI lub numer portu USB. Po skonfigurowaniu połączenia należy skonfigurować Code Composer Studio do współpracy z docelowym procesorem, co obrazuje rysunek 2.4. Rys. 2.3 Wygląd okna konfiguracyjnego driver’a firmy Spectrum Digital Rys. 2.4 Wygląd okna konfiguracyjnego Code Composer Studio u możliwiający wybór procesora docelowego Code Composer Studio oprócz pracy z modułami sprzętowymi (płyta z procesorem sygnałowym i emulator) posiada możliwość testowania oprogramowania za pomocą symulatora procesora sygnałowego. Jest to bardzo cenna możliwość, ponieważ nie zawsze na początku pracy nad daną aplikacją programista posiada pełny zestaw narzędzi. Możliwość pracy z symulatorem dostępna jest też w darmowej ograniczonej czasowo wersji testowej oprogramowania, co znacząco podnosi jego walory. Dodatkowymi atutami tego środowiska są technologia wtyczek umożliwiająca rozbudowę środowiska o dodatkowe moduły i możliwość współpracy z środowiskami VisSim i Matlab (tylko rodziny C5000, C6000 a ostatnio również C2800). Do wad tego środowiska należy zaliczyć niskiej jakości dokumentacje oraz bardzo ubogą pomoc kontekstową wbudowaną, w niewielkim stopniu rekompensowaną przez dokumentacje dedykowaną poszczególnym procesorom sygnałowym. Równie istotną wadą jest brak standardowego edytora rejestrów konfiguracyjnych procesora (na rysunku 6.5 przedstawiono okno programu w czasie pracy z wtyczką edytora rejestrów firmy Technosoft). Nie ma też możliwości wgrania zaprogramowania pamięci FLASH bezpośrednio z poziomu środowiska Code Composer Studio (dla procesorów F24x). Przykładowy kod programu napisanego dla procesora F240 znajduje się w rozdziale 4. 3. Narzędzia sprzętowe C2000 Rozróżniamy trzy podstawowe grupy narzędzi sprzętowych służących do budowy systemów opartych na procesorach sygnałowych firmy Texas Instruments: o Moduły eZdsp – platforma podstawowa służąca do testowania oprogramowania i możliwości procesora sygnałowego. Zawiera komplet wyprowadzeń i niezbędną ilość pamięci potrzebną do poprawnej pracy. Posiada możliwość współpracy z komputerem przez port równoległy za pomocą wbudowanego w moduł podstawowego emulatora korzystającego z portu JTAG, istnieje również możliwość podłączenia zewnętrznego emulatora. o Evaluation Module (w skucie EVM) jest platformą służącą do budowy aplikacji i oprócz wyposażenia podstawowego zawiera dodatkowe elementy takie jak rozszerzona pamięć, możliwość regulacji napięcia referencyjnego dla przetworników ADC, diody LED i przełączniki DIP umożliwiające symulacje klawiatury i kontrolek oraz przetwornik DAC umożliwiający monitorowanie wewnętrznych zmiennych używanych w oprogramowaniu na przykład na ekranie oscyloskopu. o Moduły DSK – będące podstawą do budowy gotowych urządzeń, gdy koszty wykonania własnego modułu byłyby zbyt wysokie, na przykład przy produkcji jednostkowej. Moduły tego typu posiadają pełny lub okrojony (w przypadku modułu firmy Technosoft) zestaw wyprowadzeń. Do komunikacji służy port szeregowy, rzadko istnieje możliwość podłączenia emulatora. Najczęściej posiadają oprogramowanie pozwalające na zaprogramowanie pamięci FLESH i uruchomienie aplikacji oraz samodzielną pracę układu (choć nie zawsze). Całość prac wykonywano przy użyciu modułu EVM firmy Texas Instruments. Wyposażenie modułu: o stałoprzecinkowy procesor sygnałowy TMP320F240 (litera P w nazwie oznacza serię próbną, S wersję produkcyjną), o pamięć SRAM o pojemności 128k słów (64k – zewnętrzna pamięć programu, 32k – zewnętrzna pamięć danych lokalnych, 32k – zewnętrzna pamięć danych globalnych), o czterokanałowy dwunastobitowy bitowy przetwornik cyfrowo-analogowy, o port szeregowy RS232, o port kompatybilny z IEEE1149.1 – JTAG do współpracy z emulatorami XDS510/XDS510PP i XDS510PLUS oraz XDS560, o bank ośmiu diod LED, o bank ośmiu przełczników DIP. Poniżej umieszczono schematyczny rysunek modułu EVM z wyszczególnieniem podstawowych elementów modułu (rysunek 6.3). Rys. 3.1 Schematyczny wygląd modułu EVM z wyszczególnieniem głównych elementów 4. Przykładowy kod programu w C dla procesora F240 * Program testowy sprawdza działanie przerwan */ /*DEFINICJE*/ /*______________________________________________________________________________ */ /* #define SYSTEM_INT_PERIOD 20000 /* 1000 uS (1kHz) sampling period @50*/ /* #define SYSTEM_INT_PERIOD 2000 /* 100 uS (10kHz) sampling period @50 ns CPU clock /* #define SYSTEM_INT_PERIOD 1000 /* 50 uS (20kHz) sampling period @50 ns CPU clock /* #define SYSTEM_INT_PERIOD 700 /* 17.5 uS sampling period @25 ns CPU clock */ /* #define SYSTEM_INT_PERIOD 360 /* 18 uS (~56kHz) sampling period @50 ns CPU clock */ /* #define SYSTEM_INT_PERIOD 450 /* 22.5 uS (44kHz) sampling period @50 ns CPU clock */ /* #define SYSTEM_INT_PERIOD 500 /* 25 uS (40kHz) sampling period @50 ns CPU clock */ /* #define SYSTEM_INT_PERIOD 200 /* 25 uS (40kHz) sampling period @50 ns CPU clock */ #define T1_INT_PERIOD 2000 /*100us (10kHz) a jest 5kHz*/ //#define T2_INT_PERIOD 0x4E1E /*1000us (1kHz)*/ #define T2_INT_PERIOD 0x9c40 /*2000us (500Hz)*/ #define WAIT_STATES 0x0004 #define TARGET F240 #define x240 1 /*_______________________________________________________________________________ */ /*MODULY*/ /*_______________________________________________________________________________ */ #include "../include/sysvecs.h" #include "../include/regs24x.h" #include "../include/F24X_WD.H" #include "../include/stdlib.h" */ */ /*______________________________________________________________________________ */ /*predefinicje funkcji*/ /*______________________________________________________________________________ */ void RstSystem(void); void interrupt c_int02(); void interrupt c_int03(); void interrupt phantom(void); void time_base_init(void); /*_______________________________________________________________________________ */ /* inicjalizacje obiektów */ WATCHDOG wdog = WATCHDOG_DEFAULTS; //piesek ;-) na lancuchu /*_______________________________________________________________________________ */ /*poczatek programu*/ void main(void) { /* glowna petal programu */ puts("Start Program Testowy"); time_base_init();/*inicjalizacja podstawy czasu*/ RstSystem();/*resecik*/ enable_ints();/*odblokowanie przerwan*/ while (1) { //asm(" CLRC XF "); /* nic nie robi caly dzien ;-) */ /* pusta petla programu glownego moze byc wykozystana do zatrzymania programu */ /* jesli zamiast while (1) wstawimy test jakiegos bitu z magistrali CONTROL */ /* mozna tu dodac komunikacje przez RS lub SPI */ } }/* main(void)*/ /*_______________________________________________________________________________ */ void time_base_init(void) { /* funkcja inicjalizacji zegarow zwiazanych EV menagerem*/ /* */ //T1 - obliczenia DTC T1PR = T1_INT_PERIOD; //T2 - enkoder i PID T2PR = T2_INT_PERIOD; /* Initialize period register */ /* * T2CON = 1001000001000000b * Operation is not affected by emulation suspend * Continuous up count mode * Enable timer operations */ T2CON = 0x9040; //asymetryczny ok T1CON = 0x9040; //asymetryczny ok puts("time init"); } /* time_base_init() */ void RstSystem(void) { /*----------------------------------------------------------------------------First execute the initialization for the Wait Stage Genrator, Global interrupt disable, Shut off the Watchdog, and set up the Interupt Mask Register -----------------------------------------------------------------------------*/ puts("rtsSystem"); disable_ints();/* Make sure the interrupts are disabled */ IMR = 0x00;/* Mask all interrupts */ IFR = 0x00ff;/* Clear any pending interrupts, if any */ asm(" CLRC SXM ");/* Clear signextension mode */ asm(" CLRC OVM ");/* Reset overflow mode */ asm(" CLRC CNF ");/* Config block B0 to data memory */ asm(" SPM 0 ");/* Set product mode at 0 */ PIRQR0 = PIRQR0 & 0x0fffe;/* Clear pending PDP flag */ EVIFRA = EVIFRA | 0x0001;/* Clear PDP int flag */ WSGR=WAIT_STATES;/* Initialize Wait State Generator */ SCSR=0x40c0;/* Init SCSR */ wdog.disable();/* Vccp/Wddis pin/bit must be high */ wdog.reset();/* reset watchdog counter */ EVIMRB=0x0004;/* Enable the timer2 underflow interrupt */ EVIMRA=0x0200;/* Enable the timer1 underflow interrupt */ EVIMRC=0x0004;/* Enable CAP3 interrupt */ EVIFRA = 0xFFFF;/* Clear all Group A interrupt flags */ EVIFRB = 0xFFFF;/* Clear all Group B interrupt flags */ EVIFRC = 0xFFFF;/* Clear all Group C interrupt flags */ /* Rejestr IMR pozwala wybrac aktywna przezwania poziomu 3 */ //IMR=0x0002; /*EN int lvl 2 (T1 ISR) */ //IMR = 0x0004;/* En Int lvl 3 (T2 ISR) */ IMR = 0x0006;/* En Int lvl 3(T2 ISR) & int lvl 2 (T1 ISR) */ //IMR = 0x000E;/* En Int lvl 3(T2 ISR) & int lvl 2 (T1 ISR) */ /* &int lvl 4 (QEP/CAP3) */ /* Ustawienia zegara EVM board'u*/ /* 10MHz zegar na module taktuje peryferia i pamiec SYSCLK=10MHz */ /* wykozystano wewnetrzna petle PLL do uzyskania CPUCLOCK */ /* wejsciem PLL jest SYSCLK mnoznik PLL x2 co daje CPUCLOCK=20MHz */ asm(" LDP #00e0h "); asm(" SPLK #0002h,CKCR0 ");//PLL disabled asm(" SPLK #00bbh,CKCR1 "); asm(" SPLK #00c3h,CKCR0 "); asm(" splk #40c0h,SYSCR "); /* Konfiguracja portow I/O PBDATDIR konfiguracja portu B */ OCRA=0x000F; /* I/O Group 1 shared pin configuration */ PBDATDIR=PBDATDIR|0x0700;/* I/O port B Data & Direction reg.- 0700 set bits 0,1,2 in port B as output */ PCDATDIR=0x0; /* I/O port C Data & Direction reg.- 0000 set all bits in port c as input */ asm(" SETC XF "); } /* RstSystem(void) */ /*________________________________________________*/ /*Interrupts Service Rutins*/ /*________________________________________________*/ void interrupt phantom(void)//other_ISR { /*puste funkcja - nic nie robi - odp na przerwania nie obslugiwane*/ static int phantom_count; phantom_count++; //puts("phantom"); /* Empty function: Used to handle any unwanted interrupts or events. All unused interrupt vectors are pointed to this function so that if any un-handled interrupts do get enabled, they are handled in a benign manner, preventing un-intended branches, calls or execution into garbage. Note that this function is an ISR, not a ordinary function. */ } /* phantom() */ void interrupt c_int02() //T1_ISR { /*funkcja obsluguje przerwanie INT2 zwiazane z EVENT MANAGEREM A i zegarem T1*/ asm(" CLRC XF "); wdog.disable(); wdog.reset(); //czyszczenie przerwan EVIFRA=0x0ffff;/* Clear all Group A EV interrupt flags */ asm(" SETC XF "); } /* interrupt c_int02() */ void interrupt c_int03() //T2_ISR { //wolna pentla uzywa zegara t2 asm(" CLRC XF "); wdog.disable(); wdog.reset(); LEDS=SWITCHES; EVIFRB=0x0ffff;/* Clear all Group B EV interrupt flags */ //asm(" SETC } /* interrupt c_int03() */ XF ");