Részletes Hardver- és Szoftvertervezés

Átírás

1 Részletes Hardver- és Szoftvertervezés A szoftver- és hardvertervezés megtanítása bonyolult és hosszadalmas folyamat, de ez nem is szerepel eme jegyzet céljai között. Ennek ellenére, mivel a beágyazott ##en.: embedded## rendszerek szoftver- és hardvertervezésének egyedi mozzanatai vannak, ezek részleteit ebben a jegyzetben kell megtárgyalni. Létezik olyan, jól leírt, működő technika, amely segítségével a PC-re C, C++ vagy Java nyelveken megírt kód futtatható a beágyazott eszközön. Ez nagy segítség a beágyazott rendszerek fejlesztésében, hiszen a PC alapú fejlesztés már bejáródott technikáit és eszközeit lehet felhasználni. Ezért ezeknek az igen fontos témaköröknek: a fejlesztési környezeteknek és a speciális szoftveres technikáknak; a bemutatására, a jegyzetben külön fejezetek lettek szentelve. A szoftverfejlesztés mellett a hardvertervezés is szükséges a beágyazott rendszerek esetében. Mivel a tárgyat vegyes előtudást megszerző diákok hallgatják, gondot jelentett megállapítani milyen részletes legyen a hardvertervezési technika ismertetése. Nagyon sok forrásanyag van, amire hivatkozni lehet, ezek közül sokkal már megismerkedtek a villamosmérnök diákok a mikroprocesszorok és digitális tervezési kurzuson. Viszont a mérnök-informatikus diákok számára bizonyos részleteket meg kell világítani, ahhoz, hogy átláthassák a beágyazott rendszerek tervezésével és kimenetével kapcsolatos témakört. Hardver/Szoftver Integrálás A beágyazott rendszer a fejlesztés során előbb-utóbb eljut abba a fázisban, amikor a hardvert és a szoftvert integrálni kell. Ez gyakran igen bonyolult folyamat, ami nemritkán speciális eszközöket és módszereket igényel. A beágyazott szoftver- és hardver integrálásának a folyamata jól felkészült szakemberek munkáját igényli, amelyek gyakorlottak hibakeresési és felderítési metódusok alkalmazásában. A felderítés egy találó kifejezés, ugyanis a fejlesztőcsapatok ilyenkor szembesülnek azzal, hogy valóban megértették-e a közösen megírt dokumentumokat, amelyek a hardver és a szoftver együttműködését írja le. Együtt kell felderíteniük a félreértéseket és elhárítani a hibákat. Sajnos mindkét oldalon előfordul a fejlesztés közbeni egyszerűsítési hajlam, ami során csak egy kicsit térnek el a leírt dokumentumokhoz, ami persze nagy gondokat okozhat az integrálás során. Az ilyen hibák elhárítása ha egyáltalán lehetséges szoftverrészek újraírásával vagy a hardver javítgatásával jár. Minden esetben, időt és pénz veszt a csapat, a hanyagul értelmezett, vagy tiszteletben nem tartott tervezési dokumentáció miatt. A fejlesztés elején elkészített fejlesztési dokumentációt indokolt esetben fejlesztés közben is meg lehet változtatni, de erről minden érintett félnek (szoftveres, hardveres, integráló, csapatfőnök stb.) tudnia kell. Ha nem így tesznek, akkor az integrálás eleve lehetetlenné válik. A hardver és szoftver integrálása során klasszikus hibára való alkalom az endian félreértés. Ez azért is érdekes hibatípus, mert hatására az integrált rendszer működésképtelen lesz, mindannak ellenére, hogy a szoftver és a hardver is külön-külön, hibátlanul működik. Az endian félreértés bővebb ismertetése a következőekben történik meg. Az endian félreértés Az egyik gyakori félreértés a hardver és szoftver integrálása során az endian félreértés. A probléma elnevezése Jonathan Swift: Guliver utazásai c. művéből ered. A probléma lényege az, hogy több byte-os adatokat a memóriában, a különböző processzoros rendszerek más-más

