ecologix1971
| Inviato il: 24/01/2015 18:34:12
|
Parlo del debugger, nel pic non ci ho ancora provato....anche perche' prima di trasferire un Codice nel pic mi assicuro che nel debugger funga alla perfezione...sbaglio? |
|
| |
ecologix1971
| Inviato il: 24/01/2015 19:33:34
|
...continua....
Il problema risiede nel debugger.
Ho trasferito i codici all'interno del pic, uno alla volta e non C'e' nessun problema...
Certo pero' nel fare un Codice, le variabili che poi non assumono i valori assegnatovi creano qualche problemino.... |
| | |
NonSoloBolleDiAcqua
| Inviato il: 24/01/2015 19:58:14
|
CITAZIONE (ecologix1971, 24/01/2015 19:33:34 ) 
Parlo del debugger, nel pic non ci ho ancora provato....anche perche' prima di trasferire un Codice nel pic mi assicuro che nel debugger funga alla perfezione...sbaglio?
Allora il problema è meno grave...non sbagli ma non avevo capito.
Il debugger è un altro SW che simula il PPTEA...trovare il bug all'interno del debugger è decisamente più facile...solo che andavo cercando il problema nel compilatore e nel firmware...infatti diverse cose non mi quadravano! Ora è tutto chiaro...quello è l'importante!
---------------
Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux).
Un risultato se non è ripetibile non esiste (by qqcreafis).
|
| | |
ecologix1971
| Inviato il: 24/01/2015 22:32:46
|
Bene...bene..... |
| | |
ecologix1971
| Inviato il: 11/02/2015 03:44:07
|
Ciao a tutti.
Avrei un paio di quesiti:
1) come mai quando carico all'interno del pic dei codici di 2000/3000/4000 token, durante il caricamento mi da dei messaggi di errore e la barra di avanzamento diventa rossa. facendo piu' tentativi senza cambiare niente (premo nuovamente"go") alla fine riesco ad inserirlo correttamente.
2) utilizzando il setdate, nel debug e' normale che non viene aggiornato l'orario. Esempio se uso setdate e poi gli chiedo l'ora, mi da ancora la precedente.
Ciao ecologix1971 |
| | |
NonSoloBolleDiAcqua
| Inviato il: 11/02/2015 09:38:52
|
CITAZIONE (ecologix1971, 11/02/2015 09:38:52 )
1) come mai quando carico all'interno del pic dei codici di 2000/3000/4000 token, durante il caricamento mi da dei messaggi di errore e la barra di avanzamento diventa rossa. facendo piu' tentativi senza cambiare niente (premo nuovamente"go") alla fine riesco ad inserirlo correttamente.
Potrebbe dipendere dalla eeprom...forse è lenta...c'è modo per rallentare l'invio dei dati...non ricordo se è a disposizione dell'utente...vediamo questa cosa in modo da chiudere le cose in appeso con la nuova versione!
CITAZIONE (ecologix1971, 11/02/2015 03:44:07 )
2) utilizzando il setdate, nel debug e' normale che non viene aggiornato l'orario. Esempio se uso setdate e poi gli chiedo l'ora, mi da ancora la precedente.
Quando si è in debug del compilatore il setdate torna l'ora del pc...puoi modificare tu l'ora...non mi sembra corretto, ma può essere fatto, modificare l'ora del pc per una simulazione...
---------------
Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux).
Un risultato se non è ripetibile non esiste (by qqcreafis).
|
| | |
MarKoZaKKa
| Inviato il: 11/02/2015 11:13:56
|
CITAZIONE (ecologix1971, 11/02/2015 09:38:52 )
1) come mai quando carico all'interno del pic...... barra di avanzamento diventa rossa......alla fine riesco ad inserirlo correttamente.
Per quello che ho potuto vedere io, il compiler durante il trasferimento è molto premaloso e non gradisce che il pc faccia altre cose, tipo screensaver o usare altri sw... poi magari c'è dell'altro... NEH?!? 
---------------
Tecnico qualificato in clownerie
Windsurfer a tempo perso
Slalomaro senza speranze
|
| | |
ecologix1971
| Inviato il: 11/02/2015 13:42:37
|
A dire il vero non ho ben capito che cosa sia che gli fa dare l'errore.
Al pc che non faccia altre cose ci sto' attento ed avviene sempre con codice abbastanza lunghi |
| | |
NonSoloBolleDiAcqua
| Inviato il: 12/02/2015 08:23:30
|
La scrittura del codice eabasic nella eeprom avviene in questo modo :
il pc invia la posizione ed il valore da scrivere, il PPTEA prende il valore e lo va a scrivere nella eeprom, il PPTEA aspetta la risposta della EEPROM e se risponde in modo positivo rigira la risposta al PC.
I test che ho effettuato sono sempre andati a buon fine...ora l'anello debole della catena è il tempo di risposta della eeprom...ognuno ha un suo tempo...più la memoria è grande e più impiega tempo...come delresto la lettura ...più le eeprom sono grandi e più impiegano...ma dipende anche dal costo e dal tipo che usiamo.Il sw , per non esagerare nella fase di caricamento, ha un tempo limite...se perde il sincronismo lo segnala con un rosso ma va comunque avanti...quindi ripetendo l'operazione più volte scrive tutto il codice...anche perchè l'errore di sincronismo avverrà in posizioni sempre diverse.
Per risolvere il problema basta aumentare il tempo di attesa da parte del pc (quindi compilatore)...volevo mettere un flag o uno slide per aumentare l'attesa.
Dopo tutto questo parlare la domanda è : che tipo di eeprom usi? Mi serve l'intero chipset.
---------------
Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux).
Un risultato se non è ripetibile non esiste (by qqcreafis).
|
| | |
ecologix1971
| Inviato il: 14/02/2015 20:48:13
|
Allora, oggi ho provato a trasferire un codice di 3570 token circa ed alla fine stavo perdendo le speranze.
Inizialmente stavo usando una :
ATMEL 138 24C32A PU27 D
Il compilatore mi dava 91% di occupato, ma trasferendo il codice nella eeprom arrivato a qualche secondo dalla fine la barra diventava rossa dando errore (proprio sugli ultimi token)
Ho pensato di stare al limite della memoria e sono passato ad un'altra memoria:
ATMEL 129 24C64A PU27 D
Ma il risultato era lo stesso. Questa non vorrei sbagliarmi mi segnalava il 47% di spazio occupato.
Poi ho provato un'altra memoria ancora:
ATMEL 128 24C256 PU27 D
E anche con questa stessa cosa. Poi provando e riprovando, chiudendo il compilatore, ricaricando il codice, per magia sono riuscito ad inserirlo regolarmente, ma non riesco a capire dov'e' che sbaglio.
Faccio le stesse identiche cose, ma devo fare sempre piu' tentativi prima di riuscirci.
Quello che ho notato, visto che sto' lavorando su di un codice che man mano sta' crescendo, e' che inizialmente, finche' era piu' corto, lo trasferivo al primo colpo ora sta' diventando un'impresa. |
| | |
NonSoloBolleDiAcqua
| Inviato il: 15/02/2015 16:29:22
|
Tranquillo, faccio qualche verifica sui tempi delle memorie e faccio uscire una versione ad hoc!
---------------
Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux).
Un risultato se non è ripetibile non esiste (by qqcreafis).
|
| | |
ecologix1971
| Inviato il: 15/02/2015 19:22:45
|
Ok,stiamo nelle tue mani |
| | |
NonSoloBolleDiAcqua
| Inviato il: 16/02/2015 15:30:12
|
Questa cosa mi preoccupa...
Dai dai ...ripartiamo e risolviamo tutte le questioni appese...iniziamo con la modifica della velocità di trasmissione...vediamo se riusciamo a risolverla.
In questa versione beta c'è la possibilità di aumentare il tempo di attesa...se viene lasciata senza modificarla parte con la solita tempistica...eco tu dovresti metterla circa a metà...se non funge nemmeno a metà portala tutta a destra...il tempo di trasmissione aumenta notevolmente.
PS: Sicuramente questa versione risolve il problema del RESTORE :LABEL nel debugger!!!
Modificato da NonSoloBolleDiAcqua - 16/02/2015, 16:41:48
---------------
Chi sa raccontare bene le bugie ha la verità in pugno (by PinoTux).
Un risultato se non è ripetibile non esiste (by qqcreafis).
|
| | |
ecologix1971
| Inviato il: 17/02/2015 12:02:16
|
Grande bolle, ora sono fuori casa, ma stasera la metto subito all'opera.
...per il restore avevo aggirato il problema, visto che ormai tornare ai numeri di linea mi sembrava troppo retro'.
Meno male che hai forgiato quest'altra versione, perche' il codice che sto' facendo sul timer si fa sempre piu' lungo e quell'errore alla fine dopo aver aspettato tutto il tempo per caricare il codice stava diventando snervante!!!
...non vedo l'ora di testarla..
Thanks |
|
| | |
|
Versione Mobile!
 
|
|
|
|
|
|
|
|
|
|
|
|
|
