Il dialogo fra PIC e sonda DS1820

[FluidGuitar]

Ho pensato di isolare la porzione di codice che nella waterstation si occupa del dialogo con la sonda digitale DS18B20 perchè penso che a molti possa interessare solo questa porzione indipendentemente dal resto delle cose che fa il programma della waterstation.
Quindi per una questione di leggibilità credo che sia meglio avere la possibilità di leggere questa parte in modo indipendente.

Chi sta seguendo il topic sulla WS sa che dopo le istruzioni che accendono le pompe e si occupano della comunicazione col PC, la waterstation fa un rilevamento della temperatura letta dalla sonda e le istruzioni corrispondenti sono quelle riportate di seguito.
Chi invece volesse realizzarsi un termometro utilizzando questo componente può tranquillamente copia/incollare queste istruzioni per avere un ciclo di lettura della temperatura "stand-alone".

Questo codice non è interamente farina del mio sacco ma è copiato da un programma che ho trovato in internet da una tesina universitaria. Purtroppo non ricordo chi fossero gli autori ma li ringrazio sentitamente per avermi risparmiato un bel po' di lavoro.

;__________________Data acquisition______________________
Acquisition
		call	inizializza_ds1820	; inizializzazione e riconoscimento del DS1820 
		call	delay_600us

		movlw	0xCC
		movwf	ds1820
		call	scrivi_ds1820		; salta la ROM
		call	delay_600us

		movlw	0x44
		movwf	ds1820
		call	scrivi_ds1820		; comando 0x44: converti temperatura

		call	delay_1s			;tempo necessario per la conversione 750ms -> attesa 1s

		call	inizializza_ds1820
		call	delay_600us

		movlw	0xCC
		movwf	ds1820
		call	scrivi_ds1820		; salta la ROM

		movlw	0xBE
		movwf	ds1820
		call	scrivi_ds1820		; comando 0xBE: leggi la Scratchpad

		call	leggi_ds1820
		movf	ds1820, w
		movwf	temp2				; Temperatura LSB  
		call	leggi_ds1820
		movf	ds1820, w
		movwf	temp1				; Temperatura MSB

		return

inizializza_ds1820
		bcf		PORTA, 4
		call	delay_600us			; 600 us se e' zero -> resetta
		bsf		PORTA, 4
		call	delay_80us			; Aspetta 80 us 
		bcf		errore,0
		btfsc	PORTA, 3			
		bsf		errore,0			;La sonda non ha risposto -> errore
		return


scrivi_ds1820
		movlw	0x08
		movwf	KEY

scrivi_ds1820_loop
		rrf		ds1820, f              ; sposta verso destra
		nop

		btfss	STATUS, C
		goto	$+3
		call	scrivi_uno
		goto	$+2
		call	scrivi_zero

		decfsz	KEY, f
		goto	scrivi_ds1820_loop    ; continua fino a che sono stati inviati 8 bit

		return

scrivi_uno
		bcf		PORTA, 4
		call	delay_7us             ; Aspetta 7 us 
		bsf		PORTA,4
		call	delay_80us            ; Aspetta 80 us 

		return


scrivi_zero
		bcf		PORTA,4
		call	delay_80us            ; Aspetta 80 us 
		bsf		PORTA,4

		return



leggi_ds1820
		clrf	ds1820
		bcf		STATUS, C

		movlw	0x08
		movwf	KEY
                      
leggi_ds1820_loop

		bcf PORTA, 4				; basso -> 0
		nop
		nop
		bsf PORTA, 4				; se e' alto non sara'_ trasmesso
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		bsf		STATUS, C
		btfss	PORTA,3				; campionamento del bus
		bcf		STATUS,C
		rrf		ds1820,f			; sposta verso destra

		call	delay_80us			; Aspetta 80 us 

		decfsz	KEY, f
		goto	leggi_ds1820_loop	; Aspetta fino a che sono stati inviati 8 bit

		return
;_______________________________________________________________________________________________

Questa era la routine principale che fa uso delle seguenti sottoroutines per generare i ritardi necessari:

;--------routines di ritardo per il dialogo con DS18B20------------------

delay_600us           movlw 0xC6                 ; Aspetta 600 us 
                      movwf d1
delay_600us_loop      decfsz d1, f
                      goto delay_600us_loop
	                  nop
	              
                      return
                      
                      
delay_50us            movlw 0x0F                 ; Aspetta 50 us 
                      movwf d1
delay_50us_loop       decfsz d1, f
                      goto delay_50us_loop
                      
                      return

