|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese|
ENCICLOPEDIA DELLA RADIOELETTRONICA ED ELETTRICA Debug dei microcontrollori utilizzando un emulatore ROM. Enciclopedia dell'elettronica radio e dell'ingegneria elettrica
Enciclopedia della radioelettronica e dell'elettrotecnica / microcontrollori La complessità dello sviluppo e del debug del programma di lavoro di un dispositivo elettronico contenente un microprocessore determina spesso il costo del suo sviluppo nel suo complesso. Nei microcontrollori (MC), che hanno memoria integrata e alcuni dispositivi periferici, questo è particolarmente pronunciato. Uno degli strumenti che facilita notevolmente il debugging è l'emulatore ROM descritto in [1]. L'articolo proposto descrive la tecnologia per lavorare con esso. Le capacità di debug non sono limitate ai metodi descritti. Questo processo, così come il progettare in generale, è in una certa misura un'arte: per uno stesso strumento ognuno crea la "sua musica". Saremo grati ai lettori che condivideranno i loro strumenti e metodi originali per il debug dei programmi MK. La complessità e la laboriosità del processo di debug del software MC è determinata dai seguenti fattori [2]:
Le apparecchiature di test tradizionali (come un oscilloscopio) possono essere utilizzate solo in misura limitata per il debug dell'MCU. Il metodo di debug più semplice (e allo stesso tempo il più inefficiente) è il "metodo per tentativi ed errori": caricare il programma in una memoria di sola lettura riprogrammabile (EPROM), tentare di eseguirlo, rilevare e correggere gli errori nel programma e hardware, cancellazione della EPROM, ricarica del programma, ecc.. e) I processi di cancellazione e scrittura dei dati sul chip EPROM richiedono molto tempo e, dopo un certo numero di cicli di riprogrammazione, generalmente falliscono. L'installazione e la rimozione ripetute del microcircuito riducono l'affidabilità dei contatti elettrici nella presa EPROM. La possibilità di ottenere informazioni di debug sul sistema è praticamente assente. Attualmente, MK viene spesso sottoposto a debug da strumenti incrociati basati su un personal computer. Ciò consente una minima distrazione delle risorse MC. Il dispositivo da debuggare, come mostrato in figura, è connesso al computer tramite uno strumento, come un emulatore ROM. Un tale complesso consente di scaricare e modificare il programma, inserire moduli di test, ottenere determinate informazioni sul sistema e molto altro, di cui parleremo di seguito. Sebbene gli emulatori ROM non siano l'unico e non il più potente strumento di debug, sono ancora popolari. La loro "longevità" è spiegata dall'indipendenza dal tipo di MC (è necessaria solo la capacità di lavorare con memoria di programma esterna), funzionamento in tempo reale, prezzo basso e accessibilità a un'ampia gamma di sviluppatori di apparecchiature e radioamatori. Considereremo la tecnologia di debug di un programma utilizzando un emulatore ROM utilizzando l'esempio della famiglia di MCS-51 (8031, 8051, 80C31, 80C51. KR1816BE31, KR1816BE51, KR1830BE31, KR1830BE51, ecc.). Avviando il debug, è necessario verificare l'operatività dell'hardware del sistema e dell'MC stesso. Per fare ciò, puoi utilizzare i test "contaggio libero" [3]. che consiste nell'enumerazione di tutte le possibili combinazioni di codice sulle linee delle porte MK. Durante il test, le linee delle porte verranno impostate sullo stato di uscita, quindi prima di tutto assicurati, in base al dispositivo in debug, che non vengano caricate sulle uscite di altri elementi. Scollegare temporaneamente tali carichi, se presenti. Caricare l'emulatore ROM con i codici di comando No Operation (NOP) all'interno dell'intero spazio degli indirizzi dei programmi MCU. Per MCS-51 questo è il codice 00H. Quando si esegue un tale "programma", MK passa in sequenza attraverso tutti gli indirizzi della memoria del programma. Monitorare i segnali di ALE, PME e le porte P0, P2 con un oscilloscopio. Le forme d'onda sulle linee di porta devono corrispondere ai diagrammi di temporizzazione del contatore binario, tenendo conto del multiplexing su P0 del byte basso dell'indirizzo e dei dati. Successivamente, controllare le porte P1 e P1 caricando il programma di test mostrato nella Tabella 00 nell'emulatore ROM. 0. Emette una sequenza di codici da XNUMXH a XNUMXFFH sulle linee delle porte specificate, simulando un contatore binario a otto bit. Se gli oscillogrammi corrispondono a quelli richiesti, ripristinare i carichi scollegati dalle porte e procedere al debug del programma di lavoro dell'MC. Ricorda che stai eseguendo il debug del software e dell'hardware del sistema contemporaneamente e non dimenticare di monitorare periodicamente i segnali nei punti di test con l'oscilloscopio. L'incoerenza del tipo di segnali con le tue idee su di essi è motivo di seria riflessione e ulteriori controlli.
Per facilitare lo sviluppo e il debug, si dovrebbe aderire al principio modulare della programmazione, ovvero dividere il programma MK in parti secondo una caratteristica funzionale. Ciò ti consentirà di spostare facilmente i singoli moduli e, se necessario, applicarli in altri progetti. Il modulo a cui viene trasferito il controllo dopo l'accensione o il ripristino dell'MK è chiamato principale o principale. Il trasferimento del controllo al punto di ingresso del programma dovrebbe essere un comando di salto, non una chiamata di subroutine, in modo da non contaminare lo stack con l'indirizzo di ritorno. Per evitare risultati imprevisti del programma, ricordarsi di assegnare un valore iniziale a ciascuna delle variabili prima di utilizzarla per la prima volta. In alcuni casi, potrebbe essere necessario inizializzare le periferiche. Il blocco di inizializzazione si trova all'inizio del modulo del programma principale. Una vista approssimativa del modulo principale del programma all'inizio del debugging è mostrata in Tabella. 2. Contiene solo il punto di ingresso al programma e il gestore di uscita. Sebbene tale uscita sia raramente utilizzata nei sistemi a microcontrollore, deve essere prevista per la corretta conclusione delle situazioni di emergenza. Nell'esempio in esame, dopo il completamento del lavoro, il programma "loop". Solo il riavvio del sistema con un segnale di ripristino dell'hardware lo farà uscire da questo stato.
Durante il debug, altri moduli del programma vengono aggiunti al modulo principale man mano che sono pronti. L'ordine della loro connessione e del debug gioca un ruolo importante. Dovresti iniziare con i driver per i dispositivi di output delle informazioni (display, convertitore digitale-analogico, ecc.), inserendo le loro chiamate nel modulo principale. Quindi eseguono il debug dei driver di altri dispositivi periferici, delle routine di elaborazione dei dati e solo successivamente controllano il funzionamento congiunto di tutti i moduli del programma. Se è presente un display alfanumerico, il relativo driver viene prima sottoposto a debug e successivamente utilizzato per visualizzare le informazioni di debug, ad esempio il contenuto della memoria dati interna dell'MK. Se viene utilizzato un emulatore ROM tale che le informazioni in esso contenute possano essere scritte e lette sia dal computer di controllo che dal dispositivo sottoposto a debug, MK può posizionare i dati di debug nell'area di memoria libera dell'emulatore ROM e il il computer di controllo li legge e li visualizza sul suo display. Ad esempio, per emettere il contenuto della RAM dati interna dell'MCU, collegare l'uscita del segnale di scrittura (WR) della memoria dati esterna all'ingresso del segnale di scrittura dell'emulatore ROM e utilizzare la subroutine mostrata nella Tabella 3. 32. Si presuppone che la quantità di memoria di programma del dispositivo sottoposto a debug non superi i 8000 KB, quindi le informazioni di debug inserite nella memoria dell'emulatore iniziano all'indirizzo 0H. I contenuti dei registri R1 e R8000 vengono inviati separatamente, poiché vengono successivamente utilizzati nel sottoprogramma per organizzare il loop. Dopo l'emissione delle informazioni di debug, il programma MK viene sospeso, il contenuto delle celle di memoria dell'emulatore ROM 807H-XNUMXFH viene letto dal computer di controllo, visualizzato e analizzato. Allo stesso modo, è possibile visualizzare il contenuto di tutti i registri MC accessibili a livello di programmazione.
Quando si avvia il debug di un driver di dispositivo periferico, disabilitare temporaneamente i segnali di controllo generati da MK per evitare possibili guasti del dispositivo dovuti a errori nel programma. Se il processo è una tantum, "loop" e, se necessario, programmare il segnale di clock dell'oscilloscopio.Eseguire il debug del driver monitorando i segnali generati dall'oscilloscopio. Dopo essersi assicurati che i diagrammi di temporizzazione dei segnali di controllo corrispondano a quelli richiesti, collegare la periferica e continuare il debug del driver su hardware reale. Infine, rimuovere gli elementi di debug dal modulo del programma e verificarne il funzionamento nella forma finale. L'utilizzo di risorse MK condivise da parte di moduli diversi porta abbastanza spesso al fatto che il programma di debug smette di funzionare quando viene aggiunta un'altra subroutine, pertanto, dopo aver eseguito il debug del modulo successivo, assicurarsi che tutti i driver e le subroutine precedentemente sottoposti a debug continuino a funzionare correttamente. Se il tuo programma utilizza gli interrupt, non disabilitarli a meno che non sia assolutamente necessario. Un modulo sottoposto a debug non deve essere rimosso dal programma, anche se non è attualmente necessario. Quando l'MK "si blocca", è utile il seguente metodo di localizzazione degli errori: inserire punti di controllo nel programma che visualizzino numeri in sequenza crescente. Dopo la "sospensione" il display mostrerà il numero corrispondente all'ultimo punto di controllo superato con successo. Se molti di questi punti vengono catturati in un loop infinito, i numeri sul display cambieranno rapidamente. Per determinare esattamente quali punti si trovano nel ciclo, dovrai rallentare artificialmente il cambio di numeri impostando un ritardo del programma durante l'emissione di ciascuno di essi, ad esempio sotto forma di un ciclo inattivo. Se il sistema sottoposto a debug non dispone di un display integrato, è possibile visualizzare le informazioni sul display del computer host tramite l'area di memoria libera dell'emulatore ROM. Dopo aver eseguito il debug di tutti i driver di dispositivo, avviare il debug di altre subroutine. Se qualcuno di essi implementa un algoritmo complesso per l'elaborazione o la conversione dei dati, la visualizzazione di uno o più valori intermedi delle variabili spesso non fornisce informazioni sufficienti per l'analisi degli errori Superare le difficoltà e scrivere le informazioni di debug della quantità richiesta nell'area di memoria libera di l'emulatore ROM aiuterà a superare le difficoltà. Dopo aver raggiunto il normale funzionamento di tutti i moduli del programma, è possibile eseguirne il debug insieme. Le difficoltà che sorgono in questo caso sono divise in due gruppi. Il primo include i problemi di condivisione delle risorse MK comuni: unità logica aritmetica, memoria dati, porte input-output. Il secondo è relativo al funzionamento dei dispositivi a microcontrollore in tempo reale. I sistemi in tempo reale sono generalmente multi-thread. Diverse attività del programma (thread) vengono eseguite in parallelo, interagendo tra loro e utilizzando risorse comuni. Ma in ogni momento l'MC, per la sua struttura, ne risolve solo uno, passando a sua volta ad altri, tenendo conto della priorità. I conflitti tra compiti sorgono sia per mancanza di risorse che per mancanza di tempo per l'elaborazione dei dati. Pertanto, prestare particolare attenzione alle risorse MK utilizzate nei moduli del programma, controllando spesso il cambiamento del loro stato visualizzando le informazioni di debug. Prova a ridurre il numero di variabili globali, sostituendole con quelle locali quando possibile. Monitorare lo stato dello stack. Stimare il tempo di esecuzione delle sezioni critiche del programma, controllare il sistema con vari valori di segnali di ingresso possibili nella pratica. Utilizzando l'emulatore ROM, puoi anche eseguire il debug di un programma progettato per funzionare nella memoria interna dell'MK, se lo metti temporaneamente nella memoria del programma esterno. Poiché in questo caso le porte P0 e P2 saranno occupate dal servizio di memoria esterna, allora se le restanti linee I/O libere dell'MK non sono sufficienti, P0 e P2 vengono sostituite con porte I/O indirizzate come celle di memoria dati esterna. Sono collegati secondo schemi standard, utilizzando registri trigger per aumentare il numero di linee di uscita e il numero di linee di ingresso - elementi con tre stati di uscita. Dopo aver eseguito il debug del sistema utilizzando l'emulatore, rimuovere gli elementi di debug da esso, scrivere il programma nella ROM (o nella memoria interna del programma MK) e controllare il funzionamento del dispositivo nella sua forma finale. Letteratura
Autori: G.Vydolob, V.Samoylov, Mosca (Zelenograd)
Macchina per diradare i fiori nei giardini
02.05.2024 Microscopio infrarosso avanzato
02.05.2024 Trappola d'aria per insetti
01.05.2024
▪ Unità portatile Toshiba Canvio Alu ▪ Pannello OLED da 0,97 mm di spessore ▪ Serie di relè FTR-H3 di FUJITSU COMPONENTS
▪ sezione del sito Auto. Selezione dell'articolo ▪ articolo Ci sono solo ragazze nel jazz. Espressione popolare ▪ articolo Dove sono nate le prime scuole? Risposta dettagliata
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