Show Posts
Pages: 1 ... 6 7 [8] 9 10 ... 22
106  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: July 15, 2013, 03:59:57 pm
Il problema è come fare la versione stand-alone?
Ciò non toglie che tu non la possa usare  smiley-cool
Che funzioni hai gA implementato nel tuo progetto?

Ciao Riccardo
107  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 17, 2013, 10:27:59 am
Grazie Lesto,
appena ho un minuto ci gioco un pò.

Riccardo
108  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 14, 2013, 10:06:58 am
Non sia mai che io tolga divertimento e sollazzo a chicchessia  smiley-eek smiley-eek smiley-eek
Piuttosto ti ringrazio per avermi spinto a conoscere ed imparare (fai finta di crederci ti prego  smiley-red) nuove metodologie!!!
Rimane il fatto che alla fine faccio cmq. come mi pare  smiley-twist smiley-twist smiley-twist

Byeee!!!

Riccardo
109  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 14, 2013, 03:15:21 am

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

...
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 smiley-wink ... oltretutto non costano cosi care, e sarebbe fattibile abbastanza facilmente, per impermeabilizzarli basta un po di resina per barche bicomponente smiley-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.

mi piace l'idea dei 3 sensori
Quote
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...  smiley-mr-green

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 smiley-razz) ... 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 smiley-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 smiley-razz ... a meno di non usare degli splitter, ma costano uno sproposito  smiley-eek-blue

Mi piace leggervi e di fatto poi passo le giornate a googlare cercando, con scarso successo devo ammettere  smiley-red, 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-grin

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


110  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 12, 2013, 01:43:20 pm
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 http://www.ti.com/product/lmp91200 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 http://www.ti.com/product/lm77 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:
Code:
byte levelsensor = A0;
void setup() {
   Serial.begin(9600);
   analogReference(INTERNAL);
}
void loop() {
  Serial.println(analogRead(levelsensor));
  delay(50);
}
I dati rilevati sono quì: https://docs.google.com/spreadsheet/ccc?key=0Ah2GzeM3ZZu4dFg5cmRxVUVyQ2FpMFBtRklDN1JPd2c&usp=sharing 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  smiley-sweat, 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  smiley-eek)
  • Lettura del PH con eventuale controllo di un'elettrovalvole per il dosagio della CO2
  • Lettura della Conducibilità

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

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

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.

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.

No problem per eventuali malfunzionamenti...
--> Sushi!!  smiley-mr-green

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 ? smiley-razz  smiley-eek-blue smiley-twist

Capperi Etemenanki, conosci la materia a quanto pare  smiley-eek, 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

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

Che metodo è questo? come funziona concettualmente parlando?

Grazie a tutti.
Riccardo
111  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 11, 2013, 12:03:25 pm
avrei due richieste/proposte: perchè il file non lo suddividete in modo tale che, chi non fosse interessato possa "tagliare" solo quello gli interessa? ad es. a me non interessa il ph o altro, ma interessano solo le luci (è un esempio!) dovrei spulciare tutto il codice ed eliminare ciò che non serve; sarebbe utile, a mio avviso, dare la possibilità di "modulare" il codice facilmente.
Seconda, molto simile alla prima, per lo schema elettrico sarebbe possibile modulare anche qui? Magari chi non ne capisce molto (come il sottoscritto) capire come collegare i sensori di temperatura può divenire un'impresa!!

con ifdef o (meglio imho, vistoche non ci sono richieste di "velocità") con classi e sottoclassi verrebbe molto bene.

Questa cosa di dividere su più file lo sketch, è gia stata chiesta, ma io sinceramente non lo so fare, la risposta che poi ha dato lesto per me è vero e proprio arabo, sinceramente, ancora non mi capacito di essere arivato al punto attuale, piano piano e progredendo, sicuramente saranno strade che percorreremo, ma non nell'immediato purtroppo ancora no...
Tempo fa però Leouz, propose al gruppo una versione light del controller con la sola gestione luci, questo fose al momento attuale è un obbiettivo tempo permettendo più alla mia portata.
Vedrò di fare qualcosa anche per lo schema...

