Generazione di sistemi operativi con comunicazioni a messaggi per microcontrollori Pic della famiglia 18F

Fa oltà di S ienze Matemati he, Fisi he e Naturali

Corso diLaureaSpe ialisti ainTe nologie Informati he

Tesi di Laurea

Generazione di sistemi operativi on

omuni azioni a messaggi per

mi ro ontrollori Pi della famiglia 18F

Laureando: Relatore:

Introduzione 1

1 I Generatori 3

1.1 Meta-programming . . . 3

1.1.1 Meta-programmingin.NET . . . 4

1.2 Generatori. . . 6

1.2.1 Implementazionedellespe i he . . . 8

1.2.2 Evoluzionedellespe i he . . . 9

1.2.3 Costruzionedi generatori . . . 10 1.2.4 Composizionalevs. Trasformazionali . . . 11 1.3 Con lusioni . . . 12 2 I mi ro ontrolloriPICmi ro 13 2.1 Introduzioneaimi ro ontrollori . . . 13 2.2 Un pòdistoria . . . 14 2.3 Caratteristi hegenerali . . . 14 2.4 Ilnu leo . . . 16 2.4.1 L'os illatore. . . 16 2.4.2 L'ar hitetturainterna . . . 16 2.4.3 FileRegister . . . 17 2.4.4 Reset . . . 17

2.4.5 L'UnitàAritmeti o Logi a. . . 18

2.4.6 ProgramMemory . . . 18

2.4.7 Data Memory . . . 18

2.4.8 Bitdi ongurazione . . . 22

2.4.9 Interruzioni . . . 23

2.5 Leperiferi he . . . 23

2.5.3 Moduloseriale . . . 25

2.5.4 Altrimoduliperiferi i . . . 26

2.6 Caratteristi hespe iali . . . 26

2.6.1 Low voltage Dete t . . . 26

2.6.2 IlWat hdogTimer . . . 27

2.6.3 In-Cir uitSerialProgramming . . . 27

2.7 Con lusioni . . . 27

3 Sistemioperativiper PIC 29 3.1 SalvoRTOS . . . 29 3.2 Pi Os18 . . . 30 3.3

µ

C/OS-II . . . 34 3.4 Con lusioni . . . 36 4 Il frameworkRoboti s4.NET 39 4.1 L'infrastrutturadi omuni azione . . . 42 4.2 IlBrain . . . 42 4.3 LaBodymap . . . 43 4.4 I Roblet . . . 43 4.5 Con lusioni . . . 45 5

µ

TNetOS 47 5.1 IlCompilatoreC18 . . . 47

5.2 Strutturadelnu leo . . . 48

5.2.1 Gestionedeitask . . . 48

5.2.2 Temporizzazione . . . 52

5.2.3 S hedulazionedeitask . . . 53

5.2.4 Gestionedellamemoria . . . 58

5.2.5 Gestionedeglieventi . . . 60

5.2.6 Gestionedeimessaggi . . . 61

5.2.7 Comuni azioneseriale . . . 65

5.3 Inizializzazioneeavvio . . . 66

5.4 Performan e. . . 68

6 Generazionedinami a 71 6.1 Ar hitetturadelGeneratore . . . 71

6.2 Generazionedei odi idi odi aXML . . . 72

6.2.1 Te ni adi odi a . . . 72

7 Un aso di studio: Controllodi un motore passo-passo 83

7.1 I motoripasso-passo . . . 83

7.1.1 Prin ipiodi funzionamento . . . 84

7.2 Strumentiutilizzati . . . 85

7.2.1 IlPIC 18F452 . . . 87

7.2.2 PICDEM 2PLUSDemoboard . . . 88

7.2.3 ProgrammatoreMPLABICD2. . . 90

7.3 Sviluppodelsistema . . . 93

7.3.1 LatoServer . . . 94

7.3.2 Lato lient . . . 103

7.4 Performan e. . . 104

8 Con lusioni 107

A Ambientedi sviluppoe Compilatore 109

Bibliograa 126

Glossario 128

In maniera res ente, i mi ro ontrollori vengono utilizzati negli ambienti

in-dustriali e di intrattenimento perpilotare e monitoraresistemi roboti i e non

solo. Dalmomento heleappli azioni assumono aratteristi hesemprepiù

so-sti ate, la loro on ezioneed implementazionedivengono omplesse erisulta

dunque impres indibile l'utilizzazione di unsistema operativopergestire tale

omplessitàeperfornirealprogrammatoreun ertolivellod'astrazioneattoad

in rementarelaportabilitàdel odi e.

Re entemente è statoimplementato presso il Dipartimento di Informati a

dell'Universitàdi Pisa unsistema operativoper unas hedadi ontrollo,

hia-mataWildFire,basatasulmi ro ontrolloreColdFiredellaMotorola. Ilsistema

èstatopoiintegratoall'internodiunainfrastruttura, hiamataRoboti s4.NET,

realizzata onlos opodisviluppareprogrammidi ontrollopersistemiroboti i

aventi un'ar hitettura bio-like , ioè ispirata al sistema nervoso umano. L'uso

di unas hedaWildFire,piuttosto heun al olatoreveroeproprio,haportato

adunanotevoleabbassamentodei ostilegatiall'hardware,adunadiminuzione

delledimensionidelsistemaeadunaumentodellasuaadabilità.

L'obiettivodi questatesi èdimigliorarean oradipiùirisultatipre edenti,

eettuandoilportingdelsistemaoperativosuun'ar hitetturahardwarepiù

pi - ola. Comear hitetturaèstatas eltalafamigliadimi ro ontrolloriPICmi ro

18FXX2dellaMi ro hip. Leragioni he ihannospintoas eglierequesta

ar hi-tettura,in ludono, ome sivedrà,ledis reteperforman e,leesiguedimensioni

eilridottissimo osto.

Nel porting del sistema operativo sono state arontate le prin ipali

pro-blemati he he aratterizzano lo sviluppodi questisistemi, la ui importanza

è sottolineata dalla loro ontinua diusione. La realizzazione di un intero

si-stema operativo per mi ro ontrollori è un problema piuttosto omplesso he

interessadiversisettoriingegneristi i: l'elettroni a,perquanto on ernela

zionediunsistemaoperativosulquale,su essivamente,saràpossibileeseguire

leappli azioni hesivoglionorealizzare.

Ilsistemaoperativoèstato hiamato

µ

TNetOS,sigla diSistemaOperativo per Mi ro ontrollori on supporto di rete (Net) eTimer pera odamento

ta-sk. Come linguaggiodiprogrammazioneèstatos eltoil C,ed èstatousato il

ompilatoreC18fornitodallaMi ro hip. Las eltadiquestolinguaggio,inve e

dellinguaggioassembler,hapermessodi on entrarsimaggiormentesullaparte

software, delegandoal ompilatorelagestionedi piùbassolivello

dell'ar hitet-tura.Inoltre,l'usodelCrendeportabile, onpo hissimemodi he,il

µ

TNetOS sututtii mi ro ontrolloridellafamiglia18FdellaMi ro hip, osa he sarebbe

stataimpossibileprogrammandodirettamentein linguaggioassembler.

Completato il porting, ilse ondo obiettivoèdi integrareil sistema

nell'in-frastrutturaRoboti s4.NET.Aquestopropositoèstatoimplementatoun

gene-ratoredi odi e he,datelespe i headaltolivello deimessaggi he ir olano

nell'infrastruttura,generailrelativo odi eCdaintegrarenelnu leodelsistema

operativo.

Il apitolo1fornis eal unenozionidimeta-programmazioneperpoipassare

ades riverele aratteristi heprin ipalideigeneratoridi odi e.

Il apitolo2presentalafamigliadimi ro ontrolloriMi ro hip18F, onuna

des rizionedelparti olaresottofamiglia18FXX2presain onsiderazioneperlo

sviluppodel

µ

TNetOS.

Il apitolo3des rivelostatodell'artedeisistemioperativiperPIC:vengono

analizzatial unideiprin ipalisistemioperativievienefattounraronto onil

µ

TNetOS.

Nel apitolo 4 analiziamo il framework Roboti s4.NET, he rappresenta

l'infrastrutturasottostantesu uiintegrareil

µ

TNetOS.

Il apitolo5illustrale aratteristi hedelnu leodelsistemaoperativo,mentre

il apitolo6des riveil generatoredellasuapartedinami a.

Il apitolo 7presenta ome asodi studioil ontrollo di unmotore

I Generatori

Nei moderni sistemiinformati i vi èuna res ente domandadi appli azioniin

grado di adattarsi dinami amente alle aratteristi he e ai ambiamenti dello

spe i oambientediutilizzo. Sirendene essario,quindi,averelapossibilitàdi

modi areidiversiaspettidei omponenti,di ongurarlieassemblarlimediante

pro essiautomati i.

Inquesto apitolosipassain rassegnale aratteristi heprin ipalidei

gene-ratoridi odi eedellameta-programmazione,idue strumentiutilizzati perla

generazionedellapartedinami adel

µ

TNetOS.

Nelparagrafo1.1analizzeremobrevementele apa itàdimeta-programming

delC#,mentrenelparagrafo1.2siintrodu onole aratteristi hedeigeneratori

elelorotipologie.

1.1 Meta-programming

Unmeta-programmaèunprogramma heanalizzaemanipolaaltriprogrammi,

ompresoséstesso. I programmigeneratisonodettiprogrammioggetto . I

om-pilatorieipre-pro essorisonoesempi dimeta-programmi heoperanosualtri

programmi. Il on ettodi meta-programmazione si appoggia sui due on etti

di metadata eree tion.

I metadatafornis ono il modellodel sistema, ioètuttele informazioni

ne- essarie a des rivere unprogramma; vengonomemorizzati in formato binario,

neutrale rispettoallinguaggio,siain memoria hein unle eseguibile.

Perree tionsiintendela apa itàdiunprogrammadia ederealproprio

statointernodi ese uzioneepossibilmentedimodi arlo: èquindiun on etto

•

introspezione : ilsistema osservaede ideinbase alpropriostato,

•

inter essione:ilsistemamodi alapropriaese uzioneoalteralapropria interpretazione;

Inunree tive system, quandoil odi esorgentediunprogrammaviene

om-pilato,leinformazionirelativeallasuastrutturavengonopreservatesottoforma

dimetadatanel odi edipiùbassolivelloprodotto.

1.1.1 Meta-programming in .NET

Ilgeneratoredes rittoin questatesièstatos rittonellinguaggioC#di .NET

pertanto, a partire dai on etti n qui esposti, des riveremo brevemente le

apa itàdi meta-programmazionedelCommonLanguageRuntimedi.NET.

Il CLR esprime il suo ree tive system attraversoapposite API; le lassi

per la ree tion sono ontenute nel namespa e System.Refle tion. Tutti i

tipisonoauto-des rittivielelorodenizioni possonoesserea edutetramiteil

metodo GetType() ereditato da System.Obje t. Conla ompilazione di una

lasse,vieneprodottounmanagedmodule (oassembly)eognitipodidato, on

irelativimembri,vienedes rittoinquestoassemblyattraversodeimetadati. In

fasediese uzione,ilCLR ari aimetadatiinmemoriaperottenereleseguenti

informazioni:

•

Des rizionedell'assembly,

•

Des rizionedeltipodi dato(nome,s ope , lassebaseeinterfa ia imple-mentate,metodi, ampi,proprietà,eventietipi annidati),

•

Attributi(elementides rittiviaggiuntivi);

Medianteree tionèpossibileistanziaredinami amenteuntipo,odottenereil

tipodiunoggettoesistente;èpossibileinvo areimetodideltipooa edereai

suoi ampi eproprietà. A titolodi esempio, il listato1 mostra ome invo are

dinami amenteilmetodoEqualsdella lasseSystem.String.

Attributi

IlCLRpermettediaggiungerenel odi espe ialidi hiarazioni,detteattributi,

perannotareelementitarget diunprogramma,quali: tipodi dato, ampi,

me-todieproprietà. Infasedi ompilazionequestiattributivengonosalvatiinsieme

aimetadatanellaappositasezionedelleeseguibile. Atempodiese uzione

Listato 1 Esempio di Ree tion in C#. Il metodo Equals ontrolla se due

stringhe sono uguali e in questo esempio restituis e false. I parametri del

metodoInvokeMember()sonoiseguenti:

•

Ilprimo parametroèil nome del metodo he vogliamo invo are eviene passato omestringa,

•

Il se ondo parametro è un membro dell'enumeration BindingFlags e spe i a l'azione da ompiere, in questo aso l'invo azione del metodo

s elto,

•

IlterzoparametroèunoggettoBinder;seènullindi a heviene utilizza-toilBinderdidefault. L'oggettoBinderdàall'utenteil ontrolloespli ito

su omeilme anismodiree tionselezionaunmetodooverloadede ome

onvertegliargomenti,

•

Ilquartoparametroèl'oggettosu uiinvo areilmetodo,

•

Il quinto parametro è un array ontenente gli argomenti da passare al metodoinvo ato;

using System;

using System.Refle tion ;

namespa e Refle tion

