Go Down

Topic: Ardu-Aquarium Controller v. 3.3.1 (Read 77063 times) previous topic - next topic

riciweb


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...


come 4k di bootloader, di che Arduino stai parlando?


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.


Devo sempre scrivere qualche Riccardata, ma in questo caso sono contento di averla scritta così grazie a voi ho corretto un mia convinzione sbagliata  :smiley-red:, 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  :smiley-red:

Riccardo
Riccardo

leo72

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

riciweb

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…  :smiley-mr-green:


PS: Ho sostituito i file anche nei post precedenti, scusate ancora   :smiley-red:.
Riccardo

Michele Menniti



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.

appunto e la MEGA avrebbe 128 o 256k di memoria.... quindi quei 4k diverrebbero ininfluenti ;)
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

lesto

#244
Jun 03, 2013, 08:55 pm Last Edit: Jun 03, 2013, 09:46 pm by lesto Reason: 1

PS: Ho sostituito i file anche nei post precedenti, scusate ancora   :smiley-red:.


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):
Code: [Select]
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

Code: [Select]

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


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
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.
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

zioTonino

#245
Jun 03, 2013, 11:03 pm Last Edit: Jun 03, 2013, 11:06 pm by zioTonino Reason: 1
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

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:
Code: [Select]
lcd.print("IMP. FOTOPERIODO L");
diventa
Code: [Select]
lcd.print(F("IMP. FOTOPERIODO L"));

riciweb


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  ;)


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!


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  :(


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

per esempio riga 129 (dallealtre parti sembrerebbe ok):
Code: [Select]
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

Code: [Select]

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...


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().


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


Riccardo

riciweb



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…


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:
Code: [Select]
lcd.print("IMP. FOTOPERIODO L");
diventa
Code: [Select]
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
Riccardo

leo72

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!
:P

leo72


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.

riciweb

Caspita Leo, ti sei messo a modificare tutto  :smiley-eek: grazie davvero!!!


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
Riccardo

lesto

Quote
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.
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

riciweb


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.
Riccardo

lesto

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.
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Go Up