VI. fejezet - Célspecifikus alkalmazások

A „SOC” rövidítés jelentése „System on a Chip”, vagyis rendszer egy integrált áramköri tokban. Kifejlesztési szempontjainál lényeges szerepet játszott a teljes berendezés alacsony összköltsége, a berendezés kis mérete, fogyasztása. Nem tudunk éles határvonalat húzni a SOC és a mikrovezérlő közt, szokásosan a 128 kb RAM memória feletti eszközöket nevezzük SOC-nak, az ez alattiakat pedig mikrovezérlőnek. Természetesen ez a határvonal sem éles, ugyanis létezik mikrovezérlőként gyártott eszköz 512k memóriával is. Más szempontból is húzhatunk határvonalat (bár ez sem lesz éles): a SOC-on általában interaktív felületű operációs rendszert futtatunk (legtöbbször valami Unix-klónt, pl. Linuxot), míg a mikrovezérlőn egy feladatspecifikus program működik. Ez a szempont is a memóriamérettel operál: általában a Unix-klónoknak nem elég a 128 kbyte körüli memória.

A SOC (és a mikrovezérlő is) különböző hardverelemekből állhat, azonban mindig tartalmaz egy vagy több CPU (esetleg DSP) magot, amely egy műveletvégző egység. Szokásos gyártási eljárás, hogy a SOC gyártója a CPU magot másik gyártótól veszi, majd körberakja a saját hardverelemeivel, és betokozza. Ez a rész felel meg kb. a PC-k processzorának. A tápellátó és buszvezérlő áramkörök is mindig megtalálhatók. Ezen elemek (pl a CPU mag) lábai közvetlenül nem jelennek meg a SOC lábai közt. A busz is jellemzően belső busz szokott lenni, ha külső memória/periféria csatlakoztatási lehetőség is van, azt buszillesztőn keresztül vezetik ki.

Opcionális, szokásos hardverelemek:

Álljon itt két tipikus blokk-diagram: egy mindentudó mikrovezérlőé (forrás: Microchip, típus: PIC32MX család), és egy médialejátszóba szánt SOC-é (forrás: Realtek, tipus: RTD1073) A Realtek kevésbé dokumentált, ott csak a külső csatlakozásokat tüntették fel.

A legtöbb Atmel mikrovezérlőt a GCC fordító is támogatja, így nyílt forráskódú IDE is készült hozzá: a WinAVR a Sourceforge weblapon található. Ingyenes, regisztrációmentes letöltés és telepítés után a GCC fordító és a szükséges binutils, valmint a gdb debugger is használható. Az ingyenes programokra jellemzően nincsenek kényelmi funkciók, vagy programkönyvtárak a speciális hardverekhez; ezeket külön kell telepítenünk. A VI.3. ábra ábra egy interneten található led-villogtató mintaprogram fordítását mutatja a WinAVR-rel. A Makefile-t és a led.c fájlt kellett ehhez a projekthez megírni a szövegszerkesztővel, majd a Tools menü „Make All” menüpontját kiválasztani.

Az első két értékadó utasítás lefordítva:

void main(void)
 
