5. Osnovna sredstva za razvoj embedded sistema

Analiziraćemo sada principe rada i mogiućnosti osnovnih sredstava koja se koriste za razvoj embedded sistema. 5.1 Uvodni deo Već smo ukazali da jedna od glavnih karakteristika embedded sistema predstavlja cross-platform metodologija za razvoj sistema. Primarne komponentte ovakvog razvojnog okruženja su: a) host sistem; b) ciljni embedded sistem; i c) veći broj sprežnih blokova (interfejs elektronika i kablovi) koji postoje između host-a i embedded sistema (vidi sliku 5.1).

Slika 5.1. Tipično cross-platform razvojno okruženje

Ključna razvojna sredstva koja se nude od strane host sistema (instalirani softver u host) su kros-kompajler, linker, i debager (nazvan source-level debugger). Ciljni embedded sistem može da ima instalirano dinamički loader, link loader, monitor, i debug agent. Skup sredstava za povezivanje (kablovi i interfejs elektronika) postoji između host-a i ciljnog sistema. Ova povezivanja se koriste sa ciljem da ostvare: 1) download-ovanje programa (program images) od host-a ka ciljnom sistemu; i 2) predaja informacije o debagiranju između ciljnog debug agent-a i host debagera. Programi kakvi su sistemski softver (RTOS ili kernel) i aplikacioni kôd, hronološki posmatrano, se moraju prvo razviti, nakon toga kompajlirati u objektni kôd, i na kraju, zajedno linkovati u izvršivi image fajl. Programeri koji pišu aplikacije koje se izvršavaju na istom okruženju kao i ono koje se koristi za razvoj (ovakvo razvojno okruženje se naziva native development) ne treba da brinu o tome kako će se executable image load-ovati u memoriju i na koji način će se upravljanje izvršenjem programa preneti na aplikaciju. Sa druge strane, embedded programeri koriste cross-platform razvojno okruženje pa treba: a) u celosti da razumeju ciljni sistem; b) da znaju na koji način da memorišu programsku image u ciljni embedded sistem; c) da znaju kako i na koji način da load-uju programsku image za potrebe izvršenja programa; i d) da znaju na koji način da razvijaju i debagiraju sistem koristeći iterativni pristup (kada se sistem testira i debagira, a pronađe se neka greška u programu, ceo postupak se ponavlja). Svaki od ovih aspekata ima uticaj na to na koji način se program razvija, kompajlira, i linkuje. 5.2 Host zasnovano debagiranje Kod razvoja embedded sistema uobičajena je praksa da se prvo napiše aplikacija na C ili C++, a zatim da se debagiranje algoritma izvrši na host-u, kakav je recimo desktop. Šta više, u slučaju da se kreiraju i programi na asemblerskom jeziku, moguće je izvršavati kôd na desktop sistemu (host-u) koristeći ISS (Instruction Set Simulator) sa ciljem da se testira što je moguće približnije real-time interakcija kôda sa (zamišljenim) specijalnim hardverom ciljnog sistema (koji verovatno u tom trenutku nije završen).

Pored nedostupnosti realnih radnih periferija, ipak najveći izvori problema kod host baziranog debagiranja su posledica egzistencije: a) neslaganja u obimu reči podataka sa kojima manipuliše host i ciljni sistem; b) uređenosti bajtova podataka u okviru reči. 5.2.1 Obim podataka Neka je obim podataka sa kojima manipuliše embedded procesor 16-bitni, a kompajler host-a bide baziran na 32-bitnoj stazi podataka. U takvoj situaciji promenljive tipa integer sa kojima manipuliše host, kakva je recimo PC mašina, nalaze se u opsegu ±2 milijarde, a integer-i sa kojima manipuliše embedded procesor biće u opsegu ±32000. Brojevi koji su veći od ciljnog opsega (32000) uzrokovaće pojavu grešaka kod embedded procesora, a na žalost neće nikad biti vidljive od strane host-a, tj. PC mašine. 5.2.2 Uređenost bajtova Drugi problem koji se javlja odnosi se na uređenost bajtova u okviru reči kod procesora koji koriste notaciju Little Endian - LE i Big Endian - BE. Ilustracije radi, analiziraćemo način memorisanja ASCII niza podataka na višem programskom jeziku C (slika 5.2).

Slika 5.2. Memorisanje podataka tipa char u bajtovski organizovanu memoriju

Na slici 5.2 prikazan je način memorisanja niza kod bajtovski organizovane memorije. Analizirajući sliku 2 vidimo da ne postoji problem iz razloga što je tip podataka char istog obima (8-bitni) kao i sadržaj memorijske lokacije, tj. zauzima prostor tačno jedne memorijske lokacije. Sada pretpostavimo da procesor ima magistralu podataka obima 16 bitova, kakva je ona kod procesora iz familije Motorola 68000 ili Intela iz familije 80186. Memorisanje samo jednog 8-bitnog podatka tipa char u memorijsku lokaciju koja je u stanju da čuva 16-bitni podatak dovodi do neefikasnog iskorišćenja memorijskog prostora pa se zbog toga ovakva šema memorisanja ne koristi. Obično bit najmanje težine (LSB) kod 16-bitne reči, se koristi da označi koji bajt (parni ili neparni) se adresira. Glavni problem koji se sada javlja (vidi sliku 5.3) odnosi se na to na koji način se smeštaju bajtovi u memoriju obima 16 bitova, prvenstveno zbog njihovog načina uređenja. Naime, kod Big Endian notacije parno adresirani bajtovi su poravnjani na bit pozicijama 15-8 od 16-bitne reči, dok kod Little Endian notacije parno adresirani bajtovi su poravnjani na bit pozicijama 7-0 od 16-bitne reči.

Slika 5.3. Memorisanje niza podataka kod 16-bitno organizovane memorije Kao što se vidi sa slike 5.2 memorisanje bajtova u memoriji obima 16 bitova dovodi do nejasnoća u odnosu na redosled kako se ovi bajtovi memorišu. Ovakva nejasnoća može da dovede do zabune. Recimo, neiskusan projektant koji je obučen za rad na Little Endian sistemu, kakva je PC mašina, odjednom se suočava sa drugačijim uređenjem bajtova u okviru reči ako projektuje sistem baziran na procesoru koji koristi Big Endian notaciju. Pomenuti problem postaje dodatno složeniji kada se koriste 32-bitne staze podataka. Na slici 5.4 su prikazana Little i Big Endian uređenja za 32-bitnu mašinu. Kod 32-bitne reči podataka, dva adresna bita najmanje težine - A0 i A1 - se koriste kao bajt selektor, ali u ovom slučaju postoje nejasnoće, a to su: od kog kraja 32-bitne reči se broji adresa?

Slika 5.4. Little i Big Endian organizacije 32-bitne reči podataka

5.3 Hardversko-softverska debagirajuća sredstva za razvoj 5.3.1 Struktura razvojnih sredstava Uspešno projektovanje jednog embedded sistema podrazumeva dobro poznavanje principa rada svih njegovih hardverskih i softverskih gradivnih blokova, kao i njihovu meeđusobnu interakciju. Pored poznavanja hardversko-softverskih komponenata veoma je važno i da se dobro razume koja su razvojna

sredstva (development tools) dostupna projektantima i od kakve su ona pomoći kod implementacije embedded sistema. Razvoj i integracija različitih hardverskih i softverskih komponenata embedded sistema su prvenstveno mogući zahvaljujući pomoći u radu koju pružaju ova razvojna sredstva a tiču se sledećih usluga: loadovanje softvera u hardver i ostvarivanje potpune kontrole (upravljlanje) nad različitim komponentama sistema. Razvojno okruženje se obično sastoji od:

a) embedded sistema - tj. sistema koji se razvija, ovaj sistem se često puta naziva target, b) host - izveden kao PC mašina ili radna stanica na kojoj se razvija program.

Target i host se povezuju preko prenosnog medijuma, serijskom ili paralelnom vezom. Razvojna sredstva embedded sistema mogu biti locirana u host-u, u target-u, ili mogu egzistirati kao nezavisne (stand-alone) jedinice. Ova sredstva se mogu svrstati u jednu od sledeće tri kategorije:

• utility tools - ovo su razvojna sredstva opšteg tipa koja su od pomoći kod razvoja hardvera i softvera kakvi su editori (koriste se za unošenje izvornog programa), VCS (Versio Control Software) namenjen za upravlljanje softverskim fajlovima, ROM burners omogućavaju da se softver upiše u ROM, i dr.

• translation tools - ova razvojna sredstva vrše konverziju kôda koga je projektant kreirao i namenio za target sistem u oblik (formu) koji je target u stanju da izvrši. Tu spadaju preprocesori, interpreteri, kompajleri, asembleri, i linkeri.

• debugging tools - ova razvojna sredstva se koriste za sleđenje traga izvršenja programa kao i korekciju grešaka u radu sistema, tj. lociranje i fiksiranje grešaka u sistemu. Tipična ovakva sredstva su In-Circuit Emulator (ICE), ROM emulator, Debugger, Profiler, Instruction Set Simulator (ISS), i dr.

