Ardu-Aquarium Controller v. 3.3.1

lesto: ma scusate con questo sistema l'acquario diventa praticamente indipendente? se no cosa manca? se non erro bisogna gestire la temperatura, l'ossigenazione, il ricircolo dell'acqua, la salinazione, il rilascio del cibo... poi?

edit: le luci

Questo progetto, nella mia testa ha diversi scopi, il primo in assoluto è rendere la gestione di un acquario il più possibile semplice e facile, premesso ciò, qualunque acquariofilo di esperienza ti può dire che i parametri da tenere sotto controllo in acquario e le cose che è possibile automatizzare, sono innumerevoli, di fatto in effetti gli acquari che richiedo la maggior competenza, il maggior numero di cose da controllare ed automatizzare, sono gli acquari marini, ma non è a tanto che questo progetto vuole arrivare, di fatto alla fine del percorso, questo sara un controller per un acquario base o se vuoi un "Hello world" dell'automazione degli acquari", quindi arrivati al controllo completo della plafoniera, del ph, della conducibilità e all'automazione dei cambi dell'acqua ecco che l'acquariofilo avrà la vita molto ma molto più semplice. Cio non toglie che poi chiunque potra prenderlo e personalizzarlo a suo piacere, ad esempio un'altro bel controllo da fare sarebbe sulla portata del ritorno in acqua dal filtro per monitorare lo stato di intasamento delllo stesso e manutenzionarlo solo se necessario... potrei andare avanti decine di pagine ad elencarti cose che si possono fare in un acquario...

