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?
@ 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"
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.
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.
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
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!
@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!
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
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.
1 | unsigned char w1_rom_search( unsigned char diff, unsigned char idata *id ) |
2 | {
|
3 | unsigned char i, j, next_diff; |
4 | char b; |
5 | |
6 | if( w1_reset() ) |
7 | return PRESENCE_ERR; // error, no device found |
8 | w1_byte_wr( SEARCH_ROM ); // ROM search command |
9 | next_diff = LAST_DEVICE; // unchanged on last device |
10 | i = 8 * 8; // 8 bytes |
11 | do{ |
12 | j = 8; // 8 bits |
13 | do{ |
14 | b = w1_bit_io( 1 ); // READ_OW bit |
15 | if( w1_bit_io( 1 ) ){ // READ_OW complement bit |
16 | if( b ) // 11 |
17 | return DATA_ERR; // data error |
18 | }else{ |
19 | if( !b ){ // 00 = 2 devices |
20 | if( diff > i || |
21 | ((*id & 1) && diff != i) ){ |
22 | b = 1; // now 1 |
23 | next_diff = i; // next pass 0 |
24 | }
|
25 | }
|
26 | }
|
27 | w1_bit_io( b ); // WRITE_OW bit |
28 | *id >>= 1; |
29 | if( b ) // store bit |
30 | *id |= 0x80; |
31 | i--; |
32 | }while( --j ); |
33 | id++; // next byte |
34 | }while( i ); |
35 | return next_diff; // to continue search |
36 | }
|
37 | |
38 | void read_meas( void ) |
39 | {
|
40 | uint8_t i; |
41 | u8 id[8], diff; |
42 | int16_t temp; |
43 | |
44 | |
45 | |
46 | for( diff = SEARCH_FIRST; diff != LAST_DEVICE; ){ |
47 | diff = w1_rom_search( diff, id ); |
48 | |
49 | if( diff == PRESENCE_ERR ){ |
50 | //uputsnl( "No Sensor found" );
|
51 | |
52 | ....
|
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.
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.
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 ...
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
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.
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."
@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.
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.
@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?
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.
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
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
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.
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.
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....
@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.
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.
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 ;)
@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!
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..
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.
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.
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
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.
@ 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 . . .
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.