Newsgroup: it.hobby.elettronica.digitale
Titolo: [Help PIC] File register problemi nel riservare

Salve a tutti,
sto sviluppando un programma per un PIC18F4320, ed ho riscontrato un
problema, riservando dei registri per delle variabili vado a sovrappormi ad
altri registri del PIC, come per esempio al _BKBUG_ON_4L (0x7F), cosě perdo
delle informazioni, infatti su questo registro mi cadeva un contatore, con
conseguente perdita del conteggio.
Ho iniziato a riservare a: ORG 40H, perchč osservando la finestra del file
register era il primo punto libero, ma dopo 96 variabili (ho anche degli
array da 35bytes) vado ad intaccare i registri del Micro.
Cosa mi consigliate?
I registri riservati che si vanno a sovrapporre come si comportano? saltano
un registro dopo o spariscono?
Devo cercarmi pezzi di memoria liberi osservando la finestra "File register"
dell'MPlab IDE?
Aiutatemi a riorganizzarmi!!!!
Grazie
Ronnie

 Devo cercarmi pezzi di memoria liberi osservando la finestra "File
register" dell'MPlab IDE?
Direi che devi farlo leggendo il datasheet del pic in questione.
Io uso i pic8 da poco e l'unica cosa che posso dirti č: sei sicuro di
impostare l'access bank nel modo corretto?
Ciao
Lucio

...


 >Io uso i pic8 da poco e l'unica cosa che posso dirti è: sei sicuro di


 ha scritto nel messaggio
news:I_Sac.3041$l27....@news.edisontel.com...


 ha scritto nel messaggio
news:WdTac.3047$l27....@news.edisontel.com...


 Org serve per la Program Memory, e non per la ram.
Beh, ORG e' usata anche per l'assegnazione di indirizzi ram quando viene
seguita dalle direttive RES... e' solo un modo comodo per evitare una lunga
scrittura di EQU... in pratica invece di scrivere PIPPO EQU 32  PLUTO EQU 33
ecc si mette una ORG 32 seguita da PIPPO RES 1  PLUTO RES 1 ecc.
Successivamente si mette anche la ORG per il programma vero e proprio.
Claudio F

 "File register" dell'MPlab IDE?
Ho buttato un occhio (prontamente ripreso) alla ram del 4320... secondo il
d.sheet (pag.60) tutti gli indirizzi da 0 a 511 (0x000..0x1FF) sono di
libero utilizzo (2 banchi da 256). Da 512 a 3967 (0x200..0xF7F) non sono
usabili. Da 3968 a 4095 (0xF80..0xFFF) ci sono i registri speciali per il
controllo dell'hardware (SFR registers). Non ho capito cosa si e'
sovrapposto a cosa...
Claudio F

 ha scritto nel messaggio
news:__Xac.5125$rM4....@news4.tin.it...


 ha scritto nel messaggio
news:__Xac.5125$rM4....@news4.tin.it...


 ha scritto nel messaggio
news:SiYac.5234$rM4.1...@news4.tin.it...


Ho iniziato a riservare a: ORG 40H, perchè osservando la finestra del file


Io è da tantissimo che ho smesso di utilizzare la direttiva res
...ti consiglio di fare altrettanto!
:)

...


Ronnie
con equ e la locazione
non so se ora mplab è cambiato ma prima utilizzando res nella finestra
di watch potevo visualizzare solo il valore della locazione e non il
registro con il nome dato da me, cosa che non accadeva riservando la
variabile con equ
sicuramente effettuare il debug visualizzando il nome delle variabili
è piu' agevole
Non so se le cose siano cambiate in mplab visto che da allora ho preso
questa abitudine
Comunque usando equ non rischio neanche di sconfinare in locazioni non
permesse

 locazioni non permesse
