Schede Standard

Come già osservato, in molte applicazioni la soluzione complessivamente più economica consiste nella realizzazione di sistemi basati su sotto-sistemi standard, ovvero schede disponibili sul mercato, per i quali, dunque, l’utilizzatore deve sviluppare “soltanto” il software applicativo.

Questa scelta è caratterizzata da un alto costo dei componenti (sotto-sistemi), ma da ridotti costi e tempi di sviluppo.

Perciò, è adatta a prodotti da sviluppare in un numero ridotto di esemplari e da caratteristiche “standard”, quindi non “ottimizzate” per quanto attiene a prestazioni, consumo, ingombro, …

Peraltro, è adatta ad ambienti con know-how relativamente modesto per quanto riguarda le componenti hardware dei sistemi (che in questo caso sono disponibili sul mercato). In buona sostanza, la soluzione rinuncia a una parte del valore aggiunto del sistema (ed anche alla sua originalità) in cambio di una facile e rapida realizzazione.

Un esempio particolarmente significativo di questo tipo di soluzioni è costituito dal settore della strumentazione e delle misure elettroniche, che hanno necessità di soluzioni molto professionali più facilmente realizzabili in forma standard da ambienti con grande competenza in materia. Il campo delle soluzioni di questo tipo porta alla realizzazione di “strumentazione virtuale”, come descritto nel seguito.

Sistemi (e sotto-sistemi) di tipo standard

a) Considerazioni di tipo economico

In questa sezione ci occupiamo di sistemi o (grandi) sotto-sistemi completamente realizzati, tipicamente nella forma di schede altamente professionali prodotte da grande case costruttrici. In questo caso, il progetto si riduce allo sviluppo del software, che quasi sempre può essere scritto in linguaggi “strutturati” (Java, C, C++, Labview,…) perché i sistemi di interesse hanno processori ad alte prestazioni adatti per utilizzare sistemi operativi evoluti. In questo caso, l’hardware è realizzato in modo molto accurato e professionale, il che comporta costi e tempi elevati. Tuttavia, dal punto di vista dei costi per l’utente, questo sono mantenuti entro limiti tollerabili (per i sistemi embedded) perché i sistemi in questione sono realizzati in grandi numeri, sui quali i costi di sviluppo possono essere convenientemente ammortizzati. Per quanto riguarda i tempi di sviluppo per l’utente, poiché i sistemi sono già disponibili sul mercato, essi risultano particolarmente bassi. Naturalmente, la necessità di realizzare prodotti standard adatti per grandi mercati implica anche l’uso di processori di tipo generale, adatti per applicazioni di tipo anche molto diverso, con i vantaggi (in termini di flessibilità) e gli svantaggi (dovuti all’eccesso di risorse disponibili) già discusse in precedenza. Inoltre, il fatto che i sistemi qui di interesse siano di fatot dei “prodotti standard” sviluppati come tali in ambienti altamente professionali, solleva l’utilizzatore da preoccupazioni in ordine all’affidabilità alla certificazione,…che rappresentano problemi risolti una volta per tutte dal costruttore (con costi che sono parte di quelli di sviluppo).

b) I Processori

Il tipo di processori qui nteresse è di tipo sincrono, quindi è temporizzato da un clock, che scandisce l’esecuzione temporale delle istruzioni, a loro volta composte di cicli di fasi standard: acquisizione dell’istruzione da eseguire in forma codificata (fetch), decodifica dell’istruzione, decodifica dell’istruzione, acquisizione dei dati (operandi), esecuzione dell’istruzione, memorizzazione (temporanea) dei risultati. L’architettura dei processori standard comprende un “percorso dati” (data path) di tipo generale, ciò adatto ad eseguire molte operazioni diverse a seconda dei “segnali di controllo” che la “specializzano” per l’una o l’altra di queste. Questa parte è costituita essenzialmente dal una “unità logico-aritmentica (ALU)” chiamata a svolgere le operazioni, e da registri destinati a memorizzare temporaneamente dati ed informazioni. I segnali di comando per il data path sono generati da una “Unità di Controllo” (controller), a sua volta comprendente una parte logica (macchia a stati) e dei registri (Program Conter e Instruction Register). Nei processori di tipo generale, anche l’unità di controllo può svolgere diverse funzioni (ovvero generare insiemi di comandi diversi per il data path), quindi deve essere “specializzato” per l’una o l’altra di queste mediante un “programma”, che è contenuto in una memoria esterna al controller e può, quindi essere cambiato dall’utilizzatore. Naturalmente, l’architettura del processore è, appunto, completata da una parte di memoria, che contiene sia i dati che le istruzioni, è strutturata in modo gerarchico e può essere organizzata in vari modi (di tipo Harvard piuttosto che Princeton) ed indirizzata in modi diversi (immediato, diretto, indiretto,…).

c) Il punto di vista dell’utilizzatore

