un parere...

la tua soluzione e' giusta ma costosa

ti conviene usare una decodifica 74xx138 o simile dipende anche se l'enable e' 0-attivo o 1-attivo gli ingressi della decodifica al PIC

con 2 '138 si fa la decodifica 4->16

ci sarebbe anche l'integrato che da solo fa la 4->16 ma e' piu' difficile da reperire

questo e' giusto cosi

ok , chiaramente un ingresso analogico , altrimenti gli amux sono sprecati

attento ai tempi di setup ( commutazione ) dei mux altrimenti aquisisci fischi per fiaschi

sopratutto se le impdedenze d'uscita dei segnali d'acquisire non sono piccole.

Ok, grazie, ma non capisco perch=E8 la mia =E8 pi=F9 costosa?, l'unica=20 differenza =E8 che per gestire 16 mux tu useresti 2 decodificatori al=20 posto di un altro mux pi=F9 grande...

attivo a 0

non essendo esattamente un pic, ma qualcosina di pi=F9 intelligente,=20 questo non =E8 un problema

=20

=20

ati

Chiaro

to=20

=20

su questo ci sar=E0 da perdere bel tempo temo....

cosa intenti per "non sono piccole"?

Grazie

perche' un mux analogico, per giunta il 16->1, costa mediamente di piu' di due '138 , tieni conto che col mux devi aggiungere , per sicurezza anche le 16 resistenze di pull-up degli enable

bene il '138, roba che trovi anche dal panettiere :-)

cos'e' un mainframe IBM ? :-)

giusto per curiosita' verso cosa ti stai orientando ? che mux analogici hai scelto e che micro ?

solo qualche prova in piu'.

Ti conviene organizzare due ingressi a due tensioni quanto piu' diverse possibile ed acquisire alternativamente variando il ritardo fino a trovare quello ottimale

in questi casi e' tutto relativo dipende anche dalle eventuali capacita' parassite/volute introdotte nel circuito, quanto piu' alte sono le impedenze in gioco tanto piu' lunghi sono i transitori

mmm ha scritto:

=20

$ 2.24 =E8 quello che mi costa un mux, facendo un po di conti della serva= ,=20 stamattina mi sono accorto che per la gestione mi conviene usare 2 mux=20

1:8 al posto di 1 mux 1:16, sono estremamente pi=F9 veloci quelli da 8.

Ci avevo gi=E0 pensato.

un main frame no, ma qualcosa di moooolto pi=F9 veloce di un pic si.

per i mux ho scelto questi:

MAXIM MAX4617:

datasheet:

Per il "micro", se proprio lo vogliamo definire cos=EC:

una cosuccia, processore risc da una ciclo di clock per istruzione ed=20 funziona a 100 MHz....e ci gira un core linux dentro sta meraviglia...

=20

No, non ti seguo, mi lo spieghi per favore?

i decoder costano decisamente di mano

bello!!! lo conoscevo gia', non amo troppo le flash integrate nel core ma non si puo' a vere tutto nella vita, ho sempre paura che dopo un po' mi abbandonino poi bisogna vedere il kernel linux quante risorse si mangia

il caso peggiore si ha nella transizione tra due ingressi che si trovano a tensioni molto diverse inoltre e' abbastanza complesso fare una stima 'a priori' delle costanti di tempo in gioco per cui la soluzione piu' semplice e' fare le prove sul campo in fase di test dell'applicazione.

per cui piloti due ingressi analogici ( del tuo sistema d'acquisizione ) con due valori di tensione ai limiti del range accettabile e acquisici alterativamente dai due ingressi variando il ritardo tra la commutazione del mux e l'acquisizione vera e propria fino ad acquisire i valori 'giusti' , noterai infatti che se il ritardo e' troppo piccolo avrai letture in errore ( con valori intermedi tra i due valori attesi )