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 ");