{ unsigned char i;
 // set PORTD for output 
DDRB = 0xFF; 
  34:    8f ef           ldi    r24, 0xFF    ; 255
  36:    87 bb           out    0x17, r24    ; 23
PORTB = 0b00000001; 
  38:    81 e0           ldi    r24, 0x01    ; 1
  3a:    88 bb           out    0x18, r24    ; 24

Elkészült az EEPROM tartalom (led.eep), amit az avrdude programozó szoftverrel, stk600-as hardverrel (200$) vagy AVRISP-vel (40$) be lehetne égetni az ATTiny2313-ba.

Az Atmel is elkészítette a saját IDE-jét, amelyhez több programkönyvtárat is adnak, ennek neve AVR Studio. Tartalmaz beépített C fordítót, de az internetes világ a GCC fordítót használja, így az AVR Studio beállítható úgy, hogy a WinAVR-ben található GCC fordítóval működjön együtt.

A Microchip-nél gcc támogatás nincs (picgcc projekt ugyan létezik, de letölthető változat nincs), így a cég weboldaláról ingyenesen letölthetjük az MPLAB IDE-t, amely assembler fordítót (MPASM) tartalmaz az összes termékükhöz (16xx,18xx,24xx,dsPIC), kivéve a PIC32 családot (MIPS core:asm32), és a C fordítóból az oktatási licenszű verziót a 18-as (c18), 24-es (c24) és 32-es (c32) sorozathoz. Az IDE a szerkesztésen kívül az összes beszerezhető programozót és debuggert is támogatja. Amennyiben kényelmesen szeretnénk használni, ne kérjünk teljes telepítést (full installation), csak a meglévő (tervezett) eszközeinket és fordítóprogramokat telepítsük fel. Hasznos eszköz lehet az MPLAB SIM, amellyel konkrét hardver nélkül futtathatjuk, debuggolhatjuk programjainkat, egy virtuális CPU-n. A virtuális CPU nagy előnye, hogy fordított polaritású tápcsatlakoztatással nem tehető tönkre, a valódi változattal szemben. A következő ábrán (VI.4. ábra) a IV.2.23. szakasz szakaszban található programmal (SerialPort) kommunikáló programrészlet fejlesztése látható.

A VI.4. ábra programrészletete egy PicKit2-vel (eredeti: 40$, klón: 25$) beégethetjük egy PIC18f4550-be, és USB-n keresztül már kommunikálhatunk is a hardverrel.

Az MPLAB IDE fejlesztése során alkalmazott problémákat (Windows-függőség) próbálja meg feloldani az új MPLAB-X. A NetBeans alapú környezet fut Linuxon és MacOS-X-en is. Ez már tartalmazza a Visual Studio-ban alkalmazott automatikus kódkiegészítő funkciót és a függvény-definíció keresőt.

A CORBA egy, az OMG (Object Management Group) által definiált szabványos objektum környezet, 1990-ben jelent meg az első verziója, amellyel különféle nyelveken írt, és/vagy különálló gépeken futó alkalmazások együtt képesek dolgozni. Az alkalmazás a metódusokat ugyanúgy használhatja a távoli gépen is, mint a helyi gépen. A szabvány fontos eleme az interfész definíciós nyelv (IDL), amely a konkrétan használt fordítóprogramtól (amely fordíthat C-ről, C++-ról, Java-ról, Cobol-ról és még néhány egyéb nyelvről) független. A CORBA fordító elkészíti az adott nyelvhez az IDL-ben megírt objektumokhoz a függvények fejléceit (skeleton - csontváz), amelyet nekünk kell az adott nyelven implementálni, ezt a folyamatot „mapping”-nek, az így készített objektumokat pedig „adapter”-nek nevezzük. A mapping a Java nyelvben egyszerű, a nyelv erősen objektum-orientált tulajdonságai miatt. C++-ban kissé többet kell dolgozni: összetett adatszerkezetek felhasználására van szükség, amelyek néha összekeverednek a szabványos sablonkönyvtár (STL) típusaival. A CORBA implementáció tartalmaz egy IDL fordítót, amely már a felhasznált nyelvre (pl C++) fordít, és a szabályos fordítóval és szerkesztővel készíthetünk futtatható programot, természetesen az IDL-ből fordított függvények definiálásával (a csontváz „felöltöztetésével”) az adott programnyelven. Emellett tartalmaz natív kommunikációs komponenseket, amelyek az internetes, socket szintű kommunikációt bonyolítják, a felhasználó számára transzparens módon. Az alábbi (VI.5. ábra) ábrán egy kiszolgálón működő objektum ügyfélből történő elérését szemléltetjük:

A CORBA egy szabvány, emiatt nem egy gyártótól szerezhető be: többen is implementálták a struktúrát. Licenszelhető (vásárolható) és nyílt forráskódú változatok egyaránt léteznek. A licenszelhető implementációk főleg a pénzügyi szektorban terjedtek el, az oktatásban az ingyenesen hozzáférhető nyílt forráskódú változatok valamelyikét használjuk.

MICO: www.mico.org a Frankfurti egyetem fejlesztéséből született, C++ nyelven íródott, egyedül Unix API hívásokat alkalmaz. A forrásfileokat a SourceForge-n tárolják, onnan letölthetők.

JacORB: www.jacorb.org Java nyelvű ORB, LGPL licensszel. JDK 1.6 kell a működéséhez.

TAO: www.ociweb.com A Washingtoni egyetem fejlesztése, létezik ingyenes és kereskedelmi változatban is. Unix-on és Windows-on is használhatjuk, létezik valós idejű (real-time) operációs rendszeren futó verzió is.

ORBiT: orbit-resource.sourceforge.net Alap C-ben és Perl-ben is használható, nyílt forráskódú CORBA 2.4 implementáció. Mivel a GNOME rendszerhez fejlesztették ki, a legtöbb Linux disztribúció tartalmazza. Win32 alatt futó változat is készült belőle.

Az alábbi példában egy "távoli" számítást fogunk elvégezni, az ügyfél megadja a műveletet, a kiszolgáló elvégzi, az ügyfél pedig kijelzi az eredményt. A példában mindkét program (a kliens és a szerver) is ugyanazon a számítógépen fut. Az IDL fájl a lehető legegyszerűbb, egy interfészt két függvénnyel tartalmaz:

// Calculator interface: calculator.idl
//
interface Calculator
{
      double add(in double number1, in double number2);
      double sub(in double number1, in double number2);
};

Fordítsuk le az idl compilerrel: /usr/pkg/bin/orbit-idl-2 calculator.idl !

orbit-idl-2 2.14.17 compiling mode, hide preprocessor errors, passes: stubs skels common headers
Processing file calculator.idl

Ekkor elkészül a „csontváz” (calculator-skel.c), a kliensen futtatható stub (calculator-stubs.c), és a fejállomány (calculator.h). A header fájlban megtaláljuk a CORBA kompatibilis osztályt (alap C, struct függvényekkel):

typedef struct {
  void *_private;
CORBA_double (*add)(PortableServer_Servant _servant, const CORBA_double number1, const CORBA_double number2, CORBA_Environment *ev);
CORBA_double (*sub)(PortableServer_Servant _servant, const CORBA_double number1, const CORBA_double number2, CORBA_Environment *ev);
} POA_Calculator__epv;

Ezeket kell implentálnunk (skelimpl.c):

static CORBA_double
impl_Calculator_add(impl_POA_Calculator * servant,
            const CORBA_double number1,
            const CORBA_double number2, CORBA_Environment * ev)
{
   CORBA_double retval;
 
   /* ------   insert method code here   ------ */
   g_print ("%f + %f\n", number1, number2);
   retval = number1 + number2;
   /* ------ ---------- end ------------ ------ */
 
   return retval;
}
 
static CORBA_double
impl_Calculator_sub(impl_POA_Calculator * servant,
            const CORBA_double number1,
            const CORBA_double number2, CORBA_Environment * ev)
{
   CORBA_double retval;
 
   /* ------   insert method code here   ------ */
   g_print ("%f - %f\n", number1, number2);
   retval = number1 - number2;
   /* ------ ---------- end ------------ ------ */
 
   return retval;
}
Ezután következhet a kiszolgáló oldali főprogram:
static CORBA_Object
server_activate_service (CORBA_ORB           orb,
             PortableServer_POA  poa,
             CORBA_Environment  *ev)
{
    Calculator  ref = CORBA_OBJECT_NIL; 
 
    ref = impl_Calculator__create (poa, ev);
    if (etk_raised_exception(ev)) 
        return CORBA_OBJECT_NIL;
    
    return ref;
}

A kiszolgáló main() függvényben elindítjuk a szolgáltatást:

servant = server_activate_service (global_orb, root_poa, ev);
server_run (global_orb, ev);

Az ügyfélen a stubon nem kell változtatnunk, csak a main() függvény megírása hiányzik:

static
void
client_run (Calculator service,
    CORBA_Environment *ev)
{
    CORBA_double result=0.0;
    result = Calculator_add(service, 1.0, 2.0, ev);
    g_print("Result: 1.0 + 2.0 = %2.0f\n", result);
}

Ezt az ügyfél main() függvényéből meghívjuk, és a kiszolgáló elvégzi a számolást:

calculator-server & elindítjuk a kiszolgálót a háttérben, ami vár a kliens csatlakozására

calculator-client elindítjuk az ügyfelet

1.000000 + 2.000000

Result: 1.0 + 2.0 = 3

A CORBA rendszert megvizsgálva azt láthatjuk, hogy sok feladatra alkalmazható, azonban a szükséges programozási munka nagy része a feleslegesen túlbonyolított objektumokra és osztályokra megy el. Néhány CORBA fejlesztő ezért egy kis fejlesztő csapatot alakított, hogy a CORBA elveit újragondolva, készítsenek egy bizonyos szempontból leegyszerűsített, bizonyos szempontból bővített távoli objektumelérést támogató rendszert. Erre a feladatra egy céget is alapítottak, ZeroC néven (www.zeroc.com). A rendszert ICE-nak nevezték el, és kétfajta licenszeléssel hozzáférhető: GPL és kereskedelmi licensz is létezik belőle. A kereskedelmi (fizetős) licenszhez terméktámogatás jár. Külön előny, hogy az ICE-hez lélezik a manapság divatos érintőképernyős platformokon futó változat, pl. az IceTouch, amely az OS-X fordítójához (Xcode) készült, és iOS szimulátort is tartalmaz. Az ICE disztribúció tartalmaz mindent, amire a környezetnek szüksége van: eszközöket, API-kat, könyvtárakat az objektumorientált kiszolgáló-ügyfél alkalmazások készítéséhez. Támogatja az architektúrák és nyelvek közti átjárhatóságot: az ügyfél és a kiszolgáló is futhat más platformon, más programozási nyelven megírva. A leíró nyelvet, amelyben definiáljuk az ICE objektumot, Slice-nek nevezzük (Specification Language for Ice). Ez tartalmazza az interfészeket, a műveleteket és az adattípusokat, amelyek a kiszolgálón és az ügyfélen közösen definiáltak. Ezeket a Slice fájlokat egy fordító API hívásokra fordítja, forrásnyelvű programrészletekre, amelyek az aktuális rendszerben és programozási nyelven lefordíthatók, természetesen csak a skeleton kitöltése (a függvények {} közti részének megírása) után. Az egyes nyelvekre való fordítást "language mapping"-nak nevezzük. Az ICE rendszerben a használt nyelv lehet C++, Java, C#, Python, Objective-C. Az ügyféloldalon PHP is alkalmazható. Az ICE-t használó programok szerkezete az alábbi (VI.6. ábra) ábrán látható:

Az ICE saját protokollt használ az IP fölött, ez lehet TCP vagy UDP is. Amennyiben érzékeny adatokat tartalmaznak az objektumaink, SSL-t is használhatunk a kiszolgáló és az ügyfél között. A hagyományos távoli objektumhoz képest plusz szolgáltatásokat is kínál, mint pl. az IceGrid, amelyben több kiszolgáló is tartalmazhatja az objektumot, teherelosztás (load-balancing) céljából, vagy az IceStorm, amely események szétosztását végzi a közzétevők és az esemény iránt érdeklődő előfizetők között.

Az alábbi, egyszerűsített példában egy ipari robot ICE kiszolgáló oldalát készítjük el, a robothoz kapcsolódó ügyfelek képesek a robot mozgatására és az aktuális koordináták lekérdezésére. A slice definiciós állomány a következő (Kuka.ice – a Visual Studioval csak mint szövegfájl nyitható ki):

module CyberLab
{
 
  struct e6pos 
  {
    float x; // x,y,z milliméterek
    float y;
    float z;
    float a; // a,b,c szögek, fokban
    float b;
    float c;
  };
 
 
  interface Robot6Dof
  {
    void GotoHome(); // alap pozíció a robot programban
    e6pos GetPosition(); // hol vagy ?
    void GotoPosition(e6pos p); // menj egy pozícióba
  };
};

Ezt a fájlt a slice2cpp.exe-vel lefordítjuk, keletkezik 2 állomány: Kuka.cpp, és Kuka.h. Ez az úgynevezett „csontváz”, amelyben a definiált metódusok, mint absztrakt virtuális tagfüggvények szerepelnek:

virtual void GotoPosition(const ::CyberLab::e6pos&, const ::Ice::Current& = ::Ice::Current()) = 0;

Ráismerhetünk az interfész utolsó függvényére. Ahhoz, hogy az osztályt példányosítsuk, ezt a függvényt definiálnuk kell. A Robot6Dof osztályból örököltetünk egy új osztályt (az implementációs osztályt: Robot6DofI), amelyben ezen tagfüggvények kifejtése szerepel:

class Robot6DofI : public Robot6Dof {
public: 
    virtual void GotoHome(const Current& c);
    virtual e6pos GetPosition(const Current& c);
virtual void GotoPosition(const e6pos& e6, const Current& c);
};

Majd ezeket a függvényeket ki is fejtjük:

void Robot6DofI::GotoHome(const Current& c)
{
    Send_command_to_robot(CMD_ROBOT_HOME);
}
 
e6pos Robot6DofI::GetPosition(const Current& c)
{
    e6pos poz;
    Send_command_to_robot(CMD_ROBOT_GET_POSITION,poz);
    return poz;
}
 
void Robot6DofI::GotoPosition(const e6pos& e6, const Current& c)
 {
     Send_command_to_robot(CMD_ROBOT_GOTO_POSITION,e6);
 }

A kifejtésben felhasználtuk a már meglévő kommunikációs függvényeket, amelyek a robotnak RS-232-n keresztül parancsokat küldtek. Már csak a főprogramot kell megírni, létrehozni a kommunikációs adaptert (az ICE demo program alapján):

int _tmain(int argc, _TCHAR* argv[])
{
    int status = 0;
    std::string s1="KukaAdapter";
    std::string s2="default -p 10000";
    Ice::CommunicatorPtr ic;
    Ice::InitializationData id;
    argc=0;
    try 
    {
    ic = Ice::initialize(id);
    Ice::ObjectAdapterPtr adapter=ic->createObjectAdapterWithEndpoints
(s1,s2);
    Ice::ObjectPtr object = new Robot6DofI;
    adapter->add(object,ic->stringToIdentity("Kuka"));
    adapter->activate();
    ic->waitForShutdown();
    } 
    catch (const Ice::Exception& e) 
    {
        cerr << e << endl;
        status = 1;
    } 
    catch (const char* msg) 
    {
        cerr << msg << endl;
        status = 1;
    }
    if (ic) 
    {
        try 
        {
            ic->destroy();
        } 
        catch (const Ice::Exception& e) 
        {
            cerr << e << endl;
            status = 1;
        }
    }
    return status;
}

Ne felejtsük el a projektünk tulajdonságaiban beállítani az ICE include és library könyvtárait, mert azok nélkül nem képes lefordítani és összeszerkeszteni a programot!

A hibátlan fordítás után már csak az ICE-hez tartozó DLL-eket kell a program futása közben elérhetővé tenni, és indulhat a szerver. A Kuka.ice file-t átküldve a külföldi partnernek, ő elkészíti az ügyfelet (valamilyen programozási nyelven, pl C++-ban, vagy C#-ban), és távolról képes irányítani a robotot.