Ancora problemi con pic

Brunix ha scritto:

Uso da qualche tempo un Propic 2 clone abbastanza simile al tuo senza nessun problema di sorta. Ho programmato correttamente 16F84A, 16F876A e 16F877A parecchie volte.

Puoi invece farci vedere una foto del circuito? Uno schema? A volte, ci sono delle cose talmente ovvie che non si vedono...

Hai messo dei condensatori al poliestere tra alimentazione e massa del PIC? Con cosa lo alimenti? I 5V sono proprio 5V? Sono puliti o c'=E8 del rumore di commutazione? I collegamenti del quarzo o dell'oscillatore RC sono abbastanza corti?

Reply to
Darwin
Loading thread data ...

Ciao, lo schema è in questa pagina:

formatting link
quello senza l'interruttore per utilizzare anche EpicWin. L'ho montato sulla breadboard... mi pare che sia tutto a posto. L'unico problema è quello dei led. Il led rosso (Vpp) rimane sempre acceso. Seguendo la procedura di test, invece, dovrebbe accendersi solo quando spunto la voce nell'hardware-check in IcProg. Il led giallo invece si comporta come descritto le procedura di test.

Il condensatore sull'alimentazione non c'è ma uso degli alimentatori stabilizzati per alimentare il circuito. I 5 V sono circa quelli. Ho regolato l'alimentatore su 5.1, 5.2 V... Il quarzo e i condensatori sono collegati vicino al pic, sulla breadboard. Ciao Brunix

Reply to
Brunix

Ok, grazie per questo.

1.05D

Uso Win98 (ho un pc che uso solo per fare queste cose)

E' questo il problema, quando spunto ATTIVA MCLR, non succede niente, perchè il led era acceso e rimane acceso! Il led di Vcc invece no, quello funziona come descritto da te, e cioè come anche la procedura di test del programmatore stesso.

Si! In effetti mi da errore dopo che programma... in fase di verifica. Mi dice "Verify Failed Address 0000h!", ma avevo letto che non era importante questo errore, di non farci caso... mah...

Ok.

Il problema era solamente che il thread sta diventando troppo "vecchio"... Comunque ok... si continua qui! ciao Brunix

Reply to
Brunix

Il giorno Tue, 27 Jun 2006 21:32:24 GMT, Brunix ha scritto:

E' l'ultima.

Allora non devi abilitare il driver NT/2000/XP.

Non va bene, in condizioni di riposo MCLR deve essere spento. Hai controllato che la casella "Inverti MCLR" sia spuntata?

Altro che se non è importante!!! Ti dice che la programmazione è fallita sulla prima locazione della memoria flash.

Reply to
Luigi C.

Il giorno Tue, 27 Jun 2006 21:23:06 GMT, Brunix ha scritto:

L'alimentazione stabilizzata non c'entra, i condensatori da 0.1 uF tra alimentazione e massa servono da bypass per i disturbi dovuti alle commutazioni veloci.

Reply to
Luigi C.

"Brunix" ha scritto nel messaggio news: snipped-for-privacy@4ax.com...

Ok, abbiamo trovato il problema... Nello schema ci sono due segnali di controllo per MCLR, ovvero due pin della parallela. Prova a staccare quello che hai usato ed a attaccare l'altro, dovrebbe essere la soluzione!

Come ti hanno gia' detto, ti avverte che non hai programmato il micro... e non potrebbe essere altrimenti perche' non mandi la tensione di programmazione sul pin MCLR che deve essere, in fase di programmazione, a livello superiore a 12,5 o 13 Volt (con beneficio di inventario per la tensione precisa, vado a memoria). Comunque, un'altra prova che puoi fare, dopo la programmazione, e' eseguire il verify che, se ti da' errore, ti conferma che il micro non e' programmato nella giusta maniera. ciao Angelo

Reply to
angelo

Brunix ha scritto:

Come detto da altri, il messaggio dice, in sostanza, che il PIC non viene programmato. Prova a controllare che tutti i collegamenti del programmatore siano a posto. Guarda questa pagina:

formatting link

Dovrebbe poterti aiutare.

Reply to
Darwin

Speriamo che sia proprio questo il problema. Visto che il segnale di controllo per Vpp arriva da due buffer provo a staccarne uno, poi l'altro finchè non avrò il comportamento corretto.

Da quello che so io :-) 13.2 V

Ok. Mi pareva infatti strano che questo errore fosse da non considerare. Speriamo bene. :-) ciao Brunix

Reply to
Brunix

Si, ho già seguito questo test. L'unica cosa che non funzionava come descritto era il led Vpp. Proverò a ricontrollare e vi farò sapere. ciao Brunix

Reply to
Brunix