5.3.2 Karakteristike debugging sredstava Pored aktivnosti koja se odnosi na kreiranje arhitekture embedded sistema, kreiranje debugging kôda je verovatno jedan od najtežih zadataka u toku razvojnog ciklusa sistema. Debugging je zadatak kojim se lociraju i fiksiraju greške u sistemu. U Tabeli 5.1 prikazane su osnovne karakteristike debugging sredstava koje se kao jedinke mogu izvesti: i) kao samostalni uređaji; ii) kao deo host-a; i iii) da bidu sastavni deo target ploča. Tabela 5.1. Sredstva za razvoj tip sredstva za razvoj

debugging sredstvo za razvoj

opis primer korišćenja i nedostaci

hardver In-Circuit-Emulator (ICE)

Aktivni uređaj koji zamenjuje mikroprocesor u sistemu

• obično je najskuplje debug rešenje, ali sa dosta debugging mogućnosti

• može da radi punom procesorskom brzinom (u zavisnosti od ICE-a), a za ostatak sistema se ponaša kao mikroprocesor

• obezbeđuje da se u realnom vremenu mogu videti i modifikovati interni sadržaji memorije i sadržaji registara i promenljivih

• slično debugger-ima omogućava postavljanje break-points-a, i ostvarivanje single stepping režim rada

• obično memorija koristi overlay memoriju za simulaciju ROM-a

• procesorsko zavisna

ROM emulator Aktivno razvojno sredstvo koje zamenjuje ROM preko kablova povezanih na Dual-port RAM u okviru ROM emulatora. To je uređaj tipa među-hardver koji se povezuje na target preko nekog kabla, tj. BDM, i povezuje se na host preko drugog porta.

• dozvoljava modifikaciju sadržaja u ROM-u

• može da postavi break-point-e u ROM kôdu, i da u realnom vremenu vidi ROM kôd

• obično ne podržava rad sa on-chip ROM-om, ASIC kolima, i td.

• može se integrisati na debugger-ima

Background Debug Mode (BDM)

Komponente koje se koriste za debugging embedded sistema. BDM komponente čine BDM hardver na ploči (BDM port i integrisani bebug monitor kod master CPU-a), i bebugger na host-u (povezan preko serijskog kabla na BDM port). BDM debugging se ponekad naziva on-chip debugging (OCD).

• obično je jeftiniji od ICE ali ne tako fleksibilan kao ICE

• nadgleda izvršenje softvera u realnom vremenu na nenametljiv način

• može da postavi break-point-e sa ciljem da zaustavi izvršenje softvera

• omogućava čitanje i upis u registre, RAM, U/I portove, i td.

• zavisan je od target procesora

IEEE 1149.1 Joint Test Action Group (JTAG)

Hardver na ploči koji radi u skladu sa JTAG preporukama.

• sličan BDM-u, ali nije specifičnost neke arhitekture (otvoreni standard)

IEEE - ISTO NEXUS 5001

Opcije JTAG porta, mora da radi u skladu sa NEXUS preporukama ili sa JTAG preporukama. Postoje nekoliko nivoa usklađivanja (sve u zavisnosti od složenosti master procesora, projektantskog izbora i td.)

• u zavisnosti od nivoa usklađivanja hardvera nude se proširljive (scalable) debug funkcije

Osciloskop Pasivni analogni uređaj koji na svom displeju prikazuje talasni oblik napona, tj. promenu napona u funkciji vremena.

• u najvećem broju slučajeva se izvodi kao dvomlazni

• može da radi u trigerskom režimu rada kako bi se prikazivanje talasnih oblika vršilo u specifičnim uslovima

• može da se koristi kao voltmetar za grubu procenu

• može da se koristi za verifikaciju rada kola posmatranjem talasnih oblika signala na U/I pinovima portova ili linija na magistrali

• nezavisan je od tipa procesora

Logički analizator

Pasivan uređaj koji simultano prihvata i sledi trag o većem broju signala, a takođe i vrši njihov prikaz.

• s obzirom na broj kanala koji se prihvataju (reda od 20 do 200) cena je visoka

• pravi razliku samo između dva naponska nivoa (Vcc i masa), sve ostale signale tretira kao logičku 1 ili 0

• može da memoriše podatke (funkcija slična storage osciloskopu)

• postoje dva režima rada:

- timing: trigeruje se na promene stanja signala; - state: registruje stanje signala

• registruje promene signala na U/I portovima, sa ciljem da verifikuje izvršenja softverskih segmenata, izračunava kašnjenje od jedne promene do druge, i td. (timing mode)

• može da se trigeruje radi prihvatanja podatka u ritmu nekog taktnog signala na target ploči ili u odnosu na interni takt logičkog analizatora

• može da se trigeruje ako procesor u pojedinu sekciju u memoriji upisuje nevalidne podatke ili pristupa pojedinom tipu instrukcije (state mode)

• može da prikaže asemblerski kôd, ali ne može da postavi breakpoint ili da prisili CPU da radi u režimu single-step

• može da nadgleda samo tok eksternih podataka, a ne i internih u odnosu na CPU, memoriju ili registre

• nezavisan je od tipa CPU-a, sva nadgledanja signala se vrše u realnom vremenu

Voltmetar Meri naponsku razliku između dve tačke u kolu.

• meri pojedine naponske vrednosti • koristi se za proveru da li kolo ima napajanje

• jeftiniji je u odnosu na ostala sredstva Ommetar Meri otpornost između dve

tačke u kolu. • jeftin uređaj • meri promene struje/napon u zavisnosti od otpornosti (V=I/R)

Multimetar Meri kako naponske razlike tako i otpornosti

• izvršava iste funkcije kao volt- i om-metar

Debugger Funkcionalno razvojno

sredstvo za debugging. u opštem slučaju od debugger-a zavisi: • koji je kôd i kojoj je ciljnoj mašini namenjen radi loadovanja/aktiviranja režima rada korak-po-korak/trasiranje

• implementacija breakpoints-a koje se koriste za stopiranje izvrvšenja softvera

• implementacija uslovnih breakpoints-a koje stopiraju izvršenje softvera ako je ispunjen pojedini uslov

• mogu modifikovati sadržaj RAM-a ali ne i ROM memorije

Profiler Prikuplja timing istoriju o izabranim registrima, promenljlivama, i drugo.

• prikuplja podatke o vremensko zavisnom ponašanju izvršenja softvera

• prikuplja podatke o putevima izvršenja softvera i drugo

Softver

Monitor Debugging interfejs sličan ICE-u, pri čemu se debug softver izvršava na target i

• slično kao print-iskaz ali ima brži, manje nametljivi (intrusive), a takođe radi bolje za sof -real time krajnje rokove, a ne za

host-u. Deo monitora se nalazi u ROM-u na target ploči, a debugging kernel je na host-u. Softver na host-u i target-u obično komuniciraju preko serijskog kanala ili Ethernet-a, u zavisnosti od toga šta je instalirano na target-u.

hard real time • sličan po funkcionalnosti debugger-u (po tome što koristi breakpoints-e, dumping registre i memoriju, i td.)

• embedded operativni sistemi mogu u sebi da sadrže monitor za pojedine arhitekture

Instruction Set Simulator

Izvršavaju se na host-u i memoriji (izvršivi binarni fajlovi se loaduju u simulator na način kao kad se loaduju u target) pri čemu simuliraju ponašanje hardvera

• obično se ne izvršavaju istom brzinom kao i na realnom target-u, ali se može proceniti vreme odziva i propusnost sistema imajući u vidu razliku u brzini rada između host-a i target-a

• verifikuju asemblerski jezik sa ciljem da utvrde da ne postoje bug-ovi (greške)

• obično ne simuliraju drugi hardver koji postoji na target-u, ali omogućavaju testiranje komponenata koje su ugrađene u procesor (tajmer, PIA, i td.)

• mogu simulirati ponašanje prekida • čuvaju trag o promenljivim, memorijskim, i registarskim vrednostima

• lako je preneti kôd razvijen na simulatoru u target sistem

• precizno simuliraju ponašanje aktuelnog hardvera u realnom vremenu

• obično su pogodniji za testiranje algoritama, a ne za testiranje arhitekture na reakcije generisane od strane spoljnih događaja (misli se na talasne dijagrame)

• jeftinije su kao investicija od realnog hardvera i sredstava za razvoj

Manuelno Lako dostupni, jeftiniji od ostalih rešenja, nelicencirano korišćenje, jednostavni za korišćenje ali vidljivi za softver koji se izvršava, ne postoji dovoljno dobra kontrola nad selektovanim događajima, izolovani su, repetitivni. Postoje problemi kod debagiranja real time sistema posebno kada je vreme izvršenja manuelnih metoda suviše dugo.

Iskazi tipa print Funkcionalno debugging sredstvo. Printing iskaz se insertuje u kôd koji štampa informaciju o promenljivoj, lokaciji informacije u kôdu, itd.

• cilj je da se vidi vrednost promenljive, sadržaj registra i dr., u toku izvršenja programa

• verifikuje se segment kôda koji se izvršava

• može značajno da uspori vreme izvršenja • može uzrokovati nekorektne krajnje rokove izvršenja kod real time sistema

Dump Funkcionalno debugging sredstvo koje u toku izvršavanja programa smešta podatke na neki tip memorijskog medijuma.

• isto kao i print iskazi samo što se izvršava brže

