1 / 36

Esercizio Temperatura

Esercizio Temperatura.

martena-clayton
Download Presentation

Esercizio Temperatura

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Esercizio Temperatura • Una stanza e’ monitorata da 4 sensori di temperatura, i quali sono pilotati da un PD32. Quest’ultimo controlla costantemente che il valor medio della temperatura rilevata nella stanza sia compreso tra i valori [Tmin-Tmax]. Nel caso in cui il valor medio della temperatura non cada in tale intervallo, il microprocessore inviera’ un segnale di allarme su un’apposita periferica, detta ALARM. Il segnale d’allarme utilizzato e’ il valore 1 codificato con 8 bit. Se la temperatura ritorna all’interno dell’intervallo [Tmin-Tmax], la CPU invia sulla periferica ALARM il valore 0. • I sensori ritornano la temperatura misurata come un numero intero ad 8 bit, usando i decimi di gradi Celsius come unita’ di misura. • Scrivere il codice assembly per il controllo dei sensori di temperatura e della periferica di allarme.

  2. ASF Esercizio newTemp, T_media NON in [Tmin-Tmax]/ - newTemp,T_media NON in [Tmin-Tmax] / Alarm_ON T_media in [Tmin-Tmax] T_media fuori da [Tmin-Tmax] newTemp, T_media in [Tmin-Tmax] / - newTemp,T_media in [Tmin-Tmax] / Alarm_OFF Legenda per le transizioni: Input, Condizione / Output

  3. Esercizio Temperatura T_media=Ts1=Ts2=Ts3=Ts4= = (Tmin+Tmax)/2 Stato=IN_RANGE controlla dev.succ Polling dev i ready? NO SI Input da dev_i: new_T_si Stato=OUT Stato=IN Ricalcola media: T_media=T_media+(new_T_si-old_T_si)/4 SI SI T_media in_range? Stato = IN Stato = OUT SI NO NO NO OUTPUT: ALARM ON OUTPUT: ALARM OFF

  4. Dal busy-wait all’interrupt Tecniche di interazione con periferiche di I/O finora studiate sono: Polling Busy-waiting Entrambe nella categoria sincrona. Adesso analizzeremo per la categoria asincrona, la metodologia ad interrupt Interrupt = interruzione. La periferica, una volta avviata, procederà in maniera autonoma fino a che non avrà completato la sua elaborazione ed interromperà il processore per avvertire che ha terminato. IL PROCESSORE DOPO AVER AVVIATO LA PERIFERICA CONTINUA LA SUA NORMALE ESECUZIONE.

  5. Dal busy-wait all’interrupt Si assuma che per l’interrogazione di un dispositivo, incluso il trasferimento del controllo alla procedura di gestione, l’accesso al dispositivo, ed il ritorno al programma utente, siano necessari 400 cicli e che il processore lavori con una frequenza di clock di 2 GHz. Si calcoli la frazione di tempo di CPU consumata nei seguenti casi, assumendo che si esegua una interrogazione del dispositvo tramite busy-wait con una frequenza sufficiente a far sì che nessun dato venga mai perso e supponendo che i dispositivi siano potenzialmente sempre al lavoro. 1. Mouse => per non perdere alcun movimento dell’utente deve essere interrogato almeno 30 volte al secondo. 2. CDROM player (20X)=> trasferisce dati al processore in blocchi da 8 bytes ad un tasso di 3 MB/s. Non è permesso perdere dati. 3. Hard Disk => trasferisce dati in blocchi da 4 longwords con un throughput max di 16 MB/s. Di nuovo non è permesso perdere dati.

  6. Soluzione 1 MOUSE Cicli di clock per secondo per l’interrogazione= 30 * 400=12000 cicli/sec % cicli di clock del processore utilizzati= 12 * 103 = 0,0012% 1000 * 106 CD-ROM PLAYER (20x =>3 MB/sec) Frequenza di interrogazione=3000 Kb/sec =375K accessi/sec 8 byte/accesso Cicli per secondo spesi dalla CPU= 375K * 400 = 150*106 % processore utilizzato= 150 * 106 = 7,5% 2000 * 106 Ignoriamo la discrepanza tra base 2 e base 10

  7. Soluzione 2 HARD DISK Frequenza di interrogazione=16 Mb/sec =1 M=10 6 accessi/sec 16 byte/accesso Ignoriamo la discrepanza tra base 2 e base 10 Cicli per secondo spesi= 400 * 106 % processore utilizzato= 400 * 106 = 20% 2000 * 106 Osservazione: Per il mouse l’ipotesi di costante attività ha senso e l’ overhead è accettabile (frequenza di interrogazione necessaria è bas- sa). CD-ROM e HD sono attivati solo quando è esplicitamente richiesto dal sistema operativo, e non costantemente. L’overhead medio è quindi minore a quello da noi calcolato, assumendo che il dispositivo sia sempre attivo. Tuttavia, nel momento in cui il SO inizia una operazione sul dispositivo, questo deve essere interrogato costantemente perché non è possibile sapere a priori quando il dispositivo avvierà effettivamente il trasferimento.

  8. Ridurre overhead • Idea : utilizzare un meccanismo per segnalare al processore quando un dispositivo di I/O richiede la sua attenzione=> le interruzioni. • Problemi: • Evitare che il verificarsi di un’interruzione non provochi interferenze indesiderate con il programma interrotto. => Salvataggio del contesto • Una CPU può colloquiare con diversi devices, i quali devono essere gestiti tramite routine specifiche => necessità di identificare l’origine dell’interruzione • 3. Gestire richieste concorrenti di interruzione o interruzioni che pervengono al processore mentre è già in corso un’interruzione (si dovrà interrompere la routine di servizio del primo interrupt?). =>definizione della gerarchia di priorità.

  9. Fasi per la gestione dell’interrupt • Salvare lo stato del processo in esecuzione; • Identificare il programma di servizio relativo all'interruzione (driver); • Eseguire il programma di servizio; • Riprendere le attività lasciate in sospeso.

  10. Context switch • Il contesto su cui opera un programma è costituito da: • Il registo PC: contiene l’indirizzo dell’istruzione da cui dovrà essere ripresa l’esecuzione del programma interrotto • Il registro di stato • I registri del modulo ALU, compresi i bit di condizione, che possono contenere valori che il programma interrotto non ha terminato di elaborare. Gestendo l’interruzione solo prima della fase di fetch, quando l’esecuzione dell’istruzione precedente è completamente conclusa, possiamo evitare di memorizzare sia questi registri, che lo stato del microprogramma. • Quando si verifica un’interruzione avviene una commutazione dal contesto del programma interrotto a quello della routine di servizio. • Analogamente il contesto del programma interrotto deve essere ripristinato una volta conclusa la routine di servizio.

  11. CPU Context switch 2 Occorre impedire che si verifichino altre interruzioni mentre sono in corso le operazioni di commutazione, pena possibili incongruenze tra i valori presenti nei registri di un contesto commutato solo parzialmente. Per fare ciò quando, al termine dell’esecuzione di un’istruzione, il segnale IRQ=0 assume valore 1, il flip-flop I viene settato a 0 via firmware. Inoltre il PD32 provvede a salvare nello stack lo SR e il PC. Infine, nel PC è caricato l’indirizzo della routine di servizio del device che ha richiesto l’interruzione. Vcc INT IRQi-1 IRQi IRQi+1 I Modulo interfaccia i-1 Modulo interfaccia i Modulo interfaccia i+1

  12. 2 0 1 prima perife. prog.servizio Indirizzo iniziale Riconoscimento interruzioni (IVN) INT Periferica IACK CPU identificazione periferica PUSH … 3 . . . 4 Indirizzo 5 iniziale Identificativo Periferica x 4 6 prog.servizio POP 7 seconda perife. RTI . . . 4*i Indirizzo 4*i+1 iniziale 4*i+2 prog.servizio 4*i+3 perife. i-esima

  13. Priorità nella gestione interrupt • Introdurre una gerarchia per la gestione delle interruzioni consiste essenzialmente nel definire dei meccanismi per: • Stabilire quale dispositivo debba essere servito per primo nel caso di richieste contemporanee. • Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. • Tali meccanismi possono essere implementati via hardware (vedi controllore interruzione a priorità) o, nel caso in cui non via un supporto hardware dedicato, via software.

  14. Priorità tra dispositivi SERVIZIO LIVELLO 2 FINE INTERR. SERVIZIO LIVELLO 1 FINE PRIORITA’ CRESCENTE SERVIZIO RIPRESA SERVIZIO LIVELLO 0 FINE INTERR. PROGRAMMA PRINCIPALE RIPRESA PROGRAMMA PRINCIPALE t IR0 IR2 IR1

  15. Implementazione gerarchia Gestire la gerarchia di priorità delle interruzioni via software

  16. Gestione priorità / 1 1) Stabilire quale dispositivo debba essere servito per primo nel caso di richieste contemporanee. Soluzione Hardware: si utilizza il segnale di IACK propagato in daisy-chain per il riconoscimento dell’origine dell’interruzione. Così facendo si introduce una priorità che è funzione della “distanza” dal processore (la periferica più vicina ha priorità max). Una soluzione alternativa implementabile via software è di interrogare una dopo l’altro le periferiche (polling). L’ordine di interrogazione definisce la priorità nella gestione delle interruzioni.

  17. 2) Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. • Abbiamo già studiato una soluzione hw a tale scopo. • Una possibile alternativa implementabile completamente tramite • software prevede che: • Ogni routine di servizio che prevede di essere interrotta (di priorità non max) debba rendere il processore nuovamente interrompibile (SETI). • Per inibire i dispositivi a priorità minore, prima della SETI devono essere opportunamente mascherati i flip-flop IM dei devices presenti, cosi’ da stabilire da quali di questi, la routine di servizio possa essere interrotta. • Lo stato di interrompibilità, definito dai valori dei registri IM dei dispositivi al momento dell’interruzione, fa parte del contesto del programma e va ripristinato prima della RTI. • Prima di rendere interrompibile il processore deve essere rimossa la causa dell’interruzione stessa, per evitare lo stack overflow. Si può raggiungere questo scopo impedendo alla periferica di generare altre interruzioni con CLRIM. Anche resettando il flip-flop di status (START,CLEAR) , rimuoviamo la causa dell’interruzione, ma non inibiamo la periferica a generarne altri. Di conseguenza possono sorgere problemi nel caso in cui un driver sia interrotto da una nuova richiesta di interruzione a cui è associato lo stesso driver! Conflitti sui dati e sul codice!

  18. Gestione priorità / 3 2) Consentire che il servizio di una interruzione possa essere a sua volta interrotto da dispositivi più prioritari. 5) Il ripristino del contesto deve avvenire con il processore non interrompibile, per evitare le incongruenze che potrebbero sorgere a causa di una commutazione incompleta. Ad esempio, si consideri il driver periferica di priorità “media” (interrompibile solo da device con priorità “alta” e non da device con priorità “bassa”) …; codice del driver per device con priorità media SET I; il processore è interrompibile … ; fine codice, inizio ripristino contesto setim dev_low_priority; pop …; altre op. ripristino contesto pop …; rti Se arriva un’interruzione da parte del device a bassa priorità, questa viene subito servita ed è violata la gerarchia di priorità!

  19. Gestione priorità / Esempio 3 rilevatori di movimento sono connessi al PD32. Quando viene rilevato un movimento, i sensori generano una richiesta di interruzione. Si vuole servire le interruzioni provenienti dai sensori con la seguente priorità : Sensore0 Sensore1 Sensore2 Priorità crescente Driver sensore 1: SETIM Sensore2 CLRIM Sensore1 CLRIM Sensore0 SETI …. …. CLRI SETIM Sensore0 SETIM Sensore1 RTI Driver sensore 2: …. …. RTI Driver sensore 0: SETIM Sensore1 SETIM Sensore2 CLRIM Sensore0 SETI …. …. CLRI SETIM Sensore0 RTI

  20. Interruzioni & PD32

  21. Riassumendo interruzioni PD32 • Periferica attiva il segnale di interruzione sul Control Bus di I/O • Prima della fase di fetch il PD32 si preoccupa di controllare se ci sono richieste pendenti di interruzione • Legge l’IVN della periferica che ha lanciato l’interruzione, lo moltiplica per 4 ed accedere all’area di memoria in cui è memorizzata la routine di servizio (driver) • All’attivazione del driver viene fatto un cambio di contesto, salvando SR e PC. Viene effettuata l’istruzione CLRI inibendo la ricezione di eventuali nuove interruzioni • All’esecuzione del comando RTI al termine della routine viene fatta automaticamente un ripristino di PC e SR

  22. Progettiamo la nuova periferica per le interruzioni tenendo presente il F/F di mascheramento

  23. Generica interfaccia di Input

  24. Esercizio Interruzioni Scambio di dati da periferica di input e periferica di output Si vuole realizzare lo scambio dei dati, in formato byte, tra una periferica di input e una di output. Lo scambio avverrà attraverso l’uso di un buffer, di un byte, allocato in RAM. La periferica di input caricherà il buffer con il dato “prodotto”, quella di output lo scaricherà “consumandolo”. Si deve inoltre impedire che la periferica di input possa inviare un nuovo dato, fino a che il buffer non sarà vuoto. Analogamente la periferica di output non potrà consumare dati se il buffer è vuoto.

  25. Interrupt da OUTPUT device Interrupt da INPUT device Salva R0 nello stack Salva R0 nello stack si si Buffer vuoto Buffer pieno no no Inibisce OUTPUT dev CLRIM output Inibisce INPUT dev CLRIM input Resetta flag: buffer vuoto Setta flag: buffer pieno Ripristina contesto ed esci Ripristina contesto ed esci OUTB buffer,output START output INB input,buffer START input INPUT device ha IM abilitato? Output device ha IM abilitato? no no si SETIM input si SETIM output Ripristina contesto ed esci Ripristina contesto ed esci

  26. ; PROGRAMMA DIMOSTRATIVO SULL'USO DEI DEVICES ; Una periferica di input invia dati in un buffer di 1byte con il meccanismo degli ; interrupt, la periferica di output preleva il dato dal suddetto buffer ; Nel simulatore è necessario installare due periferiche: ; INPUT: I/O=I, ind=30h, IVN=2 ; OUTPUT: I/O=O, ind=56h, IVN=7 org 400h ;INIZIO PROGRAMMA input equ 30h ;indirizzo periferica input output equ 56h ;indiririzzo periferica output flag db 0 ;flag =0 buffer vuoto, flag=1 buffer pieno buffer equ 500h ;indirizzo buffer di scambio code ;inizio istruzioni seti ;abilita PD32 ad accettare interruzioni setim input ;abilita periferica di input ad accettare interruzioni setim output ;abilita periferica di output ad accettare interruzioni start input ; avvio produzione del dato start output ; avvio consumo del dato main: jmp main ; progr. Principale = loop infinito

  27. ;DRIVER DI INPUT ;Invia dati al buffer se questo e' pieno pone in attesa la periferica ;di input 0->IM, sblocca (se in attesa) la periferica di output 1->IM driver 2, 600h ;Il driver della periferica con IVN=2 ;inizia dall'ind. 600h pinput: push r0 ;salva contenuto di R0 movb flag,r0 ;carica flag in R0 cmpb #1,r0 ;controlla se buffer pieno jz inibisci ;se pieno pongo in attesa la periferica di input accetta: ;altrimenti invia dato movb #1,flag ;pongo il flag=1 (buffer pieno) inb input,buffer ;carico dato nel buffer start input ;abilito device a generare un nuovo dato ed elimino la causa dell’interruzione jnim output,sbloccato ;se periferica di output e' in attesa la sblocco jmp fineinp ;termina inibisci: clrim input ;pone perif. input in attesa (buffer pieno) fineinp: pop r0 ;fine driver rti ;ritorno da interruzione sbloccato:setim output ;sblocco periferica output jmp fineinp ;FINE DRIVER DI INPUT

  28. ;DRIVER DI OUTPUT ;Preleva dati dal buffer se questo e' vuoto pone in attesa la periferica ;di output 0->IM, sblocca (se in attesa) la periferica di input 1->IM driver 7,700h ;Il driver della periferica di IVN=7 ;inizia dall'indirizzo 700h poutput: push r0 ;salva contenuto di R0 movb flag,r0 ;carica flag in R0 cmpb #0,r0 ;il buffer e' vuoto? jz blocca ;se vuoto pongo in attesa la periferica di output consuma: outb buffer,output ;altrimenti invio dato alla periferica di output movb #0,flag ;pongo flag=0 (buffer vuoto) start output ;abilito perif. output a consumare il dato jnim input,sblocca ;se perif. di input 'in attesa' la sblocco jmp esci ;termina blocca: clrim output ;blocco perif. output (buffer vuoto) esci: pop r0 ;termina prog. rti ;ritorna da interruzione sblocca:setim input ;sblocco input jmp esci ;FINE DRIVER DI OUTPUT end ;FINE PROGRAMMA

  29. La gestione dell’I/O tramite interrupts solleva il processore dal peso di attendere il verificarsi degli eventi di I/O. Il costo aggiuntivo può essere comunque intollerabile se i dispositivi con cui si interagisce hanno a disposizione una elevata larghezza di banda.

  30. Un esempio già noto… Una stanza e’ monitorata da 4 sensori di temperatura, i quali sono pilotati da un PD32. Quest’ultimo controlla costantemente che il valor medio della temperatura rilevata nella stanza sia compreso tra i valori [Tmin-Tmax]. Nel caso in cui il valor medio della temperatura non cada in tale intervallo, il microprocessore inviera’ un segnale di allarme su un’apposita periferica (ALARM). Il segnale d’allarme utilizzato e’ il valore 1 codificato con 8 bit. Se la temperatura ritorna all’interno dell’intervallo [Tmin-Tmax], la CPU invia sulla periferica il valore 0. I sensori ritornano la temperatura misurata come un numero intero ad 8 bit, usando i decimi di gradi Celsius come unita’ di misura. Scrivere il codice assembly per il controllo dei sensori di temperatura e della periferica di allarme… utilizzando il meccanismo delle interruzioni vettorizzate (piuttosto che il polling + busy wait).

  31. Il codice (1) org 400h ;INIZIO PROGRAMMA sensore1 equ 0h ; indirizzo sensore1 sensore2 equ 1h ; indirizzo sensore2 sensore3 equ 2h ; indirizzo sensore3 sensore4 equ 3h ; indirizzo sensore4 alarm equ 4h ; indiririzzo periferica allarme lowbound equ 200 ; T-min espresso in decimi di gradi Celsius upbound equ 300 ; T-min espresso in decimi di gradi Celsius media dl 0 ; valore medio della temperatura rilevato baseadd equ 2000h ; buffer contenente la temperatura misurata device dl 0 ; indirizzo ultimo sensore che ha acquisito switch db 0 ; valore da spedire sulla periferica d’allarme state db 0 ; stato allarme (0=off, 1=on) code ;inizio istruzioni main: ;... jsr init ;... loop: jmp loop ;trucco per simulare il codice sul PD32, la periferica è libera per eventuali elaborazioni

  32. Il codice (2) ; subroutine di inizializzazione delle periferiche e avvio acquisizione init: push r0 push r1 ; calcola il centro dell'intervallo [Tmin-Tmax] ... movl #lowbound, R0 ; addl #upbound, R0 ; asrl #1, R0 ; e lo memorizza in R0 movl #baseadd,R1 movl R0, (R1) ; aggiorna i buffer dei 4 movl R0, 4(R1) ; sensori con il valor medio movl R0, 8(R1) ; dell’intervallo movl R0, 12(R1) ; movl R0, media ; inizializza la media movb #0,state ; state memorizza lo stato (IN=0, OUT=1) SETIM sensore1 ; SETIM sensore2 SETIM sensore3 SETIM sensore4 ; abilita i sensori a inviare interruzioni CLRIM alarm ; blocca la periferica d’allarme che al momento non serve SETI ; abilita il processore a ricevere interruzioni

  33. Il codice (3) START sensore1; START sensore2; START sensore3; START sensore4; avvia l’acquisizione dei dati dai sensori di temp. pop r1 pop r0 ret ; fine subroutine init ; DRIVERS driver 0, 1600h ; periferica con IVN 0 ha driver allocato a partire dall’ind 1600h movl #sensore1, device jsr GET rti driver 1, 1650h movl #sensore2, device jsr GET rti driver 2, 1700h …; … e 3

  34. Il codice (4) driver 4, 1800h OUTB SWITCH, alarm ;invia il valore di switch sul buffer di alarm start alarm ;avvia il consumo del dato clrim alarm ;disabilita ulteriori interrupts della periferica rti ; SUBROUTINE GET: ACQUISIZIONE DATI DALLA PERIFERICA IL CUI IND. E’ ; E' SPECIFICATO NELLA VARIAB. DEVICE GET: PUSH r0 push r4 push r5 movl #baseadd, R0 movl device,r5 asll #2,r5 ; r5=device*4 ADDL r5, R0 ; r0=baseadd+device*4 asrl #2,r5 ;ripristina R5 all’address del device INL r5, (R0); preleva il valore e lo mette in RAM nel corrispondente buffer START r5 ; avvia nuova acquisizione JSR NEWMEDIA

  35. Il codice (5) MOVL media, R5 ; carico la media aggiornata in R5 movb state, R4 CMPL #upbound , R5 JNC OUT ; upbound <= R5 CMPL #lowbound, R5 JC OUT ;lowbound > R5; altrimenti siamo nell'intervallo CMPb #0, R4 ; verifico se lo stato era IN=0 o OUT=1 JNZ eraout exit: pop r5 pop r4 pop r0 RET eraout: MOVb #0 ,switch SETIM alarm movb #0, state jmp exit OUT: CMPb #0, R4 ; verifico se lo stato era IN=0 o OUT=1 JZ erain ; jmp exit

  36. Il codice (6) erain: MOVb #1 ,switch SETIM alarm movb #1, state jmp exit ; aggiorna la media in base ai valori presenti nelle 4 longwords a partire da baseadd NEWMEDIA: PUSH R0 PUSH R1 MOVL #baseadd,R1 XORL R0,R0 ADDL (R1),R0 ADDL 4(R1), R0 ADDL 8(R1), R0 ADDL 12(R1), R0 ASRL #2, R0 MOVL R0, media POP R1 POP R0 RET end

More Related