[quote author=Michele Menniti link=topic=141419.msg1264344#msg1264344 date=1370266332] come 4k di bootloader, di che Arduino stai parlando? [/quote]

leo72: [quote author=Michele Menniti link=topic=141419.msg1264344#msg1264344 date=1370266332] come 4k di bootloader, di che Arduino stai parlando?

Quoto. Solo sull'Arduino MEGA il bootloader occupa 4 kB, sulla vecchia 2009 ne occupava 2 mentre sulla UNO ne occupa solo 0,5. [/quote]

Devo sempre scrivere qualche Riccardata, ma in questo caso sono contento di averla scritta così grazie a voi ho corretto un mia convinzione sbagliata :blush:, o mi è rimasta in testa la reference del Leonardo o non so che dire, in ogni caso è un vero sollievo scoprire che il bootloader sulla UNO è 0,5k scusate maaaa doppio wau carpiato con avvitamentooooooo XD XD XD XD Pensavo di essere messo maluccio, non che ora abbia da scialare, ma va molto meglio!!!

Scusatemi :blush:

Riccardo

Sì, anche la Leonardo ha un bootloader da 4 kB.

Chiedo scusa :~, ma nel revisionare lo sketch, mi sono sfuggiti alcuni errorini (non che non ce ne siano altri ma questi erano scandalosi), quindi riposto il file depurato dal buon “Leouz” anche da alcuni while bloccanti.
Con l’occasione ringrazio anche “danidiscus”, “Dandovino” ed a breve anche “cmarcello”, che sono sempre lì pronti a testare le mie cialtronate… :grin:

PS: Ho sostituito i file anche nei post precedenti, scusate ancora :blush:.

acquarium_controller_v_3.ino (43.8 KB)

leo72: [quote author=Michele Menniti link=topic=141419.msg1264344#msg1264344 date=1370266332] come 4k di bootloader, di che Arduino stai parlando?

Quoto. Solo sull'Arduino MEGA il bootloader occupa 4 kB, sulla vecchia 2009 ne occupava 2 mentre sulla UNO ne occupa solo 0,5. [/quote] appunto e la MEGA avrebbe 128 o 256k di memoria.... quindi quei 4k diverrebbero ininfluenti ;)

riciweb: PS: Ho sostituito i file anche nei post precedenti, scusate ancora :blush:.

l'mportante è che aggiorni la versione nel primo post, è lì che la magior parte della gente andrà a cercare ps. ora ci butto un occhio :)

edit: uhmm il codicemi pare buono, non ho trovato cose ottimizzabili al volo. Do qualche consiglio, liberi di fare ciò che volete: 1. formattate meglio il codice 2. dividete il codice in vari file, meglio se uno per sensore. 3. il main rimane come semplice logica pura, che legge i dati da un'array di strutture (in questo modo lastruttura può essere "alimentata" da eeeprom, SD, seriale, LCD+tastierino... insomma qualsiasi cosa) 4. la Wire, in caso di errore, è bloccante. tempo fa la riscrissi in modo non bloccante, ma in rete ce ne sono varie implementazioni già pesantemente testate 5. riducete al minimo le tipologie differenti di standard, per occupare meno spazio e avere meno codice possibilimente in errore. Io starei su sensori i2c. un altro test è staccare "al volo" i componenti, vedere se il tutto supporta il problema, riattaccarli, e vedere se riparte. Sono casi rari disturbi elettromagentici così forti, ma considerado che il vostro progetto è fatto per restare acceso 24h su 24h per 365gg all'anno... 6. attenzione agli overfglow dei timer, anche della millis()

per esempio riga 129 (dallealtre parti sembrerebbe ok):

if (ArrayVariabiliTasti[Indice].ValoreTasto == true && (((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 250))) || ((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 10)) && ArrayVariabiliTasti[Indice].TastoPremuto == false)))

andrà in errore all'overflow, con imprevedibili risltati sistemala con

if (ArrayVariabiliTasti[Indice].ValoreTasto == true && 
    (
        millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 250
    || 
        (
            millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 10 
            && ArrayVariabiliTasti[Indice].TastoPremuto == false
        )
    )
)
  1. per la gestione plafo, non è più semplice creare una funzione lineare (y = m*x+q) con valori settabili? dove x è il numero di minuti a partire dalla data di accensione/spegnimento, e y il valore delle luci. Trovare m e q è semplice sopratutto considerando che molto probabilmente avrete sempre q=0.(q è il valore minimo delle luci), in questo modo conservate la data di inizio, magari in secondi dal 1970 (timestamp, che spesso gli RTC calconano tranquillamente), che quindi occupa solo 4 byte (chiamiamola S), e 2 byte (un intero usigned è sufficiente per 65536 secondi, pari a 18 ore) per memorizzare la durata del fading in secondi (chiamiamola D), più un byte per valore fading iniziale a S e valore di fading finale a D, che poi il priomo byte si può risparmiare essendo il vecchio valore di D: infatti il fading è un array ciclico. quindi a partire da S avrete X=0 e y= valore attuale delle luci (accese o spente), e a S+D avrete x = D e y= valore finale delle luci
  2. al posto di controllare ad ogni ciclo l'RTC, potete impostarlo come "sveglia". Potreste fare che ogni azione da eseguire è shedulata in un apposita struttura con timestamp di esecuzione e comando/funzione da richiamare. In questo modo, viene semplice calcolare il numero di secondi per eseguire la prossima operazione, impostare la sveglia sull'RTC, e mandare il micro "a nanna". ovvio che il pin di risveglio sarà collegato anche alla tastiera (magari però su un pin diverso, non so se si può ascoltare più pin). Così risparmiate un sacco di batteria, e analizzando lo scheduler vi accorgete se qualche istruzione và "fuori posto"!

magari butto giù qualcosa io, ma non avendo un RTC dovrete darmi supporto.

complimenti per il progetto :)

molto bello!! tempo e soldi permettendo... proverò a replicarlo così da implementare/rimpiazzare quello che ho ora per gestire, sempre con arduino, i led dell'acquario :)

ho alcune domande:

  1. ho trovato su ebay le sonde di temperatura .. e costano circa la metà di quelle che ho trovato negli shop più rinomati; dite che son buone lo stesso?

  2. tutti gli integrati ecc ecc .. da dove li hai presi? ad es. il PCF8574AP non lo trovo da nessuna parte ....