• potrebno je da se proverava sadržaj memorije u toku izvršenja programa kako ne bi došlo do prekoračenja prostora heap-a i magacina

Brojači/Tajmeri Debugging sredstva za procenu performansi i efikasnosti, pri čemu se

• skupljaju informaciju koja se odnosi na opšti tajming izvršenja, brojeći taktne impulse, cikluse na magistrali, itd.

tajmeri ili brojači resetuju i inkrementiraju u različitim tačkama programa.

Brzo prikazivanje

Funkcionalno debugging sredstvo koje pali i gasi LED diode ili koristi LCD displej za prikaz podataka.

• slično kao print iskaz ali brže, manje vidljivo, pogodnije je za rad kod manipulisanja sa real time krajnjim rokovima

• potvrđuje da se specifični deo kôda izvršava

Izlazni portovi Funkcionalno debugging sredstvo za procenu performansi i efikasnosti pri čemu se izlazni portovi u različitim tačkama izvršenja programa postavljaju na određene vrednosti

• pomoću određenog osciloskopa ili logičkog analizatora analizira se stanje kada se izlaz porta, u toku izvršenja programa, postavi na određenu vrednost

• multitasking i multithreading sistemi dodeljuju različite portove svakom thread/zadatak sa ciljem da se proceni ponašanje sistema

5.3.3 Hardverska sredstva za debugging - struktura ICE Do skoro (kraj 90-ih godina prošlog veka) glavnni pristup u razvoju mikroprocesorskih sistema je bio baziran na ICE konceptu. Kao prvo, ciljni sistem se izvodio na štampanoj ploči na koju su se ugrađivali mikroprocesorski čip, memorija, i razne periferne komponente. Da bi se ICE mogao koristiti, mikroprocesor se vadio iz podnožja na štampanoj ploči i na njegovo mesto se postavljao header plug (konektor) koji je bio "pupčanim" putem (kablovski) povezan sa ICE opremom (vidi sliku 5.5). ICE je emulirao funkciju mikroprocesora i obezbeđivao je korisniku jedan unutrašnji uvid u interno stanje sistema, obezbeđujući pristup radi čitanja i modifikovanja ssadržaja registara procesora, memorijskih lokacija, postavljanje prekidnih tačaka, i dr. Danas kada su mikroprocesori postali samo manji deo složenih čipova pristup baziran na ICE konceptu nije više primenlljiv. Razlog je sledeći: Nemoguće je da se izdvoji deo VLSI čipa i njemu posebno pristupi (misli se na core procesora). No veći broj tehnika i pristupa testiranja dizajna koji je bio korišćen kod ICE-a zadržan je danas i kod testiranja VLSI IC-ova.

Slika 5.5. Blok dijagram emulatorsko upravljačkog sistema

ROM emulator ROM emulator čine sledeći sistemski elementi :

• kablovi sa odgovarajućim konektorima koji se mehanički povezuju na podnožje ROM komponente target sistema

• brzi RAM tipa dual port RAM zamenjuje ROM u target sistemu • lokalni upravljački procesori • komandni port (portove), za vezu sa host-om • dodatne logike kakva je trace memorija i logika za podršku rada algoritama za programiranje

fleša. Na slici 5.6a) prikazan je funkcionalni blok dijagram tipičnog ROM emulatora, a na slici 5.6b) način povezivanja ROM emulatora sa host-om i target-om.

a)

b)

Slika 5.6. ROM emulator: a) funkcionalni blok dijagram, b) šematska prezentacija Background Debug Mode (BDM) BDM kao debug interfejs prvi put je bio implementiran od strane kompanije Motorola sa familijom MC 683xx a korišćen za ColdFire familiju porcesora. Na slici 5.7, na šematskom nivou prikazano je kako se embedded sistem povezuje na host računar koristeći n-žilnu vezu sa procesorskim debug jezgrom (n-žilna veza se naziva wiggler).

Slika 5.7. n-žilno povezivanje kod BDM-a

Na ciljnoj štampanoj ploči BDM se povezuje preko 26-pinskog konektora. Raspored pinova na BDM debug interfejsu je dat na slici 5.8.

Slika 5.8. Raspored pinova kod debug interfejsa firme Motorola

Četiri bita DDATA0-DDATA3 su namenjena za prenos izlaznih debug podataka, a četiri bita PST0-PST3 ukazuju na izlazni status procesora u toku rada. Na slici 5.9 su prikazani izlazni kôdovi procesora koji se prezentiraju na pinovima PST0-PST3.

Slika 5.9. Izlazni kôdovi procesora

Skup BDM komandi koje se odnose na Motorola ColdFire procesorsku familiju su prikazani na slici 5.10.

Slika 5.10. Skup komandi BDM-a

Joint Test Action Group (JTAG) JTAG (IEEE 1149.1) protokol je evaluirao kao posledica rada koji se odnosi na testiranje štampanih ploča u industriji. JTAG je prvenstveno projektovan da zameni tradicionalni način testiranja štampanih ploča, kod složenih mašina, koji se zasnivao na konceptu korišćenja gustih polja tačaka-pristupa (nazvanih bed ili nails). Tačke pristupa kontaktiraju svaki čvor (node) na ploči (čvor predstavlja deljivu vezu između komponenata na ploči). Kod JTAG pristupa ideja je sledeća: Tester ploče povezuju sve čvorove na ploči na individualne bitove jednog dugačkog pomeračkog registra. Svaki bit odgovara jednom čvoru. Da bi JTAG bio operativan neophodno je da svako integrisano kolo bude projektovano na takav način da podrži JTAG protokol. To znači da svaki U/I pin integrisanog kola treba da sadrži (ima interno ugrađeno) pridruženi element (interfejs logiku) koja je sastavni deo JTAG lanca. Na slici 5.11 skicirana je jedna jednostavna JTAG petlja za tri elementa.

Slika 5.11. Šematski prikaz JTAG petlje za tri elementa na štampanoj ploči

Danas veliki broj mikroprocesora se fabrikuje tako da, u cilju efikasnijeg testiranja njegovog rada, ima izvedeno JTAG zasnovano debagiranje jezgra-procesora. Na slici 5.12 prikazana je jedna tipična JTAG petlja koja ilustruje kako se vrši testiranje gradivnih blokova CPU-a.

Slika 5.12. Debagiranje jezgra CPU-a zasnovano na konceptu JTAG-a

Za implementaciju JTAG-a koristi se serijski protokol, koji zahteva da relativno mali broj U/I pinova mikroprocesora podržava mogućnost debagiranja. Spisak pinova za IEEE 1149.1 (JTAG) interfejsa prikazan je na slici 5.13.

Slika 5.13. Opis pinova JTAG interfejsa

Nexus interfejs U aprilu 2001. godine organizacija IEEE je donela preporuke pod nazivom IEEE-ISTO-5001. Ovaj standard je uveo nekoliko novih koncepata koji se tiču debagiranja embedded procesora. Prvi se odnosi na proširljivost (scalability). Kompatibilnost u radu procesora i standarda se može ostvariti na nekoliko nivoa usklađivanja. Prvi nivo se odnosi na jednostavne run kontrolne komande. Svaki naredni nivo uvodi veći broj mogućnosti, ali, za implementaciju, zahteva od procesora veći broj pinova. Na najnižem nivou usklađivanja Nexus koristi JTAG protokol (IEEE 1149.1) kao standardni protokol. Na slici 5.14 prikazana je osnovna struktura Nexus interfejsa.

Slika 5.14. Nexus interfejs

Treba naglasiti da se skalabilnost interfejsa proteže od osnovne run-control mogućnosti do dinamičkog debugging-a, tj. mogućnosti trasiranja kod rada u realnom vremenu. Logički analizator Kada projektant želi da ustanovi šta, u realnom vremenu, radi procesor, a da pri tome ne izvrši neke značajne dorade u hardveru embedded sistema, tada je svrsishodno da kao debugging sredstvo koristi logički analizator. U suštini, logički analizator je veoma moćno sredstvo koje se koristi za ispitivanje rada digitalnih sistema. Logički analizator može da radi u sledeća dva režima rada: timing i state. U režimu rada timing, interna visoka-frekvencija rada logičkog analizatora (> 400 MHz → 2.5 ns period uzorkovanja), određuje kada će se u memoriji logičkog analizatora prihvatiti slika o stanju procesora, ili procesora i drugih digitalnih kola sistema. Standardno logički analizator ima veći broj ulaznih sondi (od 20 do 200) koje se koriste za prihvatanje ulaznih signala. Sa periodom uzorkovanja od 2.5 ns, memorija obima 200 bitova, i dubine 106 stanja (lokacija), za slučaj da procesor radi na frekvenciji od 100 MHz, moguće je da se prihvate 250 000 ciklusa procesora na magistrali. Prikaz informacije koju logički analizator pribavlja vrši se na CRT displeju. Jedan tipičan prikaz dat je na slici 5.15.

Slika 5.15. Prikaz logičkog analizatora koji se odnosi na pojednostavljeni vremenski dijagram za 32-bitni

