sulla sezione Sensori stiamo sviscerando un problema da me riscontrato sui 18B20
se c'e' qualcuno interessato a contribuire questo e' il post, e' la seconda pagina, nella prima non era ancora chiaro il problema,
http://arduino.cc/forum/index.php/topic,68302.15.html
grazie
non ne ho nemmeno uno per provare....
quale libreria usi per controllarlo?
la Dallas di Miles Burton
ho praticamente messo in evidenza che l'uso di questo sensore, fra i piu' famosi ed usati su arduino, in un progetto di lettura continua della temperatura, quindi non ogni secondo ma continua, in real time, crea problemi di visualizzazione, il display si spegne durante la conversione del dato.
nel mio caso come display uso le nixie 
ho postato un codice di test che si puo' usare con il monitor seriale, guardando il led TX di arduino si vede leggermemnto lo spegnimento guardando il led.
nella libreria ci sono punti in cui si usano delay anche di 750ms a seconda della precisione della lettura richiesta, non sarà per quello?
il motivo e' quello, in base alla risoluzione la gestione "normale" del sensore usa delay di 750ms per i 12bit
ma gia' dalla penultima versione della libreria e' stata inserita la modalita' asincrona. che serve appunto ad eliminare questo problema.
Purtroppo appunto come evidenziato la modalita' asincrona ha cmq blocchi di 28ms, 28ms sono apprezzabili dall'occhio umano, e quindi danno fastidio.
si sta tentando di ridurre ancora di piu' questo tempo.
All'inizio ho rpovato a far lavorare il codice su una seconda variabile in cui copiare il dato letto dal sensore, ma purtroppo sembra che quei 28ms bloccano proprio tutto il micro, quindi non se ne esce con soluzioni sw.
A questo punto mi domando, non solo non e' possibile usare il 18B20 per letture continue, ma se sullo stesso progetto si usano piu' sensori anche diversi, tipo umidificatori ed altro, se e' vero che i 28ms bloccano tutto il micro, tutti i dati di tutti i tipi di sensori vengono anch'essi bloccati.
Testato:
A questo punto mi domando, non solo non e' possibile usare il 18B20 per letture continue, ma se sullo stesso progetto si usano piu' sensori anche diversi, tipo umidificatori ed altro, se e' vero che i 28ms bloccano tutto il micro, tutti i dati di tutti i tipi di sensori vengono anch'essi bloccati.
Ma assolutamente no, basta scrivere bene il software di gestione della onewire e usare gli interrupt onchange piuttosto che un polling software.
Certo che con all'interno della libreria cose come questa:
"preso dall'ultima relase 3.71"
if (parasite) delay(10); // 10ms delay
Hai voglia a blocchi del funzionamento di tutto il resto.
astrobeed:
if (parasite) delay(10); // 10ms delayHai voglia a blocchi del funzionamento di tutto il resto.
Quindi in presenza di insetti parassiti in casa il sensore si blocca nel tentativo di identificare la famiglia e la specie degli stessi.. XD
aspita, interessante, non sono andato a guardare nelle librerie aivoglia di usare il blinking without delay se poi nella libreria ci sono i delay normali.
se cambio tutti i delay della libreria con la tecnica del blink without delay potrei risolvere ?
se ho capito durante il comando Delay il micro smette di fare qualsiasi cosa ci sia nel void loop ? resta li' fermo a contare giusto ? l'unica attivita' e' il conteggio del tempo ?
anche gli interrupt continuano a funzionare ed i valori di eventuali pwm vengono mantenuti.
capisco,
e secondo te c'e' un modo per bypassare il problema via sw, senza dover usare un latch hw ?
posto il codice con commenti in italiano, magari di passaggio serve a qualcuno.
con questo codice di test il problema lo si nota guardando il led TX di arduino che invece di restare fisso a trasmettere sempre il dato, ogni 28ms si spegne per un attimo
#include <OneWire.h>
#include <DallasTemperature.h>
// Data wire is plugged into port 2 on the Arduino
#define ONE_WIRE_BUS 16
// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(ONE_WIRE_BUS);
// Pass our oneWire reference to Dallas Temperature.
DallasTemperature sensors(&oneWire);
// variabili temp
float temp;
long previousMillis = 0;
void setup(void)
{
sensors.begin();
sensors.setResolution(12);
sensors.setWaitForConversion(false); // makes it async asincrono=non blocca il programma durante la lettur
Serial.begin(9600);
}
void loop(void)
{
if (millis() - previousMillis > 750) // mette la temperatura nella variabile temp dopo 750ms
{
temp=sensors.getTempCByIndex(0); //COMANDO CHE CREA IL PROBLEMA
Serial.print("Requesting temperatures...");
sensors.requestTemperatures(); //
Serial.println("DONE");
previousMillis = millis(); // riparte il temporizzatore
}
Serial.println(temp);
}
è vero che la modalità asincrona non impone delay programmati, ma comunque devi aspettare la fine della lettura/conversione/calcolo crc ecc...
vedo che comunque effettui la lettura ogni 750ms, quindi presumo che il ds sia collegato in modalità parassita.
cambia modalità di alimentazione, dovresti riuscire a strizzare qualche millisecondo in più.
ho gia' provato senza esito, ma ora mi viene un dubbio, dovevo forse dichiararlo anche nello sketch ? oppure c'e' un riconoscimento automatico del parasite mode ?
mi ricontrollero' questa cosa, nel frattempo approfitto, per 2 richieste di chiarimenti e per un'idea.
la variabile "temp" che uso per memorizzare il dato e per passare il dato stesso alla sezione di visualizzazione durante questi benedetti 28ms non e' accessibile ? cioe' il valore presente in una variabile,nel momento in cui questa e' in attesa di ricevere il nuovo, non e' disponibile ? sono domande basi ma io vengo dal mondo elettronico, devo vedere la variabile come una cella di memoria che puo' fare una cosa alla volta, quindi se e' stata chiamata in causa per memoprizzare un valore, e questo valore arriva dopo 10 secondi, per 10 secondi il suo vecchio valore non e' a disposizione ? viene cancellato nel momento della richiesta del nuovo ?
perche' non riesco a bypassare il problema semplicemente copiando dopo 1 ms dalla fine della lettura Temp in Temp2 e quindi lavorare su temp2 per la visualizzazionhe del dato ?
cioe' aspetto 750ms per la lettura, copio temp in temp2 visualizzo temp2 per 750ms, ricopio ecc ?
l'idea invece che mi e' venuta prendendo spunto dal forum e' questa: volendo passare ad una soluzione HW, posso usare la eeprom dell'atmega per memorizzare il valore e quindi far lavorare la parte di visualizzazione su questa cosi' come farei con uno shift register hw esterno ?
si , puoi scrivere in eeprom e dichiararla come volatile
nessuno ha voglia di chiarirmi le prime due domande ?
lo so che sono domande base di programmazione, ma mi aiuterebbe molto avere queste due basi su cui ragionare.
x brain: leggendo in giro da un lato ho letto che la EEprom interna non gestisce Float, mentre in un topic sembra di si. Come e' la situazione ? a me serve solo una cifra decimale
news sul post inglese, si cercano consigli per la risoluzione.
mi sa che devo casmbiare sensore
Testato:
news sul post inglese, si cercano consigli per la risoluzione.
mi sa che devo casmbiare sensore[SOLVED] 18B20 timing problem - #50 by testato - Sensors - Arduino Forum
Siamo nella stessa barca forse... proprio ieri notte ho fatto il pieno di tutorials e alla fine mi ero deciso per il DS18B20
giusto perchè il sitema Onewire mi avrebbe risolto molte cose... (ma se dà problemi a voi che ne capite... figuriamoci a me)
Stravolto nuovamente il progetto globale... passerò probabilmente ad LM35
KrashNet:
Siamo nella stessa barca forse... proprio ieri notte ho fatto il pieno di tutorials e alla fine mi ero deciso per il DS18B20
giusto perchè il sitema Onewire mi avrebbe risolto molte cose... (ma se dà problemi a voi che ne capite... figuriamoci a me)
Il problema è la libreria che utilizzano, è stata realizzata male, certo che se pensano di risolvere senza metterci mano, in pratica va riscritta, il problema rimarrà sempre e comunque.
Giusto per conoscenza, il sistema onewire funziona benissimo, certo è un pochino ostico da gestire a livello software, ma tutto sommato nulla di strano, gestire l'I2C è più complicato, certo che se si ragiona sempre in termini di librerie "pappa pronta" fatte da altri e poi queste non vanno bene non si può, e non si deve, dare la colpa ai componenti elettronici.
Fossi in grado, darei volentieri una mano ma l'elettronica purtroppo nn è il mio campo...
Con tutto il movimento che c'è nel forum intarnazionale strano che nessuno abbia provveduto a riscrivere la libreira...
Dato che come integrato viene citato e usato in una miriade di tutorials!
Penso che ci siano quei geniacci competenti in materia che una volta evidenziati i problemi calla community, in una nottata (ottimista) riescono a patchare i codici!
KrashNet:
Con tutto il movimento che c'è nel forum intarnazionale strano che nessuno abbia provveduto a riscrivere la libreira...
Dato che come integrato viene citato e usato in una miriade di tutorials!
La questione è il problema è stato portato alla luce solo adesso perché in condizioni "normali" la libreria funziona, però se serve il real time vengono fuori i problemi.
Penso che ci siano quei geniacci competenti in materia che una volta evidenziati i problemi calla community, in una nottata (ottimista) riescono a patchare i codici!
Sicuramente ci sono, magari adesso sono in ferie pure loro
Comunque non è una questione di patch, quello si fa in poche ore, è che tocca riscrivere da 0 tutta la parte di gestione del segnale onewire a livello hardware eliminando tutti i punti bloccanti.