ARCHITETTURE SOFTWARE

Transcript

1 1 ESECUZIONE DI APPLICAZIONI SU SISTEMI EMBEDDED INTRODUZIONE AI SO EMBEDDED INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE ROUND ROBIN INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE ROUND ROBIN WITH INTERRUPTS INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA FUNCTION QUEUE SCHEDULING INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: CENNI DI SISTEMI OPERATIVI REAL-TIME 2 INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE ROUND ROBIN

2 ARCHITETTURE SOFTWARE 3 IN RELAZIONE AL FUNZIONAMENTO REALE DELLE APPLICAZIONI SU SISTEMI EMBEDDED IL COMPORTAMENTO DELLE APPLICAZIONI VISTE FINORA NON ERA REALISTICO L'ARCHITETTURA SOFTWARE PREVEDEVA INFATTI L'ESECUZIONE DI UN CERTO NUMERO DI TASK DOPODICHE' L'APPLICAZIONE SI CONSIDERAVA CONCLUSA. NELLE APPLICAZIONI REALI IL SISTEMA FUNZIONA A PARTIRE DALL'ACCENSIONE FINO AL VENIR MENO DELL'ALIMENTAZIONE O FINO AL RESET. VEDREMO LE ARCHITETTURE SOFTWARE DI BASE TRAMITE LE QUALI E' IMPLEMENTATO TALE FUNZIONAMENTO, A PARTIRE DALLE PIU' SEMPLICI IN ASSOLUTO, FINO AD ARRIVARE AI SISTEMI OPERATIVI REAL TIME (CENNI) VEDREMO NEL DETTAGLIO I 2 ESEMPI PIU' SEMPLICI DI ARCHITETTURA SOFTWARE PER SISTEMI EMBEDDED: ROUND ROBIN ROUND ROBIN CON INTERRUPTS ARCHITETTURA SOFTWARE ROUND ROBIN 4 LA PIU' SEMPLICE ARCHITETTURA SOFTWARE POSSIBILE E' DEFINITA ROUND ROBIN CONSISTE IN UN LOOP INFINITO CHE SI OCCUPA DI INTERROGARE A TURNO (POLLING) CIASCUNA DELLE PERIFERICHE DI I/O E DI ESEGUIRE LE ROUTINE ASSOCIATO OGNI QUALVOLTA SIA NECESSARIO void _main( void ) { while(1) { if (!! la periferica di I/O A deve essere servita ) {!! preleva/spedisci i dati della periferica di I/O A;!! processa i dati della periferica di I/O A; if (!! la periferica di I/O A deve essere servita ) {!! preleva/spedisci i dati della periferica di I/O Z;!! processa i dati della periferica di I/O Z;