mikroprocesor U režimu rada state, logički analizator koristi takt procesora da bi uzorkovao stanje signala. To znači da svaki put kada taktni signal CPU-a ima prelaz sa niskog na visoko, logički analizator uzorkuje stanje na pinovima i upisuje to stanje u memoriju analizatora. U ovom slučaju relativna timing informacija između signala se gubi, ali se mogu videti vrednosti tih signala. Najveći broj logičkih analizatora, kao softverske pakete ima dostupno disasemblere. Disasembler je u stanju da redukuje broj snimljenih signala od strane logičkog analizatora i da ih prikaže na displeju u tabelarnoj formi kao mnemonike instrukcija na asemblerskom jeziku, adresne infomacije, čitanje operanada ili upis, prikaz specijalne statussne informacije (kakvi su ciklusi instrukcija za obradu prekida), i drugo. Na slici 5.16 ilustrovan je jedan primer prezentacije podataka od strane logičkog analizatora kada ovaj radi u state režimu rada, a odnosi se na trasiranje izvršenja kod procesora iz familije Motorola MC68K.

Slika 5.16. Prikaz na ekranu kada logički analizator radi u režimu state

5.4 Softverska utility razvojna sredstva Izvorni kod se obično piše korišćenjem razvojnih sredstava kakva su standardni ASCII tekst editor ili IDE (Integrated Development Environment). Ovaj tip razvojnog sredstva je lociran na host-ovoj platformi (vidi sliku 5.17).

Slika 5.17. IDE

IDE predstavlja skup razvojnih sredstava, uključujući i ASCII tekst editor, integrisanih u jedinstveni aplikaciono-korisnički interfejs. U principu, bilo koji ASCII tekst editor može se koristiti za pisanje bilo kog kôda, nezavisno od jezika i platfome. Sa druge strane, IDE je specifično sredstvo za datu platformu, koje nudi proizvođač i u najvećem broju slučajeva sastavni je deo ponude proizvođača, kakav je slučaj sa starter kit-om (čine ga hardverska ploča i IDE), operativnim sistemom (MS Windows ili Linux), ili programskim jezikom (Visual C). 5.4.1 Translation razvojna sredstva Hardverske komponente u okviru embedded sistema mogu direktno da prenose, memorišu, i izvršavaju mašinski kôd, koji je osnovni jezik koga čine logičke jedinice i nule. Kao jezik, mašinski kôd je bio korišćen u ranijoj fazi računarskih sistema (negde 50-ih godina prošlog veka). Pisanje programa ovakvim načinom kôdiranja je bilo veoma teško i podložno brojnim greškama. sa ciljem da se programiranje učini efikasnijim učinjen je pokušaj da, mašinski kôd bude vidljivijji programeru, što je izvedeno putem kreiranja hardversko-specifičnog skupa instrukcija, nazvan asemblerski jezik. Tokom vremena, drugi programski jezici, kakvi su C, C++, Java i td. su evoluirali. Osnovna karakteristika ovih jezika, koje nazivamo višim programskim jezicima, je ta da poseduju hardversko-nezavisne skupove instrukcija, semantički su nezavisne od mašine, i podsećaju na jezike koje koriste ljudi. S obzirom da je mašinski jezik jedini jezik koga hardver može direktno da izvršava, svim ostalim jezicima je potreban neki tip mehanizma pomoću koga bi oni bili u stanju da generišu odgovarajući mašinski kôd. Ovaj mehanizam obično predstavlja kombinaciju preprocesiranja, translation (prevođenje) i interpretacije. U zavisnosti od jezika, translation mehanizmi postoje (instalirani su i izvedeni) na host sistemu (obično je to non-embedded razvojni sistem kakva je PC mašina ili neka radna stanica) ili na ciljnom sistemu (embedded sistem koji se razvija), kao što je to prikazano na slici 5.18.

Slika 5.18. Host-target sistemski dijagram

Preprocesiranje je opcioni korak koji postoji pre translation i interpretacije izvornog kôda, i čija se funkcionalnost standardno implementira od strane preprocesora. Zadatak preprocesora je da organizuje i restruktuira izvorni kôd sa ciljem da učini translation i interpretaciju kôda lakšim. Tako na primer, kod jezika kakvi su C i C++ , preprocesor omogućava da se koriste imenovani kôdni fragmenti, kakvi su makroi. Makroi obezbeđuju da se pojednostavi razvoj programa dozvoljavajući da se u programu koriste macro-imena pomoću kojih se zamenjuju fragmenti kôda. U toku preprocesiranja, preprocesor zamenjuje macro-ime sa sadržajem makroa. Preprocesor može da postoji kao poseban entitet, ili da bude integrisan u okviru translation ili interpretatorske jedinice. Najveći broj jezika konvertuje izvorni kôd, bilo direktno ili nakon preprocesiranja, pomoću kompajlera na pojedini ciljni jezik (vidi sliku 5.19).

Slika 5.19. Dijagram kompilacije

Kod embedded sistema, kompajleri su obično locirani u host mašini, a generišu ciljni kôd za hardversku platformu koja se razlikuje od platforme na kojoj se kompajler izvršava. Ovakve kompajlere nazivamo kros-kompajleri. Kada je reč o asemblerskom jeziku, kompajler je, u suštini, specijalizovani kros-kompajler koji se naziva asembler, i on uvek generiše mašinski kôd. Kod viših programskih jezika kompajleru se obično pridružuje ime jezika, kakav je slučaj sa C-kompajlerom, Java-kompajlerom i td. Nakon što se na host mašini kompilacija završi, generiše se objektni fajl. Objektni fajl se zatim linkuje (povezuje) sa bibliotečnim sistemskim fajlovima u jedinstveni fajl koji se standardno naziva executable (izvršivi binarni fajl). Executable se nakon toga loaduje u memoriju ciljnog embeddedi sistema (vidi sliku 5.20) uz pomoć loadera.

Slika 5.20. Koraci kompilacije/linkovanja objektnog fajla za slučaj programskog jezika C

Jedna od osnovnih karakteristika translation procesa se zasniva na konceptu razmeštaja softvera (nazvan object placement), sposobnost da se softver podeli na module i da se moduli kôda i podataka smeste u memoriji tamo gde je to potrebno. Ova karakteristika je od izuzetne važnosti kod embedded sistema iz sledećih razloga:

1. embedded dizajn karakteriše nekoliko različitih tipova fizičke memorije, 2. u odnosu na računare opšte namene iznos memorije kod embedded sistema je ograničen, 3. memorija je obično izrazito fragmentirana (podeljena), i 4. određeni tipovi (delovi) embedded softvera se često izvršavaju iz pojedinih delova memorije.

Softver za razmeštanje kôda i programa u memoriji embedded računara može da bude sastavni deo: a) host-a, generišući pri tome specijalizovane instrukcije koje se koriste za generisanje "poziciono nezavisnog kôda"; ili b) može biti sastavni deo softverskih translation razvojnih sredstava. U oba slučaja, ova mogućnost zavisi od toga da li asembler/kompajler može da: i) procesira samo apsolutne adrese (početna adresa je fiksirana od strane softvera pre nego što asembler procesira kôd); ili ii) koristi relativno adresiranje, tj. početna adresa kôda se može specificirati kasnije, prevedeni moduli su relokatibilni, a razmeštaj softvera se obavlja od strane linkera. Kod IDE, procesori, kompajleri i linkeri se nalaze u host razvojnom sistemu, neki jezici, kakav je Java ili neki script jezici, imaju kompajlere ili interpretere koji su locirani u target-u. Interpreter generiše mašinski kôd prevodeći liniju po liniju izvornog kôda ili ciljnog kôda (vidi sliku 5.21).

Slika 5.21. Dijagram interpretacije

5.5 Softverska sredstva za debugging - struktura Debugger Debugger-i kod embedded sistema sastoje se od sledeće dve celine: a) deo debugger-a koji se nalazi u host-u; i b) deo debugger-a koji se nalazi u target sistemu. Oba elementa debugger-a međusobno komuniciraju preko komunikacionog kanala, kakav je onaj koji se reallizuje preko serijskog RS-232 ili Ethernet porta. Deo debugger-a koji se nalazi u target-u naziva se target agent ili debug kernel, a deo koji je instaliran u host-u se naziva debugger front end ili GUI. Ključni zadaci koje obavlja debugger su sledeći:

• postavlja breakpoint-e • loaduje programe od host-a • nadgleda ili modifikuje sadržaj memorije ili registra • startuje izvršenje programa od određene adrese • uslovljava da procesor radi u režimu rada korak-po-korak

Debug kernel (ili target agent) zahteva da target poseduje sledeća dva resursa: vektor prekida i softverski prekid. Na slici 5.22 prikazan je način integracije debugger-a sa target kôdom.

Slika 5.22. Debug kernel target sistema

Vektor prekida serijskog porta (pod uslovom da se komunikacija između host-a i target-a obavlja po ovom kanalu) uslovljava da procesor počne da izvršava ISR serijskog porta, koja je u suštini ulazna tačka u debugger. Nakon ovoga prelazi se na izvršenje debug kernel-a, što znači da se prelazi na upravljanje radom sistema. Prekidna tačka Prekidna tačka (breakpoint) je debugging mehanizam (hardverski ili softverski), koji stopira CPU da izvrši kôd. Da bi razumeli kako se breakpoint postavlja, na određeno mesto u programu, analiziraćemo sliku 5.23.

