Lezione 1

Step 3/6

Passo precedenteInizio lezionePasso successivo

Scrittura e compilazione di un programma in assembler

 

Come per qualsiasi sistema a microprocessore, anche per il PIC è necessario preparare un programma che gli consenta di svolgere il suo lavoro.

Un programma è costituito da un elenco di instruzioni in sequenza, ognuna delle quali identifica univocamente le funzioni di base che il PIC è in grado di svolgere. Ogni istruzione è rappresentata da un codice operativo (in inglese operation code o più brevemente opcode) a 14 bit ed è memorizzata in una locazione di memoria EEPROM. Tale memoria nel PIC16F84 dispone di 1024 locazioni ognuna delle quali è in grado di contenere una sola istruzione. Un esempio di opcode in notazione binaria viene riportato di seguito:

00 0001 0000 0000B

è più probabile però che un opcode venga rappresentato in notazione esadecimale ovvero:

0100H

che rappresenta esattamente lo stesso valore ma in forma più breve. La lettera H, riportata alla fine del valore valore 0100, indica il tipo di notazione (Hexadecimal). Lo stesso valore può essere rappresentato in assembler con la notazione 0x100 derivante dal linguaggio C o H'0100'.

Questi codici, completamente privi di senso per un essere umano, sono gli unici che il PIC è in grado di capire. Per facilitare il compito al programmatore, si ricorre ad alcuni strumenti e convenzioni per rendere le istruzioni più comprensibili.

La prima covenzione è quella di associare ad ogni opcode (in totale 35 per il PIC16F84) una sigla mnemonica, ovvero una sigla che aiuti a ricordare il significato dell'istruzione.

Tornando al nostro esempio l'opcode 0100H corrisponde all'istruzione mnemonica CLRW che è la forma breve dell'istruzione CLEAR W REGISTER, ovvero azzera il registro W (vedremo meglio di seguito che cosa significa).

Altre convenzioni consentono di definire delle variabili, delle costanti, delle etichette (label) di riferimento agli indirizzi di memoria, ecc. L'insieme di queste convenzioni atte a facilitare la stesura di un programma per PIC viene chiamato linguaggio assembler. Un programma scritto in linguaggio assembler può essere scritto su un PC utilizzando un qualsiasi word processor o editor in grado di generare file ASCII. Un file ASCII o, per meglio dire, un file di testo che contenga un programma in assembler viene denominato source o sorgente assembler.

Una volta preparato il nostro source assembler (e vedremo tra breve come), occorre un programma in grado di tradurre le istruzioni mnemoniche e tutte le altre forme convenzionali con cui è stato scritto il nostro source in una serie di numeri (gli opcode) riconoscibili direttamente dal PIC. Questo programma si chiama compilatore assembler o assemblatore.

Nella figura seguente viene schematizzato il flusso di operazioni e file che vengono generati per passare da un source assembler ad un PIC programmato.

 

 

Come già detto la prima operazione da effettuare è la scrittura del source assembler e la sua memorizzazione in un file di testo con estensione .ASM. Per far questo abbiamo detto che occorre utilizzare un editor ASCII, ovvero un programma di scrittura quale ad esempio il NOTEPAD.EXE di Windows 3.1© o Windows 95© o l'EDIT.EXE di MS/DOS©. E' possibile generare questo file anche con programmi di elaborazione testi più sofisticati quali Word© o Wordperfect© avendo l'accortezza di memorizzare sempre il file prodotto in formato testo e non in formato nativo. Questo per evitare che vengano memorizzati anche i caratteri di controllo della formattazione del testo che il compilatore assembler non è in grado di trattare.

Nel nostro primo esperimento pratico utilizzeremo il file LED.ASM.

Il passo successivo è la compilazione del source, ovvero la trasformazione in opcode dei codici mnemonici o istruzioni assembler in esso contenute.

Il compilatore assembler che utilizzeremo è l'MPASMWIN.EXE prodotto dalla Microchip e disponibile sul loro sito internet; è possibile comunque scaricarne una copia nella pagina dei downloads.

Come è possibile vedere nella precedente, oltre al nostro source con estensione .ASM è necessario fornire al compilatore un secondo file prodotto dalla Microchip con estensione .INC differente a seconda del tipo di PIC che stiamo utilizzando. Nel nostro caso il file è il P16F84.INC. Questo source contiene alcune definizioni dipendenti dal chip utilizzato che vedremo più avanti.

Durante la compilazione del source, il compilatore assembler genera una serie di file con nome identico al source ma con estensione diversa:

  • .HEX è il file che contiene i codici operativi da inviare al PIC tramite il programmatore.
  • .LST è un file di testo in cui viene riportato l'intero source assembler e la corrispondente traduzione in opcode. Non è utilizzabile per la programmazione del PIC ma è estremamente utile per verificare i processi di compilazione che ha eseguito il compilatore.
  • .ERR contiene la lista degli errori di compilazione riscontrati ed il numero di linea all'interno del source assembler in cui sono stati rilevati.

I file .LST, .ERR vengono utilizzati per il controllo di quanto effettuato in compilazione. Solo il file .HEX viene utilizzato realmente per programmare il PIC. Vediamo ora come.

I file .HEX non sono file in formato binario e non rispecchiano quindi direttamente il contenuto che dovrà avere la EEPROM del PIC. Il loro formato però rispecchia direttamente quanto sarà trasferito al PIC in una forma leggibile e con alcune istruzioni in più.

Senza entrare ora nei dettagli è utile sapere che tale formato è direttamente riconoscibile dal programmatore di PIC che provvederà durante la programmazione a convertire in binario e contiene, oltre agli opcode altre informazioni aggiuntive quali gli indirizzi in cui vanno trasferiti gli opcode.

Nel passo successivo analizzeremo il nostro primo source assembler e vedremo buona parte delle convenzioni utilizzate nel linguaggio assembler.

 
Home page

PICPOINT, SXPOINT and ELETTROSHOP (C) 1997/98 by Andrea Galizia
For comments on this web site, write to webmaster@picpoint.com
Web design by Tiziano Galizia

Pic by example (c) 1997/98 by Sergio Tanzilli & Tiziano Galizia