Status på arbejde med CORBA på et indlejret system.

Forfatter: Jesper Rosholm Tørresø CTES. IHA 14-12-2006

Synopsis

Her beskrives erfaringerne med at bruge en embedded real time CORBA  pakke PrimsTech eOrb på en SBC Pentium PC platform med Real Time Operativsystemet WindRiver VxWork. Samtidig beskrives erfaringerne med brugen af de nødvendige udviklingsværktøjer som skal til for at kunne bygge run time delene til SBC platformen.  Desværre kom der ikke et kørende system ud af arbejdet, der blev stoppet af en række praktiske problemer på den PC Windows XP baserede udviklingsplatform, samt uoverensstemmelser mellem target platformenes hardware og eOrb opsætningen.

Oplæg.

CTES.IHA ønsker at få erfaring i at bruge en "ægte" embedded realtime CORBA. Som mål-platform ønskes den netop indførte standard platform SBC Pentium PC med WindRivers VxWorks 6.3. Som udgangspunkt ønskes C++ benyttet som programmeringssprog.

Det undersøges hvilke standard "of the shell" CORBA platforme der kan bruges og hvordan de eventuelle fundne  platforme kan fungere sammen med eller indgå i Integrated Development Environment (IDE) WindRivers WorkBench 2.4 for Windows XP eller med andre standard IDE'er.

Et samtidig afgangsspecialeprojekt på TEKIT  omhandler OpenSource CORBA platformen TAO (The Ace Orb) og derfor fravælges direkte brug af TAO og dermed også den underliggende ACE platform.

Et "Hello World" eksempel ønskes om muligt demonstreret, hvori netop indgår kendetegnene for en indlejret applikation med kontrolleret proces/tråd afvikling.

Den opnåede viden skal bruges i undervsiningen på området med OO-middleware og gerne også som en form konsulentydelser til virksomheder, afgangsprojekter og udviklingsprojekter.

 

Off the Shell embbed CORBA platforme.

Som udgangspunkt undersøgtes de kommercielle TAO pakker/leverandører som er henvist til fra TAO' hjemmeside

Tre leverandører blev udvalgt i første runde

Konklusion.

PrimsTech "OpenFusion e*ORB SDR C++ Edition V1.1.x for Windows host, VxWorks 5.5.1 target, C++ Pentium II compiler and x86 chipset" blev valgt som forsøgsplatform.

Andre tiltag

En gennemgang af Wind River Workbench 2.5 til VxWorks 6.3 viste at der var support for udvikling til middleware platformene

En "Hello World" Webservice  applikation med en Service Provider og en Service Consumer blev "udviklet" vha. WorkBench'ens anvisningerne og forsøgt afviklet, men der var mindre fejl i håndteringen af Consummer s modtagelse af svar. Dette arbejde blev udført mens hjemtagning af PrimsTech og WindRiver Licenser stod på og blev stoppet da disse var på plads.

Samtidig blev en Java JVM¨til VxWorks  hentet hjem JamaicaVM fra aicas

http://www.aicas.com/download.html

men denne del er ikke blevet videre bearbejdet.

Arbejdet med PrismTech eOrb og Wind River VxWorks/Tornado.

PrimsTechs platformen er en selvstændig platform hvor selve kompileringen og opbygning af processer til VxWorks sker vha. præfabrikerede "make jobs" til GNU make, samt Cross compilere der hentes fra VxWorks 5.5.1 og Tornado 2.2  installationen. PrimsTech applikationer skal afvikles i "User Mode" på VxWorks.

Problem 1

Bruge af GNU make betød at installationen af CYGWIN Linux/Unix shell'en blev nødvendiggjort. Nyeste version af CYGWIN installere GNU Make version 3.81.

Problem 2.

