Tachimetro auto (ex computer di bordo)

Francesco Sacchi ha scritto:

Per me diventa un problema, perché i segnali di accavallano e di conseguenza anche gli interrupt.

Speriamo, non vedo l'ora di risolvere.

Purtroppo non credo abbia questa funzione. Sul timer counter posso dare uno start e questo si avvia cominciando a contare dall'ultimo valore del registro contatore (se è la prima volta che conta, partirà da 0). Posso imporre un limite al conteggio (se arriva a 24 conteggi (ad esempio) si ferma e lancia un interrupt) o posso lasciarlo libero di contare fino a FF. Posso conoscere solo il valore di start e di stop ma non i valori intermedi. Solo che quel registro dopo l'interrupt, per ogni istruzione successiva viene ugualmente incrementato, se non ricordo male. Oggi stavo affrontando proprio questa problematica.

L'algo in un linguaggio inventato è questo:

@loop: cmp pin0, 5V je @loop

start timer

@loop2: altre_operazioni_interrompibili goto @loop2

interrupt_ext: stop_all_interrupt mov eax, contatore_timer mul eax, valore_in_us push eax call cmp_lookup_table

Artemis ha scritto:

Ho capito il tuo problema, ma non si può risolvere in modo ottimale senza usare un input capture.

In genere tutti i micro più moderni e diffusi hanno una funzione di timer capture (PIC16F876, ATMega8, etc...). Sei prorpio sicuro che il tuo non ce l'abbia? Che microcontrollore stai usando? Dal conteggio alla rovescia mi ricorda gli ST6...

Ciao

Francesco Sacchi ha scritto:

Ma l'input capture cosa fa di preciso?

ATMega8535

Il giorno Sat, 14 Jul 2007 09:00:10 +0200, Artemis ha scritto:

Se guardi qui

a pag. 95 Timer/Counter Clock - Counter Unit spiega come usare le funzioni contatore del Timer/Counter1 a 16 bits.

-- ciao Stefano

Artemis ha scritto:

Te l' ho spiegato prima, forse sono stato poco chiaro. L'input capture è un meccanismo hardware che svolge praticamente quello che tu hai implementato in software con un normale pin di interrupt.

Se metti il segnale da misurare in ingresso sul pin PD6 (ICP1), puoi programmare il timer1 in modo che al verificarsi di un evento a tua scelta (tipicamente un fronte) il valore attualmente presente nel contatore del timer venga salvato in automatico nel registro ICR1 e venga triggerato un interrupt. Il fatto che il salvataggio del valore di conteggio venga fatto in modo automatico dall'hardware del micro ti mette al sicuro dai problemi di latenza nella gestione dell'interrupt.

Puoi servire l'interrupt con quanto ritardo vuoi (e quindi puoi anche disabilitarli per brevi periodi) tanto ormai il valore di conteggio è stato già salvato. L'importante è che tutto duri meno del tempo tra 2 fronti consecutivi, altrimenti ne perdi qualcuno. I tempi che hai tra un interrupt e il successivo, nella peggiore delle ipotesti, sono di circa 5ms per l'iniettore, che a 1MHz fanno circa 5000 cicli di clock disponibili. Siccome suppongo che il tuo quarzo sia a una frequenza maggiore di 1MHz, non avrai certo problemi di accavallamento di interrupt.

Se quindi fai gestire l'iniettore dal capture del timer 1, la parte più critica è immune da problemi di concorrenza.

Per gestire anche il tachimetro avresti bisogno di un altro input capture, ma siccome l'ATMega8535 ne ha 1 solo, dovrai ricorrere allo stratagemma che avevi usato per l'iniettore, collegandolo ad un normale pin di interrupt del micro. E' vero, in questo caso potrà succedere che qualche volta il valore misurato sia errato in ecceso a causa della latenza, ma se riesci a tenere gli interrupt disabilitati per poco tempo, questo errore sarà trascurabile. Supponiamo che l'unico caso in cui gli interrupt sono disabilitati sia durante l'ISR degli iniettori. Vedendo il codice che avevi scritto le cose da fare non sono tante, supponiamo quindi che il tutto richieda 100 cicli macchina, che con un quarzo da 1MHz fanno 100us.

Se come dici, nel caso peggiore, il tachimetro fornisce un segnale con periodo 72ms ed anche supponendo che tutte le volte venga gestito in ritardo (che sappiamo non essere vero), questo comporterebbe un errore dello 0.14%. Mi sembra che sia ampiamente trascurabile, visto anche che ci siamo messi nelle peggiori condizioni possibili.

