Alcune FAQs dall' Help di MPASMWIN
Al termine dell' assemblaggio la finestra di stato indica "Assembler Error."
Questo vuol dire che MPASM non è stato in grado di completare un corretto
assemblaggio a causa di uno o più errori incontrati nel sorgente. Editando il
file .ERR
si potranno identificare le linee del sorgente errate e correggerle
opportunamente.
Come faccio a correggere l' errore "Illegal Parameter"?
Per prima cosa va verificato cosa si è scritto nella finestra Extra Options. Se
non c'è nulla di problematico, va verificata la lista degli errori che
indicherà una o più linee in cui la sintassi o la forma o il contenuto sono
inaccettabili dall' Assembler. Osservate anche se prima delle linee contenenti
l' errore non ne esistono altre diversamente errate; infatti capita facilmente
che un errore in una linea si rifletta nella impossibilità di compilare linee
seguenti. Ad esempio, una linea di dichiarazione errata di un parametro
impedirà l' uso di quel parametro, segnalando un errore ogni volta che esso viene richiamato.
Che cosa è il settaggio "DEFAULT" presente come scelta in
diverse opzioni ?
Se avete scelto la selezione Default e nel sorgente è presente la
dichiarazione di una radice, ad esempio RADIX HEX, questa sarà la dichiarazione
valida ed i numeri saranno intesi come esadecimali.
Se scegliete un valore che non sia Default, quel valore sovrascriverà qualsiasi
altra scelta impostata nel sorgente. Per esempio, se non avete dichiarato
una radice o avete dichiarato RADIX HEX nel sorgente e scegliete la selezione
Decimal nella finestra delle opzioni, l' assemblaggio avverrà considerando i
numeri come decimali e non come esadecimali.
Non ho il file di uscita che volevo.
All' uscita ottenete solo i file che avete selezionato nelle opzioni. C' è l'
eccezione del caso in cui l' Assembler identifichi un errore. In questa
circostanza, non si otterrà alcun file .HEX o, pur avendolo selezionato,
non sarà prodotto il file oggetto : essi non vengono semplicemente generati, in
quanto non avrebbe senso produrre un file oggetto errato e quindi sicuramente non
funzionante a priori.
Ripetendo l' assemblaggio, cosa succede ai files generati ?
Se non è stato cambiato il nome al sorgente o scelta una opzione il quelle
Extra, un nuovo assemblaggio del sorgente da in uscita files con gli stessi
nomi, che sovrascrivono quelli esistenti. Il file sorgente non viene mai
modificato dall' Assembler : solamente l' utente effettuerà le modifiche; ma se
ha assemblato il file Prova.asm e ottenuto i files Prova.lst e Prova.err ,
modificando il testo Prova.asm e salvandolo con lo stesso nome, una nuova
operazione di assemblaggio produrrà nuovi Prova.lst e Prova.err, che si
sostituiscono ai precedenti, che vanno persi. Se, quindi, si vuole mantenere un
archivio delle successive versioni, sarà necessario chiamare la seconda
versione Prova1.asm, che originerà Prova1.lst e Prova1.err e così via.
MPASM rileva errori in linee che apparentemente sono corrette
- innazitutto va detto che i compilatori sono estremamente rigidi sulle regole
sintattiche e formali ( e non può essere diversamente). Quindi, uno spazio
mancante, una virgola fuori posto, un apice dimenticato generano immediatamente
un errore.
- In secondo luogo, come già detto, un errore in una linea può sottrarre i
termini per la compilazione di linee successive, per cui una linea
apparentemente corretta darà errore semplicemente perchè altre linee prima
sono risultate affette da errori. Correggendo queste, anche le altre andranno a
posto da sole.
-
Anche errori nell' assegnazione del tipo di processore, il cui .INC non combina
con quanto specificato nelle linee del sorgente può dare origine a numerosi
errori. Così pure richiami a label non presenti nel sorgente, ma in file
esterni e non dichiarati con un include.
- Va considerato che diverse versioni dello stesso prodotto possono
riportare indicazioni di warning diverse, in quanto le più recenti
probabilmente hanno un numero maggiore di test.
- Per ultimo, è opportuno considerare che la sintassi dell' Assembler
prodotto dall' azienda XY può non essere adatta a
quello prodotto dall' azienda YZ, per cui lo stesso testo sorgente, perfettamente
funzionante nel primo, sul secondo non potrà andare a buon fine senza le
necessarie modifiche. Se il sorgente non è scritto esplicitamente per la
sintassi di MPASM, è possibile che alcune righe generino errore solamente a
causa dell' applicazione di una diversa regola sintattica.
MPASM rileva un errore di impossibilità a raggiungere un file di un un #include
presente nella lista sorgente
MPASM è un programma scritto
originariamente per DOS. Non ha le necessità di un programma grafico, in
quanto non lo è, lavorando solamente su una lista ASCII (il sorgente) per
produrre una serie di files.
A fronte di una robustezza, efficienza e semplicità che i programmi Windows
non hanno, si trova ad avere possibili idiosincrasie per quanto riguarda i
path dichiarati nel sorgente per i file da includere nell' assemblaggio.
Se si verifica questa situazione,
basta fare una copia del file incriminato nella stessa cartella che contiene
il sorgente e cambiare il path relativo.
Nell' assemblaggio ho un sacco di strani messaggi relativi a banchi o a pagine o
a default ...
La struttura dei PIC a più banchi costringe i programmatori a scrivere sorgenti
Assembly che tengano conto
con precisione del banco in cui si trova un certo registro, altrimenti si
accederà a tutt'altra locazione. Dove si abbia a che fare con i banchi e il
registro richiesto non si trovi nel banco dei default (Bank 0), l' Assembler
genererà un messaggio di avviso (warning) in modo da allertare l' utente sulla
possibilità di un errore.
Così pure esistono istruzioni il cui risultato può essere depositato in
destinazioni diverse. Ad esempio incf (incrementa
file) può depositare il file incrementato sia nel file stesso che nell'
accumulatore w, a seconda dello stato di un bit del codice dell' istruzione;
così incf file, f avrà come destinazione il
registro (file), mentre incf file,w avrà
come destinazione l' accumulatore. MPASM , incontrando una linea che
contenga solo incf file , di per se incompleta, la
compilerà comunque, utilizzando il suo default (che è incf
file,f ), ma avvertirà l' utente della cosa in modo che possa provvedere
se la sua intenzione era diversa. Questa è una delle ragioni per cui l'
abolizione totale della stampa di warning non è consigliabile a meno che si
sappia bene cosa si sta facendo.
Tutte queste particolarità ( e molte altre...) sono elencate nella
documentazione relativa all' Assembler e vanno conosciute prima di mettersi a
scrivere sorgenti o, per lo meno, in presenza di messaggi di errore o warnings
la documentazione va consultata per avere le informazioni necessarie alla
soluzione del problema.
|
|
Copyright © afg. Tutti i diritti riservati.
Aggiornato il 06/12/10.
|