EMB_75

53 EMBEDDED FEBBRAIO RTOS TOOLS | SOFTWARE = À seguito) dei task o sulle etichette degli eventi è possibile visualizzare le relative informazioni, ovvero un elenco cronologico di tutte le esecuzioni del task selezionato. Con Tracealyzer è possibile visualizzare l’ambien- te runtime sotto diverse angolazioni, compresi i À 7 = tempo utilizzato dal processore) e dei tempi di ri- sposta (il tempo effettivo intercorso tra l’inizio e la À / À À Ÿ In questo esempio i tempi di esecuzione sono ab- bastanza stabili per entrambi i task, anche se a volte il tempo di risposta del task evidenziato come “sensor Z”, è maggiore. Cliccando su uno dei dati è possibile visualizzare il corrisponden- te intervallo nella vista della trace principale (si À P/ Tutte le visualizzazioni in Tracealyzer sono cor- relate in maniera analoga. Semafori e code Anche se un RTOS permette di suddividere il codice in task di dimensioni inferiori, raramente tali task sono completamente indipendenti. Essi devono scambiare dati gli uni con gli altri, sincro- nizzare l’accesso alle risorse hardware condivise e così via. L’implementazione di una sincroniz- zazione “thread-safe” (ovvero non devono esserci Á Ÿ - mente la stessa funzione) richiede o la disabili- tazione degli interrupt oppure l’utilizzo di istru- zioni speciali per un’operazione di “test-and-set” atomica (quindi inscindibile, non soggetta a in- terruzioni). In base a questa considerazione, è so- litamente più semplice (e anche più sicuro) utiliz- zare i servizi dell’RTOS destinati a questo scopo come i semafori e le code. Inversione di priorità In linea di principio, un task a elevata priorità = À + À ˜/ - vrebbe mai essere bloccato da task a più bassa priorità. Nella pratica, alcune decisioni prese in fase di progetto possono far sì che una condizio- À Questa condizione, nota sotto il nome di “inver- sione di priorità” (priority inversion) è stata la causa dei problemi incontrati dalla NASA nella J { À y l’inversione e apportati gli opportuni aggiorna- menti software, questi problemi sono stati risolti. Lo scenario che dà luogo all’inversione può esse- — À y 7 =[ 7 +/ † = binario) attualmente detenuto da un task a prio- = 7 ;/ [ 7 + ' — ma ciò di solito non rappresenta un problema in † - riodo di tempo. Il blocco può però protrarsi per un tempo più lungo se un task di media priorità (Task M) interrompe il task L, ritardando in tal † ; W[&# † che supportano il meccanismo di “Priority Inhe- ritance” (in pratica l’eredità della priorità) che permette di aumentare la priorità del task che † 7 - Fig. 2 – Tempi di esecuzione e di risposta per ciascuna esecuzione dei due task Fig. 1 – Tracealyzer mostra la schedulazione dei task dell’RTOS e le chiamate ai servizi dell’RTOS