DS18B20-Temperatur Vergleich Problem

Hallo,

also um evtl. Hilfe zubekommen würde es helfen, wenn du ein paar mehr 
Informationen bereitstellst. D.h. in deinem Fall: µC, Programmiersprache 
evtl. auch die verwendeten Codes, Entwicklungsboard oder on fly Aufbau.

Codes für diesen sensor gibt es haufenweise, leider kann ich dir keinen 
passenden empfehlen da ich ja nicht weis welchen µC du benutzt.

MfG

Richi

Patch schrieb:

> PS: Von den Ansätzen her hab ich bisher einfach mal alle gefundenen
> fertigen Codes probiert, habe aber keinen zum Laufen bringen können.

Was heisst du hast keinen zum laufen bringen können.
DS18B20 Code gibt es doch wie Sand am Meer. AUch hier in der 
Codesammlung (die jetzt Projekte&Code heisst) gibt es genügend fertigen 
Code, der das auselesen übernimmt.

> ... und kein LCD oder ähnliches.
und das ist schon mal ein Fehler, den die meisten Anfänger begehen. 
Gerade weil man Anfänger ist, ist eine Möglichkeit für eine Ausgabe 
unumgänglich. Da ist eien simple LED zu wenig, bzw. es ist unendlich 
mühsam für einen Anfänger damit nach der Methode 'Rückschluss aus 
unvollständigen Informationen' auf Fehlerursachen bzw. weiteres Vorgehen 
in der Fehleranalyse zu schliessen. Wenn man das beherrscht ist man 
nämlich kein Anfänger mehr. Für alle anderen gilt: eine Ausgabe auf LCD 
bzw. UART kann in Gold aufgewogen werden.
Vorausgesetzt natürlich, dass der Code prinzipiell schon kompipilert. 
Aber davon geh ich naiver Weise bis zum Beweis des Gegenteils sowieso 
immer aus.

Patch schrieb:

> Das Board ist aktuell zum testen das avrispmkii

Das macht man dann aber nicht mit einem Projekt, in dessen Zuge schon 
eine Menge Dinge schief gehen können, die nichts mit dem Brenner zu tun 
haben. Ganz im Gegenteil reicht es völlig aus, ein Programm in den µC 
brennen zu lassen, welches eine LED einschaltet, ausschaltet oder 
blinken lässt. Blinkt die LED, dann ist der Nachweis erbracht, dass der 
MKII das Programm übertragen konnte und der µC läuft.
Und das dafür notwendige zu übertragende Programm ist so simpel, dass 
man davon ausgehen kann, das es auf Anhieb funktionieren wird, sofern 
nur die Hardware in Ordnung ist.

Patch schrieb:
> Da es mehr Codes mit LCD gibt als ohne, gehe ich ohnehin davon aus, das
> es mit einfacher wäre, problem bleibt nur, ich soll keines nutzen und
> habe auch keines zur hand.

Räusper:
Es ist nicht verboten, den LCD Code nach erfolgter Inbetriebnahme wieder 
aus dem Programm rauszunehmen. Es ist nicht in Stein gemeisselt, dass 
einmal im Programm vorhandener Code auch auf immer und ewig im Programm 
bleiben muss. Und wenn du keines hast, dann besorg dir eines.

Alternativ kannst du natürlich auch deinen Mega16 mit LED an den Ports 
spicken und dir auf die Art Statusmeldungen bzw. Werte ausgeben lassen. 
Aber wie gesagt: das ist sehr sehr mühsam.

Also das Ausgangspost ist doch glasklar: Er kann nichts selber machen. 
Er kann keinen vorhandenen Code anpassen. Er kann seine Aufgabe schlicht 
NICHT umsetzen. Er sucht fertigen Code für seine Aufgabe. Kein 
Beispielcode der Welt würde ihm helfen. Davon gibt's ja auch genug.

Ein typischer Fall von: "Ich will viel, kann nix.". Mal wieder.

Patch schrieb:
> Ich dachte da hauptsächlich an ne art IF abfrage des temp registers mit
> dessen hilfe ich etwas einschalte, hab das auch mit einem code aus dem 1
> wire forenthread getestet, wobei sich da aber nichts getan hatte.
> Dieser war allerdings auch so umfangreich (sprich 4 oder 5 header und
> main dateien) das ich da nicht vollkommen durchgestiegen bin.

Wie wäre es wenn du vorher mal C programmieren lernen würdest?

Cyblord -. schrieb:
> Also das Ausgangspost ist doch glasklar: Er kann nichts selber machen.

:-)
natürlich ist mir das genauso klar, wie dir.

> Kein Beispielcode der Welt würde ihm helfen.

Den braucht er auch nicht. Was er braucht, das ist fertiger COde, den er 
einfach auf den Mega16 brennt und der bereits läuft. Maximal noch 1 
Zahlenwert anpassen und dann muss es auch schon fertig sein.

