Newsgroup: it.hobby.elettronica.digitale
Titolo: codice mal eseguito?

Salve ragazzi,
         chiedo un parere prima di passare all'ultima mossa: dare per difettosi due
12f675 e acquistarne di nuovi.
E' un paio di settimane che lavoro ad un programmino che deve semplicemente
monitorare la larghezza di un impulso (ogni tot ms) e la pressione di un
tasto per programmare dei modi di funzionamento; poi gestisce un uscita a
seconda dell'impulso e del modo di funzionamento.
Sono partito molto convinto con interrupts di int per l'impulso e variaz di
stato sul pin del tasto.
Ma cominciano i problemi: quando esce dall'interrupt noto un ritardo
mostruoso prima che riparta il codice principale, poco meno di un secondo.
So dove viene perso il tempo perche inserisco istruzioni per accendere e
spegnere un led nei punti critici da verificare.
Escludo errori banali di qualsiasi genere perchè ho diversi progetti in
attivo con pic sfruttati al massimo!
Vabbeh...strano dico, proviamo a usare tmr0 int anzichè la variazione di
stato... risultato: non cambia nulla!
Un pochino alterato mi dedico alla modifica del prog per non usare proprio
gli interrupt; e qui il culmine dell'assurdità!!
Il mio codice si blocca nelle seguenti righe di codice:
                 movlw 240
                 movwf tmr0 (il prescaler è a 256)
loop movf tmr0
                 btfss status,z
                 goto loop
a questo punto mi rifiuto di provare con il testare il bit t0if invece che z
perche oramai stiamo degenerando...
ma sono vittima di qualche scherzo??? 1+1 non fa più 2 ??
Scusate se ho scritto un mucchio di righe senza alla fine spiegare bene, ma
accettate il mio sfogo...
Alla fine vorrei solo sapere se qualcuno si è trovato in situazioni anomale
analoghe a questa in cui il codice di esecuzione non lavori
appropriatamente. L'idea che mi sono fatto è che gli integrati in mio
possesso o non siano nuovi, o siano difettosi... oppure appartengano a stock
di 2° scelta. Potrebbe essere l'oscillatore (uso quello interno) che con
certe istruzioni si blocca?! Mi par strano. E il tmr0 poi? nasconde qualche
segreto nel 12f675 ? Mah! Qualche naso fino capta qualcosa?
Grazie
Bruno76
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 di 2° scelta.
mah... se alla fine dimostri che č cosě, faccelo sapere. E' estremamente 
improbabile.
1) hai simulato il codice ?
2) se temi che l'oscillatore interno non vada, metti fuori il clock, ma 
direi che anche questa č improbabile.
3) non programmo piů in assembler da qualche anno. Hai provato a compilare 
lo stesso (semplice) algoritmo in C ?
4) infine, ultimo banale consiglio, per effettuare il debug, devi pensare 
che il firmware come una cosa non scritta da te ma, che so, che ti sia stato 
passato da uno studente in panne. Verifica tutto da capo, watchdog, 
alimentazione, ecc. ecc. Togli un pezzo alla volta fino a che non hai un 
blocco di partenza semplice e funzionante e poi ricomincia ad inserire.
-- 
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)
zsimone...@zliberoz.it
 (Rimuovere i caratteri di zorro per rispondere 
via mail)

 ha scritto nel messaggio
news:81Z174Z24Z45Y1...@usenet.libero.it...

..specifica che il contenuto di tmr0 debba andare nel registro w con:
loop  movf  tmr0,w
..se così non funza non saprei dirti..ah si ricordati di disabilitare gli
interrupt se usi in questo modo tmr0...


--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 blocco di partenza semplice e funzionante e poi ricomincia ad inserire.
io ci riprovo ma giurerei di aver già fatto tutte le verifiche del caso.


 ha scritto nel messaggio 
news:81Z174Z24Z45Y1...@usenet.libero.it...

Prova a mettere
                 movlw 240
                 movwf tmr0 (il prescaler è a 256)
 loop:
                 movf tmr0,F
                 btfss status,z
                 goto loop
Per essere sicuro che venga riportato anche il bit Z.
Ciao,Roberto

"Roberto P." <roberto...@LEVAMIrobertopedrazzoli.it> ha scritto nel
messaggio news:edehkn$9kd$1...@area.cu.mi.it...

...al max è   movf  tmr0,W   se scrivi F non fai altro che un travaso di
tmr0 in se stesso, lo devi spostare in W se poi t'interessa fare il polling
sullo status register..

 ha scritto nel messaggio 
news:faBKg.4670$6Z1....@tornado.fastwebnet.it...

Non serve a niente il contenuto di tmr0 in W.
Il senso dell'istruzione movf tmr0,F è proprio qulello di settare in modo 
proprio il flag Z.
Dal datasheet:
"The contents of register f are
moved to a destination dependant
upon the status of d. If d = 0, destination
is W register. If d = 1, the
destination is file register f itself. d
= 1 is useful to test a file register
since status flag Z is affected."
Ciao, Roberto 

"Roberto P." <roberto...@LEVAMIrobertopedrazzoli.it> ha scritto nel
messaggio news:edevj8$s4c$1...@area.cu.mi.it...

..ragionissimo..mi sfuggiva..!!scusate..

vogliate scusarmi...
per il TMR0 ho risolto! Avevo detto di aver provato a usare MOVF TMR0,W
invece che MOVF TMR0,F ;ma nella confusione e ormai scocciato
probabilmente ho dimenticato di riassemblare prima di scrivere il pic...
che vergogna...
Comunque: la conclusione tratta è che per aggiornare i valori di stato
del registro TMR0 è sicuramente DIVERSO usare d=W o d=F!!
Bisogna usare MOVF TMR0,W
Che l'istruzione lavori diversamente si spiega forse nel fatto che sia un
special function reg .
Il sospetto viene chiaramente da un grafico temporale della DS33023...
Ciao
Bruno
