Laboratorul 1

1. Prezentarea instrumentelor software folosite

1.1. Compilatorul Code Warrior

CodeWarrior este un mediu integrat de dezvoltare produs de compania
Freescale. CodeWarrior permite realizarea aplicatiilor pentru sisteme de operare ca
Windows, Linux, Solaris dar si pentru sisteme incorporate. Compilatoarele de C/C++
reprezinta cele mai importante instrumente software din cadrul CodeWarrior, desi
unele versiuni au inclus si compilatoare pentru alte limbaje de programare (Pascal,
Java).
In cadrul laboratorului sunt folosite compilatorul si link-editorul de ANSI-C/C++
din pachetul CodeWarrior. Executabilele acestora sunt localizate in:
D:\IP2\Tools\s12.45\Prog\chc12.exe
D:\IP2\Tools\s12.45\Prog\linker.exe
Desi compilatorul si link-editorul prezinta interfete grafice, ele vor fi lansate in
mod linie de comanda pe parcursul procesului automat de compilare si link-editare al
sistemului de operare.

1.2. Cygwin
Cygwin este un instrument software pentru Windows ce permite dezvoltarea
de aplicatii intr-o maniera asemanatoare cu cea din Linux. Cygwin va fi folosit pentru
a executa echivalentele unor comenzi Linux in sistemul de operare Windows.
Cygwin este folosit doar pe parcursul procesului automat de compilare. Nu
este nevoie de nici o interactiune a utilizatorului pentru configurarea acestui
enviroment astfel incat procesul de copilare sa functioneze!
Comanda cea mai importanta ce va fi folosita este comanda “make”. Ea este
foarte utila atunci cind se lucreaza cu proiecte ce contin multe fisiere si exista
dependente intre diferitele fisiere sursa. Aceasta comanda se bazeaza pe utilizarea
fisierelor makefile si permite lansarea procesului automat de compilare. Comanda
make va fi apelata in cadrul laboratorului cu urmatorii parametri posibili:
make - compileaza modulele application si bootloader
make application - compileaza modulul application
make bootloader – momentan inactiv
make clean - sterge toate fisierele obiect si fisierele .abs
make application clean - sterge fisierele obiect si .abs ce tin de appl.
make bootloader clean – momentan inactiv

application si bootloader reprezinta argumente pe care le primeste fisierul

“make.bat” ce este executat.
Este important sa se faca diferenta intre comanda make pusa la dispozitie de
Cygwin si fisierul de tip batch intitulat make.bat. Fisierul make.bat lanseaza
interpretorul de comenzi Linux din Cygwin “bash” cu argumentul “./make
application”. De abia in acest moment utilitarul “make” instalat in directorul Cygwin
preia controlul procesului de compilare.
 1.3. Sistemul de operare OSEK
Sistemul de operare OSEK se afla localizat in directorul d:\IP2. Pentru a
intelege mai usor modul in care se configureaza sistemul de operare, modul in care
se realizeaza o aplicatie precum si cum lucreaza intrumentele software folosite in
configurarea sistemului, este necesara intelegerea structurii de directoare precum si
a modului in care fisierele sunt organizate.
Structura de directoare a sistemului de operare este prezentata in figura.

• BMWStandardCore.lnk – lansarea in
executie a acestui fisier creaza o mapare
temporara pe discul „Z” a intregii structuri de
directoare a sistemului de operare; acest
lucru este necesar pentru a minimiza calea
de cautare a fisierelor in procesul de
compilare, restrictia fiind impusa de utilizarea
aplicatiei Cygwin.
• AC_CONTI – contine toate fisierele care pot fi modificate de catre utilizator;
• src.bat – configureaza caile de acces la compilatorul folosit (CodeWarrior), la
Cygwin si la Java;

Structura de directoare a directorului tools este prezentata in figura.

• proosek_configurator – permite
configurarea kernelui sistemului de operare;
• geny_configurator – permite configurarea
driverului de CAN (definirea mesajelor care
pot fi trimise/receptionate, functii de
callback asociate mesajelor etc.);

Structura de directoare a directorului AC_CONTI este prezentata in figura.

