ElectroYou

Dopo aver provato a pilotare un motore elettrico attraverso un MOS, il pin utilizzato non risponde più bene. Devo ancora capire se il motivo sia questo circuito fatto male (probabile), o il momentaneo calo di tensione una volta attivato il motore.
Infatti sempre all'accensione del motore avevo problemi anche con il display alfanumerico pilotato in contemporanea dal PIC, poi risolto mettendo un condensatore da 100n tra Vdd e Vss (nonostante i 5V venissero comunque fuori da un 7805 con i relativi condensatori).
Non dovrebbe essere un problema software visto che al simulatore funziona.
Il PIC in questione è un 16f886.
Questo è il circuito o meglio la parte di interesse:


Vorrei quindi se possibile capire dove sbaglio dal punto di vista hardware.
Grazie in anticipo per eventuali risposte.

Non ti fidare o meglio lascia perdere il simulatore. Ti direbbe che va tutto bene anche quando il mondo intero sta andando a rotoli..

Il condensatore di bypass tra VDD e GND va sempre messo il più possibile vicino al componente per ovviare eventuali disturbi.

Per dire con maggior sicurezza se è un problema hardware dovresti anche specificare se il MOSFET è pilotato in PWM, se si a quale frequenza etc.. Immagino che anche il carico influisce sulle condizioni di funzionamento.

I 3Ω dello schema fanno riferimento alla resistenza di wiring? Se si, secondo me sono tanti.

Esattamente, qual è il problema che riscontri?

Ok allora spiego il funzionamento:
schema originale:
Questo è il circuito prima del mio intervento. La resistenza è dovuta ai cavi e al contatto, il motore di suo l'avrebbe molto inferiore.

Ora questo è invece il circuito modificato:


Scopo: capire quando l'interruttore è chiuso, in quel caso mandare alto o tenere basso il pin che va al gate (a seconda delle esigenze del programma).
Metodo: attraverso il partitore prelevo il segnale da mandare all'ingresso non invertente di un op amp. Nell' ingresso non invertente c'è un valore di circa 10mV.
Se l'interruttore è aperto, il segnale va a massa e quindi l'op amp darà in uscita 0V (V-=0V , V+=5V),
Se l'interruttore è chiuso, sia con transistor in conduzione, sia interdetto, si avrà un valore superiore di 10mV+offset sull'ingresso non invertente, una 40ina di mV con transistor in conduzione e circa 4V con transistor interdetto.
Ho già verificato i miei conti e il funzionamento portando il gate manualmente a 5V e a 0V e in entrambi i casi al PIC arriva la giusta informazione.
Il problema è che invece non riesco a controllare il gate tramite PIC, precisamente sta alto come dovrebbe stare, ma appena chiudo l'interruttore va basso (e non dovrebbe farlo).
Volevo più che altro sapere se il mio circuito ha dei problemi gravi che non ho considerato dal punto di vista circuitale.

Per capire se il problema è tra il pin di I/O e/o transistore o nel codice, basta scollegare l'operazionale e vedere se tutto funziona correttamente, ma bisogna anche tenere a mente che il motore ha una corrente di spunto che potrebbe influire sul tuo circuito ma non si sà come hai configurato l'operazionale, comunque ora è tardi..

Non hai detto quali sono le esigenze del programma e del circuito, apparentemente incompleto, anche se tu dici di aver fatto tutti i conti.

Il controllo che stai facendo mi fa pensare ad un consumo variabile del motore.. Sennò perché usare un operazionale? È solo per proteggere eventualmente il pin del microcontrollore? Hai collegato l'output dell'operazionale ad un entrata analogica?

Solitamente per le misure basate sui divisori di tensione meglio usare resistenze con tolleranza dell'1%.

Dici che il pin viene mandato a VOH o VOL in base alle esigenze del firmware, però quali sono le esigenze sia di quest'ultimo che del circuito?

Qualcosa mi dice che non stai dando informazioni a sufficienza..

gohan ha scritto:Per capire se il problema è tra il pin di I/O e/o transistore o nel codice, basta scollegare l'operazionale e vedere se tutto funziona correttamente, ma bisogna anche tenere a mente che il motore ha una corrente di spunto che potrebbe influire sul tuo circuito ma non si sà come hai configurato l'operazionale, comunque ora è tardi..

Forse vedendolo si capisce di più di quanto abbia scritto:

Scollegando l'operazionale e mandando in ingresso al pin un bottone con cui scelgo a mano 0V o 5V, il problema permane.
Il problema è che il pin RC1 (adibito a uscita digitale) dovrebbe rimanere alto, ma non appena succede un qualsiasi altro evento, ad esempio cambia lo stato di RA1, esso scende basso.
Ho provato ad alimentare la parte di potenza (motore) con alimentazione a parte da quella di segnale (PIC), cioè una con una batteria li-po da 11.1V, l'altra con alimentatorino da parete da 12V (che andrà in ingresso a un 7805). Le masse ovviamente sono in comune, il problema comunque persiste.

