next topic »

[on:]

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

[Reply #1 on:]

non ne ho nemmeno uno per provare....

[Reply #2 on:]

quale libreria usi per controllarlo?

[Reply #3 on:]

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.

[Reply #4 on:]

nella libreria ci sono punti in cui si usano delay anche di 750ms a seconda della precisione della lettura richiesta, non sarà per quello?

[Reply #5 on:]

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.

[Reply #6 on:]

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"

Code:

if (parasite) delay(10); // 10ms delay

Hai voglia a blocchi del funzionamento di tutto il resto.

[Reply #7 on:]

Code:

if (parasite) delay(10); // 10ms delay

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

[Reply #8 on:]

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 ?

[Reply #9 on:]

anche gli interrupt continuano a funzionare ed i valori di eventuali pwm vengono mantenuti.

[Reply #10 on:]

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

Code:

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

[Reply #11 on:]

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

[Reply #12 on:]

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.

1) 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 ?

2) 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 ?

3) 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 ?

[Reply #13 on:]

si , puoi scrivere in eeprom e dichiararla come volatile

[Reply #14 on:]

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