• application – in acest director

utilizatorii pot dezvolta aplicatia dorita;
• board – contine definitii specifice
procesorului;
• bootloader – este folosit pentru
reprogramarea aplicatiei folosind doar
modulul de CAN;
• build – este locatia in care sunt
stocate fisierele .abs rezultate in urma
compilarii si a link-editarii;
 Structura de directoare a directorului application este prezentata in figura.

• source – contine fisierele de baza ale

aplicatiei.
• config – contine 2 directoare:
o generators – pastreaza fisierele de
configurare ale tuturor resurselor
hardware (EEPROM, CAN) si software
(KERNEL OS) folosite de utilizator in
aplicatii;
o modules – este folosit pentru a
configura ce module urmeaza sa fie
compilate si incluse in modulul aplicatie;
• generated – contine toate fisierele generate automat de aplicatiile de configurare
ale sistemului de operare;

2. ProOSEK
2.1. Nucleul ProOSEK
Nucleul ProOSEK reprezinta o implementare a standardului sistemului de
operare OSEK/VDX-OS. ProOSEK este format din ProOSEK Configurator si o
structura data de directoare si fisiere. Structura data de directoare si fisiere a fost
prezentata pe scurt in unul din laboratoarele anterioare. In acest laborator, precum si
in laboratoarele urmatoare va fi prezentat ProOSEK Configurator si modul in care
acesta poate fi folosit pentru a dezvolta aplicatii folosind nucleul ProOSEK.
Procesul de dezvoltare al unei aplicatii este prezentat in figura.
 2.2. ProOSEK Configurator
ProOSEK Configurator reprezinta principalul instrument folosit in procesul de
dezvoltare al unei aplicatii, el permitand configurarea sistemului de operare
corespunzator cerintelor aplicatiei. Zona marcata din Fig.1 pune in evidenta rolul
aplicatiei ProOSEK Configurator si interactiunea acestuia cu sistemul de operare.
In prima faza obiectele necesare din sistem sunt specificate si configurate. In
faza a doua, fisierele sistemului de operare ProOSEK sunt generate si pot fi link-
editate impreuna cu fisierele sursa ale aplicatiei. ProOSEK Configurator este format
din ProOSEK Graphical Configurator si System Generator.
ProOSEK Graphical Configurator permite editarea in mod grafic a tuturor
obiectelor din sistemul de operare precum si incarcarea sau salvarea configuratiilor
in formatul OIL (OSEK Implementation Language).
System Generator (Generatorul sistemului de operare) implementeaza
urmatoarele operatii:
• verificarea consistentei configuratiei;
• calculul necesarului de memorie RAM pentru memorarea structurii
de date a sistemului;
• generarea nucleului ProOSEK pe baza configuratiei (os.h si os.c);
• generarea fisierului os.orti, fisier ce poate fi folosit in procesul de
depanare de WinIDEA sau alte aplicatii asemanatoare;
• generarea unui model de aplicatie.
System Generator este integrat in ProOSEK Configurator dar poate fi apelat si
in mod linie de comanda. Acest lucru permite integrarea generarii sistemului in
procesul make, lucru prezentat in laboratorul anterior.
ProOSEK Configurator poate fi lansat in executie prin rularea fisierului
ProOSEK.bat din directorul D:\IP2\OSEK\tools\proosek_configurator. Figura
prezinta interfata grafica a aplicatiei.

Fisierul de configurare folosit este xdp512_application.oil din directorul

D:\IP2\OSEK\AC_CONTI\application\config\generators\proosek. Acest fisier pune
la dispozitia utilizatorului o configurare predefinita a sistemului de operare. Utilizatorul
poate folosi aceasta configuratie sau o poate modifica, in functie de cerintele
aplicatiei.
 Odata fisierul de configurare incarcat, in bara de stare (localizata in partea de
jos a ferestrei aplicatiei) sunt afisate informatii despre sistemul tinta pentru care se
realizeaza configurarea sistemului de operare precum si numele fisierului OIL ce este
modificat.

In partea din stinga a aplicatiei poate fi selectat modul in care configuratia