{

lass Refle tedTypes

{

[STAThread℄

stati void Main(string[℄ args)

{

Type TypeToRefle t = Type.GetType("System.String");

obje t result = null;

obje t[℄ arguments = {"ab ","xyz"};

result = TypeToRefle t.InvokeMember ("Equals",

BindingFlags.InvokeMethod, null, result , arguments);

Console.WriteLine (result.ToString ());

}

}

}

•

Serializzazionedi dati,

•

Fa ilitazionedeldebug,

•

Interazione on omponentiCOM;

NelCLRilprogrammatorepuòestenderegliattributipredeniti

denendo-nedi propri ( Custom Attribute), al ne di aggiungereinformazioni al proprio

odi e. Dal punto di vista implementativo sono lassi tradizionali hedevono

ereditaredaSystem.Attribute.

Listato 2 Esempio di Custom Attribute. Si denis e un Custom Attribute

hiamato Help ontenente un url e si utilizza poi nella lasse MyClass per

indi arel'urldadovereperireleinformazionisulla lassestessa.

using System;

publi lass HelpAttribute : System.Attribute

{

publi readonly string Url;

publi HelpAttribute(string url)

{

this.Url = url;

}

}

[Help("http://lo alhost/MyClassInfo")℄

lass MyClass

{

//body

}

1.2 Generatori

Un generatore è un programma he prende ome input la spe i a ad alto

livellodiunsistemaeneprodu elasuaimplementazione. Quiiltermine

`siste-ma'èusatonellasuaa ezionepiùgenerale: puòessereunsistemainformati o,

una lasse,una pro edura,un omponente,et . L'uso deigeneratori permette

diraggiungeretreimportantiobiettivi:

•

Con entrarsisullespe i he(`Cosaène essario?'),evitandodipensareai dettagliimplementativi,

•

Evitare il problema della s alabilità delle librerie ( library s aling pro-blem): le librerie in genere raddoppiano in dimensione per ogni nuova

aratteristi aimplementata;

Iltermine`generatore'èmoltogenerale e oprediversete nologie, in lusii

ompilatori, ipre-pro essori,lemetafunzioni hegenerano lassiepro edure,i

generatori di odi e, e osì via. Per esempio, un ompilatore prende in input

unprogrammas rittoinunlinguaggioadaltolivelloegeneralasua

implemen-tazione in linguaggio ma hina oin byte ode . Sommariamente, un generatore

esegueleseguentiazioni:

1. Controllalavaliditàdellaspe i aininput,restituendomessaggidierrore

odi avvertimento,

2. Sene essario,integralaspe i a oninformazionipredenite,

3. Eettuaeventualiottimizzazioni,

4. General'implementazioneri hiesta;

Nel asopiùsempli e,questeazionivengonoeseguitein as ata,mentrenei asi

più omplessio orreeseguirlein paralleloe/oiterativamente.

L'attività di programmazione può essere vista ome un pro edimento per

reare e modi are le spe i he di un sistema e la sua implementazione. La

modi a(oevoluzione)di unaspe i aelasuaimplementazione, omesivede

ing. 1.1,possonoessereviste omedueattivitàortogonalifraloro. Entrambe

queste attività possono essere pensate ome una serie di trasformazioni sulle

rappresentazionediundatosistema.

1.2.1 Implementazione delle spe i he

L'attività di implementazione (g. 1.2) può essere automatizzata a tre livelli

diversi:

Figura1.2I trelivellidiimplementazioneautomati adi unsistema

1. A partire dai requisti, il programmatoreimplementa manualmente il

si-stema(peresempioinJavaoC#). L'uni aazioneautomati aèlafasedi

ompilazionedelprogramma. Inquestafaseilprogrammatoredevean ora

eseguiremanualmenteuna onsiderevolequantitàdilavoroditraduzione:

può essere ne essario introdurre delle nuove spe i he di dominio,

ese-guiredelle ottimizzazionespe i heal dominio e osì via. Tutto iò per

olmareilgap he 'èfralespe i heininputel'implementazione( odi e

e/o delle librerie he, a partire dai requisiti, fornis ono le astrazioni di

dominiori hieste,

3. Inne, unpiùalto livello di automazione vieneraggiunto on i

osiddet-tisistemi trasformazionali interattivi, he permettonodi partire da

una odi a dei requisiti funzionalie non funzionalidi unsistema e

ag-giungerevia viade isionidi progettazionee di implementazione tramite

trasformazioni memorizzate in unalibreria spe i a di dominio. Questa

trasformazionepuòperòesseresoloparzialmente automatizzata,perdue

ragioni:

•

Moltede isionidiprogettazionesitrovanonellaspe i adelsistema; iò reaunenormespaziodiri er aeilprogrammatoredeveaiutare

lama hinaas egliereletrasformazioni orrette,

•

Nonsempretuttelede isionidiprogettazionene essariesono dispo-nibili nella libreria della ma hina (in genere a ausa del loro alto

ostodisviluppo). Ilprogrammatoreèquindi ostrettoadeettuare

manualmente al unetrasformazioni;

Larappresentazionedelsistema hepuòesseremanipolatadallama hina

pren-de il nome di system sour e . Le trasformazioni eettuate

automati amen-te durante la ompilazione sono hiamate ompiler transformations, mentre

quelle eseguite interattivamente on l'aiuto del programmatoresono hiamate

sour e-to-sour e transformations.

1.2.2 Evoluzione delle spe i he

L'automazione dell'attivitàdi evoluzione èan oraoggiraraelimitata. La

ra-gione èdovutaalfatto he, di solito, l'evoluzione onsistein un ambiamento

delleproprietàdiunsistema, henonsempresonoespli itamenterappresentate

in unsystemsour e s rittoin unlinguaggiodiprogrammazione. Lapossibilità

dimodi arelede isionidiprogettazioneinunmodoe ienteri hiede hetali

de isionisianopresentinelsorgente, osa henonavvieneneiprogrammi

s rit-ti in linguaggi di programmazione general-purpose. Ilsupportoautomatizzato

all'evoluzionediventa possibilesoloquandorappresentiamounsistemausando

notazioniadaltolivello,dipendentidaldominio, he ipermettonosiadi

1.2.3 Costruzione di generatori

Lete ni heprin ipaliusateperla ostruzionedigeneratorisonotre:

•

Costruire un generatore da zero (programma stand-alone). È la strada piùfati osaper héène essarioimplementaredazerolarappresentazione

interna del sorgente, il odi e he eettua l'analisi, l'ottimizzazione ela

generazione. Nel aso heil generatoreri evagliinputinformatestuale,

o orrepoi ostruireunanalizzatorelessi aleesintatti oper onvertireil

testonellarappresentazioneinterna. Inoltre,questoappro ioindebolis e

la apa itàdelgeneratorediintegraredierentinotazioniedierenti

stru-mentidi sviluppo,per hèognigeneratoreusalapropriarappresentazione

delsorgente enonfornis enessunainterfa ia.

•

Costruire un generatore usando le apa ità di meta-programming di un parti olarelinguaggio . Al unilinguaggifornis onostrumentiper

manipo-lare gliaspetti rappresentativi di unlinguaggioatempodi ompilazione

e/oatempodiese uzione.Peresempio,inC++laprogrammazione

generi- atramitetemplatepermettedis riveregeneratoridi odi e hevengono

eseguitiatempodi ompilazione;inC#laree tionpermettedis rivere

generatori hevengonoeseguitiatempodi ese uzione.

Ilvantaggioprin ipalediquestigeneratoriè hepossonoesseredistribuiti

ome parti di pro edure onvenzionali e librarie di lassi s ritte in altri

linguaggi. Inoltre, le apa ità di meta-programming del linguaggiosono

ottimizzateperqueldatolinguaggioesonopiùfa ilidausarerispettoalla

manipolazionedi rappresentazioniinterne general purpose delsorgente.

In denitiva, questo appro io risulta più onveniente rispetto al

pre e-dente. Ci sono però an he degli svantaggi. Prima di tutto, il tipo di

spe i a implementata è limitata aquella del linguaggio ospite.

Se on-do,lamaggiorpartedeilinguaggi on apa itàdimeta-programmingnon

permettedi estendernelasintassi. Inne,questilinguagginonfornis ono

unadeguatosupportoaldebugging delmeta- odi e.

•

Costruire generatori usando un'infrastruttura apposita. L'appro io più adeguato onsiste nell'usare un'infrastruttura omune he fornis a tutti

gli strumenti ne essariper ostruire generatori. Ciò in lude un formato

omune per la rappresentazione interna del sorgente e un insieme

rappresenta-dasupportarequalsiasitipoditrasformazioni(in luseleottimizzazionie

quellesour e-to-sour e).

L'infrastrutturadovrebbeessereingradodi:

 Supportarela reazionedistrumentidiinputeoutputappropriati,

 Consentireildebugging dellenotazioniimplementatedaigeneratori,

 Fornireunadeguatosupportoalle attivitàdisviluppodeigeneratori

stessi,peresempiopermettendoil debugging delmeta- odi e;

1.2.4 Composizionale vs. Trasformazionali

Una trasformazione può essere denita formalmente ome una modi a

auto-mati aesemanti amente orretta della rappresentazione diunprogramma . Le

trasformazionieettuate daungeneratorepossonoesseredi tre tipi: verti ali,

orizzontalieoblique(g. 1.3). L'ideaallabasediunatrasformazioneverti ale(o

Figura 1.3Trasformazioniorizzontali,verti alieoblique

an heforwardrenement) onsisteneltrasformareunarappresentazioneadalto

livelloinunaabassolivello,las iandoinalteratalamodularitàdiquellaadalto

livello. Ognirinimentoimplementaunmoduloadaltolivello attraversounoo

piùmodulidi bassolivello,masempre neilimitistabiliti dalla

rappresentazio-ne adaltolivello. Un esempiodi rinimentoèl'implementazionedi una lasse

C++ in termini di astrazioni del C . I generatori basati sul forward renement

prendonoilnomedi generatori omposizionali( ompositi ona l generator).

osi fondono moduli esistenti ose ne reanodei nuovi. I generatori he

eet-tuanosiatrasformazioniverti ali heorizzontaliprendonoilnomedigeneratori

trasformazionali( transformational generators).

Un terzotipodi trasformazioni, quelleoblique, hannoentrambele

ompo-nentiorizzontalieverti ali.

L'implementazionediungeneratore omposizionaleèrelativamente

sempli- e per hè le trasformazioni possono essere eettuato durante un sempli e

at-traversamento dellarappresentazioneadalto livello: quando vienevisitatoun

ostruttoadaltolivello,vienegeneratalasuaimplementazioneabassolivello.

L'implementazione di un generatore trasformazionale è inerentemente più

omplessainquantoène essario oordinarel'appli azionedidiverse

trasforma-zioniattraversogrosseporzioni di programma he possono an hesovrapporsi.

L'implementazionediquestigeneratorivaoltrelos opodiquestatesiepertanto

sirimandaa[4℄perulterioriapprofondimenti.

1.3 Con lusioni

Questo apitoloha fornitouna panorami adei on etti di meta-programming

edei generatori. Perulterioriapprofondimenti sipuò onsultare[4℄, [22℄. Nel

I mi ro ontrollori PICmi ro

Questo apitolopassa inrassegnale aratteristi heprin ipaledellafamigliadi

mi ro ontrollori PIC 18FXX2 della Mi ro hip. Il paragrafo 2.1 fornis e una

breveintroduzioneaimi ro ontrollori,mentre ilparagrafo2.2introdu ei

PIC-mi ro. Il paragrafo 2.3 des rive le aratteristi he generali di tutti i PIC in

ommer io, mentre nei paragra 2.4, 2.5 e2.6 vengonoanalizzatein dettaglio

le aratteristi hedellafamiglia18FXX2, ioèquellapresain onsiderazioneper

lapresente tesi.

2.1 Introduzione ai mi ro ontrollor i

I mi ro ontrollori(MCU, Mi ro ontroll er Unit)sono dispositivi he integrano

unpro essoreeduninsiemedi dispositiviperiferi i,in ununi o hip. Quando

siparla dimi ro ontrollori,generalmentesi usail termine`famiglia',

intenden-do un insieme di dispositivi he hanno in omune diverse aratteristi he, per

esempio l'organizzazione della memoria interna e lagestione delle periferi he.

Esistono numerose famigliedi mi ro ontrollori, spe ializzatepervariusi e he

quindihannoar hitetturae aratteristi heassaidiversefraloro,maingenerale

tutte ontengonointegratiin ununi o hip:

•

Unpro essore entrale,

•

UnamemoriaRAMperidati,

•

UnamemoriaROMperil odi edelprogramma,

Prati amentetuttiidispositivielettroni idiuso omune,daltelefono ellulare,

allalavastoviglie,al rus ottodell'automobile,basanoillorofunzionamentosu

qual hetipodimi ro ontrolloreinterno.

Ilprin ipale vantaggiodell'utilizzazione di mi ro ontrollori per la

realizza-zione di appare hiature elettroni he, onsiste nella loro estrema essibilità:

poi hé le funzionisvolte sono determinate dal programma, lostesso

dispositi-vopuòsvolgerefunzioniassaidiverse,sempli emente ambiandoilprogramma

di ontrollo. Questo ostituis e un vantaggio nella fasedi sviluppo in quanto

unamodi a an hesostanziale delle funzioni ri hiede solo il ambiamento del

programma interno,senzavariazionidalpuntodi vistahardware. Inoltre,

poi- hélostessodispositivopuòessereutilizzatoinungrannumerodiappli azioni

diverse, èpossibileprodurloin quantità maggiori,realizzando osìe onomiedi

s ala.

2.2 Un pò di storia

Nel1970laGeneralInstruments omin iòaprodurreunpro essorea16bit

o-nos iuto omeCP1600. Losvantaggioprin ipaledelCP1600eralasualimitata

apa ità di gestire l'I/O, osì la Generale Instruments gli aan ò un pi olo

pro essore hefungesseda ontroller. Ilsuo ompitononerasolo quellodi

ge-stirel'I/Oper ontodelCP1600,maan hedifunzionare omeunveroeproprio

pro essore he potessefornire un erto gradodi ontrollo. Questo pro essore

venne hiamatoPeripheral Interfa eController oPIC .

Allametà degli anni'80 ladivisione mi roelettroni adellaGeneral

Instru-ments si sta ò e fondò laMi ro hip Te hnology In . ed il PIC ( ol nome di

PICmi ro)divenneilsuoprodottodipunta.

Oggii PIC sonolargamente usatiin ambitoroboti o,ma si trovanoan he

in molti dei dispositivi he usiamoquotidianamente: gio attolie lettoriDVD

peresempio.

2.3 Caratteristi he generali

Comesipuòvedereing. 2.1,iPIC sipresentanoesternamente ome dei

nor-mali ir uitiitegratiTTLoCMOS.Internamentedispongonodituttidispositivi

tipi idiunsistemaami ropro essore:

Figura 2.1FotodelPIC 18F452

•

Una memoria ROM ( Read Only Memory) in ui sono memorizzate in manierapermanenteleistruzionidelprogrammadaeseguire,

•

UnamemoriaRAM( RandomA essMemory),utilizzatapermemorizzare levariabilidelprogramma,

•

UnaseriedilineeI/Operpilotaredispositiviesterniori evereimpulsida sensori,pulsanti,e .,

•

Unaseriedidispositiviausiliarialfunzionamento,qualigeneratoridi lo k , bus, ontatori,e .;

La presenza di tutti questidispositivi in uno spazio estremamente ontenuto,

onsente alprogettista di avvalersi degli enormi vantaggiderivanti dall'usodi

unsistema ami ropro essore, an heinquei ir uiti henoaqual heannofa

eranodestinatiadessererealizzati on ir uiterietradizionali.

I PIC sonodisponibili in un'ampiagammadi modelli permeglio adattarsi

alle spe i heesigenzedi progetto,dierenziandosi pernumerodi lineediI/O

e perdotazione di dispositivi. Si partedai modelli piùpi oli dotati di soli8

pin, no ad arrivareai modelli più grandi dotati di 40 e più pin. All'interno

di ognifamiglia vi sono diversi dispositivi on aratteristi he dierenti (più o

meno memoria, velo ità di funzionamento, presenza di periferi he analogi he

quali onvertitorie osì via) per rispondere almeglio alle esigenzedi un erto

progetto.

Cias unPIC può esseres ompostointre gruppiprin ipali:

1. Ilnu leo

2.4 Il nu leo

2.4.1 L'os illatore

L'os illatore è un dispositivo ne essario per generare il lo k di sistema he

permettel'ese uzionedelleistruzionieilfunzionamentodeidispositiviperiferi i.

Adierenzadi altrefamiglie, ilPIC 18FXX2nondispone di unos illatore

internoepertantone deveesserefornitouno esterno. Tenendo onto di iò, il

18FXX2può operareinottodiversemodalità(vedi tab. 2.1)elosviluppatore

puòs eglierneunatramiteilsettaggiodeitrebitdi ongurazioneFOSC2,FOSC1,

eFOSC0.

Tabella 2.1 Modalità di ongurazione dell'os illatore. Come si vede sono

supportatidiversitipidi os illatoriedi onseguenzalafrequenzadi lo kvaria

infunzionedeltipodios illatores elto;lafrequenzamassimanonpuò omunque

superarei40Mhz.

Congurazione Tipodi os illatore montato

LP Cristalloabassapotenza(max200KHz)

XT Cristallo/Resonator(max4MHz)

HS Cristallo/Resonatoradaltavelo ità(max40MHz)

HS+PLL HS+4XPLL 1

(max10MHz)

RC RCEsterno(max4MHz)

RCIO RC on OSC2 omeI/O(max4MHz)

EC Clo kesterno(max40MHz)

ECIO EC onOSC2 ome I/O(max40MHz)

1

Il PLL ( Phase Lo ked Loop) è un ir uito elettroni o progettato per

generareun'ondadiunaspe i afrequenza,sin ronizzata onun'onda

divalorediverso,fornitainingresso. Lafamiglia18FXX2disponediun

PLL4x, ioè hequadrupli alafrequenzadell'os illatoreiningresso.

2.4.2 L'ar hitettura interna

L'ar hitettura interna è ad 8 bit e di tipo Harvard, ioè prevede l'uso di due

memorieseparate,una ontenentesolodati( datamemory),l'altrasolole

istru-zioni( programmemory), onnesseattraversoduebusseparati. Inquestomodo

èpossibile ari aresimultaneamente dati eistruzionidalledue memoriein un

Figura 2.2Ar hitetturaHarvardedi VonNeumanna onfronto.

loronumerovariadaunminimodi 33nelleversionidibassapotenza,noaun

massimodi 77in quellidi fas iaalta.

La pipeline è a due stadi ( two-stage) e permette l'ese uzione della fasedi

fet h in parallelo on quelladi exe ute ( hein lude an he quelladi de ode)di

un'altraistruzione. Perquestomotivoleistruzionivengonoeseguitetutteinun

i lodi lo k ,apartequellesudoppiaparola(peresempioGOTOoCALL) hene

ri hiedonodue.

Ogni i lod'istruzioneè ostituitodaquattoperiodi di lo k; peresempio,

supponendodiutilizzareun lo ka40Mhz,un i loistruzioniimpiega100ns.

Lafamiglia dispone di unosta khardwarea31 livelli, su ui vengono

me-morizzato gli indirizzi di ritorno. Lo sta k è a essibile attraverso il registro

STKPTR.

2.4.3 File Register

Un on etto omuneaiPICdiognifamigliaèquellodiFileRegister: tuttii

re-gistriutilizzatidalPIC ( ompresoilProgramCounter)risiedononellamemoria

dati; tutte le periferi he presenti sono mappate in memoria dati eviste ome

una serie di registri. La memoria dati è, almeno in parte, di elevata qualità

(SRAM interna on tempi di a essomoltobassi)in mododanonpenalizzare

leprestazioni.

2.4.4 Reset

Ogni dispositivohaun ir uitologi o di resetperpermetterglidi ritornarein

2.4.5 L'Unità Aritmeti o Logi a

L'ALU èad 8bit e può eettuareaddizioni, sottrazioni, moltipli azioni,shift

eleelementarioperazionilogi he. Al propriointernointegra unmoltipli atore

8 × 8

di tipo hardware he rende possibile eseguire la moltipli azione in un solo i lo di lo k. Nelle istruzioni he ri hiedono due operandi, il primo è

sempreunregistroa umulatore 1

, hiamatoWREG,mentrel'altropuòessereun

valore ostante ounqualsiasialtroregistro. Nelle istruzioni heri hiedonoun

solooperando, questo può essere unregistro qualsiasi ( ompresoil WREG ). Un

spe ialeregistro,STATUS, ontiene lostatoaritmeti odellaALU.

2.4.6 Program Memory

La memoria programma è di tipo FLASH, on parole di 16 bit. Il Program

Counter èa21bit epermettequindidi indirizzarenoa2Mbyte. Inrealtàla

memoriasi amenteimplementatadipendedaltipodiPICutilizzatoepertanto

può essere inferiore: eventuali letture oltre la dimensione eettiva generano

letture di istruzioni NOP . L'ese uzione di un programma avvienea partire dal

vettore di reset ( Reset Ve tor), ioè dall'istruzione memorizzata nella prima

lo azionedi memoria(indirizzo0x0000). Lamemoriaèorganizzata inblo hi

la ui dimensione, ad e ezione del primo blo o di 512 Kbyte, dipende dal

dispositivospe i o utilizzato. A titolo esempli ativolag. 2.3s hematizza

lastruttura della memoria programma del PIC 18F452, ioè quello utilizzato

nel asodistudiodel ap. 7.

2.4.7 Data Memory

Lamemoriadati(oFileRegister)èimplementata omeRAMstati a;laparola

èa8bit eogniregistro in memoriaha unindirizzodi 12bit, permettendo di

indirizzarenoaunmassimodi4096bytes. Èdivisain16ban hidi256bytes.

An heinquesto aso, omeperlamemoriaprogramma,lamemoriasi amente

implementatadipendedaldispositivoutilizzato,pertantoeventualilettureoltre

ladimensione eettivarestituis onoil valore0. Ing. 2.4 è s hematizzatala

memoriadatidelPIC 18F452.

L'a esso può esserediretto oindiretto. L'a esso diretto (g. 2.5) viene

eettuatoattraversouno spe ialeregistro hiamatoBSR( BankSele tRegister)

i ui4bitmenosigni ativivengonousatiperselezionareil ban odi interesse

(glialtribitdelregistrosonoinutilizzati).

Figura 2.3StrutturadellaProgramMemory del PIC18F452.

L'a essoindiretto(g. 2.6)vieneeettuatousandotrespe ialiregistri

hia-mati FSR0 ,FSR1 ,FSR2( FileSele t Register). An hésiapossibileindirizzare

l'interospaziodellamemoriadati,(4096bytes)questiregistridevonoutilizzare

12bit epertantosonoimplementantiusandodue registriad8bit:

•

FSR0: ompostodaidueregistriFSR0HeFSR0L,

•

FSR1: ompostodaidueregistriFSR1HeFSR1L,

•

FSR2: ompostodaidueregistriFSR2HeFSR2L,

GliFSRvengonousati omepuntatoriallalo azionedimemoria hedeveessere

Figura2.4StrutturadellaDataMemory delPIC 18F452.

Cias uno registro FSR ha asso iato un altro registro, hiamato INDF he

ontiene il ontenuto hedeveessere s ritto[letto℄ nellalo azionedi memoria

indirizzata. Una lettura [s rittura℄ in questo registro provo a direttamente la

lettura [s rittura℄ della lo azione di memoriaindirizzata dal registro FSR

as-so iato. Per esempio, se un'istruzione s rive un valore nel registro INDF0, il

valoreverràs ritto nella lo azionedi memoriapuntata da FSR0 . Una lettura

delregistroINDF1provo heràlaletturadel ontenutodellalo azionedimemoria

indirizzatadaFSR1 . Come ulterioreesempio,il listato3riportaunframmento

di odi eC hemostra omepulire il ontenutodelBan o1dimemoria.

Lamemoriavieneidealmentedivisainduesezionispe iali: Spe ialFun tion

Figura 2.5A essodirettoallamemoriadati

Figura 2.6A essoindirettoallamemoriadati

deldispositivo,mentreiGPRsonoiregistrigeneraliutilizzatidall'appli azione

utenteinese uzionesulPIC.GliSFRinizianoall'ultimalo azione( 0xFFF )

del-l'ultimoban o(Ban o15)eproseguonoversol'alto. IGPRinizianoallaprima

lo azione( 0x000delprimoban o(Ban o0) eproseguonoversoilbasso.

All'internodellamemoriadatièstatadenitaun'areadimemoriaparti olare

Listato3EsempiodipulituradelBan o1dellamemoriadati. IlBan o1inizia

all'indirizzo0x100eterminaall'indirizzo0x1FF.

FSR0 = 0x100; while (FSR0 != 0x200) { INDF0 = 0x00; FSR0++; }

( hiamatoabit) hespe i asel'eventualeoperandorisiedenell'A essRAMo

nelban oindi atodalregistroBSR .Questaregionedimemoria, he omprende

gli ultimi 128 bytes del Ban o 15 e i primi 128 bytes del Ban o 0, è stata

progettataperiseguentis opi:

•

Memorizzarei valoriintermedidelleoperazioni,

•

Memorizzarelevariabililo alidellesubroutine,

•

Velo izzareil ontext-swit h,peresempiodurantelagestionediuna inter-ruzione,

•

Fare inmodo hei registriusatipiùfrequentemente venganoa eduti in unsolo i lodi lo kesenzatenere ontodelvaloredelregistroBSR ;

Lafamigliadisponean hediunapi olamemoriaEEPROM hepuòessere

utilizzatapermemorizzare parametri del sistema (impostazioni di setup,

pas-sword,et .). L'indirizzamentononèdiretto,matramitegliSFR.Èimportante

sottolineare ome questa tipologia di memoria abbiauna vita molto limitata,

dell'ordine dei 10 milioni di i li di an ellazione/s rittura e he presenta dei

tempidia esso onsiderevoli. Pertantoquandosiopera onleEEPROMè

ne- essariolimitarnel'usoall'essenziale,in quantononsono in gradodi sostituire

alivelloappli ativoiregistridellaRAM.

2.4.8 Bit di ongurazione

I bit di ongurazione ( Conguration Bits) vengono utilizzati per selezionare

unadata ongurazionedeldispositivofraquelledisponibili. Un bithavalore

0quandoè settato,1 altrimenti. Questi bit sono mappatinellamemoria

2.4.9 Interruzioni

Il18FXX2puògestiremultiplesorgentidi interrupt epermettedi assegnarea

ias una possibile sorgente un livello di priorità alto o basso. Il vettore delle

interruzioni adaltapriorità sitrovamappatonellamemoriaprogramma

all'in-dirizzo 000008h, mentre quello delle interruzioni a bassa priorità all'indirizzo

000018h. Un'interruzione on alta priorità prevale su tutte le interruzioni a

bassapriorità hesonogiàstatea olte.

2.5 Le periferi h e

La presenza di periferi he è iò he distingue i mi ro ontrollori dai sempli i

mi ropro essorie he rendesempli einterfa iare itask in ese uzione sul PIC

on l'ambienteesterno.

2.5.1 Porte di I/O

In base al tipo di modello, sono disponibili da tre a inque porte di I/O. I

pin di al une porte possonoessereutilizzati perpiù funzioni, ovviamente non

ontemporaneamente. Adogniportasonoasso iatiiseguentitre registri:

•

registroTRIS<porta>: usatoperimpostareipindellaporta omeinput (valore1 )ooutput (valore0 ),

•

registroPORT<porta>: unasualettura omportaunaletturadellostato delpin,mentreunasuas rittura omportalas ritturadelLat hasso iato

allaporta,

•

registro LAT<porta>: vieneusato per leggeree s riveredirettamente il Lat hasso iatoalla porta;

Per hiarireleidee, riportiamoin g. 2.7il ir uito logi odei pindella porta

A. Latabella 2.2riassumequantoappenadetto.

2.5.2 I Timer

I timersonodeiparti olariregistri hesvolgonolafunzione di ontatorie

pos-sono generare degli interrupt he interrompono temporaneamente la normale

ese uzione delprogramma. Il18FXX2dispone diquattrotimer . Ci

on entre-remosolosulla des rizionegenerale delTimer0,in quanto glialtritre operano

Figura2.7Cir uitologi odeipindellaportaA

Tabella 2.2Elen oporteeregistriasso iati

Porta Numerodi pin RegistroTRIS RegistroPORT RegistroLAT

PORTA 7 TRISA PORTA LATA

PORTB 8 TRISB PORTB LATB

PORTC 8 TRISC PORTC LATC

PORTD 8 TRISD PORTD LATD

PORTE 3 TRISE PORTE LATE

•

puòessereimmpostatoa8oa16bit,

•

lasorgentedi lo kpuòessereesternaointerna,

•

puòoperare ome ontatoreo ometemporizzatore;

Come temporizzatore vienein rementato ogni i lo istruzioni, lafrequenza

di onteggio è quindi direttamente proporzionale alla frequenza di lo k. In

realtàèdisponibileundivisoreprogrammabilededi ato( pres aler) a8bit, da

utilizzare nel asolafrequenzadi onteggioinviata altimersiatroppoelevata

perinostris opi. Ivaloriselezionabili sono:

1 : 2, 1 : 4, 1 : 8, 1 : 16, 1 : 32, 1 :

64, 1 : 128, 1 : 256

. Come ontatore,puòesserein rementatoduranteognifase res ente(ode resente)

2

delsegnalesul quartopindellaportaA( RA4 ).

LeinterruzionidelTimer0vengonoabilitateattraversounappositoregistro;

una volta abilitate,il timergeneraun'interruzionedi overow alpassaggioda

0xFFa0x00inmodalità 8biteda0xFFFFa0x0000in modalità16bit.

2.5.3 Modulo seriale

All'interodel PIC èpresente unmodulo apa e di implementareuna

omuni- azione seriale. Tale modulo prende il nome di Universal Syn hronous

Asyn- hronous Re eiver Transmitter (USART) e viene spesso indi ato an he ome

Serial Communi ations Interfa e (SCI). L'USARTpuòessere onguratonelle

seguentimodalità:

•

Asin ronafull-duplex

•

Sin ronahalf-duple x ( Master)

•

Sin ronahalf-duple x ( Slave)

Sesiutilizzalamodalitàasin ronaallorailPICpuòusarel'USARTper

o-muni are on unqualsiasidispositivoperiferi o heimplementa talestandard,

ome adesempio un omune PC. Bisognaperò ri ordare he la porta RS232,

omunemente usata sui PC per omuni azioni seriali, asso ia al livello logi o

alto il valore +12V e al livello logi o basso il valore 0V (per maggiori

detta-gli si rimanda alle spe i he dello standard), mentre le porte del PIC, an he

quelle utilizzate per la omuni azione seriale, asso ianoal livello logi oalto il

valore+5Vealvalorelogi obasso0V.Quindirisultaprati amenteimpossibile

ollegare direttamente un PC tramite la propria RS232 all'interfa ia seriale

implementatadalmi ro ontrollore. In ommer ioesistonodeidispositivi

inte-grati (adesempioil MAX232) he sio upano di onvertire isegnali RS232a

12Vin segnali a5Ve he sono ompatibili on leporte logi he herealizzano

l'interfa iaserialedeiPIC.

Se si utilizza la modalità sin rona, il PIC può omuni are on dispositivi

periferi i ome onvertitori A/D o D/A, ir uiti integrati, EEPROM seriali,

et .

2.5.4 Altri moduli periferi i

Questa famiglia omprende an he altri moduli he non verranno trattati in

questatesi,me heelen hiamoper ompletezza:

•

ConvertitoreAnalogi o/Digitaleadottoingressi he onsentedi onvertire unsegnaleanalogi oinun orrispondentevaloredigitalea10bit,

•

DuemoduliCapture/Compare/PWM,

•

UnmoduloserialeMSSP( Master Syn hronousSerialPort) hepuò ope-rarenelleduemodalitàSPIeI

2

C,

•

Un omparatoreanalogi o,

•

Un modulo EMA ( External Memory A ess) per l'a esso a memorie esterne.

2.6 Caratteristi he spe iali

Per `spe iali' laMi ro hipintende tutte quelle aratteristi he he permettono

di:

•

Abbassarei ostidisviluppodelsistema,

•

Aumentarel'adabilitàdelsistema,

•

Renderepiùessibilelafasedi progettazionedelsistema;

2.6.1 Low voltage Dete t

Inal uneappli azioni puòrisultare utile esserein gradodi determinare

quan-do il voltaggiodel dispositivo s ende al di sotto di un dato livello. Questa è

unasituazione hesiveri adi frequente quandoil PIC èalimentato ondelle

batterie. Quandoviene rilevatouna diminuzionenel voltaggio,è possibilefar

sot-Dete t serve proprio aquesto. Via software è possibile spe i are una soglia

di avvertimento: quandoil voltaggios ende aldi sottodi questa soglia,viene

lan iataunainterruzione, hepuòessere atturataegestitaopportunamente.

2.6.2 Il Wat hdog Timer

Il Wat h Dog Timer èun os illatore interno alPIC, ma ompletamente

indi-pendente dal resto della ir uiteria, il ui s opoè quello di rilevare eventuali

blo hi dellaCPU e resettareil PIC per riprenderelanormale ese uzione del

programma. Perpoterrilevareuneventualeblo odurantel'ese uzionedel

pro-grammaprin ipalevieneinseritaalsuointernounaistruzionespe iale,CLRWDT

( CLeaR Wat h Dog Timer), heazzeraad intervalliregolariil Wat h Dog

Ti-mer, non onsentendoglidi terminareil suo onteggio. SelaCPUnon eettua

questa istruzione prima del termine del onteggio allorail PIC assume he il

programmasièblo atoperqual hemotivoedeettuail Resetdelsistema.

2.6.3 In-Cir uit Serial Programming

La te nologiaIn-Cir uit SerialProgramming(ICSP

T M

)permettedi

program-mare il mi ro ontrollore senza rimuoverlo dalla s heda su ui è montato. Si

tratta di una pro edura piuttosto omodaper hè permettedi fare il debugdi

un'appli azioneetestareil PIC inmodovelo e.

2.7 Con lusioni

Inquesto apitoloabbiamopassatoinrassegnale aratteristi heprin ipalidella

famiglia18FXX2. Sonostatitrattatisoltantogliaspettiessenzialiper

ompren-dereilfunzionamentoelas ritturadelsistemaoperativo

µ

TNetOS.Perulteriori approfondimentisipuò onsultare[16℄,[17℄, [18℄,[19℄, [24℄.

Sistemi operativi per PIC

Inquesto apitolovienefornitaunapanorami asullostatodell'artedeisistemi

operativiperi PIC dellafamiglia 18FdellaMi ro hip. Nei paragra 3.1, 3.2,

3.3vedremorispettivamenteitresistemioperativiSalvo,Pi Os18e

µ

C/OS-II. Ilparagrafo3.4riepilogale aratteristi heprin ipalidiquestisistemioperativi

onfrontandole onquelledel

µ

TNetOS.

3.1 Salvo RTOS

Salvoèunsistemaoperativoreal-time(RTOS)sviluppatodallaso ietàameri a

Hi-Te h. È un sistema operativo multitasking di tipo ooperativo on pieno

supportoallagestionedeglieventi. Ilmultitaskingèbasatosullivellodipriorità

assegnato ad ogni task. Sono previsti quindi i livelli di priorità e i pro essi

on lastessaprioritàvengonoserviti on unastrategiadi tiporound-robin. La

gestionedeglieventiprevedel'usodisemafori,messaggie odedimessaggiperle

omuni azionifrapro essieperlagestionedellerisorse. Salvoès rittoinANSI

C, er andodi limitarealminimoindispensabilel'usodell'assembler,spe i o

di ogni pro essore. La s elta del C, piuttosto he dell'assembly, permette a

Salvodi esserefa ilmenteportabilesuunavastagammadipro essori,daiPIC

alPentium,peresempio.

L'ammontaredi memoriaROMeRAMri hiestadipendedal tipodi

appli- azione: unaappli azionemultitaskingminimalepuòusaresolopo he entinaia

di istruzionima hina, mentre un'appli azionepiù omplessa potrebbe

ri hie-dere, sullo stesso pro essore, an he un migliaiodi istruzioni. In ogni aso, la

quantità di memoria RAM ri hiesta dipende prin ipalmente dalla dimensione

ompilazione enon possono ambiare a run-time. Sonosempli i funzioni he

onsistonoin una inizializzazione (opzionale) seguita da un i lo innito

on-tenente almenoun ambio di ontesto; non possono avere nessun parametro.

Una volta reato, il task viene posto nello statodi attesa. An hé il

multi-taskingfunzioni orrettamente,il taskin ese uzione deve ritornareil ontrollo

allo s heduler; iò avvieneattraversoun ambio di ontestoall'interno del

ta-sk. Ilnumerodi tasked eventi gestibilidaSalvodipende es lusivamente dalla

memoriadisponibile.

Un'appli azioneSalvoèuna ombinazionedi hiamatealleroutinediservizio

del sistema operativo e di odi e appli ativo. Un esempio di appli azione è

mostratonellistato4.

Salvo è un sistema operativo a pagamento, ma la Hi-Te h ha da qual he

annorilas iato an he una versione freeware hiamata SalvoLite, he limita il

numerodi taskedi eventigestibili.

3.2 Pi Os18

PICos18èunsistema operativoreal-time on multitasking di tipopreemptive

prodottodallaso ietàfran esePRAGMATECedestinatoallafamigliadeiPIC

18. Ilmultitaskingèbasatosuunlivellodiprioritàassegnatoadognitask: itask

on prioritàpiùalta hannodirittodi prelazione suitask di priorità piùbassa.

I task on la stessa priorità vengono serviti on una strategia di tipo

round-robin. Il nu leo è stato s ritto in ANSI C. La gestione degli eventi prevede

es lusivamentel'usodi semafori.

I task vengonodi hiarati stati amente assieme al kernel durante lafase di

ompilazionee non possono ambiarearun-time. Ilnumero massimo di task

eseguibilidal PICos18 è16, unnumero più he su iente per appli azioni su

mi ro ontrollore. Adognitaskèpossibileasso iareunmassimodi ottoeventi.

I listati 5 e 7 mostrano ome sia possibile eseguire un'appli azione on due

task on il Pi Os18. Ilprimo le ( main. ) èl'appli azione prin ipale, mentre

il se ondo( taskdes . ) ontiene tutte le informazioni riguardantii task ele

risorse utilizzate per una data appli azione. L'implementazione di ogni task

risiedeinunlesorgenteaparte;perinostriduetaskd'esempioèmostratanel

listato6.

Ogni volta he si rea un task e si aggiunge ad una appli azione, il

pro-grammatoredevemanualmente editare il le taskdes . perinseriretutte le

Listato 4Esempiodiunaappli azioneSalvo. Iduetask, TaskA(),TaskBnon

fannoniente e,poi héhannolastessapriorità(10),sempli emente sialternano

fra loro. Il ambio di ontestori hiede heognitask siaindenti atoda

un'e-ti hettaunivo a. Questaeti hetta viene reataattraversolama ro_OSLabel.

OSInit()inizializzalestrutturedatidelsistemaoperativoedeveessere

ri hia-mata prima di qualsiasi altra routine di servizio. OSS hed è lo s heduler del

sistema edeettuaiterarivamenteleseguentitre operazioni:

•

Controllasesisonoveri atideglieventi. In asoaermativo,tuttiitask hesieranopreventivamenteregistratiaduneventovengonopassatinello

statopronto,

•

Controlla se è s aduto il tempo di attesa di qual he task. In aso aermativotalitaskvengonopassatinellostatopronto,

•

Inne,vienemandato inese uzioneil tasksu essivo;

Lafunzione OS_Yieldeettua un ambiodi ontestoedin generesitrovaalla

nedel i loinnitodeltask. LafunzioneOSCreateTask reailtask;OSTCBPè

unama routilizzataperspe i areunpuntatorealtask ontrolblo k , ioèalla

struttura he ontieneleinformazionisultask.

_OSLabel(TaskA1) _OSLabel(TaskB1) void TaskA( void ) { for (;;) /

∗

Body here

∗

/ OS_Yield(TaskA1); } void TaskB( void ) { for (;;) /

∗

Body here

∗

/ OS_Yield(TaskB1); } int main( void ) { Init(); OSInit();

OSCreateTask(TaskA, OSTCBP(1), 10);

OSCreateTask(TaskB, OSTCBP(2), 10);

for (;;)

A dierenza di Salvo, il nu leo di PICOs18 è open-sour e ed è distribuito

gratuitamentesottoli enzaGPL.

Listato 5Esempio di appli azione on Pi Os18. Per prima osa siinizializza

ilpuntatore allosta k( STKPTR)esiselezionalamodalitàdi default

dell'appli- azione. Lasys allInitsio upa diripulirelamemoriadatiedi inizializzare

eventualirisorse(ilregistroTimer0,peresempio). Lasys allStartOSfapartire

ilmultitasking. #define DEFAULT_MODE 0 AppModeType Sele tedMode; void main(void) { STKPTR = 0; Sele tedMode =DEFAULT_MODE; Init(); while(1) { StartOS(Sele tedMode); } }

Listato 6 Implementazione dei task in Pi Os18. All'interno del i lo innto

deveessereinserito il odi e he des riveil omportamentodei task. Lo

s he-dulingè preemptive quindi, adierenza di Salvo,non è ne essario ri hiamare

al unasys allperil ambiodi ontesto.

TASK(TASK0) { while(1) { /

∗

Body here

∗

/ } } TASK(TASK1) { while(1) { /

∗

Body here

∗

/ }

Listato 7 Denizione dei task in Pi Os18. Per ogni task si devono inserire

le seguenti informazioni: priorità, indirizzo dellosta kasso iato al task esua

dimensione, nomedeltask,statoiniziale.

#define DEFAULT_STACK_SIZE 128

De lareTask(TASK0);

De lareTask(TASK1);

volatile unsigned har sta k0[DEFAULT_STACK_SIZE℄;

volatile unsigned har sta k1[DEFAULT_STACK_SIZE℄;

rom_des _tsk rom_des _task0 = {

TASK0_PRIO, /

∗

prioinit from 0 to 15

∗

/ sta k0, /

∗

sta k address (16 bits)

∗

/ TASK0, /

∗

start address (16 bits)

∗

/ READY, /

∗

state at init phase

∗

/

TASK0_ID, /

∗

id_tsk from 1 to 15

∗

/

sizeof(sta k0) /

∗

sta k size (16 bits)

∗

/ }; rom_des _tsk rom_des _task1 = { TASK1_PRIO, sta k1, TASK1, READY, TASK1_ID, sizeof(sta k1)

3.3

µ

C/OS-II

µ

C/OS-IIèunsistemaoperativoreal-time onmultitaskingditipopreemptive prodottodallaso ietàameri anaMi riumIn .

I task vengonodi hiarati stati amente assieme al kernel durante lafase di

ompilazione e non possono ambiare a run-time. Il numero massimo di

ta-sk eseguibili è 63 ed il multitasking è basato sul livello di priorità assegnato

ad ognuno di essi. I livelli di priorità sono 63 e due task non possono avere

lostesso livello; di onseguenza, adierenza del Pi Os18, non è prevista una

strategiadi s heduling round robin. La gestione degli eventi prevede l'uso di

semafori,messaggie odedimessaggi. Iltempodiese uzionedelle hiamatedi

sistemaedellagestionedeglieventiè, omeneiduepre edentisistemioperativi,

ompletamente deterministi o. Ciò vuoldire hel'utente èsemprein gradodi

sapere quanto tempoimpiegheràil sistema ad eseguireuna sys all oa gestire

unevento,indipendentementedalnumeroditaskin ese uzione 1

.

µ

C/OS-II può essere eseguito su una vasta gammadi ar hitetture, tra le quali i PIC 18 della Mi ro hip, i mi ro ontrollori Frees ale della Motorola, i

mi ropro essori ARM7, per itarne al uni. Il listato 8 mostra un esempio di

omeimplementareun'appli azione onduetask.

La li enza è proprietaria, ma è possibile a quistare i sorgenti per s opi

didatti i. Ilnu leo èstatos rittoin ANSIC.

3.3.

µ

C/OS-II 35

Listato 8Esempio di appli azione on

µ

C/OS-II. OS_STK èla struttura dati utilizzataperdenireladimensionedellosta kdiognitask. OSInitinizializza

ilsistemaoperativoe,inparti olare, reauntaskidle heverràeseguitoquando

nessun taskutente èpronto perl'ese uzione. OSTaskCreate()vieneutilizzata

per reareuntaskeri hiedequattroargomenti: ilpuntatoreal odi edeltask,

il puntatore dell'argomento deltask( pdata),il puntatorealla imadellosta k

deltask, laprioritàdeltask. OSStartavviail multitasking.

OS_STK Task1Stk[100℄;

OS_STK Task2Stk[200℄;

void Task1(void

∗

pdata) { //task loop

for(;;) {

/

∗

Body here

∗

/ }

}

void Task2(void

∗

pdata) { // task loop

for(;;) {

/

∗

Body here

∗

/ }

}

void main (void) {

OSInit();

OSTaskCreate(Task1, (void

∗

)0, &Task1Stk[0℄, 1); OSTaskCreate(Task2, (void

∗

)0, &Task2Stk[0℄, 2); OSStart();

3.4 Con lusioni

Queste apitolo ha voluto fornire una brevepanorami a dei prin ipalisistemi

operativi perla famiglia PIC 18F. Abbiamo preso in onsiderazione i sistemi

operativi piùnoti epiù utilizzati. Vale la pena qui ri ordarean he il sistema

operativo FreeRTOS, un progetto open sour e he rispetto agli altri è nato

re entemente. Intabella 3.1 vengono riepilogate le aratteristi he dei sistemi

operativitrattatiedel

µ

TNetOS, heverràanalizzatoindettaglionel apitolo 5.

Con lusioni

Tabella3.1ConfrontofraimaggiorisistemioperativiperPIC.

Salvo RTOS Pi OS18

µ

C/OS-II

µ

TNetOS

Real Time Si Si Si No

S heduling Cooperativo on Preemptive on Preemptive on Cooperativo on priorità

15livelli dipriorità 15livellidi priorità 63livellidipriorità basatasutimer ondiviso

Numeromassimodi task Dipendedallamemoria 16 63 Dipendedallamemoria

disponibileabordo disponibileabordo

GestionedegliEventi Semafori,messaggi, Semafori Semafori,messaggi, Messaggi

odedimessaggi odedimessaggi

O upazione di memoria

ROM del nu leo 1

7Kbytes 5Kbytes 9Kbytes 8Kbytes

Ar hitetture supportate Vastagamma PIC18-24-30-33 Vastagamma PIC 18F

(PIC,Pentium,et .) (PIC,Frees ale, ATR,et .)

Li enza Apagamento GPL Apagamento Mi rosoft'sSharedSour e

1

Valoremedioindi ativo, al olato onsiderandouna ongurazionemultitasking on supportoalla gestionedi eventi edi ritardi. Peril

µ

TNetOS èstatodeterminatotramiteben hmarkutilizzandoilCompilatoreC18dellaMi ro hip,perglialtritramitedatiforniti onla lorodo umentazione.

Il framework Roboti s4.NET

Roboti s4.NETèunframework diprogrammaziones rittopersviluppare

pro-grammidi ontrollodisistemiroboti iaventiun'ar hitetturabio-like , ioè

ispi-rataalsistemanervosoumano(g. 4.1). Ilmodellosottostantesibasasulla

no-zionedi orpo. Èstatoprogettatoperpermettereilriusodeimoduliefornireun

supportoautomati oall'implementazionedellainfrastrutturadi omuni azione

fradi essi.

Figura 4.1 Confronto fra sistema nervoso biologi o ed ar hitettura

Roboti s4.NET

•

Il Brain ( ervello): è responsabile della parte ognitiva del sistema di ontrollo,

•

LaBodymap: una lasseutilizzataperpermetterela omuni azionetrail Braineilrestodelsistema,

•

Il Body ( orpo): un sistema multi-agente omposto da Roblet, ioè da moduli software indipendenti he omuni ano on il Brain attraversola

Bodymap;

Figura4.2Ar hitetturadiRoboti s4.NET.Ilframeworkfornis e

un'infrastrut-turadi omuni azionepersvilupparesoftware`intelligente'ingradodiinteragire

onilrestodel orpo. Le omuni azionipossono oinvolgereognilivello.

L'obiettivodel frameworkèdi in entivare leastrazioni di programmazione

ri hiesteperimplementareilBodyelaBodymap. Èstatoimplementato

usan-do la piattaforma .NET di Mi rosoft, pertanto si appoggia ai me anismi di

ree tion(vedipar. 1.1)eai ustomattributes(vedipar. 1.1.1) omestrumenti

di hiarativiperdes rivere omeirobletsono onnessifraloroe onlaBodymap.

L'usodeirobletpermettediorganizzareeventualisensorieattuatoriin

grup-pilogi ie onsentedipre-pro essareidati,fornendounprimopassodi

astrazio-ne. Comeesempio, unrobletpuò ri onos ereun ertonumero difa e riprese

daunavideo ameraeinviareallabodymapunalistadellepersoneri onos iute,

roblet è asso iato un thread per la sua ese uzione. Come si vede in g. 4.2

unpro essopuò ontenerediversiroblet,el'ar hitetturapuòesseredistribuita

fra più nodi di una rete. Come nei sistemi viventi, esiste quindi una sortadi

intelligenzaperiferi a apa edieettuareunaprimaelaborazionedeisegnaliin

ingressoalsistema,edirielaborareleinformazioniinviateledalBrain,primadi

trasformarleinazioni.

Iroblet omuni anomediantel'interfa iadirete,analogaallaretediassoni

diunsistemavivente,doveviaggianoipa hetti ontenentileinformazioni. Un

robletèin gradodiri evereattraversolaBodymapimessaggiinviatidalBrain

e di rispondereatali messaggi. Ad esempio,se il Braindi unrobot de idedi

spostareilsistemainavantidiunmetro,invieràaimotori(peresempioiroblet

MotorSxeMotorDx),attraversolaBodymap,ilmessaggio`avantidiunmetro';

questi, unavoltari evutoil messaggio,inizierannoa al olarequantigiridelle

ruotesonone essarian héilrobotsispostiinavantidiunmetroeavvieranno

imotori inmodotaledaeettuarelospostamentori hiesto.

Dall'esempio pre edente,si può intuireuna delle innovazioni fondamentali

he Roboti s4.NETha introdotto nel mondo della roboti a. Ipotizziamo, per

esempio,divolerspostareilnostrosoftwaredi ontrollodaunrobotadunaltro

avente un'ar hitettura hardware dierente. In passatosaremmo stati

ostret-ti a ris rivere il software per riadattare il ontrollo al nuovo hardware. Con

Roboti s4.NET,inve e,ène essarioris riveresoloedes lusivamente iroblete

trasferire poi il Brain dauna piattaformaall'altra, senza dover ambiare una

sola rigadi odi e. Questovuoldire heèpossibile rearerobot aventialloro

interno più programmiin ese uzione rappresentantii roblet dedi ati. A

vvian-do il Brain,questo saràin grado di omandareil robot, senza he nessunogli

abbiadovutodiresu herobot èinstallato; sarannoi robletstessi adinviargli,

mediante laBodymap,lelorointerfa edi omuni azione,dando osì alBrain

un'immagine,alui omprensibile,delnuovosistema.

Questolavoroha portato allo sviluppodi un nuovorobot hiamatoR2D2,

he è diventato il tester per la nuovapiattaforma roboti asviluppata. A

di-mostrazione di quanto aermato, è stato possibile ontrollare, on lo stesso

Brain, due robot aventi ar hitetture ompletamente diverse, ome l'ER1della

EvolutionRoboti sedR2D2,ilrobotsviluppatodalteamdi Roboti s4.NET 1

.

1

4.1 L'infrastruttura di omuni azione

Ilframeworkimplemental'infrastrutturadi omuni azioneusandounsistemaa

messaggi hesi appoggiasul proto olloUDP;imessaggihannounlimite

mas-simodi grandezza parialla MTU dellarete utilizzata. Nel asodel

µ

TNetOS ( ome si vedrà nel ap. 5), la omuni azione avviene tramite interfa ia

se-rialee vedremoquali strategiesono stateadottate per integrareil sistema nel

framework.

ImessaggisonodenitiinXML,inquantorappresentaillinguaggiousatoda

.NETperlaserializzazione;iroblet eil Brainpossonode idere se ondividere

ladenizionedellestrutturedatiopro essaresempli ementelaloro

rappresen-tazioneXML.Questa aratteristi arendeilframeworkpiùs alabileinquantoil

proto ollopermetteildisa oppiamentodei omponenti softwareutilizzati per

denireilsistemadi ontrollodelrobot.

Quandounroblet invia unmessaggio alla Bodymap, questalo inseris e in

unalberoXMLprin ipale;questaoperazionepermettealBraindiaveresempre

unavisioned'insiemedelsistema. QuestoalberoXML,presentenellaBodymap,

rappresenta l'interfa ia di omuni azione frail sistema nervoso entrale ed il

sistemanervosoperiferi oedèassimilabilealnostro ervelletto. Alla ri ezione

di un messaggio, il Brain può rispondere inviando un nuovo messaggio alla

Bodymap, heprovvederàadinviarloalroblet destinatario.

Inviae ezionale,èpossibilerealizzareuna sortadi omuni azionediretta

fra roblet (detti Friend), he generalmente non possono omuni are fra loro.

Questapossibilitàèstataprogettataperimplementareunasortadi

omporta-mento reattivodelrobot: in al une ir ostanze, larispostaadundato evento

esternodeveessereeettuataintempibrevi;puòquindinonesseresi uro

invia-reunmessaggioal ervelloepoiaspettare hesiapro essatoe hevengade isa

una data azione. An he in questo aso, ome nell'organismo umano, quando

'èunperi oloimmediatoil orpodeveesserein gradodi reagirein modonon

os iente. Come esempio si pensi al asoin ui a identalmente mettiamo la

manosuunfuo o: ilbra iosiritraeistantaneamenteedautomati amente.

4.2 Il Brain

IlBrainsvolgelefunzioni ognitivedi ontrolloedalsuointernoospitala

Body-map;quet'ultima,grazieadunMessageListener,avverteilBraindellapresenza

di messaggiin ingresso. Ilproto ollodi omuni azione èasin rono, osì he i

ivarirobletpossonoesseretranquillamenteriavviatiin asodiblo o,senza he

il sistema vadariavviatointeramente. Seunroblet siblo a, laBodymap

es-seràsempli ementedi ri evereinformazionidaesso( omeseunartosmettesse

di omuni areilsuostatoal ervello). Ilroblet,unavoltariavviato, omin erà

nuovamente adinviare informazionialla Bodymap senzanessun bisognodi un

riavviodi quest'ultima. Analogamente,seèlaBodymap asmettere di

funzio-nare, i roblet ontinuano omunque nella omuni azione e il suo riavviosarà

indolore per il resto del sistema. La robustezza della omuni azione è legata

all'impiegodelproto olloUDPpiuttosto heTCP.

4.3 La Bodymap

LaBodymapèla lasse heinterfa iail ervello olrestodel orpo;ingenere

èun omponente in lusonel software hegestis eil Brain. È ompostadadue

parti:

•

unalberoXMLin uivengonoinseritituttiimessaggiri evutidairoblet,

•

unsistema di omuni azione pers ambiaremessaggi on i roblet fa enti partedel orpo;

L'alberoXMLdes rivelostato orrentedel orpo.

Nelmomentoin uiunrobletvieneavviato,siregistraallaBodymap

invian-dole una des rizione XML della propria interfa ia. Questa interfa ia viene

prodottaa edendo alle annotazioni spe i ate nella lasse Roblet prin ipale

tramiteilme anismodeiCustomAttributesfornitodalleAPIdellaRee tion.

Questainterfa ia vieneresadisponibilealBrain omeparte dell'albero XML.

Perognimessaggio heilroblet puògestire,l'interfa ia ontiene untagXML

he lo des rive. A questo punto il Brain è in grado di usare questi messaggi

ome template damodi areerispedirealroblet.

4.4 I Roblet

Dalpuntodivistaimplementativo,unrobletèuna lasse,ouninsiemedi lassi,

heinvia/ri evemessaggial/dalBrainattraversolaBodymap. Iroblet

rappre-sentanoivarielementidiunsistemavivente: omeadesempiounagamba,un

o hio, un ore hioe . La loro ese uzione ètemporizzata e, durante lafase

del-progettato per gestire. Ogni roblet omuni a ontinuamente alla Bodymap il

propriostato, osì omea adenel orpoumano.

Comeesempio,il listato9riportauna lasse he implementa ilbattito

ar-dia odiunroblet, ioèilmessaggiodialive (unasortadipolling) heinquesto

asovieneinviatodalrobletognise ondo.

Listato 9 Esempio di ome si può denire un roblet in Roboti s4.NET. Un

tipi orobletdenis einnanzituttounaopiù lassi he orrispondonoaimessaggi

he saranno s ambiati on la bodymap. La lasse del roblet (in questo aso

HeartBeat) eredita dalla lasse Roblet. Il ostruttore denis e il nome del

roblet, heverràusatopereti hettareimessaggiinviatiallabodymap. Ilmetodo

Runspe ializza il metodo della lasseRobletedenis eil omportamento del

roblet. Inquestosempli eesempio,ilrobletinviaallaBodymapun'istanzadela

lasse Beat ontenente un timestamp. È interessante notare ome il metodo

SendStateprenda ome parametrisoloil messaggio he deveessereinviato: il

destinatariovienedeterminatodall'infrastrutturafornitadalframework.

publi lass Beat : RobletMessage {

publi long ti k;

publi Beat() {

ti k = DateTime.Now.Ti ks;

}

}

[OutputMessage(typeof(HeartBeatMessage))℄

publi lass HeartBeat : RobletBase {

publi HeartBeat():base("HeartBeat Roblet"){}

publi override void Initialize() {

Frequen y = 1;

}

publi override void Run() {

SendState(new Beat());

}

}

Perdes riverel'interfa iadelroblet,vengonoutilizzatiiCustomAttributes;

inparti olareilframework fornis etrepossibilitipi diannotazioni:

•

OutputMessage(type) : èusatoperspe i areiltipodeimessaggiinviati dalroblet,

•

Friend(type): informailframework heilrobletdeltipospe i atopuò omuni aredirettamente (by-passandolaBodymap) onquestoroblet;

Per far partire l'ese uzionedi uno opiù roblet, viene utilizzatauna lasse

denominata Broker. Questa lassefungedaintermediarionella omuni azione

frairobletall'internodelpro essoelaBodymap( hein genereèin ese uzione

in unaltropro esso). Usandoime anismidi ongurazionefornitida.NET,

il broker determinai roblet he deve avviare e lan ia un thread per ias uno

di essi. Inviainoltre allaBodymapl'interfa iadi questiroblet perinformarla

della loroattivazione. Una tipi aappli azioneMainperavviareil Brokerèla

seguente:

stati void Main (string[℄ args) {

Broker.Start();

}

Una voltari evutounmessaggio, ilBrokerloserializzain unmessaggio XML

usandoglistrumentiresidisponibilidallalibreriabasedi.NET.Unasituazione

similesiveri aan hequandoilBraininviamessaggiairoblet: prelevaun

mes-saggio di hiarato ome InputMessagedal roblet, lo modi a opportunamente

e lo invia tramite una SendState. In questo aso il framework si da delle

informazionisul broker ontenutenelmessaggiostessoperspedireilmessaggio

orrettamente. Il listato 10 riporta il messaggio XML generato per il roblet

HeartBeat.

Sebbeneperoranon isiastatalane essitàdifarlo,èpossibileimplementare

roblet heagis ono omeBrokerperaltriroblet;unappro iosimileverrà

utiliz-zatonelCap. 5perintegrareil funzionamentodelsistema operativo

µ

TNetOS all'internodi questoframework.

4.5 Con lusioni

Questo apitolo ha fornito una des rizione dell'infrastruttura Roboti s4.NET

progettata per sistemi roboti i on ar hitettura bio-like. Il

µ

TNetOS èstata progettato prevedendo una sua integrazione on questa infrastruttura e, nei

Listato 10 MessaggioXML generatoperil roblet HeartBeat(listato9). Fra

tuttii ampipresentinelmessaggiosolol'ultimo,ti k ,èdi hiaratonel

messag-gio. Gli altri ampi sonoereditatidalla lasseRobletMessageevengonousati

dalframeworkperimplementarel'infrastrutturadi omuni azione. Ogniagente

haunproprioID heglivieneassegnatodallaBodymapdurante lapro edura

diregistrazione.

<?xml version="1.0"?>

<Beat xmlns:xsd="http://www.w3.org/2001/XMLS hema"

xmlns:xsi="http://www.w3.org/2001/XMLS hema

−

instan e"> <Name>HeartBeatRoblet</Name>

<AgentID>0</AgentID>

<BrokerHost>192.168.0.1</BrokerHost>

<BrokerPort>6667</BrokerPort>

<Type>Data</ Type>

<ti k>632321535699885456</ti k>

µ

TNetOS

Il

µ

TNetOS (SistemaOperativoperMi ro ontrollori onsupportodiretee Ti-mer per a odamento task) è unmi ro kernel on s heduling ooperativoper

mi ro ontrollori PIC 18F. Il sistema si basa su un'ar hitettura di time

sha-ring, graziealla qualeè possibile avere piùpro essi in ese uzione in gradodi

ondividereununi opro essore,inunmododettatodalleesigenzedelsistema.

Ilsistemaèstatos rittoinC,utilizzandoillinguaggioassemblersoltantoper

leoperazionistrettamentene essarie(interruzionieWat hdogTimer). Questa

s elta ihapermesso di on entrar i maggiormente sulla parte software,

dele-gando al ompilatorelagestionedi piùbasso livello dell'ar hitettura. Inoltre,

l'uso del Crende possibile, on po hissimemodi he, il porting del

µ

TNetOS su tuttiimi ro ontrollori dellafamiglia 18FdellaMi ro hip, osa hesarebbe

stataimpossibileprogrammandodirettamenteinlinguaggioassembler.

Ilquesto apitoloanalizzeremol'implementazione`stati a'del sistema

ope-rativo,rimandandoal apitolo6lades rizionedellapartedinami a.

5.1 Il Compilatore C18

Il

µ

TNetOS èstatos rittoin linguaggioCutilizzandoil ompilatoreC18della Mi ro hip. Sul mer ato esistono diversi ompilatori ANSI C per PICmi ro,

qualeperesempioil PICCdella Hi-Te h. Las eltaèri aduta sul ompilatore

C18 per al une sue aratteristi he ritenute fondamentali per la s rittura del

sistema operativo,quali:

•

Piena ompatibilità on l'ANSI C '89, in parti olare è possibile imple-mentare i puntatori afunzioni elefunzioni ri orsive , aratteristi henon