Embedded Systems Chapter 4 Razvojno okruenje Razvojna sredstva

Embedded Systems - Chapter 4 -

Razvojno okruženje Razvojna sredstva savremenih računara opšte namene kakve su PC mašine (desktops) koriste veoma složene tehnike za prevođenje programa kreiranih na nekim od HLL-ova. Pri tome u najvećem broju slučajeva izvorni kôd se direktno prevodi u binarni image-oblik koji se zatim load-uje u mašinu radi izvršenja. Sa druge strane, projektanti embedded sistema ne mogu da koriste ovakve beneficije iz nekoliko razloga. Kao prvo, embedded sistem se skoro uvek bazira na jedinstvenom (specifičnom) hardveru, hardver koji u suštini ne postoji (ne egzistira kao takav) kada se razvijalo razvojno sredstvo. Kao drugo, uprkos prednosti kojom se karakteriše procesor ugrađen u razvojno sredstvo, ipak postoji neznatna razlika u mašinskim jezicima između izabranog procesora i procesora ugrađenog u razvojnom okruženju, nezavisno od toga što oba procesora pripadaju istoj familiji (procesori Intel 286, 186, 288, 188, i td. ).

Radno okruženje Pored dobrog poznavanja ISA (Instruction Set Architecture) tj. procesora, da bi se kreirao efikasan embedded kôd, projektantu je dodatno potrebno da dobro poznaje i sledeće detalje: 1) na koji način sistem koristi memoriju, uključujući i detalje koji se odnose na to na koji način procesor manipuliše magacinom, 2) šta se dešava pri startup sistema, i 3) na koji način se manipuliše sa prekidima i izuzecima? Da bi ukazali, sa nešto više detalja, na ove probleme analilziraćemo rad jednog tipičnog embedded sistema zasnovanog na procesorima iz familije Motorola 68000 (68 K).

Organizacija memorije Ø Prostor namenjen sistemu Ø Prostor namenjen programu Ø Prostor namenjen podacima • magacin • slobodan memorijski prostor • heap Ø Nezauzeti memorijski prostor Ø Ulazno/izlazni prostor

Startup sistema Startup sekvencu čine sledeće dve faze: v hardverska faza - aktiviranjem linije RESET procesor izvršava hardversku fazu. Namena ovog dela startup-a je da usmeri CPU da počne sa izvršenjem programa ili nekog drugog kôda koji će preneti upravljanje programu. v softverska faza - odgovorna je za inicijalizaciju hardverskih elemenata kao i ključnih struktura podataka u memoriji.

Ciklus odziv-na-prekid 1) Kako CPU zna gde da pronađe kôd (tj. početnu adresu) prekidne rutine? 2) Koje akcije CPU treba da preuzme kako bi zapamtio, a kasnije i obnovio "kontekst" glavnog thread-a? 3) Kada treba dozvoliti rad prekidima?

Aktivnosti CPU-a u toku prekida • smešta adresu naredne instrukcije prekinutog programa (povratnu adresu) u magacin, • puni početnu adresu (vektor) ISR-a (Interrupt Service Routine) iz vektorske tabele u programski brojač, • zabranjuje rad drugim prekidima, • nastavlja sa normalnim ciklusima tipa fetch-execute, ali u ovom trenutku pribavlja instrukcije koje pripadaju ISR-u, i • na kraju izvršenja ISR-a povratak iz prekidnog programa (ISR) u prekinuti vrši se naredbom RTE (return from exception).

Potprogrami i šematski prikaz asemblersko-jezičkog potprograma

Run-time okruženje čine sve softverske strukture (nisu eksplicitno kreirane od strane programera) koje podržavaju izvršenje programa. Struktura koja povezuje okvire-magacina se može smatrati kao deo run-time okruženja. Za programere na C-u druge dve glavne komponente koje čine run-time okruženje su startup kôd i run-time biblioteka.

Startup kôd je softver koji premošćava vezu između hardverske startup faze i programa main(). Softver za premošćavanje treba da se izvrši pri svakom RESET-u, i minimalno, treba da prenese upravljanje programu main(). Trivijalna implementacija startup-a može da predstavlja asemblersko-jezički fajl koga čini samo sledeća instrukcija: JMP _main

