mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ds1820 Fragen


Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich steuere das Expansionsventil einer Wärmepumpe über gemessene 
ds1820-Temperaturen. Gemessen wird alle 20 Secunden. Das ist während des 
Austestens der Anlage sinnvoll, weil man Veränderungen schnell sieht. Im 
Normalbetrieb würden eine oder zwei Minuten reichen. Gibt es beim ds1820 
einen Veschleiß? Welches Messintervall wäre für 10Jahre Lebensdauer 
sinnvoll?

Wie wird die Reihenfolge der Sensoren bei einer Abfrage der Messwerte 
festgelegt? Der Master sendet die Abfrage. Melden sich dann alle 
Sensoren gleichzeitig oder haben die eine zufällig bestimmte 
individuelle Verzögerung?

Wenn sie sich alle gleichzeitig melden, wie wird dann die Reihenfolge 
der Übertragung bestimmt?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ grundschüler (Gast)

>Normalbetrieb würden eine oder zwei Minuten reichen. Gibt es beim ds1820
>einen Veschleiß?

Nicht beim Messen, nur beim Schreiben des EEPROMs.

> Welches Messintervall wäre für 10Jahre Lebensdauer
>sinnvoll?

Das hängt von der Zeitkonstante deiner Regelstrecke ab.

>Wie wird die Reihenfolge der Sensoren bei einer Abfrage der Messwerte
>festgelegt?

???

> Der Master sendet die Abfrage. Melden sich dann alle
>Sensoren gleichzeitig oder haben die eine zufällig bestimmte
>individuelle Verzögerung?

Hast du nicht angeblich schon mal was mit OneWire gemacht?

Beitrag "ds1820 - Eeprom id-Verwaltung mittels IR"

Dann solltest du doch wissen, daß man bei mehreren ICs am One Wire Bus 
diese per ID adressiert.

Beitrag "Onewire + DS18x20 Library"

Autor: Kolja L. (kolja82)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
grundschüler schrieb:
> Wie wird die Reihenfolge der Sensoren bei einer Abfrage der Messwerte
> festgelegt?

Jeder Sensor hat eine eigene ID.
Somit kannst du jederzeit selbst entscheiden, welchen Sensor du gerade 
auslesen möchtest.