gohan ha scritto:Non hai detto quali sono le esigenze del programma e del circuito, apparentemente incompleto, anche se tu dici di aver fatto tutti i conti.

Il circuito controlla esternamente un fucile da soft air, andando a capire quando esso sta sparando (interruttore chiuso=grilletto premuto), in questo modo può quindi bloccarlo, o lasciarlo fare, attraverso il MOS.
Infatti quello che sto realizzando è un fucile da laser tag, ma mantenendo invariata la meccanica interna.
Quando finisco i colpi nel caricatore virtuale, si manda a 0 il gate del transistor per fermare il motore, quando non sono finiti si tiene a 5V il gate e il motore funziona (solo se si premo il grilletto ovviamente).

gohan ha scritto:Il controllo che stai facendo mi fa pensare ad un consumo variabile del motore.. Sennò perché usare un operazionale? È solo per proteggere eventualmente il pin del microcontrollore? Hai collegato l'output dell'operazionale ad un entrata analogica?

No l'uscita dell'operazionale e collegata a un'entrata digitale, che comunque non ha problemi a rilevare il tutto (come ti ho detto la parte di rilevazione funziona perfettamente).
L'operazionale lo uso quindi come comparatore che satura a uno dei due valori a seconda degli ingressi.
Inizialmente avevo provato a usare il comparatore interno, ma a causa di altri problemi avevo pensato di non riuscire a impostarlo bene e sono passato ad uno esterno. Non appena risolvo questo problema ripasso a usare il comparatore interno.

gohan ha scritto:Solitamente per le misure basate sui divisori di tensione meglio usare resistenze con tolleranza dell'1%.

Grazie ne terrò conto, comunque per ora funziona anche con quelle al 5%.

Tornando alla domanda iniziale, quello che mi interessava era capire se era una cosa "legale" pilotare il gate del MOS di potenza direttamente con il pin del micro, o così facendo lo ho bruciato, magari per effetto condensatore del gate.
Dati aggiuntivi: tenendo scollegato il pin RC1 e andando a misurare con un oscilloscopio o un multimetro continua sempre per la sua strada: alto fintanto che non succede niente, appena qualcosa cambia di stato cade basso anche se non dovrebbe farlo.

Grazie in anticipo per eventuali risposte.

Che io sappia puoi controllare il Gate del MOSFET con il pin del micro in quelle condizioni.

Quanta corrente consuma il motore?
Quale PIC stai usando? Se non ricordo male è un 16F886 o 877 vero?

Non ricordo o non ho presente al momento a quale effetto del condensatore di Gate fai riferimento. Ti riferisci alla scarica?

La prova a cui mi riferivo io era quella di lasciare RC1 acceso, senza altri eventi, né RA1 né OpAmp né niente, scrivendo un piccolo codice, un paio di righe, per avere VOH sul Gate acceso sin dal principio per tutta la durata di esecuzione, e niente più.
Cosa succede in quelle condizioni?

Se funziona è il codice.

Innanzitutto grazie per il tempo che mi stai dedicando . Il motore consuma intorno ai 3,6A a circa 11V, quindi 40W in contemporanea al led emettitore ir (tsal6100) che consuma un altro ampere a 2,5V (2,5W) ma questo non in modo continuo, bensì modulando un segnale a 40kHz.
Il resto del circuito e composto da un pic16f886 che pilota un display LCD 8x2 alfanumerico, quindi il consumo non sarà molto alto.
Mi riferivo al fatto che il Gate di un MOSFET si comporti come un condensatore, e non vorrei che una volta riabbassato il segnale questo scaricandosi all'interno del pin faccia danni (all'inizio usavo lo stesso circuito ma senza resistenza da 10k verso massa e senza diodo).

Ora ho provato con questo semplice programma, in cui azzero per sicurezza tutti i registri:

Codice: Seleziona tutto

#include <PIC.h>

__CONFIG (HS & WDTDIS & PWRTEN & MCLREN & UNPROTECT & DUNPROTECT & BORDIS & IESODIS & FCMDIS & LVPDIS & DEBUGDIS & BORV40);

#define TRANSOPP RC1