mmm, non so, secondo me la RES serve proprio per avere piu' ordine e non
rischiare di sovrapporre registri o lasciare buchi inutilizzati in caso di
modifiche... permette anche di cambiare in blocco tutti gli indirizzi
semplicemente cambiando la ORG iniziale (utile se si vuole spostare un
programma su un micro diverso). Usando solo le EQU si dovrebbero modificare
ogni volta a mano tutti gli indirizzi e oltre a rischiare di fare errori non
sarebbe immediatamente evidente quanti bytes sono effettivamente usati...
con la RES invece basta sommare tutte le lunghezze dichiarate.
...certo quello del watch e' un bel bug.....
Claudio F

 ha scritto nel messaggio
news:x5tcc.19299$hc5.9...@news3.tin.it...


modifiche...
Beh...
sotto questo punto di vista devo dire che hai ragione
...ogni volta che faccio una modifica... impazzisco un po'
Quello che intendevo č che ai primi programmi, qualche volta mi č
capitato, facendo un res 10 per un buffer, di finire sui registri del
PIC 
:-)
Qualche riga su come utilizzo gli equ, in maniera tale che ognuno
possa fare le proprie considerazioni e decidere quale direttiva
preferisce utilizzare:
Anche se  comporta un riscrivere ogni volta tutti gli equ, ho imparato
ad organizzarmi i dati in maniera il piů coerente possibile: per le
routines che eseguono certe funzioni tutte le variabili su bank0, per
quelle di altre funzioni su bank1 etc.
In questo modo non devo andare a controllare nelle mie routines su che
banco ho messo la variabile prima di utilizzarla oppure... come ho
visto spesso fare, riempire il programma di banksel
Poi tutte le variabili le organizzio in blocchi...
e qui sarebbero comodi i res se mplab non avesse il bug:
le variabili di una suroutine le metto tutte assieme e.. se ne devo
aggiungere una, per non mischiarle e non capire piu' nulla...
purtroppo devo shiftare tutti gli equ.
Questo č un punto debole degli equ ma..per il debugging, non poter
visualizzare i nomi delle variabili, č veramente scoooomodo! :-)
Fatte queste considerazioni... ad ognuno la propria scelta.
Se a qualcuno puo' interessare qualche altra considerazione:
E' da un po' di tempo che utilizzo una mia tecnica di debugging che
trovo molto comoda: debugging attraverso porta seriale.
Mi spiego
Per testare molte routines che non utilizzano la porta seriale
introduco dei bytes di test che invio sulla seriale in vari punti del
programma e monitorizzo attraverso terminale di windows.
Cosě facendo ho una visione immediata del flusso di programma (una
sorta di trace rudimentale sul circuito funzionante).
In questo modo sono riuscito a scovare errori altrimenti impossibili
da determinare.
Un esempio:
come avreste fatto a determinare un salto nel programma causato da un
contattore che aziona un motore trifase?
Solo analizzando il flusso del programma e vedendo che il motore
all'azionamento causava un salto imprevedibile da una riga di
programma ad un'altra completamente casuale sono arrivato alla
soluzione di ridisegnare il pcb ed aggiungere ulteriori filtri sulle
linee di alimentazione e di uscita del circuito.
Spesso, al posto di visualizzare le variabili sul simulatore, le
visualizzo direttamente sul terminale di windows.
Faccio una semplice routine che mi scompone il bite di interesse in
una sequenza di '1' e '0' e invio il tutto su seriale.
Da considerare ovviamente che tutto cio' altera la tempistica di
esecuzione del programma e che quindi questa tecnica va utilizzata con
criterio.

 PIC
Anch'io uso gli EQU, ma e' per una  mia deformazione mentale
assunta quando ho iniziato a lavorare con i pic. L'assembler che
c'era allora non permetteva altre soluzioni.
Adesso che sto rispolverando i pic mi dovro' aggiornare.
A proposito, nessuno usa le direttive UDATA, UDATA_SHR, ecc.?
Dovrebbero permettere di scrivere delle subroutine rilocabili
indipendenti dagli indirizzi fisici, e percio' utilizzabili con pic diversi.
Sembra anche molto interessante la possibilita' di dichiarare
variabili temporanee il cui indirizzo viene riutilizzato piu' volte.

