Ardu-Aquarium Controller v. 3.3.1

Ed eliminando i2c andando totalmente su onewire ?
Esistono tante periferiche onewire

ottima soluzione anche quella, perdiamo "l'accelerazione hardware" (e quindi è anche più pesante il codice essendo tutto implementato in software), ma ne guadagnamo in affidabilità (credo, non so se le librerie one-wire supportano l'hot-plug o si impallano come la Wire di arduino)

@Lesto.
Non credo che chi abbia un acquario attacchi e stacchi le periferiche in continuazione.
Basta farle riconoscere all'accensione, non serve l'innesto a caldo.

e invece serve perchè in caso di problemi tipo un sensore che si frigge, un disturbo, una botta al conntettore etc... il resto dei sensori continua a funzionare. (e magari viene mostrato un allarme)
In oltre permette l'upgrade senza dover riavviare l'apparato

Ricordatevi che è una cosa che deve stare accesa 24h su 24h, quindi cresce la possibilità di fail sui BUS esterni.. e nel caso Wire un errore del genere impalla tutto l'arduino.

lesto:
...
Ricordatevi che è una cosa che deve stare accesa 24h su 24h, quindi cresce la possibilità di fail sui BUS esterni.. e nel caso Wire un errore del genere impalla tutto l'arduino.

Il che potrebbe portare ad un risultato secondario anche piu indesiderato di un blocco hardware ... mi riferisco al costo di un'eventuale "fritto misto" nel caso si impallasse il sistema di riscaldamento ... specie se usato per un'acquario marino :fearful: (non so se tutti quanti hanno un'idea di cosa costano, gli "ospiti marini" di quella scatoletta di vetro :stuck_out_tongue: XD XD XD)

Se mai dovessi fare un'acquario marino, mi verrebbe voglia di usare doppi sensori con cicli di controllo incrociato ... :stuck_out_tongue: :smiley:

No problem per eventuali malfunzionamenti...
--> Sushi!! :grin:

PaoloP:
No problem per eventuali malfunzionamenti...
--> Sushi!! :grin:

Ti passo subito il menu ...

Antipasto, cubetti di Zebrasoma Rostratum in gelatina : sui 700 Euro
Primo, zuppa di Chaetodontoplus Conspicillatum : sui 1500 Euro
Secondo, filetti di Centropyge Boiley : sui 5000 Euro l'uno
... e come dessert, una coppia di Genicantus alla panna, intorno ai 30.000 Euro ...

non male come sushi ... ce l'hai il mutuo ? :stuck_out_tongue: :fearful: ]:smiley:

lesto:
ok, se vogliamo rivedere il codice partiamo dalla sua architettura.
Propongo di fare tutto i2c, ma grazie al sistema modulare non sarà un problema sostituire dei sensori con altri fintantochè si sappia programmare uno schetch per quel sensore.
Puoi fare un elenco dei sensori che possiedi, cosa intendi misurarci, tipo di interfaccia e costo.
Aggiungi a parte altre misurazioni che vorresti fare (non è importante scegliere un sensore a priori), io sono disposto a fare un oridine di alcuni (se non tutti) i sensori per poterti seguire con il codice e i test
fai conto che io ho una UNO e due Micro, non ho intenzione di prendere una MEGA(magari prendo un 644 o quel che l'è), quindi mi oppurerò di essere il più possibile "retrocompatibile"
Quindi ci serve: un elenco di sensori per metterci tutti d'accordo, un elenco di TUTTE le misure da fare (anche quelle in fututo aiuta assai).
Per l'elenco io sceglierei di nonandare tanto sull'economico, ma piuttosto cercare di prenderli tutti da un unico rivenditore.

Lesto,
grazie davvero per la tua offerta, la apprezzo veramente tanto e quindi ti rispondo che attualmente gli unici sensori che possiedo sono gli one-wire ds18b20 per la temperatutura e l'E-tape per il livello dell'acqua che gia conosci e per il quale su tua indicazione ho fatto già uno scatafascio di letture, ma che poi ho momentaneamente abbandonato perché stavamo rivedendo tutto il codice.
Non ho ancora preso nulla per ph e conducibilità su questo quindi si può discutere.
Eliminare la ONE-WIRE e la Dallas-temperature, sarebbe un bel risparmio di ram e flash, dopo averti letto, ho trovato ed ordinato LM77 per la temperatura e lmp91200 LMP91200 data sheet, product information and support | TI.com per il PH...
Vado un pò più nello specifico e ti dico le lie considerazioni:

Temperatura: come già detto ho i DS18B20 comodissimi, si trovano gia impermeabilizzati non vanno tarati, li leggi facilmente grazie alla bella libreria <DallasTemperature.h>, ma per usarla va implementata anche la <OneWire.h> e si ciucciano insieme una fraccata di flash, con LM77 LM77 data sheet, product information and support | TI.com passeremmo se riuscissimo ad usarlo al solo uso dell'I2c, ma vanno impermeabilizzati, hanno bisogno di almeno 4 fili o 5 se li usiamo anche come comparatori (cosa che mi piacerebbe fare) ed intendessimo usare anche l'INT del chip, rendono obbligatorio l'uso del bus extender...
Si tratta quindi di passare da una cosa sicuramente funzionate ed easy come vorrebbe essere tutto questo progetto pensato non solo per un acquario di base, ma anche per i princianti come me, ad una cosa sicuramente più sofisticata e performante a livello di codice, ma decisamente molto meno accessibile ai principianti...

I sensori di livello li leggiamo comodamente in analogread(), sono questi: http://www.milonetech.com/uploads/eTape_Datasheet_12110215TC-8_040213.pdf, grazie al buon/paziente Menniti, è stato messo a punto un circuitino che con una semplice taratura permette di leggere anche quelli che non rientrano nelle specifiche del datasheet, permettono la lettura in continuo del livello e li trovo al momento i migliori perchè possono essere usati, non solo per i cambi dell'acqua, ma anche per il ripristino in continuo del livello dell'acqua e grazie al circuitino di cui sopra, sono di una precisione senza pari al momento...

li ho letti molto semplicemente con questo codice:

byte levelsensor = A0; 
void setup() {
   Serial.begin(9600);
   analogReference(INTERNAL);
}
void loop() {
  Serial.println(analogRead(levelsensor));
  delay(50);
}

I dati rilevati sono quì: Prove sensori di livello - Google Sheets nel foglio 2, ma non li ho più toccati sia per i motivi che ho già detto sià perché non ho capito bene come vadano usati/interpretati... ti va di riprendere il discorso?

Per il PH il chip che ha trovato Leouz, mi sembra molto figo, ma si legge in seriale, tutto un'altro protocollo, mentre avendo in mano una sonda, credo sia possibile leggerla anch'essa in analogread() usando anche quì un bell'amplificatorino di segnale, aggiungo, ma qui serve un vero esperto, dovendo queste sonde essere tarate con l'uso di vari liquidi, mi chiedo se sia possibile farlo automaticamente via software immergendo la sonda nel liquido ed agendo su un potenziometro digiltale :sweat_smile:, oltre tutto dovremmo usare sonde per letture in contiuno, ovvero sempre immerse.

Per la conducibilità anche quì mi domando se non sia possibile ragionare come per il PH.

Quindi ricapitolando, al momento per il controller base, gli obiettivi sono:

  • Controllo completo della plafoniera (direi che siamo al 90%)
  • Controllo della temperatura fatto(stiamo per stravolgere tutto :astonished:)
  • Lettura del PH con eventuale controllo di un'elettrovalvole per il dosagio della CO2
  • Lettura della Conducibilità

Testato:
Ed eliminando i2c andando totalmente su onewire ?
Esistono tante periferiche onewire

Ciao Testato
Con OneWire si può pilotare anche il display?

lesto:
ottima soluzione anche quella, perdiamo "l'accelerazione hardware" (e quindi è anche più pesante il codice essendo tutto implementato in software), ma ne guadagnamo in affidabilità (credo, non so se le librerie one-wire supportano l'hot-plug o si impallano come la Wire di arduino)

PaoloP:
@Lesto.
Non credo che chi abbia un acquario attacchi e stacchi le periferiche in continuazione.
Basta farle riconoscere all'accensione, non serve l'innesto a caldo.

lesto:
e invece serve perchè in caso di problemi tipo un sensore che si frigge, un disturbo, una botta al conntettore etc... il resto dei sensori continua a funzionare. (e magari viene mostrato un allarme)
In oltre permette l'upgrade senza dover riavviare l'apparato
Ricordatevi che è una cosa che deve stare accesa 24h su 24h, quindi cresce la possibilità di fail sui BUS esterni.. e nel caso Wire un errore del genere impalla tutto l'arduino.

Per ciò che riguarda l'hotplug, che controindicazioni ci sono ad un eventuale reset della scheda?
Già il sofware delle luci è fatto per ovviare aquesta eventualità.
In caso di Upgrade, se è hardware, è chiaro che va caricato anche l'eventuale sofware che lo gestisce, quindi in qualche modo la scheda va riavviata, idem con l'hot plug, cosa c'è di contropoducente in un reset della scheda?
Ma nel caso di arduino che si impalla, non esiste un modo per autoresettarlo?
Perdonatemi se faccio domande a vacca, ma sapete già che le mie sono domande dettata da scarsa preparazione, però vi prego, aiutatemi a capire.

Etemenanki:

PaoloP:
No problem per eventuali malfunzionamenti...
--> Sushi!! :grin:

Ti passo subito il menu ...
Antipasto, cubetti di Zebrasoma Rostratum in gelatina : sui 700 Euro
Primo, zuppa di Chaetodontoplus Conspicillatum : sui 1500 Euro
Secondo, filetti di Centropyge Boiley : sui 5000 Euro l'uno
... e come dessert, una coppia di Genicantus alla panna, intorno ai 30.000 Euro ...
non male come sushi ... ce l'hai il mutuo ? :stuck_out_tongue: :fearful: ]:smiley:

Capperi Etemenanki, conosci la materia a quanto pare :astonished:, ma è chiaro che volutamente un controller base per un acquario easy, esclude per forza di cose un acquario marino con quel tipo di fauna... Cio non toglie che la vita dei poveri pesciolini qualunque sia il loro valore mi sta a cuore, solo non riesco a capire con

Etemenanki:
Se mai dovessi fare un'acquario marino, mi verrebbe voglia di usare doppi sensori con cicli di controllo incrociato ... :stuck_out_tongue: :smiley:

Che metodo è questo? come funziona concettualmente parlando?

Grazie a tutti.
Riccardo

riciweb:
Ma nel caso di arduino che si impalla, non esiste un modo per autoresettarlo?

Usa il "CaneDaGuardia". :wink:

--> http://www.logicaprogrammabile.it/arduino-resettare-automaticamente-la-scheda-utilizzando-il-watchdog-timer/

riciweb:
...

Etemenanki:
Se mai dovessi fare un'acquario marino, mi verrebbe voglia di usare doppi sensori con cicli di controllo incrociato ... :stuck_out_tongue: :smiley:

Che metodo è questo? come funziona concettualmente parlando?
...

Non sono un'acquariofilo, ne ho il posto a casa per tenerci un'acquario, ma ho un'amico che e' "leggermente" maniaco per il marino (gli ho dato una mano a costruirsi un paio di vasche sui 550/600 litri, entrambe marine, e un po per la parte hardware), per cui un po di informazioni le ho ... non ha pesci da 30.000 Euro la coppia, ma in media ogni volta che fa un'aggiunta, lascia in negozio qualche centinaio di Euro :stuck_out_tongue: :smiley:

Il sistema a ridondanza comporta semplicemente l'usare sensori doppi, ed eseguire la lettura sui vari cicli integrando i valori e discriminando quelli "illogici" ... ad esempio, se hai 2 sonde di temperatura in 2 punti diversi, ogni volta che le leggi, confronti le 2 letture ... se lo carto e' entro una tolleranza programmata (mettiamo 1 grado, per fare un'esempio", fai la media dei valori e la usi come lettura, se lo scarto inizia ad essere maggiore della tolleranza (ad esempio, una delle sonde va in corto e ti restituisce 0 gradi, o simile), oltre ad accendere un'allarme, escludi la lettura della sonda che risulta illogica.

Il sistema migliore sarebbe avere almeno 3 sonde, in questo modo avresti la (quasi) certezza di individuare con precisione quella guasta ... esempio, con 2 sonde, se una ti da 27 ed una 31, non c'e' modo sicuro per discriminare quale delle due e' imprecisa, specie se entrambe continuano a dare dati coerenti (entrambe salgono o scendono insieme ... se invece una si bloccasse e l'altra continuasse a variare, sarebbe possibile discriminare quella bloccata, che non cambia piu nel lungo periodo) ... con 3 sonde, il problema non si pone cosi difficile, se una da 27, l'altra 28, e la terza 34, e' chiaramente quella che si scosta di piu da escludere dal ciclo delle medie di lettura :wink: ... oltretutto non costano cosi care, e sarebbe fattibile abbastanza facilmente, per impermeabilizzarli basta un po di resina per barche bicomponente :wink:

A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia ... personalmente per trasferire dati analogici preferirei i current-loop, anche se poi ci si deve creare una scheda di conversione da corrente a tensione per poterli leggere, perche' quello standard e' stato realizzato per uso industriale ed e' abbastanza affidabile, anche se richiede almeno un doppino per ogni sensore (ma ripeto, e' una preferenza personale)

mi piace l'idea dei 3 sensori

A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia

questo avviene perchè sono state sviluppate male le libreire (bloccanti e senza gestione degli errori), non a caso tempo fa modificai la Wire per essere non bloccante, e quindi supportare errori sulla linea/hotplug unplug di sensori, ovviamente se previsti lato software, altrimenti sono ignorati

anche l'idea della current-loop, che ammetto di non conoscere (non capisco perchè tu parli di segnali analogici, ho cercato qualcosa ma si parla di segnali digitali, in particaolre seriali), mi pace, se dimostra di essere a prova di disturbi anche su un metro di cavo volante.
il grosso vantaggio dell'analogico è che ogni sensore sarebbe su un pin separato, e quindi se si rompe inserendo una corrente "pazza" non serve escluderlo (se invece un sensore inizia a mandare segnali a caso sul bus i2c o one-wire, bisogna disaccoppiare i sensori riattivandli uno a uno fino ad individuare la causa..)

mettere più atmega in parallelo è semplice in tutti i casi (digitali o analogici), forse nei digitali una seriale è meglio perchè è più facile "sniffare" i dati in entrambe le direzioni ache se l'arduino non è il master del bus, e quindi verificare che l'output dell'atmega in master sia corretto e allineato con quello calcolato anche dagli arduiono dormienti... :grin:

Piu che alle librerie, mi riferisco a guasti fisici ai sensori ... ad esempio, in un bus in cui tutti i segnali sono in parallelo, se una delle uscite va a massa, crea problemi a tutto quello che c'e' connesso in parallelo a quell'uscita ...

Il current loop si puo usare per trasferire valori analogici (un'uscita che varia proporzionalmente da 4mA, equivalente a zero volt di uscita, a 20mA, equivalente a fondo scala), sia digitali (modulando l'uscita come una linea seriale a due fili, solo che e' in corrente invece che in tensione) sia addirittura entrambi insieme (il protocollo HART usa la sovrapposizione di due toni FSK sulla corrente del dato analogico per trasmettere contemporaneamente un valore analogico ed uno stream digitale sullo stesso doppino) ... la robustezza della trasmissione e' garantita dal fatto che il sistema e' un'anello chiuso in cui scorrono sempre da 4 a 20 mA, indipendentemente dalla lunghezza del cavo, o dai contatti osidati (fino ad un certo punto, ovviamente :P) ... potresti avere un doppino da un metro o da 100 metri, se l'interfaccia e' fatta come si deve, sempre da 4 a 20 mA ci passano :wink: ... poi ci sono anche sistemi multipunto in cui ogni sensore ha un codice e comunica in digitale, ma non ne conosco lo standard ... ed il vantaggio e' che se ad esempio un'uscita va in corto, il sistema si autoregola per riportare i corretti valori di corrente ed al massimo e' quel sensore che non ti va piu (ed a quel punto arduino potrebbe segnalare un'allarme del tipo "sensore "X" non funzionante), ma il resto continua a funzionare.

Ovvio che se il filo si stacca e l'anello si apre non funziona piu nulla, ma quello lo fa con qualsiasi altra configurazione :stuck_out_tongue: ... a meno di non usare degli splitter, ma costano uno sproposito :fearful:

riciweb:
Ciao Testato
Con OneWire si può pilotare anche il display?

ho visto farlo sia via shift register che con ulteriore micro dedicato. considera che pur sempre un altro chip devi usare, anche con i2c useresti un chip intermedio tra il bus ed il display. E' anche vero pero' che esistono display COG che sono direttamente I2C (vedi mia firma), non ne ho visti invece direttamente OneWire per ora.
Ma ripeto, se la tua idea e' usare un display standard a cui aggiungere un chip allora i componenti da usare restano numericamente uguali. Io pero' non l'ho mai fatto, sarebbe interessante approfondire, se decidete di andare verso questa strada fo qualche prova anche io
http://mbed.org/cookbook/1-wire-shifting-2x16-LCD

PaoloP:
Usa il "CaneDaGuardia". :wink:

--> http://www.logicaprogrammabile.it/arduino-resettare-automaticamente-la-scheda-utilizzando-il-watchdog-timer/

Grazie Paolo,
ho letto, mi piace e sicuramente se ne terrà conto.

Etemenanki:
...
Il sistema a ridondanza comporta semplicemente l'usare sensori doppi, ed eseguire la lettura sui vari cicli integrando i valori e discriminando quelli "illogici" ... ad esempio, se hai 2 sonde di temperatura in 2 punti diversi, ogni volta che le leggi, confronti le 2 letture ... se lo carto e' entro una tolleranza programmata (mettiamo 1 grado, per fare un'esempio", fai la media dei valori e la usi come lettura, se lo scarto inizia ad essere maggiore della tolleranza (ad esempio, una delle sonde va in corto e ti restituisce 0 gradi, o simile), oltre ad accendere un'allarme, escludi la lettura della sonda che risulta illogica.

Il sistema migliore sarebbe avere almeno 3 sonde, in questo modo avresti la (quasi) certezza di individuare con precisione quella guasta ... esempio, con 2 sonde, se una ti da 27 ed una 31, non c'e' modo sicuro per discriminare quale delle due e' imprecisa, specie se entrambe continuano a dare dati coerenti (entrambe salgono o scendono insieme ... se invece una si bloccasse e l'altra continuasse a variare, sarebbe possibile discriminare quella bloccata, che non cambia piu nel lungo periodo) ... con 3 sonde, il problema non si pone cosi difficile, se una da 27, l'altra 28, e la terza 34, e' chiaramente quella che si scosta di piu da escludere dal ciclo delle medie di lettura :wink: ... oltretutto non costano cosi care, e sarebbe fattibile abbastanza facilmente, per impermeabilizzarli basta un po di resina per barche bicomponente :wink:
A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia ... personalmente per trasferire dati analogici preferirei i current-loop, anche se poi ci si deve creare una scheda di conversione da corrente a tensione per poterli leggere, perche' quello standard e' stato realizzato per uso industriale ed e' abbastanza affidabile, anche se richiede almeno un doppino per ogni sensore (ma ripeto, e' una preferenza personale)

Già ora usiamo due sonde, di cui mediamo le letture e le confrontiamo affinche si rimanga all'interno di un certo range di temperatura (+/- 1,5°attualmente) con allarme sia visivo che sonoro, quello che non viene fatto perché non ci avevo proprio pensato è verificare quale sonda va in palla ed escluderla... un to do sicuramente.

lesto:
mi piace l'idea dei 3 sensori

A livello personale escluderei qualsiasi bus tipo "onewire", e concettualmente anche l'I2C, mettendo forse piu cavi, ma non rischiando blocchi generali dovuti alla frittura di un singolo sensore o interfaccia

questo avviene perchè sono state sviluppate male le libreire (bloccanti e senza gestione degli errori), non a caso tempo fa modificai la Wire per essere non bloccante, e quindi supportare errori sulla linea/hotplug unplug di sensori, ovviamente se previsti lato software, altrimenti sono ignorati

anche l'idea della current-loop, che ammetto di non conoscere (non capisco perchè tu parli di segnali analogici, ho cercato qualcosa ma si parla di segnali digitali, in particaolre seriali), mi pace, se dimostra di essere a prova di disturbi anche su un metro di cavo volante.
il grosso vantaggio dell'analogico è che ogni sensore sarebbe su un pin separato, e quindi se si rompe inserendo una corrente "pazza" non serve escluderlo (se invece un sensore inizia a mandare segnali a caso sul bus i2c o one-wire, bisogna disaccoppiare i sensori riattivandli uno a uno fino ad individuare la causa..)
mettere più atmega in parallelo è semplice in tutti i casi (digitali o analogici), forse nei digitali una seriale è meglio perchè è più facile "sniffare" i dati in entrambe le direzioni ache se l'arduino non è il master del bus, e quindi verificare che l'output dell'atmega in master sia corretto e allineato con quello calcolato anche dagli arduiono dormienti... :grin:

Etemenanki:
Piu che alle librerie, mi riferisco a guasti fisici ai sensori ... ad esempio, in un bus in cui tutti i segnali sono in parallelo, se una delle uscite va a massa, crea problemi a tutto quello che c'e' connesso in parallelo a quell'uscita ...
Il current loop si puo usare per trasferire valori analogici (un'uscita che varia proporzionalmente da 4mA, equivalente a zero volt di uscita, a 20mA, equivalente a fondo scala), sia digitali (modulando l'uscita come una linea seriale a due fili, solo che e' in corrente invece che in tensione) sia addirittura entrambi insieme (il protocollo HART usa la sovrapposizione di due toni FSK sulla corrente del dato analogico per trasmettere contemporaneamente un valore analogico ed uno stream digitale sullo stesso doppino) ... la robustezza della trasmissione e' garantita dal fatto che il sistema e' un'anello chiuso in cui scorrono sempre da 4 a 20 mA, indipendentemente dalla lunghezza del cavo, o dai contatti osidati (fino ad un certo punto, ovviamente :P) ... potresti avere un doppino da un metro o da 100 metri, se l'interfaccia e' fatta come si deve, sempre da 4 a 20 mA ci passano :wink: ... poi ci sono anche sistemi multipunto in cui ogni sensore ha un codice e comunica in digitale, ma non ne conosco lo standard ... ed il vantaggio e' che se ad esempio un'uscita va in corto, il sistema si autoregola per riportare i corretti valori di corrente ed al massimo e' quel sensore che non ti va piu (ed a quel punto arduino potrebbe segnalare un'allarme del tipo "sensore "X" non funzionante), ma il resto continua a funzionare.
Ovvio che se il filo si stacca e l'anello si apre non funziona piu nulla, ma quello lo fa con qualsiasi altra configurazione :stuck_out_tongue: ... a meno di non usare degli splitter, ma costano uno sproposito :fearful:

Mi piace leggervi e di fatto poi passo le giornate a googlare cercando, con scarso successo devo ammettere :blush:, di capirvi, il fatto è che così si stravolge la filosofia di tutto il progetto che poi rispecchia anche la mia attuale conoscenza di questo mondo...
Vorrei che tutto rimanesse molto easy, continuo a pensare che la vera sfida sia riuscire con Arduino UNO a fare tanto con poco e nel modo più semplice possibile...
Più avanti col tempo ci sarà sicuramente spazio per creare "Ardu-Acquarium Controller ++" ovvero più sofisticati con interfacce più avanzate e periferiche più performanti, ho in testa anche io così tante idee che non stò neanche a scrivere, ma così ho paura che non si arrivi o non si riesca a concludere.
Ho bisogno di aiuto, ma voi andate troppo avanti e troppo veloci "gna posso fa'..." oltre tutto, non so nemmeno se con arduino si possono fare tutte le cose che scrivete senza mandarlo in palla, è pur sempre un atmega328 bho... scrivo di cose che non conosco bene scusatemi :smiley:

Testato:
ho visto farlo sia via shift register che con ulteriore micro dedicato. considera che pur sempre un altro chip devi usare, anche con i2c useresti un chip intermedio tra il bus ed il display. E' anche vero pero' che esistono display COG che sono direttamente I2C (vedi mia firma), non ne ho visti invece direttamente OneWire per ora.
Ma ripeto, se la tua idea e' usare un display standard a cui aggiungere un chip allora i componenti da usare restano numericamente uguali. Io pero' non l'ho mai fatto, sarebbe interessante approfondire, se decidete di andare verso questa strada fo qualche prova anche io
http://mbed.org/cookbook/1-wire-shifting-2x16-LCD

Te lo chiedevo, perché si sta discutendo se fare tutto I2C o tutto One-Wire, è chiaro che serve un'altro chip in ogni caso, ma non sapevo se fosse una strada già percorsa da qualcuno, però grazie del tuo interessamento.

Ciao e grazie a tutti.

Riccardo

riciweb:
...il fatto è che così si stravolge la filosofia di tutto il progetto ...

Be', stravolgere i progetti altrui e' uno dei pochi, piccoli divertimenti che questa vita oppressiva e noiosa qualche rara volta ci consente ... non vorrai mica essere cosi crudele e senza cuore da negarci anche queste rare, piccole soddisfazioni, vero ? ... ]:smiley:

(scherzo, ovviamente :stuck_out_tongue: XD XD XD)

Non sia mai che io tolga divertimento e sollazzo a chicchessia :astonished: :astonished: :astonished:
Piuttosto ti ringrazio per avermi spinto a conoscere ed imparare (fai finta di crederci ti prego :blush:) nuove metodologie!!!
Rimane il fatto che alla fine faccio cmq. come mi pare ]:smiley: ]:smiley: ]:smiley:

Byeee!!!

Riccardo

Ok, fingero' di crederci (ma solo per farti un piacere :stuck_out_tongue: :D)

riciweb:
Rimane il fatto che alla fine faccio cmq. come mi pare ]:smiley: ]:smiley: ]:smiley:

E ci mancherebbe pure il contrario :wink: XD

oddio mi avete fattoscompisciare :grin:

Arrieccomi!!!

allora, a casa avevo ho un DS18B20 waterproof (che poi ho scoperto essere il sensore che usate), e l'ho usato senza la libreria dallas, ma solo quella OneWire. Allego il codice, magari vi a risparmiare qualche prezioso byte in flash: funziona in modalità parassita, ovvero GND e VCC collegati a GND, e il cavo dati sul pin 9 + pull-up di 4,7K (io uso 2 in serie da 2.2K, quindi 4.4K, senza problemi), dovrebbe funzionare con qualsiasi risoluzione, ma lascia quella di default (12bit), che permette una lettura ogni 750ms al massimo.

Notare che si tratta di una versione rivista di quella per il ds18S20 (notare la S) che è presente sul playground

#include <OneWire.h>

/* DS18B20 Temperature chip i/o */

OneWire  ds(9);  // on pin 9
#define MAX_DS1820_SENSORS 2
byte addr[MAX_DS1820_SENSORS][8];
void setup(void) 
{
  Serial.begin(9600);
  delay(1000);

  Serial.println("DS18B20 Test");

  for (int i=0;i<MAX_DS1820_SENSORS;i++){
    if (!ds.search(addr[i])) 
    {
      Serial.println("No more addresses.");
      ds.reset_search();
      delay(250);
      return;
    }
  }

}
int HighByte, LowByte, TReading, SignBit, Tc_100, Whole, Fract;
char buf[20];