Run-time biblioteka Najrestriktivnija definicija run-time biblioteke je sledeća: To je skup nevidljivih funkcija koje se koriste za podršku rada sistema kojim se pojednostavljuje generisanje kôda. Tako na primer, ako mašina ne poseduje hardver za podršku rada FP operacija, tada kompajler generiše poziv aritmetičkoj rutini koja je deo run-time biblioteke, svaki put kada se izvršava FP operacija. Smatrajmo da su rutine standardne C biblioteke deo run-time biblioteke. Eliminacijom funkcija run-time biblioteke koje se ne koriste, moguće je značajno redukovati obim programskog kôda kod embedded sistema. Takođe je moguće neke složene implementacije smanjiti uvođenjem prostih.

Run-time biblioteka – prod. Optimizacije (minimizacije obima kôda) se uobičajeno odnose na sledeće stavke: 1) Podrška radu FP operacijama – ako ne postoji podrška za rad FP operacijama tada proizvođač kompajlera može da ponudi fixed-point biblioteku koja se može direktno pozivati. 2) Podrška radu formatiranom izlazu (printf()) – umesto potpune podrške printf() funkciji, proizvođač može da ponudi funkcije za formatiranje specifičnih tipova kakve su, na primer, print. Int. As. Hex(), print. Str(), i druge. 3) Podrška radu dinamičkoj alokaciji (ovo se odnosi na malloc() i funkciju HLL-a C++ kakva je new) – kako će projektant primeniti dinamičku alokaciju zavisi od mnogo faktora, a ne samo od dostupnog memorijskog prostora i hardverske podrške. U principu se dinamička alokacija ne koristi kod embedded sistema.

Razmeštanje objekata Projektanti embedded sistema treba da su u stanju da upravljaju fizičkom pozicijom (lokacijom) kôda i podataka u memoriji. Linker je primarno sredstvo (tool) koje se koristi za upravljanje razmeštajem kôda. U opštem slučaju, asembler kreira relokatibilne module koje linker "fiksira" na specifične fizičke adrese.

Razvojni model embedded softvera

Deo kôda na asemblerskom jeziku mikroprocesora iz familije Motorola 68 K

Relokatibilni moduli (fajlovi) referenciraju (obraćaju se) funkcije u drugim modulima. Pored podešavanja internih referenciranja na aktuelne lokacije, linker je takođe zadužen za rešavanje ovih inter-modularnih referenciranja kao i kreiranje kôdnog bloka koji se može load-ovati na specifičnu lokaciju (memorijsku adresu) sistema. Kao zaključak bi mogli da kažemo sledeće: 1) Relokatibilni moduli su važni iz više razloga. Ono što je najvažnije je to da prgramerima embedded sistema, relokatibilni moduli pojednostavljuju fizički razmeštaj kôda generisanog od strane HLLa, i omogućavaju individualnim modulima da se nezavisno ažuriraju i kompajliraju. 2) Kod sistema opšte-namene, relokatibilni moduli imaju tu dobru stranu da pojednostavljuju upravljanje memorijom (omogućavajući individualnim programima da se pune u bilo koju dostupnu memorijsku sekciju (deo) bez rekompilacije), kao i da olakšavaju korišćenje deljivih, unapred rekompajliranih biblioteka.

Korišćenje linkera Ulazi u linker su: a) relokatibilni objektni moduli; i b) komandni fajl linker-a. Komandni fajl linker-a pruža projektantu mogućnost da u potpunosti kontroliše na koji će se način kôdni moduli međusobno povezati i kako se kreira konačna slika. Komandni fajl linker-a je ključni elemenat u ovom procesu i važan je diferencijator u odnosu na to kako se piše kôd za embedded sisteme ili kôd za desktop PC-ove, kao mašine opšte namene.

Korišćenje linkera – prod. Linker-i koriste programske sekcije. Programska sekcija predstavlja kôdni-blok ili blok-podataka koji je logički različit u odnosu na druge sekcije i može se opisati svojim sopstvenim lokacionim brojačem. Sekcije imaju različite atribute koji ukazuju linker-u kako se ti atributi mogu koristiti. Tako na primer, sekcija može biti: • kôd programa • kôd podataka • mešavima kôda i podataka • podaci smešteni u ROM-u

Primer komandnog fajla linker-a

Komande linker-a