Hallo allesamt Ich möchte ein bisschen mit 1-Wire Sensoren rumbasteln und habe daher ein paar Fragen zum Protokoll. Ich habe momentan noch keinen Logikanalysator und habe deswegen das Protokoll schon mal weitesgehend durchgearbeitet und Aktivitätsdiagramme für meine Programme gezeichnet. Ich erhoffe mir davon, dass ich dann die meisten Fehler garnicht erst mache :) Mein Diagramme habe ich in den Anhang gepackt? Kennt sich irgendjemand mit dem Thema aus? Und könnte vielleicht einmal drüber gucken, ob ich in diesem Schritt schon Fehler gemacht habe, oder ob ichs richtig verstanden habe? Konkret handelt es sich momentan um den Temperatur-Sensor DS18B20, von dem ich in meinen Diagrammen auch einige Funktionen benutze. Geplant ist momentan, dass ich vorher jeweils nacheinander immer einen Sensor an die Schaltung anschließe, die ID auslese und diese dann später hart im Programm codiere. Deshalb starte ich auch direkt mit dem Match Rom - Befehl. Was mir momentan allerdings nicht klar ist, ist wie ich es schaffe die ID des angeschlossenen Sensors auszulesen? So weit ich weiß nutzt man hierfür den den READ ROM - Befehl (bzw. SEARCH ROM bei mehreren Sensoren): Allerdingsist mir nicht klar, wie genau der Sensor hierauf antwortet. Kennst sich jemand mit dem Thema aus? Im Anhang habe ich auch noch mal meine Quellen angehängt. Viele Grüße Anon1234
schau mal hier: Beitrag "Vereinfache/Kompakte Libary für D18B20" Deine Ablaufdiagramme sind "nett" aber berücksichtigen keine Fehlerfälle (der Regelfall macht 90% des Codes aus, die Fehlerfälle die anderen 90% :-) 1wire ist nicht ganz trivial (vor allem das Enumerieren), und wenn man es so genial macht wie Peter Danegger, wird es noch un-trivialer...
Michael Reinelt schrieb: > (der Regelfall macht 90% des Codes aus, die Fehlerfälle die anderen 90% > :-) Komisch, bei mir ist das genau umgekehrt.
Marc Vesely schrieb: > Michael Reinelt schrieb: >> (der Regelfall macht 90% des Codes aus, die Fehlerfälle die anderen 90% >> :-) > > Komisch, bei mir ist das genau umgekehrt. Du hast recht, bei mir schwankt es auch. Vor allem abhängig von meiner Lederallergie.
Michael Reinelt schrieb: > schau mal hier: Beitrag "Vereinfache/Kompakte Libary für D18B20" > > Deine Ablaufdiagramme sind "nett" aber berücksichtigen keine Fehlerfälle > (der Regelfall macht 90% des Codes aus, die Fehlerfälle die anderen 90% > :-) Alles klar, danke für den Tipp, das werde ich mir dann mal angucken. Um was für Fehlerfälle handelt es sich dann hier? Sind dass dann Arbitrationfehler auf dem Bus, oder einfachh Fehler beim Enumerieren. Davon hab ich nämlich in den Datenblättern nichts gelesen. Weißt du wo ich mich darüber informieren kann?
Anon Anon schrieb: > Um was für Fehlerfälle handelt es sich dann hier? z.B. Kurzschluss-Erkennung beim detektieren des "presence pulse", oder beim enumerieren bit und komplementärbit beide 1. Mehr gibts aber glaub ich eh nicht.
Michael Reinelt schrieb: > schau mal hier: Beitrag "Vereinfache/Kompakte Libary für D18B20" Die Libary sieht ganz gut aus :) Aber weiß jemand wo ich diese Header-Dateien herbekomme: #include <stdlib.h> #include <stdint.h> #include <math.h> #include <util/delay.h> #include <util/atomic.h>
Anon Anon schrieb: > Aber weiß jemand wo ich diese Header-Dateien herbekomme: > #include <stdlib.h> > #include <stdint.h> > #include <math.h> > #include <util/delay.h> > #include <util/atomic.h> Die Frage wundert mich, weil das sind nur Standard-Header der GCC-AVR-Toolchain... Lass mich die Frage umdrehen: Wie sieht deine Entwicklungsumgebung aus? Womit compilierst du normalerweise?
Michael Reinelt schrieb: > Lass mich die Frage umdrehen: Wie sieht deine Entwicklungsumgebung aus? > Womit compilierst du normalerweise? Ich entwickle und compiliere mit Keil µVision. Allerdings mit einem 8051-Derivat. mit AVR kenne ich mich momentan noch nicht aus. (Also den Code kann ich schon lesen und verstehen, aber mehr hab ich mich da auch noch nicht reingearbeitet)
Anon Anon schrieb: > Ich entwickle und compiliere mit Keil µVision. Allerdings mit einem > 8051-Derivat. Sorry, damit kenn ich mich jetzt wieder gar nicht aus... > #include <stdlib.h> sollte der keil auch haben, sogar im Standard-Include-Pfad > #include <stdint.h> detto > #include <math.h> wird nur für float-berechnungen verwendet > #include <util/delay.h> das ist sehr AVR-Spezifisch, brauchst aber nur für die _dely_us() funktion, und es wird sicher was vergleichbares bei dir geben > #include <util/atomic.h> wird dzt. gar nciht verwendet
hey... hat zwar etwas gedauert, weil ich die letzte woche nicht so viel hatte, aber ich habe jetzt mal einen beispiel-code für den at89s52 geschrieben : meint ihr das passt jetzt so? die kurzschluss-abfrage habe ich jetzt auch eingebaut.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
84 | |
85 | |
86 | |
87 | |
88 | |
89 | |
90 | |
91 | |
92 | |
93 | |
94 | |
95 | |
96 | |
97 | |
98 | |
99 | |
100 | |
101 | |
102 | |
103 | |
104 | |
105 | |
106 | |
107 | |
108 | |
109 | |
110 | |
111 | |
112 | |
113 | |
114 | |
115 | |
116 | |
117 | |
118 | |
119 | |
120 | |
121 | |
122 | |
123 | |
124 | |
125 | |
126 | |
127 | |
128 | |
129 | |
130 | |
131 | |
132 | |
133 | |
134 | |
135 | |
136 | |
137 | |
138 | |
139 | |
140 | |
141 | |
142 | |
143 | |
144 | |
145 | |
146 | |
147 | |
148 | |
149 | |
150 | |
151 | |
152 | |
153 | |
154 | |
155 | |
156 | |
157 | |
158 | |
159 | |
160 | |
161 | |
162 | |
163 | |
164 | |
165 | |
166 | |
167 | |
168 | |
169 | |
170 | |
171 | |
172 | |
173 | |
174 | |
175 | |
176 | |
177 | |
178 | |
179 | |
180 | |
181 | |
182 | |
183 | |
184 | |
185 | |
186 | |
187 | |
188 | |
189 | |
190 | |
191 | |
192 | |
193 | |
194 | |
195 | |
196 | |
197 | |
198 | |
199 | |
200 | |
201 | |
202 | |
203 | |
204 | |
205 | |
206 | |
207 | |
208 | |
209 | |
210 | |
211 | |
212 | |
213 | |
214 | |
215 | |
216 | |
217 | |
218 | |
219 | |
220 | |
221 | |
222 | |
223 | |
224 | |
225 | |
226 | |
227 | |
228 | |
229 | |
230 | |
231 | |
232 | |
233 | |
234 | |
235 | |
236 | |
237 | |
238 | |
239 | |
240 | |
241 | |
242 | |
243 | |
244 | |
245 | |
246 | |
247 | |
248 | |
249 | |
250 | |
251 | |
252 | |
253 | |
254 | |
255 | |
256 | |
257 | |
258 | |
259 | |
260 | |
261 | |
262 | |
263 | |
264 | |
265 | |
266 | |
267 | |
268 | |
269 | |
270 | |
271 | |
272 | |
273 | |
274 | |
275 | |
276 | |
277 | |
278 | |
279 | |
280 | |
281 | |
282 | |
283 | |
284 | |
285 | |
286 | |
287 | |
288 | |
289 | |
290 | |
291 | |
292 | |
293 | |
294 | |
295 | |
296 | |
297 | |
298 | |
299 | |
300 | |
301 | |
302 | |
303 | |
304 | |
305 | |
306 | |
307 | |
308 | |
309 | |
310 | |
311 | |
312 | |
313 | |
314 | |
315 | |
316 | |
317 | |
318 | |
319 | |
320 | |
321 | |
322 | |
323 | |
324 | |
325 | |
326 | |
327 | |
328 | |
329 | |
330 | |
331 | |
332 | |
333 | |
334 | |
335 | |
336 | |
337 | |
338 | |
339 | |
340 | |
341 | |
ich gehe davon aus, dass die adressen für die ds18b20-Geräte bekannt sind und diese im code später fest-codiert werden. allerdings weiß ich noch nicht, wie ich die adressen am einfachsten auslesen kann. Das prinzip vom search-rom habe ich nämlich momentan noch nicht ganz verstanden. kann mir hier jemand weiter helfen? alternativ habe ich überlegt mit den fertigen libraries von arduino die addressen auszulesen.
Anon Anon schrieb: > Das prinzip vom search-rom habe ich nämlich momentan noch nicht ganz > verstanden. mit "SearchRom 0xF0" kannst du den ROM-Code von allen Slaves am Bus ermitteln das erfordert aber einiges an Software einfacher ist der Befehl "ReadROM 0x33" der ließt direkt den ROM-Code vom angeschlossenen Slave aus (allerdings darf zu diesem Zeitpunkt nur EIN Slave am Bus hängen) Ablauf. 1. Reset Sequenz 2. den Befehl "ReadRom" senden 3. 8Bytes lesen (das ist dann der 48bit ROM-Code vom Slave) Gruss Uwe
Für einen einzelnen Sensor (pro Leitung) benötigt man die Adresse überhaupt nicht. Da tut es auch SKIP ROM. Wär sinnvoll, damit anzufangen.
Anon Anon schrieb: > ich habe jetzt mal einen beispiel-code für den at89s52 geschrieben : Längerer Code passt besser in einen Anhang.
Uwe B. schrieb: > einfacher ist der Befehl "ReadROM 0x33" der ließt direkt den > ROM-Code vom angeschlossenen Slave aus > (allerdings darf zu diesem Zeitpunkt nur EIN Slave am Bus hängen) > > Ablauf. > 1. Reset Sequenz > 2. den Befehl "ReadRom" senden > 3. 8Bytes lesen (das ist dann der 48bit ROM-Code vom Slave) Hi Uwe, danke für die schnelle und gute Antwort. Das werde ich dann nacher gleich mal ausprobieren :) Du meinst aber sicherlich 64Bit oder? A. K. schrieb: > Längerer Code passt besser in einen Anhang. Alles klar, denke ich nächstes mal dran :)
Anon Anon schrieb: > Du meinst aber sicherlich 64Bit oder? ja...sorry war ein Tipfehler ROM-Code = 8 Bytes (64bit) 8bit : Family Code 48bit : Ser-Nr 8bit : CRC P.S. im Datasheet vom Dallas DS1820 ist ein Beispiel beschrieben wie man einen ROM-Search implementiert (in Textform) kannst da ja mal nachlesen falls du das auch implementieren willst
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.