grazie

ps. pensi sia sviluppabile con touchscreen così da eliminare i tasti fisici? :) tipo questo per intenderci: http://www.robot-italy.com/it/itdb02-2-4e-2-4-tft-lcd.html

Se mi permettete... state consumando un sacco di RAM (al momento il consumo statico è di 1391 byte): perché non mettete le stringhe stampate sull'LCD dentro alla funzione F()? Esempio:

lcd.print("IMP. FOTOPERIODO L");

diventa

lcd.print(F("IMP. FOTOPERIODO L"));

lesto: l'mportante è che aggiorni la versione nel primo post, è lì che la magior parte della gente andrà a cercare ps. ora ci butto un occhio :)

Già fatto, ma grazie per avermelo ricordato ;)

lesto: uhmm il codicemi pare buono, non ho trovato cose ottimizzabili al volo. Do qualche consiglio, liberi di fare ciò che volete: 1. formattate meglio il codice 2. dividete il codice in vari file, meglio se uno per sensore. 3. il main rimane come semplice logica pura, che legge i dati da un'array di strutture (in questo modo lastruttura può essere "alimentata" da eeeprom, SD, seriale, LCD+tastierino... insomma qualsiasi cosa)

1) Hai ragione, ma la formattazione quando si usa un’editor esterno è abbastanza ostica ed in uno sketch così lungo l’IDE attuale di Arduino complica la vita, stiamo usando Notepad++, che però usa tabulazioni e spazi in modo diverso dall’IDE ufficiale, aggiungi che ci mettiamo le mani in più persone ed ecco che la formattazione salta, ma mi impegnerò per migliorarla o almeno uniformarla. 2) So che è possibile farlo, ma non so come si fa, imparerò anche questo perché effettivamente sarebbe meglio. 3) Questa sarebbe la conseguenza della divisione in file dello sketch? Non sarebbe male!

lesto: 4. la Wire, in caso di errore, è bloccante. tempo fa la riscrissi in modo non bloccante, ma in rete ce ne sono varie implementazioni già pesantemente testate 5. riducete al minimo le tipologie differenti di standard, per occupare meno spazio e avere meno codice possibilimente in errore. Io starei su sensori i2c. un altro test è staccare "al volo" i componenti, vedere se il tutto supporta il problema, riattaccarli, e vedere se riparte. Sono casi rari disturbi elettromagentici così forti, ma considerado che il vostro progetto è fatto per restare acceso 24h su 24h per 365gg all'anno...

4) Non sapevo di questa cosa, ma mi documenterò. 5) Hai ragione, usare sempre lo stesso standard sarebbe meglio, ma sto cercando dei compromessi adatti anche a principianti come me, non è un caso se tutto il progetto è fatto con cose molto basic, io ho iniziato da zero e vorrei che tutto fosse di facile approccio, ad esempio i sensori di temperatura sono one-wire, comodi ma con una libreria pesantuccia ed allo stesso tempo gli unici digitali che si trovano già in formato water-proof, una valida alternativa potrebbero essere i TI TMP100 http://www.ti.com/product/tmp100 o altri della stessa famiglia, ma non esistono water-proof ed il formato non è certo per principianti, sempre della TI Leouz a trovato quest’altro chip che è fighissimo http://www.ti.com/product/LMP91200 , ma sti formati uno terra terra come me come li usa e soprattutto, saprei farli funzionare??? Ci sono infinite soluzioni, ma il mio livello attuale è troppo basso :(

lesto: 6. attenzione agli overfglow dei timer, anche della millis()

per esempio riga 129 (dallealtre parti sembrerebbe ok):

if (ArrayVariabiliTasti[Indice].ValoreTasto == true && (((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 250))) || ((millis() >= (ArrayVariabiliTasti[Indice].TempoTasto + 10)) && ArrayVariabiliTasti[Indice].TastoPremuto == false)))

andrà in errore all'overflow, con imprevedibili risltati sistemala con