Slika 5.23. Prekidne tačke (breakpoints)

Neka u programu kreiranom na asemblerskom jeziku, korisnik na određenoj instrukcijskoj lokaciji u RAM prostoru želi da postavi breakpoint. Zahtev za breakpoint se aktivira na host baziranom delu debugger-a, pa se adresa te instrukcije u memoriji šalje debug kernel-u u target-u. Debug kernel kopira instrukciju sa te lokacije na sigurno mesto i zamenjuje je sa softverskim breakpoint-om, ili trap instrukcijom. Kada izvršenje programa stigne do breakpoint-a upravljanje se prenosi na debugger. Na ovaj način moguće je: a) izvršavati program korak-po-korak; b) izvršavati program do breakpoint-a bez prekida; i c) testirati softver kontunualno komutirajući izvršenje između debugger-a i programa koji se testira. Veoma često programeri žele da debagiraju program na C ili C++, a ne na asembleru. Obično se to izvodi na sledeći način: Još u fazi prevođenja programa potrebno je dozvoliti debugging opciju putem postavljanja (setovanja) debug switch-a. Na ovaj način se preko debugger-a i debug kernel-a definiše na kojoj će se lokaciji breakpoint postaviti u memoriji. U slučajevima kada softverski breakpoint mehanizam nije moguć, moraju se koristiti hardverski mehanizmi. Veliki broj procesora ima ugrađeno specijalne breakpoint registre koji se mogu direktno programirati pod softverskom kontrolom, ili preko JTAG i BDM portova. Ovi registri obezbeđuju jednostavnu, ali veoma efikasnu mogućnost za debagiranje. Postavljanjem odgovarajuće adrese u breakpoint registar, kada procesor pribavlja instrukciju sa te adrese, aktivira se breakpoint mehanizam i ulazi u debugging. 5.6. Uvod u kompajlere Programski jezici su notacije koje se koriste za opis izračunavanja koja se obavljaju od strane mašine. Pre nego što program treba da se pusti u rad on mora da se prevede u oblik koji je prihvatljiv za izvršenje od strane mašine. Softverski sistemi koji obavljaju ovo prevođenje nazivaju se kompajleri. Kompajler je program koji čita program na jednom jeziku - izvorni jezik - i prevodi ga u ekvivalentni program na drugi jezik - ciljni jezik - (vidi sliku 5.24).

Slika 5.24. Kompajler

Ako je ciljni program izvršivi mašinsko-jezički program on se može pozvati od strane korisnika sa ciljem da procesirsa ulazne podatke i generiše izlazne (vidi sliku 5.25.).

Slika 5.25. Izvršenje ciljnog programa

Interpreter je jedan drugi standardni tip jezičkog procesora. Umesto da nakon prevođenja generiše ciljni program, interpreter direktno izvršava specificirane operacije izvornog programa nad ulaznim podacima koji se dostavljaju od strane korisnika (vidi sliku 5.26).

Slika 5.26. Interpreter

Java jezički procesori kombinuju kompilaciju i interpretaciju (vidi sliku 5.27). Izvorni program na Javi se prvo prevodi u među-formu koju nazivamo bajtkôd. Bajt-kôdovi se zatim interpretiraju od strane virtuelne mašine. Prednost ovog pristupa je ta da se bajt-kôdovi kompajliraju na jednoj mašini, a interpretiraju na drugoj.

Slika 5.27. Hibridni kompajler

Pored kompajlera, postoji i nekoliko drugih programa koji su potrebni za kreiranje izvršivog ciljnog programa (vidi sliku 5.28).

Slika 5.28. Programi potrebni za kreiranje izvršivog programa

5.6.1 Struktura kompajlera Kao što smo prethodno napomenuli, kompajleri mogu da preslikaju izvorni program u semantički ekvivalentni ciljni program. Preslikavanje se može podeliti na sledeća dva dela: a) analiza - deli izvorni program na delove i nad njima primenjuje gramatička pravila, tj. kreira strukturu. Ova struktura se koristi zatim za kreiranje među-kôdne prezentacije (intermediate code presentation) izvornog programa. Analiza prikuplja informaciju o izvornom programu i memoriše je u strukturu nazvanu simbol-tabela. Analiza se često naziva front-end. b) sinteza - na osnovu među-kôdne prezentacije i simbol-tabele ovaj deo kompajlera generiše ciljni program. Sinteza pripada back-end procesiranju kompajlera. Faze kompajlera prikazane su na slici 5.29.

Slika 5.29. Faze kompajlera

5.6.2 Leksička analiza Prva faza kompajlera se naziva leksička analiza ili skeniranje. Leksički analizator čita niz karaktera izvornog programa i grupiše karaktere u smisaone nizove (nizove kojji imaju određeno značenje) koje nazivamo lexeme. Za svaki lexeme leksički-analizator kao izlaz generiše token (znak) koji je sledećeg oblika <token-ime, atribut-vrednost> gde je: token-ime - apstraktno ime koje se koristi u toku sintaksne analize atribut-vrednost - ukazujr na ulaz (entry) u simbol-tabelu za taj token. Informacija sa ulaza (entry) simbol-tabele je potrebna radi semantičke analize i generisanja-kôda. Neka izvorni program sadrži sledeći iskaz dodele: position = initial + rate ∗ 60 (1) Karakteri ovog iskaza se mogu grupisati u lexeme i preslikati u sledeće token-e, a zatim predati sintaksnom analizatoru: 1. position je lexeme koji se može preslikati u token <id,1>, gde je id apstraktni simbol koji se odnosi na identifikator (identifier), a 1 ukazuje na ulaz u simbol-tabelu za position. Ulaz simbol-tabele identifikatora čuva informaciju o identifikatoru, informacija se odnosi na ime i tip. 2. Simbol dodele = je lexeme koji se preslikava u token <=>. S obzirom da ovom token-u nije potrebna atribut-vrednost, izostavlja se druga komponenta token-a. 3. initial je lexeme koji se preslikava u token <id,2>, gde 2 ukazuje na ulaz simbol-tabele za initial. 4. + je lexeme koji se preslikava u token <+>. 5. rate je lexeme koji se preslikava u token <id,3>, gde 3 ukazuje na ulaz simbol-tabele za rate. 6. ∗ je lexeme koji se preslikava u token <∗>. 7. 60 je lexeme koji se preslikava u token <60>. Blanko karakteri koji razdvajaju lexeme se izbacuju od strane leksičkog analizatora. Na slici 5.30 prikazana je prezentacija iskaza dodele definisanog jednačinom (1) nakon leksičke analize i predstavljena kao niz token-a. <id,1> <=> <id,2> <+> <id,3> <∗> <60> (2) Kod ove prezentacije, imena token-a =, + i ∗ su apstraktni simboli za operatore dodela, sabiranje i množenje, respektivno.

Slika 5.30. Prevođenje iskaza dodele

5.6.3 Sintaksna analiza Druga faza kompajlera predstavlja sintaksna-analiza ili parsing. Parser (rasčlanjivač) koristi prve komponente token-a generisanih od strane leksičkog analizatora kako bi kreirao među-prezentaciju tipa-stablo kojom se opisuje gramatička struktura token niza. Kod tipične prezentacije sintaksnog-stabla (syntax-tree) svaki unutrašnji čvor predstavlja operaciju, a naslednik čvor odgovara argumentima operacije. Stablo prikazuje redosled obavljanja operacija kod dodele position = initial + rate ∗ 60 Stablo ima unutrašnji čvor označen kao ∗, sa <id,3> kao svoj levi naslednik i integer 60 kao desni naslednik. Čvor <id,3> odgovara identifikatoru rate. Čvor označen sa ∗ eksplicitno ukazuje da moramo prvo pomnožiti vrednost rate sa 60. Čvor označen sa + ukazuje da moramo sabrati rezultat ovog množenja sa vrednošću initial. Koren stabla, označen sa =, ukazuje da moramo smestiti rezultat sabiranja u lokaciju identifikatora position. Uređenje operacija je konzistentno sa aritmetičkim konvencijama koje nam ukazuju da množenje ima prioritet u odnosu na sabiranje, pa zbog toga množenje treba da se obavi pre sabiranja. Naredne faze komapjlera koriste gramatičku strukturu koja je od pomoći kod analize izvornog programa i generisanja ciljnog programa. 5.6.4 Semantička analiza Semantički analizator koristi sintaksno stablo i informaciju koja se čuva u simbol-tabeli kako bi proverio izvorni program radi semantičke konzistentnosti sa definicijom jezika. Ovaj analizator prikuplja informaciju o tipovima token-a (int, float, boolean, ...) i smešta tu informaciju bilo u sintaksno-stablo, bilo u simbol-tabelu, sa ciljem da bi se ta informacija u narednim fazama koristila za generisanje među-kôda. Važni deo semantičke analize predstavlja aktivnost type-checking, u toku koje kompajler proverava da li svaki operator koristi uparene operande. Tako na primer, može da se ostvari sabiranje samo integer sa integer vrednošću, a ne integer sa floating point vrednošću, itd. Specifikacija jezika može da dozvoli da se ostvari neki tip konverzije koju nazivamo coercions. Tako na primer, binarni aritmetički operator se može aplicirati bilo na par integer-a, ili na par floating-point operatora. Ako se operator primenjuje na floating-point broj i na integer tada kompajler mora da konvertuje (coerce) integer u floating-point broj. Ovaj tip konverzije se javlja na slici 5.30. Ako su position, initial, i rate deklarisani kao floating-point brojevi, a lexeme 60 kao integer tada type-checker u semantičkom analizatoru otkriva da operator ∗ treba da se primeni na floating-point broj rate i integer 60. Zbog ovoga integer se mora konvertovati u floating-point. Kao posledica izlaz semantičkog analizatora ima dodatni čvor za operator inttofloat koji eksplicitno konvertuje integer argument u floating-point broj. 5.6.5 Generisanje među-kôda U toku procesa prevođenja izvornog programa u ciljni kôd, kompajler može da generiše jednu ili veći broj među (intermediate) prezentacija, koje mogu imati veći broj formi. Sintaksna-stabla (syntax trees) predstavljaju formu među-prezentacije, i ona se standardno koriste u toku sintaksne i semantičke analize. Nakon sintaksne i semantičke analize izvornog programa veliki broj kompajlera generiše eksplicitno među-prezentaciju niskog-nivoa ili mašinskkog-nivoa, koja se može smatrati kao problem za apstraktnu mašinu. Ovakvu među-prezentaciju karakterišu sledeće dva važne osobine: a) treba da je laka za generisanje; b) treba da je laka za prevođenje na kôd ciljne mašine.