Mi pare che abbia già messo un condensatore tra il positivo e il negativo direttamente sulle uscite degli alimentatori che ho, ma comunque è sempre meglio averne uno più vicino possibile al pic, giusto? Ok. Una volta messo a posto il programmatore provvederò... (Magari fosse questo: ce ne metterei 10 di condensatori se si risolve il problema :-D) Grazie Ciao Brunix

Reply to
Brunix

Ciao a tutti, sono appena tornato dal "laboratorio"... Dunque, il programmatore aveva un problema hardware, il led Vpp era sempre acceso perchè era bruciato il transistor che lo comandava. Sostituito questo, ha funzionato come descritto dal test. Ho quindi programmato il mio pic16f84A escludendo il WDT (mettendo a volte il PWRT). L'errore della verifica c'è sempre (Verify Failed Address 0000h). Il programma funziona, ma non riesco a capire perchè va in loop, cioè il pic ripete all'infinito il programma. Non so se sia il comportamento corretto... Vi chiedo ancora aiuto, stiamo facendo passi avanti!!! ciao Brunix

Reply to
Brunix

Brunix ha scritto:

Bene, una cosa =E8 risolta.

Questo =E8 meno normale.

Hai fatto fermare il tutto con un loop infinito? Se il programma =E8 questo:

#include #include main(void) { TRISB =3D 0; PORTB =3D 0x01; DelayMs(250); DelayMs(250); DelayMs(250); DelayMs(250); PORTB =3D 0x02; }

alla fine del main, il microcontrollore passa ad eseguire l'istruzione seguente. Non essendoci nient'altro, il codice eseguito puo' essere qualcosa di strano che puo' mandare in reset il sistema. Ecco perch=E9 il programma viene eseguito all'infinito.

Se vuoi bloccare l'esecuzione, puoi aggiungere qualcosa del tipo: while (1); alla fine del main.

Sui condensatori, come detto sopra, servono per evitare che picchi di assorbimento del PIC disturbino l'alimentazione. Tuttavia, il PIC consuma pochissimo ed il circuito che fai =E8 molto semplice. Non credo che i problemi vengano da li'. Mettili quando monti il circuito definitivo.

Reply to
Darwin

Questo è valido anche se il pic è stato programmato più volte con lo stesso programma?

Ok. Provo e vi faccio sapere. Comunque ho già provato a mettere un return alla fine, ma il risultato non è cambiato.

Ok. Ciao Brunix

Reply to
Brunix

Brunix ha scritto:

Beh, normale: con return poni fine ad una funzione e ritorni a quella che l'ha chiamata. Nel caso del main, ritorni al sistema operativo (puoi anche passare un codice d'errore, non per niente il main standard C ritorna un intero). Nel PIC non v'=E8 sistema operativo... per sapere cosa succede bisognerebbe sapere come viene implementata l'istruzione return. Se, com'=E8 probabile avviene con l'istruzione assembler corrispondente, si crea uno stack overflow e si impalla tutto. Hai provato a cercare un simulatore?

Reply to
Darwin

No, ma effettivamente quello che dici è giusto. Il problema è che non vi avevo pensato: ho sempre programmato in C per il PC, sono un perito informatico... Proverò con il while(1); alla fine e vi farò sapere. Intanto Grazie per l'aiuto. Ciao Brunix

Reply to
Brunix

HA FUNZIONATO!!! Evvai... finalmente sono riuscito a risolvere i problemi del pic. Adesso ce n'è solo un altro... Devo convertire un numero binario in BCD... Come posso fare? Grazie Ciao Brunix

Reply to
Brunix

Brunix ha scritto:

Bene, felice per te.

Vuoi scrivere su un display un numero x contenuto in 8 bit? Un metodo semplice prevede di sottrarre 100 fino a quando il risultato resta positivo e contando il numero di volte in cui questo avviene. Con il resto (che =E8 compreso tra 0 e 99) fai lo stesso con le decine. Alla fine, restano le unit=E0. Un metodo pi=F9 complicato consiste nel fare una divisione con il resto (che =E8 quello che facciamo sopra in maniera semplice). E' comodo nei microcontrollori che hanno una istruzione che lo fa.

Reply to
Darwin

Quindi il problema non era la programmazione, ma il ciclo while (1) nel main che non avevi implementato? L'errore dato da Ic Prog era quindi un errore di Ic Prog e qundi irrilevante? ciao Angelo

Reply to
angelo

No il problema era che il programma alla fine, dopo aver corretto il problema del programmatore, funzionava ma il pic ripeteva all'infinito il programma che aveva all'interno. Mettendo il while(1) il programma si blocca. Funziona insomma.

Penso proprio di si a questo punto. In un sito dove si parla di questo programmatore ho letto che per ovviare a questo errore si può provare a cambiare il delay. Non so.

Ciao Brunix

Reply to
Brunix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.