sistemului va fi afisata: la nivel de obiect sau la nivel de fisier.
In cazul in care configuratia sistemului este afisata la nivel de obiect, vor fi
afisate toate tipurile de obiecte disponibile pentru sistemul tinta. Selectarea unuia
dintre tipurile de obiecte va determina afisarea tuturor obiectelor de acel tip definite in
fisierul OIL (figura stanga). Crearea unui nou obiect de un anumit tip se poate face
prin selectarea tipului de obiect cu butonul dreapta al mouse-ului (figura dreapta).

Un fisier de configurare poate fi impartit in mai multe fisiere OIL. In cazul

sistemelor mari, cu multe obiecte definite, acest lucru ajuta la intelegerea sistemului
respectiv si usureaza procesul de configurare. Configurarea unui sistem poate fi
astfel realizata prin intermediul unui fisier .oil si a mai multor fisiere .oil_objects. In
cazul in care configuratia sistemului este afisata la nivel de fisier, toate fisierele de
configurare vor fi afisate impreuna cu obiectele ce sunt definite in ele.
Odata creat sau modificat un fisier OIL, configurarea sistemului trebuie
verificata daca este completa si consistenta. Aceasta verificare se starteaza prin
 apelarea optiunii Verify din meniul
Tools. Rezultatele verificarii
(verificare realizata cu success sau
eventuale erori) sunt afisate intr-o
fereastra de tip dialog.
Generarea fisierelor sistemului
de operare corespunzatoare
configuratiei specificate prin
intermediul fisierului .oil se poate
realiza prin apelarea optiunii
Generate OS din acelasi menu Tools
sau in modul linie de comanda pe
parcursul procesului make.
Fisierele sistemului vor fi
generate in directorul setat prin
apelarea optiunii Set generation
path… din meniul Tools. In cadrul laboratorului, acest director va fi
Z:\AC_CONTI\application\generated.

Inainte de a se genera fisierele sistemului de operare se va realiza maparea

pe discul Z a intregii structuri de directoare a sistemului de operare prin startarea
fisierului BMWStandardCore.lnk din directorul OSEK. Pe langa fisierele os.c si os.h
va fi creat si fisierul os.cnf, fisier ce contine o descriere statica a sistemului. Acest
fisier este utilizat si in generarea fisierului os.orti, atunci cind este cazul.
 3. Obiectul OS
ProOSEK Configurator reprezinta principalul instrument folosit in procesul de
dezvoltare al unei aplicatii, el permitand configurarea sistemului de operare
corespunzator cerintelor aplicatiei.
Intr-un sistem poate exista un singur obiect de tip OS, obiect ce este definit tot
cu ProOSEK Configurator. Se poate observa ca nu sunt permise operatiunile de
creare sau duplicare obiect de tip OS.

Cele mai importante attribute ale obiectului OS sunt prezentate mai jos:
• MICROCONTROLLER – indica tipul de microcontroller folosit din familia
S12X;
• S12X_REALTIMECLOCK – indica daca este folosita facilitatea de ceas de
timp real si ce canal de timp este utilizat pentru acest scop;
• S12X_XGATE_INIT – indica nucleului sistemului de operare daca sa
initializeze modulul XGATE;
• S12X_XGATE_VECTORTABLE – indica faptul ca trebuie generata o tabela a
vectorilor de intreruperi si pentru modulul XGATE;
 • S12X_MEMORY_MODEL – indica modelul de memorie folosit. Pentru S12X