void main(void)
{
      TRISA=0;
        TRISB=0;
      TRISC=0;
      PORTA=0;
      PORTB=0;
      PORTC=0;
      CM1CON0=0;
      CM2CON0=0;
      ADCON0=0;
      ADCON1=0;
      OPTION=0b10000000;
      ANSELH=0;
      ANSEL=0;
      IOCB=0;
      WPUB=0;
      PIE1=0;
      PIE2=0;
      PIR1=0;
      T1CON=0;
      RCSTA=0;
      SSPCON=0;
      INTCON=0;
      EECON1=0;
      TMR2IF=0;
      PR2=0;
      CCP1CON=0;
      CCP2CON=0;
      CCPR1L=0;
      T2CON=0;
      PSTRCON=0;
      VRCON=0;
      SRCON=0;
      
      TRANSOPP=1;
      while(1);
}



Ora il pin sta alto e se provo a collegarlo al gate, effettivamente funziona tutto bene.
Da questo quindi penso possiamo dedurne che il pin non ha perso le sue funzionalità ed è in buono stato.

Che io sappia puoi controllare il Gate del MOSFET con il pin del micro in quelle condizioni.

In realtà era proprio solo questo che mi interessava e ti ringrazio per la risposta.
Ora provo a controllare bene tutti i registri che ho impostato per capire se il problema è software, altrimenti forse è dovuto all'ulteriore consumo del led, anche se per provare a escludere questo ho provato ad alimentare il tutto con una batteria da macchina, ma ancora senza successo.
Per completezza riporto la configurazione che ho nel mio programma:

Codice: Seleziona tutto

void settings_menu(void)
{
       
      TRISA=0b00110010;
        TRISB=0b00000001;
      TRISC=0b11111000;
      CM1CON0=0;
      CM2CON0=0;
      ADCON0=0;
      ADCON1=0;
      OPTION=0b01000000;
      ANSEL=0;
      ANSELH=0;
      IOCB=0b00000001;//interrupt-on-change su rb0. lo preparò qui poi quando entro in modalità gioco alzo anche RBIE
      WPUB=0b00000001;//debole pull up su rb0
      PIE1=0b00000000;
      PIE2=0b00000000;
      PIR1=0b00000000;
      T1CON=0b00000000;
      RCSTA=0;
      SSPCON=0;
      INTCON=0b00001000;
      EECON1=0b00000000;
      TMR2IF=0;
      PR2=0b00111110;
      CCP1CON=0b00101100;
      CCP2CON=0b00000000;
      CCPR1L=0b00011111;
      T2CON=0b00000100;
      PSTRCON=0x01;
      VRCON=0b00000000;
      SRCON=0b00000000;
}

Il pin si brucia o si rompe, o per eccessiva corrente di carico, perché non vengono rispettati i valori di collegamento con tensioni e collegamenti "esterni" o perché non viene usato come si deve, per esempio configurarlo come output ed usarlo come input etc.

Come detto, se in condizioni "normali" il transistore rimane acceso, il problema allora molto probabilmente è nel codice..

Ora devo scappare, devo pulire casa e correre al lavoro.

Beh, menomale che c'è.. :)

gohan ha scritto:Beh, menomale che c'è.. :)

Già, speriamo anche per me in futuro .

Comunque ora sono sicuro che il software non abbia problemi, è solo un problema hardware, ma comunque penso interno al PIC.
Mi spiego:
Se provo a staccare il led ir, il tutto funziona senza problemi e RC1 riesce a pilotare il gate del mosfet.
Se riconnetto il led invece non funziona nulla, il motore accenna a partire ma non ci riesce.
Se il gate non lo piloto con RC1 ma lo attacco direttamente ai 5V, funziona tutto contemporaneamente, cioè il motore gira al massimo e il led trasmette bene, questo quindi esclude un problema di alimentazione, in quanto entrambi sono alimentati dalla stessa batteria litio-polimero da 11.1V che a quanto pare fornisce i 4,6A senza storie.
Ho provato quindi a usare degli op-amp in configurazione inseguitore di tensione, ma nel caso del led non funziona, credo non sia abbastanza veloce, e nel caso del gate neppure...
Sembra proprio che a fare troppe cose insieme non riesca, eppure non trovo dove vada questo eccessivo consumo di corrente ma sopratutto perché usando un inseguitore la situazione non cambi.

Diciamo che dal piccolo schema che hai postato non sembra che ci siano errori "particolari"..

Dire che il problema è di hardware è un po' generico. Se il LED è collegato correttamente, il problema è del codice che probabilmente è mal implementato, o il micro che non è adatto e magari lo devi tirare per il collo, perché no, ma penso più al codice.

L'uscita dell'Op Amp collegala ad un pin del PORTB con la Interrupt On Change.

Per il LED IR non userei la IOC, ma mo sembra che già ne avevamo parlato nell'altro thread dove riscontravi problemi con il codice.

Ebbene si, se il micro non è quello adatto, usane uno più performante o con più periferiche hardware interne.
I 18F per esempio hanno anche la priorità di esecuzione di interrupt se non ricordo male, eventualmente consulta qualche datasheet per farti una idea..