variabili temporanee il cui indirizzo viene riutilizzato piu' volte.
mah
anche questo io lo faccio 'manualmente'
mi capita di dichiarare con gli equ l'associazione di due variabili ad
una stessa locazione
ad esempio
contatore10	equ 0x21
contatore20	equ 0x21
se so che ad esempio utilizzo le due variabili come contatori di cicli
in due suroutines distinte....
così facendo utilizzo nomi che permettono di migliorare la leggibiltà
del programma.
Non ho guardato l'uso delle direttive di cui parlavi ma...
non sto facendo quello che dici tu?
cioe' riutilizzare delle variabili temporanee?
Dopotutto le direttive non fanno altro che tradurre automaticamente la
riga in una o piu' righe assembler
Non aggiungono assolutamente funzionalità al PIC.

 Non aggiungono assolutamente funzionalità al PIC.
Nemmeno l'assembler aggiunge niente ad un pic, ma se permetti
e' un po' piu' comodo di programmare direttamente con  codici
binari delle istruzioni!

 stack in cui allocare parametri e variabili temporanee,
Infatti e' scomodo dover dichiarare sempre nuovi nomi di registro per ogni
sciocchezza... ultimamente preferisco definire un gruppetto di registri AL
BL CL ecc (magari se serve anche una controparte high AH BH CH ecc) e usarli
come i buoni vecchi registri generali di una cpu convenzionale... e lo stack
si simula con un paio di macro:
1) Definire un'indirizzo di partenza per un'area di stack, con equ o res e'
indifferente
BSTACK      EQU         xxxxx
2) Definire le due macro PUSH e POP:
PUSH        MACRO       ARG1
            MOVF        ARG1,W
            MOVWF       INDF
            INCF        FSR,F
            ENDM
POP         MACRO       ARG1
            DECF        FSR,F
            MOVF        INDF,W
            MOVWF       ARG1
            ENDM
3) All'inizio del programma assegnare l'indirizzo dello stack a FSR
            MOVLW       BSTACK
            MOVWF       FSR
4) Usare PUSH e POP nel modo consueto
            PUSH        PIPPO
            POP         PLUTO
....e sembra di rinascere;)
Per i 18F non ho ancora approfondito, ma il fatto che abbiano 3 registri FSR
con indirizzamento lineare non bankizzato su tutta la ram (e post
incremento/decremento automatici) rende l'operazione ancora piu' semplice e
veloce.
Claudio F

binari delle istruzioni!
Premessa: le mie non vogliono assolutamente essere critiche sul modo
di programmare verso una persona dalla quale penso di avere solo da
imparare.
Tornando all'affermazione su fatta...
anche programmando in C non si aggiunge nulla ed č ancora piu' comdo (
molti mi diranno che il basic lo č ancora di piu')
Quello che volevo dire io č che con l'assembler  la corrispondenza tra
il linguaggio e il codice macchina per le istruzioni č 'uno a uno' e
quindi permette un'ottimizzazione perfettamente controllata del
codice.
Sicuramente programmando cosģ, i tempi di stesura del programma sono
molto piu' lunghi ma, utilizzando le direttive sempre piu' potenti del
compilatore, si rischia di sconfinare in linguaggi a piu' alto livello
che non permettono l'ottimizzazione (o per lo meno si perde di vista
cio' che si sta realmente facendo).
A questo punto mi chiedo se non sia piu' vantaggioso programmare in C,
un linguaggio a livello sempre abbastanza basso e sicuramente piu'
generico di un assembler a ampliato.
Con il C, dopotutto, ho buone possibilitą di poter  riadattare il
programma anche ad altre famiglie di microcontrollori senza (o con
pochissime) modifiche.