Newsgroup: it.hobby.elettronica.digitale
Titolo: call

Ma è possibile che un programma si comporti cosi??!
Sto impazzendo per far rifunzionare un programma che prima andava benissimo.
L'unico cambiamento importante è che per i ritardi ho introdotto delle macro
e il programma è diventato quindi più pesante... ma ciò cosa centra?
Assemblandolo è tutto corretto!
Il problema, secondo i miei poco rispettabili test di debug, sta nelle call!
In particolare nelle tabelle. Es:
get_newpos      addwf      pcl,f
                        retlw        0
                        retlw        7
                        retlw        3
                        ......
......
                         clrf          posizione
label_prima        movf       posizione,w
                         call         get_newpos
label_dopo        movwf    posizione
......
succede che se parto con posizione=0 in label_prima  in label_dopo a
posizione non viene assegnato 0.  Ma è possibile mai.
Se sposto get_newpos in altre locazioni funziona!
Il problema è che di tabelle ne ho molte! Vai a farle funzionare tutte!
Capisco che queste mie spiegazioni siano vaghe per localizzare il problema
ma devo pur sfogarmi...
Bruno

 Ma è possibile che un programma si comporti cosi??!
Certo... PIC=crazy architecture... perche' fare le cose in modo semplice (un
bel program counter lineare) quando ci si puo' complicare la vita con il
PCLATH;)
http://members.xoom.it/stor/pic/page1/pic16f84_1.htm
(sezione note per la programmazione->tabelle dati)
ciao
Claudio F

 ma devo pur sfogarmi...
Hai messo la tabella nei primi 256 byte? E' li che deve stare...
ciao
S

Grazie di avermi spiegato il beffardo funzionamento delle tabelle  : )
Il particolare del PCLATH mi è sempre sfuggito!
Ora so dove probabilmente sbatto la testa...
E via in obitorio.. ehem.. Hobby-torio !  : )
Ciao
                                                Bruno

 Ma è possibile che un programma si comporti cosi??!
guarda, è successo anche a me e mi sono preso la tua stessa arrabbiatura.
alla fine ho scoperto che (per la tabella) NON devi mettere label e
istruzione nella stessa riga.
non so quale arcano mistero si celi dietro tale motivazione, ma di sicuro
c'è qualche mente malata alla Microchip...
quindi:
...
get_newpos [vai a capo]
           addwf  PCL,F
...
e tutto funzionerà.
ciao ciao
Gabriele


 PCLATH;)
Forse perche` il program counter ha una dimensione piu` grande del bus
dati? :-)
Per lo stesso motivo l'Intel ci ha rotto le palle per anni (anzi,
decenni!) con segmenti e offset.
--
Lorenzo

 ha scritto nel
messaggio news:1RS7a.166348$ZE.49...@twister2.libero.it...


E il gate A20 per la ram sopra il MegaByte, lo ricordate?
(Ok forse sono 3 ordini di grandezza sopra i PIC,
e quindi Off Topic)
E il VicII (chip grafico) nel commodore 64?
Era collegato a 16K di Ram mentre la CPU era collegata a 64K,
e si poteva collegare a piacere in uno dei quattro posti possibili.
C'era pure la possibilità di collegare la rom-basic in lettura
alla cpu (così poteva accedere all'interprete basic).
Nelle stesse locazioni, in scrittura la cpu scriveva
sulla ram, mentre la scheda video leggeva dalla ram
'nascosta sotto la rom-basic dal punto di vista della cpu'
l'immagine da mandare a schermo:
la cpu metteva un dato in ram, e ne rileggeva un altro
dalla rom nella stessa locazione.
That's crazy architetture!
Chi ha esempi ancora più "Crazy"?
--
Gli americani hanno bisogno del telefono, ma noi no.
Noi abbiamo postini in abbondanza.
Sir William Preece, ingegnere capo delle Poste Britanniche, 1876
"Lorenzo Lutti" <lorenz...@DOHtiscalinet.it> ha scritto nel messaggio
news:A178a.168429$ZE.50...@twister2.libero.it...


 ha scritto nel messaggio
news:ukw7a.162191$YG2.4...@twister1.libero.it...