U konkretnom slučaju smatraćemo da se koristi tro-adresna mašina pa će zbog toga svaka prividno-asemblerska instrukcija koristiti tri operanda po instrukciji. Svaki operand može da predstavlja registar. Izlaz generatora među-kôda sa slike 5.30 čini sledeća tro-adresna kôdna sekvenca: t1=inttofloat(60) t2=id3∗t1 t3=id2+t2 id1=t3 (3) Treba pri ovome, kada se govori o tro-adresnim instrukcijama, istaknuti sledeće:

1) Svaka tro-adresna instrukcija dodele ima najmanje jedan operator na desnoj strani. Na ovoj strani instrukcije fiksiraju redosled po kome operacije moraju da se obave, kao na primer, množenje prethodi (prioritetnije je) operaciji sabiranja u izvornom programu (jed. (1)).

2) Kompajler mora da generiše privremena imena za čuvanje vrednosti koje se izračunavaju od strane tro-adresnih instrukcija.

3) Neke od tro-adresnih instrukcija, kakve su prva i zadnja u jednačini (3), imaju manje od tri operanda.

5.6.6 Optimizacija kôda Mašinsko-nezavisna kôdno-optimizaciona faza ima za cilj da poboljša među-kôd tako da se generiše bolji ciljni-kôd. Obično pojam bolji se odnosi na brži, no često i drugi ciljevi mogu biti od važnosti kakvi su kraći kôd, kôd koji rezultira manjoj potrošnji energije, i dr. Tako na primer, na izlazu generatora, za dati slučaj, dobija se izlaz definisan jednačinom (3). Ako se na među-kôd (jednačina (3)) primeni algoritam za optimizaciju-kôda, dobiće se oblik t1=id3∗60.0 id1=id2+t1 (4) U konkretnom slučaju kompajler zaključuje da se konverzija 60 u floating-point može obaviti samo jedanput i to u toku faze kompilacije tako da se operacija inttofloat može eliminisati a integer 60 zameniti sa floating-point broj 60.0. Šta više i t3 se koristi samo jedanput za predaju svoje vrednosti ka id1. U principu, postoji veći broj optimizacija koje kompajler može da obavi. 5.6.7 Generisanje kôda Generator kôda prihvata kao ulaz među-kôd izvornog programa i preslikava ga u jezik ciljne mašine. Ako je ciljni jezik mašinski-kôd za svaku od promenljivih u programu selektuju se registri ili memorijske lokacije. Nakon toga, instrukcije na među-kôdu prevode se u sekvence mašinskih instrukcija koje obavljaju isti zadatak. Ključni aspekt generisanja kôda se odnosi na razumno (optimalno) dodeljivanje registara radi čuvanja promenljivih. Tako na primer, korišćenje registara R1 i R2, među-kôd definisan jednačinom (4), se može prevesti u sledeći mašinski kôd: LDF R2,id3 MULF R2,R2,#60.0 LDF R1,id2 ADDF R1,R1,R2 STF id1,R1 (5) Prvi operand svake instrukcije specificira odredište. Slovo F u svakoj instrukciji ukazuje da se manipuliše sa floating-point brojevima.

5.6.8 Upravljanje simbol tabelom Jedna od važnih funkcija kompajlera ogleda se u vođenju evidencije imena promenljivih koje se koriste u izvornom programu, kao i prikupljanju informacije o različitim atributima svakog imena. Ovi atributi mogu pružiti informaciju o alociranoj memoriji datom imenu, tipu promenljive, oblasti važenja (scope) i za slučaj imena procedura treba da pamte broj i tip argumenata, način predaje svakog argumenta (po vrednosti ili po referenciranju), kao i tip povratne vrednosti (rezultata). Simbol-tabela je struktura podataka koja sadrži zapis za svako ime promenljive, sa odgovarajućim poljima za svako ime. 5.7 Linker Linkovanje je proces sakupljanja i kombinovanja različitih delova kôda i podataka u jedinstveni fajl koji se može load-ovati (kopirati) u memoriju i izvršavati. Linkovanje se može obaviti na sledeće načine:

a) u fazi kompilacije - kada se izvorni kôd prevodi u mašinski kôd b) u fazi punjenja - kada se program load-uje u memoriju i izvršava od strane loader-a c) u trenutku izvršenja - od strane aplikacionih programa.

Linkeri imaju ključnu ulogu u razvoju softvera jer oni dozvoljavaju (omogućavaju) rad tehnici nazvanoj separate compilation. Umesto da se velike aplikacije organizuju kao jedan monolitni izvorni fajl, moguće je razložiti takav fajl na manje, upravljivije module, koji se mogu modifikovati i kompajlirati kao posebni. Kada treba da se promeni samo jedan od ovih modula, tada je neophodno da se rekompajlira samo taj modul, a zatim da se on relinkuje sa aplikacijom bez da se rekompajliraju ostali fajlovi. Na slici 5.31 prikazan je standardni razvojni proces softvera, kao i mesto linkera u tom procesu.

Slika 5.31. Proces razvoja softvera

Glavni razlozi zbog kojih projektanti treba dobro da poznaju osobine linkera su sledeći: 1) poznavanje linkera omogućava lakše kreiranje velikih programa, 2) razumevanje linkera olakšava izbegavanje opasnih programskih grešaka, 3) razumevanj elinkera omogućava nam da se lakše razume način na koji se implementiraju jezička

pravila (kao na primer, razlika između globalnih i lokalnih promenljivih), 4) razumevanje linkovanja omogućava lakše razumevanje drugih važnih sistemskih komponenata

kakvi su punjenje i izvršenje programa, virtuelna memorija, straničenje, i memorijska mapa, 5) razumevanje linkova dozvoljava da se koriste deljive biblioteke.

Na slici 5.32 prikazano je, sa nešto više detalja u odnosu na sliku 5.31, kako različita sredstva prihvataju različite ulazne fajlove i generišu odgovarajuće izlazne fajlove koji se zatim koriste za građenje izvršivog image fajla.

Slika 5.32. Kreiranje izvršivog image fajla za ciljni sistem

Programer obično kreira izvorne programe na: a) nekom višem programskkom jeziku, kakav je C ili C++; i b) asemblerskom jeziku. Izvorni programi se kao fajlovi (često nazvani izvorni fajlovi) sa odgovarajućim ekstenzijama (.c, za programe kreirane na C-u, ili .asm, za programe kreirane na asemblerskom jeziku) smeštaju na disku. Dodatno, programer može da kreira i makefile koji se koristi za potrebe sleđenja modifikacije fajlova u toku rada.

