|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
ENCICLOPEDIA DELLA RADIOELETTRONICA ED ELETTRICA Microcontrollori per principianti e non solo. Enciclopedia dell'elettronica radio e dell'ingegneria elettrica
Enciclopedia della radioelettronica e dell'elettrotecnica / microcontrollori PRIMO INCONTRO Innanzitutto, poche parole per coloro ai quali il tema del ciclo, a giudicare dal titolo, sembra a priori poco interessante o "straniero". Forse non hai ancora utilizzato i microcontrollori nei tuoi progetti (di seguito denominati MK per brevità) e pensi che nel prossimo futuro potrai farne a meno. È anche possibile che tu presuma che la costruzione di un sistema di microcontrollori per risolvere il tuo problema sia troppo ingombrante e non economicamente sostenibile. Non avere fretta: soprattutto per te, vogliamo fornire alcuni fatti e alcune statistiche. Ad esempio, prendiamo il parente più stretto di MK, un personal computer, e confrontiamo l'intensità del loro utilizzo. Secondo la società di analisi Loewenbaum & Co. Inc. (USA), il numero di personal computer rilasciati nel mondo nel 1997 ha raggiunto circa 20 milioni di unità. D'accordo, questo è molto. Ora immagina che questo numero gigantesco sia solo lo 0,2% della produzione globale di MK. Secondo la società di analisi IC Insights Inc. (USA) il mercato mondiale nel 1998 ne ha assorbiti più di 13,5 miliardi! La conclusione suggerisce se stessa. Se ancora oggi è difficile trovare un campo dell'attività umana in cui il computer non sarebbe effettivamente utilizzato, allora cosa possiamo dire di MK? Perché sono diventati così popolari e letteralmente indispensabili? La risposta sta nella struttura stessa del microcontrollore. In prima approssimazione alla definizione di questo concetto, possiamo ipotizzare che l'MC sia un computer situato in un singolo microcircuito. Da qui le sue principali qualità attrattive: piccole dimensioni, consumi, prezzo; alte prestazioni, affidabilità e capacità di adattarsi per eseguire un'ampia varietà di compiti. MK differisce da un microprocessore in quanto, oltre all'unità di elaborazione centrale (CPU), contiene memoria e numerosi dispositivi di input / output: convertitori analogico-digitali, canali di informazioni seriali e paralleli, timer in tempo reale, ampiezza di impulso modulatori (PWM), generatori di impulsi programmabili e così via. Nella sua struttura e principio di funzionamento, l'MK, in sostanza, non differisce da un personal computer. Pertanto, le parole microcontrollore e microcomputer sono sinonimi. Tuttavia, il primo termine (dalla parola inglese control - manage) è più comune, perché riflette il suo scopo principale: l'uso nei sistemi di controllo automatico integrati in una varietà di dispositivi: carte di credito, fotocamere, telefoni cellulari, stereo, TV, videoregistratori e videocamere, lavatrici, automobili, forni a microonde, sistemi antifurto, sistemi di accensione di motori a benzina, azionamenti elettrici di locomotive, reattori nucleari e molto altro ancora. I sistemi di controllo incorporati sono diventati un fenomeno così di massa che si è effettivamente formato un nuovo ramo dell'economia, chiamato Embedded Systems (sistemi incorporati - inglese). Attualmente nel mondo vengono prodotte migliaia di varietà di MK. Sono forniti in package da 8 a 356 pin, operano a temperature da -55 a +125oC a frequenze da 32 kHz a 200 MHz, sono in grado di funzionare a una tensione di alimentazione di 1,2 V, pur consumando una corrente non superiore a pochi microampere . . Anche il prezzo dei prodotti è in costante diminuzione. Alcuni MCU a otto bit già oggi non costano più di 50 centesimi, il che è paragonabile al costo di un chip "hard logic". Tutto ciò ha portato al fatto che oggi è sempre più difficile trovare un'area di attività umana in cui MC non troverebbe applicazione, e il processo della loro distribuzione ha un carattere simile a una valanga. Speriamo che i fatti di cui sopra ti abbiano già preparato per un atteggiamento rispettoso nei confronti del personaggio principale della nostra storia. In effetti, MC è diventato un evento globale, invadendo quasi tutti i tipi di attività umana. Cosa ha fornito una crescita così rapida della popolarità di questi prodotti, apparsi poco più di 25 anni fa? Quali sono questi dispositivi e quali sono le loro capacità e prospettive? Se non hai ancora utilizzato MC o sistemi basati su di essi nelle tue attività, allora. forse è il caso di pensarci? E se decidi di applicare MK, quale dovrebbe essere la sequenza delle tue azioni? Quali difficoltà possono aspettarti, cosa può aiutarti lungo la strada? Cercheremo di rispondere a queste domande nella serie di articoli proposta. LA LEGGE DI MOORE E IL PRIMO MK Nel 1965, Gordon Moore, uno dei futuri fondatori della potente Intel Corporation, attirò l'attenzione su un fatto interessante. Dopo aver tracciato la crescita delle prestazioni dei chip di memoria, ha scoperto uno schema interessante: nuovi modelli di chip apparivano ogni 18-24 mesi e la loro capacità raddoppiava ogni volta. Se questa tendenza continua, ha suggerito G. Moore, la potenza dei dispositivi informatici aumenterà in modo esponenziale in un periodo di tempo relativamente breve. La previsione di G. Moore è stata successivamente brillantemente confermata e il modello da lui scoperto è osservato oggi e con sorprendente precisione, essendo la base per numerose previsioni di crescita della produttività. Nei 28 anni trascorsi dall'avvento del microprocessore 4004 (1971), il numero di transistor su un chip è aumentato di oltre 12 volte: da 000 a 2 nel chip Sorrettué. Ebbene, nel 1976, lo sviluppo esponenziale della tecnologia dei semiconduttori portò alla creazione da parte di Intel del primo MK - 8048. Oltre alla CPU, includeva memoria di programma, memoria dati, un timer a otto bit e 27 linee di I/O . Oggi l'8048 è già storia, ma il prodotto successivo, rilasciato da Intel nel 1980, è ancora vivo e vegeto. Questo è l'MK 8051. ARCHITETTURA MK 8051 Questo MK può essere considerato un modello classico, a immagine e somiglianza del quale sono stati successivamente creati molti altri prodotti. Il suo schema a blocchi è mostrato in fig. 1. CPU: il nodo principale di MK. È associato a un concetto così importante come un sistema di comando.
Il set di istruzioni è un insieme univoco di codici binari specifici per una data CPU che definisce un elenco di tutte le sue possibili operazioni. Ciascuno di questi codici definisce un'operazione ed è chiamato codice operazione o comando. Maggiore è il numero di codici utilizzati nel set di istruzioni, maggiore è il numero di operazioni che la CPU può eseguire. MK 8051 è a otto bit, quindi i suoi codici operativi hanno una dimensione di 8 bit. Teoricamente, possono esserci un totale di 256 codici operativi a otto bit. 8051 utilizza 255. A seconda del numero di codici operativi utilizzati, i sistemi di istruzioni sono divisi in due gruppi: CISC e RISC. Il termine CISC indica un complesso sistema di comandi ed è un'abbreviazione della definizione inglese di Complex Instruction Set Computer. Allo stesso modo, il termine RISC significa un set di istruzioni ridotto e deriva dall'inglese Reduced Instruction Set Computer. Il sistema di comando MK 8051 può essere attribuito al tipo C15C. Tuttavia, nonostante l'uso diffuso di questi concetti, si deve riconoscere che i nomi stessi non riflettono la principale differenza tra i sistemi di comando CISC e RISC. L'idea principale dell'architettura RISC è un'attenta selezione di tali combinazioni di codici operativi che potrebbero essere eseguiti in un ciclo del generatore di clock. Il vantaggio principale di questo approccio è una netta semplificazione dell'implementazione hardware della CPU e la capacità di aumentarne significativamente le prestazioni. Inizialmente, era possibile implementare un tale approccio solo riducendo notevolmente l'insieme dei comandi, da cui è nato il nome RISC. Ad esempio, il set di istruzioni dell'MK della famiglia Microchir PIC include solo 35 istruzioni e può essere classificato come RISC. Ovviamente, nel caso generale, ad una istruzione dell'architettura CISC devono corrispondere più istruzioni dell'architettura RISC. Tuttavia, i guadagni in termini di prestazioni dell'architettura RISC di solito superano le perdite dovute al set di istruzioni meno efficiente, determinando una maggiore efficienza del sistema RISC nel suo insieme rispetto al CISC. COSÌ. il comando più veloce MK 8051 viene eseguito in 12 cicli. Anche se è necessario eseguire tre istruzioni del controller RISC per ciascuna istruzione, alla fine l'architettura RISC fornirà un aumento di quattro volte delle prestazioni. Lungo la strada, l'architettura RISC ti consente di risolvere una serie di compiti. Infatti, con la semplificazione della CPU, diminuisce il numero di transistor necessari per la sua implementazione, quindi diminuisce l'area del cristallo. Ciò si traduce in una riduzione dei costi e del consumo energetico. A questo punto si potrebbe esclamare: il futuro appartiene all'architettura RISC! Tuttavia, il confine tra questi due concetti sta rapidamente sfumando. Per esempio. Gli MCU della famiglia AVR di Atmel hanno un set di istruzioni di 120 istruzioni, che corrisponde al tipo CISC. Tuttavia, la maggior parte di essi viene eseguita in un ciclo, che è un segno distintivo dell'architettura RISC. Oggi è generalmente accettato che la caratteristica principale dell'architettura RISC sia l'esecuzione di istruzioni in un ciclo del generatore di clock. Il numero di comandi in sé non ha più importanza. Il generatore di clock genera impulsi per sincronizzare il funzionamento di tutti i nodi del dispositivo. La frequenza della loro ripetizione può essere impostata da un risonatore al quarzo o da un circuito RC collegato alle uscite dell'MK. In alcuni MK, viene fornita una modalità operativa del generatore di clock senza l'uso di elementi esterni. In questo caso, la frequenza degli impulsi di clock dipende dai parametri del cristallo, che vengono determinati durante la sua produzione. La ROM è un dispositivo di memoria di sola lettura progettato per memorizzare programmi, quindi questa memoria è spesso chiamata codice o memoria di programma. Fino a poco tempo fa, esistevano due tipi principali di ROM: mascherata e programmabile. Le informazioni vengono inserite nelle ROM delle maschere durante il processo di fabbricazione dell'MC utilizzando modelli tecnologici - maschere. Non può essere modificato dopo la fine del ciclo produttivo. Tali ROM vengono utilizzate solo nei casi in cui la qualità del programma è fuori dubbio e vi è un enorme bisogno di MK con questo particolare programma. Il vantaggio delle ROM maschera è il costo più basso nella produzione di massa (da diverse migliaia di pezzi). Le informazioni sulla ROM programmabile vengono scritte utilizzando un dispositivo chiamato programmatore. MK con tali ROM sono di due tipi: una volta e ripetutamente programmabili (riprogrammabili). I primi, come dice il nome stesso, consentono solo una programmazione una tantum, dopodiché non è più possibile cancellare le informazioni (MK con memoria OTP - dall'inglese. One Time Programmable). Sono utilizzati nella produzione su piccola scala (fino a 1000 pezzi). quando l'uso della maschera MK non è economicamente giustificato. I microcircuiti ripetutamente programmabili si dividono in MK dotati di ROM con cancellazione per irradiazione ultravioletta (disponibile in confezioni con "finestra"), e MK con memoria riprogrammabile elettricamente. Lo svantaggio di MC con ROM con cancellazione mediante irradiazione ultravioletta è un costo molto elevato e un numero relativamente piccolo di cicli di scrittura / cancellazione (dipende dalla dose totale di irradiazione del cristallo e di solito non supera 15 ... 20) Attualmente, una nuova tecnologia per l'implementazione della ROM sta diventando sempre più popolare: la memoria flash. Il suo merito principale è che è costruito sul principio della riprogrammabilità elettrica. cioè, consente la cancellazione multipla e la registrazione delle informazioni utilizzando i programmatori. Il numero minimo garantito di cicli di scrittura/cancellazione di solito supera diverse migliaia. Ciò aumenta notevolmente il ciclo di vita e aumenta la flessibilità dei sistemi MC. poiché consente di apportare modifiche al programma MC sia nella fase di sviluppo del sistema che durante il suo funzionamento in un dispositivo reale. La RAM è una memoria ad accesso casuale utilizzata per memorizzare i dati, quindi questa memoria è anche chiamata memoria dati. Il numero di cicli di lettura e scrittura nella RAM non è limitato, ma quando la tensione di alimentazione viene interrotta, tutte le informazioni vengono perse. L'architettura dell'MK 8051 prevede l'uso separato della memoria del programma e dei dati e si chiama Harvard. In genere, questa architettura viene utilizzata per migliorare le prestazioni del sistema separando i percorsi di accesso alla memoria del programma e dei dati, ma nell'8051 è stata utilizzata per ottenere una memoria del programma e dei dati che non richiedesse la stessa dimensione. L'antipodo di Harvard - l'architettura von Neumann - prevede l'archiviazione di programmi e dati in una memoria condivisa ed è più tipica per i microprocessori progettati per l'uso nei computer. Un esempio è la famiglia di microprocessori x86. I timer TO, T1 sono timer/contatori programmabili a sedici bit che possono essere programmati per eseguire una varietà di funzioni. Possono essere utilizzati per la formazione accurata di intervalli di tempo, il conteggio degli impulsi sulle uscite dell'MK, la formazione di una sequenza di impulsi, il clock del ricetrasmettitore di un canale di comunicazione seriale. I timer/contatori sono in grado di generare richieste di interrupt, commutando la CPU per servirle su eventi e liberandola dalla necessità di interrogare periodicamente lo stato dei timer. Poiché l'applicazione principale di MK si trova nei sistemi in tempo reale, i timer/contatori sono il loro elemento indispensabile. In alcune modifiche, il numero di timer raggiunge 32. La porta seriale è un canale per lo scambio di informazioni tra MK e il mondo esterno. Tali canali di comunicazione occupano un numero minimo di pin di cristallo, fornendo comunicazioni su distanze significative con costi hardware minimi. L'8051 implementa un ricetrasmettitore seriale asincrono universale (UART) che supporta il protocollo standard RS-232C, che consente di organizzare la comunicazione tra questo MK e un personal computer. Oltre a RS-232C, i protocolli più diffusi nel mondo dei sistemi embedded sono RS-485. I2C (bus bidirezionale a due fili). SPI (interfaccia periferica seriale a XNUMX fili). Bitbus (bus di controllo seriale), CAN (interfaccia di rete tra controller), USB (bus seriale universale) e alcuni altri. Per quasi ogni tipo di canale seriale, oggi puoi trovare un MK che ha una porta seriale corrispondente nella sua composizione. Anche le porte I/O parallele sono una parte essenziale di qualsiasi MCU. Di solito vengono utilizzati per comunicare con l'ambiente circostante: sensori e attuatori. Una caratteristica importante delle porte parallele MK è la possibilità di essere programmate per svolgere diverse funzioni. Ad esempio, sull'8051, i pin della porta P0 e P2 possono essere utilizzati come normali registri di I/O statici o come bus di indirizzi e dati per il collegamento di dispositivi esterni come memoria di programma aggiuntiva, memoria dati, dispositivi I/O. Ciò conferisce flessibilità architettonica a MK. La porta RXNUMX può essere utilizzata come registro I/O statico o eseguire funzioni speciali per il funzionamento di un canale seriale, timer, controller di interrupt, ecc. La riprogrammabilità consente di utilizzare tutte le uscite dell'MC nel dispositivo progettato con la massima efficienza. Il sistema di interruzione è una delle parti più importanti di MK. Una caratteristica dei sistemi in tempo reale è che per loro un parametro estremamente importante è il tempo di risposta agli eventi esterni. Spieghiamo con un semplice esempio. Quando esegui un calcolo matematico su un computer, di solito esegui un programma progettato per eseguire questi calcoli e, dopo che è stato caricato nella memoria del computer, inserisci la dichiarazione del problema e attendi il risultato. Il tempo di attesa in questo caso non è di fondamentale importanza (ovviamente entro limiti ragionevoli): il funzionamento lento del computer può essere fastidioso, ma ciò non influirà sul risultato. Il sistema in tempo reale assume una velocità molto specifica, calcolata in fase di sviluppo, della risposta del sistema di controllo a eventi esterni. I ritardi oltre quelli calcolati sono semplicemente inaccettabili qui: possono portare a conseguenze catastrofiche. I problemi di risposta rapida agli eventi vengono risolti organizzando un sistema di interruzioni. Ciò implica che per ciascuno di questi eventi viene sviluppato un "pezzo" di codice separato, che costituisce la reazione del MK ad esso. Questo "pezzo" di codice è chiamato routine di richiesta di interruzione (il termine routine di interruzione è spesso usato per brevità) ed è collocato nella memoria del programma a un indirizzo noto. Al momento del verificarsi di un determinato evento, un segnale al riguardo viene inviato all'ingresso del controller di interrupt. Quest'ultimo è un dispositivo che stabilisce una corrispondenza biunivoca tra il segnale di ingresso su un evento che si è verificato e l'indirizzo di memoria del programma in cui si trova il punto di ingresso alla routine di elaborazione della richiesta di interruzione da questo evento. Il controller interrompe l'esecuzione della CPU del programma corrente e avvia la sua transizione all'esecuzione della routine di servizio di interruzione. Il tempo trascorso dal momento in cui si è verificato l'evento all'inizio dell'esecuzione della prima istruzione della routine di interrupt è chiamato tempo di risposta dell'MC all'evento. Al termine dell'elaborazione, la CPU torna automaticamente all'esecuzione del programma interrotto. Un'altra funzione del controller di interrupt è dare priorità agli eventi. Il concetto di priorità significa che una routine di interrupt in esecuzione può essere interrotta da un altro evento solo se ha una priorità maggiore di quella corrente. In caso contrario, la CPU passerà all'elaborazione di un nuovo evento dopo aver terminato l'elaborazione di quello precedente. Il controller di interrupt, che fa parte dell'MK 8051, ha cinque ingressi di evento: due da dispositivi esterni, due da timer e uno dal canale seriale. Di solito, quando parlano di qualsiasi MK, menzionano sempre la famiglia a cui appartiene. Una famiglia include prodotti che hanno lo stesso nucleo, inteso come un insieme di concetti come un sistema di istruzioni, un diagramma della sequenza operativa della CPU, l'organizzazione della memoria del programma e della memoria dei dati, un sistema di interruzione e un insieme di base di dispositivi periferici . Infatti, nella Fig. 1 mostra il nucleo che divenne la base per la creazione di centinaia di altre modifiche della famiglia 8051. Le differenze tra i suoi vari rappresentanti sono principalmente nella composizione dei dispositivi periferici e nella quantità di memoria del programma o dei dati. Poiché la gamma di compiti risolti da MK. estremamente ampio, i loro produttori stanno cercando di rilasciare quante più modifiche per soddisfare le più diverse esigenze dei consumatori. In molte famiglie, il numero di modifiche si avvicina al centinaio o addirittura supera questo valore. La caratteristica più importante della famiglia è la compatibilità software a livello di codice binario di tutti i MK inclusi in essa. Ciò consente agli sviluppatori di sistemi di sostituire una famiglia di microcontrollori con altri senza perdere i loro sviluppi software. Naturalmente, maggiore è il numero di varietà incluse nella famiglia, maggiore è la probabilità di scegliere l'opzione migliore, più attraente è questa famiglia per lo sviluppatore. La questione della giusta scelta di una famiglia MC per un nuovo sviluppo è strategica, poiché il problema del trasferimento del software tra prodotti di famiglie diverse è estremamente complesso e anche l'uso di linguaggi di alto livello non sempre consente di risolvere senza grosse perdite. Torneremo sulla questione dei criteri di selezione nei successivi articoli della serie. Lo sviluppo del programma è una delle fasi più importanti nella creazione di un dispositivo basato su MK. Senza di essa è "morto", non risponde alle influenze esterne e non emette segnali di controllo. All'accensione, l'MCU avvia immediatamente l'esecuzione del programma situato nella memoria di programma (solitamente ROM) ad esso collegata. La sua esecuzione parte da un indirizzo fisso, molto spesso zero. Un indirizzo è semplicemente un numero di cella ROM.Il processo viene eseguito come segue: l'MCU legge il numero memorizzato nella memoria del programma e, a seconda del suo valore, chiamato codice macchina, esegue determinate azioni sul contenuto dei registri ALU . memoria, porte, ecc. Ad esempio, leggendo il numero 32H dalla memoria del programma. MK "capisce" che è necessario leggere il valore dalla porta di ingresso numero 2 e inserirlo nel registro dell'accumulatore. Spesso un byte non è sufficiente per descrivere l'azione, quindi MK legge ulteriori byte dalla memoria. Dopo aver eseguito l'azione, MK legge il valore dalla successiva cella di memoria in ordine, ecc. L'insieme di byte che descrivono un'azione eseguita da MK è chiamato comando macchina (istruzione) e l'insieme di tali comandi che MK " capisce”. - il suo sistema di comando o set di istruzioni (Instruction Set). MK di famiglie diverse hanno sistemi di comando diversi, ovvero i loro codici macchina hanno significati diversi, sebbene eseguano azioni simili. Quindi, il programma per MK è una sequenza di numeri, i cui valori indicano quali azioni eseguire. Il risultato dello sviluppo di un programma è un file di computer contenente questi codici macchina. Con l'aiuto di un programmatore ROM, viene inserito ("cucito") nella memoria del programma MK. Com'è la composizione di questa sequenza di codici macchina: un programma per MK? Lo sviluppatore ha davvero bisogno di ricordare i valori dei codici macchina e impostarne manualmente la sequenza? I primi programmi per MK sono stati creati in questo modo. e si chiamava programmazione in codici macchina. È chiaro che questo modo di sviluppare programmi richiede molto tempo ed è inefficiente. Il primo passo per facilitare il processo di creazione dei programmi è stato un programma per computer, il cosiddetto traduttore dal linguaggio assembly. L'idea era di esprimere le azioni eseguite dall'MK in un linguaggio più leggibile dall'uomo e quindi convertire queste espressioni in codici macchina. Nell'esempio precedente di istruzione macchina che legge il valore della porta 2 e lo inserisce nell'accumulatore, l'azione intrapresa può essere approssimativamente indicata come MOV A.P2. Qui la parola MOV (dall'inglese move), chiamata istruzione mnemonica, denota il trasferimento di un valore, e A e P2, chiamati operandi, indicano da dove prendere il valore e dove metterlo. Questa notazione è chiamata linguaggio assembly. programma scritto su di esso. elaborato da un traduttore che converte i costrutti del linguaggio assembly in codici macchina. La programmazione in linguaggio assembly è diffusa fino ad oggi. I traduttori del linguaggio assembly per tutte le famiglie di microcontrollori più diffusi sono gratuiti. Nonostante gli ovvi vantaggi della programmazione in assembler rispetto alla programmazione in codice macchina, in molti casi l'assembler non è sufficientemente efficiente per implementare i compiti dello sviluppatore. Il fatto è che MK è in grado di eseguire solo le operazioni più semplici come operazioni aritmetiche su numeri interi, trasferimenti, confronti, ecc. Per attività più complesse, ad esempio operazioni su numeri in virgola mobile, gli sviluppatori hanno dovuto scrivere routine speciali scomode da uso e ingombrante. Il passo successivo nello sviluppo di programmi per MK è stata la creazione di speciali programmi per computer: traduttori di linguaggi di programmazione di alto livello o compilatori. Il linguaggio di programmazione più diffuso è il C. Con l'avvento dei traduttori, lo sviluppo dei programmi per MK è stato notevolmente semplificato. Se, ad esempio, devi aggiungere due numeri nel programma, ora è sufficiente scrivere a = b + c. e il traduttore converte questa espressione nella necessaria sequenza di istruzioni macchina a seconda dei tipi di variabili a, b e c. L'uso di un linguaggio di alto livello consente allo sviluppatore di astrarre dal sistema di comando di un particolare microcontrollore e operare in categorie più semplici e comprensibili per una persona. Allo sviluppatore è richiesto solo di conoscere l'architettura generale del microcontrollore. principi di funzionamento delle periferiche embedded necessarie alla risoluzione del compito e capacità di programmazione in linguaggio C. Il contenuto funzionale del programma è implementato utilizzando gli strumenti del linguaggio C. che contiene un gran numero di varie subroutine (funzioni): aritmetica, per lavorare con stringhe di caratteri e molte altre. Considera il processo di creazione di un programma per MK nel linguaggio C. Il processo di sviluppo richiederà un personal computer. Dopo aver compreso l'attività, lo sviluppatore scrive il codice sorgente del suo programma in linguaggio C utilizzando qualsiasi editor di testo. Quindi esegue il programma di traduzione C. che converte il testo sorgente in un file oggetto intermedio. Il traduttore è controllato da un insieme di chiavi (la loro descrizione può essere trovata nella sua documentazione) che sono specificate sulla sua riga di comando. Se lo sviluppatore ha commesso errori sintattici durante la scrittura del programma, il traduttore ne visualizza un elenco sullo schermo con un'indicazione per ogni numero di riga nel file di testo sorgente. Lo sviluppatore deve correggere tutti i bug. Dopo la corretta traduzione, i file oggetto devono essere elaborati dal linker (linker), che genera il file di programma in codici macchina. C'è un problema quando si usa un linguaggio di alto livello. Il compilatore è responsabile della conversione dei costrutti del linguaggio in codici macchina e questa conversione può essere eseguita con vari gradi di efficienza. I criteri di efficienza sono la dimensione del codice macchina (più piccolo è, ovviamente, meglio è) e la velocità del codice macchina. Il compito di generare codice compatto e veloce è molto difficile e la qualità complessiva del compilatore dipende dalla sua soluzione. I moderni compilatori C utilizzano l'ottimizzazione multilivello, le caratteristiche dell'architettura di un particolare MK, consentono di creare programmi misti in cui alcune delle subroutine sono scritte in assembler. Il processo descritto sembra piuttosto macchinoso: lo sviluppatore deve avviare manualmente vari programmi (editor di testo, compilatore C, linker per ricordare i tasti di controllo, ricerca di errori nel programma tramite numeri di riga nel file. L'ultimo passo per facilitare il lavoro dello sviluppatore di programmi per MK è stata l'emergere di ambienti di sviluppo integrati (Integrated Development Environment. IDE). L'ambiente di sviluppo integrato è un programma per computer che collega tutte le fasi dello sviluppo del programma. Combina un editor di testo per scrivere codice sorgente, traduttori da assembler e C, un linker, un debugger, informazioni di riferimento su MK e altri strumenti necessari per lo sviluppatore. La configurazione di traduttori, linker e altri componenti viene eseguita non specificando opzioni sulla riga di comando, ma sotto forma di finestre di dialogo in cui è necessario solo spuntare le caselle nei posti giusti. . L'emergere di ambienti di sviluppo software integrati ha ulteriormente aumentato l'efficienza della creazione di programmi per MC, ha permesso allo sviluppatore di concentrarsi sull'essenza del problema da risolvere e di astrarre dai dettagli specifici della sua implementazione. I pacchetti di sviluppo software integrati sono prodotti da diverse aziende. I pacchetti di diversi produttori hanno funzioni simili, ma differiscono per capacità di servizio, facilità d'uso e qualità del codice macchina generato. Le caratteristiche principali dei kit di sviluppo più diffusi sono riportate nella tabella.
DEBUG SIMBOLICO DEI PROGRAMMI PER MK Con rare eccezioni, i programmi per MK, a causa degli errori che contengono, non iniziano a funzionare la prima volta e richiedono il debug. Gli sviluppatori affrontano i problemi di debug in modi diversi. Alcuni di loro credono che sia sufficiente analizzare attentamente il testo sorgente, vedere con un oscilloscopio cosa sta succedendo sulle uscite MK e tutti gli errori possono essere corretti. Questo metodo è applicabile se lo sviluppatore ha una vasta esperienza, conosce perfettamente l'MK utilizzato e dispone di un traduttore che genera sempre il codice corretto (di solito un assemblatore) e di tempo sufficiente. Altri usano monitor di debug fatti in casa nella loro pratica: set di subroutine speciali che vengono caricate in MK insieme al programma principale. Quest'ultimo chiama le subroutine monitor ai checkpoint e forniscono informazioni sullo stato delle risorse MK. Quasi tutti i programmi possono essere sottoposti a debug in questo modo, ma presentano svantaggi che possono essere significativi. In primo luogo, il monitor di debug deve essere dotato di una parte delle risorse MC per il lavoro: almeno una parte dello spazio degli indirizzi del codice e un certo numero di celle dello stack, e al massimo anche una parte della RAM e delle periferiche dispositivi del MC. utilizzato dal monitor per visualizzare le informazioni. Può essere difficile allocare risorse al monitor di debug se il programma principale stesso sta caricando attivamente MK. Ad esempio, il PIC 16С5х (Microchip) MK ha solo due celle dello stack ed è difficile utilizzare le chiamate alla subroutine del monitor di debug. In secondo luogo, le chiamate monitor richiedono tempo dal programma principale e, pertanto, non possono essere chiamate da parti del programma in cui il tempo è critico. In terzo luogo, la creazione di un monitor di debug, di per sé, richiede tempo. Il modo più efficace per eseguire il debug dei programmi per MK è utilizzare strumenti di debug professionali specializzati, che includono debugger di simulatori ed emulatori in-circuit. Prima di parlare delle possibilità fornite da tali debugger, è necessario toccare la scelta del compilatore, con l'aiuto del quale i testi sorgente dei programmi vengono convertiti in codice macchina. Nella stragrande maggioranza dei casi è preferibile programmare in un linguaggio di alto livello. L'uso dell'assembler è necessario se vengono imposti requisiti molto rigidi sulla dimensione e sulla velocità del codice generato. Attualmente, tali casi stanno diventando sempre meno, dal momento che puoi quasi sempre prendere un MK "più veloce" con più memoria. Inoltre, i moderni pacchetti cross-tool semplificano la scrittura di programmi misti, in cui alcuni dei moduli sono scritti in C. e le parti più critiche per le prestazioni sono in assembler. I compilatori C consentono anche di inserire istruzioni di assemblaggio nel codice sorgente. Quali sono i vantaggi della programmazione in C rispetto alla programmazione in assembler? In breve, sono i seguenti:
Per eseguire efficacemente il debug di programmi scritti in un linguaggio di alto livello, lo sviluppatore deve disporre di strumenti di debug che forniscano adeguate opportunità per visualizzare i dati utilizzati nel programma, nonché per tracciare l'esecuzione del programma dal suo codice sorgente . Perché ciò sia possibile sono necessarie due condizioni:
Consideriamo ora come il debugger dovrebbe interpretare le informazioni simboliche e quali opzioni dovrebbero essere fornite all'utente in relazione a ciò. TRACCIARE L'ESECUZIONE DEL PROGRAMMA SECONDO IL SUO TESTO FONTE In generale, una riga di testo sorgente viene convertita dal compilatore in diverse istruzioni macchina. Anche un programma assembler contiene quasi sempre macro che, una volta tradotte, si espandono in diverse istruzioni del processore. È scomodo eseguire il debug di un programma di questo tipo utilizzando il disassemblatore del suo codice, quindi i compilatori inseriscono una tabella di numeri di riga nelle informazioni di debug. Contiene informazioni sulla corrispondenza dei numeri di riga del testo di origine e dei nomi dei file di testo di origine con gli indirizzi assoluti del codice del programma. Il debugger visualizza il codice sorgente del programma sullo schermo. seguendo questa tabella può eseguire il programma "riga per riga", eseguendo in un unico passo tutte le istruzioni macchina generate dal compilatore per la riga corrente. La tabella dei numeri di riga consente inoltre di eseguire azioni contestuali con il testo del programma, ad esempio eseguirlo "fino al cursore", ovvero in una posizione specificata dall'utente nel testo di origine, impostare punti di interruzione su righe specificate, ecc. Azioni contestuali sono convenienti perché lo sviluppatore non ha bisogno di conoscere gli indirizzi corrispondenti alle righe del testo sorgente: il debugger stesso li determinerà dalla tabella. Il debugger deve anche "conoscere" gli indirizzi di subroutine, funzioni ed etichette di codice ed essere in grado di trovare il testo sorgente di una funzione in base al suo nome. VISUALIZZAZIONE DEI DATI UTILIZZATI NEL PROGRAMMA DEBUGATO Per il debug completo, lo sviluppatore deve essere in grado di visualizzare i dati manipolati dal programma in qualsiasi momento. Il debugger deve "essere in grado" di visualizzare nel modo più opportuno qualsiasi dato utilizzato dal programma. Di norma, gli sviluppatori utilizzano dati denominati nei programmi, ovvero a ciascun oggetto utilizzato nel programma viene assegnato un nome. Gli oggetti possono essere di varia complessità: da semplici celle di memoria a strutture complesse di linguaggi di alto livello come strutture, array, ecc. DATI NEI PROGRAMMI DI ASSEMBLAGGIO I programmi di assemblaggio utilizzano per lo più dati semplici, ad esempio celle di memoria. Vengono utilizzati anche gli array. Per visualizzare correttamente dati semplici, il debugger deve "sapere":
Con le informazioni di cui sopra, il debugger dovrebbe, dopo aver ricevuto il nome dell'oggetto dall'utente, visualizzarne il valore in base al tipo. I debugger più "avanzati" possono inoltre visualizzare il resto degli attributi dell'oggetto. DATI IN PROGRAMMI IN LINGUE DI ALTO LIVELLO La visualizzazione di oggetti utilizzati in linguaggi di alto livello è molto più difficile a causa della varietà di strutture degli oggetti, dei modi in cui sono archiviati in memoria e degli ambiti. Ad esempio, utilizzeremo il linguaggio C, in quanto il più popolare tra gli sviluppatori. STRUTTURA DEGLI OGGETTI Oltre a semplici variabili di diversa lunghezza, i programmi C utilizzano anche variabili in virgola mobile, strutture (struct), unioni o unioni (union), puntatori, array unidimensionali e multidimensionali. Quest'ultimo può essere costituito sia da oggetti semplici sia da oggetti complessi (strutture, unioni, puntatori). Usare oggetti complessi nei programmi è sicuramente comodo. Tuttavia, a causa della complessità della loro struttura, è altamente desiderabile poterlo visualizzare adeguatamente in fase di debug. Nei debugger di Fiton, gli oggetti complessi possono essere visualizzati sia in forma compressa (elenco di valori degli elementi) che in forma espansa, indicando l'indirizzo, il valore e il tipo di ciascun elemento dell'array e/o membro della struttura. L'implementazione di puntatori in diversi compilatori è diversa. Il fatto che MK di solito abbia diversi spazi di indirizzi crea ulteriori difficoltà, poiché quando si lavora con un puntatore, oltre all'indirizzo, deve essere noto lo spazio di indirizzi a cui punta il puntatore. In alcune implementazioni, l'identificatore dello spazio degli indirizzi fa parte del valore del puntatore; in altre, il compilatore lo "sa" in anticipo e genera il codice appropriato. Inoltre, il componente dell'indirizzo in un puntatore può avere una dimensione compresa tra 8 e 32 bit. Quando si visualizzano i valori dei puntatori, il debugger deve "conoscere" tutti i dettagli della loro implementazione in ciascun compilatore. METODI PER LA POSIZIONE DEGLI OGGETTI IN MEMORIA Oltre agli oggetti statici, i cui indirizzi non cambiano durante l'esecuzione del programma, in un programma scritto in un linguaggio di alto livello, possono esserci i cosiddetti oggetti automatici, la cui memoria è temporaneamente allocata nello stack MK . Gli indirizzi di tali oggetti non sono assoluti, ma sono determinati dinamicamente nella fase di esecuzione del programma. Di solito sono misurati dal valore corrente di una variabile statica chiamata stack frame pointer (Base Pointer o BP). Poiché il valore di BP viene generato dinamicamente dal programma in fase di esecuzione, i valori degli oggetti automatici sono disponibili solo all'interno del loro ambito, ovvero con un valore BP valido. Il debugger, quando visualizza i valori degli oggetti automatici, deve "conoscere" il modo in cui vengono determinati gli indirizzi, oltre a monitorare la correttezza del valore BP È anche possibile posizionare temporaneamente variabili nei registri MK. In questo caso, il debugger deve "sapere" quali variabili sono posizionate in quali registri e per quanto tempo. E, infine, c'è spesso una situazione in cui lo stesso oggetto durante la sua vita cambia il modo in cui viene inserito nella memoria, e più di una volta. Ciò può accadere, ad esempio, quando una funzione riceve uno o più parametri nei registri e quindi li inserisce nello stack. CAMPO DI VISIBILITA' DELL'OGGETTO Come nei programmi assembler, i programmi C hanno oggetti globali accessibili per nome da qualsiasi modulo e oggetti che sono localizzati nel modulo (questi oggetti sono dichiarati statici). Tuttavia, le variabili automatiche e di registro rendono più difficile per i debugger visualizzare i loro valori. Il fatto è che. in primo luogo, la durata di un oggetto automatico è limitata dal suo ambito e, in secondo luogo, gli ambiti che lo racchiudono possono avere i propri oggetti automatici con gli stessi nomi. Illustriamo questo con un esempio di una funzione che ha diversi ambiti nidificati:
La variabile denominata "a" esiste fintanto che la funzione f viene eseguita, ma a seconda di quale parte della funzione viene eseguita, il nome "a" sta per variabili diverse. Quando si traccia la funzione f, il debugger deve, a seconda di quale variabile è attiva, mostrarne correttamente il valore. Durante la creazione di un programma, lo sviluppatore non si preoccupa dei dettagli dell'implementazione dei concetti che ha utilizzato nel programma. In termini di categorie "per scontate", spesso non sospetta quanto sia stato difficile per gli sviluppatori di compilatori e debugger implementarle. Questi ultimi devono risolvere il problema di unire in una shell allo stesso tempo un'interfaccia semplice e intuitiva, una ricchezza di funzionalità e uno studio dettagliato di tutto ciò che riguarda l'implementazione delle caratteristiche dell'architettura e il funzionamento di un particolare MK. Se il debugger non fornisce allo sviluppatore strumenti di debug adeguati alla complessità del problema da risolvere, lo sviluppatore perde inevitabilmente produttività. Chi di noi non ha dovuto passare ore e giorni alla ricerca di un fastidioso errore o refuso nel testo sorgente?! Nel processo di sviluppo e creazione di un sistema a microprocessore, prima o poi arriva un momento in cui finalmente viene incorporato nell'hardware e inizia a dare segni di vita. Tuttavia, nella maggior parte dei casi questi segni risultano imprevedibili, il sistema inizia a vivere la propria vita. Molti programmatori sarebbero probabilmente d'accordo sul fatto che ogni nuovo programma contiene bug. Questo è in parte il motivo per cui la nuova MK si comporta inizialmente come una scatola "nera". Per facilitare il processo di debug dei sistemi, è stata sviluppata un'intera classe di strumenti. Il loro scopo principale è rendere "trasparente" il processo di funzionamento dell'MK sottoposto a debug, ovvero facilmente controllabile, arbitrariamente controllato e modificabile a piacimento dello sviluppatore. Un buon toolkit professionale può inoltre fornire allo sviluppatore molti servizi, facilitando così notevolmente il suo lavoro, eliminando le operazioni di routine. I principali strumenti di debug includono emulatori in-circuit, simulatori software, schede di sviluppo (schede di valutazione), monitor di debug ed emulatori ROM. Esistono anche dispositivi e set combinati. EMULATORI IN CIRCUITO Un emulatore in-circuit (ICE) è uno strumento hardware-software che può sostituire un processore emulato in un dispositivo reale. VSE è lo strumento di debug più potente e versatile. Funzionalmente, i VE si dividono in quelli collegati a un computer esterno (solitamente un PC compatibile con IBM) e funzionanti in modo autonomo. Questi ultimi hanno le proprie risorse di calcolo e strutture di input/output, quindi, a parità di capacità, sono molto più costosi dei primi e, a parità di prezzo, sono significativamente inferiori a loro in termini di funzionalità e capacità di servizio. Con il sistema in fase di debug, il VSE è solitamente collegato tramite un cavo a una speciale testina di emulazione. Relativamente di recente, sono apparsi modelli VSE in cui tale testina è strutturalmente combinata con l'unità principale ed è inserita nel sistema in fase di debug al posto dell'MC. Se quest'ultimo non può essere rimosso (i pin sono saldati alla scheda), l'uso del VSE è consentito, a condizione che questo MC abbia una modalità di debug in cui tutti i suoi pin si trovano nel terzo stato (alta impedenza). In questo caso, per collegare il VSE, viene utilizzato uno speciale adattatore a clip, che viene collegato direttamente alle uscite dell'MK emulato. Meno. VSE contiene un debugger, un nodo di emulazione MK. memoria di emulazione e sottosistema del punto di interruzione. I TSE più avanzati possono inoltre includere un tracciante, un processore breakpoint, un profiler (analizzatore di efficienza del codice del programma), un timer in tempo reale, strumenti software e hardware che consentono di leggere e modificare le risorse del processore emulato "al volo" , strumenti software e hardware che forniscono la gestione sincrona e necessaria per l'emulazione nei sistemi multiprocessore, un ambiente di sviluppo integrato. Il debugger è una sorta di ponte tra lo sviluppatore e lo strumento di debug. Un buon debugger assicura che i programmi sottoposti a debug vengano caricati nella memoria di sistema, gli stati e il contenuto di tutti i registri e la memoria (e, se necessario, le loro modifiche) siano visualizzati sul monitor e il processo di emulazione sia controllato. Anche i debugger più potenti (comunemente indicati come debugger di alto livello o di alto livello) lo consentono.
Tale debugger consente all'utente di controllare contemporaneamente l'avanzamento del programma e vedere la corrispondenza tra il testo sorgente, l'immagine del programma in codici macchina e lo stato di tutte le risorse del microcontrollore emulato. Va notato che un debugger di alto livello fornisce l'esecuzione di tutte le sue funzioni solo se viene utilizzato un cross-compilatore che fornisce informazioni di debugging complete e corrette (non tutti i compilatori, specialmente le loro versioni pirata, sono in grado di farlo), e a allo stesso tempo il formato della sua presentazione "familiare" al debugger. La memoria di emulazione viene utilizzata nel processo di debug invece della ROM del sistema in fase di sviluppo. Inoltre, consente di eseguire il debug del programma in assenza di un sistema reale o del suo layout. Se è necessario apportare modifiche al programma in debug, è sufficiente caricare un programma nuovo o modificato nella memoria dell'emulatore, piuttosto che riprogrammare la ROM. Ci sono VSE. che consentono all'utente di "sostituire" la memoria di emulazione al posto della ROM non solo nella sua interezza, ma anche blocco per blocco (in alcuni modelli, la dimensione minima del blocco è di 1 byte). nell'ordine specificato dall'utente. Per fare ciò gli basta impostare la distribuzione della memoria dati e della memoria programma, in base alla quale il processore accederà sia al contenuto della ROM nel sistema in fase di debug sia al contenuto della memoria di emulazione del TSE. Tale memoria è solitamente chiamata memoria con possibilità di mappatura. Il tracciante è un analizzatore logico che funziona in modo sincrono con il processore e cattura il flusso delle istruzioni in esecuzione e lo stato dei segnali esterni selezionati. Esistono VSE che consentono di tracciare non solo i segnali esterni, ma anche gli stati delle risorse interne dell'MC. ad esempio i registri. In tali dispositivi vengono utilizzate versioni speciali di MK (cristalli di emulazione). Il processore del punto di interruzione consente di interrompere l'esecuzione del programma o eseguire altre azioni (ad esempio, avviare o arrestare il tracciante) quando vengono soddisfatte le condizioni specificate dall'utente, a differenza del normale meccanismo del punto di interruzione, il processore consente di formare e tenere traccia delle condizioni di quasi tutti complessità a livello hardware, pur essendo emulato il processo non viene dedotto dalla scala in tempo reale. In alcuni modelli VSE, il processore del punto di interruzione può essere facoltativamente utilizzato per controllare dinamicamente il tracciante. Il profiler (analizzatore di efficienza del codice del programma) consente, in base ai risultati dell'esecuzione del programma di debug, di ottenere informazioni sul numero di chiamate a varie sezioni del programma e sul tempo impiegato per la loro esecuzione. L'analisi delle informazioni statistiche fornite dal profiler consente di identificare sezioni di programmi "morte" o sovraccaricate e, di conseguenza, ottimizzare la struttura del programma sottoposto a debug. Un ambiente di sviluppo integrato è un insieme di strumenti software che supporta tutte le fasi dello sviluppo del software, dalla scrittura del codice sorgente di un programma alla compilazione e al debugging, e fornisce un'interazione semplice e veloce con un simulatore e un programmatore di debugger software. La presenza di un editor integrato, project manager e sistema di controllo nella shell del software VSE facilita notevolmente il lavoro dello sviluppatore, salvandolo da molte azioni di routine. Per lui, il confine tra scrivere un programma, modificarlo ed eseguire il debug è sfumato. Il passaggio dall'editing del testo sorgente al debugging e viceversa avviene in modo "trasparente" e sincrono con l'attivazione delle relative finestre. Il Project Manager avvia automaticamente la compilazione secondo necessità e attiva la corrispondente finestra dell'interfaccia del programma. Puoi procedere altrettanto facilmente al debug del progetto utilizzando il debugger del simulatore esistente o avviare il flashing della ROM con un programma di debug. Alcune ITU forniscono agli utenti altre funzionalità aggiuntive. Tra questi va notato in particolare uno, sebbene abbastanza specifico, ma in alcuni casi di fondamentale importanza, la capacità di costruire complessi multi-emulatore necessari per il debug sistemi multiprocessore... Una caratteristica distintiva di tale complesso è il controllo sincrono (da un computer) di diversi emulatori. Nel caso generale, la capacità del TSE di controllare e gestire il funzionamento dei dispositivi sottoposti a debug può essere limitata (ad esempio, gestione errata degli interrupt in modalità passo, divieto di utilizzo di una porta seriale, ecc.). È inoltre necessario ricordare che ogni modello VSE ha il proprio elenco di microcontrollori e compilatori supportati. Tuttavia, per la maggior parte dei microcontrollori popolari, sono stati sviluppati VSE che non hanno restrizioni sull'uso delle risorse dei cristalli sottoposti a debug. Illustreremo le possibilità di un tale ESS utilizzando come esempio il modello PICE-51 della società Fiton. PICE-51 è un dispositivo creato utilizzando un IC logico programmabile (FPGA). Ciò ha permesso di ridurre drasticamente le dimensioni del VSE, minimizzare le deviazioni delle sue caratteristiche elettriche e di frequenza dalle caratteristiche dell'MC emulato, e quindi ottenere la massima precisione di emulazione a frequenze fino a 33 MHz a tensioni di alimentazione da 3,3 a 5 V emulazione di quasi tutti gli MK della famiglia MCS-51. Il supporto software funziona in ambiente Windows. PICE-51 è costituito da una scheda madre, un adattatore sostituibile per un gruppo MK specifico e una testina di emulazione sostituibile anche per un tipo di case specifico. Un processore tracciante e un processore punto di interruzione sono assemblati sulla scheda principale e un processore di emulazione per un tipo specifico di MK è installato sulla scheda adattatore sostituibile. Le testine di emulazione consentono di installare il dispositivo negli zoccoli DIP e PLCC sulla scheda utente. L'alimentazione viene fornita da un blocco con una tensione di uscita di +5 V (0,5 A) o da un dispositivo in fase di debug. La comunicazione con un computer avviene tramite un canale RS-232C isolato galvanicamente a una velocità di 115 kbaud. Altre caratteristiche e capacità del PICE-51 sono le seguenti:
Una gamma così ampia di funzionalità rende VSE lo strumento di debug più potente e versatile. SIMULATORI Simulatore: uno strumento software in grado di simulare il funzionamento di MK e la sua memoria. In genere, è costituito da un debugger, un modello di CPU e una memoria. I dispositivi più avanzati contengono modelli di dispositivi periferici incorporati (timer, porte, ADC e sistemi di interrupt). Il simulatore dovrebbe "essere in grado" di caricare file di programma in tutti i formati più diffusi, visualizzare le informazioni sullo stato delle risorse del microcontrollore simulato nel modo più completo possibile. e forniscono anche opportunità per simulare l'esecuzione del programma caricato in varie modalità. Durante il debug, il modello esegue il programma e lo stato corrente del modello viene visualizzato sullo schermo del monitor del computer. Caricando il programma nel simulatore. l'utente può eseguirlo in modalità passo-passo o continua, impostare breakpoint condizionali o incondizionati, controllare e modificare liberamente il contenuto delle celle di memoria e dei registri del microcontrollore simulato. Il simulatore consente di verificare rapidamente la logica dell'esecuzione del programma, la correttezza delle operazioni aritmetiche. A seconda della classe di debugger utilizzata, alcuni modelli di simulatore supportano il debugging simbolico di alto livello dei programmi. Il simulatore può anche contenere una serie di strumenti software aggiuntivi, come un'interfaccia per l'ambiente esterno. La presenza di tale interfaccia consente di creare e utilizzare in modo flessibile un modello dell'ambiente esterno di MK. funzionare e influenzare il programma sottoposto a debug secondo un dato algoritmo. In un sistema reale, l'MC è solitamente "impegnato" a leggere informazioni da dispositivi esterni (sensori) ad esso collegati, elaborarle ed inviare segnali di controllo agli attuatori. Per simulare il funzionamento di un sensore in un semplice simulatore, è necessario modificare manualmente lo stato corrente del modello del dispositivo periferico a cui il sensore è collegato in un sistema reale. Se, ad esempio, quando si riceve un byte tramite una porta seriale, viene impostato un determinato flag e il byte stesso rientra in un determinato registro, entrambe queste azioni devono essere eseguite manualmente nel simulatore. In alcuni modelli, questo problema è risolto: i simulatori dispongono di strumenti integrati per la creazione di modelli di dispositivi esterni collegati a MK, inclusi strumenti per la visualizzazione grafica delle informazioni. Una caratteristica ovvia dei simulatori software è questa che i programmi in essi caricati vengano eseguiti in una scala temporale diversa dal tempo reale. Tuttavia, il prezzo contenuto, la possibilità di eseguire il debug anche in assenza di un modello del dispositivo sottoposto a debug, rendono i simulatori software uno strumento di debug molto interessante. Va inoltre notato che esiste un'intera classe di errori che possono essere rilevati solo utilizzando un simulatore. MONITOR DI DEBUG Un monitor di debug è un programma speciale che viene caricato nella memoria del sistema sottoposto a debug. Forza l'MK a svolgere, oltre al task applicato, anche funzioni di debug:
Il programma monitor lavora "in congiunzione" con un computer o un terminale passivo, sul quale avviene la visualizzazione e il controllo del processo di debugging. Il vantaggio di questo approccio
SCHEDE DI SVILUPPO Schede di sviluppo o, come vengono solitamente chiamate nella letteratura straniera, schede di valutazione (comitati di valutazione). - costruttori originali per la prototipazione dei sistemi applicati. Di recente, molte aziende manifatturiere, rilasciando nuovi modelli di MK. offerta e relative schede di sviluppo. Di solito si tratta di un circuito stampato con un MK installato su di esso e tutti gli elementi necessari per il suo normale funzionamento, nonché sistemi di comunicazione con un computer. Di norma, la scheda offre spazio libero per il montaggio del dispositivo utente in fase di sviluppo. A volte è presente anche un "cablaggio" già pronto per l'installazione di dispositivi aggiuntivi consigliati dall'azienda (ROM, RAM, display LCD, tastiera, ADC, ecc.). Le schede modificate dall'utente possono essere vantaggiosamente utilizzate come controllori a scheda singola integrati in prodotti di piccole dimensioni (5...20 pz.). Per comodità dell'utente, le schede di sviluppo sono inoltre dotate di un semplice strumento di debug basato sul monitor di debug. Qui sono emersi due diversi approcci: uno è utilizzato per MK. avere un bus esterno e il secondo - per MK che non ce l'hanno. Nel primo caso, il monitor di debug viene fornito come chip ROM. che è installato in una presa speciale sulla scheda di sviluppo. La scheda dispone inoltre di RAM per i programmi utente e di un canale di comunicazione con un computer o un terminale. Un esempio è la scheda di sviluppo sviluppata da Intel per la famiglia MK MCS-51. Nel secondo caso, la scheda di sviluppo contiene sistemi di programmazione integrati per la ROM interna dell'MK. che sono controllati da un computer. Il programma del monitor viene inserito nella ROM dell'MK insieme all'applicazione preparata di conseguenza (le chiamate delle routine di debug del monitor vengono inserite nei posti giusti). Quindi viene eseguita una corsa di prova. Per apportare correzioni al programma in fase di debug, viene cancellato dalla ROM e vi viene scritto quello corretto. Il programma applicativo finito si ottiene da quello sottoposto a debug rimuovendo il monitor e tutte le chiamate alle sue funzioni. Le schede di sviluppo per MK delle famiglie PIC-micro (Microchip), 80C750 (Philips), 89C2051 (Atmel) sono progettate per tale algoritmo di debug. Le schede di sviluppo sono talvolta dotate di programmi di debug che vengono eseguiti su un computer esterno "insieme" a un monitor. Questi programmi sono recentemente diventati notevolmente più complessi e spesso hanno un insieme altamente professionale di funzioni di debug (ad esempio, un simulatore di debugger) o vari elementi che sono inerenti solo agli ambienti di sviluppo integrati nella loro forma pura. I kit possono anche includere programmi applicati che si incontrano più spesso nella pratica. Le capacità di debug del kit "scheda di sviluppo più monitor" non sono universali come quelle dell'ESS. inoltre, alcune delle risorse MC nel processo di debug vengono selezionate affinché il monitor funzioni. Tuttavia, la disponibilità di un set completo di strumenti software e hardware già pronti che consentono di avviare l'installazione e il debug del sistema applicato senza perdite di tempo è in molti casi un fattore decisivo. Soprattutto se si considera che un kit del genere costa parecchie volte meno di un emulatore più versatile. EMULATORI ROM Un emulatore ROM è uno strumento software e hardware che consente di sostituire la ROM del dispositivo sottoposto a debug con la RAM. in cui è possibile scaricare il programma dal proprio computer tramite uno dei canali di comunicazione standard. Consente all'utente di evitare cicli multipli di flashing della ROM. L'emulatore ROM viene utilizzato solo per il debug di programmi MK che sono in grado di accedere alla memoria del programma esterno. In termini di complessità e costo, questo dispositivo è paragonabile alle schede di sviluppo. Ha un grande vantaggio: la versatilità. L'emulatore ROM può funzionare con qualsiasi MK. I primi emulatori ROM consentivano solo il caricamento, l'esecuzione e l'arresto di un programma utilizzando un ripristino generale. Poi c'erano modelli complicati con generazione hardware di segnali di traccia all'oscilloscopio al raggiungimento di un certo indirizzo. La memoria emulata in tali prodotti era disponibile per la visualizzazione e la modifica, ma il controllo sui registri di controllo interni dell'MK era fino a poco tempo fa impossibile. Di recente sono apparsi i cosiddetti emulatori ROM intelligenti. Ti permettono di "guardare" all'interno dell'MC sulla scheda utente e sono simili nel controllo del debug al VSE. Cactus presenta persino il suo emulatore ROM effettivamente intelligente come il VSE della serie MK, è così impossibile distinguere tra lavorare con uno e l'altro, infatti il processore in questo caso non viene sostituito, e viene utilizzato quello a pagamento dell'utente. L'emulatore smart ROM è un ibrido del normale emulatore ROM. un monitor di debug e un sistema per commutare rapidamente il bus da uno all'altro. Questo crea l'effetto come se il monitor di debug fosse installato sulla scheda dell'utente, e allo stesso tempo praticamente non occupa risorse hardware da MK, ad eccezione di una piccola zona (circa 4 KB) di passaggi software. Tale emulatore è stato sviluppato, ad esempio, dalla società Fiton per tutti gli MK esistenti e futuri che hanno il core 8051, ma sono inoltre saturi di vari dispositivi di input / output. Il prodotto supporta molti MC diversi di Philips, Siemens. OKI. AMBIENTI DI SVILUPPO INTEGRATO A rigor di termini, gli ambienti di sviluppo integrati non sono tra gli strumenti di debug, tuttavia, sarebbe sbagliato ignorare questa classe di strumenti software che facilitano e velocizzano notevolmente il processo di sviluppo e debug dei sistemi a microprocessore. Con l'approccio tradizionale, la fase iniziale di scrittura di un programma è strutturata come segue. Il testo di origine viene digitato utilizzando un editor di testo. Al termine della digitazione, il lavoro con l'editor di testo si interrompe e si avvia il compilatore incrociato. Di norma, un nuovo programma contiene errori di sintassi e il compilatore li segnala alla console dell'operatore. Quindi l'editor di testo viene riavviato e l'operatore cerca ed elimina gli errori identificati. Allo stesso tempo, i messaggi sulla loro natura, visualizzati dal compilatore, non sono più visibili, poiché lo schermo è occupato da un editor di testo. Questo ciclo può ripetersi più di una volta. E se il programma è relativamente complesso, è assemblato da varie parti, è soggetto a modifiche o aggiornamenti, anche questa fase iniziale può richiedere molto impegno e tempo al programmatore. Per evitare una grande quantità di lavoro di routine e quindi aumentare significativamente la produttività di un programmatore, i cosiddetti ambienti di sviluppo integrati (shell) di sviluppo (Integrated Development Environment IDE) che sono apparsi e stanno rapidamente guadagnando popolarità consentono. Di norma, un buon ambiente integrato combina gli strumenti di debug disponibili (emulatore in-circuit, simulatore software, programmatore) e fornisce al programmatore testi di programma in stile "Turbo". L'ambiente integrato consente:
Recentemente le funzionalità degli ambienti di sviluppo integrato sono entrate a far parte delle interfacce di programmazione degli emulatori e dei simulatori di debugger più “avanzati”. Tale funzionalità, combinata con un'interfaccia amichevole, accelera notevolmente il lavoro del programmatore. Pertanto, quando si scelgono gli strumenti di debug, è consigliabile tenere conto del seguente insieme di indicatori: l'elenco dei microcontrollori supportati, le restrizioni sulle risorse dei microcontrollori emulati / simulati, la possibilità di debug simbolico, l'elenco dei compilatori supportati e, infine, capacità di servizio. Autori: Yu.Zobnin, Sh.Kobakhidze, Mosca
Macchina per diradare i fiori nei giardini
02.05.2024 Microscopio infrarosso avanzato
02.05.2024 Trappola d'aria per insetti
01.05.2024
▪ Alternativa al silicio per microcircuiti ▪ Perché i dinosauri hanno il collo lungo ▪ ULF Toshiba TCB701FNG integrale a quattro canali
▪ sezione del sito Materiali di riferimento. Selezione dell'articolo ▪ articolo E chissà cosa sbatte le palpebre. Espressione popolare ▪ Da quale animale prendono il nome le Isole Canarie? Risposta dettagliata ▪ articolo di Ungerniy Viktor. Leggende, coltivazione, metodi di applicazione ▪ controller del motore passo-passo. Enciclopedia dell'elettronica radio e dell'ingegneria elettrica
Homepage | Biblioteca | Articoli | Mappa del sito | Recensioni del sito
www.diagram.com.ua |
Vedi altri articoli sezione 
Ultime notizie di scienza e tecnologia, nuova elettronica:
Tutte le lingue di questa pagina