delay_30us            movlw 30        	         ; Aspetta 30 us 
                      movwf d1
delay_30us_loop       decfsz d1, f
                      goto delay_30us_loop
                      
                      return
                      
                      
delay_15ms            movlw 182                 ; Aspetta 15 ms 
                      movwf d1
                      movlw 12
                      movwf d2
delay_15ms_loop       decfsz d1, f
                      goto $+2
                      decfsz d2, f
                      goto delay_15ms_loop
                      goto $+1
                      nop
                      
                      return
                      
                      
delay_7us             goto $+1                   ; Aspetta 7 us 
                      nop
                      nop
                      return
                      
                      
delay_80us            movlw 0x19                 ; Aspetta 80 us 
                      movwf d1
delay_80us_loop       decfsz d1, f
                      goto delay_80us_loop
                      
                      return
                      
                      
delay_1s              movlw 0x07                 ; Aspetta 1 s 
                      movwf d1
                      movlw 0x2F
                      movwf d2
                      movlw 0x03
                      movwf d3
delay_1s_loop         decfsz d1, f
                      goto $+2
                      decfsz d2, f
                      goto $+2
                      decfsz d3, f
                      goto delay_1s_loop
                      goto $+1
                      goto $+1
                      goto $+1
                      
                      return

Prima di iniziare il commento spendiamo due parole per descrivere la comunicazione 1-wired ossia "su un solo filo".

I dispositivi comunicano tramite un'uscita "open collector". Per questo ho utilizzato la porta RA4 del PIC che ha proprio questa caratterisica.
Il valore logico uno viene quindi generato da una resistenza di pull-up di 5k collegata verso il positivo (5V) quindi i due dispositivi che dialogano possono scrivere uno 0 mettendo collegando la linea a massa o scrivere un uno semplicemente "rilasciando la linea".

Il PIC è messo in ascolto sulla linea RA3 che risulta in definitiva cortocircuitata con la 4.

Il protocollo prevede di collegare un numero superiore di sonde sulla stessa linea, ma l'algoritmo di riconoscimento è alquanto indaginoso.
In questo caso ci limitiamo al dialogo con una sola sonda.

Chi comanda la comunicazione è il "master", cioè il PIC.

Quando il pic vuole dialogare deve inviare sulla linea un "impulso di reset".
Un impulso di reset consiste nel mettere la linea a 0 e mantenerla per un tempo compreso fra i 480 e i 960us.
Dopo l'impulso di reset il PIC si mette in ascolto.
La sonda che ha visto l'impulso di reset risponde con un impulso di "presence".
Un impulso di presence consiste nel mettere la linea a 0 a partire da 15-60us dall'impulso di reset e per un tempo compreso fra i 60 e i 240us.

Se dopo 60us il PIC non ha visto uno zero sulla linea saprà che non vi è nessuna sonda collegata.
Altrimenti potrà iniziale la comunicazione vera e popria.

Continua...

[FluidGuitar]

Dopo la routine di inizializzazione si ritorna alla chiamante con il flag "errore,0" che vale 1 sel il pic non ha trovato la sonda (ovvero se non vi è stato alcun impulso di presence sulla linea.

Nel caso in cui la sonda non sia presente il resto delle istruzioni di dialogo vengono eseguite ma vanno a vuoto e, quando il programma ritorna alla main visualizzerà un messaggio di errore a causa del flag settato a 1.

Supponiamo ora che la sonda sia effettivamente presente.

Tralascerò la descrizione delle routines di ritardo che vengono usate all'occorrenza dal momento che ne ho illustrata una a titolo di esempio nel topic della waterstation .

Dopo l'inizializzazione il bus-master, cioè il pic, può finalmente dialogare con la sonda.
Dobbiamo distinguere due situazioni: sul bus è presente una sola sonda oppure ve ne sono più d'una.

Nel caso in cui vi siano più sonde esiste una procedura ad eliminazione che permette al bus-master di leggere di ciascuna di esse un condice univoco a 64 bit che permette di distiguerle l'una dall'altra.
In seguito il bus-master utilizzerà questo codice per indirizzare individualmente i comandi a ciascuna sonda.

Il programma che ho usato nella waterstation è pensato per funzionare con una sola sonda quindi subito dopo l'inizializzazione il bus master invia alla sonda un comando che si chiama "skip ROM" (in esadecimale CCH).
Quando la sonda riceve questo comando sa che subito dopo deve attendersi un comando diretto a lei che riguarda le sue funzioni di "sonda".

Il comando skip rom dice alla sonda si "saltare" l'invio del codice univoco da 64 bit che nel nostro caso è perfettamente inutile avendo a che fare con una sola sonda.

		movlw	0xCC
		movwf	ds1820
		call	scrivi_ds1820		; salta la ROM
		call	delay_600us

Queste istruzioni eseguono le seguenti operazioni:

-mettere il valore CCh nell'accumulatore
-mettere il valore dell'accumulatore nel registro ds1820 (definito all'inizio del codice, vedi topic sulla WS)
-chiama la routine scrivi ds1820
-aspetta 600 microsecondi

Non ci resta che esaminare la routine che invia il comando alla sonda.

Continua...

[djufuk87]

ti seguo!

[FluidGuitar]

Siamo al punto di dover effettivamente mandare il cpomando alla sonda, quindi dobbiamo scrivere le routines per realizzare il dialogo.
Dobbiamo innanzitutto sapere che la sonda "legge" il valore logico sul filo 15 microsecondi dopo che questo è stato "tirato giù" dal bus-master".
In altre parole se la sonda vede la linea, che è normalmente a 1, andare a 0 saprà che il bus-master le sta per comunicare un bit e quindi asptterà 15us e poi leggerà lo stato della linea interpretando il valore come un bit di dato.
Quello che deve fare il pic è quindi, se vuole trasmettere uno 0, abbassare la linea e continuare a tenerla bassa fino a oltre i 15us per almeno 75us.
Questo perchè la sonda potrà leggere il valore della linea in un intervallo compreso fra 15 e 75us da quando il bus-master l'ha abbassata.
Viceversa, se il pic vuole trasmettere un 1, deve rilasciare la linea "entro" i 15us e lasciarla invariata per almeno 75us.
Ovviamente anche nel caso della trasmissione di un 1 la linea deve essere dapprima abbassata dal pic e, per dare il tempo alla sonda di accorgersi della variazione sulla linea il pic la deve mantenere a 0 per almeno 1us prima di poterla rilasciare entro il limite dei 15us.

E' più facile a farsi che a dirsi. Esaminiamo il codice:

scrivi_uno
		bcf		PORTA, 4
		call	delay_7us             ; Aspetta 7 us 
		bsf		PORTA,4
		call	delay_80us            ; Aspetta 80 us 

		return


scrivi_zero
		bcf		PORTA,4
		call	delay_80us            ; Aspetta 80 us 
		bsf		PORTA,4

		return

Come vedete per scrivere un 1 si mette a 0 la linea su cui è collegata la sonda (in questo caso il piedino RA4) e lo si mantiene per 7us. Quindi siamo sicuri di averlo tenuto per 1us e cadiamo a metà dell'intervallo da 15us.
Successivamente si rimette la linea a 1 e si aspettano 80us che è un po' di più dei 75us per avere un po' di margine.

Nel caso della scrittura di uno 0 è sufficiente mettere la linea a 0 per 80us e poi rimetterla a 1.

Continua...

[FluidGuitar]

Dopo avere esaminato le routines che fanno il "lavoro sporco" di controllare a basso livello la linea, esaminiamo quella che effettivamente si occupa di inviare la parola che ci interessa.

scrivi_ds1820
		movlw	0x08
		movwf	KEY

scrivi_ds1820_loop
		rrf		ds1820, f              ; sposta verso destra
		nop

		btfss	STATUS, C
		goto	$+3
		call	scrivi_uno
		goto	$+2
		call	scrivi_zero

		decfsz	KEY, f
		goto	scrivi_ds1820_loop    ; continua fino a che sono stati inviati 8 bit

		return

Ricordiamo che nel registro ds1820 è stato preventivamente inserito il valore che vogliamo trasmettere e sappiamo che tutte le comunicazione con la sonda avvengono trasmettendo per primo il bit MENO significativo.

Sapendo questo esaminiamo le righe una per una:

- metti nell'accumulatore il valore decimale 8
- metti il valore dell'accumulatore nel registro KEY

questo serve per avere un contatore per gli 8 bit di trasmissione...

- rrf ds1820,F

questa è una istruzione che non avevamo ancora incontrato, essa effettua una "rotazione verso destra" del registro specificato e ne salva il contenuto nel registro stesso.
La particolarità consiste nel fatto che la rotazione avviene "attraverso" il bit di Carry dello STATUS register.
Questo significa che dopo aver eseguito la "rrf" ci ritroveremo al posto del bit 7 il valore che era nel bit di carry prima della rrf, al posto del bit di carry troveremo il valore del bit 0 (il bit meno significativo) e tutti gli altri bit saranno scalati di una posizione verso il meno significativo.
Avrete già capito che questa procedura ci permette di avere ad ogni ciclo, nel bit di carry, proprio il valore da trasmettere partendo dal meno significativo.

Non ci rimane altro che:

- controllare il valore del bit di carry e saltare se vale 1
- andare avanti di 3 istruzioni
- chiamare la "scrivi_uno" esaminata precedentemente
- andare avanti di 2 istruzioni
- chiamare la "scrivi_zero" esaminata precedentemente
- decrementare il contatore "KEY" saltando se vale 0
- ritornare all'inizio della routine
- ritornare alla chiamante

Mi sembra che ci sia poco altro da aggiungere a queste righe, si tratta di alcuni salti condizionati organizzati in modo da chiamare la "scrivi_uno" o la "scrivi_zero" in base al valore del bit di carry.

Continua...

[djufuk87]

ottime spiegazioni!!

[FluidGuitar]

Ritorniamo quindi a considerare la routine principale di dialogo con la sonda:

		movlw	0x44
		movwf	ds1820
		call	scrivi_ds1820		; comando 0x44: converti temperatura

		call	delay_1s			;tempo necessario per la conversione 750ms -> attesa 1s

		call	inizializza_ds1820
		call	delay_600us

		movlw	0xCC
		movwf	ds1820
		call	scrivi_ds1820		; salta la ROM

		movlw	0xBE
		movwf	ds1820
		call	scrivi_ds1820		; comando 0xBE: leggi la Scratchpad

Dopo il comando "skip-rom" (CCH) la sonda si aspetta un comando riguardante o le sue funzioni di sonda o delle operazioni di memoria.

Per inciso la sonda ha anche una "configration word" che può essere programmata e una memoria in cui memorizzare un valore di temperatura in base al quale la sonda può fare da allarme settando un flag quando la temperatura supera tale valore.
Nel mio caso non ho utilizzato nessuna di queste funzioni quindi non ne parlerò in questa esposizione ma, una volta capito come funziona il dialogo, è sufficiente cambiare le parole di comando e riutilizzare le stesse routines.

Quindi dopo il comando di "ROM" mandiamo un comando di funzione:

		movlw	0x44
		movwf	ds1820
		call	scrivi_ds1820		; comando 0x44: converti temperatura

		call	delay_1s			;tempo necessario per la conversione 750ms -> attesa 1s

In questo caso il comando 44=converti temperatura.

Dopo questo comando la sonda rimane inattiva per il tempo necessario a leggere la temperatura e convertirne il valore in binario. Il tempo necessario dipende dalla risoluzione impostata.
Per default la sonda è impostata alla risoluzione massima di 12bit e in questo caso il tempo richiesto è di 750ms. Nel codice è impostato un valore approssimato per eccesso.

Continua...

[FluidGuitar]

Dopo il comando "converti temperatura" (44H) la sonda ha esaurito il suo ciclo di operazioni e ha bisogno di essere reindirizzata.

La routine principale quindi dovrà eseguire di nuovo un impulso di reset per reinizializzare la sonda seguito da un comando "skip rom" per passare di nuovo alle funzioni esecutive.

Quello che dobbiamo fare adesso è leggere la "scratchpad" cioè la memoria in cui viene memorizzato l'ultimo valore di temperatura convertito.

Il codice si presenta così:

		call	inizializza_ds1820
		call	delay_600us

		movlw	0xCC
		movwf	ds1820
		call	scrivi_ds1820		; salta la ROM

		movlw	0xBE
		movwf	ds1820
		call	scrivi_ds1820		; comando 0xBE: leggi la Scratchpad

Si tratta delle routines viste precedentemente; come unica differenza vi è appunto il comando "leggi scratchpad" (BEH) il quale dice alla sonda che subito dopo dovrà inviarci il dato di temperatura.

Dobbiamo ora affrontare il problema di "leggere" questo dato che ci viene inviato ancora una volta a partire dal bit meno significativo.

Anche in questo caso è il bus-master che "comanda" la comunicazione abbassando la linea.
La sonda, se vuole trasmettere uno 0 manterrà la linea a 0 per un massimo di 15us da quando il bus-master l'ha abbassata.
Quindi il pic dovrà smettere di "pilotare" la linea entro i 15us e leggere il valore.
Ogni slot di lettura deve durare almeno 60us e fra uno slot e l'altro deve intercorrere almeno 1 us.

Alla luce di quanto sopra possiamo interpretare la seguente routine:

leggi_ds1820
		clrf	ds1820
		bcf		STATUS, C

		movlw	0x08
		movwf	KEY
                      
leggi_ds1820_loop

		bcf PORTA, 4				; basso -> 0
		nop
		nop
		bsf PORTA, 4				; se e' alto non sara'_ trasmesso
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		nop
		bsf		STATUS, C
		btfss	PORTA,3				; campionamento del bus
		bcf		STATUS,C
		rrf		ds1820,f			; sposta verso destra

		call	delay_80us			; Aspetta 80 us 

		decfsz	KEY, f
		goto	leggi_ds1820_loop	; Aspetta fino a che sono stati inviati 8 bit

		return

Come prima operazione si pulisce il contenuto del registro ds1820 perchè vi andremo a inserire il dato letto.
Poi si imposta a 8 il contatore dei bit, in questo caso, ricevuti.
Si abbassa la linea di comunicazione.
Si eseguono due "nop", cioè due operazioni "a vuoto" che permettono di far trascorrere 2 microsecondi per far assestare la linea e permettere alla sonda di vedere la variazione.
Si rilascia la linea.
Si effettuano una serie di nop per portarsi a ridosso dei 15us che è il limite massimo entro cui fare la lettura.
Si preimposta alto il bit di carry.
Finalmente si effettua la lettura del valore.
Se tale valore è 0 si imposta a 0 il bit di carry altrimenti si salta alla istruzione successiva.
Si effettua la rrf per riportare nel registro ds1820 il bit di carry infilandolo da sinistra.
In questo modo dopo le 8 iterazioni il primo bit letto sarà arrivato in posizione 0 che è appunto la meno significativa.

Dopo aver letto gli 8 bit si ritorna alla chiamante che non abbiamo ancora esaminato.

		call	leggi_ds1820
		movf	ds1820, w
		movwf	temp2				; Temperatura LSB  
		call	leggi_ds1820
		movf	ds1820, w
		movwf	temp1				; Temperatura MSB

		return

La routine "leggi_ds1820" viene chiama immediatamente dopo la scrittura del codice "leggi scratchpad" e, come si può vedere, viene eseguita due volte memorizzando, dopo ogni chiamata, il valore letto nel registro ds1820 in un registro temporaneo: temp1 e temp2.
Infatti la sonda invierà i 12 bit del valore di temperatura spezzato in due byte dei quali ci invia prima il meno significativo. (i 4 bit in eccesso del secondo byte sono don't care).

Continua...

[FluidGuitar]

Al termine dell'ultima subroutine ci ritroviamo quindi con il valore di temperatura letta dalla sonda contenuta nei due registri da un byte ciascuno, temp1 e temp2.
Inoltre abbiamo il flag di controllo rappresentato dal bit 0 del registro "errore". Nel caso in cui tale bit valga 1 il contenuto dei temp1 e temp2 è da ignorare perchè la sonda non è presente anche se le istruzioni di lettura vengono eseguite comunque.

Avrei potuto mettere una istruzione di salto per evitare di eseguire del codice inutile, ma ho preferito tenere la routine uguale all'originale visto che non avevo la necessità di spaccare il microsecondo .

Il valore di temperatura è un decimale fixed point con segno in complemento a 2 e della conversione in decimale ce ne occuperemo nel topic originale sulla waterstation.

In questo vorrei che il discorso rimanesse limitato alla sonda, al suo funzionamento e ad eventuali modifiche alla routine di dialogo per adattarla ad altre necessità

[V0r[T3X]]

Ti ringrazio veramente tanto per questa "guida", in quando in futuro ho intenzione di sperimentare le DS18B20 (ne ho alcune a casa). Quello che cercherò di fare è di integrare in C quello che hai sviluppato in ASM. Ovviamente alcune parti rimmarranno obbligatoriamente in assembler, essendo fondamentali i timings per il corretto svolgimento della comunicazione.

[FluidGuitar]

Originariamente inviato da V0r[T3X]
Ti ringrazio veramente tanto per questa "guida", in quando in futuro ho intenzione di sperimentare le DS18B20 (ne ho alcune a casa). Quello che cercherò di fare è di integrare in C quello che hai sviluppato in ASM. Ovviamente alcune parti rimmarranno obbligatoriamente in assembler, essendo fondamentali i timings per il corretto svolgimento della comunicazione.

Mi fa piacere. Credo che sia una cosa positiva che sul forum ci sia supporto per entrambi gli approcci, asm e C.