Na osnovu izvornih fajlova kompajler i asembler generišu objektne fajlove koji sadrže: 1) mašinski binarni kôd; i 2) programske podatke. Arhiva koju čini skup bibliotečnih programa dopunjava kolekciju objektnih fajlova (ovi fajlovi se čuvaju kao bibliotečni). Linker prihvata objektne fajlove kao ulaze i generiše executable image ili objektni fajl koji se može kasnije koristiti za dodatno linkovanje sa drugim objektnim fajlovima. Komandni fajl linkera daje instrukcije linkeru na koji način da kombinuje objektne fajlove i gde da smešta binerni kôd i podatke u ciljnom embedded sistemu. Glavna funkcija linkera je da kombinuje veći broj objektnih fajlova u jedinstveni veći relokatibilni objektni fajl, deljijvi objektni fajl, ili konačno executable image. Kod jednog tipičnog programa, deo kôda u jednom izvornom fajlu može da referencira promenljive (obraća se promenljivama) definisanim u drugom izvornom fajlu. Takođe, funkcija iz jednog izvornog fajla može da pozove funkciju u drugom izvornom fajlu. Globalne promenljive i ne-statičke funkcije standardno nazivamo globalni simboli. U izvornim fajlovima, ovim simbolima se dodeljuju različita imena, kao na primer, globalna promenljiva se može zvati foo-bar, a globalna funkcija func_a. Kod konačne izvršive binarne image, simboli ukazuju na adresu memorijske lokacije. Sadržaj ove memorijske lokacije može da predstavlja vrednost (podatak) promenljive, ili izvršivi kôd funkcije. Kompajler kreira simboličku-tabelu koja čuva simbolička-imena. Simbolička-imena ukazuju na adresna preslikavanja između izvornog i objektnog fajla. U trenutku kreiranja relokatibilnog izlaza, kompajler, za svaki simbol generiše adresu koja je relativna u odnosu na fajl koji se komapajlira. Saglasno tome, ove adrese se generišu u odnosu na ofset 0. Simbol-tabela sadrži globalne simbole definisane u fajlu koji se kompajlira, kao i eksterne simbole koji se referenciraju (kojima se obraćamo) u fajlu, a koje linker treba da razreši. Proces linkovanja koga obavlja linker čine i aktivnosti simbol-rezolucija i simbol-relokacija. Simbol-rezolucija je proces u toku koga linker prolazi kroz svaki objektni fajl, i za taj objektni fajl određuje u kojim su još drugim objektnim fajlovima definisani eksterni simboli koji se u njemu javljaju. Ponekad linker mora da procesira listu objektnih fajlova veći broj puta, sa ciljem da razreši sve eksterne simbole. Ako su eksterni simboli definisani u statičkoj biblioteci, linker kopira objektne fajlove iz biblioteke i upisuje ih u konačni image fajl. Simbol-rezolucija predstavlja proces u toku koga linker preslikava referenciranje simbola u definiciju simbola. Linker modifikuje mašinski kôd linkovanih fajlova tako da se kôdna referenciranja simbolima odnose na aktuelne dodele adresa tim simbolima. Za veliki broj simbola, dolazi do promena u relativnim ofset adresama iz razloga što se veći broj objektnih fajlova ujedinjuje u jedinstven. Simbol-rezolucija zahteva da se izvrši modifikacija kôda iz razloga što linker podešava referenciranja ovih simbola u mašinskom kôdu na takav način da ona ukazuju na njihove konačne adrese. Relokaciona tabela ukazuje linkeru gde u programskom kôdu da izvede akciju relokacije. Svaki ulaz u relokacionu tabelu sadrži referenciranje na simbol tabelu. Koristeći ovo referenciranje, linker može da izbavi aktuelnu adresu simbola i da je dodeli lokaciji u programu kao što je to specificirano od strane ulaza u relokacionu tabelu. U suštini, relokaciona tabela može da čuva adresu simbola, kao i informaciju o podatku na tom ulazu. U tom slučaju ne postoji referenciranje između relokacione tabele i simbol tabele. Na slici 5.33 prikazan je odnos, u pojednostavljenom obliku, između simbol tabele i relokacione tabele.

Slika 5.33. Odnos između simbol tabele i relokacione tabele

Za izvršivu image, sva referenciranja koja se odnose na eksterne simbole moraju biti razrešena. Naime, pošto je izvršiva image spremna za izvršenje svaki simbol mora da ima svoju apsolutnu memorijsku adresu. Jedini izuzetak od ovog pravila su oni simboli koji su definisani u deljivim bibliotekama (ovi simboli mogu da imaju relativne adrese koje se konačno dodeljuju u fazi izvršenja programa (dinamičko linkovanje)). Relokatibilni objektni fajlovi mogu da sadrže nerešene eksterne simbole. Slično biblioteci, relokatibilni fajl generisan od strane linkera predstavlja spoj većeg broja objektnih fajlova sa jednom razlikom - referenciranja su delimično razrešena, a ovaj fajl se može dalje koristiti za linkovanje sa drugim objektnim fajlovima radi kreiranja izvršive image, ili drugog deljivog fajla. 5.7.1 Linkovanje u odnosu na loadovanje Linkeri i loaderi obavljaju nekoliko sličnih ali konceptualno različitih akcija. Na osnovu akcija koje oni preuzimaju ukazaćemo na to kakva razlika postoji između ova dva programa.

• Loadovanje programa - se odnosi na kopiranje programa iz sekundarne memorije (kakav je disk) u glavnu memoriju radi njegovog izvršenja. U nekim slučajevima loadovanje se odnosi samo na jednostavno kopiranje podataka sa diska u memoriju, a u drugim situacijama uključuje alokaciju (dodelu) memomrijskog prostora, postavljanje bitova zaštite, ili uslkađivanje koje se odnosi na to da virtuelna memorija obavlja preslikavanje virtuelnih adresa na disk-stranice.

• Relokacija - kompajleri i asembleri u opštem slučaju kreiraju fajlove objektni kôd, kod kojih programske adrese počinju od 0. Naglasimo da sammo mali broj računara dozvoljava da se programi loaduju u računar počev od nulte adrese. Ako kreirani program čini veći broj potprograma, tada svi potprogrami se moraju loadovati na ne-preklapajućim adresama. Relokacija predstavlja proces dodele load-adresa različitim delovima programa i podešavanja kôda i podataka u programu da oni budu u skladu sa dodeljenim adresama. Kod najvećeg broja sistema relokacija se izvodi veći broj puta. Uobičajena je praksa da linker kreira program na osnovu većeg broja potprograma, kao i da kreira jedan linkovani izlazni program koji startuje od adrese 0, pri čemu su različiti potprogrami relocirani na različitim lokacijama u okviru velikog programa. Nakon toga program se loaduje u mašinu, pri čemu (operativni) sistem definiše aktuelnu load-adresu, pa se linkovani program u celosti relocira (početno pozicionira) na load adresu.

• Simbol rezolucija - kada je program sastavljen od većeg broja potprograma za sva referenciranja (obraćanja) od strane jednog potprograma ka drugom se koriste simboli; tako na primer, glavni program može da koristi rutinu kvadratni koren sqrt, a matematička biblioteka da definiše sqrt

u biblioteci, kao i da usmeri poziv u objektnom kôdu pozivnog programa na takav način da call instrukcija u pozivnom programu referencira lokaciju sqrt-a u pozvanom programu.

Na osnovu prethodne diskusije, eviddentno je da postoji značajno preklapanje između prethodne tri nabrojane aktivnosti koje se odnose na linkovanje i loadovanje. Ipak, nezavisno od svega, program koji obavlja loadovanje se zove loader, a onaj koji rešava probleme vezane za simbol-rezoluciju predstavlja linker. Oba programa, linker i loader, obavljaju relokaciju. Veoma često proizvođači kao jedinstveni (integrisani) proizvod nude program linkage-loader koji ujedinjuje sve tri pomenute funkcije. 5.7.2 Executable i linking formati Kompajleri i asembleri kreiraju objektne fajlove koji sadrže: j) generisani binarni kôd, i jj) podatke za izvorni fajl. Linkeri kombinuju veći broj objektnih fajlova u jedinstveni fajl, dok loaderi prihvataju objektne fajlove i loaduju ih (pune) u memoriju. Objektni fajlovi sadrže sledećih pet osnovnih tipova informacije:

1. Header informaciju - čuva osnovne tipove informacija o objektnom fajlu kakve su: obim kôda i podataka, ime izvornog fajla od koga je kreiran taj objektni fajl, i datum kreiranja.

2. Objektni kôd - ovaj kôd odgovara mašinsko-arhitekturno-specifičnim binarnim instrukcijama i podacima generisanih od strane kompajlera ili asemblera.

3. Informacija o relokaciji (relokaciona tabela) - predstavlja listu mesta u objektnom kôdu koje treba urediti u trenutku kada linker promeni adrese objektnog kôda.

4. Simboli (simbol tabela) - ova tabela sadrži: a) globalne simbole koji su definisani u tom modulu kao i simbole koje treba importovati od drugih modula; ili b) simbole definisane od strane linkera.

5. Debugging informacija - čuva se informacija o objektnom kôdu koja nije od koristi za potrebe linkovanja, ali je od koristi debugger-u. Informacija se odnosi na broj linije u izvornom fajlu, lokalne simbole, i opis strukture podataka koje se koriste od strane objektnog kôda, kakve su definicije struktura na programskom jeziku C.

Način na koji se ova informacija organizuje u objektnom fajlu naziva se objektni fajl format. U principu objektni fajl/fajlovi treba da ima/imaju sledeće osobine:

i) linkable - da se koristi kao ulaz od strane link editor-a ili linkage loader-a, ii) executable - da bude u stanju da se loaduje u memoriju i izvršava kao program iii) loadable - da bude u stanju da se loaduje u memoriju kao bibliotečni program zajedno sa

programom, iv) da predstavlja kombinaciju bilo koje prethodne tri stavke.