PrimsTech make job er konfigureret til GNU make version 3.80 og KAN IKKE bruge andre version af make ver. 3.80.  3.80udgave er kun tilgængelig på Internettet som kilekode til egen oversættelse (Kræve MS VSC++ vers 3 eller 4) Et hint fra Ole Weigelt sagde at GNU make ver 3.80  er inkluderet i WindRiver WorkBench 2.4. Ved at erstatte CYGWIN ver GNU make 3.81 med 3.80 (make.exe i  'C:\cygwin' estattes med WorkBenchen's udgave) kom PrismTech' make job i luften.

UnderProblem 2.1 afledt af brugen af GNU make ver 3.81

Med GNU make ver 3.81 opstod den klassiske konflikt mellem Linux/Unix og Windows nemlig fortolkningen af '/' (Slash) kontra '\' (Backslash). 

Backslash betyder "fortsæt på næste linje" i GNU make syntaxen, og det giver selvsagt problemer når der benyttes filstier med Windows syntax. (Eks 'C:\Tornado2.2\target\config\pcPentium' kan ikke forstås af GNU make)  Dette problem kan løses med CYGPATH funktionen i CYGWIN og ved at bruge 'slash' en række miljøvariabler på Windows/CYGWIN men også behov for at ændre i PrimsTech' make filer.

UnderProblem 2.2 afledt af brugen af GNU make ver 3.81

Men "include stier "med 'slash' kan ikke umidelbart forstås af WindRivers Crosscompilerne til Windows platformen og dermed er det slut med make 3.81 og PrismTech for denne omgang (De forskellige krydskompilere findes i Tornado under  eks. 'C:\Tornado2.2\host\x86-win32\bin'

Problem 3

PrismTech eOrb pakke er standard opsat til et benytte en PentiumII cpu på en x86 platform. Efter at make problematikken så ud til at være løst var det nu muligt at oversætte og få linket 2  out filer hhv server.out og client.out.  Fra Tornado udviklingsmiljøet  startes et Shell vindue  med forbindelse til den tilbørende SBC/VxWorks 5.5.1 platform med download af filer fra PC til SBC gav kommunikationsproblemer. En søgning på "nettet" viste at det er et kendt problem som åbentbart skyldes at den binære file der hentes fra PC til SBC/VxWorks fejlfortolkes af "downloaderen" i Tornado.  Ved at give adgang til symbol tabellerne for de binære filer skulle dette problem angiveligt løses, men i dette projekt står den løsning hen i det uvisse. På et tidspunkt lykkes det at få en client.out fil ned på SBC'en med dette gav efterfølgende problem

Problem 4

Loadning og afvikling af binære fil (, som ikke følger den binære standard for en Pentium cpu platform,) på VxWorks giver formatfejl.

Ved at ændre i PrimsTech make job så der oversættes til en Pentium CPU og ikke en PentiumII CPU (vxworks-551-gnu-PII-win32.cfg se nedenstående liste)  var det håbet at dette problem kunne løses, men ændringen gav linker fejl en mas'  ved linkningen af serveren og client.out kan ikke downloades til SBC (Problem 3 igen)

 

Just to Compare!!

Hvis man vil bruge den almindelig PC løsning kan man sætte PrismTech Visual Studio 2005 projekter ind i VS 2005 og så afvikle eOrb projekterne på sin PC, med deraf følgende afskrivning af real time delen sammen med ORB'en.

Referencemodel

Referencemodellen som er blevet brugt i arbejdet findes her

Konklusion

CORBA og Real Time problematikkerne i sig selv er vanskelige at arbejde med. Dette arbejde har vist at det også er ekstremt vanskeligt, for ikke at sige umuligt, at få opstillet et brugbart udviklingsmiljø til at arbejde med de to problematikker på en embedded platform.

Årsagen hertil kan skyldes/skyldes givetvis at der er brugt C/C++ som programmeringssprog, der ikke supporterer det komponent orienterede paradigme på samme måde som Java og  .NET platformen.  Det er for eksempel rimeligt simpelt at installere og bruges en Java eller .NET implementeret ORB på en Windows/Linux platform mens C/C++ udgaver af ORB'erofte giver anledning til store problemer i forbindelse med installation og brug.

Det kan ikke siges med sikkerhed, men der er tilsyneladende ikke udført et korrekt lagdelt design i PrimsTech TAO baserede eOrb. Linkning af programmer ikke kan udføres til trods for at oversættelse er gennemført. Dette kan dog også skyldes forkert opsætning af "Options"  til hhv compiler og linker.

Under alle omstændigheder gælder at en kommerciel "Off the Shell  embedded CORBA platform" er bundet til et bestemt udviklings miljø og en bestemt udgave af den embedded hardwareplatfrom.