if (ArrayVariabiliTasti[Indice].ValoreTasto == true && 
    (
        millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 250
    || 
        (
            millis()-ArrayVariabiliTasti[Indice].TempoTasto >= 10 
            && ArrayVariabiliTasti[Indice].TastoPremuto == false
        )
    )
)

La parte della lettura dei tasti è da rivedere meglio, grazie per la tua segnalazione, provo subito il tuo codice, ma intendo rivedere meglio tutta la cosa, nel senso che attualmente con la IOexp, sembra che il bus I2C sia spazzolato in continuazione in attesa che venga premuto un tasto, quando in effetti i PCF8574 hanno un piedino INT che segnala appunto le variazioni sui piedini di I/O, leggendo quello, con la wire posso leggere il PCF solo quando serve effettivamente, a breve quindi farò questa modifica...

lesto: 7. per la gestione plafo, non è più semplice creare una funzione lineare (y = m*x+q) con valori settabili? dove x è il numero di minuti a partire dalla data di accensione/spegnimento, e y il valore delle luci. Trovare m e q è semplice sopratutto considerando che molto probabilmente avrete sempre q=0.(q è il valore minimo delle luci), in questo modo conservate la data di inizio, magari in secondi dal 1970 (timestamp, che spesso gli RTC calconano tranquillamente), che quindi occupa solo 4 byte (chiamiamola S), e 2 byte (un intero usigned è sufficiente per 65536 secondi, pari a 18 ore) per memorizzare la durata del fading in secondi (chiamiamola D), più un byte per valore fading iniziale a S e valore di fading finale a D, che poi il priomo byte si può risparmiare essendo il vecchio valore di D: infatti il fading è un array ciclico. quindi a partire da S avrete X=0 e y= valore attuale delle luci (accese o spente), e a S+D avrete x = D e y= valore finale delle luci

Credo di aver capito cosa intendi, ma abbiamo visto ed anche provato a buttare giù altre funzioni simili, il risultato però e che la stessa funzione eseguita in background per tutte tre le linee diventa troppo impegnativa per Arduino che contemporaneamente fa anche altre cose, è per questa ragione che attualmente le luci vengono gestite con due procedure, la prima “Statoluci()”, serve a riallineare Arduino con la gestione delle luci in caso di variazione dei dati o di mancanza di corrente, quando le linee sono in modalità automatica, mentre “GestioneLuci()” che invece cicla continuamente in background, grazie appunto ai dati che eventualmente gli passa “Statoluci()” fa funzionare le luci eseguendo semplici confronti sugli orari e su millis().

lesto: 8. al posto di controllare ad ogni ciclo l'RTC, potete impostarlo come "sveglia". Potreste fare che ogni azione da eseguire è shedulata in un apposita struttura con timestamp di esecuzione e comando/funzione da richiamare. In questo modo, viene semplice calcolare il numero di secondi per eseguire la prossima operazione, impostare la sveglia sull'RTC, e mandare il micro "a nanna". ovvio che il pin di risveglio sarà collegato anche alla tastiera (magari però su un pin diverso, non so se si può ascoltare più pin). Così risparmiate un sacco di batteria, e analizzando lo scheduler vi accorgete se qualche istruzione và "fuori posto"!

magari butto giù qualcosa io, ma non avendo un RTC dovrete darmi supporto.

Ecco qui non so se ho capito bene cosa intendi e se anche fosse non saprei nemmeno da dove cominciare, in più cosa intendi per risparmiare batteria, il controller è alimentato dalla rete domestica…

In ogni caso grazie per il tuo interessamento e per l’offerta di collaborazione, io sono disponibilissimo con il mio RTC.

Grazie Lesto