3 5 APPLICAZIONE DI ESEMPIO (ES0_S3) APPLICAZIONE DI ESEMPIO 6 void _main( void ) { int CH0_IN_var, CH1_IN_var, CH0_OUT_var; int i, *p_reg_ch0_in, *p_reg_ch1_in, *p_reg_ch0_out; p_reg_ch0_in = (int*) 0x4000; p_reg_ch1_in = (int*)0x4004; p_reg_ch0_out = (int*)0x4008; while( 1) { CH0_IN_var = get_input(p_reg_ch0_in); // acquisisce la temperatura CH1_IN_var = get_input(p_reg_ch1_in); // acquisisce l'umidita if( CH0_IN_var > 42 ){ send2out( 0, p_reg_ch0_out) ; send2out(ch0_in_var, p_reg_ch0_out) ; if( CH1_IN_var > 900 ){ send2out(0, p_reg_ch0_out) ; send2out(ch1_in_var, p_reg_ch0_out) ;

4 ARCHITETTURA SOFTWARE ROUND ROBIN 7 L'ARCHITETTURA SW RR, RISPETTO ALLE ALTRE TIPOLOGIE DI ARCHITETTURA, HA IL VANTAGGIO DI ESSERE LA PIU' SEMPLICE, PRESENTA PERO' LIMITI NOTEVOLI. L'ARCHITETTURA SW RR FUNZIONA BENE NEI SISTEMI CHE VERIFICHINO CONTEMPORANEAMENTE LE SEGUENTI CONDIZIONI: POCHE PORTE DI I/O ELABORAZIONI NON PARTICOLARMENTE LUNGHE VINCOLI DI TEMPI DI RISPOSTA IN INPUT/OUTPUT NON STRINGENTI NEL CASO UNO DEGLI INGRESSI RICHIEDA DEI TEMPI DI RISPOSTA INFERIORI AL TEMPO DI RISPOSTA DEL SISTEMA NEL CASO PEGGIORE, IL SISTEMA NON FUNZIONA E' SUFFICIENTE CHE UNO SOLO DEI TASK ABBIA UNA DURATA ELEVATA, AFFINCHE' IL SISTEMA DIVENTI PRATICAMENTE INSERVIBILE, PUR CONTINUANDO A FUNZIONARE LA STRUTTURA DEL SW NON E' ROBUSTA: PUO' ESSERE SUFFICIENTE L'INSERIMENTO DI UNA NUOVA PERIFERICA DA GESTIRE PER MODIFICARE LA RISPOSTA TEMPORALE COMPLESSIVA IN MANIERA INACCETTABILE 8 INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE ROUND ROBIN CON INTERRUPTS

5 ARCHITETTURA SOFTWARE ROUND ROBIN CON INTERRUPT 9 LA PRIMA ARCHITETTURA ALTERNATIVA CHE VEDIAMO E' LA RR + INT PRESENTA UN INCREMENTO DI COMPLESSITA' MA OFFRE VANTAGGI SOSTANZIALI LA STRUTTURA DELL'ARCHITETTURA PREVEDE CHE: LE ROUTINE DI INTERRUPT (INTERRUPT SERVICE ROUTIN - ISR)SI OCCUPINO DI SERVIRE LE INCOMBENZE URGENTI LEGATE ALLE PERIFERICHE DI I/O SETTANDO DEI FLAG OGNI QUALVOLTA VIENE ACQUISITO/SPEDITO UN DATO IL LOOP PRINCIPALE INTERROGA I FLAG ASSOCIATI ALLE ROUTINE DI INTERRUPT ED ESEGUE LE ELABORAZIONI ASSOCIATE SOLO QUANDO NECESSARIO VIENE INTRODOTTO UNA PRIORITA' NELLA GESTIONE DEI TASK LA GESTIONE DI DATI SOTTO INTERRUPT PONE IL PROBLEMA DELLA GESTIONE DI DATI CONDIVISI FRA ROUTINE DI INTERRUPT E APPLICAZIONE PRINCIPALE: SHARED DATA PROBLEM ARCHITETTURA SOFTWARE ROUND ROBIN CON INTERRUPT SCHEMA DELL'ARCHITETTURA SW BOOL FdeviceA = false;.. BOOL FdeviceZ = false; void interrupt HandleDeviceA {!! preleva/spedisci i dati della periferica di I/O A; FdeviceA = true;... void interrupt HandleDeviceZ {!! preleva/spedisci i dati della periferica di I/O A; FdeviceZ = true; void _main( void ) { while(1) { if ( FdeviceA) { FdeviceA = false;!! processa i dati della periferica di I/O A;... if ( FdeviceZ) { FdeviceZ = false;!! processa i dati della periferica di I/O Z; 10

6 ARCHITETTURE SOFTWARE 11 PRIORITA' RR + INT: SHARED-DATA PROBLEM 12 VIENE DEFINITA IN QUESTO MODO LA PROBLEMATICA LEGATA AI MALFUNZIONAMENTI CAUSATI DALL'ACCESSO ASINCRONO AI DATI DI PROGRAMMA PRINCIPALE E ROUTINE DI INTERRUPT PER MEGLIO CAPIRE IL PROBLEMA UTILIZZIAMO UN ESEMPIO SUPPONIAMO DI UTILIZZARE UN SISTEMA EMBEDDED PER ACQUISIRE DEI VALORI FISICI DI TEMPERATURA DA DEI SENSORI POSTI IN DIVERSI PUNTI DI UN REATTORE NUCLEARE SEGNALARE UN ALLARME SE LE TEMPERATURE ACQUISITE NON SONO UGUALI LA PRIMA ATTIVITA' VIENE ESEGUITA SOTTO INTERRUPT LA SECONDA NELLA ROUTINE PRINCIPALE SUPPONIAMO DI GESTIRE 2 SOLI SENSORI E OMETTIAMO PER SEMPLICITA' ANCHE LA GESTIONE DEI FLAG

7 RR + INT: SHARED-DATA PROBLEM 13 static int temperature[2] static int* preg0 Reg0Addr; static int* preg1 Reg1Addr; void interrupt LeggiTemperature { temperature[0] = *preg0; temperature[1] = *preg1; void _main( void ) { int temp1, temp2; while(1) { temp0 = temperature[0]; INTERRUPT temp1 = temperature[1]; if (temp0!= temp1)!! segnala condizione di allarme; RR + INT: SHARED-DATA PROBLEM 14 NEL CASO SI PRESENTINO ENTRAMBE LE SEGUENTI CONDIZIONI: SI VERIFICA UN INTERRUPT FRA L'ESECUZIONE DELLE 2 ISTRUZIONI CHE ASSEGNANO I VALORI DI TEMPERATURA ALLE 2 VARIABILI temp0 E temp1 LE TEMPERATURE RILEVATE DAI 2 SENSORI, PUR RIMANENDO UGUALI FRA LORO, SONO CAMBIATE RISPETTO ALLE ULTIME RILEVATE SI VERIFICA UNA CONDIZIONE DI ALLARME INGIUSTIFICATA!!!!!

8 RR + INT: SHARED-DATA PROBLEM 15 SI PUO' TENTARE DI ELIMINARE IL PROBLEMA OTTIMIZZANDO IL SOFTWARE NON SERVE PERCHE' LE ROUTINE DI INTERRUPT POSSONO INTERROMPERE IL PROGRAMMA FRA 2 DELLE ISTRUZIONI ASSEMBLY CHE IMPLEMENTANO IL TEST DI UGUAGLIANZA... void interrupt LeggiTemperature { temperature[0] = *preg0; temperature[1] = *preg1; void _main( void ) { INTERRUPT while(1) { if (temperature[0]!= temperature[1])!! segnala condizione di allarme; RR + INT: SHARED-DATA PROBLEM 16 IL PROBLEMA SI VERIFICA QUANDO L'INTERRUPT E IL PROGRAMMA PRINCIPALE CONDIVIDONO DEI DATI, E IL PROGRAMMA PRINCIPALE UTILIZZA QUESTI DATI IN MANIERA NON ATOMICA IL PEZZO DI CODICE LA CUI INTERRUZIONE PUO' GENERARE IL PROBLEMA VIENE DEFINITO CRITICAL SECTION. PER RISOLVERE IL PROBLEMA E' POSSIBILE SFRUTTARE LA POSSIBILITA' DI DISABILITARE GLI INTERRUPT void interrupt LeggiTemperature { temperature[0] = *preg0; temperature[1] = *preg1; void _main( void ) { int temp1, temp2; while(1) { disable_int(); temp0 = temperature[0]; temp1 = temperature[1]; enable_int(); if (temp0!= temp1)!! segnala condizione di allarme; CRITICAL SECTION

9 ARCHITETTURA SOFTWARE ROUND ROBIN CON INTERRUPT 17 LO SVANTAGGIO PRINCIPALE DELLA ARCHITETTURA RR+INT (OLTRE AL FATTO CHE RISULTA PIU' COMPLESSA DELLA RR SEMPLICE) E' CHE TUTTI I TASK DEL PROGRAMMA PRINCIPALE VENGONO GESTITI CON LA STESSA PRIORITA' SUPPONIAMO DI AVERE 3 TASK (A, B E C) GESTITI NEL PROGRAMMA PRINCIPALE ESEGUITI NELL'ORDINE A,B,C. NEL CASO SI VERIFICHINO TUTTI E 3 GLI INTERRUPT ALL'INIZIO DELL'ESECUZIONE DELLA ROUTINE PRINCIPALE PRIMA DI INIZIARE L'ESECUZIONE DI A, IL TEMPO DI ATTESA PRIMA DI POTER ESEGUIRE IL TASK C E' PARI ALLA SOMMA DEI TEMPI DI ESECUZIONE DEI TASK A E B, PIU' I TEMPI DI ESECUZIONE DELLE ROUTINE DI INTERRUPT. CIO' POTREBBE ESSERE NON ACCETTABILE PER LE SPECIFICHE DI TEMPORIZAZIONE DEL TASK C. IN QUESTO CASO SI POTREBBE SPOSTARE LA SEZIONE DI CODICE CHE DEFINISCE IL TASK C SOTTO INTERRUPT COME EFFETTO COLLATERALE OTTENGO PERO' CHE IL TEMPO DI RISPOSTA MASSIMO PER GLI ALTRI 2 TASK (A E B) SI INCREMENTA DI UNA QUANTITA' PARI AL TEMPO DI ESECUZIONE DEL TASK C, E CIO' POTREBBE ESSERE A SUA VOLTA NON ACCETTABILE UN ALTRO SVANTAGGIO FONDAMENTALE E' LA POCA STABILITA' DEL CODICE: MODIFICANDO IL CODICE DI UN TASK SI INFLUENZA IL TEMPO DI RISPOSTA DEGLI ALTRI ARCHITETTURA SOFTWARE ROUND ROBIN CON INTERRUPT 18 NEL CASO DI SEQUENZA DI ESECUZIONE DEI TASK NEL PROGRAMMA PRINCIPALE CHE ESEGUA IN SUCCESSIONE TUTTI I TASK, IL TEMPO DI RISPOSTA DNEL CASO PEGGIORE PER UN TASK E' PARI ALLA SOMMA DEI TEMPI DI ESECUZIONE DI CIASCUNO DEGLI ALTRI TASK PIU' LA SOMMA DEI TEMPI DI ESECUZIONE DI TUTTE LE ROUTINE DI INTERRUPT UN'ALTRA ALTERNATIVA POTREBBE ESSERE USARE UNA SEQUENZA DI ESECUZIONE DEI TASK NEL PROGRAMMA PRINCIPALE CHE PRIVILEGI IL TASK C: C,A,C,B, C,A,C,B, C,A,C,B, QUESTA SOLUZIONE RIDURREBBE IL TEMPO DI ATTESA MINIMO PER C AL MASSIMO FRA I TEMPO DI ESECUZIONE DEI TASK A E B, AL COSTO DI UN AUMENTO DEL TEMPO MASSIMO DI RISPOSTA PER A E B, CHE VERREBBE AUMENTATO DI UN TERMINE C. IN CONCLUSIONE UTILIZZANDO UNA ARCHITETTURE DI TIPO RR+INT SI PUO' TENTARE DI GESTIRE LE SPECIFICHE DI TEMPORIZZAZIONE SUI TASK TRAMITE OTTIMIZZAZIONI DEL CODICE O SPOSTAMENTI DI SEZIONI DI CODICE FRA ROUTINE INTERRUPT E PROGRAMMA PRINCIPALE, MA SI VA INCONTRO A PESANTI EFFETTI COLLATERALI E IL CODICE RISULTANTE RIMANO POCO STABILE RIDUCENDO IL TEMPO DI RISPOSTA DI CASO PEGGIORE PER UN TASK, SI INCREMENTA QUELLO PER TUTTI GLI ALTI TASK

10 19 INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE FUNCTION QUEUE SCHEDULING ARCHITETTURA SOFTWARE FUNCTION QUEUE SCHEDULING QUESTA ARCHITETTURA PREVEDE CHE CIASCUNA ROUTINE DI INTERRUPT COMNICHI AL PROGRAMMA PRINCIPALE L'AVVENUTA ESIGENZA DI ESEGUIRE IL TASK DI ELABORAZIONE ASSOCIATO, NON SETTANDO UN FLAG, MA INSERENDO (PUSH) UN PUNTATORE AL TASK ASSOCIATO ALLA ROUTINE DI INTERRUPT IN UNA CODA DI PUNTATORI A FUNZIONI IL PROGRAMMA PRINCIPALE LEGGE DALLA CODA IL PUNTATORE AD UNA FUNZIONE ED ESEGUE IL TASK STESSO IL TRUCCO STA NEL FATTO CHE NESSUNA REGOLA MI DICE CHE DEVO PER FORZA LEGGERE DALLA CODA LE FUNZIONI NELL'ORDINE IN CUI VI SONO STATE INSERITE POSSO QUINDI PRIVILEGIARE (IN MANIERA ORDINATA E SISTEMATICA) I TASK CON UNA PRIORITA' MAGGIORE POSSO ADDIRITTURA MODIFICARE LA PRIORITA' A TEMPO DI ESECUZIONE ADATTANDOMI AD EVENTUALI MODIFICHE DELLE CONDIZIONI AL CONTORNO IN MANIERA DINAMICA IL TEMPO DI RISPOSTA DI CASO PEGGIORE PER IL TASK CON PRIORITA' PIU' ELEVATA E' PARI AL TEMPO DI ESECUZIONE DEL TASK PIU' LENTO PIU' LA SOMMA DEI TEMPI DI ESECUZIONE DELLE ROUTINE DI INTERRUPT (COME PER RR+INT) PERMANE, ANCHE SE RIDOTTO, IL PROBLEMA DELLA POCA STABILITA' DEL CODICE: MODIFICANDO IL CODICE DI UN TASK SI INFLUENZA IL TEMPO DI RISPOSTA DEGLI ALTRI 20

11 21 INTRODUZIONE AI SISTEMI OPERATIVI EMBEDDED: ARCHITETTURA SOFTWARE REAL TIME OPERATING SYSTEM ARCHITETTURA SOFTWARE RT OS 22 QUESTA ARCHITETTURA (COME LE ALTRE VISTE FINORA) PREVEDE CHE LE ROUTINE DI INTERRUPT SI OCCUPINO DEI DELLE OPERAZIONI PIU' URGENTI (QUELLE LEGATE ALL'I/O) LE ROUTINE DI INTERRUPT SEGNALINO L'AVVENUTA NECESSITA' DI ESEGUIRE IL TASK ASSOCIATO A QUELLA ROUTINE DI INT LA DIFFERENZE RISPETTO AI CASI PRECEDENTI SONO LE SEGUENTI: 1. LA COMUNICAZIONE FRA ROUTINE DI INTERRUPT E TASK DEL PROGRAMMA PRINCIPALE ASSOCIATO VIENE GESTITA DAL SISTEMA OPERATIVO 2. LA SEQUENZA DI ESECUZIONE DEI TASK E' GESTITA DAL SISTEMA OPERATIVO, NON CI SONO LOOP O CODE O ALTRO GESTITI IN MANIERA ESPLICITA DAL PROGRAMMATORE. IL CODICE DEL RT OS SI OCCUPA DELLO SCHEDULING DEI TASK, GESTENDO LE PRIORITA' DI ESECUZIONE NELLA MANIERA PIU' APPROPRIATA 3. IL RT OS PUO' SOSPENDERE L'ESECUZIONE DI UN TASK PER ESEGUIRNE UN ALTRO

12 ARCHITETTURA SOFTWARE RT OS 23 LE PRIME 2 DIFFERENZE FORNISCONO DEI VANTAGGI LEGATI SOPRATTUTTO ALLA MODALITA' DI PROGRAMMAZIONE LA TERZA DIFFERENZA (L'INTERROMPIBILITA' DEI TASK DA PARTE NON SOLO DELLE ROUTINE DI INTERRUPT, MA ANCHE DA PARTE DI ALTRI TASK), E' SOSTANZIALE: UN'ARCHITETTURA SOFTWARE BASATA SU RT OS DA LA POSSIBILITA DI GESTIRE UNA PRIORITA' DI ESCUZIONE SISTEMATICA NON SOLO DELLE ROUTINE DI INTERRUPT, MA ANCHE DEI TASK DEL PROGRAMMA PRINCIPALE IL TEMPO DI RISPOSTA DI CASO PEGGIORE PER IL TASK A PRIORITA' PIU' ELEVATA SI RIDUCE ALLA SOMMA DEI TEMPI DI ESECUZIONE DELLE ROUTINE DI INTERRUPT QUESTO RENDE FINALMENTE L'ARCHITETTURA SW ROBUSTA: MODIFICANDO IL CODICE DI UN TASK NON INFLUENZO IL TEMPO DI RISPOSTA DI QUELLI A PRIORITA' SUPERIORE UN'ALTRO VANTAGGIO CONSIDEREVO DEI RT OS E' CHE SONO REPERIBILI SUL MERCATO. IN QUESTO MODO E' POSSIBILE RIDURRE I TEMPI DI SVILUPPO A COSTI RAGIONEVOLI O ADDIRITTURA NULLI (CODICE FREEWARE), SOPRATTUTTO IN CASO DI UTILIZZO DELLO STESSO RT OS PER APPLICAZIONI DIVERSE LO SVANTAGGIO PRINCIPALE LEGATO ALL'UTILIZZO DI UN RT OS E' LEGATO AL FATTO CHE L'OS STESSO UTILIZZA UNA CERTA QUANTITA' DI TEMPO DI ELABORAZIONE ARCHITETTURE SOFTWARE 24 PRIORITA'

13 ARCHITETTURE SOFTWARE TABELLA RIASSUNTIVA 25