Interpretare segnali da partitore

[bloodsun]

Originalmente inviato da romoloman

Assolutamente no...
Evidentemente non conosci il bus I2C...
Il sistema con i sensori equipaggiati di pic diventerebbe molto più scalabile...
se ci riesci a mettere un cd4051 ci metti anche un pic o un AVR, inoltre in questi casi non hai bisogno del quarzo, l'oscillatore interno basta ed avanza...

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

[bloodsun]

Originalmente inviato da ElNonino

Allora vediamo di restringere le variabili, i 9bit che escono dal singolo sensore sono seriali, paralleli o codificati in qualche modo; per intenderci ci sono sensori di posizione a fotocellula, magnetici, ottici a laser etc etc etc con uscite codificate, oppure sensori 'barbari' tipo gli indicatori di direzione vento realizzati con 8 reed se hai 9 interruttori con contatto 'pulito' la soluzione R-2R potrebbe essere percorribile ti servirebbero solo 4 ingressi A/D sul PIC (uno per sensore) un solo filo di segnale dal sensore oltre al GND comune ed ai 12V.

Anche se l'ambiente industriale è intrinsecamente rumoroso si possono trasmettere segnali analogici a discrete distanze senza troppi problemi; un punto importante è anche conoscere la velocità di risposta necessaria, filtrare e pulire un segnale analogico comporta una latenza in taluni casi non accettabile (es. sistemi di sicurezza od emergenza).

Se lato sensore non rappresentasse un problema implementare un semplice circuito si potrebbe pensare di trasmettere il segnale o in corrente 4..20mA o con un pwm, anche la trasmissione seriale proposta da romoloman (leggermente più complessa) è percorribile usando una sola linea 485 per tutti i sensori (sconsiglio la I2C su distanze superiori ad 1m ed in ambiente industriale); che PIC usi per controllare il tutto ?.

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.

[ElNonino]

Ok allora domani sera ti sottoporrò alcune possibili soluzioni.

[romoloman]

Originalmente inviato da ElNonino

Se lato sensore non rappresentasse un problema implementare un semplice circuito si potrebbe pensare di trasmettere il segnale o in corrente 4..20mA o con un pwm, anche la trasmissione seriale proposta da romoloman (leggermente più complessa) è percorribile usando una sola linea 485 per tutti i sensori (sconsiglio la I2C su distanze superiori ad 1m ed in ambiente industriale); che PIC usi per controllare il tutto ?.

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

[ElNonino]

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.

[bloodsun]

Originalmente inviato da ElNonino

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.

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
Grazie per il momento

[romoloman]

Originalmente inviato da bloodsun

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
Grazie per il momento

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.

[bloodsun]

Originalmente inviato da romoloman

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.

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.

Originalmente inviato da romoloman

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.

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à

[muvideo]

Originalmente inviato da romoloman

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.

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.

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.

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

Ciao!

[romoloman]

Originalmente inviato da muvideo

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

Ciao!

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