Bus I2C effettivamente non lo conosco, quindi non mi azzardo più a ribattere, anzi se ti spieghi meglio su cosa avevi in mente potrei valutare se possa essere più conveniente il pic rispetto al registro. (anche se mi avevano sempre detto che l'oscillatore esterno era di rigore per il funzionamento del pic)
Per quanto riguarda il CD4051 ho appena promesso a ElNonino che c'avrei dato un'occhiata (cosa che devo ancora fare). Non conoscendone nemmeno le dimensioni, difficilmente posso dirti che ci sta fisicamente o se ci sono altre problematiche a portare i segnali per esempio.

Ciao

vedo di rispondere alle domande specifiche.
I sensori sono semplici micro switch a contatto on/off e mi danno 9 bit di segnali isolati fra loro. Se vogliamo identificarli così, in questo momento li posso definire 9 bit in parallelo.
La definizione "R-2R" non saprei cosa comporta a livello di schema e a livello di interpretazione softwere.
Particolari esigenze di tempo di risposta non ne ho... quando ho una lettura ogni mezzo secondo penso sia già sufficente, non ho necessità ed esigenze di sicurezza perchè il macchinario è isolato dall'essere umano e non crea danni anche se andasse fuori dai sensori. Comporta solo il doverlo riposizionare (L'esempio più verosimile è "sensori di parcheggio a contatto" per evitare che altre macchine collidano con essa.)
Non ho grandi problemi di distanze o rumorosità ambientale, ma semplicemente l'impossibilità fisica della sezione che ne limita il numero di cavi da poter passare per arrivare alla scheda del pic.
Attualmente a casa ho un 16F877 ed ero partito con quello, ma se volessi usarne uno di minor dimensioni e porte non mi cambia molto (dipende tutto dalla soluzione che adotterò)
Poi il pic fungerà da slave ad un'altro pic con un segnale a 12 V in PWM (opportunamente interfacciato) che trasporterà il segnale per un cavo di circa 5 metri. In base al livello di PWM saprò in che posizione è l'oggetto sui sensori.

Ok allora domani sera ti sottoporrò alcune possibili soluzioni. :wink:

:yeah:

concordo, ma senza specifiche di lunghezza il modo più semplice mi sembrava l'i2c, del resto se si potevano portare dei segnali mediante un DAC casereccio immaginavo che le distanze non fossero eccessive. Comunque concordo in ambito industriale meglio RS-485
Come soluzione vedo bene un atmega-32 con un max485 in cascata

Dop 2 calcoli direi che la soluzione analogica sia, giustamente, da scartare, 9 bit di risoluzione sono 512 livelli di tensione....

Quindi direi che l'uso di uno micro, PIC od ATMega o..., che serializza e trasmette i 9 bit, sia la soluzione ideale (usando questo sistema + la 485 puoi assegnare un indirizzo ad ogni gruppo di 9 sensori e connettere fino a 255 gruppi) in alternativa il registro a scorrimento.

:yeah:

Se non ho capito male, il sistema analogico è da scartare, I2C non è applicabile e mi resterebbero solo le soluzioni PIC, ATMega (che necessitano di quarzo e altro) e l'utilizzo di registri.
Credo che per le solite questioni di spazio sulla basetta per far correre le piste dei sensori, utilizzerò il registro che mi permette una quantità di componenti minore, non necessita di programmazione se non nel pic master (unico), e mi bastano 5 fili di collegamento per i registri 74HC165 (GND, +5V, il segnale di lettura dati (pin 1) il segnale di clock (pin 2) e l'uscita del segnale in serie (pin 9))
OK... dovrebbero bastare poche righe di programmazione ciclica per caricare su variabili il dato dei sensori e 3 pin del pic per collegarsi ai registri.
Adesso mi metto a studiare il protocollo USART.
Se ho cannato qualche cosa... correggetemi pure :wink:
Grazie per il momento:D

l'unica cosa cannata a mio giudizio è la seguente... la scalabilità e il numero di fili che ti troveresti in giro, comunque devi usare un 74HC676 perché ti servono almeno 16 bit per gestirne 9.

Considerate le possibili basse velocità di trasmissione un pic o un avr possono andare con l'oscillatore interno.usando un atmega 32 smd non credere di occupare molto più spazio che con uno shift register.

sul fatto che dovrei usare il 74HC676 è vero per fare il 16 bit, hai perfettamente ragione, ma sempre per la questione della larghezza del circuito (i sensori sono tutti in linea) mi conviene far passare 3 linee in più per pilotare un paio di HC165 (2 andata e 1 ritorno) posti alle estremità piuttosto che un HC676 che mi costringe a piazzarlo da un solo lato e far passare ben 8 linee in più dai sensori. L'alimentazione è centrale e quindi posso portarmela dove voglio e piazzare un HC676 al centro dei sensori è impossibile.

In futuro approfondirò meglio il discorso quarzo. Per quanto riguarda SMD mi piacerebbe tantissimo riuscire a realizzare certe basette, ma mi risulta difficile lo sviluppo delle basette senza perdita di piste per eccesso di esposizione o sviluppo o il contrario di cortocircuiti tra le piste per difetto.
Sto già lavorando con piste da 0.5/0.8 interposte a 0.3 mm e mi sembra già ai limiti delle mie capacità/possibilità

Non ti seguo, di registri a 8 bit ne può concatenare quanti ne vuole,
il numero di segnali verso il micro rimane quello:
- Clock
- Data
- Load
a cui si aggiunge un Data Out -> Data In tra un registro e l'altro
Ma forse non ho capito cosa intendi.

Anche se l'idea del micro per ogni gruppo di sensori è sensata un
atmega 32 è uno schiaffo alla miseria, per impacchettare pochi
bit e spedirli sulla seriale, ma io tendo ad essere un po' taccagno con i
componenti elettronici :P

Ciao!

Vabbè dai allora un ATtiny261A
costa meno di due shift register...