este folosit de obicei modelul “Banked”.
• S12X_ISR_NESTING – indica cum si daca se pot imbrica intreruperile;
• CC – este un atribut specific pentru ProOSEK. Indica ce tipuri de task-uri vor fi
folosite.
• SCHEDULE – este un atribut specific pentru ProOSEK. Specifica tipul de
planificare folosita.
• USERMAIN – indica faptul ca se doreste a se defini rutina main() in cadrul
aplicatiei utilizator si ca nu va fi continuta in mod predefinit de nucleul
sistemului generat.
• STARTUPHOOK – indica faptul ca aplicatia va contine o functie numita
StartupHook() ce va fi apelata automat la pornirea sistemului.
• PRETASKHOOK – indica faptul ca aplicatia va contine o functie
PreTaskHook() ce va fi apelata de fiecare data cand un task este planificat.
Nucleul sistemului de operare va contine referiri la aceasta functie ce va trebui
definite de utilizator in cadrul aplicatiei.
• USERESSCHEDULER – indica faptul ca utilizatorul doreste sa utilizeze
resursa predefinita RES_SCHEDULER. Achizitionarea acestei resurse
determina dezactivarea planificatorului.
• ISR1SYMBOLNAME – indica forma numelor alocate intreruperilor din
categoria 1in C. Daca parametrul are valoarea TRUE, numele intreruperii in C
va fi xx si nu OSEKOS_ISR1_xx.

Toate atributele obiectului OS sunt obligatorii. Pentru mai multe detalii despre
atributele obiectului OS consultati notitele de curs.

4. Obiectele de tip TASK

4.1. Definirea task-urilor in ProOSEK Configurator
ProOSEK Configurator este folosit si pentru definirea obiectelor de tip TASK
din sistem.
Lista task-urilor definite in sistem poate fi afisata in ProOSEK Configurator prin
selectarea tipului de obiect TASK atunci cind vizualizarea configuratiei este la nivel
de obiecte. In partea dreapta vor fi afisate toate obiectele de tip TASK cu atributele
lor.

Editorul de task-uri permite modificarea atributelor pentru un obiect de tip

TASK nou creat sau creat anterior.
 Atributele generale ale unui obiect de tip TASK sunt:

• Name – numele obiectului de tip TASK; valoarea acestui atribut este unica;
• Type – acest atribut este specific sistemului ProOSEK. Atributul Type indica
modul in care se comporta task-ul. Acest atribut poate avea 2 valori posibile:

BASIC – task-ul nu poate astepta aparitia unor evenimente;

EXTENDED – task-ul poate astepta aparitia unor evenimente;
• Priority – Acest atribut are ca valoare un numar intreg ce defineste prioritatea
task-ului in procesul de planificare. O valoare mai mare a acestui atribut indica
o prioritate mai mare a task-ului. Acest argument nu poate avea valori
negative.
• Activation – indica numarul maxim de activari ale task-ului premise in coada.
Valoare 1 indica faptul ca este permisa o singura activare. Acest argument nu
poate lua valori negative sau nule.
• Schedule – indica daca task-ul poate fi interupt sau nu din executie. Valorile
posibile sunt:

NON – task-ul nu poate fi intrerupt.

FULL – task-ul poate fi intrerupt.
• Stacksize – specifica dimensiunea in octeti a stivei necesare acestui task.
Sistemul adauga automat spatiu suplimentar pentru apelul functiilor de sistem
(ActivateTask si TerminateTask).
• Callscheduler – acest atribut indica daca functia Shedule() va fi apelata sau
nu pe parcursul task-ului. Daca acest lucru nu este cunoscut, atributul va avea
valoarea DON’T KNOW.
Toate atributele prezentate mai sus sunt obligatorii. Daca unul dintre aceste
atribute nu a fost definit, procesul de verificare din ProOSEK Configurator va genera
o eroare.

Pe linga sectiunea GENERAL, ProOSEK pune la dispozitie si sectiunile

prezentate mai jos. Pentru fiecare sectiune este posibila adaugarea, stergerea si
duplicarea unui obiect din lista prezenta in sectiunea respectiva.

ACCESSORs – sectiune ce specifica toate mesajele accesate de task. Printre

cele mai importante atribute sunt numele mesajului (MESSAGE) si modul in care
este accesat mesajul (este primit sau trimis)(ACCESSOR). Aceasta sectiune va fi
explicata in detaliu in unul dintre laboratoarele urmatoare.
 RESOURCEs – sectiune ce indica lista de resurse accesate de task. Aceasta
lista trebuie sa contina toate resursele utilizate de task.

EVENTs – sectiune ce indica lista de evenimente pentru un task extins.

Aceasta lista trebuie sa contina toate evenimentele la care task-ul apeleaza
serviciul WaitEvent().
 AUTOSTART – sectiune ce indica daca un task este lansat in cadrul