2 módon tárolják. A probléma a több byte-os egész-, a lebegőpontos- és a fixpontos számokat is érintheti, valamint a soros átvitelű (RS232, USB, Ethernet) adatok esetén is előfordulhat. Az endianizmus A problémának hardverre visszavezethető forrása van. Az egész számokkal műveleteket végző processzorok kitüntetett regisztere(i) pl. akumulátor, szorzatregiszter stb. - a gyakorlatban kétszer, négyszer szélesebbek, mint a rendelkező memória bitszélessége. Ezért amennyiben egy belső regiszter tartalmát a csatlakoztatott memóriában kell tárolni, ezt csak a regisztertartalom több részadatra való bontásával lehet megtenni. A processzorok a memóriát az alacsonyabb címektől kezdődően a magasabb címek felé szokták írni (és olvasni), kivéve a vermet ##en.:stack## ahol ez pont fordított irányban történik. A processzor bitszámától függően az írást nem lehet akármelyik címtől kezdeni, így előfordul, hogy csak páros, vagy csak néggyel osztható címtől lehet adatot kiírni. Belátható, hogy mindez a gyakorlatban igen változatos kiírási képét eredményez. A lebegőpontos számok ábrázolása szabványosítva van (de a nagy processzor gyártók bizony sokszor ettől is eltérnek), de ezen a téren is előfordulhat az endian szindróma. A gyakorlatban a little- és big-endian ábrázolással lehet találkozni, habár a kettőnél több byte-ot tartalmazó adatok esetében elképzelhető mixed-endian és middle-endian alak is. Itt kell elmondani, - amire a liliputi tojásfeltörés esetében Swift is rámutatott - hogy nem létezik helyes és helytelen ábrázolás. Mindegyik helyes. Egy adott rendszer a saját adatait minden esetben ugyanazon az ábrázolással értelmezi (írja és olvassa), vagyis sohasem jut az endian probléma miatt hibás adathoz. A gond akkor jelentkezhet, ha több rendszernek kell együttműködnie. A litle-endian ábrázolás: az alacsonyabb helyértékű adatrész az alacsonyabb memóricímre kerül, míg a magasabb helyértékű adatrész a magasabb memóriacímre (1. ábra). Vagyis a tárolás az alacsonyabb helyértékű oldalon kezdődik. A big-endian ábrázolás: a magasabb helyértékű adatrész az alacsonyabb memóriacímre kerül, míg az alacsonyabb helyértékű adatrész kerül a magasabb memóriacímre (2.ábra). Vagyis a tárolás a magasabb helyértékű oldalon kezdődik. 1. példa: Amennyiben egy belső 32bites regiszter a 0x0A0B0C0D értéket tartalmazza, akkor a négy részre széttört adat tárolása, a 8bit széles memóriában a little-endian és big-endian alakban a következő módon fog megtörténni:

3 1. ábra little-endian tárolás 2. ábra big-endian tárolás Az endianizmus és az architektúrák A processzorok tervezői és gyártói, valamint az operációs rendszerek fejlesztői, szabályozás híján a két uralkodó endian ábrázolás közül szabadon választhatnak. Ebből természetesen sok probléma adódhat, pl. az ARM processzorok a lebegőpontos számok egyes típusait az egyik, míg más típusait a másik módon tárolják. Sőt a családon belüli váltás is előfordul, pl. a 3. verzió előtti ARM processzorok az egész számokat little-endian alakban tárolták, az újabb verziók pedig bigendian alakban. Ismertetésül következzen pár ismert operációs rendszer architektúra pár: little-endian: DragonFlyBSD x86, x86-64 FreeBSD Linux x86, x86-64, MIPS, ARM, Itanium x86, x86-64, MIPSEL, Alpha, Itanium, S+core, MN103, CRIS, Blackfin, MicroblazeEL, ARM, M32REL, TILE, SH, XtensaEL, UniCore32 Mac OS X x86, x86-64 ios ARM NetBSD x86, x86-64, Itanium, stb. OpenBSD x86, x86-64, Alpha, VAX, Loongson (MIPSEL) OpenVMS VAX, Alpha, Itanium Solaris x86, x86-64, PowerPC Tru64 UNIX Alpha ESX x86, x86-64 Windows x86, x86-64, Alpha, PowerPC, MIPS, Itanium big-endian: AIX AmigaOS POWER PowerPC, 680x0

