Ciao
per me per quanto riguarda la velocità del PIC 20 MHz sono anche troppo, considera che un motore che fa i 10000 giri sono 10000/60=167 Hz, basterebbe anche un quarzo da 1 MHz!!
Ciao
per me per quanto riguarda la velocità del PIC 20 MHz sono anche troppo, considera che un motore che fa i 10000 giri sono 10000/60=167 Hz, basterebbe anche un quarzo da 1 MHz!!
Ok si è vero ma è giusto per stare larghi..per me cmq la soluzione con l'88 e il timer0 che viene incrementato a ogni giro è fattibile per il conteggio dei giri..se poi si deciderà di non usare la EEPROM dove salvare le curve si può pensare di usare anche il glorioso 628A..:)
Mi sono accorto di un piccolo errore, riguardando il datasheet del 16F88 mi sono accorto può essere utilizzato solo in modalità slave sul bus I2C per tanto se si vuole usare una memoria esterna per le curve non è possibile farlo, provo a vedere se c'è qualcos altro, altrimenti si va sul 16F876A secondo me..
Allora intanto ripondo ad un po di dubbi. Per gestire l'anticipo e la misura del numero di giri servono 2 timer. Poi la frequanza elevata del clock serve per per elaborare i dati e non solo per poter misurare il numero di giri. Tenete con che ogni operazione necessita di un certo numero di cicli di clock per essere eseguita, se la frequenza e bassa ci mette piu tempo ad eseguire la stessa operazione, Se le manipolazioni sulle misure sono tante e vanno eseguito ad ogni giro, con clock a bassa frequenza non ci si sta dentro con i tempi.
Vol.
mmmm...perchè servono 2 timer? Spiegami come hai in mente di fare il firmware...
Le curve poi dove le memorizzi? nel pic o nella EEPROM?
Ciao
io non vedo poi questa grande quantità di operazioni da fare
1. fissi un certo periodo di tempo in cui vengono contati in un registro il numero di giri dell'albero
2. si fissa una tabella dove ad ogni intervallo di giri corrisponde un anticipo (ovvero la curva, che può essere memorizzata o sulla memoria del pic o su una memoria esterna). Per avere un determinato numeri di intervalli la soluzione più semplice è abbassare la risoluzione, cosa che si può ottenere aumentando la frequenza di campionamento oppure campionando con frequenza più bassa e dividendo il risultato ottenuto, cosa che si può effettuare semplicemente con l'istruzione RRF. Considerate che il registro del pic 16 è da 8 bit, per cui si hanno 256 combinazioni, che, se si fissa un regime massimo approssimativo di 10.000 giri, danno intervalli di 10.000/256=39 giri, che mi sembra abbastanza stretto come intervallo!!
3. sempre con lo stesso numero acquisito sopra e sempre attraverso una seria di divisioni e/o moltiplicazioni si arriva al numero di giri al minuto. Considerate che una moltiplicazione per n è la somma del numero con sé stesso n volte, e una divisione con risultato n è la sottrazione del numero con sé stesso n volte fino ad arrivare ad un risultato negativo. Quindi anche in questo caso non serve un gran ché di numero di cicli.
Alla fine quello che deve fare il pic è acquisire il numero, confrontarlo con un listato e moltiplicarlo/dividerlo per avere il numero di giri. Personalmente ho scritto firmware molto più complessi. Se il pic ha anche un certo numero di piedini, è possibile pilotare direttamente il display con la tecnica del multiplexing.
Quindi to pensi da lavorare sul numero medio di giri contati in un certo periodo?
Non so se puo funzionare bene, in fase di forti accelerazioni sei in ritardo con il calcolo dell'anticipo.
Non mi e' chiaro cosa vuoi campionare.
Ci credo che hai scritto firware piu complessi, ma pesno che tu semplificando troppo il problema.
Il controllo piu efficacie e' un controllo realtime, cioe si misura il tempo necessario a percorrere un giro completo dell'albero motore, si calcola l'anticipo desiderato, nello stesso istante in cui generi l'interrupt di fine giro, inizi a misurare il ritardo necessario per ottenere l'angolo di anticipo desiderato a quel regime.
Vol.