Riprendiamo da qua:
http://megasquirt.forumfree.it/?t=30556122

follediquinta sembra sparito, ma il progetto pur sembrando fermo, si muove sempre
Mi sono quasi convinto a fare un circuito che di per se non fa la decodifica delle ruote foniche, ovvero che di base non puo' essere usato senza megasquirt, ma con l'aggiunta di un chip dedicato per la sola decodifica ci sia la possibilita' di usarlo in modalita' standalone. Così ognuno si fa gli affari suoi. Uno si occupa della decodifica, l'altro della rilevazione del battito della comunicazione con il tpic, etc.
Io intanto sto cercando di capire con james se posso sfruttare il tacho out della megasquirt per capire dove è il tdc, in modo da poter avere il riferimento per il windowing...

Enri eccomi qua. Il progetto riparte.

Allora, da quello che mi ha detto james l'uscita del tacho è abbastanza affidabile, ovvero viene 'sparata' nella routine di decodifica della ruota, ed è legata all'angolo dell'albero della ruota fonica.
Che alla fine è quello che avevo scoperto io oscilloscopio alla mano, anche se avevo notato un errore di qualche grado ad rpm elevatissimi (no so se per latenze sw o per latenze hw), ma la cosa non mi preoccupa, se la finestra di windowing si sposta di 1 o 2° non cambia nulla.
Quindi, l'idea continua ad essere quella di sfruttare il tacho per rilevare il pms, con futura opzione un integrato che permette la decodifica al volo della ruota.
Nel caso volessimo sapere quale cilindro ha detonato, penso la cosa piu' semplice sia interfacciarsi ad una uscita digitale che poi va verso le bobine, così da avere il riferimento del primo cilindro. Nel caso di cpu aggiuntiva per decodifica ruota in modalita' 'standalone' (separata dalla ms) il chip stesso si occupera' di decodificare anche il segnale di camma.
Come dicevo, preferisco fare in questo modo, così a chi interessa averlo solo attaccato alla ms non deve pagare per una mcu piu' costosa e relativi circuiti di condizionamento, ed il codice risulta piu' pulito e snello.
Ad ora sapere che cilindro ha detonato non credo sia una cosa indispensabile, tanto se non è la centralina a tirare indietro l'anticipo di quel singolo cilindro non serve a molto...

Sul sito msextra c'e' uno che si è cimentato a fare un circuito simile, che vende alla 'modica' cifra di 150$... Ha applicato anche la procedura di autoapprendimento del rumore di fondo come pensavo di farla io
Io penso di poter stare entro cifre molto piu' ragionevoli.

Lui per mandare il segnale di knock alla centralina usa dei DAC, e per campionare il segnale di detonazione usa il canale analogico... Non mi sembra un buon metodo...
Io pensavo di leggere il livello di knock via spi, e sfruttare l'uscita analogica della tpic da mandare alla centralina. Peccato che il segnale di uscita durante il tempo di integrazione fa una rampa, che darebbe fastidio sicuramente alla megasquirt (la stessa non fa per ora windowing, fa un pooling a tempo fisso del segnale analogico del livello di knock, non relazionato agli rpm).
Il tpic è pensato per acquisire il valore solo alla fine della finestra di windowing. Per risolvere questa rogna, pensavo di usare un semplice circuito di sample & hold, che mantenga costante il segnale di uscita fino a che non c'e' una nuova campionatura disponibile.
Tanto il segnale di uscita della tpic è direttamente proporzionale al livello di detonazione, perchè farlo entrare nella mcu per poi doverlo fare riuscire?
Una volta impostati i parametri della tpic (costante integrazione, amplificazione, frequenza, etc), è la stessa a dare il valore corretto... La mcu legge il valore solo per statistiche 'interne', o per accendere un buzzer o una spia. Mentre la megasquirt riceve il suo segnale analogico.

Usando questi accorgimenti mi risparmio dei passaggi inutili di ADC/DAC, lavoro di processore, costi che ritengo inutili, etc.

Che ne dite?

Non so se ho capito bene, non vuoi usare una mcu in più? Secondo me è necessaria visto che a memoria c'erano parametri da impostare a variare del regime. Il sample and hold c'è già sul tpic. Il tutto sempre a memoria. Ce la fai a buttare giù uno schemino?