Ciao

e perche' ?

gli interrupt stanno li APPOSTA!!!!

200 km/h sono 55 m/s ovvero 20 interrupt al secondo il piu' puzzoso dei micro ce la fa ed '8535 non e' affatto puzzoso ( posso supporre che lo stai clockando a frequenza sufficientemente alta )

gli interrupt hanno un sacco di interessanti proprieta'

1) sono innestabili ( con un minimo di attenzione :-) ) 2) hanno le priorita' ( spesso ) 3) aspettano li pazientemente anche dopo che sono stati generati ( ma non in coda 4) ricihedono solo un po' di pulizia ed ordine quando si programma

i timer sarebbero ancora meglio, se ne hai a disposizione, in quanto il conteggio lo fanno in maniera del tutto automatica ( ed asincrona )

io avrei dato la seguente struttura

main loop con analisi dei dati e la gestione del display agganciata via un flag al successivo timer un timer per una base dei tempi da 1 s o piu' ovvero quella di refresh dei dati ( quando va in overflow setto il flag di cui sopra ) un timer + un interrupt esterno assegnato all'iniettore ( questa e' effettivamente la zona piu' pesante ) un timer hardware ( o un interrupt esterno piu' software ) per la velocita' ( quello che realmente misuri e' il cammino )

struttura abbastanza semplice e 'lineare'

chiaramente non posso entrare nei dettagli in quanto nno li conosco

i DUE diodi di clamp uno verso vcc e l'altro verso massa come ho gia' detto piu' una resistenza SERIE dovrebbero bastare ( e 100 pF verso massa pure li metterei ) prima dell'ingresso del trigger

anche un optoisolatore va bene con diodo esterno in antiparallelo al LED e resistenza di limitazione, sempre seguito dal trigger

la scelta tra 40106 e 74HC14 e' un fatto di gusti personali

anche se distruggi un paio di 40106 nessuno ti incrimina per eccesso di spesa :-)

puoi fare qualche prova, anche senza micro, attaccandoci i due canali dell'oscilloscopio a monte e a valle per vedere l'effetto che fa.

stiamo sempre parlando di segnali a bassissima frequanza ti puoi permettere di smorzarli un po' ma gli ingressi di interrupt gradiscono segnali 'ripidi' per cui meglio usare il trigger per avere fronti puliti.

ocio anche all'uscita del trigger alla presenza di eventuali ringing, un po' di capacita' puo' aiutare

"mmm" ha scritto nel messaggio news:46987f58$0$10628$ snipped-for-privacy@reader2.news.tin.it...

[cut] solo una domanda: perchè parlate sempre di "interrupt" ? non esistono interrupt in assoluto, ma richieste di interrupt (IRQ). Sarà poi il gestore (se c'è, ma sono propenso a suppore di si) appunto a gestirli, in base alle priorità. Ma esiste uno stack? Il sito della Microchip non brilla per chiarezza.

Solo per la precisione, a meno che i PIC, ai quali stavo cominciando a interessarmi, non siano rozze macchinette che sono in balia di interrupt non mascherabili. In tal caso rinuncio a tentare di programmare un simile schifezza. :P Qualcuno è disposto a darmi chiarimenti?

ciao Chance :O)

perche' in italiano si tende ad evitare le sigle e parlare e scrivere per esteso dove pero' "richieste d'interrupt" comincia a diventare un po' troppo lungo e si abbrevia semplicemente in interrupt.

poi distinguere tra le richieste possibili e quelle che effettivamente generano il salto alle ( alla ) routine d'interrupt e' una questione un po' di lana caprina, sia in condizioni statiche cioe' quando abilititi N interrupt ( qui ci andava sorgenti d'interrupt ) e li mantieni saempre abilitati sia in condizioni dinamiche dove abiliti selettivamente un certo numero variabile secondi le necessita' lo stack esiste e' di tipo hardware ( non mappato in memoria utente per quanto ne so ) e piccolo ( mi sembra anche solo 3 livelli nei pic piu' piccoli d'altro canto esiste anche l'istruzione di call

la mia esperienza e' con i pic della famiglia 18 esiste sia il flag di abilitazione generale sia i vari flag di abilitazione singola, due soli vettori ( fast e slow interrupt ) a cui mi sembra sia possibile associare le varie sorgenti, la risoluzione delle priorita' all'interno di questa struttura e' hardware e quindi fissata, la vettorizzazione richirede quindi un pelo di codice da parte dell'utente ( leggi : la presenza di piu' interrupt abilitati rallenta un po' i tempi di risposta )

e anche se non fosse cosi' basterebbe nno servire la prima volta la richiesta d'interrupt per una periferica e la suddetta non ne potra' piu' generare :-)

comunque i pic di devi guardare per quello che sono dei microcontroller e non dei microprocessori, se ti serve una architettura piu' ricca ci sono tante alternative, ma non allo stesso costo :-) e sopratutto con una diversa montabilita' hobbystica ( e' un velato riferimento agli ARM )

mmm ha scritto:

Per utilizzarli c'è bisogno della vector table ossia una sfilza di jump e return iniziali. Il primo jmp deve essere alla routine principale (il programma) poi in ordine ci sono INT0, INT1 ... TIMERCOUNTER0, TIMERCOUNTER1 etc. Quelli che usi come interrupt avranno un jmp alla propria routine, quelli che non usi devono avere un return.

Questa non la so.

Si è vero, sono molto utili anche loro.

E' possibile lavorare con numeri reali anziché solo interi?

I diodi allungano la forma d'onda, perché l'integrale sulla tensione deve essere lo stesso.

Diodo esterno?

Il ringing cos'è?

A presto

Artemis

SB ha scritto:

Perfetto Grazie!

Grazie infinite!

Artemis

mmm ha scritto:

Ottimo!

Il problema che mi è capitato (anche simulando un semplice buck) è che per ridurre gli spike hai un'allungamento dell'onda quadra, perché un conto è avere uno spike a 60 V, un conto ad avere uno spike che si ferma a 12 V... durerà di più perché la corrente si estinguerà per più tempo, quindi mi inficia la misura. Infatti sul monoiniettore gli spikes appaiono normali e ben appuntiti (anche a 60 V arrivano), non vi sono diodi che allungano la forma d'onda, altrimenti l'iniettore rimane aperto per più tempo.

Cos'è il ringing?

A presto e grazie 1000 per la tua soluzione.

Artemis

SB ha scritto:

Ottimo grazie!

Francesco Sacchi ha scritto:

Ecco, ora è molto chiaro e vedo con un occhio diverso il problema. E' veramente utile questa funzione!

Un'altra cosa che non mi è chiara: siccome abbiamo fatto soltanto esercizi sui led (solito accendi e spegni, le lucine dell'albero di natale, quelle cose lì), quando settavamo ad 1 il pin, i led si spegnevano (logica negata). Ora, essendo i led montati sul kit della Atmel, potevano essere stati montati appositamente negati per cui è necessario sapere:

1) Nella realtà, se collego un led al microcontrollore e imposterò il pin ad 1, si accenderà o resterà spento? Credo comunque che vi sia un pullup dentro il micro. 2) E quando leggo un segnale dall'esterno, se questo è a 5V (1 logico), il micro lo leggerà come 0 logico?