Aber: das ganze klingt nicht nach "Ich würde brauchen", sondern nach 
"Ich habe als Aufgabe bekommen und werde dafür benotet". Und in dem Fall 
wende ich strengere Massstäbe an.

Edit: Jup, wurde inzwischen auch bestätigt, dass es sich um eine Aufgabe 
handelt.

OMG
Dann erzähl doch einfach mal, welchen Code du nicht zum laufen bringst 
und woran es scheitert.
Eines dürfte dir mittlerweile auch schon klar geworden sein: fix 
fertigen Code zum brennen spielt es nicht.

Na ja.
Peters COde ist natürlich schon alt. Er stammt im Kern aus 2004 und 
einige Dinge werden heutzutage anders geschrieben. Zudem ist er so 
geschrieben, dass er mit beliebig vielen DS18B20 am Bus klar kommt.
Aber so wild ist der in 1Wire.zip dann auch wieder nicht.

Patch schrieb:
> Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil
> beklauen müsste durch externe beschaltung.
Ja nur klappt bei dir ja noch nicht mal das Code klauen. Tip: 
Programmieren besteht NICHT aus dem Copy&Paste von fertigem Code den man 
nicht versteht.

Patch schrieb:
> Cyblord -. schrieb:
>> Patch schrieb:
>>> Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil
>>> beklauen müsste durch externe beschaltung.
>> Ja nur klappt bei dir ja noch nicht mal das Code klauen. Tip:
>> Programmieren besteht NICHT aus dem Copy&Paste von fertigem Code den man
>> nicht versteht.
>
> Ich weiß, aber irgendwie muss ich mir behelfen, wenn ich nicht
> wochenlang an einem problem arbeiten möchte :/

Tja. Daran sollte man aber denken, BEVOR man sich um ein Projekt 
bewirbt.

Egal. Peters Kernroutinen sind in 1WIRE.C/H bzw. TEMPREAD.C/H
Der Rest ist nur Geplänkel um das Gemessene per UART auszugeben bzw. ein 
Timer der dafür sorgt, dass die Messung alle 2 Sekunden neu angestossen 
bzw. das Messergebnis abgefragt wird.

1_wire.zip solltest du eigentlich zum Laufen kriegen können und dann 
wird erst mal überprüft, ob sich überhaupt der Baustein am Bus meldet 
(zb. indem eine LED eingeschaltet wird, wenn dem so ist)

Schau ins Datenblatt vom DS18B20. Da ist beschrieben wie man den Sensor 
ausliest. Das musst du nur in C implementieren. Kein Problem, kostet nur 
bissl Zeit.
Hat man keine Probleme mit zip entpacken oder fremden Code verstehen.

Patch schrieb:
> Habe mich bisher mit 2 Codes näher beschäftigt, einer davon compiliert
> erst gar nicht richtig ohne fehler und der andere ist eben etwas
> umfangreich.

habe mir beide angesehen, finde da nichts verdächtiges.
Da du die Fehler ja nicht benennst wüsste ich nicht wie man da helfen 
soll.

Ein Code schreibt auf die UART, wenn da nix die Zeichen abholt weisst du 
noch nicht mal ob der Code nicht funktioniert, vielleicht funktioniert 
er ja nur du siehst es nicht.

