level shift, OD --> TP

e?

No, almeno per quanto riguarda una linea di trasmissione organizzata come l'I2C che necessita in certi casi di condividere il bus per la sincronizzazione di diverse velocit=E0. Interessante leggere il protocollo dal datasheet dell'ATmega8 (bus TWI) che lo spiega esaustivamente.

Una sola tensione ti toglie tutti i grattacapi di interfacciamento.

Prego.

Piccio.

*No, almeno per quanto riguarda una linea di trasmissione organizzata come l'I2C che necessita in certi casi di condividere il bus per la* forse non ho capito che intendi... l'arbitraggio del bus lo fa il master e con la soluzione che ho postato (che non è mia ma della philips) posso collegare tutti gli slave che voglio i resistori di pull-up ovviamente si mettono una volta per tutte e non per ogni slave che si aggiunge... tu dici che è qui il problema? cioè essendo degli stadi TP più ne aggiungo più carico la linea?

nel mio caso sarebbe solo 2 ICs ma il protocollo non è I2C... al momento non so nulla del protocollo, volevo individuare una soluzione "universale"

*Una sola tensione ti toglie tutti i grattacapi di interfacciamento.* lo so :) intendevo dire che ho un IC che lavora a +5v e poi ho un bus verso un secondo IC che può essere un IC a +3,3v oppure un IC a +5v (la scelta avviene in un secondo momento quindi mi serve una soluzione flessibile)

tipo ho visto dei lever shifter della maxim con doppia alimentazione, una è vvc1 e l'altra vcc2 poi hanno i vari I/O lato vvc1 e i vari I/O lato vcc2 quindi io metterei vcc1=+5v e vcc2=+3,3v oppure vcc2=+5v e senza cambiare nulla riuscirei a gestire sia connessioni 5v-5v sia connessioni 5v-3,3v

prima di "cedere" alla tentazione di compare da qualche parte questi ICs, mi chiedevo se c'era una soluzione a discreti... magari con un mos di mezzo come hanno fatto per il bus I2C che ho postato

GRAZIE!

-ice-

ps: una curiosità se ti va di rispondere... anche tu sei progettista? non che io lo sia ma giusto perchè qui su ihe intervengono anche progettisti di professione e/o hobbysti con decenni di esperienza

non

E' indispensabile saperlo. Nella I2C, il clock pu=F2 essere tenuto basso anche dallo slave per introdurre stati di wait necessari allo scopo di sincronizzare frequenze di bus diverse (periferiche lente con periferiche veloci). Infatti, i segnali son open collector e devono rimanerlo, il che giustifica l'interessante schemino che hai linkato. Il totem pole non permetterebbe questa situazione.

mi

Rinnovo l'invito a saperne di pi=F9 sul protocollo. Queste connessioni semplificate hanno dietro protocolli anche complessi.

Ho migrato dall'hobby alla professione (come artigiano autonomo), ma ho progettato di tutto tranne il mio futuro! :-) Sono ancora attaccato al basso livello (assembler, discreti, ottimizzazioni) e faccio fatica ad accettare l'utilizzo di "pappe pronte" che commercialmente rappresentano, invece, fonte di guadagno. E' un mio limite e sto cominciando a porvi rimedio. Affilo le armi in questo 2008-2009 e nel frattempo curo un'altra attivit=E0 pi=F9 redditizia totalmente diversa. In particolare, cerco di imparare ad usare l'ANSI C per vari ambienti e Visual Studio (che Dio mi perdoni!). Sono sostenitore del purismo software e della necessit=E0 di applicare un'informatica sana e robusta, senza accrocchi figli di una moda del momento. Anche l'utilizzo dei micro andrebbe sfruttato meglio: certi ambienti ad alto livello sfruttano malissimo le risorse. SIGH!

Piccio.

*E' indispensabile saperlo.* ho capito... è che stavo pensando prima al livello hardware cmq diciamo che dovendo usare uscite TP la possibilità di implementare I2C è esclusa

*Queste connessioni semplificate hanno dietro protocolli anche complessi.* gli IC della maxim di cui dicevo non fanno riferimento al protocollo... semplicemente possono raggiungere velocità inferiori se pilotati con uscite a drain/collettore aperto esempio: max3371

*Ho migrato dall'hobby alla professione (come artigiano autonomo), ma* cioè? tu progetti qualcosa e poi la metti in vendita oppure esegui il progetto su richiesta di una ditta?

*Anche l'utilizzo dei micro andrebbe sfruttato meglio: certi ambienti ad alto livello sfruttano malissimo le risorse.* mi sa che sia voluto questo... così poi l'utenete finale (non potendo/sapendo agire sul software proprietario) è costretto ad agire sull'hardware (cioè sul portafoglio)

lo dice anche lo spot "your potential, our businnes" :)))

-ice-