Adressering av DS18B20 ?

[Marta]

Har ett problem som förefaller vara svart magi, DS18B20 reagerar inte när den adresseras med sin ROM-kod.

Adresseras kretsen med $CC skip ROM så fungerar allt OK.

Läsning av ROM-koden med $33 fungerar OK och CRC stämmer. Första avlästa byte är $28 som den alltid skall vara enligt databladet.

Adresseras kretsen med $55 match ROM + ROM-kod händer ingenting.

Flera kretsar är provade med samma resultat.


Sänder reset, kretsen svarar med en kvittenspuls.

Sänder $55 med bit0 först

Sänder ROM-koden i samma ordning som den lästs av. Alla bytes med bit0 först
$28, 6 bytes individuell kod, CRC.

Sänder $BE read scratchpad följt av läspulser där inget händer.



Finns det några maxtider någonstans? Databladet uppfattar jag som att det inte finns sådana. Krävs någon initiering, tex andra kommandon som måste ha gjorts innan adresseringen kan fungera?

Någon som har en fungerande källkod till PIC som adresserar 18B20 och kan tänka sig att posta just den delen där adresseringen skickas?

[JustNeed]

Kod: Markera allt

void matchRom(void)
{
	char i,j;
	j = cSensor*8;
	Reset();
	Write(MATCHROM);
	for(i = 0; i < 8; i++)
	{
		Write(rom[i+j]);
	}
}

Ursäkta att det är lite fult och stökigt, ska försöka förklara lite kvickt.
MATCHROM är 0x55
rom[] är där jag lagrar alla adresser efter varandra men som de är (d.v.s inte baklänges eller så).
cSensor är det nummer som givaren har i PICen.
Skrivet för CC5X

Ser inte ut att vara så stor skillnad bortsett från att jag inte skiljer på family code, serial number och CRC utan sparar alltihop i samma sträng.
Har inte koll på om det finns några tidskrav.

[Marta]

Felet är hittat, det var min otroliga klantighet som orsakade det.

När ROM-koderna lästes av och antecknades manuellt fanns det ett fel i 7-segment tabellen för teckenvisningen C visades som E, så ROM-koderna som skickades var alldeles fel...

Har gjort det här förr och allt såg rätt ut vilket det också var. Mycket konfunderande när det inte fungerade.

Anledningen till uppdelningen av adressen i olika delar är för att hålla nere tabellens storlek till 6 bytes per sensor. Skulle nog kunna vara ännu mindre, eftersom de översta bytes är 00 00 02 på alla sensorerna. Om enumereringen startat ungefär på 0 så har de gjort drygt 8 miljoner sådana...

Nu skall jag läsa av ROM-koderna på 40 sensorer för andra gången
Hoppas det blir rätt den här gången...

[v-g]

För mig tog det tre dagars konstant kodande/felsökande för att få igång det hela. Helt lätt är det inte iaf