Assembler in MplabX

...buono a sapersi!

Pero' e' strano.

Il resto del program counter e' corretto o viene resettato?
Se tutto il registro e' resettato potrebbe essere indice di un reset.

Nel map file generato dall'assemblatore le etichette sono posizionate in maniera corretta (indirizzo corretto)?

Il problema potrebbe discendere anche dall'assemblatore.
potresti provare il programma sia con il vecchio assemblatore del C18 che con il nuovo del XC8.
Un utente, qualche mese fa ha avuto problemi strani, con un compilatore andava e con un altro no.

Saluti,

Mauro

Ciao Mauro

io ho allocato tutto il programma a partire dalla locazione 0x0000, mentre la routine Visualizza l'ho allocata a partire dalla locazione 0x0100, ho controllato questa distribuzione usando Pic Memory View - Program Memory dal menù Windows è risulta come impostata. (non conosco il map file)
Dall'analisi che ho condotto con il debugger ICD3 ho notato:
1) all'istruzione "call Visualizza" viene impostato correttamente il program counter (PCL=00 - PCLATH=01);
2) appena eseguo la prima istruzione della routine "Visualizza" (andlw 0x02) il program counter viene aggiornato correttamente (ma con PCL=02 (OK) - PCLATH=00 ????);
3) ovviamente il controllo passa alla seconda istruzione della routine addwf PCL, 1 e il program counter viene ancora aggiornato correttamente (ma con PCL=04 (OK) - PCLATH = 00);
4) siccome adesso il program counter è costretto a leggere i vari registri PCL, esso si aggiorna erroneamente perchè PCLATH=00, ovviamente il controllo ritorna alla terza istruzione del programma principale interrompendo anzitempo l'esecuzione della routine, quindi non è intervenuto un reset;
5) ho aggirato momentaneamente l'ostacolo impostando inizialmente PCLATH=01, in questo modo quando eseguo la routine il PCLATH non viene modificato ed il tutto funziona come previsto;
6) sto usando l'assembler 5.47, ho provato anche con la Freedom II e si comporta allo stesso modo, non ho provato con il C, penso di provarci la prossima settimana.

Saluti

Giovanni

Ciao Giovanni,

se hai modo cerca di compilare il tutto facendo uso versioni piu' vecchie del compilatore o usando il nuovo compilatore assembly associato al XC8.
non mi aspetto che il problema sia di tipo hardware per cui indipendente dalla scheda di sviluppo.

Il file di map e' il riassunto dei vari indirizzi e codice.
Se memoria non mi inganna non viene generato di defualt ma lo devi richiedere tra le opzioni del progetto.

Dal momento che hai una traduzione 1:1 tra codice assembly e linguaggio macchina potresti anche fare una "traduzione" del codice generato dall'assemblatore e vedere se e' corretto.

Saluti,

Mauro

Ciao Mauro

Nell'intento di capirci qualcosa di sicuro, piuttosto che fare supposizioni e prove generiche tentate dall'esperienza, ho pensato bene di rileggermi attentamente il manuale del PIC, in particolare il capitolo che tratta la gestione del Program Counter, nella organizzazione della memoria.
Con mia grande sorpresa ho trovato scritto che il PCLATH e il PCLUTH:
1) vengono trasferiti al Program Counter solo in occasione di scrittura del PCL;
2) il Program Counter viene trasferito a PCLATH e a PCLUTH solo quando effettuo operazioni di lettura del PCL;
3) le istruzioni CALL, GOTO, RCALL modificano direttamente il Program Counter senza interessare I registri PCLATH e PCHUTH.
Stando così le cose è evidente che l'esempio che riporta il manuale per gestire una tabella è palesemente errato (non può funzionare). A conferma di ciò, a supporto di una demoboard della Microchip, sono forniti degli esempi in assembler, di cui uno riguarda la gestione delle tabelle e guarda caso nell'esempio si sono presi la briga di modificare manualmente il PCLATH, altrimenti l'esempio, in base alle allocazio ni potrebbe non funzionare.
Conclusione: a questo punto credo che l'assemblatore funzioni correttamente rispettando quanto scritto sul manuale, mentre l'errore sta nel simulatore.

Saluti

Giovanni

Ottimo!

...ho imparato nuovi problemi e soluzioni senza scottarmi!
I benefici del Forum!

Personalmente non sono un fanatico del simulatore.
In caso di problemi preferisco fare il debug.
Quello che vedo e' certamente vero...mentre il simulatore potrebbe non "simulare" quello che vorrei vedere o fare.

ora con le memorie flash e' facile scrivere nuovi programmi e riprovare il tutto con pochi click.
In passato con le memorie EPROM ad Ultravioletti tra una programma ed un altro passava un po' di tempo!
Simulatori ed emulatori erano piu' importanti.

Saluti,

Mauro