Autor: grundschüler (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Falk B. schrieb:
> Hast du nicht angeblich schon mal was mit OneWire gemacht?

Du hast die Frage nicht verstanden.

Der Master sendet die Abfrage. Dann melden sich alle Sensoren 
nacheinander mit ihrer id und werden nach ihrer id ausgewertet.

Unabhängig von der Auswertung - wie die geht weiß ich - muss doch 
irgendwie durch das Programm in den Sensoren bestimmt werden, welcher 
Sensor wartet und welcher Sensor antwortet. Wie wird das im Bus-System 
bestimmt? Also, die Sensoren erhalten die Abfrage alle zur gleichen 
Zeit, können aber nicht gleichzeitig antworten.

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
grundschüler schrieb:
> Falk B. schrieb:
>> Hast du nicht angeblich schon mal was mit OneWire gemacht?
>
> Du hast die Frage nicht verstanden.

Nein DU hast 1Wire nicht verstanden.

>
> Der Master sendet die Abfrage. Dann melden sich alle Sensoren
> nacheinander mit ihrer id und werden nach ihrer id ausgewertet.

So funktioniert das auf BUS Ebene nicht. Vielleicht hast du eine lib die 
das für dich tut, dann frag diese lib nach Details. Mit 1Wire hat das 
nichts zu tun. Das KANN man so machen.

> Unabhängig von der Auswertung - wie die geht weiß ich - muss doch
> irgendwie durch das Programm in den Sensoren bestimmt werden, welcher
> Sensor wartet und welcher Sensor antwortet. Wie wird das im Bus-System
> bestimmt? Also, die Sensoren erhalten die Abfrage alle zur gleichen
> Zeit, können aber nicht gleichzeitig antworten.

Also 1Wire nicht verstanden. Warum lügst du und behauptest das 
Gegenteil?

Bei mehreren Sensoren spricht man diese jeweils mit ihrer ID an (READ 
ROM). D.h. du bestimmst die Reihenfolge komplett selbst.
Die IDs können vorher per SEARCH ROM gefunden werden.

Der Master entscheidet also selber wann er welchen Sensor kontaktiert. 
Die Sensoren tun da gar nichts von sich aus. Und es erhält immer nur EIN 
Sensor eine abfrage. Nicht alle.
Das SEARCH ROM Verfahren bildet hier eine Ausnahme. Wie das genau geht, 
kannst du in den Dokumenten zum 1Wire von Dallas/Maxim nachlesen.
Aber das wird nur zum finden aller IDS angewendet, nicht zum abfragen 
der Sensorwerte.

: Bearbeitet durch User
Autor: Lothar Mayer (zwickel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Reihenfolge der Anzeige hängt von der Auslese-Software ab.
Wenn du z.B. LogTemp als Software benutzt, dann ordnet die Software die 
ID der Sensoren in aufsteigender (Zahl) Reihenfolge.

Das kann man aber manuell ändern, sodass die Reihenfolge eine 
individuelle ist.

Genau das gleiche macht auch das kleine Proggi Tempwin.

Einmal die Reihenfolge festgelegt, fragt die Soft die einzelnen Sensoren 
immer in der festgelegten Reihenfolge ab.

Übrigens, die Sensoren werde schön der Reihe nach abgefragt, also nicht 
alle gleichzeitig!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@grundschüler (Gast)

>> Hast du nicht angeblich schon mal was mit OneWire gemacht?

>Du hast die Frage nicht verstanden.

Möglich.

>Der Master sendet die Abfrage. Dann melden sich alle Sensoren
>nacheinander mit ihrer id und werden nach ihrer id ausgewertet.

Falsch!

Der OneWire Master sendet eine Anfrage an EINEN bestimmten IC, der durch 
seine ID (ROM-Code) eindeutig adressiert wird. Und nur DER antwortet.

>Unabhängig von der Auswertung - wie die geht weiß ich - muss doch
>irgendwie durch das Programm in den Sensoren bestimmt werden, welcher
>Sensor wartet und welcher Sensor antwortet.

Du redest wirr und machst aus einem eher trivialen Problem ein 
Riesenthema. Trink mal nen  Kaffee und versuch's in ner Stunde nochmal.

> Wie wird das im Bus-System
>bestimmt? Also, die Sensoren erhalten die Abfrage alle zur gleichen
>Zeit,

FALSCH!

Man kann BESTENFALLS das Startkommando (Temperature conversion) 
gleichzeitig an alle schicken. Die Abfrage des Ergebnisses muss aber für 
jeden Sensor EINZELN erfolgen.

So gesehen ist OneWire recht ähnlich zu I2C. Auch dort wird jeder IC mit 
seiner ID adressiert. Kein IC sendet von sich aus!

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
grundschüler schrieb:
> Der Master sendet die Abfrage. Dann melden sich alle Sensoren
> nacheinander mit ihrer id und werden nach ihrer id ausgewertet.

Geh davon aus, dass recht viele in diesem Forum bereits DS18x20 Sensoren 
verwendet haben und deshalb wissen, wie sie betrieben werden.

: Bearbeitet durch User
Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Nein DU hast 1Wire nicht verstanden.

mag sein - deswegen Frage ich hier.


> Das SEARCH ROM Verfahren bildet hier eine Ausnahme.
nur um diese Ausnahme geht es.
unsigned char w1_rom_search( unsigned char diff, unsigned char idata *id )
{
  unsigned char i, j, next_diff;
  char b;

  if( w1_reset() )
    return PRESENCE_ERR;      // error, no device found
  w1_byte_wr( SEARCH_ROM );      // ROM search command
  next_diff = LAST_DEVICE;      // unchanged on last device
  i = 8 * 8;          // 8 bytes
  do{
    j = 8;          // 8 bits
    do{
      b = w1_bit_io( 1 );      // READ_OW bit
      if( w1_bit_io( 1 ) ){      // READ_OW complement bit
  if( b )          // 11
    return DATA_ERR;      // data error
      }else{
  if( !b ){        // 00 = 2 devices
    if( diff > i ||
      ((*id & 1) && diff != i) ){
      b = 1;        // now 1
      next_diff = i;      // next pass 0
    }
  }
      }
      w1_bit_io( b );           // WRITE_OW bit
      *id >>= 1;
      if( b )          // store bit
  *id |= 0x80;
      i--;
    }while( --j );
    id++;          // next byte
  }while( i );
  return next_diff;        // to continue search
}

void read_meas( void )
{
uint8_t i;
u8 id[8], diff;
int16_t temp;



  for( diff = SEARCH_FIRST; diff != LAST_DEVICE; ){
    diff = w1_rom_search( diff, id );

    if( diff == PRESENCE_ERR ){
        //uputsnl( "No Sensor found" );

....


Wenn ich den code - uralt, ich glaube von pd - richtig verstehe sendet 
der Master solange
 w1_byte_wr( SEARCH_ROM );      // ROM search command
bis alle Sensoren geantwortet haben. Die Reihenfolge der Antworten wird 
vom master meiner Meinung nach nicht festgelegt, denn der master sendet 
die id nicht sondern wertet die id nur aus. Alle Sensoren bekommen 
geleichzeitig den Befehl   SEARCH_ROM...

> Wie das genau geht,
> kannst du in den Dokumenten zum 1Wire von Dallas/Maxim nachlesen.
Das Datenblatt hilft tatsächlich weiter:

http://pdfserv.maximintegrated.com/en/an/AN937.pdf


"A flowchart of all ROM Commands is shown in Figure
5–2. Since the logic of the Search ROM command is the
most complex, the following example is used to illustrate
it step by step.
Four devices are connected to the 1–Wire bus. Their
binary ROM contents are:
device 1: xxxxxx10101100
device 2: xxxxxx01010101
device 3: xxxxxx10101111
device 4: xxxxxx10001000
The x’s represent the higher remaining bits. Shown are
the lowest eight bits of the ROM contents. The least sig-
nificant  bit  is  rightmost  in  this  representation.  The
search process runs as follows:
1.   The  master  begins  the  initialization  sequence  by
issuing  a  Reset  Pulse.  The  i
Buttons  respond  by
issuing Presence pulses.
2.   The master will then issue the Search ROM com-
mand on the 1–Wire Bus.
3.   The master reads one bit from the 1–Wire bus. Each
device will respond by placing the value of the first
bit of its respective ROM data onto the 1–Wire bus.
Devices 1 and 4 will place a 0 onto the 1–Wire bus;
that is, they pull it low. Devices 2 and 3 will send a 1
by allowing the line to stay high. The result is the log-
ical AND of all devices on the line; therefore the mas-
ter reads a 0. The master will read an
..."

Einfach genial von dallas. Alle Sensoren senden gleichzeitig. 
Ausgewertet wird der Sensor zuerst, der least significant die meisten 
Nullen in der id hat.

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
grundschüler schrieb:
> Cyblord -. schrieb:
>> Nein DU hast 1Wire nicht verstanden.
>
> mag sein - deswegen Frage ich hier.

Du hast behauptet du kennst sich mit 1Wire aus. Was eine Lüge war.

>
>
>> Das SEARCH ROM Verfahren bildet hier eine Ausnahme.
> nur um diese Ausnahme geht es.

Nein, denn du schreibst:

> Der Master sendet die Abfrage. Dann melden sich alle Sensoren
> nacheinander mit ihrer id und werden nach ihrer id ausgewertet.

Und das passt nicht zum SEARCH ROM. Denn weder melden sich hier alle 
Sensoren nacheinander, noch werden die Sensoren hier "ausgewertet". Es 
werden nur alle IDs eingesammelt.

: Bearbeitet durch User
Beitrag #5054957 wurde vom Autor gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
>
> Also 1Wire nicht verstanden. Warum lügst du und behauptest das
> Gegenteil?

Auch wenn Du ganz klar recht hast:
warum muss man gleich zu dieser Wortwahl greifen ... und das bei einem 
Grundschüler? Aber das gilt generell hier im Forum!

Für mich ist eine Lüge mit Vorsatz verbunden, bei ihm ist es doch wohl 
eher eine Behauptung wider besseres Wissen ...

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Für mich ist eine Lüge mit Vorsatz verbunden, bei ihm ist es doch wohl
> eher eine Behauptung wider besseres Wissen ...

egal wie, helfen wir mal.

@grundschüler

mit search ROM sammelst du alle IDs die zurückgemeldet ein, optimal in 
einem Array (struct) mit Platz für ID (& wenn du magst für Temperatur 
und Ort wo dein Sensor steckt)

also werden alle Sensoren IDs gesammelt und dann kannst du später 
gezielt abfragen nach ID

Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Auch wenn Du ganz klar recht hast:
> warum muss man gleich zu dieser Wortwahl greifen ... und das bei einem

er hat nicht recht. Ich kenn mich mit ds1820 zumindest soweit aus, dass 
ich die Sensoren auslesen kann - also ist die diesbezügliche Behauptung 
keine Lüge. Sein Beitrag war aber trotzdem gut, denn der Hinweis auf das 
Datenblatt war zielführend und deswegen berechtigt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jedes ROM COMMAND adressiert mindestens einen Sensor.
Nach jedem SEARCH ROM Zyklus ist der gefundene Sensor adressiert, d.h. 
dessen Temperatur kann ausgelesen werden. Man muß die IDs also nicht 
erst alle aufsammeln.
Sobald man Sensoren entfernt oder hinzufügt, verschiebt sich aber die 
Reihenfolge. Um eine permanente Zuordnung zur Meßstelle zu erreichen, 
kann man die Meßstelle im EEPROM des Sensors speichern.

Im alten Datenblatt war das noch eindeutig:
"The 1–Wire bus master must first provide one of five ROM function 
commands:
1) Read ROM, 2) Match ROM, 3) Search ROM, 4) Skip ROM, or 5) Alarm 
Search. After a ROM functions sequence has been successfully executed, 
the functions
specific to the DS1820 are accessible and the bus master may then 
provide and one of the six memory and control function commands."

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>Jedes ROM COMMAND adressiert mindestens einen Sensor.

