Newsgroup: it.hobby.elettronica.digitale
Titolo: help me... invertire un segnale minimizzando il jitter!

Ciao a tutti,
non riesco a venire a capo al problema in oggetto. Se ricordate tempo fa 
postai riguardo al fatto di un problema con un'interfaccia seriale SPI e 
integrati con modalità di funzionamento diverse.
La soluzione ultima è stata quella di riuscire per quanto possibile a 
uniformare la modalità. Ho però un integrato che rimane fuori : devo avere 
il clock basso a riposo, mentre tutti gli altri lo vogliono alto.
Per fare questo ho pensato di mettere una porta NOT sulla linea clock, ma ho 
potuto scoprire che l'integrato necessita un jitter tra clock e SDI molto 
piccolo, che non riesco a raggiungere con la logica tradizionale (ho provato 
anche con una porta della serie AHC, che garantisce un Tpd dalle parti dei 
10ns ma niente).
Ricordo una lezione di elettronica dei sistemi digitali, all'università, 
dove si affrontò un problema simile: il professore ci propose una soluzione 
che faceva uso di un flip-flop (sfruttando le uscite Q e Q negato), 
dicendoci che non era l'unica possibile.
Premesso che non posso aggiungere più di un integrato (altrimenti la 
miniaturizzazione va a quel paese, quando dovrò fare lo sbroglio più piccolo 
possibile prima di andare in produzione), qualcuno saprebbe aiutarmi ? Devo 
in sintesi garantire su due linee lo stesso tempo di propagazione, però 
avere in uscita una delle due invertita...
Grazie
Ciao
-- 
____________________
      CG Engineering
 Lab. Ricerca & Sviluppo
********************
Skype : cg_ingegnering
MSN : 
cgaudiola...@interfree.it
ICQ UIN# : 104528066 

avere in uscita una delle due invertita...
Con una porta XOR es.74HC86 puoi ottenere un buffer o un inverter a seconda
dello stato logico dell'altro ingresso, e credo che il  delay time sia lo
stesso, nel senso che non dovrebbe dipendere dallo stato logico.
--
ciao
  Stefano

 stesso, nel senso che non dovrebbe dipendere dallo stato logico.
Grazie....avevo già più o meno pensato ad una XNOR (es. 74hc266), ma la XOR 
che mi proponi te costa meno :)
Devo perdere il vizio di pensare sempre a NAND, NOR, XNOR, ecc.
Ho guardato lo schema interno: non dovrebbe dipendere dallo stato logico, 
infatti si trova tPHL=tPLH=tpd
p.s. non sono comunque venuto a capo del problema....non ho più idea di cosa 
fare, sto seriamente pensando di usare un secondo microcontrollore o 
cambiare ADC (è un adc il rompiscatole, il CS5523)....


 piccolo, che non riesco a raggiungere con la logica tradizionale
Apparentemente stai usando il fronte di clock sbagliato: il jitter non
c'entra nulla, dato che lo standard SPI imposta il dato su un fronte e lo
legge sull'altro. Siccome inverti il clock ma non il dato, quest'ultimo lo
devi campionare sull'altro fronte.
-- 
emboliaschizoide.splinder.com

 devi campionare sull'altro fronte.
Grazie per la risposta
Non avevo pensato a questo problema. Per adesso sto utilizzando delle 
librerie SPI software sfruttando altre linee, ma prima di fare il circuito 
stampato definitivo riproverņ con le SPI hardware
(soliti problemi di tempo...non č mai possibile fare qualcosa con 
calma...che p***e :) )


cambiare ADC (è un adc il rompiscatole, il CS5523)....
Forse ha ragione Antonio quando dice che non dovresti avere fronti così
time-critical e che il Clock ha la fase sbagliata.
Se guardi qui a pag.14:
http://www.tranzistoare.ro/datasheets/1150/158584_DS.pdf
 vedrai che i tempi di setup e hold sono tra i 50nS e i 150.
E' probabile che il problema sia nel tuo HW, se poi la SPI è software è quasi
certo. (perchè è sicuramente + lenta)
--
ciao
  Stefano

 devi campionare sull'altro fronte.
