DS18B20 auslesen wird immer langsamer.

Ja wenn man ein solch großes Projekt (80 Sensoren!!!) mit Arduino und 
ner fremden Lib hochzieht, dann muss man sich halt damit abfinden was 
die lib so macht. Man kann ja eine fertige OW lib nehmen, aber die 
Sensorabfrage würde ich in solch einem Fall sicher NIEMALS aus der Hand 
geben. Selber machen, dann weiß man was passiert und kann auf die 
eigenen Anforderungen optimieren.

Aber du nutzt fertiges Zeug und andere sollen jetzt darin rumkramen und 
schauen warum es nicht das tut was du willst? Klar doch.

gruß cyblord

Hei,

cyblord vielen Dank fürs lesen.
Ich hab von keinem verlangt, darin rumzukramen.
Ich habe nur darum gebeten, falls einer nen Hinweis hat.

Auch habe ich schon Stunden über der "fremden" Bibliothek verbracht und 
nicht einfach schnell ne Frage ins Forum geschmissen.

ABER: Ich bin halt noch ziemlicher Anfänger, was die µC Programmierung 
angeht. Dafür klappt es aber schon erstaunlich gut, was ich mir so 
vornehme.
Modbus läuft, Sensoren auslesen läuft, dRGB-Led ansteuern läuft...
Ist halt nur noch das kleine Problem mit der Anzahl der Sensoren.

Also lehn dich zurück, genieße das Leben und nimms mal ein wenig 
lockerer...

Hier noch ein Link auf die DallasTemperature.cpp, fall es sich doch 
jemand antun will:
http://code.google.com/p/dallas-temperature-control-library/source/browse/trunk/DallasTemperature.cpp?r=5


Grüße,

Tom

Ich kann mit Deinem Code auch nichts anfangen.
Ich sehe nur einen Haufen unbekannter Funktionen und Variablen 
unbekannten Typs und nichts davon ist kommentiert.

Daß es immer langsamer wird, kann daran liegen, daß die Sensoren immer 
per ROM-Search durchgezählt werden.
Will man einen bestimmten Sensor auslesen, ohne dessen Adresse zu 
kennen, dann adressiert man quasi alle vorherigen Sensoren und das 
dauert eben.

Will man aber alle auslesen, dann gibt man sie einfach der Reihe nach 
aus, d.h. das ROM-Search adressiert immer den nächsten.
Es muß dafür 2 Funktionen geben:
"ROM-Search-first" liest den ersten Sensor und:
"ROM-Search-next" dann immer den folgenden.
Genaueres sollte in der Doku zu der Arduino-Lib stehen.

Und "Loop" ist ein schlechter Name für eine Funktion, die keine Loop 
enthält, das ist irreführend.


Peter

Hallo Peter,

ich glaube, Du hast mich da auf eine heisse Spur gebracht!

1

// finds an address at a given index on the bus

2

// returns true if the device was found

3

bool DallasTemperature::getAddress(uint8_t* deviceAddress, uint8_t index)

4

{

5

  uint8_t depth = 0;

6

7

  _wire->reset_search();

8

9

  while (depth <= index && _wire->search(deviceAddress))

10

  {

11

    if (depth == index && validAddress(deviceAddress)) return true;

12

    depth++;

13

  }

14

15

  return false;

16

}

Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.
Ich hab sie zwar noch nicht ganz kapiert, scheint aber so wie Du 
schreibst, dass er da erstmal alle Sensoren durchgeht, bis er die 
passende Adresse findet.

Ich werde jetzt einfach mal zu Beginn meines Programms alle gefundenen 
Adressen in ein Array speichern, (sofern soviel Speicher zur 
Verfügung...) und dann nur noch mit den Adressen statt den Indexes 
arbeiten.

Melde mich, wenn ich es ausprobiert habe.
Schon mal vielen Dank!


Grüße,

Tom

Hallo Bernd,

hast ja eigentlich recht. ;-)
(Mit dem Forum)

Ja alle Sensoren sind auf 12bit eingestellt.
Wenn alle die gleiche Temperatur haben,
(Was wirklich schwierig ist!) dann weichen die Werte gerade mal so 0,2K 
von einander ab. Bin begeistert, wie genau die Sensoren sind.


Grüße,

Tom

bernd59 schrieb:

> Da sind sie auch netter:)
Aber können halt nix:
social skills don't pay any bills

gruß cyblord

Tom P. schrieb:
> Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.

Es hindert Dich niemand daran, sie nicht zu benutzen.
Du brauchst immer nur einen Paß aufrufen und dann den adressierten 
Sensor auslesen.
Es ist schon ein deutlicher Unterschied, ob man n * die Zeit braucht 
oder n*(n+1)/2.