potreste evitare di essere troppo telegrafici? magari tra voi "elettronici" vi capite... ma chi non è del settore... non capisce una mazza!
il sensore di temperatura l'ho trovato e il cavo è lungo 1 m (appena sufficiente come lunghezza, secondo me) funzionerà sulla i2c o no?
ce ne facciamo pochino se è troppo complesso avere un cavo più lungo di 1 m

Se il sensore che hai trovato è quello dell’attuale progetto, allora è di tipo OneWire, e per quello nessun problema di lunghezza…
Ad ogni modo, seguendo i suggerimenti di lesto, ho ordinato il sensore LM77 http://www.ti.com/product/lm77  e I2C non lo conosco e non ho trovato molto sul suo uso con arduino, ma da quel poco che ho potuto capire dal datasheet, potrebbe essere interessante per il nostro progetto… spero di riuscire ad usarlo…  smiley-roll-sweat

Sul fatto di essere invece telegrafici, non mi pare, ricordati che c'è sempre san google, guarda cosa è riuscito a fare un inetto come me grazie ad un pò di ricerca  smiley
 
112  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 08, 2013, 06:26:16 am
Le mie solite Riccardate  smiley-red

Corretto in tutti i post...
Grazieeee!!!

Riccardo
113  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 08, 2013, 05:47:50 am
Con la F, vai sempre tranquillo!!  smiley-lol

Eheheh!!! Ora lo so, grazie Paolo!!!  smiley-wink

scusa, non ho letto tutto il topic, ma allora il problema distanza esiste, mica possono mettere l'arduino a mollo ?
ma c'e' lo schema elettrico di questo progetto oppure solo le foto delle bread ?

Allego a questo topic l'ultimo aggiornamento e a questo punto lo aggiungo anche al topic iniziale...  smiley-lol

mica sta a mollo l'arduino, la soluzione è ugiale a quall on-wire, però risparmiano un sacco di ram e flash, certo la lunghezza (o meglio la capacità) del cavo del sensore sarà limitata, diciamo sui 10cm circa.

10 cm come lunghezza massima del cavo, è impossibile, sarà difficile stare sotto i 30cm anche metendo il pcb del controller in una scatola stagna all'interno del coperchio dell'acquario, è per questo che qualche post fà, ho parlato di integrare nel circuito l' I2C expander  http://www.ti.com/product/p82b715 che appunto dovrebbe risolvere il problema della lunghezza del bus, ho ordinato un pò di cosette per fare delle prove, vedremo cosa fare più avanti...  smiley-neutral

In allegato anche lo sketch rivisto in alcune parti, con la correzione della if suggerita da lesto, con le F() gentilmente inserite da leo72 e formattato un pò meglio, anche se l'uso quasi obbigato di un'editor esterno (Notepad++) non aiuta affatto, ma perché non aggiornano un pochino anche le visualizzazioni dell'IDE ufficiale  smiley-cry che bello sarebbe poter chiudere/espandere i livelli anche lì...
Grazie di cuore a tutti.

Riccardo.
114  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 05, 2013, 04:18:34 am
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  smiley-wink

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

@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!  smiley-wink
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!!  smiley-eek

Grazie per avermi aiutato a focalizzare le priorità, in effetti sono considerazione che non avevo fatto.  smiley-neutral

Ciao

Riccardo
115  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 04, 2013, 06:45:44 am
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.
116  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 04, 2013, 05:26:11 am
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
117  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 04, 2013, 04:30:51 am

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
118  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 04, 2013, 04:30:11 am
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


119  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 03, 2013, 01:33:12 pm
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.
120  International / Megatopic / Re: Ardu-Acquarium Controller v. 3.0 on: June 03, 2013, 10:47:32 am
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
Pages: 1 ... 6 7 [8] 9 10 ... 22