Mein aktuelles Problem habe ich hier bereits beschrieben:
Beitrag "Re: DS1820, DS18B20 in C"
Ich habe mich bereits schon die ganze Zeit gewundert wie mehrere 1-Wire
Clients auf dem Bus nacheinander identifiziert und direkt ausgelesen
werden können.
In dem Code wird nämlich der SEARCH ROM Befehl verwendet und direkt
danach die Sensordaten abgefragt.
Allerdings steht in der Dokumentation:
1
When a system is initially powered up, the master must identify the ROM codes of all slave devices on
2
the bus, which allows the master to determine the number of slaves and their device types. The master
3
learns the ROM codes through a process of elimination that requires the master to perform a Search ROM
4
cycle (i.e., Search ROM command followed by data exchange) as many times as necessary to identify all
5
of the slave devices.
Ich verstehe den Text so das zunächst einmal der Master mit dem SEARCH
ROM Befehl alle ID's der Slaves auf dem Bus lernen soll.
Danach sollen die Slaves gezielt mit der ID adressiert werden.
Da dies in dem Code so nicht getan wird, wäre doch ein guter Grund
gegeben warum das auslesen mehrerer Sensoren so schlecht funktioniert !?
Vielleicht ist es mehr oder weniger Zufall das die bisherige
Vorgehensweise in dem Code bei mehreren Slaves überhaupt funktioniert?
Sehe ich das falsch?
In dem IButton Dokument steht zwar das man mit dem Search auch
adressieren kann, aber weiter unten in dem Text steht wieder das der
Master die ID's lernt.
1
C.3. Search ROM Command
2
Even if the master does not know the serial numbers of
3
the devices connected to the 1–Wire bus, it is possible
4
to address one single device at a time. This is done by
5
using the command Search ROM, code F0H.
6
...
7
After the first
8
stage of selection, 63 reading/selecting cycles will fol-
9
low, until finally the master has learned one device’s
10
ROM code and simultaneously has addressed it.
Daher gehe ich davon aus das es so gedacht ist das man mehrere Slaves
immer gezielt über ihre ID adressiert.
Vorab: ich habe dein Programm nicht gelesen.
Karsten M. schrieb:> Ich verstehe den Text so das zunächst einmal der Master mit dem SEARCH> ROM Befehl alle ID's der Slaves auf dem Bus lernen soll.> Danach sollen die Slaves gezielt mit der ID adressiert werden.>> Da dies in dem Code so nicht getan wird, wäre doch ein guter Grund> gegeben warum das auslesen mehrerer Sensoren so schlecht funktioniert !?
Es ist ja gut und schön, wenn die Software das Knäul von DSxxx
identifiziert,
deshalb kenne ich aber nicht die Position der einzelnen Sensoren.
In der Praxis nützt mir das nix.
Ich lese deshalb die ID eines einzelnen Sensors aus, bapp dem die Nummer
drauf und notiere wo der verbaut ist.
Karsten M. schrieb:> Daher gehe ich davon aus das es so gedacht ist das man mehrere Slaves> immer gezielt über ihre ID adressiert.
Wie soll es sonst gehen? Einen einzelnen DS kann man mit "read Rom"
lesen, sind es mehrere, dann sendet man das "Match Rom" und die ID des
Sensors den man auslesen will.
Jörn P. schrieb:> Wie soll es sonst gehen? Einen einzelnen DS kann man mit "read Rom"> lesen, sind es mehrere, dann sendet man das "Match Rom" und die ID des> Sensors den man auslesen will.
Ich habe wie viele andere diese Firmware hier verwendet.
Beitrag "Re: DS1820, DS18B20 in C"
Diese Firmware benutzt nur den Befehl "Search Rom" um die Sensoren
nacheinander auszulesen.
Offensichtlich funktioniert dies nicht zuverlässig.
Der Befehl "Match Rom" ist in der Firmware so nicht implementiert.
Gibt es irgendwo eine Firmware für den avr-gcc die vollständig ist?
Sonst kann ich nur diese Firmware hier für Arduino anpassen:
http://www.pjrc.com/teensy/td_libs_OneWire.html
@Karsten M. (lsmod)
>Ich habe wie viele andere diese Firmware hier verwendet.>Beitrag "Re: DS1820, DS18B20 in C"
Sagt doch gleich, daß du wahrscheinlich ein Hardwareproblem hast!
Beitrag "Re: DS1820, DS18B20 in C"
"Nun möchte ich allerdings 3 (max. 5) Sensoren an dem gleichen 1Wire-Bus
auslesen und ich habe dabei große Probleme.
Interessanterweise funktioniert das Auslesen von 3 Sensoren problemlos
im Laborbetrieb auf dem Schreibtisch!
In eingebautem Zustand sind die Sensoren aber über ein ca. 5m langes
CAT5 Kabel angeschlossen, von dem 3 Leitungen benutzt werden. 5V, Data
und GND (Schirmung ist ebenfalls an GND).
Am Ende des CAT5 Kabel sind noch 300 nF Blockkondensatoren und von dort
aus gehen jeweils 3 Leitungen mit ca. 1m zu jeweils einem Sensor."
>Diese Firmware benutzt nur den Befehl "Search Rom" um die Sensoren>nacheinander auszulesen.>Offensichtlich funktioniert dies nicht zuverlässig.
Was aber an der Hardware liegt!
>Der Befehl "Match Rom" ist in der Firmware so nicht implementiert.
Ist auch egal. Wenn dein Bus auf der Hardwareebene nicht solide läuft,
nützt der dir auch nichts.
>Gibt es irgendwo eine Firmware für den avr-gcc die vollständig ist?
Ist es diese Software nicht?
Aber ja, es gibt noch andere.
Beitrag "Onewire + DS18x20 Library"
Kürze deine Kabel schrittweise ein. Im Idealfall mißt du mal an den
Sensoren mit einem Oszilloskop. 5m sind schon recht viel, da muss man
einen möglichst kleinen Pull-Up Widerstand nutzen, so 1,5kOhm.
"Am Ende des CAT5 Kabel sind noch 300 nF Blockkondensatoren und von dort
aus gehen jeweils 3 Leitungen mit ca. 1m zu jeweils einem Sensor."
Auch das ist Unsinn, die 100nF gehören DIREKT an die 3 Sensoren, 10mm
Abstand und weniger!!!
Falk B. schrieb:> Was aber an der Hardware liegt!
Die aber leider bereits fest verbaut ist.
Z.B. in Form von verklebten vergossenen Sensoren.
Die hatte ich vorher selbstverständlich einzeln getestet und die liefen
problemlos.
>>Gibt es irgendwo eine Firmware für den avr-gcc die vollständig ist?>> Ist es diese Software nicht?
Leider nicht.
> Aber ja, es gibt noch andere.> Beitrag "Onewire + DS18x20 Library"
Super - Danke für den Link.
Die probiere ich gleich Mal aus.
> Kürze deine Kabel schrittweise ein. Im Idealfall mißt du mal an den> Sensoren mit einem Oszilloskop.
Es ist schwierig die Kabel einzukürzen, wenn sowohl die Sensoren als
auch der ansteuernde Mega8 fest verbaut sind. ;-)
Entweder klappt es mit der neuen Firmware oder dieser Teil der
Gesamtfunktion fällt flach.
Alternativ könnte ich höchstens noch einen weiteren Mega8 direkt an die
Sensoren setzen und anbinden.
> 5m sind schon recht viel, da muss man> einen möglichst kleinen Pull-Up Widerstand nutzen, so 1,5kOhm.
5m sind viel?
Für den 1Wire-Bus ist eine maximale Länge von 100m angegeben!
Den Pullup-Widerstand kann ich natürlich noch Mal herabsetzen.
Ich hatte allerdings bereits schon erfolglos einen 1K Widerstand
ausprobiert, der keine Verbesserung erbracht hatte.
Falk B. schrieb:> Auch das ist Unsinn, die 100nF gehören DIREKT an die 3 Sensoren, 10mm> Abstand und weniger!!!
Das ist mir schon klar - aber zeige mir Mal wie Du das bei vergossenen
Sensoren bewerkstelligen willst? :-)
@ Karsten M. (lsmod)
>Die aber leider bereits fest verbaut ist.>Z.B. in Form von verklebten vergossenen Sensoren.
Zumindest kannst du erstmal das 5m CAT-Kabel weglassen und neu testen.
>Die hatte ich vorher selbstverständlich einzeln getestet und die liefen>problemlos.
Wie hast du EXAKT getestet? Immer nur einen Sensor am Bus oder alle
drei?
>> Ist es diese Software nicht?>Leider nicht.
Was fehlt denn?
>Es ist schwierig die Kabel einzukürzen, wenn sowohl die Sensoren als>auch der ansteuernde Mega8 fest verbaut sind. ;-)
Dann besorg dir einen 2. AVR.
>Entweder klappt es mit der neuen Firmware oder dieser Teil der>Gesamtfunktion fällt flach.
So kann man ein Problem auch "lösen" 8-(
>5m sind viel?>Für den 1Wire-Bus ist eine maximale Länge von 100m angegeben!
???
Kaum. Wo soll das stehen?
>Den Pullup-Widerstand kann ich natürlich noch Mal herabsetzen.>Ich hatte allerdings bereits schon erfolglos einen 1K Widerstand>ausprobiert, der keine Verbesserung erbracht hatte.
Ohne Oszi ist das ein Blindflug.
Falk B. schrieb:> @ Karsten M. (lsmod)> Wie hast du EXAKT getestet? Immer nur einen Sensor am Bus oder alle> drei?
Ich hatte unter Laborbedingungen bis zu 3 Sensoren angeschlossen.
>>> Ist es diese Software nicht?>>>Leider nicht.>> Was fehlt denn?
Ein auslesen der Sensoren mit Match Rom.
>>Es ist schwierig die Kabel einzukürzen, wenn sowohl die Sensoren als>>auch der ansteuernde Mega8 fest verbaut sind. ;-)>> Dann besorg dir einen 2. AVR.
Habe ich - aber mich interessiert nun die Frage ob das Problem mit einer
anderen Firmware lösbar ist.
> So kann man ein Problem auch "lösen" 8-(
Ja - denn es ist nur ein Teil der Gesamtfunktionalität.
Daher kann ich die Steuerung auch nicht verlagern.
>>5m sind viel?>>Für den 1Wire-Bus ist eine maximale Länge von 100m angegeben!>> ???> Kaum. Wo soll das stehen?https://de.wikipedia.org/wiki/1-Wire
1
Die Verkabelung kann über ein einfaches Kabel bzw. eine einzelne Leitung auf einer Platine erfolgen.
2
Mit einem passiven Pull-up-Widerstand sind so Leitungslängen von bis zu 100 m mit 150 1-Wire-Geräten möglich.
This interface works with large and small 1-Wire networks equally well,
2
and can reliably operate a network with high weight and radius values up to 500m.
>>Den Pullup-Widerstand kann ich natürlich noch Mal herabsetzen.>>Ich hatte allerdings bereits schon erfolglos einen 1K Widerstand>>ausprobiert, der keine Verbesserung erbracht hatte.>> Ohne Oszi ist das ein Blindflug.
Das stimmt - aber da ich das Kabel nun sowieso nicht mehr ändern werde
muss auch ein Blindflug genügen.
Na gut - wenn Deine Firmware keine Verbesserung bringt dann werde ich
wohl schon alleine aus Neugier den Blindflug gegen einen
Instrumentenflug tauschen ...
ich habe circa 20 Sensoren in einem wirren Netzwerk mit mindestens 20m
über das ganze Haus verteilt. das funktioniert ohne Kondensatoren
zuverlässig.
Die Sensoren werden in einem Durchgang ausgelesen und die Messwerte den
gespeicherten IDs zugeordnet. Interessieren würde mich die Reihenfolge
der Meldung der einzelnen Sensoren. Ist das Zufall oder haben die
Sensoren entsprechend der ID verschiedene Wartezeiten, nach denen sie
einen Versuch starten, ob der Bus frei ist? Was passiert wenn sich zwei
Sensoren exakt gleichzeitig melden?
@ Karsten M. (lsmod)
>Ich hatte unter Laborbedingungen bis zu 3 Sensoren angeschlossen.
Aber ohne die 5m Zusatzkabel? Mensch, laß dir doch nicht jede Wort aus
der Nase ziehen!!
https://www.mikrocontroller.net/articles/Netiquette#Klare_Beschreibung_des_Problems
" Daran denken, dass die Leute im Forum nicht neben einem sitzen und
alles so vor sich sehen wie der Fragesteller"
>> Was fehlt denn?>Ein auslesen der Sensoren mit Match Rom.
OK.
>Habe ich - aber mich interessiert nun die Frage ob das Problem mit einer>anderen Firmware lösbar ist.
Deine Hardwareprobleme löst eine andere Software auch nicht.
>Ja - denn es ist nur ein Teil der Gesamtfunktionalität.>Daher kann ich die Steuerung auch nicht verlagern.
Sollst du auch gar nicht. Aber man kann Übertragungsstörungen finden und
beheben, wenn man denn Know How und Ausdauer hat.
>https://www.maximintegrated.com/en/app-notes/index...>This interface works with large and small 1-Wire networks equally well, >and can
reliably operate a network with high weight and radius values up >to 500m.
Das geht aber nur mit diversen Anpassungen und Treibern.
Egal, 5m sollten trotzdem funktionieren.
>Das stimmt - aber da ich das Kabel nun sowieso nicht mehr ändern werde>muss auch ein Blindflug genügen.
Es muss gar nichts. Du willst ein Problem lösen, ohne etwas dafür zu
tun. Das wird nicht funktionieren.
>Na gut - wenn Deine Firmware keine Verbesserung bringt dann werde ich>wohl schon alleine aus Neugier den Blindflug gegen einen>Instrumentenflug tauschen ...
Eine weise Entscheidung.
grundschüler schrieb:> ich habe circa 20 Sensoren in einem wirren Netzwerk mit mindestens 20m> über das ganze Haus verteilt. das funktioniert ohne Kondensatoren> zuverlässig.
Mit welcher Firmware?
> Die Sensoren werden in einem Durchgang ausgelesen und die Messwerte den> gespeicherten IDs zugeordnet. Interessieren würde mich die Reihenfolge> der Meldung der einzelnen Sensoren. Ist das Zufall oder haben die> Sensoren entsprechend der ID verschiedene Wartezeiten, nach denen sie> einen Versuch starten, ob der Bus frei ist? Was passiert wenn sich zwei> Sensoren exakt gleichzeitig melden?
Soweit ich es verstanden habe wird die ID Bit für Bit ausgelesen und der
Master gibt jeweils bei einem Bit vor ob er gerade einen Sensor mit 1
oder 0 hören möchte. Alle anderen schweigen dann.
So können alle Adressen durchgegangen werden.
Ich sehe zur Zeit nur:
28FFAFF1351603A5
281B9F5D05000015
Dieser hier wird nicht mehr erkannt:
28...0467
Falk B. schrieb:> @ Karsten M. (lsmod)>>>Ich hatte unter Laborbedingungen bis zu 3 Sensoren angeschlossen.>> Aber ohne die 5m Zusatzkabel? Mensch, laß dir doch nicht jede Wort aus> der Nase ziehen!!
Den Link auf meine Problembeschreibung hatte ich oben als erstes
genannt!
> " Daran denken, dass die Leute im Forum nicht neben einem sitzen und> alles so vor sich sehen wie der Fragesteller"
Dann hätte ich die Problembeschreibung hier noch einmal komplett
wiederholen müssen.
Ich wollte die Redundanz vermeiden. ;-)
Es war nicht böswillig gemeint.
> Deine Hardwareprobleme löst eine andere Software auch nicht.
Man darf die Hoffnung nie aufgeben.
Auf jeden Fall möchte ich eine vollständige 1Wire Implementierung
ausprobieren.
Bei der Library hast Du Dir Dein Bier auf jeden Fall schon verdient!
Allerdings ist das Beispiel für die Benutzung schon eher einen Tick zu
ausführlich.
Wie kann ich denn erst einmal einen Sensorscan durchführen und die ID's
ausgeben?
> Sollst du auch gar nicht. Aber man kann Übertragungsstörungen finden und> beheben, wenn man denn Know How und Ausdauer hat.
Ein CAT5 Kabel hat sich bei der RS485 bereits sehr gut auf deutlich
längeren Leitungen bewährt.
Ich bin eindeutig zu faul die Verdrahtung wieder auseinanderzudröseln.
;-)
Einige Verbindungen sind zudem verdammt schlecht erreichbar.
>>https://www.maximintegrated.com/en/app-notes/index...>>>This interface works with large and small 1-Wire networks equally well, >and can> reliably operate a network with high weight and radius values up >to 500m.>> Das geht aber nur mit diversen Anpassungen und Treibern.>> Egal, 5m sollten trotzdem funktionieren.
Meine Rede!
> Es muss gar nichts. Du willst ein Problem lösen, ohne etwas dafür zu> tun. Das wird nicht funktionieren.
Da bin ich doch tatkräftig dabei oder nicht? :-)
> Eine weise Entscheidung.
Danke!
@Karsten M. (lsmod)
>Soweit ich es verstanden habe wird die ID Bit für Bit ausgelesen und der>Master gibt jeweils bei einem Bit vor ob er gerade einen Sensor mit 1>oder 0 hören möchte. Alle anderen schweigen dann.>So können alle Adressen durchgegangen werden.
Ja.
>Ich sehe zur Zeit nur:>28FFAFF1351603A5>281B9F5D05000015
OK.
>Dieser hier wird nicht mehr erkannt:>28...0467
Defekt? Wackelkontakt? Kalte Lötstelle? Kurzschluß?
Kannst du den Sensor auslesen, wenn du die anderen abklemmst? Hast du
mal den Anschluß geprüft bzw. getrennt und neu verlötet?
Ich hab hier gerade mal mit meinem Testaufbau einen DS1820 an 5m Kabel
geklemmt, geht problemlos. Pull-Up ist 4k7. Wie das Signal aussieht weiß
ich nicht, hab im Moment kein Oszi parat.
@Karsten M. (lsmod)
>Allerdings ist das Beispiel für die Benutzung schon eher einen Tick zu>ausführlich.
??
>Wie kann ich denn erst einmal einen Sensorscan durchführen und die ID's>ausgeben?
Steht doch ziemlich weit oben im Programm. Dort wird der gesamt Bus
gescannt und die IDs ausgegeben.
1
// multiple devices on bus, access only with ROM code
2
3
rc=scan_bus(roms,ONEWIRE_SEARCH_ROM);
>Ein CAT5 Kabel hat sich bei der RS485 bereits sehr gut auf deutlich>längeren Leitungen bewährt.
Das bezweifelt doch keiner. Trotzdem kann dort ein Problem liegen, vor
allem in den Verbindungen.
>Ich bin eindeutig zu faul die Verdrahtung wieder auseinanderzudröseln.>;-)>Einige Verbindungen sind zudem verdammt schlecht erreichbar.
Nur mit Handauflegen wird das nix. Du musst die die Hände auch ein
bisschen schmutzig machen.
Falk B. schrieb:> Defekt? Wackelkontakt? Kalte Lötstelle? Kurzschluß?
Er lief problemlos bis der 3. Sensor hinzugekommen ist.
(281B9F5D05000015)
> Kannst du den Sensor auslesen, wenn du die anderen abklemmst? Hast du> mal den Anschluß geprüft bzw. getrennt und neu verlötet?
Nein kann ich nicht.
Die Verbindung liegt an einer Stelle die sehr schwer zugänglich ist!
> Nur mit Handauflegen wird das nix. Du musst die die Hände auch ein> bisschen schmutzig machen.
Schmutzig ist nicht das Problem.
Um da drann zu kommen handelt man sich eher derbe Verspannungen ein. ;-)
> Ich hab hier gerade mal mit meinem Testaufbau einen DS1820 an 5m Kabel> geklemmt, geht problemlos. Pull-Up ist 4k7. Wie das Signal aussieht weiß> ich nicht, hab im Moment kein Oszi parat.
Unser lieber grundschüler kann auch 20 Sensoren auslesen.
> Steht doch ziemlich weit oben im Programm. Dort wird der gesamt Bus> gescannt und die IDs ausgegeben.
rc = scan_bus(roms, ONEWIRE_SEARCH_ROM);
Sorry - das kann ich in dem "onewire_demo.ino" nicht finden!
Habe ich das falsche Archiv heruntergeladen?
@Karsten M. (lsmod)
>> Defekt? Wackelkontakt? Kalte Lötstelle? Kurzschluß?>Er lief problemlos bis der 3. Sensor hinzugekommen ist.>(281B9F5D05000015)
Na dann liegt die Vermutung wohl nah, daß dort das Problem liegt!
>> Kannst du den Sensor auslesen, wenn du die anderen abklemmst? Hast du>> mal den Anschluß geprüft bzw. getrennt und neu verlötet?>Nein kann ich nicht.>Die Verbindung liegt an einer Stelle die sehr schwer zugänglich ist!
Ja und? Glaubst du mit Jammern und "geht nicht, zu schwierig" wird sich
das Problem in Luft auflösen?
>rc = scan_bus(roms, ONEWIRE_SEARCH_ROM);>Sorry - das kann ich in dem "onewire_demo.ino" nicht finden!
Bitte? Zeile 221!
>Habe ich das falsche Archiv heruntergeladen?
Hmm, stimmt. Mein erster Link ist die alte Version. Das hier ist die
aktuelle. ;-)
Beitrag "Re: Onewire + DS18x20 Library"
Falk B. schrieb:> Ja und? Glaubst du mit Jammern und "geht nicht, zu schwierig" wird sich> das Problem in Luft auflösen?
Ja! :-)
Nun lasse mich doch bitte erst einmal Deine Firmware ans laufen bringen
...
>>Habe ich das falsche Archiv heruntergeladen?>> Hmm, stimmt. Mein erster Link ist die alte Version. Das hier ist die> aktuelle. ;-)>> Beitrag "Re: Onewire + DS18x20 Library"
GRRRR!
Jetzt habe ich gerade angefangen alles ein wenig für mich anzupassen.
Hier ein paar kleine Verbesserungsvorschläge als Rache: :-)
1
/** \file
2
* \brief Main Project File
3
* \details Diese Datei beinhaltet die Funktion main() und führt alles zusammen.
4
*/
5
6
7
#ifndef _STDIO_H_
8
#include<stdio.h>
9
#endif
10
#ifndef _STDLIB_H_
11
#include<stdlib.h>
12
#endif
13
#ifndef _AVR_IO_H_
14
#include<avr/io.h>
15
#endif
16
#ifndef _AVR_INTERRUPT_H_
17
#include<avr/interrupt.h>
18
#endif
19
#ifndef __PGMSPACE_H_
20
#include<avr/pgmspace.h>
21
#endif
22
#ifndef _UTIL_DELAY_H_
23
#include<util/delay.h>
24
#endif
25
#ifndef _UTIL_ATOMIC_H_
26
#include<util/atomic.h>
27
#endif
28
#ifndef _STRING_H_
29
#include<string.h>
30
#endif
Für das Doxygen fehlt bei Dir meine ich jeweils die File Deklaration,
damit das Dokument gelistet wird.
Wenn es bei mir endlich läuft, schicke ich Dir Mal meine Version.
Die Libraries lade ich immer nur falls sie noch nicht geladen wurden.
@Karsten M. (lsmod)
>Hier ein paar kleine Verbesserungsvorschläge als Rache: :-)>#ifndef _STDIO_H_> #include <stdio.h>>#endif
Das ist totaler Quark, denn dieser Schutz gegen doppelte Includes steckt
schon in jedem Include Files drin.
>Für das Doxygen fehlt bei Dir meine ich jeweils die File Deklaration,>damit das Dokument gelistet wird.
Kann sein, ich kenn mich damit nicht sonderlich gut aus.
Falk B. schrieb:> @Karsten M. (lsmod)> Das ist totaler Quark, denn dieser Schutz gegen doppelte Includes steckt> schon in jedem Include Files drin.
Auch wieder wahr.
>>Für das Doxygen fehlt bei Dir meine ich jeweils die File Deklaration,>>damit das Dokument gelistet wird.>> Kann sein, ich kenn mich damit nicht sonderlich gut aus.
Ich auch nicht - das doxygen ist wirklich recht komplex.
Eine weitere gemeine Frage:
Bläht das den RAM-Verbrauch nicht ungemein auf?
Ich würde gerne ein statisches Array definieren, welches alle gefundenen
Clients beinhaltet und dann einfach per Index benutzt werden kann.
@Karsten M. (lsmod)
>uint8_t scan_bus(uint8_t rom_list[10][8], uint8_t cmd) {>Bläht das den RAM-Verbrauch nicht ungemein auf?
Warum sollte es das? rom_list ist ein POINTER, kein echtes Array. Das
gibt es nur einmalig als globale Variable.
>Ich würde gerne ein statisches Array definieren, welches alle gefundenen>Clients beinhaltet und dann einfach per Index benutzt werden kann.
Genau DAS ist im Code vorhanden ;-)
Falk B. schrieb:> Warum sollte es das? rom_list ist ein POINTER, kein echtes Array. Das> gibt es nur einmalig als globale Variable.
Sollte ein Pointer nicht mit einem '*' beginnen?
Und ein Pointer vom Typ uint8_t?
rom_list ist auch nicht als static deklariert.
Welchen Sinn haben die Werte in dem Array?
Edit: Antwort gefunden. Es geht um den "speed test in simulator".
Leider bin ich kein guter C Programmierer und mit Pointern tue ich mich
noch immer schwer ...
Dein Code ist auch für Arduino in C++ - nicht in C.
@Karsten M. (lsmod)
>> Warum sollte es das? rom_list ist ein POINTER, kein echtes Array. Das>> gibt es nur einmalig als globale Variable.>Sollte ein Pointer nicht mit einem '*' beginnen?
Ja, aber wenn ich einen Pointer auf ein mehrdimensionales Feld haben
will, muss ich die Größen der niedrigeren Dimensionen angeben, sonst
kann der Compiler das nicht allein dereferenzieren. OK, die gezeigte
Methode ist vielleicht nicht die schönste, ein Pointer auf einen
passenden Typ wäre besser. Das hier ginge auch.
>Und ein Pointer vom Typ uint8_t?>rom_list ist auch nicht als static deklariert.
Wozu auch? Es ist global.
>Welchen Sinn haben die Werte in dem Array?>uint8_t buffer[9] = {0x02, 0x1C, 0xB8, 0x01, 0x00, 0x00, 0x00, 0x00, 0
x00};
Zum testen während der Softwareentwicklung, kann man auch 0 setzen.
>Leider bin ich kein guter C Programmierer und mit Pointern tue ich mich>noch immer schwer ...
Dann musst du dir auch hier die "Hände schmutzig machen" und das lernen.
Sooo schwer ist das nicht.
Falk B. schrieb:> Dann musst du dir auch hier die "Hände schmutzig machen" und das lernen.> Sooo schwer ist das nicht.
Doch - die ganzen Feinheiten halte ich für nicht so einfach.
Es gibt eine ganze Menge Sonderlocken die in der Syntax möglich sind.
Vor allem die Unterschiede zwischen C und C++.
Es hat schon einen Grund warum man versucht hat dies in Arduino zu
vereinfachen.
Allerdings bringen diese "Vereinfachungen für den Benutzer" aus meiner
Sicht wiederum zusätzliche Probleme, wenn man über die
Standard-Funktionen von Arduino hinaus geht.
Ich bin total fasziniert davon wieviel Funktionalität mit C in den 8KB
eines Mega8 untergebracht werden kann.
Nun muss ich allerdings ohne Arduino erst einmal die ganzen Arduino
Library Befehle wie z.B. "Serial.println" in einem Teil Deiner Demo nach
C "zurückschrauben".
In der Demo werden aber nicht mehrere Sensoren ausgegeben, wenn diese
vorhanden sind?
Nur der erste Sensor der gefunden wird oder?
1
while(!Serial.available()){
2
onewire_match_rom(roms[i_ds18B20]);
3
ds18B20_convert_t(1);// parasitic power
4
_delay_ms(750);
5
ONEWIRE_STRONG_PU_OFF// user must disable strong pull up after conversion
6
onewire_match_rom(roms[i_ds18B20]);// when using parasitic power
So - ich habe fertig und es läuft nun im Labormuster wunderbar mit 6
Sensoren problemlos.
Von ds18B20_read_temp lasse ich mir allerdings den gemessenen Raw-Wert
zurückliefern.
Diesen rechne ich dann per Integer-Arithmetik in eine Fliesskommazahl
um.
1
while(1){
2
dcount=scan_bus(roms,ONEWIRE_SEARCH_ROM);
3
4
if(dcount==255){
5
uart_string_P(PSTR("Error, no device found!"CR));
6
uart_string(CR);
7
}else{
8
uart_string_P(PSTR("Scan finished, "));
9
uart_int(dcount);
10
uart_string_P(PSTR(" devices found."CRCR));
11
12
for(i=0;i<dcount;i++){
13
uart_string_P(PSTR("Reading temperature of DS18S20 "));
14
uart_int(i+1);
15
uart_string_P(PSTR(" : "));
16
onewire_match_rom(roms[i]);
17
ds18B20_convert_t(0);// start conversion
18
_delay_ms(750);
19
onewire_match_rom(roms[i]);
20
rc=ds18B20_read_temp(&x);// read result
21
if(rc){
22
uart_string_P(PSTR("CRC error!"CR));
23
}else{
24
uart_string_P(PSTR("T Raw: "));
25
uart_int(x);
26
uart_string_P(PSTR(" = "));
27
int32_tTemp=(int32_t)x*625;// caclulate as floating point
28
Vor=Temp/10000;// int8_t
29
Temp=Temp-(int32_t)Vor*10000;// Rest
30
if(Temp<0){
31
Temp=-1*Temp;// Nachkomma immer positiv
32
if(Vor==0){// Minus für -0.x nicht vergessen
33
uart_char('-');
34
}
35
}else{
36
Temp=Temp+500;// Rundung auf 1 Nachkommastelle wenn positiv
37
}
38
Nach=Temp/1000;// int8_t
39
uart_int(Vor);
40
uart_string_P(PSTR("."));
41
uart_int(Nach);
42
uart_string_P(PSTR(" °C"CR));
43
}
44
}
45
}
46
uart_string(CR);
47
}
Das gesamte Programm benötigt 2342 Byte.
Es gibt folgendes aus:
1
Scanning OneWire bus for ROM codes.
2
Index : 7 6 5 4 3 2 1 0
3
ROM 01: 28 34 4D DD 03 00 00 52
4
ROM 02: 28 6F 5A DD 03 00 00 A9
5
ROM 03: 28 FF A5 BF 63 15 02 4C
6
ROM 04: 28 FF 6D E6 63 15 02 1B
7
ROM 05: 28 FF E3 A9 63 15 02 08
8
ROM 06: 28 FF A7 D4 63 15 02 CB
9
Scan finished, 6 devices found.
10
11
Reading temperature of DS18S20 1 : T Raw: 379 = 23.7 °C
12
Reading temperature of DS18S20 2 : T Raw: 379 = 23.7 °C
13
Reading temperature of DS18S20 3 : T Raw: 376 = 23.5 °C
14
Reading temperature of DS18S20 4 : T Raw: 373 = 23.3 °C
15
Reading temperature of DS18S20 5 : T Raw: 373 = 23.3 °C
16
Reading temperature of DS18S20 6 : T Raw: 377 = 23.6 °C
Das werde ich nun noch erweitern und in meine andere Firmware
integrieren.
Dann bin ich gespannt ob es dort auch mit dem bösen langen Kabel
funktioniert? :-)
@ Karsten M. (lsmod)
>So - ich habe fertig und es läuft nun im Labormuster wunderbar mit 6>Sensoren problemlos.
Das lief es vorher auch.
>Von ds18B20_read_temp lasse ich mir allerdings den gemessenen Raw-Wert>zurückliefern.>Diesen rechne ich dann per Integer-Arithmetik in eine Fliesskommazahl>um.
Das ist wieder so eine Sinnlosigkeit, du erfindest das Rad neu. Die
Funktion liefert schon eine Temperatur als Integer, berechnet durch
Festkommaarithmik. Wenn man das das dann wieder in Fließkomma
umrechnet, ist der Vorteil dahin.
>Dann bin ich gespannt ob es dort auch mit dem bösen langen Kabel>funktioniert? :-)
DAS ist doch die Frage des Tages. Der Rest ist nur nice to have.
Alter Mopperhannes!
Falk B. schrieb:> Das lief es vorher auch.
Kann ich nicht bestätigen. Ich hatte nur mit max. 3 Sensoren getestet.
> Das ist wieder so eine Sinnlosigkeit, du erfindest das Rad neu. Die> Funktion liefert schon eine Temperatur als Integer, berechnet durch> Festkommaarithmik. Wenn man das das dann wieder in Fließkomma> umrechnet, ist der Vorteil dahin.
Es ist nicht sinnlos, weil
1. Ich später nur den Raw-Wert übernehme und in eine Datenbank schreibe
2. Meine Umrechnung mit Rundung umrechnet
Anbei meine Ausgabe in doxygen.
Das bekommt man bei Bedarf auch noch schöner hin.
@Karsten M. (lsmod)
>Kann ich nicht bestätigen. Ich hatte nur mit max. 3 Sensoren getestet.
Dann klemm doch das Ding jetzt an das Originalkabel und scan den Bus.
Dann siehst du was Sache ist.
Falk B. schrieb:> Dann klemm doch das Ding jetzt an das Originalkabel und scan den Bus.> Dann siehst du was Sache ist.
Das ist zu einfach! :-)
Aber durchaus eine Idee!
Na dann bis gleich ...
Falk B. schrieb:> DAS ist doch die Frage des Tages. Der Rest ist nur nice to have.
Die Frage kann ich nun endlich beantworten.
Es liegt nicht am Kabel, sondern nur an der Firmware!
Ich bekomme nun problemlos + extrem stabil die Werte ausgelesen:
1
Scanning OneWire bus for ROM codes.
2
Index : 7 6 5 4 3 2 1 0
3
ROM 01: 28 1B 9F 5D 05 00 00 15
4
ROM 02: 28 FF 0A 57 35 16 04 67
5
ROM 03: 28 FF AF F1 35 16 03 A5
6
Scan finished, 3 devices found.
7
8
Reading temperature of DS18S20 1 : T Raw: 343 = 21.4 °C
9
Reading temperature of DS18S20 2 : T Raw: 282 = 17.6 °C
10
Reading temperature of DS18S20 3 : T Raw: 289 = 18.1 °C
Damit steht fest:
1. Die Library von Volker U. bzw. von Peter Dannegger versagt bei
mehreren Sensoren
2. Du hast Dir mit Deiner Library das Bier redlich verdient!
3. Die Verkabelung ist nicht kritisch
VOILA!
Herzlichen Dank für Deinen netten Support! ;-)
@ Karsten M. (lsmod)
>Ich bekomme nun problemlos + extrem stabil die Werte ausgelesen:
Schön zu hören.
>1. Die Firmware von Volker U. bzw. von Peter Dannegger versagt bei>mehreren Sensoren
Das kann ich kaum glauben. Irgendwas klemmt hier.
Aber wenn es mit meiner Software läuft, so what.
Njoy.
Falk B. schrieb:>>1. Die Firmware von Volker U. bzw. von Peter Dannegger versagt bei>>mehreren Sensoren>> Das kann ich kaum glauben. Irgendwas klemmt hier.
Der entscheidende Unterschied ist das hier jeder Sensor explizit mit
seiner ID abgefragt wird!
1
ds18B20_convert_t(0);// start conversion
2
_delay_ms(750);
3
onewire_match_rom(roms[i]);
4
rc=ds18B20_read_temp(&x);// read result
Ich starte nun übrigens die Messung nur noch einmal und lese dann die
Sensoren ohne Wartezeit alle hintereinander aus.
> Aber wenn es mit meiner Software läuft, so what.
Deine Firmware deckt eine viel größere Funktionalität des 1-Wire-Bus ab.
Daher vielen Dank für die Veröffentlichung!
> Njoy.
Das tue ich.
Vor allem das ich nicht in üblen Ecken einen Kabelfehler gesucht habe.
;-)
Thread beobachten
Seitenaufteilung abschalten