void loop(void) 
{
  byte i, sensor;
  byte present = 0;
  byte data[9];

  for (sensor=0;sensor<MAX_DS1820_SENSORS;sensor++)
  {
    if ( OneWire::crc8( addr[sensor], 7) != addr[sensor][7]) 
    {
      Serial.println("CRC is not valid");
      return;
    }

    if ( addr[sensor][0] != 0x28) 
    {
      Serial.print("Device is not a DS18B20: ");
      Serial.println(addr[sensor][0], HEX);
      return;
    }

    ds.reset();
    ds.select(addr[sensor]);
    ds.write(0x44,1);         // start conversion, with parasite power on at the end

    delay(1000);     // maybe 750ms is enough, maybe not
    // we might do a ds.depower() here, but the reset will take care of it.

    present = ds.reset();
    ds.select(addr[sensor]);    
    ds.write(0xBE);         // Read Scratchpad

    for ( i = 0; i < 9; i++) 
    {           // we need 9 bytes
      data[i] = ds.read();
    }

    LowByte = data[0];
    HighByte = data[1];
    TReading = (HighByte << 8) + LowByte;

    Serial.print("Temperaura: ");
    Serial.println(TReading/16.0);    
    
    Serial.print("Configuration: ");
    Serial.println(data[4], BIN);
  }
}

Grazie Lesto,
appena ho un minuto ci gioco un pò.

Riccardo