Patch schrieb:
> rm -rf ProjektTemP.o 1WIRE.o DELAY.o MAIN.o TEMPMEAS.o TIMEBASE.o UART.o
> ProjektTemP.elf dep/* ProjektTemP.hex ProjektTemP.eep ProjektTemP.lss
> ProjektTemP.map
> Build succeeded with 0 Warnings...
> avr-gcc  -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char
> -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT 1WIRE.o -MF
> dep/1WIRE.o.d  -c  ../../../../Downloads/1wire/1WIRE.C
> cc1plus.exe: warning: command line option "-std=gnu99" is valid for
> C/ObjC but not for C++
> In file included from ../../../../Downloads/1wire/1WIRE.C:9:
> ../../../../Downloads/1wire/main.h:11:16: error: io.h: No such file or
> directory

Der Header io.h ist jetzt in avr/io.h, wie eigentlich jeder wissen 
sollte, der schon mindestens 1 mal ein AVR Programm geschrieben hat

Also in main.h:

1

#include <avr/io.h>

>> dep/1WIRE.o.d  -c  ../../../../Downloads/1wire/1WIRE.C
>> cc1plus.exe: warning: command line option "-std=gnu99" is valid for
>> C/ObjC but not for C++

Der Dateiname ist schlecht. Eine Endung mit einem grossen C ist das 
Kennzeichen, dass es sich um C++ Code handelt.
Datei umbenennen auf 1WIRE.c (kleines c). Denn das ist alles reiner C 
Code.

Patch schrieb:
> Beides befolgt, noch immer 3 fehler:

Und?
Wie wäre es mal mit LESEN der Fehlermeldung?

> In file included from ../../../../Downloads/1wire/1WIRE.c:9:
> ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or
> directory

Nö. Du hast nichts befolgt. Immer noch gleiches File, gleicher Header, 
gleiches wird nicht gefunden

> ../../../../Downloads/1wire/main.h:13:23: error: interrupt.h: No such
> file or directory

selber Typ

> ../../../../Downloads/1wire/main.h:14:20: error: signal.h: No such file
> or directory

und noch einmal

Patch schrieb:
> ich nehm mal die nicht existenten libs einfach rauslöschen?

ne lernen,

hab auch mal grad probiert

<io.h> wird <avr/io.h> usw. für andere

signal.h ist nicht mehr aktuell -> auskommentieren

einige Warnungen sind nur weil evtl. cast fehlen

uputsnl( "Bus Error" );

damit der compiler glücklich ist caste ich

uputsnl( (char *)"No Sensor found" );

Karl H. schrieb:

Ich versteh nicht, was daran jetzt so schwer ist
Der Compiler schreibt hin, in welchem Source Code File das Prpoblem 
existiert

1

../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory

2

                            ******

Er schreibt hin in welcher Zeile und innerhalb der Zeile in welcher 
Spalte

1

../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory

2

                                   ******

Er schreibt hin, welches andere File er gesucht hätte, weil es offenbar 
an dieser Stelle verwendet wird (was in 99% aller Fälle mit einem 
#include zu tun hat)

1

../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory

2

                                                ******

Wo liegt also das Problem, ausser das man den kompletten Fehlertext 
lesen müsste?

Patch schrieb:
> Naja, jetzt spuckt er nur noch wegen dem interrupt.h rum,

für interrupt.h gilt dasselbe wie für io.h
Es wurde in ein Subverzeichnis namens "avr" verbannt, weil es nichts mit 
Standard-C zu tun hat, trotzdem aber als System-Header anzusehen ist.

Karl H. schrieb:
> Patch schrieb:
>> Naja, jetzt spuckt er nur noch wegen dem interrupt.h rum,
>
> für interrupt.h gilt dasselbe wie für io.h
> Es wurde in ein Subverzeichnis namens "avr" verbannt, weil es nichts mit
> Standard-C zu tun hat, trotzdem aber als System-Header anzusehen ist.

Im übrigen leicht erkennbar daran, dass Peter völlig korrekt in main.h

1

...

2

#ifndef _main_h_

3

#define _main_h_

4

#include <io.h>

5

#include <interrupt.h>

6

....

die Spitzklammern < > benutzt hat und nicht

1

...

2

#ifndef _main_h_

3

#define _main_h_

4

#include "io.h"

5

#include "interrupt.h"

6

...

geschrieben hat. Die Spitzklammern < > sind immer ein Indiz dafür, dass 
es sich in irgendeiner Form um einen System-Header handelt, der im 
eigentlichen Sinne nicht zum Projekt gehört und daher auch nicht auf dem 
Projektverzeichnis zu finden ist.
Nur dass diese Header Files früher eben auf dem Haupt-System-Include 
Verzeichnis rumgelungert sind und im Laufe der Jahre (ebenfalls 
korrekterweise) in ein AVR spezifisches Subverzeichnis verschoben 
wurden.

Daher ist die korrkte Schreibweise heute

1

...

2

#ifndef _main_h_

3

#define _main_h_

4

#include <avr/io.h>

5

#include <avr/interrupt.h>

6

...

Kaufe dir einen Arduino Uno oder Nano (kannste so ins Steckbrett 
stecken) und mach das komplett mit Arduino. Auch die IDE, denn dann 
kannst du die Daten in einem zugehörigen Terminalfenster anzeigen 
lassen. Der Code ist fertig und läuft (selbst getestet).

Patch schrieb:
> Naja, jetzt spuckt er nur noch wegen dem interrupt.h

Frage steckt interrupt.h im ZIP File?

wenn nein wird es wohl in der LIB sein und wenn wir die LIB Pfade um 
avr/ erweitern müssen, wie würdest du diese Frage beantworten?

Patch schrieb:
> Du meinst, ich muss es mit avr/ erweitern?

Der Unterschied

#include <mein.h>
#include "mein.h"

im Studio ist bekannt?
(nur dem Arduino solls egal sein, warum auch immer)

Patch schrieb:
> Du meinst, ich muss es mit avr/ erweitern?

Jetzt hast du Glück gehabt, dass ich meine Erklärung schon gschrieben 
hatte, ehe ich diese Frage gesehen habe.

Patch schrieb:

> #define _main_h_
> //#include <io.h>
> //#include <avr/interrupt.h>

von auskommentieren war aber nicht die Rede

Karl H. schrieb:
> von auskommentieren war aber nicht die Rede

doch für <signal.h> aber logisch nicht für alles :-)

Joachim B. schrieb:
> Karl H. schrieb:
>> von auskommentieren war aber nicht die Rede
>
> doch für <signal.h> aber logisch nicht für alles :-)

Wobei.
Ist das immer noch so, dass bei signal.h eine Warnung kommt, dass das 
File mitlerweile obsolet ist und wegfallen kann?

Wenn ja dann ...
Ach was solls, er liest ja sowieso keine Fehlermeldungen.

Patch schrieb:
> In der main.h steht bei mir aktuell oben:
>
> #include <avr/io.h>
> #include <avr/interrupt.h>
> #ifndef main_h
> #define main_h
> //#include <io.h>
> //#include <avr/interrupt.h>
> //#include <signal.h>
> #include <stdlib.h>
> #include <stdio.h>

und warum machst du sowas?

#ifndef bleibt immer vorne um Mehrfacheinbindungen zu verhindern


#ifndef main_h
#define main_h
#include <avr/io.h>
#include <avr/interrupt.h>
//#include <avr/signal.h> ERSATZLOS gestrichen -> steckt nun in 
interrupt.h
#include <stdlib.h>
#include <stdio.h>

Karl H. schrieb:
> Ist das immer noch so, dass bei signal.h eine Warnung kommt


ja die kommt immer noch und erleichert das Leben

Patch schrieb:
> Ja, leider muss ich mich auf reines C beschränken was den
> programmierteil angeht.

Das ist aber äußerst blöd, denn offensichtlich kannst du noch kein 
bisschen C, vom DS18B20 weißt du auch nichts und von uC's hast du 
wahrscheinlich auch keine Ahnung. Da wird es schon schwer..

Patch schrieb:
> Ja, leider muss ich mich auf reines C beschränken was den
> programmierteil angeht.

Wer schreibt das vor? Der Lehrer, Meister, ...?

Wenn's nur darum geht so ein Teil zu bauen:
 (wie oben schon mal geschrieben)
Arduino nano (China:<3€, "DIL36", inclusive Bootloader per USB),
Arduino IDE und
1wire-Lib, die garantiert mit Beispiel für DS18x20 kommt.

Oder eben BASCOM.
(auch wenn ich selber erschrecke. Hab ich das wirklich geschrieben?)

C-Compiler Meldungen sind nunmal ohne hinreichend Erfahrung schwer zu 
interpretieren. Bzw. aus dem Verständnis dann eine zielgerichtete 
Handlung abzuleiten.
Schreib es selbst. Am Ende hast du genug Erfahrung um die fertige Lösung 
zu portieren und zu benutzen.
Ein wechsel der Programmiersprache ersetzt keine Erfahrung sondern 
kostet erstmal nur Zeit.
Die Stunden die du jetzt schon reingesteckt hast, sind bereits die 
ersten Stückchen gesammelte Erfahrung. Schätze sie wert und bau drauf 
auf. Eine erkannte Sackgasse richtet den Blick automatisch auf 
unbeschrittene Wege. Gehe sie,  am Wegrand wirst du helfende Gefährten 
treffen,  aber auch Trolle und andere Gestalten. Sie werden dich 
versuchen zu locken,  mit Schlangenölen und -balsamen,  die da STM32, 
PIC oder Bascom heißen. Notier sie dir. Das Schlangenöl von heute ist 
die Lösung von morgen. Aber die Lösung für heute liegt direkt vor dir.

Robin R. schrieb:
> C-Compiler Meldungen sind nunmal ohne hinreichend Erfahrung schwer zu
> interpretieren. Bzw. aus dem Verständnis dann eine zielgerichtete
> Handlung abzuleiten.
> Schreib es selbst. Am Ende hast du genug Erfahrung um die fertige Lösung
> zu portieren und zu benutzen.
> Ein wechsel der Programmiersprache ersetzt keine Erfahrung sondern
> kostet erstmal nur Zeit.
> Die Stunden die du jetzt schon reingesteckt hast, sind bereits die
> ersten Stückchen gesammelte Erfahrung. Schätze sie wert und bau drauf
> auf. Eine erkannte Sackgasse richtet den Blick automatisch auf
> unbeschrittene Wege. Gehe sie,  am Wegrand wirst du helfende Gefährten
> treffen,  aber auch Trolle und andere Gestalten. Sie werden dich
> versuchen zu locken,  mit Schlangenölen und -balsamen,  die da STM32,
> PIC oder Bascom heißen. Notier sie dir. Das Schlangenöl von heute ist
> die Lösung von morgen. Aber die Lösung für heute liegt direkt vor dir.

Amen!