Pages: 1 ... 15 16 [17] 18 19 ... 46   Go Down
Author Topic: Ardu-Aquarium Controller v. 3.3.1  (Read 59753 times)
0 Members and 2 Guests are viewing this topic.
Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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  smiley-lol smiley-lol smiley-lol smiley-lol
Pensavo di essere messo maluccio, non che ora abbia da scialare, ma va molto meglio!!!

Scusatemi  smiley-red

Riccardo
Logged

Riccardo

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 327
Posts: 22640
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Chiedo scusa  smiley-confuse, 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.

* acquarium_controller_v_3.ino (43.75 KB - downloaded 23 times.)
Logged

Riccardo

Lamezia Terme
Offline Offline
Shannon Member
****
Karma: 564
Posts: 12450
Le domande di chi vuol imparare rappresentano la sua sete di sapere
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley-wink
Logged

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

0
Offline Offline
Shannon Member
****
Karma: 130
Posts: 10464
:(){:|:&};:
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley


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:
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:
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.
« Last Edit: June 03, 2013, 02:46:55 pm by lesto » Logged

sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Offline Offline
Full Member
***
Karma: 0
Posts: 106
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

complimenti per il progetto smiley

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 smiley

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? smiley
tipo questo per intenderci: http://www.robot-italy.com/it/itdb02-2-4e-2-4-tft-lcd.html
« Last Edit: June 03, 2013, 04:06:03 pm by zioTonino » Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 327
Posts: 22640
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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


Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley

Già fatto, ma grazie per avermelo ricordato  smiley-wink

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  smiley-sad

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

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


Logged

Riccardo

Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


complimenti per il progetto smiley
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 smiley
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? smiley
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…  smiley-neutral
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:
lcd.print("IMP. FOTOPERIODO L");
diventa
Code:
lcd.print(F("IMP. FOTOPERIODO L"));

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

Grazie a tutti.
Riccardo
Logged

Riccardo

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 327
Posts: 22640
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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!
 smiley-razz

* acquarium_controller_v3_1.ino (50.21 KB - downloaded 16 times.)
Logged


Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 327
Posts: 22640
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Grazie del consiglio, e sopratutto permettiti sempre ti prego  smiley  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.
Logged


Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Riccardo
Logged

Riccardo

0
Offline Offline
Shannon Member
****
Karma: 130
Posts: 10464
:(){:|:&};:
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Rome
Offline Offline
Sr. Member
****
Karma: 9
Posts: 376
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Riccardo

0
Offline Offline
Shannon Member
****
Karma: 130
Posts: 10464
:(){:|:&};:
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Pages: 1 ... 15 16 [17] 18 19 ... 46   Go Up
Jump to: