[RISOLTO] 18B20 in RealTime

astrobeed:

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

  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 ?

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

Krash aspetta pero' a cambiare sensore, dimmi tu dove devi visualizzare la temperatura ?
il problema da me evidenziato non deriva dal componente ma dal metodo di visualizzazione che uso io (nixie, multiplexate, con una genialata di alimentazione gratuita che purtroppo aggiunge flickering ed un aggiornamento di 10ms)

un normale lcd, o un utilizzo da serial monitor, o un lcd i2c o tutto il 99,99% restante non ha problemi.

x astro, non credo sia risolvibile via sw, nemmeno riscrivendo tutta la libreria, perche' per ricevere il dato dal sensore occorrono un tot di millisecondi, l'autore della libreria e' sceso a 18 dai precedenti 28ms, ma non si potra' scendere a 0ms perche' il sensore ha bisogno di un minimo tempo per rendere disponibile il dato. A questo punto se per quel determinato tempo la variabile in cui si mette il dato non e' accessibile, non potra' esistere una soluzione sw ma solo hw, sei daccordo ?

Testato:
Krash aspetta pero' a cambiare sensore, dimmi tu dove devi visualizzare la temperatura ?
il problema da me evidenziato non deriva dal componente ma dal metodo di visualizzazione che uso io (nixie, multiplexate, con una genialata di alimentazione gratuita che purtroppo aggiunge flickering ed un aggiornamento di 10ms)

un normale lcd, o un utilizzo da serial monitor, o un lcd i2c o tutto il 99,99% restante non ha problemi.

x astro, non credo sia risolvibile via sw, nemmeno riscrivendo tutta la libreria, perche' per ricevere il dato dal sensore occorrono un tot di millisecondi, l'autore della libreria e' sceso a 18 dai precedenti 28ms, ma non si potra' scendere a 0ms perche' il sensore ha bisogno di un minimo tempo per rendere disponibile il dato. A questo punto se per quel determinato tempo la variabile in cui si mette il dato non e' accessibile, non potra' esistere una soluzione sw ma solo hw, sei daccordo ?

Si effettivamente i dati ora li mostro su LCD 4x16 con 2 LM35 e due thermistori NTC ordinati un po a caso e problemi non ne ho riscontrati (a parte letture sfalsate tra i moelli) ma dato il mio livello niubbo in elettronica neanche me ne accorgerei di difetti di programmazione o risposta.... (ma sono ancora su breadboard)

Mettevo mentalmente le mani avanti dato che sono ancora in fase di sviluppo del progetto e se a settembre va tutto bene mi ritroverò a dover creare un sistema "titanico" e trovavo la soluzione onewire col 18b20 ottima... e soprattutto comoda!
P.S. tutti i dati alla fine dovranno essere mandati su server MySql (mi preoccupava il delay anche associato alle varie connessioni simultanee, lunghezza cavi e colli di bottiglia vari) e non vorrei che troppi fattori precari mi stressino macchine e scripts!

allora senza ombra di dubbio resta su protocollo onewire, per il tuo scopo i millesimi di secondo di cui parliamo non sono nemmeno rilevabili. il 18B20 eà un bellissimo sensore, costa poco, supportato al massimo, e funziona anche in parasite mode con soli due fili.

Andata :smiley:
(e al 90% ho risolto il problema temperature.... il 10% rimanente sono i pasticci che combinerò io)

Testato:
perche' per ricevere il dato dal sensore occorrono un tot di millisecondi

Ci possono volere pure delle ore, ma questo non vuol dire che devo stare per forza fermo ad aspettare il sensore, come ho già detto qualche post indietro la onewire va gestita tramite interrupt on change, non esiste che mi metto a fare il polling software su un pin o ad aspettare senza fare nulla tot ms.

ho letto la sezione interrupt e provato il blink del led sull'arduino, usando l'interrupt 0 (pin2)
da quest'esempio e da un altro trovato ho capito come gestire un interrupt ad esempio per un bump switch.
ma non capisco come devo usarli io questio interrupt, non serve appunto un elemento esterno come uno switch che cambia lo stato al pin 2 ?

avevo pensato ad esempio di mettere il comando gettempbyindex all'interno della funzione inerrupt, ma poi mi sono detto, sempre sti maledetti 28ms gli serviranno per finire la funzione interrupt, e visto che l'interrupt appunto interrompe il resto del codice, la mia visualizzazione restera' ugualmente buia.

anche sul topic inglese sono venuti fuori gli interrupt, mi potresti mettere sulla buona strada ? e' una buona cosa da approfondire.

io ho sto sistema di visualizzazione con un refresh velocissimo di 10ms ed invece un sensore che per fornire il dato ne impiega il triplo, in che modo usare l'interrupt e su quale lato, lato display o lato sensore ?

Testato:
anche sul topic inglese sono venuti fuori gli interrupt, mi potresti mettere sulla buona strada ? e' una buona cosa da approfondire.

Guardati l'application note "AVR318: Dallas 1-Wire® master", illustra le varie tecniche per la one wire incluso il polling software, semplice da implementare, ma bloccante, ed è quello che fa la libreria che stai utilizzando, l'interrupt, che non è bloccante salvo le poche decine di microsecondi per gestire lo stato del pin, oppure tramite USART slegandoti completamente dal software per l'invio e la ricezione dei byte.