zioTonino: complimenti per il progetto :) molto bello!! tempo e soldi permettendo... proverò a replicarlo così da implementare/rimpiazzare quello che ho ora per gestire, sempre con arduino, i led dell'acquario :) ho alcune domande: 1. ho trovato su ebay le sonde di temperatura .. e costano circa la metà di quelle che ho trovato negli shop più rinomati; dite che son buone lo stesso? 2. tutti gli integrati ecc ecc .. da dove li hai presi? ad es. il PCF8574AP non lo trovo da nessuna parte .... grazie ps. pensi sia sviluppabile con touchscreen così da eliminare i tasti fisici? :) tipo questo per intenderci: http://www.robot-italy.com/it/itdb02-2-4e-2-4-tft-lcd.html

Ciao zioTonino, Grazie per i complimenti, per i tuoi quesiti, non è facile darti una risposta, io per i miei acquisti uso spesso ebay, anche per i pcf, in alternativa puoi vedere si RS o Distrelec, sulla qualità poi non so proprio che dire, finche non li hai in mano e difficile dirlo… :| Per il touchscreen, come ho già scritto molte volte, il controller anche nella componentistica, vorrei che rimanesse il più basic possibile, se ci fai caso il circuito è fatto quasi tutto con connessioni che trovi anche nell’ ABC - Arduino Basic Connections del grande pighixxx, quello che tu hai linkato è bellissimo, e ci ho pure giochicchiato, ma si beve un mare delle poche risorse di Arduino UNO, quindi per usarlo sei in pratica costretto ad usare un MEGA, magari in futuro tempo permettendo si potrà vedere di fare una versione del controller anche così, ma prima voglio completare questo. La sfida che sto cercando faticosamente di vincere a causa della mia scarsa preparazione è di riuscire fare tanto con poco e nel modo più semplice possibile, ecco perché sono li che limo il codice in continuazione per non consumare tutta la flash della UNO o mi ostino ad usare un LCD 20x4…

leo72: Se mi permettete... state consumando un sacco di RAM (al momento il consumo statico è di 1391 byte): perché non mettete le stringhe stampate sull'LCD dentro alla funzione F()? Esempio:

lcd.print("IMP. FOTOPERIODO L");

diventa

lcd.print(F("IMP. FOTOPERIODO L"));

Grazie del consiglio, e sopratutto permettiti sempre ti prego :) ma così non si consuma più flash? Faro un po’ di prove ad ogni modo.

Grazie a tutti. Riccardo

Allegato c’è lo sketch con l’uso della funzione F().
E’ lo STESSO IDENTICO sketch di qualche post sopra, ma ora la RAM usata è di soli 957 byte, 400 byte in meno!
:stuck_out_tongue:

acquarium_controller_v3_1.ino (50.2 KB)

riciweb: Grazie del consiglio, e sopratutto permettiti sempre ti prego :) ma così non si consuma più flash?

No, il consumo di Flash è identico perché la stringa è sempre salvata in Flash. Quanto tu compili uno sketch che contiene una stringa da stampare su LCD o seriale, il compilatore salva la stringa nel firmware, e questo viene scritto nella Flash. Ciò che fa la differenza è il dopo: usando la funzione F(), che altro non è se non una scorciatoia per gestire i dati in Flash con PROGMEM, la stringa tu la leggi direttamente dalla Flash mentre senza la stringa viene prima copiata in RAM e poi spedita al display o sulla seriale. Quindi occupi anche RAM.

Un'altra ottimizzazione sarebbe quella di gestire le voci del menu sempre da Flash con PROGMEM, riscrivendo un pochino le funzioni per la stampa.

Altra cosa che ho visto è la presenza di diverse porzioni di codice uguale, ad esempio quello per la stampa delle frecce. Fatene una funzione da richiamare dove serve, così recuperate un pò di Flash.

Caspita Leo, ti sei messo a modificare tutto :astonished: grazie davvero!!!

leo72: No, il consumo di Flash è identico perché la stringa è sempre salvata in Flash. Quanto tu compili uno sketch che contiene una stringa da stampare su LCD o seriale, il compilatore salva la stringa nel firmware, e questo viene scritto nella Flash. Ciò che fa la differenza è il dopo: usando la funzione F(), che altro non è se non una scorciatoia per gestire i dati in Flash con PROGMEM, la stringa tu la leggi direttamente dalla Flash mentre senza la stringa viene prima copiata in RAM e poi spedita al display o sulla seriale. Quindi occupi anche RAM.

Ho provato a confrontare le compilazioni ed o visto che utilizzando la funzione F(), hai liberato un bel po di RAM, ma ho pure perso più di 200 byte di flash, credo che alla fine bisognerà forse fare una valutazione su cosa sia meglio mantenere, sull'uso della PROGMEM, in effeti il menù attuale è frutto della rivisitazione di quello che Leouz aveva già fatto usandola, solo che in questo modo, senza appunto includere un'altra libreria, il codice è più leggero, quello che non riesco a capire è perché sia tu che lui insistete sull'utilizzo della flash che è quasi finita o che comunque finirà con l'aggiunta del codice per i cambi dell'acqua, del PH e della conducibilità, preoccupandovi più per la RAM che invece è a circa il 70% dell'utilizzo e con la F() a meno del 50%... Sono molto scarso a nozioni di questo tipo, ma se trovi un minuto ti sarei grato... :)

Riccardo

Ecco qui non so se ho capito bene cosa intendi e se anche fosse non saprei nemmeno da dove cominciare, in più cosa intendi per risparmiare batteria, il controller è alimentato dalla rete domestica…

il fatto che sei su rete domestica non vuol dire che non sprechi corrente :) BTW esattamente come i pulsanti hanno un piedino "int" (che sta per interrupt), la stessa cosa lo hanno molti RTC! Tu imposti una "sveglia" sull'RTC, e lui all'orario prefissato manda il pin ad HIGH, insomma "suona la sveglia".

Attento che con la RAM all'80% è facile iniziare a subire reset per via dello stack che cresce dalla parte opposta. Siete al limite in entrambi i casi.

Essitono vari sensori di temperatura i2c, non so però se già "incapsulati" a tenuta stagna.. non che sia difficile da ottenere.

lesto: BTW esattamente come i pulsanti hanno un piedino "int" (che sta per interrupt), la stessa cosa lo hanno molti RTC! Tu imposti una "sveglia" sull'RTC, e lui all'orario prefissato manda il pin ad HIGH, insomma "suona la sveglia".

Attento che con la RAM all'80% è facile iniziare a subire reset per via dello stack che cresce dalla parte opposta. Siete al limite in entrambi i casi.

Essitono vari sensori di temperatura i2c, non so però se già "incapsulati" a tenuta stagna.. non che sia difficile da ottenere.

Sto usando il DS1307 come RTC e non credo sia fattibile quello che dici, ho googlato un po, ma non ho capito molto, mi pare che il PCF8583 abbia la possibilità di imposare un allarme, non credo ne esistano con più di un allarme impostabile, hai qualche dritta?

C'è da qualche parte qualcosa terra terra per me, per capire come funziona lo stack?

Grazie Riccardo.

il tuo non ha gli allarmi, al massimo crea un onda quadra di frequenza 1Hz…