procedurii de pornire a sistemului sau nu. In cazul in care este bifata casuta task-ul
va intra automat in starea ready pe parcursul pornirii sistemului pentru fiecare mod
de lucru indicat in lista. Modurile de lucru sunt definite ca obiecte de tip APPMODE.

4.2. Servicii ProOSEK specifice task-urilor

Serviciile ProOSEK specifice task-urilor au fost prezentate la curs. Mai jos
sunt prezentate succinct aceste servicii. Pentru mai multe detalii, consultati notitele
de curs.
• DeclareTask(TaskType TaskID)
o macrou ce declara un task
o poate fi folosit in afara task-urilor, intreruperilor si a functiilor

• ActivateTask(TaskType TaskID)
o activeaza un task
o poate fi apelata de la nivel de task sau de ISR

• TerminateTask(TaskType TaskID)
o Termina executia unui task
o poate fi apelata doar de la nivel de task

• ChainTask(TaskType TaskID)
o termina task-ul current si activeaza task-ul identificat de TaskID
o poate fi apelata doar de la nivel de task
 • GetTaskID(TaskRefType TaskID)
o returneaza identificatorul task-ului activ la momentul respective
o poate fi apelata de la nivel de task, de ISR sau din rutinele
PreTaskHook(), PostTaskHook() si ErrorHook()

• GetTaskState(TaskType TaskID, TaskStateRefType State)

o returneaza starea task-ului in variabila State
o poate fi apelata de la nivel de task, de ISR sau din rutinele
PreTaskHook(), PostTaskHook() si ErrorHook()

4.3. Definirea task-urilor in cadrul aplicatiei

Pentru fiecare task declarat in ProOSEK Configurator trebuie adaugate
urmatoarele linii de cod in fisierul applmain.c.

Exemplu:
DeclareTask(Task_1s); // se declara task-ul
si
TASK(Task_1s) // se defineste task-ul
{

(void)TerminateTask();
}

Este evident ca functia TerminateTask() poate fi inlocuita cu ChainTask() daca

se doreste aceasta functionalitate.
Modificarile suplimentare ce trebuie facute in fisierul applmain.c in cazul task-
urilor ce sunt startate de alarme vor fi prezentate intr-o sedinta de laborator
urmatoare.

5. Lucrul in laborator

5.1. Obtinerea fisierului application.abs

Pentru a starta procesul automat de compilare, trebuie parcurse urmatoarele
etape:
a. Se realizeaza maparea pe discul „Z” a intregii structuri de directoare a
sistemului de operare. Pentru aceasta trebuie startat fisierul BMWStandardCore.lnk
din directorul OSEK. Acest fisier porneste interpretorul “cmd.exe” si apoi lanseaza
in executie fisierul “src.bat”.
Dupa cum am prezentat anterior, fisierul src.bat configureaza caile de acces
la compilatorul folosit (CodeWarrior), la Cygwin si la Java. Daca aceasta etapa a fost
efectuata cu success, va fi afisat mesajul “ready” (Fig.9).
 Fig.9

b. Se va schimba directorul de lucru in AC_CONTI. In acest director se afla

fisierele necesare startarii procesului de compilare cu comanda make.
Z:\> cd AC_CONTI

c. Pentru a intelege mai bine efectele comenzilor make application si make

clean
• se verifica existenta fisierelor .abs in directorul AC_CONTI\build
si a fisierelor obiect in directorul AC_CONTI\application\object;
• se lanseaza comanda make clean;
• se verifica disparitia fisierelor obiect din directorul
AC_CONTI\application\objec;
• se verifica disparitia fisierului application.obj din directorul
AC_CONTI\build;

d. Se starteaza procesul automat de compilare a aplicatiei cu comanda make.

Z:\AC_CONTI> make application
Cu aceasta comanda o serie de actiuni automate sunt executate. Aceste
actiuni vor fi discutate in laboratoarele urmatoare. In urma acestei comenzi, directorul
AC_CONTI\application\object vor fi create fisierele obiect iar in directorul
Z:\AC_CONTI\build va fi creat fisierul application.abs, fisier ce va fi incarcat in
memoria microcontroller-ului.