Allora, pensavo di usare una mcu per comandare via spi con la tpic, un'altra mcu (opzionale) per la decodifica dei vr, ed ovviamente la tpic.
La megasquirt pero' si aspetta un segnale analogico, proporzionale al livello di detonazione.
Per far questo sarebbe bello mandare l'uscita analogica della tpic direttamente alla megasquirt, peccato che se controlli sul pdf del tpic, durante l'integrazione (finestra di windowing) il segnale parte da 0v per salire fino ad un valore che è proporzionale al livello di detonazione (tenendo conto di amplificazione, etc impostate via spi). Una volta finito il periodo di integrazione il segnale resta costante fino al successivo ciclo di windowing (in questa fase dovrebbe avvenire l'acquisizione del livello di knock da parte della mcu)
La megasqirt non digerisce sicuramente questo tipo di segnale, in quanto (per ora) effettua un campionamento ogni TOT ms (non relativi all'angolo di manovella ne' tantomeno agli rpm), percio' potrebbe campionare il segnale a meta' della rampa. James diceva che probabilmente aggiungeranno il windowing prima o poi (e magari si potra' avere un'uscita digitale che indica il periodo di windowing impostato nella megasquirt), ma per ora è così, e cmq dubito lo facciano per la ms2.
Per risolvere questo problema, pensavo di mettere un chip di s&h in grado di far mantenere la tensione costante anche durante il tempo di integrazione, e far 'aggiornare' il segnale di uscita solo alla fine del periodo di integrazione.
L'alternativa è quella di usare un DAC collegato alla mcu che da l'uscita corretta.
Ma a me non me ne sembra il caso, quando un semplice s&h puo' fare tutto...

Non sapevo che la ms volesse un segnale analogico. Pensavo ad un segnale digitale perché o c'è o non c'è detonazione.
Sulla logica analogica se non ci fosse detonazione e tutto fosse impostato correttamente la mega dovrebbe campionare sempre il solito valore.
Sulla logica digitale invece si legga il valore via spi e la mcu decide se c'è detonazione e poi segnala alla mega portando un pin digitale alto, la mega lo legge e abbassa l'anticipo.
Non so proprio come lavori la mega. Secondo me avrebbe più senso se l'ingresso fosse digitale e poi la mega diminuisce l'anticipo gradualmente finché la detonazione non cessa.
Una altrenativa potrebbe essere un buffer tristate abilitato solo quando il chip è in fase di hold. Come lo fai il s&h?
PS: secondo me non serve un'altra mcu per la decodifica nel caso non si usi il circuito con la mega.

Sisi, l'ingresso è analogico... La detonazione non è che c'e' o non c'e', volendo fare i precisi in base ai vari livelli di detonazione si possono prendere diverse strade. Se la detonazione è lieve applicare solo un leggero ritardo, mentre se è forte usare un ritardo piu' considerevole.
Questo per non perdere troppa potenza.
Utile se stai finendo un giro in pista, o altre situazione dove insorge al detonazione, e non vuoi ne' buttare il mtoore ne' ritardare troppo.
Cmq per ora è si un ingresso analogico, ma viene gestito come se fosse digitale, pero' espansioni future del codice ms3 penso si dirigano verso la strada sopra descritta, eprico' meglio prepararsi in anticipo.
La ms1 era digitale se non ricordo male...
Per l's&h pensavo di usare un chip dedicato. Non costano tanto. Il piu' è che il s&h lo piloto tramite una linea digitale, mente un DAC dovrei probabilmente o pilotarlo con un sacco di pin (parallelo, come un R-2R), o via seriale (che mi ruba tempo alla cpu).
Sono tutti accrogimenti che mi permettono di lasciare scarica la cpu.
Volevo usare un altro chip per la decodifica della ruota anche per questo. Ricorda che pur sembrando semplice la decodifica della ruota N-1, la decodifica di altre eventuali ruote puo' non essere altrettanto semplice. Poi come dicevo mi lascia anche piu' pulito il codice della mcu collegata al tpic, e cmq le pic di fascia bassa (leggi - economiche) non è che hanno tanti timer hardware.
A chi interessa usare il circuito abbinato alla ms, non installa i circuiti vr/opto/hall e non mette la cpu, e porta il segnale tacho direttamente alla mcu collegata al tpic.
Senza contare che posso inziare lo sviluppo del codice senza preoccuparmi di decodificare nulla, e poi posso aggiungere la decodifica senza toccare il codice della mcu che gestisce la tpic.
La vedo la cosa piu' economica e sensata al momento...

guardate un pò
http://www.youtube.com/watch?v=c0u-tbCu ... er&list=UL