L’utilizzatore di processori di tipo generale non deve necessariamente conoscere l’organizzatore interna del sistema, che gli viene resa “trasparente” dal sistema operativo. Pertanto può limitarsi a scrivere il codice in linguaggio opportuno, tipicamente ad alto livello (Java, C++, Labview,…), ma qualche volta anche in “linguaggio macchina” (assembly). Quest’ultimo è più efficiente del primo (perché utilizza meglio le risorse a disposizione, saltando una serie di decodifiche delle istruzioni), tuttavia è di uso meno immediato e richiede una certa conoscenza del sistema a cui è diretto. Per questi motivi è tipicamente riservato a periferiche e parti speciali in cui le prestazioni sono particolarmente importanti. Un problema particolarmente rilevante per l’utilizzatore è la scelta del processore da utilizzare. A questo proposito occorre considerare diversi aspetti, tra cui in particolare i seguenti:

  • Costo (nel caso di microprocessori di tipo generale, come il Pentium, si tratta di cifre dell’ordine di 1000 dollari per le versioni più avanzate);
  • Consumo di potenza (che può facilmente arrivare a livelli dell’ordine di 100 W);
  • Larghezza del bus (ovvero dei bit che possono essere trasferiti in parallelo, tipicamente 32 o 64 per i processori più avanzati);
  • Prestazioni (velocità, per esempio misurata in Milioni di Istruzioni Per secondo, MIPS, tipicamente da diverse centinaia a numeri significativamente in eccesso del migliaio;
  • Frequenza di clock (come già accennato, parametro spesso utilizzato in sostituzione del precedente, anche se così facendo si trascura il determinante effetto della architettura di sistema sulla prestazioni). La frequenza di clok è determinate anche per quanto riguarda il consumo di potenza. Nei processori più avanzati la frequenza di clock è oggi di alcuni GHz;
  • La quantità di memoria disponibile (sia “di programma” che RAM);
  • Le periferiche che il processore può supportare (in particolare quelle dedicata alle comunicazioni con l’esterno);
  • L’esperienza eventualmente acquisita sul tipo di dispositivo di potenziale interesse (da questo punto di vista un ruolo importante può essere giocato dalla eventuale disponibilità di software sviluppato per lo stesso processore o per altri della stessa “famiglia”, quindi legati da vincoli di compatibilità con quello in esame);
  • Conoscenza e/o disponibilità del sistema di sviluppo;
  • Eventuali licenze
  • ….
  • d) Sviluppo programmi

    Il software per i sistemi qui di interesse viene normalmente sviluppato su PC, con l’utilizzo di strumenti (compilatori, assemblatori, linkers) che consentono di mettere insieme parti diverse, tipicamente scritte da persone differenti, in un unico programma. Inoltre, si utilizzano anche strumenti mirati ad individuare problemi ed errori debugger), oppure parti critiche dal punto di vista della funzionalità e delle prestazioni (profilers) Poiché, comunque, i programmi sono sviluppati su calcolatori diversi da quelli su cui sono destinati a girare. Perciò a tempo debito si pone il problema di provare (“testare”) il programma sviluppato per verificarne il funzionamento “in condizioni operative”. Da questo punto di vista esistono diverse possibilità. Quella più diretta (e definitiva) consiste nello scaricare (download) il programma sul processore su cui dovrà effettivamente “girare” e procedere ad un insieme di prove mirate “neel reali condizioni di funzionamento” (in particolare alla velocità prevista). Questa soluzione ha il vantaggio della semplicità e fornisce indicazioni “definitive”. Tuttavia, occorre progettare accuratamente le prove da eseguire per essere sicuri che siano sufficientemente “complete” da rappresentare l’intero funzionamento del sistema. Inoltre, nel caso qualcosa non funzioni, non si va molto al di là della constatazione che le cose stano così, perché, al fine di ottimizzare le prestazioni, il sistema finale non prevede strumenti di analisi e diagnosi che possano aiutare la comprensione dei motivi di eventuali malfunzionamenti. La soluzione di tipo opposto consiste nell’usare strumenti (software) in grado di simulare sul processore utilizzato per lo sviluppo le istruzioni di quello finale Instruction Set Simulator). Questo tipo di strumento consente di controllare ed analizzare il funzionamento del programma ad ogni singolo passo, fornendo tutte le informazioni desiderate. Tuttavia, è evidente che la simulazione (di qualunque tipo sia) non può mai sostituire completamente il confronto con la realtà fisica, perché fondata su modelli semplificati di quest’ultima, la cui adeguatezza deve in ultima analisi essere verificata caso per caso. Inoltre, in ogni caso la simulazione non è in grado di dare informazioni attendibili sulle capacità del programma di funzionare alla reale velocità a cui opererà in fase di applicazione. La soluzione intermedia, molto utilizzata in pratica, consiste nell’utilizzo di “emulatori”, ovvero di sistemi di sviluppo (in pratica schede sviluppate ad hoc dal costruttore dei sistemi di interesse), che simulano le condizioni reali di funzionamento (in modo concettualmente simile a quanto fanno le macchine di collaudo per schede e componenti), consentendo però anche un certo gradi di controllo delle stesse (per esempio mediante PC). In questo modo i programmi sviluppati possono essere provati sui processori finali (quasi) alla piena velocità di funzionamento con una discreta capacità di analisi dettagliata.