Alimentazioni e seriali su PCB lungo

cut...

on

Spara, sono seduto! :-)

Piccio.

Piccio:

Niet. I pin dello SPI sono anche ingressi analogici.

Costano più o meno quanto un processore e sono piuttosto grandini. Immagino che i fotodiodi debbano essere in posizioni predefinite, lo sbroglio si complicherebbe non poco.

LOL

Il 11/09/2010 14:32, F. Bertolazzi ha scritto:

L'idea era di non usare il quarzo ma l'oscillatore interno e di fare una seriale sincrona utilizzando gli interrupt. La sincronia mi permette di essere indipendente dalle tolleranze del clock, e trasmettere un paio di byte in corrispondenza dei fronti si può fare agevolmente via software, visto che i micro non devono fare altro se non acquisire i segnali analogici e trasmetterli.

Questa almeno era l'idea iniziale.

Quindi una specie di daisy-chain... in questo caso però se mi si blocca un micro blocco tutta la catena. Invece con la seriale "lunga" posso segnalare un malfunzionamento di un blocco e continuare ad acquisire gli altri.

Poi è da capire se questa cosa serve... anzi quasi certamente la mancanza di un blocco rendere inutilizzabile il dato finale. Quindi ragioniamo come tu proponi.

Può anche essere che mi bastino 8 bit, comunque per sicurezza anche io sto facendo i conti a 10 bit.

Perché trasmettere un A/D alla volta? Non è più comodo inviarli tutti e

Quindi questo secondo micro trasmette al terzo

Passiamo al micro n 3 che riceve la stringa sopra. Questo trasmette al 4:

e così via fino al n. 16 che riceve quindi una stringa lunga

a cui dovrebbe aggiungere i suoi 8 A/D. Ora... dal micro n. 1 siamo arrivati all'ultimo (dalla parte opposta al master). Non ho capito come facciamo a far "tornare indietro" i dati.

mumble... cosa pensi invece di questa soluzione?

All'accensione ogni micro manda un "ping" al micro successivo. Quello che non riceve risposta assume di essere l'ultimo della catena.

Quando il master invia lo start, questo viene propagato fino alla fine della catena. L'ultimo micro non fa altro che inviare al precedente un 'token' e i suoi dati. Il micro precedente accoda i suoi e così via fino a tornare al master. Il token è in realtà un pacchetto di qualche byte che contiene dei flag che possono essere modificati dagli altri micro per segnalare qualcosa.

Mi sembra più semplice o sbaglio? Anche in questo caso tutti hanno lo stesso software e la cosa funziona in modo indipendente dalla lunghezza della catena.

Yep, infatti stavo proprio cercando una soluzione su come evitare di impostare l'indirizzo di ognuno.

