Svenska ElektronikForumet

> ibland står vad som ska komma,"
Då det är ett "fast" värde, oberoende av allt annat.

> "ibland står "as sent""
Kan läsas tillbaka för verifiering...

> "och ibland "response""
Då det är ett i förväg okänt värde (som t.ex temp-värdet)

> Jag bör väl tala om svaren, fast jag tror inte det gör nån mycket klokare.

Det är väll inte du som skall avgöra det !

> ska se om jag kan få fram nå svar som ger nått:)

*OM* du får fram svar som "ger nått", så finns det ingen anledning att posta dom alls, då vet du ju redan svaret, eller ?
Och hur avgör du om svaret kanske "ger nått" för någon annan än du ??

Nog om det...

Jag skulle lägga en read mellan varje byte du skickar.
Det är inte helt tydligt om DS2480 svarar "as sent" när man skickar "ROM code", men det verkar inte helt osannolikt om man jämför med andra funktioner i DS2480...

JAG KLARADE DET!!!

Utförlig beskrivning kommer:)
EDIT:

Här kommer hur jag gjorde med att skicka ROM-ID:

Först skickas MATCH ROM (h'55')
Sen skickas ID med familycode först. en byte åt gången

Svaret kommer direkt med samma som du skickade, detta gör du 8 ggr.

Så här ser ordningen ut:
DS2480 startar upp i "COMMAND MODE" vilket är läget som DS2480 hanterar data internt, "DATA MODE" skickar vidare till sensorer externt.

Det som står efter varje kommando är det jag skickar, ex "Reset_C1", då skickar jag "C1" osv.

***********************************
PULLUP_524 (skickar "39", svar blir "38", ger 524 ms)

RESET_C1 ' command mode (Svar "CD" eller "ED")

DATAMODE_E1 ' Skiftar till DATA MODE (inget svar)


MATCHROM_55 ' Data mode (Svar "55")

SENDROM ' Data mode (svar på varje byte, samma som du skickar)

COMMANDMODE_E3 ' skiftar till COMMAND MODE (inget svar)

ARM_STRONG_PULLUP_EF (Inget svar)
TERMINATE_PULSE_F1 ' svaret blir "EC" vid MATCH ROM, vid SKIP ROM blir svaret "EF"

DATAMODE_E1 (inget svar)
CONVERT_T_44 ' data mode (Svar "44")

WAIT_76 (inget ska skickas, bara tas emot) ' Denna är väntetiden tempberäkningen tar o svaret blir "76"

COMMANDMODE_E3 (inget svar)
DISARM_STRONG_PULLUP_ED (inget svar)

TERMINATE_PULSE_F1 (svar "EC")

RESET_C1 ' command mode (Svar "CD" eller "ED")

DATAMODE_E1 (inget svar)

MATCHROM_55 ' data mode (Svar "55")

SENDROM ' data mode (svar på varje byte, samma som du skickar, vilket är ROM ID)


(För read scratchpad skickas "BE" först, sen "FF" på resten, första svaret ger BE, detta skall bort, du får in CRC sist)

For i = 1 To 10' (Det är 9 bytes totalt)
READ_SCRATCHPAD (i) ' data mode
Next

COMMANDMODE_E3 (inget svar)
RESET_C1 'command mode (Svar "CD" eller "ED")
'***********************************


Hoppas detta var tydligt och att det inte skiljer på svar mm hos er andra.

EDIT 2:

Detta är en read rom (för att få in ROM ID på 64 bitar)
OBS, går endast med en singel sensor!!
****************************
RESET_C1
DATAMODE_E1
READROM_33

(Skicka FF 8 ggr för att läsa in 8 byte)
For i = 1 To 8
READ_ROM_ID_FF (i)

Next

COMMANDMODE_E3
RESET_C1
**********************

Detta är kodat i VB6 och en typisk funktion för nästan alla dessa rader är:

*********************************
Private Sub RESET_C1()
Dim i As Long

MSComm1.Output = Chr(&HC1)
' Vänta på att data skickas tillbaka genom COM-porten

Do


buffer$ = buffer$ & MSComm1.Input
If buffer$ = "" Then GoTo 1
tmp = Asc(buffer$)
'Debug.Print Hex(tmp)
1

Loop Until Hex(tmp) = "CD"

buffer$ = ""

End Sub
*******************************************'


/B

Jäkligt kul !
Och bra beskrivning dessutom...

Det man kan konstatera är att det blir lite mer "pratigt" eftersom det är en mix av kommandon både till temp-givaren (DS18s20) och till RS232/1-Wire convertern (DS2480B).

Men å andra sidan blir det ju inga igentliga konstighetet med timing eller annat från PC/VB sidan. Bara enkel seriekommunikation med hela bytes.

Återstår väll bara funktionen för att "scanna av" en 1-Wire bus...

Tackar

Ja, den funktionen blir nått i hästväg
Ska köpa fler sensorer bara.

/B

Jo, men med en snygg struktur på koden, borde det bara bli ett par anrop till några "canned functions" där alla detaljer ligger.

Absolut, det behöver inte bli så mycket men det "ser ut" som sättet att scanna på är svårt o komplicerat... fast det har jag ju tyckt om allt hittils så...

Ska labba i morgon eftermiddag!

/B

hej igen då:)

Jag köpte mig en DS2405 (switch) den funkade på en gång:)

Jag försöker att få "search rom" att funka, dock så är det inte så enkelt.
Jag tänkte använda "search accelerator" i DS2480´n, vilken finns beskriven här: http://pdfserv.maxim-ic.com/en/ds/DS2480B.pdf på sida 10.

Det jag inte fattar är två saker:

1. vilka bytes ska jag skicka? Hur är det tänkt?
2. Vad är "Do Memory Function"? (Search Accelerator Usage Example sid 11, 3:e raden nerifrån)

Det står bara "not specified here" i texten på sid 10...


Kan man få lite hjälp, me dessa två saker?


EDIT: Såg nyss att denna tråd genererat 2643 visningar, det är flest på hela första sidan iaf för en tråd
/B

> "1. vilka bytes ska jag skicka? Hur är det tänkt?"

Som jag har förstått det så är en "Search ROM" operation, ett sätt att med uteslutningsmetoden hitta alla device på bussen. Man börjar (enligt DS2480 databladet sid 10) med en ROM code med 64 "nollor". Genom det resultat man får tillbaka ska man (om jag förstår rätt) kunna få ROM code till *ett* device. Sedan får man modifiera sitt "sök-mönster" och köra om tills man har hittat alla device.

> "2. Vad är "Do Memory Function"? (Search Accelerator Usage Example sid 11, 3:e raden nerifrån)"

En tänkt funktion som är "not specified here"
Det skulle kunna vara vad som helst, det har inget med "search accelerator" eller "search rom" att göra i alla fall, det verkar bara vara utfyllnad i exemplet...

Sodjan, ibland undrar jag om du sitter och bevakar min tråd:)
Helt ok i så fall hehe.

1. Det är just det där med uteslutningsmetoden som e lite förvirrande.
Ska jag testa att skicka 64 "nollor" och se vad jag får för svar?

2, ahaaa, det hör inte dit alltså, då har jag lite mer att jobba på, funktionen är klar, visste bara inte vilka 64 bitar jag skulle in me:)

Testar!

/B

Ok, jag testade att skicka 64 st "&H0" och svaret blev 16 byte av data, resten blev bara "FF" vilket slog mig att det stod så, 16 byte är max.

EDIT:Jag skickade in "&H1" oxå för att testa och svaert blir det samma som med noll.

Hur som helst så är svaret på dessa:

1
2
2A
80
A0
8
AA
82
0
0
80
0
0
0
0
20

Jag har 2 sensorer.
Hur ska jag nu göra för att veta vilken ROM en sensor har?

/B

> "Ok, jag testade att skicka 64 st "&H0""

Du blandar fortfarande ihop BITS och BYTES !!!!

Har du kodat dina 16 bytes enligt beskrivningen ?
Har du tolkat dina svar enligt beskrivningen ?
Allt finns på sidan 9 och 10.

Om en av de två sensorerna är samma som du använde förrut, så skall ditt svar stämma överens med den (eller den andra !), Gör det det ? Tolkat enligt beskrivningen på sidan 10, så klart...

sodjan : Du kommer att vara kung på 1-wire efter detta :D

Ja, benring : Du också :D

Jag har suttit och stirrat på dom två sidorna i ca 3 timmar nu men fattar inte iaf!!
Det är ju därför jag frågar, den typen av engelska är inte så enkel heller, tex "discrepancy" ?? Aldrig hört, slog upp det och fick massa val.

Jag ska löda bort den nya sensorn så jag bara har en att testa koden mot.


Sen undrar jag fortfarande hur det är tänkt att jag ska "bygga upp" mina BYTES?

x= utfyllnad, betyder att jag kan ha vad som helst där??

"The character r marks the path to go at that particular bit in case of a conflict during the execution of the ROM Search."

vaddå? vilken PATH??

Asså dessa datablad drömmer jag mardrömmar om...

EDIT: Ja, vi kommer va två utbrända kungar

/B

benring skrev: x= utfyllnad, betyder att jag kan ha vad som helst där??



/B

Ja

och det är en bra ide att köra med en sensor bara, du kan ju ta först den ena o sen den andra om jag minns rätt (dom har väl kvar samma ROM-code?)

edit: ändrade från id till rom

OK

Så här har jag tolkat det (enbart efter databladet, ej testat i praktiken !)

Först skikcar du en "mall" till en ROM code där alla 64 bitarna är "0".
Dessa fylls ut i 16 bytes enligt beskrivningen, alltså i "R-bitarna".
Vad "X-bitarna" innhåller spelar ingen roll just nu.

Detta skickas.

Du får du tillbaka 16 bytes.

I svaret har du "R" och "D" (f.d "X") bitar.
"D-bitarna" talar om i vilka positioner det blev en "adress konflikt".
"R-bitarna" talar om vilken adress DS2480 valde.
D.v.s att "R-bitarna" kommer tillsammans att utgöra ROM code till det *första* funna devicet på bussen.

Nu skall man köra om hela proceduren, med samma R1-R64 som gången innan, men med Rm = 1 i den *första* position där D-biten var lika med "1", d.v.s där man fick första konflikten "discrepancy" mellan devicen.

Svaret tolkas på samma sätt igen, och steget ovan körs om tills man får första konflikt i samma bit två gånger efter varandra.

Detta gör, så vitt jag förstår, att man fortsätter sökningen neråt i "trädet", men tvingar DS2480 in på den andra grenen vid första konflikten.

Säg att man först kör 64 nollor.

I t.ex pos 10 får man en konflikt (vilket markeras i R-biten).
D.v.s att det finns (minst) *två* device som har olika bit i pos 10 !!

Sökningen fortsätter via den "path" som har en nolla i pos 10.

När man kör andra gången sätter (tvingar) man in en etta i pos 10, för att fortsätta sökningen via *den* path'en. O.s.v tills alla device är funna.

Se det hela som ett upp och nedvänd gren som börjar med *en* "root" som sedan delar sig 64 gånger...

Eller lite som en klassisk "binär-sökning".

Jag kan inte se annat än att börja koda upp och tolka de 16 bytes enligt beskrivningen...