Nyilatkozat
Alulírott, Raikovich Tamás, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem.
……………………………………….. Raikovich Tamás
Összefoglaló Az elektronika gyors ütemű fejlődésének köszönhetően a programozható logikai eszközökkel (FPGA és CPLD áramkörök), valamint a mikrokontrollerekkel felépített rendszerek egyre szélesebb körben kerülnek alkalmazásra. Nagy előnyük az alkalmazás-specifikus integrált áramkörökhöz képest a programozhatóságukból
adódó
rugalmasság,
amely
nagymértékben
csökkenti
a
rendszer
prototípusának kifejlesztése során jelentkező költségeket.
A programozható eszközök használata hatékony fejlesztési támogatást igényel. Egyszerűbb alkalmazások esetén a minimális követelmény az eszközök gyors és megbízható konfigurálása. Az összetettebb alkalmazások sok esetben megkövetelik a fejlesztés, hibakeresés támogatására a már működő
alkalmazással
kialakítható
kommunikációs
kapcsolatokat,
amelyekkel
speciális
fejlesztőeszközök használatára nyílik lehetőség. Ilyen például az áramkörön belüli jelek vizsgálatát támogató logikai analizátor, vagy a processzoros rendszerek szoftverfejlesztését segítő debugger.
A diplomaterv célja a korábban elkészített, az eszközök egységes konfigurációját biztosító USB alapú letöltőkábel integrálása a tanszéken kifejlesztett LOGSYS rendszerhez, illetve a Xilinx gyári fejlesztőrendszeréhez. A letöltőkábel az alábbi szolgáltatásokat nyújtja a programozható logikai eszközök fejlesztésének támogatásához: •
JTAG interfész a célrendszer konfigurálásához
•
órajel és reset jel a célrendszer működtetéséhez
•
soros I/O vonalak a kommunikációhoz
•
5V-os rövidzárlat védett tápfeszültség kimenet
Abstract Thanks to the rapid development of electronics, systems built with programmable logic devices (FPGAs and CPLDs) as well as with microcontrollers are becoming more and more widely used. Their great advantage that arises from their programmable nature as compared to systems using application specific integrated circuits is their flexibility, which cuts back the cost of the development of the prototype to a great extent.
Using of programmable devices requires efficient development support. As for simple applications, fast and reliable configuration of the devices is a basic requirement. More complicated applications require efficient support for development, debug and verification. Special development tools offers the possibility of communication with the application itself. Such tool is the in-circuit logic analyzer, which allows observation of internal signals, or the software debugger.
The purpose of this work is to integrate a previously built USB based download cable with the LOGSYS system and with the Xilinx development environment. The download cable provides the following features to support the development of programmable devices: •
JTAG interface to configure the target system
•
clock and reset signals to operate the target system
•
serial communication lines
•
5V short circuit protected power output
Tartalomjegyzék
1
Bevezetés....................................................................................................................................................... 1
2
Tervezési szempontok.................................................................................................................................. 2 2.1 A hardver kialakításának szempontjai.................................................................................................. 2 2.1.1 A hardver egységek közötti interfész............................................................................................... 2 2.1.2 Kapcsolat a számítógéppel .............................................................................................................. 4 2.1.3 Tápfeszültség alatti csatlakoztatás ................................................................................................... 4 2.2 A szoftverek tervezési szempontjai........................................................................................................ 5 2.2.1 A fejlesztői kábel firmware-je ......................................................................................................... 5 2.2.2 Az eszközmeghajtó programok ....................................................................................................... 5 2.2.3 A fejlesztői kábel integrálása a LOGSYS környezetbe ................................................................... 6 2.2.4 A fejlesztői kábel integrálása a Xilinx fejlesztőrendszerébe............................................................ 7
3
4
A JTAG interfész ......................................................................................................................................... 8 3.1
A boundary-scan cella.......................................................................................................................... 9
3.2
A TAP vezérlő..................................................................................................................................... 10
3.3
Az SVF fájlformátum .......................................................................................................................... 11
3.4
A BSDL fájlformátum ......................................................................................................................... 12
Az Universal Serial Bus (USB).................................................................................................................. 13 4.1
Az USB topológiája ............................................................................................................................ 13
4.2
A fizikai interfész ................................................................................................................................ 14
4.3 Az adatátvitel...................................................................................................................................... 14 4.3.1 Bulk transzfer ................................................................................................................................ 16 4.3.2 Interrupt transzfer .......................................................................................................................... 16 4.3.3 Isochronous transzfer..................................................................................................................... 17 4.3.4 Kontroll transzfer........................................................................................................................... 17 4.4
Az USB perifériák logikai felépítése................................................................................................... 18
5
A tápfeszültség alatti csatlakoztatás kérdései.......................................................................................... 20
6
Fejlesztői kábel AT90USB1287 mikrovezérlővel .................................................................................... 25
7
A LOGSYS Spartan-3E kártya ................................................................................................................ 29
8
A fejlesztői kábel firmware-je................................................................................................................... 32 8.1
Az USB periféria megvalósítása ......................................................................................................... 32
8.2 A funkciók megvalósítása ................................................................................................................... 33 8.2.1 A JTAG funkció ............................................................................................................................ 34 8.2.2 Az UART és az USRT funkció ..................................................................................................... 35 8.2.3 Az SPI funkció .............................................................................................................................. 36 8.2.4 Az I2C funkció ............................................................................................................................... 37 8.2.5 A szoftveres soros I/O funkció ...................................................................................................... 38 8.2.6 A mérési funkciók ......................................................................................................................... 39 8.2.7 Egyéb funkciók.............................................................................................................................. 39 9
Az eszközmeghajtó programok................................................................................................................. 40 9.1
Áttekintés ............................................................................................................................................ 40
10
11
12
9.2
Az általános célú USB meghajtó ........................................................................................................ 42
9.3
A virtuális soros port meghajtó .......................................................................................................... 43
A kábel integrálása a LOGSYS környezetbe........................................................................................... 45 10.1
A PnPMessage osztálykönyvtár.......................................................................................................... 45
10.2
A LogsysUSB osztálykönyvtár ............................................................................................................ 46
10.3
A JTAG osztálykönyvtár ..................................................................................................................... 48
A kábel integrálása a Xilinx fejlesztőrendszerébe................................................................................... 50 11.1
A fejlesztői kábel integrálása az ISE programba ............................................................................... 50
11.2
A fejlesztői kábel integrálása az EDK programba ............................................................................. 53
A rendszer tesztelése .................................................................................................................................. 55 12.1 A hardver tesztelése............................................................................................................................ 55 12.1.1 A fejlesztői kábel tesztelése ...................................................................................................... 55 12.1.2 Az FPGA kártya tesztelése ....................................................................................................... 56 12.2 A szoftverek tesztelése ........................................................................................................................ 56 12.2.1 A firmware tesztelése................................................................................................................ 56 12.2.2 Az eszközmeghajtó programok tesztelése ................................................................................ 57 12.2.3 A .NET alkalmazások tesztelése............................................................................................... 57 12.3
A tesztprogramok................................................................................................................................ 58
12.4
A mikroprocesszoros rendszer............................................................................................................ 60
12.5
A fejlesztői kábel néhány jellemző paramétere................................................................................... 61
13
Az eredmények értékelése ......................................................................................................................... 62
14
Ábrajegyzék................................................................................................................................................ 63
15
Irodalomjegyzék......................................................................................................................................... 64
16
A CD melléklet tartalma ........................................................................................................................... 65
17
Mellékletek ................................................................................................................................................. 66 17.1
A fejlesztői kábel kapcsolási rajza...................................................................................................... 66
17.2
A fejlesztői kábel nyomtatott áramköri terve ...................................................................................... 67
17.3 A LOGSYS Spartan-3E kártya kapcsolási rajza................................................................................. 68 17.3.1 FPGA ........................................................................................................................................ 68 17.3.2 I/O csatlakozók, memóriák ....................................................................................................... 69 17.3.3 Kijelzők, DIP kapcsoló, nyomógombok ................................................................................... 70 17.3.4 Tápegység ................................................................................................................................. 71 17.4
A LOGSYS Spartan-3E kártya nyomtatott áramköri terve ................................................................. 72
17.5 Osztálydiagramok............................................................................................................................... 73 17.5.1 LogsysUSB osztálykönyvtár..................................................................................................... 73 17.5.2 JTAG osztálykönyvtár .............................................................................................................. 75
1 Bevezetés Az elektronika gyors ütemű fejlődésének köszönhetően a programozható logikai eszközökkel (FPGA és CPLD áramkörök), valamint a mikrokontrollerekkel felépített rendszerek egyre szélesebb körben kerülnek alkalmazásra. Nagy előnyük az alkalmazás-specifikus integrált áramkörökhöz képest a programozhatóságukból
adódó
rugalmasság,
amely
nagymértékben
csökkenti
a
rendszer
prototípusának kifejlesztése során jelentkező költségeket. A programozható eszközök használata hatékony fejlesztési támogatást igényel.
A diplomaterv célja az önálló laboratóriumi munkám során elkészített, az eszközök egységes konfigurációját biztosító USB alapú fejlesztői kábel integrálása a tanszéken kifejlesztett LOGSYS rendszerhez, illetve a Xilinx gyári fejlesztőrendszeréhez.
Az [1] irodalomban ismertetett LOGSYS-BLOXES egy elsősorban oktatási célra kifejlesztett eszközcsalád, amely többféle alapkártyából és az ezekhez illeszthető különféle modulokból áll. A kártyák a fejlesztői kábel segítségével csatlakoztathatók a számítógéphez. Az eszközök konfigurálása, valamint a kommunikációs és tesztelési műveletek elvégzése egy PC-s programmal lehetséges.
A Xilinx cég fejlesztőrendszerére azért esett a választás, mert egyrészt a cég az FPGA piac egyik vezető szállítója, másrészt pedig a tanszéken ez rendelkezésre áll.
A kábel az alábbi szolgáltatásokat nyújtja a programozható logikai eszközök fejlesztésének támogatásához: •
JTAG interfész a célrendszer konfigurálásához.
•
Órajel és reset jel a célrendszer működtetéséhez.
•
Soros I/O vonalak a kommunikációhoz.
•
5V-os rövidzárlat védett tápfeszültség kimenet.
A diplomatervhez mellékelek egy CD-t, amely tartalmazza a felhasznált áramkörök adatlapjait, a programok forráskódját és egyes hivatkozott irodalmakat is.
1
2 Tervezési szempontok 2.1 A hardver kialakításának szempontjai 2.1.1 A hardver egységek közötti interfész A hardver kialakítása során az egyik fő szempont volt a konfigurációs és a tesztelési célokra szolgáló interfész megfelelő megvalósítása. Itt a bevezetőben említett LOGSYS-BLOXES kártyákon az erre a célra kialakított interfészt vettem alapul, de bizonyos szempontok megvalósíthatósága miatt ezt bővíteni kellett. Az alap változat az alábbi lehetőségekkel rendelkezik (a csatlakozó kiosztása a fejlesztői kábel szerinti nézetből a 2-1. ábrán látható): •
JTAG interfész
•
Soros adat ki- és bemenet
•
Órajel vonal
•
Reset vonal
•
Tápfeszültség bemenet
A programozható eszközök konfigurálása és bizonyos tesztelési feladatok megvalósítása a JTAG interfészen keresztül történik. A JTAG interfész megtalálható a manapság használt programozható logikai eszközökön (CPLD-k és FPGA-k) és sok mikrovezérlő is rendelkezik ezzel. A JTAG interfészt részletesebben a 3. fejezetben ismertetem.
A soros kommunikációs vonalakon keresztül többféle, szinkron és aszinkron kommunikációs protokoll is megvalósítható. Ezek közül például az alábbiak széles körben használatosak: •
Aszinkron soros kommunikáció (UART)
•
Az előbbi „szinkron” változata (USRT). Ekkor a master egység folyamatosan kiadja az órajelet, amely meghatározza az adatátviteli sebességet, de a kommunikáció továbbra is a START bitre történő szinkronizálással valósul meg.
•
SPI
•
I2C
Az órajel vonalon keresztül – ha éppen nincs valamelyik szinkron kommunikációs protokoll által használva – a felhasználó által megadott frekvenciájú órajel adható a célrendszernek. A reset vonal pedig a célrendszer alapállapotba hozására szolgál.
A komplex kommunikációs lehetőségek miatt a fejlesztői kábel funkcióit mikrovezérlővel valósítottam meg. Ez a megoldás többféle előnyt nyújt. Egyrészt kihasználhatóak a mikrovezérlő beépített hardveres erőforrásai (pl. USART, SPI és I2C perifériák a kommunikációhoz; időzítők a
2
hardveres órajel előállításhoz; A/D átalakító a feszültség és áram mérésre; stb.), másrészt pedig lehetővé teszi a hardveresen nem támogatott kommunikációs protokollok szoftverből való megvalósítását.
Az interfész alap változatában a tápfeszültség bemeneten keresztül 3,3V-os tápfeszültség adható az eszközöknek és ezzel a feszültségszinttel működnek az interfész többi vonalai is. A mai modern FPGA-k azonban eltérő feszültségszinteket használ(hat)nak a konfigurációs célú és az I/O lábaikon. Például a Xilinx cég Spartan-3 típusú FPGA-i esetén a JTAG vonalak 2,5V-ról járnak, az I/O vonalak tápfeszültsége pedig lehet 3,3V is. Az eltérő feszültségszintek miatt keletkező problémára többféle megoldás is adható (pl. soros áramkorlátozó ellenállás használata, a Spartan-3 adatlapja említi is ezt a lehetőséget), de az igazán korrekt megoldás a szintillesztő áramkörök alkalmazása. A szintillesztőket a fejlesztői kábelen érdemes elhelyezni annak érdekében, hogy a kábel ne csak a LOGSYS-es rendszerekkel legyen képes együttműködni. Ennek megfelelően a tápfeszültség ellátás az alábbi módon lesz kialakítva az újabb LOGSYS-BLOXES kártyákon: •
5V-os tápfeszültség bemenet.
•
Referencia feszültség kimenet a JTAG szintillesztők számára.
•
Referencia feszültség kimenet a soros I/O, az órajel vonal és a reset vonal szintillesztőinek számára.
A tápfeszültség bemenet feszültségszintje azért lett 3,3V-ról 5V-ra változtatva, mert így az eszközben kapcsolóüzemű tápegységet alkalmazva a tápellátás hatásfoka javítható.
2-1. ábra: A régi (felül) és az új (alul) interfész (LOGSYS port) lábkiosztása.
A 2-1. ábra alapján látható, hogy a kétféle csatlakozó nem kompatibilis egymással. Ezért, hogy a fejlesztői kábel szolgáltatásait ki lehessen próbálni, készítettem egy új FPGA-s kártyát is, amelyen már az új lábkiosztású LOGSYS port található. Ezen kártya ismertetéséről a 7. fejezetben lesz szó.
3
2.1.2 Kapcsolat a számítógéppel A fejlesztőrendszer teljesítményét és sebességét döntően befolyásolja, hogy a fejlesztői kábel és a számítógép közötti adatátvitel milyen módon valósul meg. Egy mai számítógépen általában megtalálható az aszinkron soros port, a párhuzamos port és az USB port, melyek alkalmasak a külvilággal történő kapcsolattartásra. Ezek közül érdemes tehát valamelyiket kiválasztani.
A soros port a mi célunknak nem megfelelő az alacsony átviteli sebessége miatt (max. 115200 bit/s), illetve ez a megoldás nem ad tápfeszültséget a külső rendszer számára, tehát azt máshonnan kellene biztosítani. Másik probléma, hogy a soros port a jövőben valószínűleg el fog tűnni a számítógépekről (sok laptopon pedig már most sincs rajta). A soros port egyetlen előnye talán csak az lenne, hogy a Windows API tartalmazza a kezeléséhez szükséges rutinokat.
A párhuzamos port nagyobb átviteli sebességre képes az aszinkron soros portnál, de sajnos ez sem biztosít tápfeszültséget. Ráadásul a Windows XP nem támogatja a párhuzamos port közvetlen elérését (és feltehetően az azt követő verziók sem fogják), a használatához mindenképpen eszközmeghajtó programot kell írni. Ennyi munka árán pedig már a párhuzamos portnál jóval korszerűbb kommunikációs lehetőséget, az USB-t is használhatjuk. Gondot jelent az is, hogy a párhuzamos port a soros porthoz hasonlóan mára már kihalófélben van.
Az USB egy igen jól kitalált és kényelmes megoldás arra, hogy a számítógéphez különféle perifériákat csatlakoztassunk. Az USB megfelelő adatátviteli sebességet biztosít, emellett képes tápfeszültséggel is ellátni a csatlakoztatott perifériát. Az USB port 5V-os rövidzárlat védett tápfeszültséget szolgáltat maximum 500mA terhelhetőséggel, amivel a fejlesztői kábelen kívül a kisebb rendszerek táplálását is megoldhatjuk. Az USB számos előnye miatt egy jó választás, erről részletesebben a 4. fejezetben lesz szó. Ha a fejlesztői kábelt a számítógép USB portjára szeretnénk csatlakoztatni, akkor a felhasznált mikrovezérlőnek tartalmaznia kell az USB perifériát. Ilyen mikrovezérlőket sok gyártó kínál.
2.1.3 Tápfeszültség alatti csatlakoztatás A fejlesztői kábel használhatóságát jelentős mértékben növeli, ha az már működő, tápfeszültség alatti rendszerekhez is csatlakoztatható anélkül, hogy a hardver egységekben meghibásodás történne. Ez egyrészt kényelmi szempontból fontos, mert a csatlakoztatás és az eltávolítás során nem kell lekapcsolni a tápfeszültséget a rendszerről (és előfordulhat olyan helyzet is, amikor ez nem megoldható), másrészt pedig védelmet biztosít a felhasználó esetleges figyelmetlenségéből adódó meghibásodások ellen. Az 5. fejezetben részletesen megvizsgálom, hogy milyen feltételeknek kell teljesülnie ahhoz, hogy a fejlesztői kábel megvalósítsa ezt az elvárást.
4
2.2 A szoftverek tervezési szempontjai A LOGSYS fejlesztőrendszer szoftverei két nagy csoportra oszthatók: a fejlesztői kábelen található mikrokontrolleren
futó
programra
(firmware),
illetve
a
számítógépen
futó
programokra
(meghajtóprogramok, alkalmazói program). Ez utóbbiak Windows XP operációs rendszer alá készültek el annak elterjedtsége és támogatottsága miatt.
2.2.1 A fejlesztői kábel firmware-je A mikrovezérlő programjának a feladata a hardver alacsony szintű kezelése, ezért annak megvalósítását nagymértékben befolyásolja a hardver kialakítása. A hatékonyság érdekében a firmware elkészítésénél törekedni kell a mikrovezérlő hardveres erőforrásainak minél jobb kihasználására. Egy másik fontos szempont az egyes feladatok ésszerű elosztása firmware és a PC-n futó alkalmazói program között, mert a tevékenységek jellege miatt lehet, hogy az egyiket hatékonyabban lehet megvalósítani a mikrokontrolleren, más esetben pedig pont fordított a helyzet. Lényeges a funkciók által használt adatformátum is, mert ennek jó megválasztásával csökkenthető az elküldendő adatok mérete és az adatok feldolgozására fordítandó idő. Az USB-n keresztül történő kommunikáció miatt a mikrokontroller programjának meg kell valósítania a szabványban előírt alapvető USB kérések kezelését. A firmware-ről bővebben a 8. fejezetben lesz szó.
2.2.2 Az eszközmeghajtó programok Azért döntöttem saját eszközmeghajtó programok elkészítése mellett, mert ezt nem minden gyártó biztosítja az USB-s mikrovezérlőjéhez. Ha pedig a gyártó biztosít eszközmeghajtót, akkor meg az a probléma, hogy az egyes gyártók eszközmeghajtóinak kezelése és szolgáltatásai eltérőek lehetnek. Saját meghajtóprogrammal viszont megvalósítható az USB perifériák egységes kezelése, ami a fejlesztőrendszer későbbi bővíthetősége miatt fontos.
A PC-n futó alkalmazásnak az USB perifériával való kommunikációt egy általános célú USB meghajtó teszi lehetővé. Amint a neve is utal rá, ez a meghajtó minden USB perifériával képes együttműködni, mert csak az alapvető kommunikációs funkciókat valósítja meg, és nem tartalmaz semmilyen eszközspecifikus funkciót. Az általános célú USB meghajtóval szemben az alábbi főbb követelmények fogalmazódtak meg: •
Kontroll, bulk és interrupt USB transzferek kezelése.
•
Aszinkron I/O műveletek támogatása. Ez azt jelenti, hogy az alkalmazás az adatátvitel ideje alatt foglalkozhat más hasznos tevékenységgel is.
•
A meghajtót használó alkalmazások kapjanak értesítést az általuk kezelt USB eszközök csatlakoztatása, illetve eltávolítása esetén („plug & play” üzenetek).
5
Egy másik, szintén általam készített eszközmeghajtó lehetővé teszi, hogy a fejlesztői kábel aszinkron soros portja virtuális soros portként (COM port) látszódjon a számítógépen. Ez azért hasznos szolgáltatás, mert így nem szükséges külön soros kábellel csatlakozni a tesztelendő rendszerhez, másrészt pedig a soros porttal nem rendelkező számítógépek is tudják használni ezt a kommunikációs módot. A virtuális soros port meghajtó esetén is lényeges, hogy képes legyen többféle USB perifériával együttműködni. Ennek feltétele, hogy az adott periféria implementáljon egy általam specifikált USB interfészt és kezelni tudjon bizonyos általam specifikált USB kéréseket. Tehát a perifériának programozhatónak kell lennie (pl. mikrovezérlő).
A meghajtóprogramok esetén igen fontos szempont a hibamentes működés, mert egy rosszul működő eszközmeghajtó miatt az egész rendszer összeomolhat. Az eszközmeghajtó programokat a 9. fejezetben ismertetem bővebben.
2.2.3 A fejlesztői kábel integrálása a LOGSYS környezetbe A LOGSYS fejlesztői környezet vázlatos felépítése a 2-2. ábrán látható. A rendszert hardver- és szoftverkomponensek alkotják. A vizsgált rendszert tartalmazó panelek a fejlesztői kábelen keresztül csatlakoztathatók a számítógéphez. A kábel az eszközök konfigurálását, tesztelését és (bizonyos teljesítményhatáron belül) a tápellátását is biztosítja. Az esetenként komplex tesztelési igényeket egy, a PC-n futó alkalmazói program elégíti ki, amely egy egységes felületet nyújt a különböző konfigurációs és tesztelési funkciók elérésére. A LOGSYS-BLOXES logikai fejlesztőrendszerről bővebben az [1] és a [2] irodalmakban olvashatunk, a grafikus felhasználói felület ismertetése az utóbbiban található meg.
2-2. ábra: A LOGSYS fejlesztői környezet.
Az általam készített fejlesztői kábelnek a LOGSYS környezetbe integrálásához a fent említett alkalmazói programot kell módosítani. Mivel az alkalmazói programot nem én készítettem, ezért a
6
diplomatervben csak az alkalmazásba beépítendő általam készített szoftverkomponenseket és az azok használatához szükséges információkat ismertetem 8. és a 10. fejezetben: •
A fejlesztői kábel által megvalósított funkciók és USB gyártóspecifikus kérések.
•
A Windows „plug & play” üzeneteinek feldolgozását végző .NET osztálykönyvtár.
•
Az általános célú USB meghajtó funkcióinak elérését biztosító .NET osztálykönyvtár.
•
A fejlesztői kábel JTAG funkciójának használatához szükséges .NET osztálykönyvtár.
A fenti információk ismeretében a szükséges szoftverkomponenseket az alkalmazói programba beépítve az alkalmassá válik az új fejlesztői kábel kezelésére.
2.2.4 A fejlesztői kábel integrálása a Xilinx fejlesztőrendszerébe A Xilinx gyári fejlesztőrendszerét az alábbi szoftverek alkotják: •
ISE: A Xilinx programozható logikai eszközeinek fejlesztői környezete. Lehetővé teszi HDL alapú és kapcsolási rajz alapú tervek létrehozását, valamint azok letöltését az eszközökbe. Van ingyenesen letölthető változata is (ISE WebPack).
•
EDK (Embedded Development Kit): A mikroprocesszoros rendszerek (MicroBlaze és PowerPC) fejlesztői környezete. Tartalmazza a fejlesztéshez szükséges IP modulokat, a C/C++ fordítóprogramot és a debuggert.
•
ChipScope: Logikai analizátor, lehetővé teszi az FPGA-ban kialakított rendszerben a belső jelek vizsgálatát.
A diplomaterv kiírásnak megfelelően megvizsgáltam az új fejlesztői kábelnek a Xilinx ISE és EDK szoftverekbe való integrálási lehetőségeit, erről bővebben a 11. fejezet szól. Az ISE, az EDK és a ChipScope alapvetően a JTAG interfészen keresztül teremt kapcsolatot az eszközökkel.
Az ISE fejlesztői környezetben a programozható eszközök konfigurálása az iMPACT program segítségével végezhető el. A program lehetőséget biztosít távoli számítógépekhez csatlakoztatott letöltőkábelek elérésére is. Ekkor a távoli gépen futnia kell egy kábelszerver alkalmazásnak, amellyel az iMPACT TCP/IP protokollon keresztül kommunikál. A fejlesztői kábelnek az ISE rendszerbe történő integrálása tehát egy ilyen kábelszerver alkalmazás elkészítésével valósítható meg.
Az EDK fejlesztői környezetben a mikroprocesszoros rendszerrel a kapcsolatot az XMD (Xilinx Microprocessor Debug) program biztosítja, de ebbe sajnos nincs beépítve a kábelszerver alkalmazás támogatása. MicroBlaze processzort használó rendszer esetén az XMDStub debug opcióval lehetőség van a soros porton keresztül történő kommunikációra is. A fejlesztői kábel soros portját az általam készített virtuális soros port meghajtó elérhetővé teszti az XMD számára.
7
3 A JTAG interfész A JTAG interfészt eredetileg a digitális áramkörök tesztelésére hozták létre (boundary-scan). Az áramkörök méretének csökkentése érdekében felületszerelt tokozású alkatrészeket és többrétegű nyomtatott áramköröket használnak. Ilyen technológiák alkalmazása mellett a gyártási hibák tesztelése az akkori módszerekkel nem volt könnyen megoldható. A tesztelés megkönnyítése érdekében azt a megoldást választották, hogy az áramkörökhöz úgynevezett boundary-scan regisztereket adnak hozzá. Ezek segítségével az IC-k lábaira adatokat lehet kiírni, illetve a lábakon megjelenő értékeket lehet beolvasni. A JTAG interfész szolgál a boundary-scan cellák írására és olvasására. A JTAG interfészről [3]-ban olvashatunk bővebben.
Azoknál a programozható eszközöknél (CPLD, FPGA, mikrovezérlők, stb.), ahol a teszteléshez ki lett alakítva a JTAG interfész, ott általában ezen keresztül is megoldható a konfigurálás.
A JTAG interfész egy egyszerű szinkron soros kommunikációs protokollt használ. Az eszközökkel való kommunikációhoz négy jelre van szükség: •
TDI (Test Data Input): soros adatbemenet
•
TDO (Test Data Output): soros adatkimenet
•
TCK (Test Clock): órajel
•
TMS (Test Mode Select): a TAP kontroller vezérlésére szolgál
•
TRST (Test Reset): a TAP kontroller alapállapotba állítására szolgál (opcionális)
Az eszközök a TDI és a TMS vonalakat a TCK jel felfutó élére mintavételezik, a TDO vonalon az új érték a TCK jel lefutó élének hatására jelenik meg.
A soros interfészen keresztül az eszközök láncba fűzhetők (JTAG lánc). Ennek módját mutatja a 3-1. ábra. Az áramkörök TDO lába csatlakozik a következő áramkör TDI lábára, a TCK és a TMS jelek közösek.
3-1. ábra: A JTAG lánc kialakítása.
8
Minden JTAG interfészt implementáló IC tartalmaz egy TAP (Test Access Port) vezérlőt és belső regisztereket. Ezek a regiszterek két csoportra oszthatók: az utasításregiszterre és az adatregiszterekre. Az eszköz többféle adatregisztert tartalmazhat, például: •
Boundary-scan regiszter (kötelező).
•
Bypass-regiszter, amely a JTAG lánc lerövidítésére szolgál (kötelező).
•
ID regiszter, amelyből kiolvasható az eszközazonosító kód.
•
Az eszköz programozására, konfigurálására szolgáló regiszterek.
•
Stb.
3.1 A boundary-scan cella A boundary-scan cellák felépítése a 3-2. ábrán látható (forrás: [3]). Az ábra az univerzális BC-1 típusú cellát mutatja, lehetségesek azonban más típusú cellák is. Az egyes cellák az SI és SO vonalak segítségével egy shiftregiszterré vannak összekapcsolva. A soros bemeneten (TDI) és kimeneten (TDO) tudja a felhasználó a cellák tartalmát kiolvasni, illetve módosítani. A shiftregiszter párhuzamos bemenete és kimenete a digitális áramkörhöz és a tokozás lábaihoz kapcsolódik.
3-2. ábra: A boundary-scan cella felépítése. Minden egyes boundary-scan cella képes: •
A bemeneti jelek értékeinek azonos időben történő mintavételére (CAPTURE).
•
A kimeneti jelek értékeinek azonos időben történő frissítésére (UPDATE).
•
A soros adatok továbbítására a szomszédos cellának (SHIFT).
•
Transzparens működésre.
A fenti műveletekhez a TAP vezérlő egy-egy állapota rendelhető hozzá (lásd az állapotgráfot).
9
Az áramkörök olyan kivezetéseihez, amelyek kimenetként és bemenetként is tudnak viselkedni (I/O lábak), a boundary-scan regiszrerben három egymást követő bit tartozik. Az egyik bit szolgál az adott kivezetés értékének beállítására (ha az kimenetként van konfigurálva), egy másik bit tartalmazza a kivezetés aktuális értékét, a harmadik bittel pedig a kimeneti meghajtó engedélyezhető, illetve tiltható.
3.2 A TAP vezérlő A TAP kontroller egy 16 állapotú véges automata, ez vezérli az egyes boundary-scan cellákat és az egyéb belső regisztereket is. A vezérlő állapotgráfja a 3-3. ábrán látható. Az állapotátmeneteket a TMS jel vezérli, ezen értékek vannak a nyilakra írva. Az ábrán látható, hogy külön állapotok szolgálnak az utasításregiszter (jobboldali oszlop) és az adatregiszterek (bal oldali oszlop) eléréséhez.
3-3. ábra: A TAP vezérlő állapotgráfja. Az utasításregiszter feltöltése és kiolvasása a SHIFT-IR állapotban történik. Az utasításregiszter kimenetére egy dekóder kapcsolódik, amely előállítja az adatregiszterek kiválasztó jelét és az egyéb belső vezérlő jeleket. Az érvénytelen utasításokat a dekóder BYPASS utasításként értelmezi. A JTAG szabvány az alábbi négy kötelező utasítást írja elő:
10
EXTEST
A boundary-scan regiszter írása és olvasása az áramkörök közötti külső összeköttetések teszteléséhez. Az utasítás hatására az eszköz teszt módba kerül.
BYPASS
Ez az utasítás szolgál a JTAG lánc lerövidítésére. Az utasítás hatására a TDI és a TDO vonalak közé egy 1 bites shiftregiszter iktatódik be.
SAMPLE/PRELOAD
A boundary-scan cellák írása és olvasása. Az eszköz normál működési módban marad. A SAMPLE és PRELOAD utasítások kódja azonos.
A kötelezően előírt utasításokon kívül az eszköz támogathat egyéb utasításokat is. Ilyen utasítások lehetnek például: •
INTEST: a boundary-scan regiszter írása és olvasása az áramkör belső tesztelésének céljából. Az áramkör teszt módba kerül.
•
IDCODE: ha az eszköz tartalmaz ID regisztert, akkor ezzel az utasítással lehet azt kiválasztani olvasásra.
•
USERCODE: a konfiguráció során a felhasználó által megadott azonosító kód kiolvasására szolgál.
•
USER1/USER2: a felhasználó által kialakított boundary-scan regiszterek kiválasztására szolgál. A USER utasítás általában az FPGA-kra jellemző.
•
Az eszköz konfigurálását végző utasítások (programozható eszközök esetén).
•
Stb.
3.3 Az SVF fájlformátum Az SVF (Serial Vector Format) egy szöveges fájlformátum, melynek feladata a JTAG buszon elvégzendő műveletek leírása. A JTAG interfészen keresztül programozható eszközök fejlesztői környezetei lehetőséget biztosítanak a konfigurálást végző SVF fájl létrehozására. A támogatottsága miatt a LOGSYS fejlesztői környezet is ezt a formátumot használja. Az SVF fájlok szintaktikájának részletes leírása [4]-ben található meg.
Az alábbiakban egy rövid példán keresztül tekintsük át az SVF fájlok szerkezetét, illetve, hogy az SVF fájlok feldolgozása során milyen műveleteket kell elvégezni. A példában szereplő fájlrészlet egy, a Xilinx iMPACT program által generált SVF fájlból való és a JTAG láncban található eszköz típusát ellenőrzi az ID kód alapján.
11
1. 2. 3. 4. 5. 6. 7. 8.
//Created using Xilinx iMPACT Software [ISE Foundation - 7.1.04i] TRST OFF; ENDIR IDLE; ENDDR IDLE; STATE RESET IDLE; //Loading device with 'idcode' instruction. SIR 6 TDI (09) SMASK (3f) ; SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f1414093) MASK (0fffffff) ;
Az 1. és a 7. sor megjegyzést tartalmaz, ezt a feldolgozás során nem kell figyelembe venni. A 2. sor megadja, hogy ha az eszköz rendelkezik Test Reset vonallal (a TAP vezérlő alapállapotba állítására való opcionális jel), akkor azt alacsony szintre kell állítani. A 3. és a 4. sorban található ENDIR és ENDDR parancsok szolgálnak az utasítás- és adatregiszter műveletek végállapotának beállítására, azaz a shift műveletek után az ’Exit1-DR’ vagy az ’Exit1-IR’ állapotból az itt megadott állapotba kell állítani a TAP vezérlőt. A példában mindkét művelet esetén a végállapot a ’Run Test Idle’. Az 5. sorban a STATE parancs hatására a jelenlegi állapotból át kell menni a ’Test Logic Reset’, majd pedig a ’Run Test Idle’ állapotba. A 7. sorban a SIR parancs kezdeményezi az utasításregiszter műveletet. Először a jelenlegi állapotból (’Run Test Idle’) át kell menni a ’Shift-IR’ állapotba, majd a TDI vonalra ki kell shiftelni az 100100 bitsorozatot. Az utolsó bit kiírásakor a TMS vonalat magas szintre kell állítani, ez biztosítja az ’Exit1-IR’ állapotba való átmenetet. Az utasításregiszter művelet végén az ’Exit1-IR’ állapotból vissza kell menni a ’Run Test Idle’ állapotba. A 8. sorban található adatregiszter művelet végrehajtása hasonló az előbb ismertetett utasításregiszter művelethez. Különbség viszont, hogy most a beolvasott 32 bites adatot össze kell hasonlítani a TDO és a MASK paraméterek által meghatározott 0x01414093 értékkel. Eltérés esetén jelezni kell a hibát és az SVF fájl további részének feldolgozását abba kell hagyni.
3.4 A BSDL fájlformátum A BSDL (Boundary Scan Description Language) fájlformátum a VHDL nyelvre épül, az áramkörökről többek között az alábbi adatokat tartalmazza: •
A kivezetések típusát (kimenet, bemenet, vagy kétirányú).
•
Az JTAG utasításregiszter hosszát.
•
A támogatott JTAG utasítások nevét és kódját.
•
Az azonosító kódot (az ID regiszter tartalmát).
•
A boundary-scan regiszter felépítését, a regisztert alkotó cellák típusát és az egyes biteknek a kivezetésekhez való hozzárendelését.
12
4 Az Universal Serial Bus (USB) Az USB kifejlesztésénél egy olcsó, gyors adatátviteli képességekkel rendelkező és felhasználóbarát bővítési lehetőség megalkotása volt a cél.
Ha egy USB perifériát csatlakoztatunk a számítógéphez, akkor azt vehetjük észre, hogy a periféria szinte azonnal működőképes, esetleg az első csatlakoztatáskor az eszközmeghajtó programot telepíteni kell. Az USB a felhasználó szeméből nézve egyszerűnek tűnik, azonban egy bonyolult hardver, protokoll és szoftver együttesről van szó. Erről tanúskodik az USB 2.0 specifikáció ([5]) több mint 600 oldala is. Az USB periféria csatlakoztatása után az operációs rendszer lekérdezi a perifériában található leírókat, és ezek alapján betölti a szükséges eszközmeghajtó programokat. Tehát az USB „plug & play” működésű, a felhasználói oldalról nézve nem igényel semmiféle beállítást.
4.1 Az USB topológiája A rendszer alapvető építőelemei a következők: •
Host (gazda) eszköz, amely az adatátvitelt vezérli.
•
Perifériák: a buszra csatlakoztatott eszközök.
•
Hub-ok: elosztó és jelismétlő eszközök.
A perifériák alacsony ára érdekében host-vezérlésű megoldást választottak a tervezők. Ez azt jelenti, hogy a rendszerben egyetlen master egység található (a PC-ben lévő USB Host Controller), az összes többi periféria slave egység. Ennek a megoldásnak köszönhetően az USB periféria áramkörök viszonylag egyszerű felépítésűek lettek, a vezérléshez szükséges „intelligencia” pedig a host kontrollerbe került. Minden periféria a csatlakoztatása után egy 7 bites egyedi címet kap, így egy host kontrollerhez legfeljebb 127 eszköz csatlakoztatható (a 0 cím fenntartott). Az USB fa topológiájában maximum 7 szint lehet a host-ot is beleértve (4-1. ábra).
4-1. ábra: Az USB topológiája.
13
4.2 A fizikai interfész A hardver megvalósítás igen egyszerű: az USB busz egy négyvezetékes kábel, ahol két jelvezeték (D+ és D-), valamint az eszközök működtetéséhez szükséges tápfeszültség (Vcc és GND) található meg. Az USB a perifériák számára 5V-os (4,4V garantált) rövidzárlat védett tápfeszültséget biztosít. A maximális áramfelvétel saját tápellátással rendelkező hubra történő csatlakozás esetén 500mA, buszról táplált hubra történő csatlakozás esetén 100mA és „alvás” (suspend) üzemmódban pedig 500µA lehet. Az „alvás” üzemmód energiatakarékossági célokat szolgál, minden perifériának ebbe a módba kell kapcsolnia, ha a buszon 3ms-ig nincs aktivitás.
Az USB 2.0 szabvány háromféle adatátviteli sebességet definiál: •
low-speed (1,5 Mbit/s): például billentyűzet, egér.
•
full-speed (12 Mbit/s): például modem.
•
high-speed (480 Mbit/s): például adattároló.
Egy high-speed periféria képes a lassabb full-speed módban is működni. Valójában a high-speed adatátviteli sebességet támogató perifériák mindig full-speed módban indulnak el és majd később, a host utasítására kapcsolnak át gyorsabb működésre, ha ez támogatott.
Az adatátvitel a D+ és D- differenciális vonalon keresztül történik szinkron módon. Az órajel a bitfolyamba van kódolva. Az órajel kódolásának módja NRZI, ez kiegészül még a bitbeszúrással, hogy biztosítva legyen a megfelelő gyakoriságú 0-1, illetve 1-0 átmenet.
4.3 Az adatátvitel Az USB transzfer iránya kétféle lehet: OUT és IN. Az elnevezések a host szerinti nézetből értendőek, tehát OUT transzfer esetén a host küld adatokat a periféria számára, illetve IN transzfer esetén pedig a periféria küld adatokat a host-nak.
A perifériákkal történő kommunikáció úgynevezett végpontokon keresztül történik. A végpont tulajdonképpen a perifériában található memóriaterület, amelyet a host is tud írni és olvasni. A kommunikációt minden esetben a host kezdeményezi. Ez alól egy kivétel van: „alvás” üzemmódban a perifériák is kezdeményezhetik a rendszer felélesztését (remote wakeup). Egy eszközben legfeljebb 16 OUT és 16 IN végpont lehet a végpontok 4 biten történő címzése miatt.
14
Egy USB transzfer adatcsomagokból áll, melyeket az úgynevezett csomag-azonosítók (packet ID, röviden PID) azonosítanak. A PID jelzi, hogy éppen milyen típusú csomag küldése történik. Az alábbi táblázat összefoglalja a fontosabb PID-ek nevét és funkcióját. A félkövérrel jelzett azonosítók csak a high-speed módban vannak jelen.
A PID típusa A PID neve Token IN OUT SOF SETUP Adat DATA0 DATA1 DATA2 MDATA Handshake ACK NAK STALL
NYET Speciális
PRE PING
Funkció Jelzi, hogy a host adatot vár a perifériától. Jelzi, hogy a host adatot fog küldeni a perifériának. A keretek kezdetét jelzi. A kontroll transzfer kezdeti SETUP fázisát jelzi. Ezek a PID-ek azonosítják a „hasznos” adatokat tartalmazó csomagokat.
Nyugta, amely jelzi a sikeres adatátvitelt. Nyugta, amely jelzi, hogy a periféria jelenleg elfoglalt és a transzfert később meg kell ismételni. Nyugta, amely jelzi, hogy valamilyen előreláthatatlan hiba történt, például az eszköz nem értette meg a neki címzett kérést. Nyugta, amely jelzi, hogy az adott végpont jelenleg nem tud több OUT transzfert fogadni (tele van). A low-speed adatátvitelt jelzi. A host ezzel le tudja kérdezni, hogy van-e hely a küldendő csomag számára az adott OUT végpontban.
4-2. ábra: USB csomagok.
A 4-2. ábrán egy USB transzfer látható. Az 1. csomag egy OUT token, ezt mutatja az OUT PID. Az OUT token jelzi, hogy a host adatokat fog küldeni a periféria számára a buszon keresztül. A 2. csomag tartalmazza ezeket az adatokat, ezt jelzi a DATA1 PID. A 3. csomag az átvitelvezérlésre (handshake) szolgál, a periféria az ACK token elküldésével jelzi a hibamentes adatátvitelt. A 4., 5. és 6. csomagok az előzőekhez hasonlóan szintén egy OUT transzfer részei. Vegyük észre azonban, hogy az ábrán kétféle DATA PID, a DATA1 és a DATA0 látható. Ez azért van, mert a hibavédelmet az USB kifejlesztésénél nagyon komolyan vették. Habár a token és az adat csomagok CRC kóddal védettek, de mi van, ha a handshake csomag sérül meg? Ennek észlelésére a host és a periféria oldal is nyilvántart minden végponthoz egy DATA TOGGLE bitet, melynek értéke mindig megváltozik az adatcsomagok
15
sikeres elküldése után. A bit értékét összehasonlítva az adatcsomagban található DATA0 vagy DATA1 azonosítóval kiszűrhetőek a hibás handshake csomagok.
Az USB host egy időalapot biztosít az eszközöknek azzal, hogy minden milliszekundumban elküld egy SOF (Start Of Frame) tokent. High-speed módban minden 1ms-os keret nyolc, egyenként 125µsos mikrokeretre (microframe) osztható, ezek mindegyikét egy-egy SOF token előzi meg. A host az adatátvitelt keretenként, illetve high-speed módban mikrokeretenként ütemezi.
Az USB szabvány négyféle adatátvitel típust (bulk, interrupt, isochronous és kontroll transzferek) biztosít, minden végpont ezek közül csak egyfélét támogat. IN transzferek esetén a kértnél kevesebb adat küldése megengedett, ez esetben a host befejezi az adatátvitelt.
4.3.1 Bulk transzfer
4-3. ábra: Bulk IN és bulk OUT transzferek.
A bulk adatátvitel burstös, a csomagok mérete maximum 64 bájt lehet full-speed módban, illetve maximum 512 bájt high-speed módban. A bulk adatok garantáltan hibamentesek, a hibás csomagokat a host automatikusan újraküldi. A host csak akkor ütemez bulk adatátvitelt, ha szabad busz idő áll rendelkezésre. Bulk transzfer esetén a handshake csomagok automatikusan biztosítják az átvitelvezérlést.
4.3.2 Interrupt transzfer
4-4. ábra: Interrupt transzfer.
Az interrupt átvitel hasonlít a bulk átvitelhez. A csomagok mérete maximum 64 bájt lehet full-speed módban és maximum 1024 bájt lehet high-speed módban. Az interrupt végpontokhoz tartozik egy lekérdezési időköz, amely biztosítja, hogy a host az adott végpontra a megadott időközönként átvitelt fog ütemezni. Interrupt transzfernek az IN végpontok esetén van értelme.
16
4.3.3 Isochronous transzfer
4-5. ábra: Isochronous transzfer.
Az isochronous adatok időkritikusak, a host adott sávszélességet foglal le ezek számára. Ezt a módot általában hang- és videoátvitel esetén szokták használni. A csomagok mérete maximum 1023 bájt lehet full-speed módban és maximum 1024 bájt lehet high-speed módban. Az isochronous transzfer esetén nincsenek handshake csomagok, a hibák észlelése csak a CRC kód alapján lehetséges. A teli végpont miatt nem fogadott, vagy a hibás csomagokat a rendszer eldobja és nincs újraküldés.
4.3.4 Kontroll transzfer
4-6. ábra: Kontroll transzfer.
A kontroll transzferek szempontjából kitüntetett szerepe van a 0. végpontnak. Ez egy kontroll végpont, implementálása minden USB eszközben kötelező. Az USB host egy speciális SETUP tokennel jelzi azokat a transzfereket, amelyek a perifériák konfigurálását és vezérlését végzik; ilyen speciális tokeneket csak a kontroll végpont képes fogadni. A kontrol végpont kétirányú.
Az USB szabvány definiál standard kéréseket (pl. a leírók lekérdezése), amelyeket minden eszköznek támogatnia kell. Léteznek még úgynevezett gyártóspecifikus kérések is, ezek funkcióját az eszköz tervezője határozza meg.
Mivel ez a típusú adatátvitel igen fontos, ezért itt van a legalaposabb hibaellenőrzés. A host mindig fenntart egy adott sávszélességet a kontroll transzferek számára. A kontroll transzferek két vagy három
17
fázisból állnak. A kezdeti SETUP fázisban a host egy 8 bájt méretű adatcsomagot küld a perifériának, amely a kérésről tartalmaz információkat: •
bmRequestType mező: a kérés típusáról (standard, osztályspecifikus vagy gyártóspecifikus kérés), a címzettről (eszköz, interfész, végpont vagy más) és az adat fázis irányáról (OUT vagy IN) ad információt.
•
bRequest mező: a kérés kódja.
•
wValue mező: értelmezése a kéréstől függ.
•
wIndex mező: értelmezése a kéréstől függ.
•
wLength mező: az opcionális DATA fázisban elküldendő adatok mérete.
A SETUP fázis után következhet az opcionális DATA fázis, amelyben további adatok átvitele lehetséges. A kontroll transzfert a STATUS fázis zárja le, ez tájékoztatja a hostot arról, hogy a kérés sikeresen végrehajtódott.
Amennyiben a periféria nem támogatja az adott kérést vagy a SETUP adatok nem megfelelőek, akkor ezt a STALL handshake elküldésével jelzi a host-nak.
4.4 Az USB perifériák logikai felépítése Az USB eszközök logikai felépítését az abban található USB leírók határozzák meg. Az eszköz azonosításához szükséges legfontosabb adatokat az USB eszköz leíró tartalmazza. Ebben megtalálható többek között a gyártó- és a termékazonosító kód (VID és PID), az eszköz adott osztályba történő besorolása, illetve a konfigurációk száma.
Az USB perifériáknak egy vagy több konfigurációja lehet, amelyek meghatározzák az eszköz viselkedését. Egy eszköz konfigurációi különbözhetnek az energiafogyasztásban, a bennük lévő interfészek számában és hogy támogatják-e a rendszer „alvó” állapotból történő felélesztését (remote wakeup). Az egyes konfigurációk adatait tárolják az USB konfiguráció leírók.
Az eszköz minden egyes konfigurációjának tartalmaznia kell egy vagy több interfészt, amelyek előírják, hogy a szoftvernek hogyan kell elérnie a hardvert. Az interfészeknek gyakran van másodlagos beállításuk (alternate setting), amelyek lehetővé teszik az adott interfész tulajdonságainak megváltoztatását úgy, hogy közben a többi interfész változatlan módon működhet tovább. Az interfészek adatait az USB interfész leírók adják meg. Általában a több interfészt tartalmazó perifériákban (kompozit eszközök) az egyes interfészek különböző funkciót valósítanak meg. A kompozit eszközöknél lehetőség van arra az USB leírók megfelelő megválasztásával, hogy az
18
operációs rendszer az egyes interfészekhez külön-külön eszközmeghajtót töltsön be, így azok önálló eszközként fognak látszani.
Az interfészekhez tartoznak a végpontok, de egy végpont nem lehet egy konfigurációban két különböző interfésznek is tagja. A végpont típusáról és az egyéb tulajdonságairól az USB végpont leírók adnak tájékoztatást.
4-7. ábra: Egy USB periféria logikai felépítése.
19
5 A tápfeszültség alatti csatlakoztatás kérdései A digitális áramkörök tápfeszültség alatti csatlakoztatásának megvalósítása korántsem olyan könnyű, mint ahogyan azt elsőre gondolnánk. A legtöbb korszerű digitális integrált áramkört CMOS technológiával gyártják, a nehézségek oka pedig éppen a standard CMOS áramkörök belső kialakításában keresendő.
A CMOS digitális IC-k esetében a gyártók szigorúbb alkalmazási előírásokat írnak elő, mint a TTL áramköröknél. Az egyik figyelmeztetés szerint a CMOS áramkörre addig nem vezethető jelfeszültség, amíg a tápfeszültséget rá nem kapcsolták. Egy másik megkötés, hogy a jelfeszültség nem haladhatja meg a tápfeszültség értékét. A katalógusban felsorolt maximális értékeket CMOS áramkörök esetén még pillanatszerűen sem szabad túllépni. Ezeket a korlátozásokat legegyszerűbben úgy lehet betartani, ha a rendszer módosítását kikapcsolt állapotban végezzük. A MOS kialakítású áramkörök azért érzékenyek a jelfeszültség és a tápfeszültség viszonyára, mert a gyártás során parazita bipoláris elemek (pl. tirisztor) alakulnak ki a belsejükben a föld és a tápfeszültség vonal között. A korlátozásoknál említett esetekben a parazita elem hajlamos a begyújtásra, ezt nevezik latch-up jelenségnek. Ilyen esetben rövidzárlat keletkezik és az IC azonnal tönkremegy. További kényes pont a CMOS digitális IC-k esetén az elektrosztatikus kisülés (ElectroStatic Discharge, ESD). Ha egy feltöltött tárgy az IC-n át kisül, akkor az áramkör szintén tönkremegy. A latch-up jelenség ellen a belső szerkezet átalakításával lehet védekezni, az elektrosztatikus kisülés hatása ellen pedig a gyártók az IC bemeneteire és kimeneteire diódás védőhálózatot telepítettek. Azonban éppen az ESD-védelmet biztosító diódák miatt továbbra sem szabad tápfeszültség mellett áramkört kivenni vagy behelyezni.
A vizsgálatokhoz egy egyszerű áramkört vegyünk példának, mondjuk egy sima CMOS invertert. Ennek a kapcsolási rajzát mutatja az 5-1. ábra.
5-1. ábra: CMOS inverter.
20
A CMOS áramkörök hagyományos bemeneti és kimeneti kialakítása esetén a bemenet és a kimenet a tápfeszültség és a föld felé is egy-egy diódát tartalmaz. A diódák vezetik le az elektrosztatikus kisüléseket, normális működés esetén le vannak zárva. Ha az integrált áramkörön nincs tápfeszültség, akkor ezek a diódák határozzák meg a bemenetek és a kimenetek viselkedését. A nyitott drainű kimeneteknél is megtalálható az ESD-védelem.
Nézzük meg, hogy hogyan hatnak egymásra a tápfeszültség alatti és a tápfeszültség nélküli áramköri részek. A részleges tápfeszültség kikapcsolást széleskörűen alkalmazzák például energiatakarékossági célból. Az ilyen helyzetbe kerülő áramkörök jelcsatlakozása és földpontja folyamatosan össze van kötve, de a tápfeszültség vezetékek csoportosítottak, s így egy-egy rész kikapcsolható. Az 5-2. ábra mutatja a részleges tápfeszültség kikapcsolás egy lehetséges esetét hagyományos ESD-védelemmel ellátott CMOS áramköröknél.
5-2. ábra: Részleges tápfeszültség kikapcsolás.
Az ábrán az első inverter folyamatosan kapja az 5V-os tápfeszültséget, és ennek kimenete egy másik inverter bemenetére kapcsolódik, amin nincs tápfeszültség. Ha az első inverter bemenete alacsony szinten van, akkor a kimenetén lévő magas szint miatt kinyit a második áramkörben a bemenet és a tápfeszültség közötti dióda. Ezen keresztül pedig tápfeszültséget kap az áramkör és minden más áramkör is, melyek ugyanarra a tápfeszültség vezetékre kapcsolódik. Ilyenkor jelentős áram is folyhat, amit a kimeneti fokozat vagy a dióda nem tud tartósan elviselni.
A hagyományos ESD-védelemmel rendelkező áramkörökből is építhető azonban a részleges tápfeszültség kikapcsolást támogató rendszer, csak a kialakuló hamis táplálásoknál meg kell akadályozni a káros áramértékek fellépését. Ez többféle módon is megoldható. Ha a tápfeszültség alatt maradó áramkör háromállapotú kimenetekkel rendelkezik, akkor megfelelő kiegészítéssel megoldható, hogy a másik rész kikapcsolásakor a kimenet nagyimpedanciás állapotba kerüljön. Ez megbízható védelem, de nem mindig alkalmazható. Ha a működő áramkör kimenete nem háromállapotú, akkor egyéb módszereket kell alkalmazni.
21
5-3. ábra: A soros áramkorlátozó ellenállás és a diódás megoldás.
Az 5-3. ábrán két lehetséges megoldás látható. Az egyik megoldásban egy soros áramkorlátozó ellenállást helyeztünk a működő és a kikapcsolt rész közé a jelútba. Ezzel az ellenállással érhető el, hogy a diódán átfolyó áram ne haladja meg a 10-20 mA-t (kb. ez a védődiódák maximális terhelhetősége). Mivel a részleges kikapcsolást a teljesítményfelvétel csökkentésére használják, ezért nem biztos, hogy célszerű egy újabb, feleslegesen disszipáló ellenállást beépíteni a készülékbe. Ennek a megoldásnak további hátránya, hogy jelentősen megnövelheti a kapcsolási időt. Egy másik lehetséges megoldásban egy dióda akadályozza meg a hamis tápáram fellépését. A disszipáció ez esetben kisebb értékű, de több áramköri elem szükséges és az alacsony jelszint megnő a bemeneten a diódán eső feszültség miatt.
Problémát jelent az is, ha az összekapcsolt IC-k tápfeszültsége eltérő. Ha ez az eltérés 0,5 V-nál nagyobb, akkor a megfelelő ESD-védő dióda kinyit. Ekkor is szükséges az áramkorlátozó megoldások használata.
Az újabb logikai integrált áramkör családoknál a gyártók másfajta védelmi megoldásokat alkalmaztak. Ezeknél az áramkörökben már nem az előbbiekben látott normál ESD-védelm található, a kimeneti fokozatnál a visszatáplálási út blokkolását egy újabb beintegrált p-n átmenettel oldják meg. Ez látható az 5-4. ábrán (forrás: [6]).
5-4. ábra: A módosított kimeneti fokozat.
22
Ilyen esetben részleges tápfeszültség kikapcsoláskor a kimeneten át csak egy minimális Ioff áram fog folyni. A katalógusok alapján ennek maximális értékére a gyártók 10 µA-t garantálnak. Az alkalmazott védelem miatt ezek az IC-k túlfeszültséget elviselő típusok, azaz képesek a tápfeszültséget meghaladó jelek kezelésére. Ezen felül egyes áramkörökbe egy feszültségkomparátor egységet is raktak, ami automatikusan nagyimpedanciás állapotba kapcsolja a kimeneteket, ha a tápfeszültség egy meghatározott érték alá csökken.
A hagyományos négydiódás ESD-védelem esetén a problémák elsődleges okai a csatlakozópontok és a tápfeszültség közötti diódák. Így a standard CMOS IC-k, például a CD4XXX, a 74C, 74HC és 74HCT sorozatú áramkörök mindegyikére igaz, hogy tápfeszültség mellett nem behelyezhető és eltávolítható elemek.
A csatlakozóhoz kapcsolódó áramköröknek olyan ESD-védelemmel kell rendelkezniük, hogy a csatlakozópontok és a tápfeszültség közt ne legyen dióda. Az újabb logikai áramkörök már mind ilyen védelemmel rendelkeznek, ide tartozik például a 74LVC, a 74ABT, a 74LVT, a 74ALVT és a 74AUC sorozat. Ezek az áramkörök tehát tápfeszültség mellett behelyezhetők, illetve eltávolíthatók. A kapcsolódás során keletkező zavarokat tovább lehet csökkenteni, ha olyan IC-ket alkalmazunk, melyek kimenete automatikusan nagyimpedanciás állapotba kerül alacsony tápfeszültség esetén. A zavarkeltés meg is szüntethető a jelvezeték előtöltésével, ez a funkció szintén megtalálható egyes integrált áramkörökben.
A fejlesztői kábel esetében elmondható, hogy a tápfeszültség alatti csatlakoztathatóságot és eltávolíthatóságot azok az áramkörök határozzák meg, amelyek közvetlen kapcsolatban vannak a célrendszerrel. Ha a korábbiakban említett szempontok figyelembevételével valósítjuk meg a hardvert, akkor ezek az áramkörök a szintillesztő IC-k és a tápellátást végző IC-k lesznek.
A normál kimeneti és bemeneti vonalak esetén a szintillesztést az SN74LVC1T45 ([7]), illetve az SN74LVC2T45 ([8]) (Texas Instruments) típusú áramkörökkel oldottam meg. Ezek az áramkörök csak a bitszámban különböznek egymástól, az előbbi 1 bites, míg az utóbbi 2 bites. Működésükhöz két tápfeszültség szükséges, amelyek az egyes oldalakat táplálják. A tápfeszültség mindkét oldalon 1,65V és 5,5V közötti lehet, tehát a szintillesztés széles feszültségtartományon megvalósítható. Ha a két tápfeszültség közül valamelyik nincs jelen, akkor mindkét oldal nagyimpedanciás állapotba kerül. Az adatátvitel iránya egy erre a célra szolgáló jellel állítható be. Az áramkörök 1,8V-os tápfeszültség esetén 70Mbit/s, 3,3V feletti tápfeszültség esetén pedig 420Mbit/s adatátviteli sebességre képesek.
23
Az I2C vonalak a nyitott kollektoros meghajtásuk miatt speciális szintillesztő áramkört igényelnek. Erre a feladatra a PCA9306 (Texas Instruments) típusú áramkört választottam ([9]). Itt is mindkét oldalnak külön-külön referenciafeszültsége van, a szintillesztés 1,2V és 5V között valósítható meg. Az egyetlen megkötés, hogy a megfelelő működés érdekében az egyik oldal referenciafeszültségének legalább 1V-tal nagyobbnak kell lennie a másik oldal referenciafeszültségénél. Az áramkör rendelkezik egy engedélyező bemenettel is, melynek segítségével a két oldal izolálható egymástól.
A tápellátást végző áramköröknek biztosítani kell, hogy kikapcsolt állapotban a kimenetük felől a bemenetük felé ne folyhasson áram. Az 5V-os kimeneti feszültség kapcsolására a MIC2544 (Micrel) típusú áramkört választottam ([10]). Ebben az IC-ben az áteresztő tranzisztor egy N-csatornás MOSFET, amely a source és a drain között nem tartalmaz védődiódát. Az N-csatornás MOSFET-ek jellemzője, hogy csak akkor vezetnek, ha a gate-jük magasabb feszültségen van, mint a source, ezért ez az áramkör teljesíti a szükséges feltételt. A tápfeszültségnél magasabb gate-feszültség előállítására az IC tartalmaz egy belső charge-pump fokozatot.
24
6 Fejlesztői kábel AT90USB1287 mikrovezérlővel Amint már korábban említettem, a fejlesztői kábel funkciói egy mikrovezérlővel vannak megvalósítva. Mivel a funkciók megvalósításához a 12 Mbit/s adatátviteli sebesség megfelelő, ezért egy full-speed módot támogató mikrovezérlő használata mellett döntöttem. Fontos szempont volt továbbá olyan típus alkalmazása, amely az USB port által szolgáltatott 5V-os feszültségről is táplálható, mert így alkatrészeket lehet megtakarítani.
A fentieknek megfelelő és az itthon is beszerezhető mikrovezérlők közül az Atmel cég AT90USB1287 típusú eszközére esett a választás, az eszközről bővebben [11]-ben olvashatunk. Ez a mikrokontroller a 8-bites AVR család tagja, valódi RISC architektúrájú, 32 darab 8 bites belső regiszterrel rendelkezik. Az AVR mikrovezérlők további előnye, hogy jól kialakított, fejlett belső perifériákkal rendelkeznek és van hozzájuk ingyenes C fordító (AVR-GCC).
6-1. ábra: A fejlesztői kábel blokkvázlata. A fejlesztői kábel blokkvázlata a 6-1. ábrán látható, a teljes kapcsolási rajz pedig a melléklet 17.1 pontjában található meg. A készülék az AT90USB1287 mikrokontrollerre épül, amely ellátja az összes kommunikációs és vezérlési feladatot. A mikrokontroller körül csak a funkciók ellátásához szükséges minimális számú alkatrész található meg.
25
A mikrovezérlő és a LOGSYS port között található szintillesztők lehetővé teszik, hogy a fejlesztői kábelt 1,65V és 5,5V közötti feszültséggel működő rendszerekhez csatlakoztassuk. A JTAG és az I/O vonalak feszültségszintje eltérő lehet, mert ezek külön-külön referenciafeszültséget kapnak a célrendszertől.
A
szintillesztő
áramkörök
a
mikrokontroller
felől
egységesen
5V-os
referenciafeszültséget kapnak, amelyet a mikrokontroller I/O portjai biztosítanak. A mikrovezérlő I/O kivezetései képesek a táplálást megoldani, mert a terhelhetőségük kb. 10-15 milliamper. A szintillesztők minden egyes csoportja (JTAG, órajel és reset, soros I/O, I2C) egyedileg engedélyezhető, mert ha a valamelyik referenciafeszültség nincs jelen, akkor a szintillesztők adatvonalai nagyimpedanciás állapotba kerülnek. Ez lehetővé teszi, hogy a csatlakozónak csak az éppen használt funkciókhoz tartozó I/O kivezetéseit hajtsuk meg, a többi pedig nagyimpedanciás állapotú marad.
A fejlesztői kábel 5V-os tápfeszültséget képes biztosítani a célrendszernek. Az 5V-os feszültség a MIC2544 típusú feszültségkapcsoló áramkörön ([10]) keresztül jut a kimenetre, a kapcsolón átfolyó áram legfeljebb 1,5A lehet. Ezt a típust a gyártó kifejezetten USB eszközökben való használatra javasolja. A MIC2544 IC hasznos funkciója a kimeneti áramkorlátozás, melynek értéke az ILIM kivezetés és a föld közé bekötött ellenállással állítható be. Az áramkorlátozás pontossága az adatlap szerint jobb, mint ±20%. A fejlesztői kábel háromféle áramkorlátozási érték beállítását teszi lehetővé: a fixen bekötött 510Ω-os ellenállás mellé még párhuzamosan beiktatható két 910Ω-os ellenállás az ILIM1 és ILIM2 open-drain meghajtású vonalak segítségével. A beállítható áramkorlátozási értékeket az alábbi táblázat foglalja össze. ILIM2 ILIM1
Kimeneti áramkorlátozás
230V = = 0,45 A = 450mA 510Ω
Z
Z
I LIMIT
Z
0
0
Z
1 1 + I LIMIT = 230V ⋅ = 0,7 A = 700mA 510Ω 910Ω
0
0
1 1 1 + + I LIMIT = 230V ⋅ = 0,95 A = 950mA 510Ω 910Ω 910Ω
Mivel egy USB port csak 500mA árammal terhelhető, ezért felmerül a kérdés, hogy van-e értelme a 700mA-es és a 950mA-es áramkorlátozási beállításoknak. Ha Y-kábelt használunk (2 USB portra csatlakoztatható kábel, a második csatlakozás csak tápellátási célt szolgál), akkor 1000mA áram is biztosítható, így ezek a beállítások értelmesek.
A mikrokontroller beépített 10 bites A/D átalakítója feszültség- és árammérési célra használható fel. Az A/D átalakító rendelkezik saját belső 2,56V-os referenciafeszültség forrással is, ezt a referenciafeszültséget használjuk a mérések során. Feszültségmérés esetén az 5V-os tápfeszültség
26
kimenet, a JTAG referenciafeszültség és az I/O referenciafeszültség értékét mérjük. Mivel ezek maximálisan megengedett értéke 5,5V lehet, ezért feszültségosztókat kell alkalmazni. Az 5V-os kimenet esetén 3-as, a szintillesztők referenciafeszültsége esetén pedig 5-ös az osztás. Az előbbi adatok alapján ki lehet számolni a feszültségmérések elméleti pontosságát (ULSB): •
A mérés pontossága az 5V-os kimenet esetén:
U 5V , LSB = 3 ⋅ •
U ADCref 2
10
= 3⋅
2,56 = 0,0075 V = 7,5 mV 210
A mérés pontossága a referenciafeszültségek esetén:
U ref , LSB = 5 ⋅
U ADCref 2
10
= 5⋅
2,56 = 0,0125 V = 12,5 mV 210
Az árammérésnél kihasználjuk, hogy az AVR mikrovezérlő A/D átalakítója képes differenciális módban is működni, azaz két analóg bemenet közötti feszültségkülönbséget is tud mérni. Differenciális módban az eredmény kettes komplemens formátumú és 1x, 10x, illetve 200x erősítést is be lehet állítani. Az áramkör adatlapja szerint 1x és 10x erősítés esetén 8 bites felbontás, 200x erősítés esetén pedig 7 bites felbontás várható. A célrendszer által felvett áram mérése tehát egy soros ellenállás alkalmazásával megoldható, melynek értéke jelen esetben 0,2Ω. A maximálisan mérhető áramerősség (Imax) és a mérés várható pontossága (ILSB): •
200-szoros erősítés esetén:
I 200,max = •
U ADCref 200 ⋅ Rsoros
=
I 2,56 = 0,064 A = 64 mA; I 200, LSB = 200,7max = 0,5 mA 200 ⋅ 0,2 2
10-szeres erősítés esetén:
I 10,max =
U ADCref 10 ⋅ Rsoros
=
I 2,56 = 1,28 A; I 10, LSB = 10, max = 0,005 A = 5 mA 10 ⋅ 0,2 28
A fent kiszámított mérési pontosságok várhatóan nem fognak teljesülni az alkatrészek pontatlansága és az A/D konverter hibái miatt. A mérések igazából csak tájékoztatási célt szolgálnak, ezért a nagyfokú pontosság nem elvárás.
A mérési és a tápfeszültség ellátási lehetőségekről az előbbiekben volt szó. Nézzük meg most, hogy miként lehetséges a többi funkció megvalósítása. A JTAG interfészt szoftveresen kell megvalósítani, mert erre vonatkozóan hardveres támogatást a mikrovezérlő nem tartalmaz. A mikrokontroller USART perifériája UART, USRT és SPI módban is képes működni. Az utóbbi kettő esetén csak a master üzemmód használata lehetséges, mert a csatlakozó órajel vonala kimenet. Az USART órajel kimenete össze van kötve a TIMER3 időzítő kimenetével. A rövidzárlat elkerülése érdekében a mikrovezérlő programjának biztosítania kell, hogy ezek közük egyszerre csak az egyik I/O láb legyen
27
kimenetként konfigurálva. A TIMER3 időzítő segítségével 8MHz és 0,2Hz közötti frekvenciájú órajelet lehet hardveresen előállítani. A mikrovezérlő I2C perifériájának (az adatlap ezt TWI-nek nevezi) SDA és SCL vonalai a soros I/O vonalakra vannak kivezetve, így az I2C adatátvitel használata esetén lehetőség van még az órajel és a reset jel kiadására is.
Az alábbi táblázatban látható az egyes kommunikációs funkciók által használt jeleknek és a csatlakozó I/O kivezetéseinek az összerendelése. Funkciók
JTAG UART USRT SPI I 2C szoftveres soros I/O
TDI
TDO
TMS
TDI -
TDO -
TMS -
-
-
-
A csatlakozó I/O kivezetései TCK órajel reset soros kimenet TCK TXD CLK TXD CLK /CS MOSI SDA -
CLK
RST
SDO
soros bemenet RXD RXD MISO SCL SDI
A kábelen található egy sárga (D1) és egy zöld LED (D2), amelyek a rendszer állapotáról adnak tájékoztatást a felhasználónak. A jelzések jelentését az alábbi táblázat tartalmazza. Jelzés nem ég folyamatosan ég villog
Sárga LED (D1) nincs feszültség a tápellátást biztosító kivezetéseken a fejlesztői kábel tápfeszültséget ad a célrendszernek a fejlesztői kábel nem ad ki tápfeszültséget, de valamelyik tápellátást biztosító kivezetésen 0,2Vnál nagyobb feszültség van
Zöld LED (D2) egyetlen kommunikációs funkció sem aktív legalább egy funkció aktív, de nem történik adatátvitel legalább egy funkció aktív és adatátvitel van folyamatban
A fejlesztői kábel nyomtatott áramköre négyrétegű, az egyes rétegek rajzolatai kétszeres nagyításban megtalálhatóak a melléklet 17.2 pontjában. Az összeszerelt fejlesztői kábel a 6-2. ábrán látható, valódi mérete 48mm x 16,5mm.
6-2. ábra: Az összeszerelt fejlesztői kábel.
28
7 A LOGSYS Spartan-3E kártya A LOGSYS-BLOXES Spartan-3E FPGA kártya az [1]-ben ismertetett CPLD kártya leváltására készült. A CPLD kártyán egy 64 makrocellás Xilinx CoolRunner-II (XC2C64) típusú eszköz található, amelynek mérete már nem teszi lehetővé az összetettebb logikák megvalósítását. Az új kártyára nézve az alábbi főbb szempontok fogalmazódtak meg: •
Az FPGA legyen közepes kapacitású (200-400 ezer kapu), ez lehetővé teszi az összetettebb logikák és a kisebb mikroprocesszoros rendszerek megvalósítását is.
•
Legyenek rajta megjelenítő (LED-ek, kijelzők) és beviteli eszközök (nyomógombok, kapcsolók).
•
Legyen rajta külső SRAM és FLASH memória, melyek lehetőséget biztosítanak mikroprocesszoros rendszerek esetén a program és az adatok tárolására.
•
Legyen bővíthető különféle kiegészítő modulokkal.
•
Az új lábkiosztású LOGSYS porttal rendelkezzen (lásd 2-1. ábra).
A 7-1. ábrán látható az FPGA kártya blokkvázlata, a kapcsolási rajza pedig a melléklet 17.3 pontjában található meg.
7-1. ábra: Az FPGA kártya blokkvázlata. A szempontoknak megfelelő FPGA típusok közül a Xilinx cég XC3S250E-TQ144C áramkörére esett a választás ([12]). A 250 ezer kapus, TQ144 tokozású FPGA összesen 108 felhasználói I/O lábbal rendelkezik, melyek közül 28 csak bemenetként funkcionál. Ez egy kicsit megnehezítette a nyomtatott áramkör megtervezését.
29
A kártyán háromféle megjelenítő eszköz van: 8 darab LED, egy 4 digites hétszegmenses kijelző és egy 5x7-es pontmátrix kijelző. A kijelzők vezérlése időmultipexelt módon történik. A két kijelző esetén hét vezérlőjel közös, ezekkel lehet a hétszegmenses kijelző egyes szegmenseit, illetve a pontmátrix kijelző oszlopaiban található LED-eket bekapcsolni. Minden egyes karakter, illetve oszlop külön anódvezérlő jellel rendelkezik. A kijelzők anódjaira a 3,3V-os feszültséget az MMUN2111 típusú tranzisztorok kapcsolják rá. Ezek úgynevezett „digitális” tranzisztorok, ami annyit jelent, hogy a vezérléshez szükséges ellenállásokat az eszköz tartalmazza. Így tranzisztoronként két külső ellenállást meg lehet takarítani.
A kártyán található 5 darab nyomógomb és a 8-as DIP kapcsoló az FPGA bemeneti lábaira csatlakozik.
A kártyán kétféle típusú memória található. Az egyik egy 10ns hozzáférési idejű, 128k x 8 méretű SRAM (Samsung K6R1008V1D-TI10, [13]), a másik pedig egy 16 Mbit-es SPI buszos soros FLASH memória (Winbond W25P16-VSIG, [14]). Az SPI FLASH memóriából az FPGA képes magát felkonfigurálni, utána pedig az alkalmazás számára szabadon hozzáférhető. Ezért nincs szükség külön az FPGA konfigurációs adatait tároló nem felejtő memóriára. Az FPGA konfigurációs adatok a FLASH méretének kb. a tizedét foglalják el, tehát elegendő hely marad még a saját célú adatok számára is.
A kártyához a kiegészítő modulok illesztését két 16 pólusú csatlakozó teszi lehetővé. Mindkét csatlakozó lábkiosztása azonos, ez az FPGA kártya szerinti nézetből a 7-2. ábrán látható. A csatlakozókra ki van vezetve a 3,3V-os és az 5V-os tápfeszültség is, de az adatvonalak a 3,3V-os feszültségről járnak. A 13 adatvonal közül 11 ténylegesen kétirányú, 2 azonban csak bemenetként funkcionál (ezt másként nem lehetett megoldani, mert az FPGA összes I/O lába fel van használva).
7-2. ábra: A bővítőcsatlakozók lábkiosztása. Az FPGA felkonfigurálása kétféleképpen lehetséges. Egyrészt a LOGSYS port JTAG vonalain keresztül, ez a lehetőség mindig rendelkezésre áll. Másrészt pedig az SPI FLASH memóriából, ezt a konfigurációs módot egy jumperrel lehet engedélyezni, illetve letiltani. A FLASH memória felprogramozása csak az FPGA-n keresztül lehetséges. Például a JTAG vonalon keresztül az FPGA-ba letöltünk egy olyan konfigurációt, amely összeköttetést biztosít a fejlesztői kábel soros I/O vonalai és
30
a FLASH memória kivezetései között. Ezután a fejlesztői kábel SPI funkciója már használható a FLASH memória felprogramozására. A kártyán a PROG nyomógomb az FPGA alapállapotba hozására szolgál, ezzel újból elindítható a konfigurációs folyamat. A DONE LED jelzi, ha a konfiguráció sikeresen befejeződött.
Az FPGA-ba letöltött terv a kártyán lévő 16MHz-es oszcillátortól és a LOGSYS port CLK vonaláról kaphat órajelet. Ezek az FPGA órajel bemeneteire (GCLK lábak) vannak rákötve. Az FPGA-ban található DCM (Digital Clock Manager) modulok lehetőséget biztosítanak a frekvenciaszintézisre, ha magasabb frekvenciájú órajelet szeretnénk használni.
A kártya tápfeszültség ellátása alapvetően a fejlesztői kábelről történik, de lehetőség van más külső 5V-os egyenfeszültség forrás csatlakoztatására is. Az FPGA a működéséhez 3,3V-os (I/O kivezetések), 2,5V-os (DCM, JTAG) és 1,2V-os (belső mag) tápfeszültséget igényel. Az SRAM, a FLASH és az oszcillátor tápellátása a 3,3V-os feszültségről történik. Mivel a 2,5V-os tápfeszültség terhelése a legkisebb (kb. 100-200mA), ezért ennek előállítására megfelel egy normál lineáris feszültségstabilizátor is (LM1117-ADJ). Az 1,2V-os és a 3,3V-os tápfeszültség terhelése nagyobb, ezért a jobb hatásfok elérése érdekében ezek előállítása kapcsolóüzemű tápegységgel történik. A kártyán a Microchip gyártmányú MCP1612 típusú kapcsolóüzemű tápegység IC található ([15]). Az áramkör kimenete 1 amperrel terhelhető. A kapcsolási frekvencia 1,4MHz, ez lehetővé teszi kisméretű induktivitások alkalmazását.
A Spartan-3E FPGA kártya nyomtatott áramköre kétrétegű, az egyes rétegek rajzolatai megtalálhatóak a melléklet 17.4 pontjában. Az összeszerelt kártya a 7-3. ábrán látható, valódi mérete 102mm x 65mm.
7-3. ábra: Az összeszerelt FPGA kártya.
31
8 A fejlesztői kábel firmware-je Ebben a fejezetben ismertetem a fejlesztői kábelen található AT90USB1287 mikrovezérlő programját. A firmware forráskód szintű ismertetésére a terjedelmi korlátok miatt nincs lehetőség, ezért az egyes funkciókat vázlatosan, a lényeges dolgokat kiemelve mutatom be. A firmware C és assembly nyelven íródott. C nyelvűek a bonyolultabb funkciókat (pl. az USB periféria kezelése) megvalósító kódrészek. Assembly nyelven készültek egyes megszakítás-kezelő rutinok és a gyors végrehajtást igénylő programrészek (pl. a JTAG funkció). A firmware teljes forráskódja megtalálható a CD mellékleten.
8.1 Az USB periféria megvalósítása A fejlesztői kábelben kialakított USB periféria logikai felépítése a 8-1. ábrán látható. Az eszköz egyetlen konfigurációval rendelkezik, amelynek áramfelvétele legfeljebb 500mA lehet, nem támogatja a PC „alvó” állapotból történő felélesztését és két interfész tartozik hozzá. A 0. interfésznek négy bulk végpontja van, ezeken keresztül lehet kommunikálni az UART kivételével az egyes funkciókkal. Az 1. interfész egy bulk és egy interrupt végpontot tartalmaz, ezek az UART funkcióhoz tartoznak. Mivel az elsődleges konfigurációnak két interfésze van, ezért ez egy kompozit eszköz. Kompozit eszközök esetén a Windows az egyes interfészekhez külön eszközmeghajtót tölt be, így azok önálló eszközként látszanak: •
A 0. interfész a fejlesztői kábelt reprezentálja (általános célú USB meghajtó).
•
Az 1. interfész az aszinkron soros portot reprezentálja (virtuális soros port meghajtó).
8-1. ábra: Az USB periféria logikai felépítése.
32
A fejlesztői kábel összes végpontja 64 bájt méretű (full-speed mód esetén ez a lehetséges legnagyobb méret) és a kontroll végpont kivételével duplán pufferelt. A dupla pufferelés azért fontos, mert amíg a firmware a végpont egyik pufferével foglalkozik, addig a host képes hozzáférni a másik pufferhez. Így jó esetben nem kell a két félnek egymásra várakoznia.
A firmware kontroll transzferekkel foglalkozó része valósítja meg a szabványban előírt standard USB kérések kezelését, amelyeket minden USB perifériának támogatnia kell. Ez a rész a funkcióknak szóló gyártóspecifikus USB kérésekkel nem foglalkozik, hanem azokat átadja a megfelelő funkciónak, amely majd végrehajtja az adott kérést. Ugyanígy a bulk és az interrupt végpontok kezelése is az egyes funkciók feladata. A kontroll transzferek kezelése megszakítások használatával történik.
Az USB kontroll transzferek kezelését végző kódrészlet a CD mellékleten a \firmware\usb könyvtárban található meg.
8.2 A funkciók megvalósítása Az egyes funkciók lekérdezéses vagy megszakításos módon kezelhetik a hozzájuk tartozó hardveregységeket. E szempont alapján a funkciók az alábbi csoportokba sorolhatók be: •
A perifériákat csak lekérdezéses módon kezelő funkciók: JTAG, SPI.
•
A perifériákat csak megszakításos módon kezelő funkciók: UART, USRT, I2C, szoftveres soros I/O.
Az SPI funkció megvalósítható lenne megszakításos módon is, de ez esetben a megszakítás-kezelő rutin végrehajtási ideje korlátozná a maximális adatátviteli sebességet kb. 200 kHz-re. Nyilvánvaló, hogy egyszerre csak egy lekérdezésesen kezelt funkció lehet aktív. Egy megszakításos és egy lekérdezéses módon kezelt funkció működhet egymás mellett, amennyiben nem használnak azonos erőforrásokat. Itt erőforrások alatt a csatlakozó I/O kivezetéseit és a mikrovezérlő beépített perifériáit kell érteni. Az alábbi táblázat összefoglalja a funkciók és az erőforrások közötti kapcsolatokat.
Funkciók JTAG UART USRT SPI I2C sw. soros I/O órajel kiadás reset jel kiadás
A csatlakozó I/O kivezetései JTAG CLK RST soros I/O X X X X X X X X X X X X X
33
A mikrovezérlő perifériái USART TWI TIMER3 X X X X X X
A táblázat alapján látható, hogy például a JTAG és az UART funkciók képesek egymás mellett működni, vagy az I2C kommunikáció mellett még ki lehet adni órajelet és reset jelet. A lekérdezéses és a megszakításos módon kezelt funkciók egymás melletti működéséhez még az is szükséges, hogy a végpontok használatában se legyen ütközés. Ezért az előbbiek az EP1 OUT és az EP2 IN végpontokat, míg az utóbbiak az EP3 OUT és az EP4 IN végpontokat használják.
Minden kommunikációs funkcióhoz tartozik két alapvető USB gyártóspecifikus kérés: az adott funkció megnyitása és lezárása. A megnyitás során a firmware mindig ellenőrzi, hogy van-e erőforrás ütközés. Ha van ütközés, akkor a kért funkció megnyitása nem lehetséges.
8.2.1 A JTAG funkció A JTAG funkció megvalósítása tisztán szoftveres. Ez a funkció kétféleképpen képes működni: írás/olvasás módban és ellenőrzéses módban. Az első esetben a firmware a beolvasott TDO adatokat visszaküldi a számítógépnek. A második esetben a számítógép elküldi a kiírandó TDI adatokkal együtt a várt TDO adatokat is és a firmware elvégzi az összehasonlítást. Utóbbi például SVF fájlok letöltése esetén hasznos, mert abban mind a TDI, mind pedig a TDO adatok megtalálhatók. Ekkor nincs szükség a bulk IN transzferekre, hanem csak a letöltés végén kell egy kontroll transzfer segítségével lekérdezni, hogy volt-e hiba az összehasonlítások során. Hiba esetén a firmware eldobja a PC felől érkező további adatokat, amíg a hibajelzést nem töröljük.
A JTAG funkció hatékonysága érdekében lényeges a kommunikáció során használt adatszerkezet. Itt alapvetően kétféle megoldás képzelhető el. Egyik lehetőség, hogy a vett bájtokat közvetlenül a mikrokontroller I/O portjára írjuk ki. Ez a módszer gyors, de pazarló, mert nagyméretű transzfereket igényel. A másik lehetőség, hogy egy szoftveres shiftregisztert valósítunk meg. Ez a megoldás valamivel lassabb, de kevesebb adat átvitelét igényli. A firmware ez utóbbit, azaz a shiftregiszteres megoldást valósítja meg a 8-2. ábrán látható adatszerkezettel. A vett adatok ilyen 2 vagy 4 bájtos blokkokat tartalmaznak.
1. bájt
7. bit
6. bit
5. bit
TDI/TMS
TMS value
RUNTEST
4. bit
3. bit
2. bit
1. bit
a kiírandó bitek száma / TCK pulzusok száma (H)
2. bájt
a kiírandó bitek / TCK pulzusok száma (L)
3. bájt
a várt TDO érték / TCK pulzusok száma (H)
4. bájt
a TDO adat maszkja / TCK pulzusok száma (L) csak írás/olvasás módban
csak ellenőrzéses módban
8-2. ábra: A JTAG adatszerkezet.
34
0. bit
A TDI/TMS bit mondja meg, hogy a kiírandó bitek a TDI (TDI/TMS=0) vagy a TMS (TDI/TMS=1) vonalra kerüljenek. Az előbbit az adatok írásánál és olvasásánál használjuk, az utóbbi pedig a TAP kontroller állapotának beállításához kell. Ha az adatbiteket a TDI vonalra írjuk ki, akkor az utolsó bit kiírásakor a TMS vonal a TMS value értékét veszi fel, egyébként pedig 0. Ez a SHIFT állapotokból való kilépés hatékony megoldása. Ha a RUNTEST bit értéke 1, akkor a TCK vonalra a megadott számú órajelpulzust lehet kiküldeni és a TMS vonal értéke a TMS value bit lesz. Ez a lehetőség a várakozásoknál hasznos (RUNTEST SVF parancs). Írás/olvasás módban az egyszerre kiküldhető TCK pulzusok száma 4096, ellenőrzéses mód esetén pedig ez az érték 65536. A 3. és a 4. bájt csak ellenőrzéses módban van jelen.
Írás/olvasás módban a számítógépnek ugyanannyi bájtot kell visszaolvasnia, mint amennyit elküldött. A visszaolvasott bájtok közül csak minden második a hasznos TDO adat, a többi bájt értéke 0.
A JTAG funkciót megvalósító kódrészlet a CD mellékleten a \firmware\functions\jtag könyvtárban található meg.
8.2.2 Az UART és az USRT funkció Az UART és az USRT funkció az AVR mikrovezérlőben található USART perifériával van megvalósítva, melynek kezelése megszakításos módon történik. A két funkció az 1. interfész végpontjait használja (EP5 OUT és EP6 IN). Az USRT csak abban különbözik az UART-tól, hogy ekkor a mikrovezérlő kiadja az adatátviteli sebességet meghatározó órajelet is.
Az adási oldalon kezdetben engedélyezve van az EP5 OUT végponton az „adat érkezett” megszakítás és tiltva van az USART periféria „adási regiszter üres” megszakítása. Ha adat érkezik az EP5 OUT végpontba, akkor a megszakítás-kezelő rutin feltölti az USART adási regiszterét, majd pedig tiltja a végpont „adat érkezett” megszakítását és engedélyezi az USART „adási regiszter üres” megszakítását. Az USART „adási regiszter üres” megszakítás-kezelő rutinja kiolvassa a végpontból az adatokat és beírja azokat az adási regiszterbe. Ha a végpontban már nincs több adat, akkor beállítja a fent említett kezdeti állapotot.
A vételi oldalon kezdetben engedélyezve van az USART periféria „vételi regiszter tele” megszakítása és tiltva van a TIMER0 időzítő megszakítás. Egy karakter vétele esetén a „vételi regiszter tele” megszakítás-kezelő rutin először ellenőrzi, hogy írható-e az EP6 IN végpont. Ha nem írható, akkor túlcsordulás történt. Ha írható, akkor megvizsgálja, hogy a karakter vétele során történt-e hiba (kerethiba, paritáshiba, vételi regiszter túlcsordulása) és hibátlan vétel esetén beírja a vett karaktert az
35
EP6 IN végpontba. Az első karakter vétele után engedélyezi a TIMER0 időzítőt. Az EP6 végpont élesítése (élesítés után tudja kiolvasni a végpontból az adatokat az USB host) kétféleképpen történhet: •
63 karakter vétele után az USART „vételi regiszter tele” megszakítás-kezelő rutinja élesíti a végpontot (a végpont mérete 64 bájt, az utolsó bájt a vételi státusz információ számára van fenntartva).
•
Az engedélyezéstől számított 5ms múlva lejár a TIMER0 időzítő és annak megszakítás-kezelő rutinja élesíti a végpontot.
Az EP6 IN végpont élesítése után mindkét esetben le kell tiltani a TIMER0 időzítőt. Ezzel a módszerrel biztosítható, hogy a vett adatokat meghatározott időn belül megkapja a számítógép. Az élesítés előtt a megszakítás-kezelő rutin beírja a végpontba a státuszbájtot, amely az előfordult vételi hibákról ad tájékoztatást. Ha a vétel során hiba történt, akkor a megszakítás-kezelő rutin azonnal élesíti az EP6 IN végpontot. Az EP6 IN végpont egy interrupt végpont 1ms lekérdezési időközzel, tehát a host minden milliszekundumban adatátvitelt fog ütemezni erre a végpontra.
Az UART/USRT funkcióhoz tartozó USB gyártóspecifikus kérések az alábbiak: •
Az UART képességeinek lekérdezése.
•
Azonnali karakter küldése. Az itt megadott karaktert az EP5 OUT végpontban található adatok előtt kell elküldeni.
•
Az UART alapállapotba állítása.
•
Az elküldendő adatok törlése.
•
A vett adatok törlése.
•
Az adatátviteli sebesség beállítása és lekérdezése.
•
A vonali kódolás beállítása és lekérdezése.
•
Az USRT mód engedélyezése, illetve tiltása.
Az UART/USRT funkciót megvalósító kódrészlet a CD mellékleten a \firmware\functions\usart könyvtárban található meg.
8.2.3 Az SPI funkció Az SPI funkció az UART funkcióhoz hasonlóan a mikrovezérlő USART perifériájával van megvalósítva, melynek kezelése most lekérdezéses módon történik. Az SPI kommunikáció esetén minden írási művelethez tartozik egy olvasás is, ez egyszerűsíti a funkció megvalósítását. Az alkalmazói programnak ugyanannyi bájtot kell beolvasnia, mint amennyit elküldött.
A funkció elindítása után a firmware várakozik, amíg az EP1 OUT végpontba nem érkezik adat. Az adatok megérkezése után a program a vett bájtokat beírja az USART adási regiszterébe. Minden egyes
36
bájt elküldése után várakozni kell az adatátvitel befejeződésére, majd az USART vételi regiszterének tartalmát be kell írni az EP2 IN végpontba. Ha az EP1 OUT végpont kiürült, akkor a firmware mindkét végpontot élesíti. Ezután az egész folyamat kezdődik elölről.
Az SPI funkcióhoz az alábbi USB gyártóspecifikus kérések tartoznak: •
Az órajel frekvenciájának beállítása és lekérdezése.
•
Az adatátviteli mód beállítása és lekérdezése:
•
-
írási és olvasási órajel él (felfutó vagy lefutó).
-
órajel inaktív szintje (alacsony vagy magas).
-
bitsorrend (MSB-t vagy LSB-t küldjük ki/olvassuk be először).
A /CS (chip select) jel értékének beállítása és lekérdezése.
Az SPI funkciót megvalósító kódrészlet a CD mellékleten a \firmware\functions\spi könyvtárban található meg.
8.2.4 Az I2C funkció Az I2C funkció megvalósításánál a mikrovezérlőben található TWI perifériának csak a master üzemmódját használjuk, a fejlesztői kábel esetén a slave mód használatának nincs értelme. A TWI periféria kezelése megszakításos módon történik.
Az adatátvitel indításának első lépése az alábbi információk elküldése az EP3 OUT végpontra: •
A kiírandó/beolvasandó adatok mérete (max. 65536 bájt).
•
Írásról vagy olvasásról van-e szó.
•
A szolga egység címének mérete (7 vagy 10 bit).
•
A szolga egység címe.
A firmware a fenti adatok vétele után generál egy START feltételt, elküldi a szolga egység címét, majd az alkalmazói programnak elküldi a státusz információt. Hiba esetén ismételt START feltétel vagy STOP feltétel generálható. Ha a megcímzett szolga egység nyugtázta a kérést, akkor következhet a tényleges adatátvitel. Olvasás esetén, ha menetközben hiba történik, akkor az alkalmazói program a kértnél kevesebb adatot fog kapni. Ennek észlelése esetén egy gyártóspecifikus kéréssel le tudja kérdezni a hibakódot. Írás esetén az alkalmazói program a művelet sikeres befejeződését vagy a hibát az EP4 IN végpontból kiolvasott státusz kód alapján észlelheti. Az adatátvitel befejezése után az ismételt START feltétel küldésével egy újabb transzfer indítható, vagy a STOP feltétel generálásával felszabadítható az I2C busz.
37
Az I2C funkcióhoz tartozó gyártóspecifikus kérések a következők: •
Az órajelfrekvencia beállítása és lekérdezése.
•
Az elkezdett adatátvitel leállítása.
•
Az előző művelet státuszának lekérdezése.
Az I2C funkciót megvalósító kódrészlet a CD mellékleten a \firmware\functions\i2c könyvtárban található meg.
8.2.5 A szoftveres soros I/O funkció A szoftveres soros I/O funkció lehetőséget biztosít a soros kimenet és a reset vonal tetszőleges vezérlésére. Ezzel a funkcióval a felhasználó saját szinkron soros kommunikációs protokollt valósíthat meg. A fejlesztői kábel a TIMER3 időzítő segítségével hardveresen generálja az órajelet és a beállított órajel éleknél történik az adatok kiírása, illetve a bemenet mintavételezése.
A TIMER3 időzítő által generált megszakítások kezelésekor a firmware megvizsgálja az órajel vonal értékét, ez alapján észlelni lehet a felfutó vagy a lefutó éleket. A megfelelő élnél elvégzi az adatok kiírását, illetve a mintavételezését. A mikrovezérlő megfelelő I/O portjának írása és olvasása bájtosan történik. A vett és az elküldött bájtokban található bitek értelmezése a 8-3. ábrán látható. A megszakításos működés egyetlen hátránya, hogy a megszakítás-kezelő rutin végrehajtási ideje limitálja az órajel frekvenciáját.
7. bit -
6. bit
5. bit
-
órajel (hardveresen kezeljük)
4. bit
3. bit
2. bit
1. bit
0. bit
a reset jel értéke
a soros kimenet értéke
a soros bemenet értéke
-
-
8-3. ábra: Az I/O vonalak vezérlése.
Az órajelet csak akkor adjuk ki, ha az EP3 OUT végpontban van kiírandó adat. A szoftveres soros I/O funkció esetén az alkalmazói programnak ugyanannyi bájtot kell visszaolvasnia az EP4 IN végpontból, mint amennyit beírt az EP3 OUT végpontba.
A funkcióhoz tartozó USB gyártóspecifikus kérések: •
Az órajel frekvenciájának beállítása és lekérdezése.
•
Az órajel inaktív szintjének beállítása és lekérdezése.
•
Az I/O vonalak (az órajel kivételével) aszinkron módon történő írása és olvasása.
•
Az írási és az olvasási órajel élek beállítása és lekérdezése.
•
Az elkezdett művelet leállítása.
38
A
szoftveres
soros
I/O
funkciót
megvalósító
kódrészlet
a
CD
mellékleten
a
\firmware\functions\sw_sio könyvtárban található meg.
8.2.6 A mérési funkciók Az áram- és feszültségmérések elvégzése periodikusan, másodpercenként négyszer történik. A mérések időzítését a TIMER1 időzítő biztosítja. Ez a funkció állandóan működik, engedélyezésére és leállítására nincs lehetőség. Az alkalmazói program a mérési eredményeket egy USB kontrol transzferrel tudja lekérdezni. Az eredmények között a 10x és a 200x erősítéssel mért áramerősségek egyszerre szerepelnek, a valóságnak megfelelő értéket az alkalmazói programnak kell kiválasztania.
Az A/D átalakító kezelését megvalósító kódrészlet a CD mellékleten a \firmware\functions\adc könyvtárban található meg.
8.2.7 Egyéb funkciók A firmware a már említett funkciókon kívül még az alábbiakat is megvalósítja: •
Hardveresen előállított órajel kiadása.
•
Reset jel kiadása aszinkron módon.
•
Az 5V-os tápfeszültség kapcsolása és a kimeneti áramkorlátozás beállítása.
A TIMER3 időzítő által generált órajelet bármikor ki lehet adni, ha az órajel vonalat nem használja már egy kommunikációs funkció. Az órajel kiadással kapcsolatos USB gyártóspecifikus kérések a következők: •
Az órajel elindítása, illetve leállítása.
•
Az órajel frekvenciájának beállítása és lekérdezése.
A szoftveres soros I/O és az SPI funkció kivételével bármely egyéb kommunikációs funkció használata mellet lehetséges a reset vonal aszinkron módon történő vezérlése. A reset vonal értékének beállítása, vagy lekérdezése egy USB gyártóspecifikus kéréssel végezhető el.
Az itt említett funkciókat megvalósító kódrészlet a CD mellékleten a \firmware\functions\functions.c fájlban található meg.
39
9 Az eszközmeghajtó programok 9.1 Áttekintés Ebben a fejezetben ismertetem az általam készített eszközmeghajtó programokat. Terjedelmi korlátok miatt csak a legfontosabb feladatok megvalósítási elvének ismertetésére van lehetőség, a meghajtók írásához szükséges alapismereteket a [16] és a [17] irodalmak tartalmazzák. Utóbbiban a dokumentációk mellett megtalálhatók a forráskód lefordításához szükséges programok (C/C++ fordító, make, stb.) és könyvtárak is.
Egy eszközmeghajtó program lényegében szubrutinok gyűjteménye, amelyeket az operációs rendszer hív meg az adott hardverrel kapcsolatos műveletek végrehajtása érdekében. Az operációs rendszer sokféle kérést intézhet az eszközhöz, például: •
az eszköz megnyitása (IRP_MJ_CREATE)
•
az eszköz lezárása (IRP_MJ_CLOSE)
•
adatok írása (IRP_MJ_WRITE)
•
adatok olvasása (IRP_MJ_READ)
•
I/O kontroll kérések (IRP_MJ_DEVICE_CONTROL)
•
plug & play kérések (IRP_MJ_PNP)
•
tápellátással kapcsolatos kérések (IRP_MJ_POWER)
A tervezési szempontoknál már említettem az aszinkron I/O műveleteket. A kéréseket alapvetően kétféleképpen, szinkron és aszinkron módon lehet végrehajtani. Szinkron kérések esetén a kezdeményező szál futása blokkolódik a kérés végrehajtásának befejeződéséig. Aszinkron kérések esetén nincs blokkolás, ezért a kérés feldolgozása alatt is végezhető hasznos tevékenység, melynek elvégzése után természetesen a programnak várakoznia kell a művelet befejeződésére. Az eszközmeghajtó program részéről általában csak a hosszú végrehajtási idejű kéréseket érdemes aszinkron módon kezelni.
Az aszinkron műveletek esetén lehetséges az is, hogy az eszközmeghajtó akkor kap egy új kérést, amikor éppen egy korábban érkezett kérést hajt végre. Ezt a problémát a várakozási sorok használata oldja meg. Másik probléma, hogy az I/O műveletek végrehajtását szinkronizálni kell a plug & play és a tápellátással kapcsolatos kérésekkel (pl. egy USB meghajtónak az USB periféria eltávolításakor ki kell ürítenie a várakozási sorait). Itt számos versenyhelyzetet kell feloldani, ami még a gyakorlott programozóknak is nagy nehézséget jelent. Ezért [16] szerzője nem javasolja, hogy a várakozási
40
sorokat, illetve a plug & play és a tápellátással kapcsolatos kérések kezelését saját magunk valósítsuk meg, hanem a könyvéhez mellékeli az általa készített megoldást.
Az általam készített meghajtóprogramok a Kernel Mode Driver Framework (röviden KMDF) könyvtárat használják. A KMDF a Windows Driver Kit része ([17]) és biztosítja azokat az alapvető szolgáltatásokat, melyek szükségesek a kernel módban futó eszközmeghajtó programok számára. Ezek közé tartozik például: •
A plug & play és a tápellátással kapcsolatos kérések kezelése.
•
Az I/O sorok (várakozási sorok) implementálása.
•
A megszakítások (IRQ) kezelése.
•
A közvetlen memória hozzáférés (DMA) kezelése.
•
Szinkronizáció.
Az alkalmazói program és a meghajtó közötti adatcsere háromféleképpen történhet: •
Az alkalmazói program írási kérést küld a meghajtónak a WriteFile() függvény meghívásával. Ennek egyik paramétere egy mutató az elküldendő adatokra.
•
Az alkalmazói program olvasási kérést küld a meghajtónak a ReadFile() függvénnyel. Ennek egyik paramétere egy mutató a beolvasott adatokat tároló memóriaterületre.
•
Az alkalmazói program I/O kontroll kérést küld a meghajtónak a DeviceIoControl() függvény meghívásával. Ennek egyik paramétere egy mutató a művelet végrehajtásához szükséges adatokra (bemeneti puffer), másik paramétere pedig egy mutató a művelet által visszaadott adatokat tároló memóriaterületre (kimeneti puffer).
Az adatátvitel hatékonysága érdekében lényeges, hogy a felhasználói adatok milyen módon érhetők el az eszközmeghajtóból. A Windows XP erre háromféle lehetőséget biztosít: •
BUFFERED módban az operációs rendszer lefoglal egy megfelelő méretű kernel módú memóriaterületet és elvégzi a szükséges irányokban az adatok másolását.
•
DIRECT módban az operációs rendszer lerögzíti a felhasználói módú adatpuffereket a memóriában (így nem kerülhetnek ki a lapozófájlba) és a meghajtónak átadja a puffer MDLjét (Memory Descriptor List). A DIRECT módú I/O kontroll kérések esetén azonban a bemeneti puffer kezelése mindig BUFFERED módon történik.
•
NEITHER módban az operációs rendszer átadja a felhasználói módú (!) adatpufferek virtuális címét. Ezért használata nagy óvatosságot igényel!
41
9.2 Az általános célú USB meghajtó A tradicionális PC buszokhoz (pl. PCI) illeszkedő eszközök meghajtóival ellentétben az USB perifériák meghajtói nem közvetlenül a hozzájuk tartozó hardverrel kommunikálnak, hanem létrehoznak egy példányt az URB-nak (USB Request Block) nevezett adatstruktúrából és ezt továbbítják az alattuk lévő meghajtóprogramnak. A tervezési szempontoknak megfelelően az eszközmeghajtó program minden USB perifériával képes együttműködni, mert csak az alacsonyabb szinten lévő meghajtók egyes szolgáltatásainak elérését teszi lehetővé az alkalmazói program számára, és nem valósít meg semmilyen eszközspecifikus funkciót.
Az általános célú USB meghajtó által nyújtott főbb szolgáltatások a következők: •
A meghajtóprogram verziójának lekérdezése.
•
Az USB eszköz leíró lekérdezése.
•
Az USB konfiguráció leíró lekérdezése.
•
Az elsődleges interfész alternate setting-jének beállítása és lekérdezése. (Azért csak az elsődleges interfésszel kell foglalkozni, mert kompozit eszközök esetén a Windows minden egyes interfészhez külön-külön meghajtóprogramot tölt be, így azok csak a hozzájuk tartozó egyetlen interfészt látják.)
•
Kontroll, bulk és interrupt transzferek indítása.
•
Az eszköz eltávolításának és újracsatlakoztatásának szimulálása.
•
Azon USB port alaphelyzetbe állítása, amelyre a periféria csatlakozik.
•
A megadott USB végpont alaphelyzetbe állítása.
•
A megadott végponton a folyamatban lévő transzferek leállítása.
A fenti felsorolás alapján látható, hogy a meghajtó (jelenleg) nem támogatja az isochronous transzfereket. Egyrészt ezek kezelése jóval bonyolultabb a többinél, másrészt pedig high-speed módú adatátvitel esetén közel azonos sebesség érhető el bulk transzferekkel is, ráadásul ez esetben kizárt az adatvesztés.
A meghajtó által nyújtott szolgáltatások az I/O kontroll kéréseken keresztül érhetők el. Az adott művelet elvégzéséhez szükséges paramétereket (pl. a végpont címe, a SETUP adatok kontroll transzferek esetén, stb.) tartalmazó struktúrát mindig a bemeneti pufferben kell átadni. A transzferek indításával nem kapcsolatos szolgáltatások esetén a meghajtó BUFFERED módon kapja meg a felhasználói adatokat. Itt ezt a legcélszerűbb alkalmazni, mert ezen szolgáltatások számára szükséges adatok csak néhány bájtosak. A transzferek indításával kapcsolatos szolgáltatások esetén a NEITHER módot használjuk, mert az esetenként nagyméretű adatok másolása jelentős teljesítményveszteséget
42
okozna. Ez esetben kihasználható, hogy NEITHER mód esetén a meghajtó két különböző puffert tud írni és olvasni. A bemeneti puffer szerepét már említettem, a kimeneti puffert pedig adatpufferként használjuk. Sajnos ennek az adatelérési módnak a kezelése a legnehezebb. A kérések feldolgozásának kezdete előtt le kell rögzíteni a felhasználói módú puffereket a memóriában, nehogy véletlenül kiíródjanak a lapozófájlba. A művelet végrehajtása után pedig meg kell szűntetni a lerögzítést.
Az általános célú USB meghajtó forráskódja megtalálható a CD mellékleten a \drivers\logsys_usb könyvtárban.
9.3 A virtuális soros port meghajtó Ahhoz, hogy a Windows XP képes legyen az aszinkron soros kommunikációhoz használni a meghajtóprogramot, annak az operációs rendszer felé biztosítania kell egy programozási interfészt, melynek részletes ismertetése [17]-ben megtalálható. Az USB-n keresztül való kommunikáció pedig a már említett módon történik az alacsonyabb szintű meghajtók szolgáltatásainak igénybevételével.
A soros port kezelését döntően befolyásolja az alkalmazott mikrovezérlő és a benne található UART periféria belső felépítése. Annak érdekében, hogy az eszközfüggetlenség biztosítva legyen, a perifériának implementálni kell egy USB interfészt és kezelnie kell bizonyos gyártóspecifikus kéréseket. Ezek specifikációjáról a 8. fejezetben már volt szó. A gyártóspecifikus kérések közül az egyik az UART paramétereinek lekérdezésére szolgál: •
Az UART baud-rate generátorának órajelfrekvenciája és előosztása.
•
A beállítható maximális és minimális adatátviteli sebesség.
•
A beállítható vonali kódolások (szóhossz, start és stop bitek száma, paritás).
•
Az alapértelmezett beállítás.
A fenti adatok ismeretében az UART az adott eszköz képességeinek megfelelően kezelhető és a meghajtó a felhasználói program számára jelezni tudja az érvénytelen beállítási kísérleteket. Az átvitelvezérlés nincs támogatva, mert ez a mikrokontrollerek legtöbbjében nincs hardveresen implementálva, a szoftveres megvalósítás pedig csökkenti a rendszer teljesítményét.
A felhasználói adatok elérése BUFFERED módban történik, ez logikus választás az alacsony adatátviteli sebesség miatt (szabványos soros port esetén maximum 115200 bit/s). Az USB sajnos kis adatméret (néhány bájt) esetén nem nyújt megfelelő adatátviteli teljesítményt, viszont bizonyos programok (pl. a HyperTerminal) karakterenként küldik ki a soros portra az adatokat. Ezért a meghajtónak ezt a helyzetet kezelnie kell.
43
Az írási kéréseket egy külön szál hajtja végre. Ez puffereli a beérkező adatokat, az USB transzfert pedig csak akkor indítja el, ha a pufferben van már megfelelő mennyiségű adat, vagy ha lejárt egy időzítő. Így a fent említett szituáció esetén is biztosítani lehet a megfelelő adatátviteli sebességet.
Az olvasási műveleteket két külön szál kezeli. Az aszinkron jelleg miatt vétel esetén az adatok bármikor megjöhetnek, ezért az egyik olvasási szál az USB perifériától kapott adatokat beírja egy körforgásos pufferbe. Ugyanez a szál dolgozza fel a vételi státusz információt és a bekövetkezett eseményeket (pl. puffer túlcsordulás, kerethiba, paritáshiba, adat jött, stb.) jelzi a felhasználói programnak, amennyiben az kért az egyes eseményekről értesítést. A másik olvasási szálnak a feladata a felhasználói oldal felől érkező olvasási kérések kezelése. Ez a szál a körforgásos vételi pufferből karakterenként kiolvassa az adatokat és azokat átadja a felhasználói programnak. A karakterenkénti olvasás azért szükséges, mert az írási és az olvasási kérések teljes időtartamára előírt korlát mellet megadható a két karakter érkezése kötött eltelt időre is egy maximális érték. Az egyes időkorlátok túllépése esetén a megfelelő adatátviteli kérés feldolgozását meg kell szakítani.
A virtuális soros port meghajtó forráskódja megtalálható a CD mellékleten a \drivers\logsys_serial könyvtárban.
44
10 A kábel integrálása a LOGSYS környezetbe Ebben a fejezetben ismertetem azokat az általam készített .NET osztálykönyvtárakat, melyeket beépítve a LOGSYS rendszerhez tartozó alkalmazói programba az alkalmassá válik az új fejlesztői kábel kezelésére. Az alkalmazói program ismertetése a [2] irodalomban található meg.
10.1 A PnPMessage osztálykönyvtár A PnPMessage osztálykönyvtár végzi el az operációs rendszer felől érkező „plug & play” üzenetek feldolgozását és a bekövetkezett eseményeket jelzi az alkalmazásnak. Az osztálydiagram a 10-1. ábrán látható. A „plug & play” üzenetek vételének szükséges feltétele, hogy az eszközmeghajtó program az általa kezelt hardvert hozzárendelje egy eszköz interfészhez. Minden egyes eszköz interfészt egy 128 bites egyedi kód (GUID, Globally Unique IDentifier) azonosít, ennek ismeretében az alkalmazói program regisztrálni tudja magát az adott eszközhöz tartozó üzenetek vételéhez. Az előző fejezetben ismertetett meghajtóprogramok teljesítik a szükséges követelményeket, az általános célú USB meghajtó esetén a GUID a telepítési információkat tároló INF fájlban adható meg, a virtuális soros port meghajtó esetén pedig az azonosító egy fix érték (az ntddser.h fájlban van definiálva, amely a Windows Driver Kit része).
10-1. ábra: A PnPMessage osztálykönyvtár osztálydiagramja.
A „plug & play” üzenetek vétele csak grafikus alkalmazások esetén lehetséges, konzolos alkalmazások esetén nem. Az operációs rendszer minden üzenet elküldésénél meghívja az alkalmazás ablakához tartozó üzenet-feldolgozó függvényt (az osztálydiagramon ez a WndProc() metódus).
45
A PnPMessageHandler osztály tartalmazza azokat a metódusokat, melyek segítségével az alkalmazások be tudják állítani, hogy melyik eszköz interfész üzeneteire tartanak igényt, illetve ez az osztály jelzi az alkalmazások felé a bekövetkezett eseményeket is. A PnPMessageHandler osztály konstruktora létrehoz egy nem látható ablakot (MessageForm). Ennek az ablaknak az üzenetfeldolgozó metódusa a „plug & play” üzenetek vétele esetén meghívja a pnpMsgHandler objektum RaisePnPEvent() metódusát, amely előidézi a PnPEvent eseményt. Az alkalmazás egy PnPEventArgs típusú objektumban kapja meg az eseményhez tartozó adatokat. A RegisterInterface() metódussal lehetséges regisztrálni a megadott azonosítóval rendelkező eszköz interfész eseményeinek vételére. A RegisterDevice() metódus meghívásával lehet a már megnyitott hardvereszköz eltávolítását jelző esemény vételét kérni. Az Unregister() metódus meghívásával az alkalmazás megszüntetheti a már nem kívánt események vételét.
A SymbolicLink statikus osztálynak két metódusa van. A GetSymbolicLinks() metódussal a számítógéphez csatlakoztatott és a megadott azonosítóval rendelkező interfészhez tartozó eszközök neve kérdezhető le. Az eszköznév ismerete az adott hardveregység megnyitásához szükséges. A GetDeviceRegistryValue() metódussal lekérdezhető a megadott nevű eszközhöz tartozó rendszerleíró adatbázis (registry) bejegyzések értéke.
A PnPMessage osztálykönyvtár forráskódja a \programok\Utils\PnPMessage könyvtárban található meg a CD mellékleten.
10.2 A LogsysUSB osztálykönyvtár A LogsysUSB osztálykönyvtár biztosítja az általános célú USB meghajtót használó USB perifériákkal a kommunikációt. A LogsysUSB osztálykönyvtár osztálydiagramja a melléklet 17.5.1 pontjában található meg.
A számítógéphez csatlakoztatott eszközök nyilvántartása a LogsysUSBDeviceList osztály feladata. Ha az osztály megpéldányosításánál a konstruktornak megadtuk a „plug & play” üzeneteket kezelő objektumot, akkor az eszközök adatait tároló lista automatikusan frissülni fog az USB perifériák csatlakoztatása vagy eltávolítása esetén. Új eszköz interfész GUID az AddGuid() metódussal adható meg. Az eszközlista manuális frissítése is lehetséges a Refresh() metódus meghívásával. Ha az eszközlistában változás következett be, akkor azt a DeviceListChanged esemény jelzi az alkalmazás felé. A csatlakoztatott eszközök számát a Count property adja meg. Egy adott eszköz adatait tároló objektum az osztály indexerével kérdezhető le a sorszám, az INF fájlban megadott név vagy a VID és a PID alapján.
46
Az USB eszközök adatait a LogsysUSBDeviceListItem osztály tárolja. Az osztályban található property-k segítségével kérdezhetők le az eszköz adatai. Az elsődleges interfész adatait tároló objektum az osztály indexerével kérdezhető le az alternate setting száma alapján.
Az interfészek adatait a LogsysUSBInterfaceListItem osztály tárolja. A Description property megadja az interfészhez tartozó USB string leíró tartalmát. A Descriptor property megadja az USB interfész leíró objektumot. Az interfészhez tartozó végpontok adatait tároló objektumok az osztály indexerével kérdezhetők le a sorszám vagy pedig a végpont címe és iránya alapján.
A végpontok adatait a LogsysUSBEndpointListItem osztály tárolja. A Direction property megadja a végpont irányát (OUT vagy IN), a Type property megadja a végpont típusát (kontroll, bulk, interrupt vagy isochronous), a Descriptor property pedig megadja USB végpont leíró objektumot.
Az alapvető USB leírókat az USBDeviceDescriptor, az USBConfigurationDescriptor, az USBInterfaceDescriptor és az USBEndpointDescriptor osztályok reprezentálják.
A LogsysUSBDevice osztály reprezentálja az USB eszközt. Az osztály megpéldányosításakor a konstruktornak meg kell adni a használni kívánt eszköz adatait tároló LogsysUSBDeviceListItem típusú objektumot. Ha a konstruktornak megadjuk a „plug & play” üzeneteket kezelő objektumot is, akkor a DeviceRemoved esemény jelezni fogja az alkalmazásnak az USB eszköz eltávolítását. A property-k nagy része az eszközhöz tartozó LogsysUSBDeviceListItem és LogsysUSBInterfaceListItem típusú objektumokban tárolt adatok elérését biztosítja. Az AlternateSetting property az elsődleges interfész alternate setting-jének beállítására és lekérdezésére szolgál. A ControlEndpoint property megadja az eszközhöz tartozó USB kontroll végpont objektumot. A bulk, interrupt és isochronous végpont objektumok az osztály indexerével kérdezhetők le a sorszám, illetve a végpont címe és iránya alapján. A CyclePort() metódus meghívásával szimulálható az USB eszköz eltávolítása és újracsatlakoztatása. A ResetParentPort() metódus azt az USB portot állítja alaphelyzetbe, amelyre az eszköz csatlakozik. Az eszköz az Close() vagy a Dispose() metódusok meghívásával zárható le.
Az USB periféria végpontjaival a kommunikációt a végpont osztályok biztosítják. A négyféle USB végpont mindegyikét külön-külön osztály reprezentálja, melyek a LogsysUSBEnpoint absztrakt osztályból vannak származtatva. Szinkron adatátvitel a TransferData() metódussal indítható. Aszinkron adatátvitel indítása a BeginTransfer() metódus meghívásával lehetséges. A FinishTransfer() metódust minden aszinkron adatátvitel befejeződése után meg kell hívni. A Reset() metódussal lehet az adott végpontot alaphelyzetbe állítani. Az Abort() metódus a folyamatban lévő USB transzferek leállítására szolgál.
47
Az USB transzferek kezeléséhez szükséges adatokat a LogsysUSBTransfer osztály tárolja. Ilyen típusú objektum a végpont osztályok TransferData(), BeginTransfer() és FinishTrnasfer() metódusainak az egyik paramétere. Az adatátvitel indítása előtt meg kell adni a végpont címét (EndpointAddress property), valamint kontroll transzferek esetén még ki kell tölteni a setup packet-et (SetupPacket property). Aszinkron adatátvitel esetén a CompletionEvent property által visszaadott eseményre kell várakozni, ez az esemény jelzi az adatátvitel befejeződését.
A LogsysUSB osztálykönyvtár forráskódja a CD mellékleten a \programok\LogsysUSB könyvtárban található meg.
10.3 A JTAG osztálykönyvtár A JTAG osztálykönyvtárban találhatók meg azok a JTAG funkcióval kapcsolatos osztályok, amelyek nem tartalmaznak a fejlesztői kábeltől függő kódot. A JTAG osztálykönyvtár osztálydiagramja a melléklet 17.5.2 pontjában található meg.
Az IJTAG interfészen keresztül érhető el a fejlesztői kábel JTAG funkciója. Az interfész által definiált metódusok megvalósítása függ a fejlesztői kábeltől, többségük az adatátvitellel kapcsolatos. Az IJTAG interfészt egy külső osztályban kell implementálni.
A JTAG eszköz adatbázis biztosítja az eszközök egységes, gyártófüggetlen kezelését. Az itt tárolt adatok (eszköz neve, utasításregiszter hossza, ID kód) lehetővé teszik a JTAG láncban található eszközök azonosítását, valamint az utasítás- és adatregiszter műveletekhez szükséges header és trailer adatok előállítását (a header és trailer adatok pontos jelentése [4]-ben megtalálható).
10-2. ábra: A JTAG eszköz adatbázis. A JTAG eszköz adatbázist a JTAGDeviceDatabase osztály reprezentálja. Az osztály indexerével lehetséges az eszközök adatainak lekérdezése a 32 bites eszköz azonosító kód alapján. Az adatbázis
48
tartalma a JTAGDeviceDatabaseForm típusú ablakban jeleníthető meg (10-2. ábra bal oldala). Ugyanebben az ablakban lehetséges az új eszközök hozzáadása, a meglévő eszközök törlése, valamint az eszközök nevének módosítása is. Az eszközök adatait a JTAGDeviceData osztály tárolja. Az Edit() metódus megjelenít egy JTAGDeviceDataForm típusú ablakot (10-2. ábra jobb oldala), amelyben megadható az eszköz utasításregiszterének hossza és ID kódja. Lehetőség van ezen adatok BSDL fájlból történő importálására is.
A TAPController statikus osztály tartalmazza a TAP vezérlő állapotátmeneti mátrixát és az alapértelmezett állapotátmeneti útvonalakat. A GetDefaultStatePath() metódus a megadott kezdeti- és végállapot közötti alapértelmezett útvonalat tároló tömbbel tér vissza. Amennyiben a két állapot között nincs alapértelmezett állapotátmeneti útvonal, akkor kivétel keletkezik. A GetNextStateByTMSBit() metódus a jelenlegi állapot és a TMS vonal értéke alapján megadja a TAP kontroller következő állapotát. A GetStateMatrixElement() metódussal az állapotátmeneti mátrix egy eleme kérdezhető le, paraméterként két TAP vezérlő állapotot kell megadni. Amennyiben a megadott két állapot szomszédos az állapotgráfban (3-3. ábra), akkor a metódus visszatérési értéke a TMS vonalra kiírandó bit (0x00 vagy 0x01). Ha a két állapot nem szomszédos, akkor a visszatérési érték 0xFF.
Az SVFFile osztály végzi el az SVF fájlok feldolgozását. A Load() metódussal tölthető be a kívánt SVF fájl, majd a Process() metódus meghívásával végrehajthatók az SVF fájl által leírt műveletek. A Process() metódusnak paraméterként meg kell adni egy olyan objektumot, amely implementálja az IJTAG interfészt. Ha a műveletek végrehajtása közben hiba történik, akkor kivétel keletkezik. A ProgressChanged esemény jelzi, ha a feldolgozottsági szintben változás történik.
A JTAG osztálykönyvtár forráskódja a \programok\JTAG könyvtárban, az általam készített fejlesztői kábelhez
az
IJTAG
interfészt
megvalósító
osztály
forráskódja
\programok\AVRDevelopmentCable könyvtárban található meg a CD mellékleten.
49
pedig
a
11 A kábel integrálása a Xilinx fejlesztőrendszerébe Ebben a fejezetben ismertetem az általam készített fejlesztői kábelnek a Xilinx ISE és EDK programokból történő használatának lehetőségeit. A Xilinx fejlesztőrendszere a programozható logikai eszközökkel alapvetően a JTAG interfészen keresztül teremt kapcsolatot, a célrendszert a gyári letöltőkábelek illesztik a számítógéphez: •
Parallel III
•
Parallel IV
•
MultiPRO
•
Platform Cable USB
A fejlesztőrendszer a fenti letöltőkábelekkel közvetlenül, saját eszközmeghajtón keresztül kommunikál. A kommunikáció folyamata nem dokumentált, emiatt a Xilinx fejlesztőrendszerébe direkt módon nem lehet beintegrálni az általam készített fejlesztői kábelt. Más megoldást kell tehát keresni.
11.1 A fejlesztői kábel integrálása az ISE programba Az ISE fejlesztői környezetben a programozható eszközök konfigurálását, illetve a BIT és JEDEC konfigurációs fájlok más formátumra konvertálását (SVF, XSVF, MCS, stb.) az iMPACT program végzi el. A 11-1. ábra mutatja a lehetséges letöltőkábel kezelési beállításokat, a dialógusablakban az alábbi paraméterek adhatók meg: •
a letöltőkábel típusa
•
az adatátviteli sebesség és a port, amelyre a kábel csatlakozik
•
a kábel helyi, vagy távoli számítógéphez van csatlakoztatva
11-1. ábra: Lehetséges letöltőkábel beállítások az iMPACT programban.
50
Ha a letöltőkábel a helyi számítógépre van csatlakoztatva, akkor azt a fejlesztőrendszer közvetlenül kezeli, ily módon a saját fejlesztői kábel beintegrálása nem megoldható. Azonban az iMPACT lehetőséget biztosít távoli számítógéphez csatlakoztatott letöltőkábelek elérésére is. Ez esetben a távoli gépen futnia kell egy kábelszerver alkalmazásnak, amellyel az iMPACT TCP/IP protokollon keresztül kommunikál. Természetesen a kábelszerver program futtatható azon a gépen is, amelyen az iMPACT is fut, ilyenkor a beállításoknál a 127.0.0.1 IP-címet (vagy a localhost nevet) kell megadni.
Az általam készített fejlesztői kábelnek az ISE-ből történő használatára egyetlen módon van lehetőség, mégpedig a kábelszerver alkalmazáson keresztül. Sajnos a kábelszerver kommunikációs protokollja sem dokumentált, ezért a TCP/IP csomagokban található adatok alapján lehetséges annak visszafejtése. A helyi hálózaton közlekedő TCP/IP csomagok elfogása az úgynevezett „sniffer” programokkal lehetséges. Ezt a feladatot végül nem kellet elvégeznem, mert az interneten találtam egy olyan nyílt forráskódú kábelszerver alkalmazást ([19]), amely képes a Parallel III letöltőkábel emulálására. A forráskódot átnézve könnyen megállapítható volt, hogy az iMPACT és a kábelszerver közötti adatcsere milyen módon történik.
A TCP kapcsolat felépülése után az iMPACT elküldi a kábelszerver programnak az üzenet azonosítóját és a művelet végrehajtásához szükséges egyéb adatokat. Ezek vételét a kábelszerver nyugtázza, majd végrehajtja a kért műveletet. Ezután, ha van az iMPACT felé továbbítandó adat, akkor azt a kábelszerver elküldi, végül pedig bontja a TCP kapcsolatot. A Parallel III letöltőkábel emulálása esetén az alábbi öt üzenetet vétele lehetséges.
MSG_COMMANDS (0x01) Az üzenet hatására a kábelszerver parancs végrehajtási módba kerül. MSG_SET_CABLE_MODE (0x03) A letöltőkábel paramétereinek beállítása. Az iMPACT a 11-1. ábrán látható dialógusablakban megadott paramétereket adja át a kábelszervernek. MSG_CLOSE_CABLE (0x04) A letöltőkábel lezárása. Az iMPACT ezzel az üzenettel jelzi, ha már nem használja a letöltőkábelt. MSG_GET_INFO (0x05) Az MSG_SET_CABLE_MODE üzenettel megadott adatok lekérdezésére szolgál. MSG_CHECK_SERVER (0x70) Az iMPACT és a kábelszerver közötti kapcsolat meglétének ellenőrzésére szolgál. Az MSG_COMMANDS üzenet vétele után a kábelszerver a következő műveleteket hajtja végre mindaddig, amíg CMD_DONE parancsot nem kap. A TCP kapcsolat csak a CMD_DONE parancs vétele után kerül lebontásra.
51
CMD_DONE (0x02) Kilépés a parancs végrehajtási módból. CMD_SET_CABLE_OPTION (0x06) A letöltőkábel paramétereinek beállítása. CMD_GET_CABLE_OPTION (0x07) A letöltőkábel paramétereinek lekérdezése. CMD_IS_CONNECTED (0x11) Az iMPACT és a kábelszerver közötti kapcsolat meglétének ellenőrzése. CMD_READ (0x20) A parancs hatására az utolsó utasítás- vagy adatregiszter művelet során beolvasott adatokat el kell küldeni az iMPACT-nak. CMD_WRITE (0x21) Az utasítás- és adatregiszter műveletek végrehajtása, vagy az előbbi műveletek esetén az elküldendő adatok előtt (header) és az elküldendő adatok után (trailer) kiírandó bitek beállítása. CMD_SET_PIN (0x25) A TCK vagy a TMS vonal értékének beállítása. CMD_PULSE_PIN (0x26) A megadott számú pulzust kell kiadni a TCK vonalra. CMD_START_OPERATION (0x30) Parallel III kábel emulálása esetén a CMD_START_OPERATION parancs hatására semmilyen műveletet sem kell végrehajtani. CMD_NAVIGATE_TAP (0x31) A TAP kontroller állapotának beállítása. A megadott állapotátmeneti útvonalon kell végighaladni. CMD_WAIT_TIME (0x35) Várakozás a megadott ideig. CMD_WAIT_TCK (0x37) A megadott számú pulzust kell kiadni a TCK vonalra. A fenti műveletek nagy részének elvégzéséhez a JTAG osztálykönyvtárban található IJTAG interfész tartalmazza a szükséges metódusokat. A CMD_SET_PIN parancs közvetlen módon nem támogatott, de ezt a parancsot az iMPACT csak a TAP kontroller alapállapotba állítása esetén (TMS=1 és 5 pulzus kiadása a TCK vonalra) küldi el a kábelszervernek. Erre pedig az IJTAG interfész lehetőséget biztosít.
A 11-2. ábrán látható az iMPACT és a fejlesztői kábelhez készült kábelszerver alkalmazás. Az iMPACT képes volt a kábelszerver alkalmazáson keresztül a fejlesztői kábel JTAG interfészét használni és sikeresen azonosította, majd pedig felkonfigurálta az FPGA kártyán lévő XC3S250E típusú eszközt.
52
A kábelszerver alkalmazás forráskódja a \programok\Teszt programok\XilinxCableServer könyvtárban található meg a CD mellékleten.
11-2. ábra: A Xilinx iMPACT és a kábelszerver alkalmazás.
11.2 A fejlesztői kábel integrálása az EDK programba Az EDK (Embedded Development Kit) a beágyazott mikroprocesszoros rendszerek (MicroBlaze és PowerPC) fejlesztői környezete, amely tartalmazza a fejlesztéshez szükséges IP modulokat, a C/C++ fordítóprogramot és a debuggert. Az EDK fejlesztői környezetben a mikroprocesszoros rendszerrel a kapcsolatot az XMD (Xilinx Microprocessor Debug) program biztosítja (11-3. ábra).
11-3. ábra: Az XMD és a processzoros rendszer közötti kommunikációs lehetőségek.
53
Az XMD háromféle módon képes kapcsolódni a célrendszerhez: •
A JTAG interfészen keresztül az MDM (Microprocessor Debug Module) perifériát használva. Ez az alapértelmezett kapcsolat az XMD és a célrendszer között. MicroBlaze és PowerPC processzoros rendszerek fejlesztésére is használható.
•
Soros porton keresztül. Az XMDStub szoftver szükséges hozzá, valamint a célrendszernek tartalmaznia kell egy UART perifériát. Csak MicroBlaze processzort tartalmazó rendszerek fejlesztéséhez használható.
•
JTAG interfészen keresztül a JTAG UART modult használva. Hasonló az előzőhöz, de a soros adatvonalak értéke a JTAG interfészen keresztül kerül átvitelre. Csak MicroBlaze processzort tartalmazó rendszerek fejlesztéséhez használható.
Az XMD-be nincs beépítve a kábelszerver alkalmazás támogatása, ezért a JTAG interfészt igénylő módok a fejlesztői kábelen keresztül nem használhatók. A MicroBlaze processzort használó rendszerek esetén az XMDStub debug opcióval lehetőség van a soros porton keresztüli kommunikációra is. A fejlesztői kábel soros portját az általam készített virtuális soros port meghajtó elérhetővé teszi az XMD számára.
A 11-4. ábrán látható az XMD és a GNU debugger. Az XMD a fejlesztői kábel soros portján keresztül sikeresen kapcsolódott a MicroBlaze processzort tartalmazó rendszerhez. A GNU debuggerrel letöltöttem egy egyszerű programot és kipróbáltam a nyomkövetési funkciókat. A tesztek során minden az elvárásoknak megfelelően működött.
11-4. ábra: Az XMD és a GNU debugger.
54
12 A rendszer tesztelése A fejlesztés minden fázisában lényeges az addig elkészült komponensek alapos tesztelése, mert egy később felbukkanó hiba kijavítása már jóval nehezebb feladat. A munkám során elkészített hardver és szoftver egységek eltérő tesztelési módszereket igényelnek, a viszonylag egyszerű felépítésű hardver miatt a szoftverek tesztelésén van a nagyobb hangsúly.
12.1 A hardver tesztelése 12.1.1 A fejlesztői kábel tesztelése A fejlesztői kábelekből az eddig elkészült néhány darabot kézzel szereltem össze, ezért lényeges volt a forrasztások ellenőrzése. A kisméretű SMD alkatrészek felhasználása miatt ilyen jellegű hiba könnyen előfordulhat és a keletkezett rövidzárlat tönkreteheti a hardvert. A fejlesztői kábel tesztelésének következő lépése az USB kommunikáció ellenőrzése volt. Az AT90USBxxx típusú mikrovezérlőket a gyártó betöltőprogrammal (bootloader) felprogramozva szállítja, amely lehetőséget biztosít az USB-n keresztüli firmware frissítésre. Ezért az USB kommunikáció teszteléséhez elegendő volt csatlakoztatni a fejlesztői kábelt a számítógéphez. A PC gond nélkül felismerte az újonnan csatlakoztatott USB perifériát. Ezután a szintillesztők és a tápfeszültség kapcsoló áramkör működésének ellenőrzése következett. Ehhez az Atmel JTAG ICE mk-II in-circuit emulátort használtam, amelynek segítségével az AVR Studio 4 programból hozzá lehet férni a mikrokontroller regisztereihez és egyéb hardveres erőforrásaihoz. Így a megfelelő I/O lábak vezérlésével és oszcilloszkóp segítségével ellenőrizni tudtam a megfelelő működést. Legutoljára a tápfeszültség kimenet áramkorlátozását ellenőriztem a 12-1. ábrán látható elrendezés szerint.
12-1. ábra: A kimeneti áramkorlátozás tesztelése. A nagyteljesítményű potenciométerrel beállítható az áramfelvétel, melynek pontos értéke az ampermérővel figyelhető meg. A voltmérővel figyeltem, hogy mikor lép működésbe a tápfeszültség kapcsoló IC túláramvédelme. Mindhárom beállítható áramkorlátozási érték (450mA, 700mA és 950mA) esetén az eltérés 15-20 milliamperen belül volt.
55
Miután a firmware elkészült, az előző tesztet USB portról történő táplálás esetén is el tudtam végezni. A fejlesztői kábelt asztali PC-kkel és laptopokkal is kipróbáltam. A legtöbb esetben Y-kábel használatával az USB port biztosítani tudta a 950 milliampert. Egyetlen laptop esetén tapasztaltam, hogy az USB port áramkorlátozása kb. 800 milliamperes áramfelvételnél már működésbe lépett.
A hardveres tesztek során semmiféle hibajelenséget nem tapasztaltam, a fejlesztői kábel az elvárásoknak megfelelően viselkedett.
12.1.2 Az FPGA kártya tesztelése Az FPGA kártya összeszerelésénél először a tápegység alkatrészeit ültettem be. Ezután 5V-os feszültséget kapcsoltam a rendszerre és ellenőriztem, hogy a 3,3V-os, a 2,5V-os és az 1,2V-os tápfeszültség vonalakon megfelelőek-e a feszültségértékek. Itt hibát nem tapasztaltam, a tápegység megfelelően működött. Az FPGA kártya teljes összeszerelése után ellenőriztem a forrasztásokat a rövidzárlatok elkerülése végett. Tápfeszültséget adva a rendszernek megmértem az üresjárati áramfelvételt (azaz az FPGA nem volt felkonfigurálva), ennek értéke 45mA volt. A kártyán található perifériák működésének ellenőrzéséhez készítettem az EDK-ban egy egyszerű mikroprocesszoros rendszert.
Az elkészült három darab FPGA kártya közül egyetlen egy esetben tapasztaltam egy kisebb problémát. Ennek oka a nyomtatott áramkör gyártási hibája volt: az SPI FLASH memória CLK (órajel) és DI (soros adat bemenet) vonalai közötti zárlat miatt nem lehetett azt felprogramozni. A zárlat megszüntetése után az áramkör rendesen működött, meghibásodás nem történt.
12.2 A szoftverek tesztelése 12.2.1 A firmware tesztelése A mikrovezérlő programjának tesztelését szintén az in-circuit emulátor segítségével végeztem. Az USB perifériát kezelő rutinok teszteléséhez ez a módszer viszont nem alkalmazható, mert ha a PC nem kap időben választ az elküldött kérésre, akkor az USB perifériát hibásnak tekinti. Ezért az egyes USB kérések végrehajtásakor az UART-on keresztül küldtem a PC-nek üzeneteket, melyeket egy terminálprogrammal megjelenítve következtetni lehetett a program helyes vagy helytelen viselkedésére. Mivel a korábbi munkáim során sok tapasztalatot szereztem az USB-vel kapcsolatban, ezért az USB kommunikációt kezelő rutinokban komoly hibák nem voltak. A fejlesztői kábel funkcióinak (JTAG, SPI, I2C, szoftveres soros I/O) teszteléséhez egyszerű PC-s alkalmazásokat készítettem, így az egyes funkciók működése gyorsan ellenőrizhető volt a LOGSYS rendszer alkalmazói programja nélkül is.
56
12.2.2 Az eszközmeghajtó programok tesztelése Az eszközmeghajtó programok tesztelése kiemelt fontosságú, mert egy rosszul működő meghajtó az egész rendszer stabilitását veszélyezteti. A meghajtók kernel módban futnak, ezért működésük vizsgálata kernel debuggert igényel. A kernel debugger használatához a 12-2. ábrán látható konfiguráció szükséges. Az egyik számítógépen a Windows XP-t debug módban kell elindítani, ez a gép futtatja a tesztelendő eszközmeghajtót. A másik számítógépen fut a WinDebug program (kernel debugger). A Windows XP tartalmaz egy másik hasznos eszközt is, az illesztőprogram-ellenőrzőt. Ez képes a tesztelésre kiválasztott meghajtóprogramok részére különféle hibákat szimulálni, és ellenőrzi a megfelelő hibakezelést. Az eszközmeghajtók elkészítéséhez és teszteléséhez sok hasznos tanács található a [16], a [17] és a [18] irodalmakban.
12-2. ábra: A kernel debugger használatához szükséges konfiguráció. Az eszközmeghajtó programok a KdPrint() makróval (használata hasonló a printf() függvényhez) szöveges üzenetet tudnak küldeni a kernel debuggernek. Ez egy igen hasznos hibakeresési lehetőség, mert az üzenetek alapján nyomon követhető az egyes műveletek végrehajtása és meghajtó állapota.
A meghajtóprogramok legelső változatai sok olyan hibát tartalmaztak, melyek a rendszer lefagyását okozták („kék halál”). A jelenlegi eszközmeghajtókban az összes ismert hiba ki lett javítva, ezek működése stabilnak és hibamentesnek bizonyult.
12.2.3 A .NET alkalmazások tesztelése Az osztálykönyvtárakat és a tesztalkalmazásokat C# nyelven, .NET platformra a Microsoft Visual Studio 2005 fejlesztőrendszer használatával készítettem el. A .NET kód felügyelt (managed) jellege miatt számos olyan hibára a keletkezésük pillanatában azonnal fény derül, amely normál C++ programok esetén csak nagyon nehezen vehető észre (pl. nem megfelelő típuskonverzió, a lefoglalt memória fel nem szabadítása, stb.). A Visual Studio 2005 nagyon jól használhatónak bizonyult, a beépített debugger sok fejlett szolgáltatást tartalmaz. A fejlesztés végeztével a kész programokon ellenőriztem a funkcionális és viselkedési követelmények teljesülését.
57
12.3 A tesztprogramok A fejlesztői kábel funkcióinak (JTAG, SPI, I2C, szoftveres soros I/O) teszteléséhez négy egyszerű PCs alkalmazást készítettem, így az egyes funkciók működése gyorsan ellenőrizhető volt a LOGSYS rendszer alkalmazói programja nélkül is. A programok forráskódja megtalálható a CD mellékleten a \programok\Teszt programok könyvtárban.
A JTAG tesztalkalmazás a 12-3. ábrán látható, lehetőséget biztosít a JTAG láncban található eszközök azonosítására és a kiválasztott eszköz SVF fájl alapján történő konfigurálására, valamint megjeleníti a mérési eredményeket. A program segítségével ellenőrizni tudtam a fejlesztői kábel JTAG és mérési funkcióit, illetve a JTAG .NET osztálykönyvtárat.
12-3. ábra: A JTAG tesztalkalmazás. Az I2C tesztalkalmazás a 12-4. ábrán látható. Az I2C funkció kipróbálásához a PCF8574 típusú áramkört használtam, amely egy I2C buszról vezérelhető 8 bites I/O port. Az áramkör I/O lábaira csatlakoztatott 8 darab LED-et a programból lehet egyenként be- és kikapcsolni.
12-4. ábra: Az I2C tesztalkalmazás.
58
A fejlesztői kábel szoftveres soros I/O funkciójának kipróbálására készített program a 12-5. ábrán látható. Az alkalmazás legfeljebb 16 bites adatot tud kiírni a soros kimenetre, megjeleníti a soros bemenetre érkező biteket, illetve biztosítja az adatátvitellel kapcsolatos beállítási lehetőségeket.
12-5. ábra: A szoftveres soros I/O tesztalkalmazás. Az SPI funkció teszteléséhez egy olyan alkalmazást készítettem, amely a Xilinx iMPACT program által generált MCS fájl alapján elvégzi az FPGA kártyán található SPI FLASH memória felprogramozását (12-6. ábra). A program először egy olyan konfigurációt tölt le az FPGA-ba, amely összeköttetést teremt a LOGSYS port soros I/O vonalai és a FLASH memória között. Ezután a fejlesztői kábel SPI funkciójával már elvégezhetők a szükséges műveletek (törlés, az adatok beírása a memóriába, ellenőrzés).
12-6. ábra: Alkalmazás az SPI FLASH felprogramozásához.
59
12.4 A mikroprocesszoros rendszer Az FPGA kártyán lévő perifériák teszteléséhez egy egyszerű mikroprocesszoros rendszert készítettem az EDK segítségével, ennek blokkvázlata a 12-7. ábrán látható. Az ábrán feltüntettem az egyes perifériák báziscímeit is. A teljes EDK projekt megtalálható a CD mellékleten az \edk könyvtárban.
12-7. ábra: A MicroBlaze processzoros rendszer blokkvázlata.
A rendszer a MicroBlaze processzor köré épül, amely egy 32 bites RISC szoft processzor. A perifériákkal az OPB buszon kommunikál, az FPGA-ban található belső blokk-RAM-mal a nagyobb adatátviteli sebességet biztosító LMB buszon létesít kapcsolatot. Az UART-ra (opb_uartlite) az XMDStub debug opció használata miatt van szükség. A külső memóriavezérlő (opb_emc) a kártyán található SRAM-ot illeszti a rendszerhez. Az FPGA kártyán lévő megjelenítő és adatbeviteli eszközök elérését az sp3small nevű periféria biztosítja. Ez tartalmazza a kijelzők időmultiplexelt vezérléséhez szükséges logikát és a pontmátrix kijelző karaktergenerátorát (angol ABC, 0-9 számjegyek). A periféria az alábbi programozási interfésszel rendelkezik: Regiszter címe bázis + 0x00 bázis + 0x04 bázis + 0x08
Írás LED-ek hétszegmenses kijelző pontmátrix kijelző
Olvasás DIP kapcsoló nyomógombok 0x00000000
A 12-8. ábrán látható, hogy az XMD sikeresen kapcsolódott a mikroprocesszoros rendszerhez a soros porton keresztül. Az mwr parancs segítségével a kijelzőkre, illetve a memóriába tudtam adatokat írni. A nyomógombok és a kapcsolók állapotának, valamint a memória tartalmának beolvasása az mrd paranccsal lehetséges. Végül pedig a külső memóriába letöltöttem egy programot (dow parancs). A tesztek során minden az elvárásoknak megfelelően viselkedett.
60
12-8. ábra: Az FPGA kártya tesztelése az XMD-vel.
12.5 A fejlesztői kábel néhány jellemző paramétere A tápfeszültség kimenet terhelhetősége Normál USB kábelt használva Y-kábel használata esetén JTAG funkció TCK frekvencia XC3S200 típusú FPGA konfigurálásának időtartama XC3S250E típusú FPGA konfigurálásának időtartama XC2C64 típusú CPLD konfigurálásának időtartama XCF02S típusú Platform FLASH felprogramozásának időtartama Kommunikációs funkciók UART adatátviteli sebesség SPI órajel frekvencia I2C órajel frekvencia Szoftveres soros I/O órajel frekvencia
61
max. 450 mA max. 950 mA kb. 1 MHz kb. 1600 ms kb. 2100 ms kb. 1200 ms kb. 35 s 4800 – 115200 bit/s 2000 Hz – 8 MHz 500 Hz – 400 kHz 0,2 – 1000 Hz
13 Az eredmények értékelése A tesztelési eredmények alapján elmondható, hogy a kitűzött célokat sikerült elérni és az elkészült rendszer az elvárásoknak megfelelően viselkedik.
A diplomamunka elkészítése során hasznos tapasztalatokat szereztem hardverrel és szoftverrel kapcsolatos területeken is. A hardvertervezés talán egy kicsit idegen terület az informatikusok számára, ennek ellenére a fejlesztői kábel és az FPGA kártya megtervezése, illetve a nyomtatott áramkörök megtervezése és összeszerelése nem okozott nagy nehézséget. A szoftverek elkészítéséhez szükséges ismeretek is széles tartományt ölelnek fel: •
hardverközeli programozás (mikrovezérlő programja),
•
rendszerprogramozás (eszközmeghajtók),
•
.NET platform (osztálykönyvtárak és alkalmazások).
A szoftverek közül külön kiemelném az eszközmeghajtó programokat, ezek megírása volt a legnehezebb munka. Az egyetemi tanulmányaim során az eszközmeghajtó programok készítésével kapcsolatos tantárgyaim nem voltak, ezért ezeket az ismereteket saját magamnak kellett könyvekből és internetes forrásokból elsajátítani.
62
14 Ábrajegyzék 2-1. ábra: A régi (felül) és az új (alul) interfész (LOGSYS port) lábkiosztása. .........................3 2-2. ábra: A LOGSYS fejlesztői környezet. ...............................................................................6 3-1. ábra: A JTAG lánc kialakítása. ...........................................................................................8 3-2. ábra: A boundary-scan cella felépítése................................................................................9 3-3. ábra: A TAP vezérlő állapotgráfja. ...................................................................................10 4-1. ábra: Az USB topológiája. ................................................................................................13 4-2. ábra: USB csomagok.........................................................................................................15 4-3. ábra: Bulk IN és bulk OUT transzferek. ...........................................................................16 4-4. ábra: Interrupt transzfer. ....................................................................................................16 4-5. ábra: Isochronous transzfer. ..............................................................................................17 4-6. ábra: Kontroll transzfer. ....................................................................................................17 4-7. ábra: Egy USB periféria logikai felépítése........................................................................19 5-1. ábra: CMOS inverter. ........................................................................................................20 5-2. ábra: Részleges tápfeszültség kikapcsolás. .......................................................................21 5-3. ábra: A soros áramkorlátozó ellenállás és a diódás megoldás. .........................................22 5-4. ábra: A módosított kimeneti fokozat.................................................................................22 6-1. ábra: A fejlesztői kábel blokkvázlata. ...............................................................................25 6-2. ábra: Az összeszerelt fejlesztői kábel................................................................................28 7-1. ábra: Az FPGA kártya blokkvázlata..................................................................................29 7-2. ábra: A bővítőcsatlakozók lábkiosztása. ...........................................................................30 7-3. ábra: Az összeszerelt FPGA kártya. ..................................................................................31 8-1. ábra: Az USB periféria logikai felépítése. ........................................................................32 8-2. ábra: A JTAG adatszerkezet..............................................................................................34 8-3. ábra: Az I/O vonalak vezérlése. ........................................................................................38 10-1. ábra: A PnPMessage osztálykönyvtár osztálydiagramja.................................................45 10-2. ábra: A JTAG eszköz adatbázis. .....................................................................................48 11-1. ábra: Lehetséges letöltőkábel beállítások az iMPACT programban. ..............................50 11-2. ábra: A Xilinx iMPACT és a kábelszerver alkalmazás...................................................53 11-3. ábra: Az XMD és a processzoros rendszer közötti kommunikációs lehetőségek. ..........53 11-4. ábra: Az XMD és a GNU debugger. ...............................................................................54 12-1. ábra: A kimeneti áramkorlátozás tesztelése. ...................................................................55 12-2. ábra: A kernel debugger használatához szükséges konfiguráció. ...................................57 12-3. ábra: A JTAG tesztalkalmazás. .......................................................................................58 12-4. ábra: Az I2C tesztalkalmazás...........................................................................................58 12-5. ábra: A szoftveres soros I/O tesztalkalmazás..................................................................59 12-6. ábra: Alkalmazás az SPI FLASH felprogramozásához...................................................59 12-7. ábra: A MicroBlaze processzoros rendszer blokkvázlata. ..............................................60 12-8. ábra: Az FPGA kártya tesztelése az XMD-vel................................................................61
63
15 Irodalomjegyzék [1]
Molnár Gábor, Fülöp Tamás, Kiss Gergely, Zigó Attila: Digitális áramkörök oktatási és demonstrációs eszköze. BME-VIK, TDK dolgozat (2003).
[2]
Laczkó Péter, Raikovich Tamás: Programozható logikai rendszerek konfigurációs- és tesztkörnyezete. BME-VIK, TDK dolgozat (2006).
[3]
R. G. Bennetts: Boundary Scan Tutorial ASSET InterTech, Inc., http://www.asset-intertech.com/pdfs/boundaryscan_tutorial.pdf
[4]
Serial Vector Format Specification ASSET InterTech, Inc., http://www.asset-intertech.com/support/svf.pdf
[5]
Universal Serial Bus Specification, http://www.usb.org
[6]
Logic Selection Guide Texas Instruments Inc., http://www.ti.com
[7]
SN74LVC1T45 Datasheet Texas Instruments Inc., http://www.ti.com
[8]
SN74LVC2T45 Datasheet Texas Instruments Inc., http://www.ti.com
[9]
PCA9306 Datasheet Texas Instruments Inc., http://www.ti.com
[10] MIC2544 Datasheet Micrel, Inc., http://www.micrel.com [11] AT90USB646/647/1286/1287 Datasheet Atmel Corporation, http://www.atmel.com [12] DS321: Spartan-3E FPGA Family Data Sheet Xilinx, Inc., http://www.xilinx.com [13] K6R1008V1D Datasheet Samsung Electronics Co., Ltd., http://www.samsung.com [14] W25P16 SPI FLASH Datasheet Winbond Electronics Corp., http://www.winbond-usa.com [15] MCP1612 Datasheet Microchip Technology Inc., http://www.microchip.com [16] Walter Oney: Programming the Microsoft Windows Driver Model, Second Edition. Microsoft Press, Redmond, 2003. ISBN 0-7356-1803-8 [17] Windows Driver Kit Microsoft Corporation, http://www.microsoft.com/whdc/devtools/WDK/default.mspx [18] Debugging Tools for Windows Microsoft Corporation http://www.microsoft.com/whdc/devtools/debugging/default.mspx [19] XILPRG projekt http://sourceforge.net/projects/xilprg
64
16 A CD melléklet tartalma \adatlap A felhasznált integrált áramkörök adatlapjai a gyártók szerint csoportosítva ([6], [7], [8], [9], [10], [11], [12], [13], [14] és [15]).
\drivers Az általános célú USB meghajtó és a virtuális soros port meghajtó forráskódja (Visual Studio 2005 projekt).
\edk A Spartan-3E FPGA kártya teszteléséhez készült mikroprocesszoros rendszer (Xilinx EDK 8.2i projekt).
\firmware A fejlesztői kábelen lévő mikrovezérlő programjának forráskódja (AVR Studio 4 projekt).
\jtag boundaryscan_tutorial.pdf
Összefoglaló a JTAG interfészről és annak tesztelési célú felhasználásáról ([3]).
svf_specification.pdf
Az SVF fájlformátum leírása ([4]).
\programok A .NET osztálykönyvtárak és az alkalmazások forráskódja (Visual Studio 2005 projekt).
\usb usb_20.pdf
Az USB 2.0 specifikáció ([5]).
\xilprg A XILPRG projekt kábelszerver alkalmazásának forráskódja ([19]).
65
17 Mellékletek 17.1 A fejlesztői kábel kapcsolási rajza
66
17.2 A fejlesztői kábel nyomtatott áramköri terve
Felső réteg
Belső réteg (1)
Belső réteg (2)
Alsó réteg
Felső réteg beültetése
Alsó réteg beültetése
67
17.3 A LOGSYS Spartan-3E kártya kapcsolási rajza 17.3.1 FPGA
68
17.3.2 I/O csatlakozók, memóriák
69
17.3.3 Kijelzők, DIP kapcsoló, nyomógombok
70
17.3.4 Tápegység
71
17.4 A LOGSYS Spartan-3E kártya nyomtatott áramköri terve
Felső réteg
Alsó réteg
Felső réteg beültetése
Alsó réteg beültetése
72
17.5 Osztálydiagramok 17.5.1 LogsysUSB osztálykönyvtár
73
74
17.5.2 JTAG osztálykönyvtár
75