E poi c'è il problema del condizionamento del segnale, ovvero, come posso evitare che gli spikes dell'iniettore rompano l'optoisolatore? I diodi allungano la forma d'onda e generano latenze...

Ti ringrazio molto, mi sei stato d'aiuto sul serio.

A presto

Artemis

=E0:

scotto

e,

Ciao Artemis,

non ho avuto tempo di leggere tutti i 34 post (!!!)...cmq il trip computer =E8 il computerino di bordo che per es mettono sulle Punto a partire dalla terza generazione mi pare. In ogni caso il trip (=3D=3Dviaggio) ti da info sul consumo medio del viaggio, sul consumo istantaneo, sull autonomia residua, sui km percorsi etc.... Per la conversione F/V ci sono molti integrati , tra cui l LM131 ma credo te lo abbiano gia suggerito :)

Saluti e buona giornata :) Junior

errore mio ho usato una pessima traduzione per l'inglese "nested" mi riferivo che con un minimo di attenzione si puo' riabilitare la gestione degli interrupt all'interno della routine d'interrupt stessa in modo che eventuali interrupt veloci vengano serviti anche durante l'esecuzione di routine d'interrupt lenti

qui devi vedere sul datasheet, francamente non conosco gli AVR a fondo ma se lo schema degli interrupt e' simile a quello degli 8051 dovrebbe essere cosi:

interrupt vettorizzati ( e questo lo hai gia' confermato ) due livelli di priorita' assegnabili ai vari interrupt, all'interno di questi due gruppi la 'sotto'priorita' e' fissata in hardware

FIXED POINT ( o interi 'scalati' ) e' la parolina magica, niente floating point completa.

in questa maniera si riescono ad ottenere ottime prestazioni negli algoritmi senza inficiare la velocita' ( somme e sottrazioni restano identiche, moltiplicazioni e divisioni richiedono alcuni trucchetti )

ma stai avendo a che fare con segnali abbastanza lenti, non vedo il problema

e male che vada puoi usare o 1n4148 o 1n5718 tutti e due abbastanza veloci

si tratta di replicare lo stesso schema di protezione delle porte logiche ( tip. CMOS ) all'esterno del chip per maggiore sicurezza.

diodo esterno in antiparallelo al fotodiodo dell'optoisolatore cosi blocchi i picchi negativi

sovraelongazione , fronti troppo ripidi, derivanti dalla commutazione di porte logiche veloci, possono generare fenomeni oscillatori nel transitorio che in casi estremi si presentano come impulsi successivi

mi sembra la soluzione piu' banale, se hai delle risorse usale sempre, timer, interrupt stanno li apposta e non a consumare corrente :-)

ma non stai lavorando con un circuito di potenza, i 4148 sono veloci e con pochissima capacita'

vedi l'altro post

ue' va da se' che va testata quella e' comunque una soluzione di principio e poi c'e' parecchio lavoro da fare

P.S: non e' che pensi di misurare la velocita' della macchina misurando il tempo che intercorre tra due impulsi ?

Artemis ha scritto:

Il pull-up lo puoi attivare quando il pin lo configuri come ingresso. Se lo metti come uscita il pin presenterà un livello di tensione in accordo con il livello logico: se il pin è a 0 ci saranno circa 0V, se a 1 ce ne saranno circa 5. Per i valori precisi e per la massima corrente erogabile devi consultare il datasheet.

No, se sul pin di input sono presenti 5V il micro lo vedrà come 1 logico.

Il fotoaccoppiatore probabilmente si sfonda perchè il diodo led è soggetto ad una grande tensione inversa. Mi sembra strano però che la centralina elettronica non abbia già un circuito per proteggersi dalle estratensioni. Perchè dici che un diodo allunga la forma d'onda? Dove hai provato a metterlo? Io l'avrei messo in antiparallelo al led dell'optoisolatore.

Ciao

mmm ha scritto:

Eh ma come?

Il problema è che per quanto lenti siano i segnali, tanto alti saranno i picchi. Se il segnale è 1.35 us e il diodo me lo allunga a 1.7 us è la fine, perché vado in un altra regione. Il diodo condurrà fin quando la corrente non si estingue. Inoltre se metto un semplice operazionale non tiro corrente dall'iniettore, ma se metto il diodo, mi frego la corrente dell'iniettore e si spegne la macchina =)

Non è la velocità del diodo ma l'integrale della tensione a farla da padrona. Se l'integrale della tensione nel tempo è 6*10^-5 V*s, significa che c'è un picco di 60 V e che dura 1 us. Ora, se abbasso la tensione, il prodotto deve rimanere costante e l'impulso di 0.6 V (Vdiodo) mi durerà 100 us. Ecco perché sugli iniettori gli impulsi glieli fanno prendere in pieno, perché sennò il tempo di apertura non lo controlli più!

Lì mettono i diodi di protezione perché l'impulso è un qualcosa di anomalo e indesiderato e si preferisce salvaguardare la porta (se colleghi un alimentazione più alta di 5V o se c'è un guasto nell'alimentatore, ma quando si verificano queste cose, non ottieni dalle porte informazioni corrette). Io non devo solo proteggere l'operazionale, ma in condizioni normali devo bloccare l'impulso e ottenere la stessa informazione.

Ho un altro problema, mi servono questi timer counter:

1) Quello che controlla l'iniettore. 2) Quello che controlla gli spikes ogni 3 metri. 3) Quello che conta per 1s e poi fa il refresh del display.

Problema? Il mio microcontrollore ha solo 2 timer counter e devono essere usati di continuo, perché sono veloci, rispetto a quello di 1s.

Come posso risolvere?

A presto

Artemis

mmm ha scritto:

Si, infatti il tempo massimo di attesa è 10.8 s, il tempo minimo è 60 ms. Setto il micro in modo che se arriva un impulso, attende l'altro per al massimo 10.8 s. Se non arriva, resetta e attende indefinitamente l'altro impulso, mostrando chiaramente 0 km/h. Ogni coppia di impulsi mostra la velocità corrispondente nella fase di refresh, facendo una media delle tante misure effettuate.

A presto

Artemis