guarda il DS3232 (http://www.freetronics.com/pages/rtc-real-time-clock-module-quickstart-guide#.Ua3gQpyPDCo)
o il DS1337 (http://forum.arduino.cc/index.php?topic=38077.0)

a te non serve avere più di un allarme: il tuo arduino avarà la tabella degli allarmi, prima di andare a nanna cercherà l’allarme più vicino, lo setta all’RTC e va a nanna.

Le varie sonde non saranno lette durante lo sleep, quindi: o fai in modo che ogni tot secondi ci sia un allarme per forza, anche se vuoto (quindi aggiornamento dati), oppure vari sensori, sopratutto i2c, hanno delle soglie impostabili che lanciano un segnale su un pin INT, quindi anche qui avresti un segnale che in caso di “pericolo” ti riseglia.

Ma riguardo ai sensori ti temperatura i2c, non è che siano solo per misurazioni prese direttamente dalla board.
perche se non ricordo male in un post si era detto che questo protocollo non sia assicurato per dispositivi staccati dalla scheda principale… magari è solo una questione per dispositivi industriali, o semplicemente ho maleinterpretato io le cose.

Per quanto riguarda il salvataggio delle stringhe da stampare direttamente nella flash sono alquanto d’accordo, tanto che avevo cominciato a ricreare la struttura del menu, ed ero pure a buon punto (allego codice).

Sarei curioso di sapere cosa ne pensate di questo integrato, sembra promettere la lettura del ph, con la possibilità di collegarci 2 sonde e 1 sonda temperature pt100 o pt1000 , ha pure la comunicazione serialecon il quale lo si puo programmare, solo che dal datasheet non capisco come creargli un circuito base per provarlo… sembra che non gli servi niente,
l’integrato http://www.ti.com/product/LMP91200, Datasheet: http://www.ti.com/lit/ds/snas571c/snas571c.pdf

acqua_PROGMEM.ino (24.6 KB)

quell’integrato è solo un ADC moolto sensibile e preciso, mancano le sonde e i necessari liquidi di calibrazione. Vedi questo kit e la famiglia di kit vanduti da questa azienda… costano, ma sai di portarti a casa tutto il necessaire.
PH: https://www.sparkfun.com/products/10972

ossigeno dissolto: https://www.sparkfun.com/products/11194
conduttività elettrica: https://www.sparkfun.com/products/11193

se non erro parlano tutte via seriale, e hanno esempi di codice.

@riciweb: la Flash sono 31,5 kB (tolto il bootloader della UNO) mentre di RAM ne hai solo 2 kB. Devi pensare a come salvare la RAM sempre prima di come salvare la Flash! ;) Con la funzione F() hai perso 200 byte di Flash su un totale di 32256, cioè lo 0,62% in più, mentre passare da 1391 a 957 sono 434 byte salvati su 2048, cioè il 21,19% in meno!! :astonished:

leouz: Ma riguardo ai sensori ti temperatura i2c, non è che siano solo per misurazioni prese direttamente dalla board. perche se non ricordo male in un post si era detto che questo protocollo non sia assicurato per dispositivi staccati dalla scheda principale.. magari è solo una questione per dispositivi industriali, o semplicemente ho maleinterpretato io le cose.

In realtà ci potremmo auto costruire i sensori waterproof, ma a quel punto sarà necessario tenere in considerazione non solo il "forse" elevato numero di periche sul bus, ma anche la lunghezza complessiva del bus stesso, perché i sensori saranno collegati via cavo al pcb, dovremmo quindi integrare il PCB con un bus extender, questo http://www.ti.com/product/p82b715 ;)

lesto: quell'integrato è solo un ADC moolto sensibile e preciso, mancano le sonde e i necessari liquidi di calibrazione. Vedi questo kit e la famiglia di kit vanduti da questa azienda... costano, ma sai di portarti a casa tutto il necessaire. PH: https://www.sparkfun.com/products/10972 ossigeno dissolto: https://www.sparkfun.com/products/11194 conduttività elettrica: https://www.sparkfun.com/products/11193 se non erro parlano tutte via seriale, e hanno esempi di codice.

I prodotti Atlas, sono tanto belli e funzionali, quanto estremamente costosi, speravamo di autocostrurci qualcosa, magari prendendo spunti quà e la...

leo72: @riciweb: la Flash sono 31,5 kB (tolto il bootloader della UNO) mentre di RAM ne hai solo 2 kB. Devi pensare a come salvare la RAM sempre prima di come salvare la Flash! ;) Con la funzione F() hai perso 200 byte di Flash su un totale di 32256, cioè lo 0,62% in più, mentre passare da 1391 a 957 sono 434 byte salvati su 2048, cioè il 21,19% in meno!! :astonished:

Grazie per avermi aiutato a focalizzare le priorità, in effetti sono considerazione che non avevo fatto. :|

Ciao

Riccardo

Con la F, vai sempre tranquillo!! XD