Dopo aver finito lo sviluppo del basso livello tramite le SPI software, ho 
riprovato con l'hardware, seguendo i tuoi consigli. In effetti così 
funziona, però la riconfigurazione mi fa smettere di funzionare la Secure 
Digital (sullo stesso bus SPI ci sono: RTC, SD, ADC,DS1822)!
Credo che con i nuovi driver di MikroC le cose vadano a posto, ma non ne 
sono così sicuro. Non mi forniscono i sorgenti per "firm policy"... credo 
che cambierò compilatore quanto prima, anche se, visto che nel demo limitano 
l'HEX a 2kb, potrei pensare di fare delle mini-periferiche per sfruttare le 
loro librerie built-in che sono davvero tante :
http://www.mikroe.com/en/compilers/mikroc/pic/builtin.htm


 Digital (sullo stesso bus SPI ci sono: RTC, SD, ADC,DS1822)!
Devi riprogrammare la modalità per l'accesso a ogni dispositivo. Lo SPI
dispone di quattro modalità, che corrispondono alle quattro combinazioni di
fase e polarità del clock (CPOL e CPHA). Fra i tanti siti informativi puoi
cominciare da qui:
http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Clock_polarity_and_phase
Se non hai i sorgenti potresti farcela lo stesso nel caso che i
trasferimenti siano sincroni (e quindi puoi programmare CPOL e CPHA prima
di ogni chiamata alle funzioni che usano il bus SPI). Se invece i
trasferimenti sono asincroni e/o usano il DMA la cosa si complica.
-- 
emboliaschizoide.splinder.com


Già.... infatti ogni dispositivo ha la funzione set_CE_xxx() (e la 
conseguente reset_CE_xxx() ) che abilita/disabilita il relativo ChipSelect, 
settando prima la modalità SPI opportuna.
Sembra però che il pic utilizzato (PIC18F8621/22) abbia dei problemi nel 
RIconfigurare la SPI più di 2 volte, e non riesco a capirne il motivo...ho 
provato anche a settare manualmente i registri fisici tramite piccole 
routine assembler (uso un compilatore C) ma nessun risultato 
incoraggiante...
Infatti, al momento, utilizzo SPI hardware per la SD e per il RTC e SPI 
software per l'ADC, visto che non riesco a farli lavorare correttamente 
sullo stesso bus. Sul forum di Mikroelektronika qualcuno mi ha detto 
esplicitamente di evitare di RIconfigurare le SPI hardware e di utilizzare 
eventualmente più di un micro!!!


 (sullo stesso bus SPI ci sono: RTC, SD, ADC,DS1822)!
Per il tuo problema ti confermo che, come ti hanno gia' detto altri,
probabilmente usi il fronte di clock sbagliato. Non ho mai avuto
problemi di jitter con la SPI.
Piuttosto ti pongo io una domanda.
Come hai risolto in C la condivisione della SPI tra un ADC veloce e la
SD?
Voglio dire, la SD ha latenze di decine di millisecondi, nel frattempo
come servi l'ADC? Che compilatore C usi?
Io l'ho fatto in assembly, che comunque prediligo, ma in C non mi era
riuscito.
Ciao.
pinco pallo


Non posso darti codice....comunque gioco con gli interrupt dei timer.
In pratica il main è una specie di dispatcher, che prende il task da servire 
da una fifo che ho implementato (sempre che non sia vuota). Con questo 
sistema non è troppo complicato fare una specie di prelazione "virtuale" e 
si ha *gratis* pure una specie di semaforo per ogni risorsa, SPI compresa.
Uso il compilatore CCS e per alcune cose il mikroC. Credo che abbandonerò il 
mikroC, che mi è servito per testare l'hardware e scrivere i vari driver di 
basso livello, per il semplice motivo che non forniscono i sorgenti delle 
funzioni built-in, per cui se hai un problema devi aspettare loro, e ciò è 
assolutamente inaccettabile.
Il CCS integra inoltre un RTOS cooperativo, che permette la prelazione e ha 
funzioni del tipo task_yield().
L'ADC che uso non è velocissimo, difficilmente devo salire oltre 40Hz di 
frequenza di campionamento! Per il momento è destinato alla misura di 
temperature , e nella sua versione più articolata potrà dare un campione 
ogni 200ms per 8 canali (che sono multiplexati all'interno verso un unico 
convertitore)
Tu hai del codice per la SD da poter fornire (con file system FAT16 o meglio 
FAT32) ?
Non riesco a trovare del codice che per funzionare non mi faccia perdere 
settimane....è stato questo il motivo per cui ho usato il mikroC! (che 
integra tutto quanto)