Hier mal ein Code ohne die A-Lib:

Beitrag "DS1820, DS18B20 in C"


Peter

Peter Dannegger schrieb:
> Tom P. schrieb:
>> Diese Funktion wird bei jedem Mal Sensor-Auslesen aufgerufen.
>
> Es hindert Dich niemand daran, sie nicht zu benutzen.

Doch! Mein Unwissen hat mich dran gehindert. :-)
Problem erkannt, Problem gebannt. So hoffe ich zumindest.
Vielen Dank Peter, für den Hinweis!
Dafür ist doch ein Forum super, dass man mal andere Sichtweisen 
aufgezeigt bekommt.
Manche Stänkerer sind halt dabei, aber die kann man ja einfach 
"überlesen"... ;-)


Grüße,

Tom

Hei,

danke Bernd und vor allem Peter.
Jetzt fetzt es.
Bis aufs erste Mal Adressen auslesen und abspeichern.
Aber "langes booten" ist man ja von Windows gewohnt LOL


Dann steht meinem "großen Projekt (80 Sensoren!!!) " ja nichts mehr im 
Wege.
Hehe, naja soo groß ist das nun auch wieder nicht...


Grüße,

Tom

Hallo,

ich bin ganz neu hier und über die Suche nach DS18B20 und 1-wire auf 
diesen Threat gestoßen. Ich weiß der ist eigentlich Steinzeit aber ich 
steh grad vor der selben Herausforderung.
Vielleicht ist Tom so nett und zeigt mal die Lösung? :)

Vielen Dank im Voraus

Henrik

Hei,

na die Lösung steht doch schon ein paar Beiträge weiter oben!
Beitrag "Re: DS18B20 auslesen wird immer langsamer."


Grüße,

Tom

Danke für die schnelle Antwort Tom :)

Ich meinte diesen Abschnitt:
"Ich werde jetzt einfach mal zu Beginn meines Programms alle gefundenen
Adressen in ein Array speichern, (sofern soviel Speicher zur
Verfügung...) und dann nur noch mit den Adressen statt den Indexes
arbeiten."

Viele Grüße
Henrik

Hei,

genau das ist die Lösung. Mach es doch auch so.
Den Code dazu habe ich leider nicht mehr zur Hand.
Aber da war ich noch blutiger Anfänger und habe das geschafft.
Kann also nicht schwierig gewesen sein. ;-)


Grüße,

Tom

Danke

Hi

Das ist aber doch 'Quatsch' - wenn ich Das Mal so nennen darf.
Im Datenblatt der Sensoren sollte enthalten sein, wie man den ROM_Search 
benutzt.
Diese Funktion richtig angewendet findet IMMER den NÄCHSTEN Sensor - 
wenn's keinen Hinteren mehr gibt, wird der Erste wieder gefunden.
(zumindest in meinem in in ASM auf einem ATtiny45 nachgebautem Programm)

Hat natürlich auch einen Nachteil:
Man weiß nie, Welcher Sensor wann an die Reihe kommt (da die Reihenfolge 
sich aus den IDs ableitet, die Richtung aber 'verkehrt herum' ist.
Theoretisch müssten die IDs, binär notiert und umgedreht, dann sortiert, 
die Reihenfolge der Funde ergeben - habe ich mir gerade zusammen gereimt 
(also ungetestet, klingt aber recht gut).
Nebenbei würfelt es Dir die Reihenfolge durcheinander, wenn Du einen 
neuen Sensor einsetzt oder ein Sensor getauscht werden muß - dann sogar 
2x!!

Selber habe ich angedacht, in den User-Bytes eine Sensor-ID und einen 
Korrekturwert einzutragen -ä da die Sensoren zwar 1/16tel °C Auflösung 
haben, aber (glaub) nur 0,5°C Genauigkeit.
Wenn man jetzt die Abweichung zu einem Master-Sensor in den 
Slave-Sensoren einträgt, kann man Diese immer Korrekturrechnen.
Auch kann man dann gezielt Sensoren austauschen - der Getauschte braucht 
'nur' die gleiche ID wie der Auszutauschende.

Und - man sucht zwar immer noch die I2C-IDs durch, selektiert aber nach 
der enthaltenen ID.

Sollte Das Alles nicht zu Deinem Problem passen - hast Du vll. bei den 
'hinteren Sensoren' die volle Auflösung (12bit) und bei den schnellen 
'Vorderen' vll. nur 9bit?

MfG