4 FreeBSD HP-UX IRIX Linux Mac OS Mac OS X NetBSD MIPS, ARM, PowerPC, SPARC Itanium, PA-RISC MIPS MIPS, SPARC, PA-RISC, POWER, PowerPC, 680x0, ESA/390, z/architecture, H8, FR-V, AVR32, Microblaze, ARMEB, M32R, SHEB, Xtensa, ubicom32 PowerPC, 680x0 PowerPC PowerPC, SPARC, stb. OpenBSD PowerPC, SPARC, PA-RISC, SGI (MIPSEB), Motorola 68k és 88k, Landisk (SuperH-4) MVS és DOS/VSE z/vse és z/os Solaris ESA/390 z/architecture SPARC Az endianizmus és az adatátvitel A soros adatátvitel esetén szintén előfordulhat endian félreértés, aminek többszörös oka is lehet: az egyes adategységeken belül az átvitel bitsorrendje, vagyis először az LSB, vagy MSB kerül átvitelre? a több adategységből kialakuló adat leolvasási sorrendje, a már ismertetett endian eset. Az egyes szabványos soros átviteli protokollok között található little-endian, big-endian is. Viszont fellelhetőek olyan CPU, UART és DMA vezérlők amelyek transzparensek, vagyis konfigurálhatóak és mindkettőt támogatják, sőt egyes alaplapokon a RAM és rendszermemória endianizmusa is konfigurálható. Ismertetésül következzen pár szabványos protokoll és hardverelem endianizmusa: USB bit szinten little-endian RS-232 UART szinten little-endian RS-422 UART szinten little-endian RS-485 UART szinten little-endian DMX512 little-endian MIDI little-endian CANopen byte szinten little-endian Ethernet Powerlink byte szinten little-endian I 2 C big-endian I 2 S big-endian SMBus big-endian IP - Internet Protocol byte szinten big-endian

5 UART vezérlő bit szinten programozható DMA vezérlő byte szinten programozható soros/párhuzamos átalakító bit szinten programozható 8/16 bit hardveres FIFO byte szinten programozható Ajánlott irodalom: példa: Az FPGA-ban egy saját soros port lett tervezve. A port hardveresen úgy lett tervezve, hogy 32 bites adatbuszon keresztül lehet írni és olvasni. A port memóriába leképzett címe 0x A port alsó 16 bitje az adat, a felső 16 bitje pedig az állapot értéket tárolja. Amennyiben a szoftver írása során a tervező a port eléréséhez byte elérést használ, könnyen megtörténhet, hogy endian félreértés miatt hibás lesz a hardver és szoftver együttműködése. Vagyis a gyakorlatban összekeverednek az adat- és állapotrészbe szánt adatok. 3. példa: A 8. fejezetben ismertetett adatgyüjtő műszer esetében a 16 darab, párhuzamos I 2 S adatfolyam és a DMA egységek közé szükség volt két hardveres FIFO elhelyezésére. Az adatfolyamok szétválasztását, a FIFO-k konfigurálását és vezérlését, valamint a processzor DMA ciklusának indítását egy CPLD egységnek kellett elvégeznie. A CPLD hardvert és a mikroprocesszor szoftverét meg kellett tervezni, majd az elkészült elemeket össze kellet integrálni. Mindezek előtt egyeztetni kellett az adatok ábrázolási alakjában, hiszen a hardver végzi a 16 darab I 2 S adatfolyam két, egyenként 8 folyamra való bontását, amit a hardveres FIFOk little-endian sorrendben két 16 bites számmá alakítottak. A processzor perifériális terében megjelenő FIFO kimeneteket, megfelelő bitsorrendben kell DMA-val kiolvasni, majd a processzor RAM-jában tárolni, ezeket a feladatokat viszont a szoftver felügyeli. Azaz egy részletes dokumentációt kell készíteni. Az említett műszer esetében ez a dokumentum alapos átgondolás után elkészült. Pár részlet a következő három ábrán látható. A 3. ábrán a tervezés alatt keletkezett blokk-diagramm látható, a kívánt byte sorrend megjelöléssel. 3. ábra az adatok hardver terve

6 A 4. ábrán a tervezés alatt keletkezett ábra látható, a CPLD hardveres bekötésével. 4. ábra a CPLD és a vezérlőjelek Az 5. ábrán látható a végleges panel, amelyen be van jelölve a két hardveres FIFO és a CPLD. 5. ábra a két FIFO és a CPLD elhelyezése a panelen A szoftverfejlesztés mindeközben szintén követte a lefektetett terveket. Mikor mind a két rész elkészült a hardver és a szoftver integrálása könnyedén megtörténhetett.