5.2. Incarcarea fisierelor .abs in memoria microcontroller-ului, rularea si

depanarea aplicatiei
Nucleul de OSEK disponibil in laborator este proiectat sa fie format din doua
fisiere cu extensia .abs: application.abs si bootloader.abs. Dat fiind ca
programatoarele pot incarca un singur fisier .abs, secventa de operatiuni necesara
incarcarii fisierelor aplicatiei precum si depanarii si rularii acesteia sunt urmatoarele:
1. Se unesc fisierele application.sx si bootloader.sx din directorul
AC_CONTI\build prin apelul programului merge.bat din directorul
D:\IP2\Tools. In urma unirii fisierelor se va obtine fisierul Project.sx in
directorul AC_CONTI\build.
2. Pentru incarcarea, rularea si depanarea aplicatiei va fi folosit programul True-
Time Simulator and Real-Time Debugger cu executabilul hiwave.exe din
 directorul D:\IP2\Tools\s12.45\Prog. In directorul D:\IP2\Tools exista un
“shortcut” catre hiwave.exe ce permite o lansare mai usoara a acestuia.

3. Incarcarea aplicatiei pe microcontroller consta in doua etape:

a. Incarcarea fisierului Project.sx prin intermediul meniului File-Load
Application.
 In fereastra de dialog aparuta se va selecta fisierul Project.sx, se va bifa
optiunea de stergere si programare automata a programului si se va
actiona butonul “Load Code”.
b. Incarcarea simbolurilor aplicatiei (nume de variabile, nume de functii)
prin intermediul meniului File-Load Application. Pentru aceasta se va
selecta fisierul application.abs si se va actiona butonul “Load
Symbols”.

4. Aplicatia poate fi rulata si/sau depanata.

Exercitiul 1:
Sa se modifice sistemul astfel incat nucleul sistemului de operare sa permita lucrul cu
functiile PreTaskHook() si PostTaskHook().
1. Se modifica atributele obiectului OS in ProOSEK Configurator.
2. Se genereaza fisierele os.c si os.h.
3. Se verifica in fisierul de configurare xdp512_application.oil modificarea valorilor
celor doi parametri PRETASKHOOK si POSTTASKHOOK.
4. Se verifica aparitia referirilor si a apelurilor functiilor in fisierele generate.
5. Se adauga corpuri vide pentru cele doua functii in fisierul applmain.c.
6. Se compileaza aplicatia.
Exercitiul 2:
Sa se modifice functia PreTaskHook() definita la exercitiul 1 astfel incat sa se
realizeze urmatoarele operatiuni:
• sa comande LED-ul conectat la pinul PB6 cu perioada de aproximativ 1
secunda;
• sa comande aprinderea/stingerea unui LED conectat la pinul PK2 cu o
perioada de aproximativ 250ms, folosind folosind comutarile spre starea “in
curs de executie” ale task-ului de perioada 2ms.
Obs:
• Instructiunea de comanda a pinului PB6 din task-ul de 1s va fi comentata!
• Va fi folosita functia GetTaskID.

Exercitiul 3:
• Sa se defineasca doua obiecte de tip TASK cu urmatoarele specificatii:
a. Nume: Task_A
Prioritate: 10
Activari: 1
Marime stiva: 20
Mod planificare: Ne-preemtiv

b. Nume: Task_B
Prioritate: 10
Activari: 1
Marime stiva: 20
Mod planificare: Ne-preemtiv

• Sa se genereze fisierele os.c si os.h.

• Sa se observe in fisierul de configurare xdp512_application.oil aparitia celor
doua obiecte de tip TASK.
• Sa se faca modificarile necesare in applmain.c astfel incat:
o task-ul Task_1s sa se termine prin activarea task-ului Task_A;
o task-ul Task_A sa se termine prin activarea task-ului Task_B;
o task-ul Task_A sa comande releul conectat la pinul PB6
o task-ul Task_B sa comande releul conectat la pinul PP2;
• Sa se compileze si sa se ruleze aplicatia aplicatia.