Am Ende ist es nur ein Sensor, denn mitten drin kann man nicht sinnvoll 
aufhören.

>Nach jedem SEARCH ROM Zyklus ist der gefundene Sensor adressiert, d.h.
>dessen Temperatur kann ausgelesen werden. Man muß die IDs also nicht
>erst alle aufsammeln.

Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll.
Praktisch scannt man EINMAL den Bus und hat dann alle IDs, über welche 
dann die Sensoren direkt adressiert werden.

>Sobald man Sensoren entfernt oder hinzufügt, verschiebt sich aber die
>Reihenfolge.

Eben.

>Um eine permanente Zuordnung zur Meßstelle zu erreichen,
>kann man die Meßstelle im EEPROM des Sensors speichern.

Du meinst wohl eher den Mikrocontroller = OneWire Master.

>Im alten Datenblatt war das noch eindeutig:

In den neuen auch.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll.

Das ist sogar äußert sinnvoll bei MCs, die keinen EEPROM haben.
Ich hab das z.B. beim AT89C2051 so macht.
Daß mit dem Speichern im EEPROM des Sensors hatte ich mal angedacht, 
aber nicht realisiert.
Es sind mir auch keine Sensoren ausgefallen, so daß ich sie neu zuordnen 
mußte.

Falk B. schrieb:
> In den neuen auch.

Nein, da ist diese Passage rausgefallen. Und auch im Flowchart geht der 
Pfeil nicht mehr zum "Master TX Funktion Command". Das neue Datenblatt 
ist also falsch.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>> Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll.

>Das ist sogar äußert sinnvoll bei MCs, die keinen EEPROM haben.

Nö. Dort würde man eher eine Liste im RAM halten, die muss halt bei 
jedem Reset neu aufgebaut werden.

Bis auf SEHR wenige Sonderfälle ist die Suchfunktion als reguläre 
Adressierung von OneWire ICs NICHT SINNVOLL!

>Ich hab das z.B. beim AT89C2051 so macht.

In EINEM Sonderfall!

>Daß mit dem Speichern im EEPROM des Sensors hatte ich mal angedacht,
>aber nicht realisiert.

Ich glaube wir reden aneinander vorbei. Der Sensor ist bei mir der 
OneWire IC. Dort kann man wohl kaum sinnvoll seine eigene Zuordnung 
speichern.

Es sind mir auch keine Sensoren ausgefallen, so daß ich sie neu zuordnen
mußte.

>Nein, da ist diese Passage rausgefallen. Und auch im Flowchart geht der
>Pfeil nicht mehr zum "Master TX Funktion Command". Das neue Datenblatt
>ist also falsch.

Link?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Am Ende ist es nur ein Sensor, denn mitten drin kann man nicht sinnvoll
> aufhören.

Was sinnvoll ist, bestimmst doch nicht Du.
Man kann sehr wohl jederzeit einen weiteren ROM-SEARCH Zyklus ausführen. 
Man muß sich dafür nur die 8 Byte ID des vorherigen Sensors und die 
Bitnummer des letzten Konflikts merken.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Nö. Dort würde man eher eine Liste im RAM halten, die muss halt bei
> jedem Reset neu aufgebaut werden.

D.h. Du stellst Dich nach jedem Stromausfall hin und legst die 
Reihenfolge neu fest. Ansonsten hast Du doch auch nur die Reihenfolge, 
die sich aus den IDs ergibt, nur mit erheblich mehr SRAM-Verbrauch.

Falk B. schrieb:
> Ich glaube wir reden aneinander vorbei. Der Sensor ist bei mir der
> OneWire IC. Dort kann man wohl kaum sinnvoll seine eigene Zuordnung
> speichern.

Natürlich. Jeder Sensor hat 2 Byte EEPROM, d.h. Du könntest bis zu 65536 
Meßstellen festlegen.

: Bearbeitet durch User
Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
>> Falk B. schrieb:
>> Ich glaube wir reden aneinander vorbei. Der Sensor ist bei mir der
>> OneWire IC. Dort kann man wohl kaum sinnvoll seine eigene Zuordnung
>> speichern.
>
> Natürlich. Jeder Sensor hat 2 Byte EEPROM, d.h. Du könntest bis zu 65536
> Meßstellen festlegen.

Ob nun im Sensor oder im zentralen EEPROM ist erst mal egal. Die Frage 
die sich jeder 1Wire Nutzer am Anfang sehr schnell stellen wird, ist 
die, wie man die Sensoren initial überhaupt den realen Messstellen 
zuordnet. Und wie das bei einem Sensortausch ohne manuellen Eingriff 
beibehalten werden kann.
Wird nur immer genau EIN Sensor getauscht, kann die Zuordnung 
automatisch beibehalten werden. Sonst nur schwerlich.

Nur für die erstmalige Zuordnung gibt es leider kein Patentrezept. Bei 
nur sehr wenigen Sensoren kann es sich lohnen, für jede Messstelle einen 
1Wire Pin vorzusehen und dort nur jeweils einen Sensor zu betreiben. 
Damit entfällt auch die SEARCH ROM Implementierung und man kann mit SKIP 
ROM arbeiten.

: Bearbeitet durch User
Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Falk B. schrieb:
>> Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll.
>
> Das ist sogar äußert sinnvoll bei MCs, die keinen EEPROM haben.

PeDa ich bin ja dein FAN, aber hier widerspreche ich auch, nach PRG 
Start wird der Bus gescannt und alles in ein Array gepackt, da brauchts 
kein EEPROM!

Falk B. schrieb:
> Nö. Dort würde man eher eine Liste im RAM halten, die muss halt bei
> jedem Reset neu aufgebaut werden.

eben

Falk B. schrieb:
> Es sind mir auch keine Sensoren ausgefallen, so daß ich sie neu zuordnen
> mußte.

mir hat sich durch AP Verschiebung (der Rv war wohl an der Grenze 2,2k) 
ein Sensor nicht mehr gemeldet, nach Rv auf 1,5k war er wieder da.

Sensor muss nicht ausfallen, ich finde Scan vorher und ID im Array 
halten sinnvoll.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> PeDa ich bin ja dein FAN, aber hier widerspreche ich auch, nach PRG
> Start wird der Bus gescannt und alles in ein Array gepackt, da brauchts
> kein EEPROM!

Ich hatte früher auch AT90S1200, ATtiny12, ATtiny15 verwendet, da geht 
es nur mit Auslesen direkt nach jedem ROM-SEARCH-Zyklus. Die 9 Byte 
temporären Speicher mußte man von den 32 Registern abknapsen, extra SRAM 
hatten die nicht.
Die AT89C2051 waren da schon komfortabler mit 128Byte SRAM, die wollte 
ich aber auch nicht ohne Not verschwenden.

Man sollte es also jedem gefälligst selber überlassen, was sinnvoll ist 
oder nicht und nicht anderen irgend etwas vorschreiben wollen, nur weil 
man die gewählte Lösung nicht kennt.

Autor: Cyblord ---- (cyblord)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man sollte es also jedem gefälligst selber überlassen, was sinnvoll ist
> oder nicht und nicht anderen irgend etwas vorschreiben wollen, nur weil
> man die gewählte Lösung nicht kennt.

Langsam merkt man schon den Altersstarrsinn....

Autor: Falk Brunner (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>Man sollte es also jedem gefälligst selber überlassen, was sinnvoll ist
>oder nicht und nicht anderen irgend etwas vorschreiben wollen, nur weil
>man die gewählte Lösung nicht kennt.

Du solltest mal an deiner Lesekompetent arbeiten. Ich schrieb

"Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll."

"Bis auf SEHR wenige Sonderfälle ist die Suchfunktion als reguläre
Adressierung von OneWire ICs NICHT SINNVOLL!"

Der OneWire Bus mit seinen Befehlen ist sicher NICHT explizit oder gar 
exklusiv für uCs mit minimalstem RAM gebaut worden. Deine Methode ist 
ein Workaround für DIESE spezielle Situation, aber sicher NICHT 
allgemeingültig.
Du aber stellst es allgemeingültig dar.

Und last but not least geht es in einem Forum um den Meinungsaustausch. 
Wenn ich etwas für nicht sinnvoll halte, dann sage ich das so, incl. 
Begründung. Ob das anderen oder besonders dir passt, ist mir reichlich 
egal.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Falk B. schrieb:
> "Bis auf SEHR wenige Sonderfälle ist die Suchfunktion als reguläre
> Adressierung von OneWire ICs NICHT SINNVOLL!"

Kannst Du das mal begründen, warum diese Lösung nicht sinnvoll sein 
soll?
Sie spart Code und SRAM und funktioniert ebenso zuverlässig, wie die 
separate Speicherung aller IDs.
Ich sehe daher keinerlei Grund, sie nicht auch auf MCs mit mehr 
Flash+SRAM zu verwenden.
Der Grund, daß sie Dir nicht gefällt, ist mir herzlich egal.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Man sollte es also jedem gefälligst selber überlassen, was sinnvoll ist
> oder nicht

da schliesse ich mich doch an, überlasse es jedem selbst! (also auch 
mir)

Peter D. schrieb:
> Ich sehe daher keinerlei Grund, sie nicht auch auf MCs mit mehr
> Flash+SRAM zu verwenden.

Wenn DU alle meine Programme programmierst kannst du machen wie DU 
willst, da ich selber muss mache ich es wie ich es besser kann und da 
habe ich MEINE Methode gefunden, egal ob sinnvoll, nötig oder nicht 
deiner Meinung nach ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>> "Bis auf SEHR wenige Sonderfälle ist die Suchfunktion als reguläre
>> Adressierung von OneWire ICs NICHT SINNVOLL!"

>Kannst Du das mal begründen, warum diese Lösung nicht sinnvoll sein
>soll?

Gern ;-)

- Wenn mehrere (viele) ICs am Bus hängen, muss man immer viele Scans 
durchführen, wenn man die höheren IDs erreichen will. Das kostet Zeit.
- bei den Scans können in EMV-kritischen Umgebungen Bitfehler auftreten, 
die dann erneutes Scannen nötig machen
- die Zuordung von ROM-IDs und interner Verwaltungsnummer wird nicht 
einfacher
- es ist einfach dämlich, immer den Bus zu scannen anstatt den 
Teilnehmer direkt anzusprechen.

>Ich sehe daher keinerlei Grund, sie nicht auch auf MCs mit mehr
>Flash+SRAM zu verwenden.

Sag am besten noch "alternativlos", dann ist die Diskussion endgültig 
abgewürgt.

>Der Grund, daß sie Dir nicht gefällt, ist mir herzlich egal.

Umso besser! We agree to disagree!

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> - es ist einfach dämlich, immer den Bus zu scannen anstatt den
> Teilnehmer direkt anzusprechen.

vor allem kann ich bei direkter Ansprache über IDs meine Zimmer nach 
Wichtigkeit in der Temperatur scannen und nicht immer (unnötig) über 
alle Sensoren..

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> da schliesse ich mich doch an, überlasse es jedem selbst! (also auch
> mir)

Tue ich doch die ganze Zeit schon.
Ich habe meine Lösung in keinem Wort jemand anderem aufgezwungen oder 
eine andere Lösung schlecht gemacht. Bitte mal genau lesen, was ich 
schreibe.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Falk B. schrieb:
> - es ist einfach dämlich, immer den Bus zu scannen anstatt den
> Teilnehmer direkt anzusprechen.

Aha, jetzt ist es eben dämlich, tiefer gehts wohl nicht. Ich bin dann 
mal raus.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ich habe meine Lösung in keinem Wort jemand anderem aufgezwungen oder
> eine andere Lösung schlecht gemacht.

dann verstehe ich diesen Text falsch:

Peter D. schrieb:
> Nach jedem SEARCH ROM Zyklus ist der gefundene Sensor adressiert, d.h.
> dessen Temperatur kann ausgelesen werden. Man muß die IDs also nicht
> erst alle aufsammeln.

d.h. wenn ich ein Zimmer auslesen will muss ich immer ROM search machen!

Peter D. schrieb:
> D.h. Du stellst Dich nach jedem Stromausfall hin und legst die
> Reihenfolge neu fest

nein, auch das mache ich nicht, ich sortiere nach startup die IDs (wenn 
gefunden) in meine bekannte Zimmerzuordnung (ID im Array)

Peter D. schrieb:
> Nach jedem SEARCH ROM Zyklus ist der gefundene Sensor adressiert, d.h.
> dessen Temperatur kann ausgelesen werden. Man muß die IDs also nicht
> erst alle aufsammeln.

Ich will aber ein Zimmer (auch mehrfach) auslesen können ohne erneute 
Suche

: Bearbeitet durch User
Autor: grundschüler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> - es ist einfach dämlich, immer den Bus zu scannen anstatt den
> Teilnehmer direkt anzusprechen.


für mich stellt sich jetzt die Frage, was schneller geht - Abfrage der 
64bit-Adresse durch den Master oder Mitteilung der 64bit-Adresse durch 
den slave.

Wenn ich das richtig verstanden habe - ich bin mir nicht sicher und 
möchte nicht lügen -  wird bei search-rom die Adresse durch den Master 
nicht noch einmal aufgerufen. Dann wäre beides in etwa gleich schnell. 
Auf die Abfrage einzelner Sensoren lege ich keinen Wert.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ grundschüler (Gast)

>> - es ist einfach dämlich, immer den Bus zu scannen anstatt den
>> Teilnehmer direkt anzusprechen.


>für mich stellt sich jetzt die Frage, was schneller geht - Abfrage der
>64bit-Adresse durch den Master oder Mitteilung der 64bit-Adresse durch
>den slave.

Ganz einfach. Adressierung des Slave durch den Master. Denn dabei wird 
jedes Bit nur einmal gesendet. Beim ROM-Scan wird jedes Bit 2x gelesen 
und 1x gesendet, ist also ~ 3mal langsamer.

>Auf die Abfrage einzelner Sensoren lege ich keinen Wert.

Ein sehr sinnvolles Konzept . . .

Autor: Patrick J. (ho-bit-hun-ter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Falk B. schrieb:
> Das kann man vielleicht machen, ist aber praktisch wenig sinnvoll.
> Praktisch scannt man EINMAL den Bus und hat dann alle IDs, über welche
> dann die Sensoren direkt adressiert werden.
Der Scan besteht aus mehreren Scans - eigentlich genau so viele 
Durchläufe, wie Sensoren gefunden werden.

Peter D. schrieb:
> D.h. Du stellst Dich nach jedem Stromausfall hin und legst die
> Reihenfolge neu fest. Ansonsten hast Du doch auch nur die Reihenfolge,
> die sich aus den IDs ergibt, nur mit erheblich mehr SRAM-Verbrauch.
Die Einlese-Reihenfolge ergibt sich aus dem Search_ROM-Algorythmus, die 
Sortierung im µC muß damit ja nicht übereinstimmen, denn:

Peter D. schrieb:
> Natürlich. Jeder Sensor hat 2 Byte EEPROM, d.h. Du könntest bis zu 65536
> Meßstellen festlegen.

Hier wollte ich, neben einer eigenen ID, die Abweichung zu einem 
'Master-DS18B20' eintragen, damit ich die Messwerte 'korrigieren' kann.
Angedacht ist dabei auch, daß bei einem Sensortausch der 'Neue' eben so 
vorbereitet wird, daß die Abweichung zum 'Master-DS18B20' bestimmt wird 
(beide Sensoren liegen dicht nebeneinander und weden zyklisch gemessen, 
bis sich keine Differenz-Änderung zwischen Beiden mehr ergibt. Dann wird 
die Differenz ermittelt und als Korrekturwert neben die zuvor 
eingestellte ID ins Eeprom gebrannt.

Denke nicht, daß Das unbedingt nötig ist, selbst, wenn zwei DS18B20 1°C 
auseinander liegen, werde ich davon Nichts meiner Lebenszeit einbüßen - 
nur, wenn schon, denn schon - dann kann das Ding auch 'korrekt' gehen - 
eben mit 'Meinem DS18B20-Eichnormal' abgeglichen.

MfG

Nun muß Das nur noch Wer machen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.