Questo è interessante anche perché i dati cambieranno molto lentamente (nell'ordine di qualche secondo come minimo). Però vorrei prima essere in grado di gestire l'aggiornamento continuo.

Marco

Il 11/09/2010 15:22, F. Bertolazzi ha scritto:

Secondo te - io non ci ho ancora provato - quanto è complesso fare un bootloader seriale con questo hw?

Perché a questo punto programmerei una volta i micro in ISP con le mollette (ne ho ordinate altre 3M e sto facendo delle prove. Se non vanno ancora scrivo a quel contatto) e poi aggiornerei i vari firmware a catena.

Tornerebbe comodo per eventuali upgrade sul campo senza dover accedere fisicamente al PCB.

Esatto.

Marco

cut... [Bertolazzi]

Di sicuro aumenta il rumore e si riduce la simmetria. Un solo micro =3D un solo ADC =3D tutte le misure godono dello stesso errore =3D stessa Vref =3D minor consumo =3D un solo firmware =3D una sola programmazione. Io userei un ATmega88 che ha anche l'UART e 512 bytes di RAM in grado di contenere le 128 conversioni a 10 bit. Eppoi, un HCF4067 (ANALOG MULTIPLEXER/DEMULTIPLEXER 16 vie) costa 1.46 euri su FARNELL, meno di un micro minimale. Con 8 dispositivi risolvi, totale 9 integrati. La soluzione coi micro ne deve impiegare minimo 16. Data la grande simmetria, basta portare un bus di 11 linee su ogni segmento di scheda: Vcc, Gnd, 4 Address, 8 Enable, 1 Analog. Con una struttura a totem viene molto pulito e i consumi restano praticamente quelli di un solo micro.

Piccio.

Marco Trapanese:

Non è detto. Se il malfunzionamento inchioda la linea dati o sincronia, sei del gatto.

Nel senso che al reset (ovvero un segnale di sincronia molto lungo) tutti i micro mettono l'output alto. Quindi il solo che non vedrà alto il proprio input è il primo.

Se trasmetti 10 bit ed hai una disparità di clock superiore al 5% riceverai l'ultimo bit sbagliato. Per trasmetterne 100 la differenza tra gli oscillatori deve essere inferiore allo 0,5%.

Hai dimenticato i 10 bit a 0 tra i risultati di micro1 e micro2.

Se per byte intendiamo il numero di bit che vuoi leggere dagli A/D, il 16mo ne riceverà (8+1)*15.

Non sapevo tu dovessi far tornare indietro dei dati.

Mette l'output in alto, come già descritto. Non solo all'accensione, ma quando "sente" la linea di sincronismo alta per diciamo 1 secondo. Quando il sincronismo torna basso campiona l'input.

Vuoi eliminare la linea di sincronismo, quella che dal master va in parallelo a tutti gli slave?

Non direi proprio. Stiamo sempre parlando di liea dati "in serie" ("daisy chain" è il girotondo, qui giri non ce n'è) e linea sincronismo "in parallelo"?

Anche in questo caso tutti hanno lo

Il fatto è semplice: per spedire il singolo dato devi raddoppiare i dati da inviare, dato che l'indirizzo è praticamente grande quanto il dato.

Se prevedi che, in media, più di metà dei campioni sarà uguale al precedente, ti conviene trasmettere solo i cambiamenti.

Non ha però molto senso continuare a elucubrare, dato che non ci hai ancora detto quale frequenza di aggiornamento ti serve, la latenza massima accettabile e la durata minima degli eventi.

Insomma, anche tu lavori ad un progetto ipersegreto e non ci dici a che serve perché poi dovresti ucciderci tutti.

Piccio:

Più di un tiny24 o 44. Che però in SOIC non hanno. :O

Il tutto lungo un metro e mezzo???

Il 12/09/2010 14:57, F. Bertolazzi ha scritto:

Nel caso di una produzione non acquisterei da Farnell ;)

Mi accodo alla domanda! Già sono abbastanza confuso su come gestire due linee di alimentazione, figuriamoci portarmi a spasso per un metro e mezzo tutte quelle linee!

E ricordiamoci che la larghezza del PCB non sarà più di 20 mm circa.

Marco

Il 12/09/2010 14:44, F. Bertolazzi ha scritto:

Ok.

Aspetta, io quando parlo di seriale asincrona penso a un 8N1. Avrei certo dell'overhead e dei bit "sprecati" (che comunque riciclerei come flag) ma al massimo trasmetto sempre 8 bit alla volta e saranno sempre ricevuti correttamente. Per cui posso inviare anche 100000 byte, sempre uno alla volta.

Allora non ho capito a che servono :( Pensavo che i 10 bit a 0 indicassero l'inizio dei dati "storici" e i 10 bit a 1 l'autorizzazione ad aggiungere i nuovi.

Senza contare che bisognerebbe anche gestire i casi di letture 0x000 e

Io appunto ragionavo sempre in byte.

Ma non mi torna il conto anche ragionando in bit. Se abbiamo 15 micro, gli A/D sono di 10 bit (anche trasmettendo un solo canale alla volta, come mi pare di avere capito) più di blocchi di 10 bit 0 e 1 che inframmezzano il pacchetto, questo dovrebbe essere molto più lungo.

Beh, il master come fa a leggerli? A meno che, reinterpretando quello che hai scritto, tu per master consideri il primo micro della catena, che quindi risulta autonoma nella trasmissione dei dati.

Questo lo eviterei però, preferisco tenermi sempre libera la possibilità di comunicare qualcosa ai tigrotti.

Si, ma così sai chi è il primo ma non chi è l'ultimo. Forse nel tuo ragionamento non serve saperlo, ma non sono ancora arrivato a quello stadio :)

Ahhhhh, ecco dove non ci capiamo! Avevo capito che l'avevi tolta tu:

Con quell' "anzi" e segnale di inizio trasmissione avevo inteso che il master comunicava sulla stessa linea seriale della catena, non con il clock della prima frase.

Sicuro? Io avevo questa nozione:

dove appunto dice che la d.c. non forma loop:

"In electrical and electronic engineering a daisy chain is a wiring scheme in which, for example, device A is wired to device B, device B is wired to device C, device C is wired to device D, etc.[1] Connections do not form webs (in the preceding example, device C cannot be directly connected to device A), nor do they loop back from the last device to the first."

Io l'ho vista così (che è diversa dalla tua che non ho ancora afferrato appieno, mi rileggo ancora una volta i tuoi post) :

MASTER 1 MCU 2 MCU 3 MCU...

il master è su una scheda diversa. Tutti i giocatori sono collegati tra loro con una sola linea (quindi due pin per micro).

Il master invia il comando di start al N.1 che lo ritrasmette fino all'ultimo della catena.

Questo esegue la sua acquisizione e la invia al precedente. Quest'altro accoda la sua acquisizione e invia il tutto a quello ancora prima.

Così fino a tornare al master che si vede recapitati tutti i messaggi.

Lo potrò sapere dopo il primo prototipo, ora non sono in grado di stimarlo. E nel caso è solo una modifica software.

Ma uffa. Sei tu che lo pensi. E' che non ne ho la minima idea. Le specifiche sono quelle che ho scritto, poi si fa il prototipo e si corregge il tiro.

E poi ho scritto che a occhio i valori cambieranno nell'arco di qualche secondo, quindi direi che qualsiasi soluzione si scelga non è un problema di velocità di aggiornamento o di latenza, quanto di criticità del layout (con le linee ad alta frequenza lunghe) o di comodità di gestione (es. firmware tutti uguali).

Marco

Marco Trapanese:

Ne parlavamo per telefono. Non ti potrà rispondere prima di notte. In effetti i processori, coi loro oscillatori e trasmissioni, un po' di rumore ne fanno, otre che consumare, che fa rumore anche ciò. Col sistema di Piccio avresti un assorbimento totale nell'ordine del mA.

Le linee di controllo dei multiplexer analogici (CD4051, 8 in 1 out) potrebbero essere controllate con degli shift register (74595, uno serve due 4051), quindi dovresti mandare in giro, oltre le alimentazioni, la linea analogica, clock e dati seriali, comando di trasferimento tra shift e latch.

Tra l'altro forse avrebbe senso avere una doppia alimentazione, una per i sensori, da far correre insieme alla linea analogica, ed una per shift e multiplexer, da far correre insieme ai tre segnali digitali.

D'altronde, non sapendo chemminchia ci vioi fare, è difficile dare una soluzione...

Marco Trapanese ha scritto:

Non so se ho perso qualcosa del discorso... a parte che 400kHz non so se =

sono po cosi' critici per una distanza inferiore ai 2 metri, ma non mi=20 sembra che ci sia bisogno di tutta quella velocita'.

C'e' un master che chiama 15 slave. Un byte di chiamata e due di risposta, per 15 volte fanno 45bytes, cioe' =

Se facciamo il trenino di micri il traffico aumenta da 450bit ad almeno=20

e il software dovrebbe farsi carico anche della lettura e rispedizione=20 dei dati dei precedenti.

ciao Claudio_F

Il 12/09/2010 17:06, Claudio_F ha scritto:

Verissimo, però il trenino di micro eviterebbe di dover assegnare a ciascuno un indirizzo.

Marco

Il 12/09/2010 17:05, F. Bertolazzi ha scritto:

Questo è buono. Però 16 micro, che magari viaggiano a 1 MHz (riducendo la frequenza di trasmissione) non è che consumino poi così tanto. Senza contare che una volta trasmessi i dati possono andare in sleep fino alla successiva acquisizione.

Non impossibile ma comunque scomodo. Ci penso su.

Visto che come dicevo probabilmente anche 8 bit sono sufficienti, forse è troppo penare anche a separare le alimentazioni.

Il thread è comunque molto interessante. Ho parecchio materiale su cui rimuginare. Poi farò una scelta. Che sarà quella sbagliata :o)

Ancora? Ma ormai mi sembra abbastanza chiaro! Se manca qualche dettaglio chiedi, ma mi sembra di avere spiegato cosa deve fare sta scheda :/

Marco

Marco Trapanese ha scritto:

Se e' per avere il software uguale non basta cablare l'indirizzo su 4=20 pin? Fammi indovinare, non hai 4 pin da usare :)