Neki od formata podržavaju jednu stavku, drugi dve, a treći sve tri. To znači da između različitih proizvođača kompajlera, asemblera, linkera i debugger-a ne postoji opšti konsenzus o jedinstvenom formatu. Glavna prednost jedinstvenog formata bi bila interoperabilnost, tj. mogućnost da projektant izabere kompajler firme A, a zatim generiše objektni kôd koristeći linker firme B, kako bi formirao executable image. Objektni kôd se često deli na manje logičke segmente koji se na različite načine tretiraju od strane linkera. Danas projektanti koriste različite formate objektnih fajlova kakvi su, na primer, DOS COM fajlovi, DOS EXE fajlovi, Unix a.out fajlovi, Unix ELF fajlovi, COFF (Common object file format), IBM 360 Object Format, Microsoft Portable Executable Format, Intel/Microsoft OMF fajlovi, i drugi. Nabrojani fajlovi su međusobno nekompatibilni, tako da projektant kada bira sredstva za projektovanje svog embedded sistema, uključujući i debugger, mora odabrati takvo sredstvo koje će razumeti sve formate objektnih fajlova sa kojima će se on koristiti u toku razvoja sistema. Mi ćemo se, u daljem tekstu, koncentrisati na Unix ELF (Executable and Linking Format) fajlove, iz prostog razloga što njih projektanti embedded sistema najčešće koriste.

5.7.3 ELF objektni fajl format Postoje sledeća tri tipa različitih ELF fajlova:

1. relocatable - kreiraju ih kompajleri i asembleri, ali pre izvršenja potrebno je da budu procesirani od strane linker-a.

2. executable - imaju izvedenu relokaciju i razrešena su obraćanja svim simbolima sa izuzetkom simbola iz deljive-biblioteke koja se moraju razrešiti u toku izvršenja programa.

3. shared object (deljivi objekti) - predstavlljaju deljive bibliotečne fajlove koji u sebi čuvaju kako informaciju o simbolima koja je od koristi linkeru, tako i direktno izvršivi kôd.

ELF fajl format, vidi sliku 5.34, ima dve različite interpretacije.

Slika 5.34. Dva pogleda na ELF fajl; executable i linking format

Kompajleri, asembleri, i linkeri trertiraju fajl kao skup logičkih sekcija opisanih od strane section header table, dok sistem-loader tretira fajl kao skup segmenata koji su opisani od strane program header table. Jedan segment obično čini nekoliko sekcija. Tako na primer, loadable read onlyI segment može da sadrži sekcije tipa executable code, read-only data, i simbole za potrebe dinamičkog linker-a. Relocatable fajlovi sadrže section tabele, executable fajlovi imaju program header tabele, a shared objects i jedno i drugo. Sekcije su namenjene za dalje procesiranje od strane linker-a, dok su segmenti namenjeni za preslikavanje (mapiranje) u memoriju. Svi ELF fajlovi startuju sa ELF header-om (vidi sliku 5.35). Header (zaglavlje) je tako projektovan da se može dekôdirati, šta više i od mašina koje koriste različito bajt uređenje (Little Endian

ili Big Endian). Prva četiri bajta predstavljaju magični broj kojim se identifikuje ELF fajl, zatim slede tri bajta pomoću kojih se opisuje format ostatka header-a. Nakon što je program pročitao markere class i byteorder, on zna redosled bajtova i obim fajla u rečima, pa stoga može da obavi neophodnu byte-swapping aktivnost kao i size-conversion. Ostala polja sadrže informaciju o obimu i lokaciji section header-a i program header-a za slučaj da su oni prisutni.

Slika 5.35. ELF header 5.7.4 Mapiranje executable image-a u target embedded sistem Nakon što je veći broj izvornih fajlova (C/C++ ili asemblerskih fajlova) kompajlirano ili asemblirano u ELF objektne fajlove, linker mora da kombinuje ove objektne fajlove i sjedini sekcije različitih fajlova u programske segmente. Ovim procesom se kreira jedinstvena executable image za target embedded sistem. Da bi uspešno kombinovali sekcije i alocirali segmente u target sistem, projektanti koriste linker komande koje se alternativno nazivaju linker direktive. Linker direktive se predaju preko linker command fajla. 5.7.5 Linker command fajl Format linker-command fajla nije standardizovan i razlikuje se od linkera do linkera. Nezavisno od svega, najveći broj linkera podržava sledeće dve direktive: MEMORY i SECTION. Direktiva MEMORY se koristi da opiše memorijsku mapu target sistema. Memorijska mapa lista različite tipove memorija (ROM, RAM, fleš) koje egzistiraju u target sistemu, zajedno sa opsegom adresa koje se koriste za memorisanje i izvršenje executable image-a. Projektanti embedded sistema treba da su familijarni sa adresibilnom fizičkom memorijom target sistema pre nego što kreiraju linker-command fajl. Na slici 5.36 prikazana je jedna memorijska mapa jednostavnog target embedded sistema.

Slika 5.36. Pojednostavljena šema memorijske mape target sistema

Linker kombinuje ulazne sekcije koje imaju isto ime u jedinstvenu ulaznu sekciju sa tim imenom. Projektant često želi da naredi linkeru gde da preslika ove sekcije, ili drugim rečima, koje adrese da koristi linker kako bi obavio simbol-rezolucije. Da bi se ovo ostvarilo projektanti embedded sistema koriste direktivu SECTION. Direktiva MEMORY definiše tipove fizičkih memorija koje postoje u ciljnom (target) sistemu, kao i adresne opsege koje zauzima svaki fizički memorijski blok, koristeći sledeću sintaksu

Kod primera sa slike 5.36 postoje sledeća tri memorijska bloka:

• ROM čip koji se preslikava u adresni prostor na lokaciji 0, obima 32 bajta, • FLASH memorija koja se preslikava u adresni prostor na lokaciji 0x40, obima 4096 bajtova, • blok RAM koji startuje od adrese 0x10000 i obima je 65536 bajtova

Prevođenje ove memorijske mape u MEMORY direktivu je prikazano u Listingu 5.1. Imenovane oblasti su ROM, FLASH i RAM.

Listing 5.1. Memorijska mapa Direktiva SECTION ukazuje linkeru koje ulazne sekcije treba kombinovati u koju izlaznu sekciju, zatim koje izlazne sekcije zajedno grupisati i alocirati u kontinualnu memoriju, nakon toga gde smestiti svaku sekciju, kao i druge informacije. Opšta notacija komande SECTION je data Listingom 5.2.

Listing 5.2. SECTION komanda Kod ilustrativnog primera prikazanog na slici 5.37 egzistiraju tri default sekcije (.txt, .data, i .bss), kao i dve sekciej koje su specificirane od strane projektanta (loader i my_section), koje su sastavni deo dva objektna fajla generisana od strane kompajlera ili asemblera (file1.0 i file2.0).

Slika 5.37. Kombinovanje ulaznih sekcija u executable image

Komanda SECTION u linker command fajlu naređuje linkeru da kombinuje ulaznu sekciju my_section i default .txt sekcije iz svih objektnih fajlova u konačnu izlaznu .txt sekciju. Sekcija loader-a se smešta u fleš memoriju. Sekcije .txt, .data, i .bss se zajedno grupišu i dodeljuju (alociraju) kontinualnoj fizičkoj RAM memoriji, koja je poravnjana na granici od četiri bajta (vidi sliku 5.38).

Slika 5.38. Mapiranje executable image u target sistem

5.7.6 Mapiranje executable image Postoji veći broj razloga zbog kojih projektant embedded sistema želi sam da definiše gde da smesti ciljne memorijske oblasti. Ukažimo na ključne: Nadgradnja modula - U prethodnim poglavljima smo ukazali na različite opcije memorisanja programa i nadgradnje softvera kod embedded sistema. Softver se može nadgraditi ako se upiše u non-volatile memoriju, kakva je keš. Nadgradnja softvera se može izvesti: a) download-ovanjem nove programske image preko serijske veze sa host-om ili preko mreže; i b) reprogramiranjem fleš memorije. Loader je tipičan primer ovakve jedne aplikacije. Inicijalna verzija loader-a može da prenese image od ROM-a ka RAM-u. Novija verzija loader-a treba da je u stanju da prenese image od host-a preko serijske veze u RAM. Iz pomenutog razloga kôd loader-a i sekciju podataka treba kreirati u custom loader sekciju. Celu sekciju treba nakon toga programirati u fleš memoriju kako bi se u budućnosti mogla nadograditi. Ograničenje obima memorije - Target sistem obično ima ugrađeno različite tipove fizičke memorije, ali svaka ograničenog obima. Ponekad nije moguće sav kôd i podatke smestiti u jedan tip memorije, na primer u SDRAM. S obzirom da SDRAM ima brži pristup od DRAM-a, uvek je poželjno preslikati kôd i podatke u SDRAM. No, dostupan fizički SDRAM može biti nedovoljno veliki za čuvanje celokupne informacije, a sa druge strane da je u sistem instalirano dovoljno DRAM-a. Zbog toga, strategija se sastoji u sledećem: Program se deli na veći broj sekcija, pri čemu se deo sekcija dodeljuje SDRAM-u, a deo DRAM-u. Tako na primer, onaj deo kôda koji se najčešće izvršava ili za čije se izvršenje troši najviše vremena se smešta u SDRAM, a ostatak kôda i podataka se alocira DRAM-u. Zaštita podataka - U programima se obično koriste različiti tipovi konstanti, kakve su integer konstante i string konstante. Ponekad se ove konstante čuvaju u ROM prostoru kako bi se izbegla njihova neželjena modifikacija. Kod ovakvog slučaja, ove konstante pripadaju specijalnoj sekciji za podatke, koja se alocira u ROM-u.