Claudio_F

Marco Trapanese:

Dopo aver ritrasmesso i dati dei predecessori. E, andando in sleep, cambiano assorbimento, generando quindi una variazione di corrente, che, come sai, è il modo per generare radiazioni elettromagnetiche.

A me per nulla. Cosa leggono i 128 fotodiodi?

Claudio_F:

Facciamo almeno nove. Ogni slave legge 8 fotodiodi.

Per nulla. Col "trenino" non solo hai il vantaggio che la linea dati è lunga pochi centimetri anziché un metro e mezzo, ma risparmi il byte di interrogazione ed il byte di risposta, aggiungendo uno solo bit (per la precisione un byte ogni otto) per il "token".

Questo sempre che non si rinunci a uno dei possibili valori di lettura, nel qual caso quel valore sarà il token e sarà un solo byte in coda a tutte le letture.

Claudio_F:

Anche se li avesse, sarebbe una rottura paragonabile al customizzare il software. Tra parentesi, quasi tutti gli AVR (senz'altro i tiny25) hanno qualche centinaio di byte di EEPROM. Ma, dato che è una rete fissa ed immutabile, ci sono mille modi per fare a meno di programmare l'indirizzo.

Il 12/09/2010 17:46, F. Bertolazzi ha scritto:

Luce solare.

Marco

Marco Trapanese:

Non è detto: se, invece di tutte le letture, vuoi solo i valori cambiati, devi prefissarli con un indirizzo. Ma la catena se lo può calcolare da sola.