www.mikrocontroller.net

Forum: Codesammlung DS1820, DS18B20 in C

Autor: peter dannegger (Gast)
Datum: 12.05.2004 00:23
Angehängte Dateien:

Anbei der komplette Code für 1-Wire in C auf dem AVR.

Wer meine AVR Assembler und C51 Beispiele schon kennt, wird große
Ähnlichkeiten entdecken.

Es werden alle gefundenen Sensoren in 0,1°C Schritten ausgegeben.
Dabei erfolgt die Anzeige der DS1820 nur in 0,5°C Schritten.
Die Routine muß für negative Werte leicht geändert werden.
Die Ausgabe erfolgt über die UART.

Die nötigen Delay-Zeiten für den 1-Wire werden mit dem Timer erzeugt.
Dadurch ergibt sich eine Unabhängigkeit vom Compiler und die
Quarzfrequenz kann einfach geändert werden.


Peter
Autor: Matthias Reiter (Gast)
Datum: 14.07.2004 18:45
Angehängte Dateien:

@Peter:
Ich mache erste Gehversuche mit C und WINAVR.
Dein 1-wire Beispiel bekomme ich aber nicht fehlerfrei compiliert.
Ich bekomme nach make all folgende Fehler:

-------- begin --------
avr-gcc (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


Linking: main.elf
avr-gcc -mmcu=at90s8535 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.o  -std=gnu99
-Wp,-M,-MP,-MT,main.o,-MF,.dep/main.elf.d main.o  1WIRE.C DELAY.C
TIMEBASE.C TEMPMEAS.C UART.C   --output main.elf
-Wl,-Map=main.map,--cref    -lm
cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++
cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++
cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++
TIMEBASE.C: In function `void init_timer()':
TIMEBASE.C:40: warning: assignment of negative value `-1' to `volatile
unsigned
   int'
TIMEBASE.C:40: warning: argument of negative value `-1' to `unsigned
int'
cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++
TEMPMEAS.C: In function `void read_meas()':
TEMPMEAS.C:37: error: invalid conversion from `unsigned char*' to
`char*'
TEMPMEAS.C:38: error: invalid conversion from `unsigned char*' to
`char*'
TEMPMEAS.C:45: error: invalid conversion from `unsigned char*' to
`char*'
TEMPMEAS.C:46: error: invalid conversion from `unsigned char*' to
`char*'
TEMPMEAS.C:47: error: invalid conversion from `unsigned char*' to
`char*'
TEMPMEAS.C:48: error: invalid conversion from `unsigned char*' to
`char*'
cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++
UART.C: In function `void uinit()':
UART.C:6: error: `UBRRL' undeclared (first use this function)
UART.C:6: error: (Each undeclared identifier is reported only once for
each
   function it appears in.)
UART.C:7: error: `UBRRH' undeclared (first use this function)
UART.C:8: error: `UCSRA' undeclared (first use this function)
UART.C:9: error: `UCSRC' undeclared (first use this function)
UART.C:9: error: `URSEL' undeclared (first use this function)
UART.C:9: error: `UCSZ1' undeclared (first use this function)
UART.C:9: error: `UCSZ0' undeclared (first use this function)
UART.C:10: error: `UCSRB' undeclared (first use this function)
make.exe: *** [main.elf] Error 1

> Process Exit Code: 2

Müssen bei Deinem Code SFR-Bezeichnungen für den AT90S8535 angepaßt
werden?

Was ist mit den Umwandlungen von Uchar zu Char??

Liegen die ganzen Fehlermeldungen möglicherweise an meinem makefile?

Ich bin dankbar für jeden Hinweis.

BTW: Danke für Deine zahlreichen Codebeispiele.

Gruß

Matthias
Autor: peter dannegger (Gast)
Datum: 14.07.2004 22:30

Tut mir leid, aber mit dem make kenne ich mich nun überhaupt nicht aus.

Ich compiliere immer in der DOS-Box mit einer Batch:


@echo off

:set mcu=90s2313
:set mcu=tiny26

set mcu=mega8

set main=test

set ac=c:\avr\winavr

path %ac%\bin;%path%
avr-gcc.exe -Os -mmcu=at%mcu% -Wall -g -o main.out *.c
if not exist main.out goto end
cmd /c avr-objdump.exe -t -h -S main.out >%main%.lst
cmd /c avr-objcopy.exe -O ihex main.out %main%.hex
avr-size.exe -B main.out
del main.out

:end


Peter
Autor: Matthias Reiter (Gast)
Datum: 14.07.2004 22:57

@ Peter:

Danke für die Antwort. Ich werds mal auf Deine Art probieren.

Zwei Fragen zu Deinen Code habe ich noch:

1. Für welchen Controller hast Du Ihn geschrieben? Für den Mega8, wie
Dein Batchfile andeutet? Ich könnte dann leichter die Fehlermeldungen
mit den SFR-Definitionen verstehen.

2. Sind die Fehlermeldungen zu den Umwandlungen von uchar* nach char*
in der TEMPMEAS.C berechtigt?

Beispiel:
TEMPMEAS.C:37: error: invalid conversion from `unsigned char*' to
`char*'
Zeile 37:   sprintf( s, "%02X ", id[i] );
s ist uchar

Grüße Matthias
Autor: Matthias Reiter (Gast)
Datum: 14.07.2004 23:12

@Peter:

Frage 1 hat sich erledigt: bei mcu=atmega8 sind die Fehlermeldungen zu
den SFRs weg.

Matthias
Autor: Ronny Schulz (Gast)
Datum: 19.07.2004 21:35

Ich möchte mich nochmal bei Peter bedanken. Lange hatte ich mit dem
1-Wire-Protokoll rumgefummelt. Und irgendwie hat nichts so recht
geklappt. Inzwischen geht es endlich, da ich hier ein sehr gutes
Beispiel hatte. Somit bin ich zumindest schon in der Lage so ein Teil
auszulesen.

Was noch offen ist, wäre Search-ROM und Match-ROM. Das ist wirklich
sehr schwer zu verstehen und vor allem umzusetzen, wenn man mal das
iButton-Guide gelesen hat. Obwohl ja alles ausführlich dasteht.
Autor: Andreas Schwarz (Gast)
Datum: 20.07.2004 00:34

Matthias: Die Dateinamen müssen auf ".c" enden, sonst behandelt sie
der Compiler als C++, nicht C:
"cc1plus.exe: warning: "-std=gnu99" is valid for C/ObjC but not for
C++"
Autor: Matthias Reiter (Gast)
Datum: 29.07.2004 22:53

@ Andreas:
Danke für den Hinweis. Meine C-Dateien waren "*.C".
Ich verstehe deshalb die Meldung von make nicht.
Ich nehme an, dass ich irgend einen Unsinn in meinem Makefile habe.
Autor: Matthias Reiter (Gast)
Datum: 30.10.2004 13:26

Nun funktioniert es. Danke
Autor: Martin Schuhmacher (Gast)
Datum: 20.11.2004 16:50

das gepostete batch file bringt bei mir
[...Warnings...]
uart.c: In function `uinit':
uart.c:6: error: `UBRRL' undeclared (first use in this function)
uart.c:6: error: (Each undeclared identifier is reported only once
uart.c:6: error: for each function it appears in.)
uart.c:7: error: `UBRRH' undeclared (first use in this function)
uart.c:8: error: `UCSRA' undeclared (first use in this function)
uart.c:9: error: `UCSRC' undeclared (first use in this function)
uart.c:9: error: `URSEL' undeclared (first use in this function)
uart.c:9: error: `UCSZ1' undeclared (first use in this function)
uart.c:9: error: `UCSZ0' undeclared (first use in this function)
uart.c:10: error: `UCSRB' undeclared (first use in this function)
uart.c: In function `uputchar':
uart.c:16: error: `UCSRA' undeclared (first use in this function)

die dateien sind *.c
in der main.h habe ich noch
#include <avr/signal.h>
verbessert sowie in der batch den pfad geändert.
Autor: peter dannegger (Gast)
Datum: 21.11.2004 18:16

@Martin,

lies alle Beiträge in Ruhe durch, besonders die von Matthias.


Peter
Autor: Michael (Gast)
Datum: 22.11.2004 15:35

@ Peter,
im Hauptprogramm setzt du die Sekunden auf 0. Must du eigentlich nicht
auch den Prescaler auf 0 setzen, um das Timing sicherzustellen? In
dieser Applikation evtl. nicht so wichtig, aber durch irgendwelche
Interrupt-Sachen kann der Prescaler ja weiter zählen, bis im
Hauptprogramm Sekunden auf Null gesetzt werden.
Michael
Autor: Peter Dannegger (Gast)
Datum: 22.11.2004 17:16

Hast recht, guter Programmierstil ist es, alle globalen Variablen zu
initialisieren, damit das Programm besser lesbar ist.

Oft wird das Initialisieren mit 0 weggelassen, da das der Compiler
automatisch macht.


Peter
Autor: Michael Kramer (Gast)
Datum: 26.01.2005 14:43

Hi ...

nachdem ich Sie nirgends finden kann - Peter Dannegger hat mal Routinen
in C51 veröffentlicht - gibts die noch irgendwo ?

danke
  michael
Autor: peter dannegger (Gast)
Datum: 26.01.2005 15:41

Autor: Leo (Gast)
Datum: 23.03.2005 15:55

@peter

... On bigger applications this time may be longer, but should not
exceed 500ms. Otherwise the user can think, there is Windows working
inside ...

W U N D E R B A R E S    S T A T E M E N T!!!


leo
Autor: Andreas (Gast)
Datum: 05.06.2005 22:25

Hallo liebes Forum,

hat jemand einen C-oder Assembler -code für den ds18s20 an einem 8051?
Oder einen entsprechenden Link?

MFG
Andreas
Autor: Bernhard Waterkamp (Gast)
Datum: 13.06.2005 23:25

Hi!
Ich brauche dringend Hilfe. Ich möchte den DS1820 mit meiner C-Control
auslesen. Allerdings hab ich nur einen Assemblerocde ohne viele
Erklärungen (http://www.b-kainka.de/ccbsp.htm; ganz unten).
Kennt wer einen Beispielcode in Basic und Assemblercode?

Gruß

Bernie
Autor: Elektrikser (Gast)
Datum: 13.06.2005 23:35

C-Control I oder II?

Bei der C-Control I wird es nicht möglich sein das ganze in Basic zu
machen. Das wird zu langsam und der Ein-Draht-Bus ist im Timing
ziemlich empfindlich. Du wirst um Assembler nicht herumkommen, und da
gehen ohne Tricks nur 256 Bytes, wenn ich mich nicht irre.

Gruß Elektrikser
Autor: Bernhard Waterkamp (Gast)
Datum: 13.06.2005 23:43

Hi!
Ja ich habe die C-Control I. Wenn Assemblercode dabei ist, wäre es ja
nicht schlimm. Aber die oben genannten Seite beinhaltet nur den
Assemblercode. Ich weiß nur nicht wie das Basic-Programm dazu
aussieht.

Gruß Bernie
Autor: Elektrikser (Gast)
Datum: 14.06.2005 00:44

Autsch, die CControl ist bei mir schon lang her. Aber die asm-Datei
müsste mit "syscode" in das Basic-Programm eingebunden werden. Und
der Rest? Hmm, Das asm-Programm hat auf der linken Seite Sprungmarken,
die du im Basic-Programm anspringen kannst. Da gab es noch den
"sys"-Befehl. Schau mal in deine Beschreibung rein.
In dem Assemblerprogramm müsste es; reset, byte_read, byte_write, delay
geben.
Ich muss mal suchen, ob ich überhaupt noch was mit der CControl
habe...

Ich hoffe, dass ich da jetzt nicht zuviel durcheinander gebracht habe.

Gruß Elektrikser
Autor: Bernhard Waterkamp (Gast)
Datum: 14.06.2005 01:13

Wie ich den Assembler in den Code einbinde und "anspringe" habe ich
auch schon herrausgefunden. Aber ich glaube, dass es im Basic-Programm
noch mehr Code erforderlich ist um die Temperatur auszulesen, denn als
Kommentar bei der Variabeldeklarierung steht: "bas_2  .equ $b8 ;
zweite Basic Variable => Daten Rein&Raus". Falls du da durchblickst:
Ich habe ein BASIC-Programm gefunden, aber es ist recht komplex und ich
habe keine Erklärung dazu gefunden.
(http://homepages.compuserve.de/BernardWeiler/DS1820.BAS).
Ich habe den Code ausprobiert und auch etwas herum experimentiert aber
ich bekomme nur Fehlermeldungen, dass der Sensor nicht gefunden worden
ist. Da ich von diesem Code wenig Ahnung und keine Informationen habe,
weiß ich nicht wo ich mit der Fehlersuche beginnen soll.

Gruß Bernie
Autor: Thomas (Gast)
Datum: 30.10.2005 21:20

Auch wenn ich diesen alten Thread mal wieder rauskrame, habe ich mal
eine Frage zu der Leseroutine:
Ich versuche gerade meine eigenen 1-Wire Funktionen zu schreiben, da
das Lesen aber nicht so recht funktioniert habe ich mir mal die
Funktionen von Peter angesehen.

Aus dem Datenblatt des DS1820 verstehe ich den Read-Time Slot
folgendermaßen:

- 1 Byte über den 1-Wire Bus lesen:
Ein Read-Time-Slot hat eine Mindestdauer von 60µs. Zwischen den
einzelnen Slots muss einer Erholungszeit von mindestens 1µs liegen.
Der Slot wird gestartet, indem der Master den Bus für mindestens 1µs
auf 0 zieht, und dann wieder vom Pull-Up auf 5V gehen lässt.
Der DS1820 überträgt daraufhin sein Bit:
Lesen einer 0:
  Der DS1820 zieht den Bus nach der fallenden Flanke vom Master auf 0.
  Das Signal muss innerhalb von 15µs nach Beginn vom Master gesampelt
werden.
Lesen einer 1:
 Der DS1820 lässt den Bus weiterhin auf 5V (vom Pull-Up hochgezogen)
 Das Signal muss innerhalb von 15µs nach Beginn vom Master gesampelt
werden.

So habe ich das auch programmiert, erhalte aber keine Daten zurück.
(Ich habe vorher ein READ ROM (0x33) gesendet)

Die Funktion w1_bit_io() von Peter funktioniert auch anders:
Er programmiert erst den Pin als Ausgang, nach 1µs Wartezeit dann
wieder als Eingang, liest dann nach 14µs den Pin ein.
Zum Abschluss wird der Pin nochmals als Eingang programmiert (wohl nur,
weil die Funktion auch zum Bits senden benötigt wird).

Wieso funktioert das bei Peter, obwohl er den Ausgang ja garnicht auf 0
zieht und dem Slave mitzuteilen dass der Slot gestartet wird?
Autor: Peter Dannegger (Gast)
Datum: 31.10.2005 08:55

@Thomas

es wird ja ein open-drain Ausgang benötigt, d.h. das Ausgangsbit bleibt
immer auf 0 und mit dem Direktionbit wird dann nur der untere Transistor
ein- bzw. ausgeschaltet.


Peter
Autor: Thomas (Gast)
Datum: 31.10.2005 11:33

Achso OK, das aktive auf 0 setzen des Ausgangs machst du nur einmal in
der 1-Wire Initialisierungsroutine. Naja, reicht ja auch eigentlich, da
diese vor jedem Übertragungsbeginn sowieso einmal durchlaufen wird.
Autor: Simons (Gast)
Datum: 06.11.2005 20:59

Hallo!
Wo ich syscode ds1820.obj erhalten kann, das ich im Programm benötige.
Danke!
Autor: xzibit (Gast)
Datum: 16.12.2005 11:50

Das Du kann erhalten compilieren. Mit Compiler.
Autor: Wolf4124 (Gast)
Datum: 31.03.2006 21:46

Hallo

Ich wollte einen anderen Pin verwenden.
Habe die Zeilen

#define OW_PIN  PD6
#define OW_IN   PIND
#define OW_OUT  PORTD
#define OW_DDR  DDRD
 auf

#define OW_PIN  PC5
#define OW_IN   PINC
#define OW_OUT  PORTC
#define OW_DDR  DDRC

geändert.
Ich verwende einen ATMEGA8.
Es funkt super aber eben nur mit dem PD6.
Wenn ich die andere Festlegung verwenden funkt es auch.?????
Aber nur über den PD6????
Vielleicht habe ich ja etwas übersehen.

Gruß
Autor: Peter Dannegger (peda)
Datum: 31.03.2006 22:33

@Wolf4124

diese Macros stehen nirgends in meinem Code.

Ist also kein Wunder, daß auf nicht verwendete Macros keine Reaktion
erfolgt.


Peter
Autor: wolf4124 (Gast)
Datum: 31.03.2006 22:49

Upps

Falsche Baustelle.  ;-(

Gruß
Autor: H-Joachim (Gast)
Datum: 24.05.2006 20:04

Hallo Peter.

Habe Deinen Source auf einem ATMEGA16 mit 8Mhz Quartz
ausprobiert. Nachdem es immer die Meldung "DATA_ERR" gab,
habe ich dann angefangen mit einem Scope zu messen.
Als erstes habe ich mir eine kleine Schleife geschrieben,
mit der ich messen konte, ob die delay-Funktion richtig
funktioniert (timing). Das tat sie.
Ich habe dann gesehen, daß Du bei einem READ immer erst
nach 15usec. die Daten des Sensors einließt. Laut Spec.
sollte das aber innerhalb von 15usec. passieren.
Habe dann Deinen Code zum Testen wie folgt "gepatcht":

#if 0
uchar w1_bit_io( bit b )
{
  cli();
  W1_DDR |= 1<<W1_PIN;
  DELAY( DELAY_US( 1 ));
  if( b )
    W1_DDR &= ~(1<<W1_PIN);
  DELAY( DELAY_US( 15 - 1 ));
  if( (W1_IN & (1<<W1_PIN)) == 0 )
    b = 0;
  DELAY( DELAY_US( 60 - 15 ));
  W1_DDR &= ~(1<<W1_PIN);
  sei();
  return b;
}
#else
uchar w1_bit_io( bit b )
{
  cli();
  W1_DDR |= 1<<W1_PIN;
  DELAY( DELAY_US( 1 ));
  if( b )
  {
    W1_DDR &= ~(1<<W1_PIN);
    DELAY( DELAY_US( 10 - 1 )); // beim LESEN kurzer delay
  }
  else
    DELAY( DELAY_US( 15 - 1 ));
  if( (W1_IN & (1<<W1_PIN)) == 0 )
    b = 0;
  DELAY( DELAY_US( 60 - 15 ));
  W1_DDR &= ~(1<<W1_PIN);
  sei();
  return b;
}
#endif

Damit funktionierte es.
Der DS1820 hat bei einer "0" das Signal schon nach 15usec
wieder auf 1 gesetzt. Das hatte ich mit dem Scope gesehen.
Darum natürlich "DATA_ERR".
Jetzt frage ich mich, wieso hat das bei Euch funktioniert?
Sind die Teile vom Timing so unterschiedlich? Allerdings laut
meinem Datenblatt (DS18S20) soll man auch innerhalb der 15usec lesen.
Liegt es an dem DS18S20 (S!!!!)?

Hast Du eine Idee?

Danke und Gruß
Joachim
Autor: peter dannegger (Gast)
Datum: 24.05.2006 23:03

@Joachim,

ich habs nicht nachgemessen.

Ich hab auch einige Meter Leitung dazwischen, deren Kapazität wird wohl
die Flanke etwas verzögern.

Der genaue Wert, wann der Slave wieder auf 1 geht, darf laut Datenblatt
irgendwo zwischen 15µs und 60µs liegen.

Du hast warscheinlich ein Exemplar erwischt, was genau am unteren Limit
liegt.


Peter
Autor: Dubbster (Gast)
Datum: 14.11.2006 19:01
Angehängte Dateien:

kann mir jemand beim 1 wire port helfen,ich muss das in c programmiern!
Autor: Dubbster (Gast)
Datum: 19.11.2006 10:01

hey kann mir wer sagen,ob das hier richtig ist!

#include<reg517.h>
#include<stdio.h>


//---------------------------------------
// Initialize serial port
//---------------------------------------



void InitSerial(void)
{
    TMOD = 0x20;    // Timer 1=8-Bit-relod
    TH1  = 0xFD;    // TH1
  TR1   = 1;      // Timer 1 starten
  SCON = 0x52;    // Freigabe von Sender & Empfänger
}

bei mir steht immer undefined identifier! jedoch sollte es meiner
meinung stimmen,blick da jetzt ned durch
Autor: Serge Polish (Gast)
Datum: 04.12.2006 15:33

Good day, Peter!

Thanks for the "1Ware.zip"!

Best regards, P.S.
Autor: Karl (Gast)
Datum: 12.12.2006 17:35

Hallo

Ich habe das Programm ProfiLab Expert. Mit dem Programm kann man
Schaltungen am PC realisieren.
Für meine Anwendung (Heizungsregeler) muss ich Temperaturen erfassen die
ich über den 1 wire Bus auslesen möchte. Es gibt fertige Lösungen z.B.
von der Firma Hygrosens, die mir aber etwas zu teuer sind.
In ProfiLab kann man aber DLL Dateien importieren die in C++ oder Delphi
geschrieben werden müssen.
Gibt es eine DLL um den 1 wire Bus in Profilab Expert auszulesen um
damit die Temperatur zu messen?

Ich habe hier einmal einen Auszug der Hilfe zum DLL-Import von ProfiLab
reingestellt.


DLL-Import

Funktion
Mit dem DLL-Import haben Sie ein Bauteil zur Verfügung, dass eine
Programmierschnittstelle darstellt, die es ermöglicht selbst eigene
Bauteile, z.B. zur Ansteuerung spezieller Hardware, o.ä., für ProfiLab
zu programmieren. Dazu benötigen Sie natürlich eine Programmiersprache,
die es ermöglicht DLL-Dateien (Dynamic Link Libraries) zu erzeugen,
sowie die entsprechenden Programmierkenntnisse.

Bei der Programmierung der DLL müssen Sie sich an bestimmte Vorgaben von
ProfiLab halten. So muss Ihre DLL bestimmte Routinen enthalten und
exportieren, mit denen Sie die Anzahl der Ein- und Ausgänge, deren
Bezeichnung und natürlich die interne Funktion des Bauteils bestimmen.
Folgende Funktionen muss Ihre DLL bereitstellen:

Delphi: function NumInputs: Byte;
C++: unsigned char _stdcall NumInputs()
Das Ergebnis dieser Funktion muss einen Bytewert mit der gewünschten
Anzahl von Bauteileingängen zurückliefern.

Delphi: function NumOutputs: Byte;
C++: unsigned char _stdcall NumOutputs()
Das Ergebnis dieser Funktion muss einen Bytewert mit der gewünschten
Anzahl von Bauteilausgängen zurückliefern.

Delphi: function InputName(Channel: Byte): ShortString;
C++: void _stdcall GetInputName(unsigned char Channel, unsigned char
*Name)
Das Ergebnis dieser Funktion muss einen Text für die Beschriftungen
jedes Eingangs (Channel) zurückliefern. Das Bauteil ruft diese Funktion
für jeden Eingang (Channel) auf und fragt so die Beschriftung für jeden
Eingangs-Pin ab. Der Parameter CHANNELS gibt an welcher Pin gemeint ist,
und läuft von 0 bis NumInputs-1.

Delphi: function OutputName(Channel: Byte): ShortString;
C++: void _stdcall GetOutputName(unsigned char Channel, unsigned char
*Name)
Das Ergebnis dieser Funktion muss einen Text für die Beschriftungen
jedes Ausgangs (Channel) zurückliefern. Das Bauteil ruft diese Funktion
für jeden Eingang (Channel) auf und fragt so (von oben nach unten) die
Beschriftung für jeden Eingangs-Pin ab. Der Parameter CHANNELS gibt an
welcher Ausgangs-Pin gemeint ist, und läuft von 0 bis NumOutputs-1.

Delphi: Procedure Calculate(PInput,POutput,PUser: PDLLParams);
C++: void _stdcall CCalculate(double *PInput, double *POutput, double
*PUser)
Die ist die zentrale Berechnungsroutine Ihres DLL-Bauteils, die die
Funktion des Bauteils definiert. Mit den Parametern PINPUT, POUTPUT und
PUSER bekommt die Routine drei Zeigervariablen (Pointer) übergeben die
folgende Funktion haben:

Der Pointer PINPUT zeigt auf einen Speicherbereich, der dazu dient die
Eingangswerte des Bauteils an die DLL zu übergeben.
Der Pointer POUTPUT zeigt auf einen Speicherbereich, der dazu dient die
berechneten Ausgangswerte der DLL an das Bauteil zurückzugeben.
Der Pointer PUSER stellt einen Pointer auf einen Speicherbereich zur
Verfügung, in dem die DLL eigene (lokale) Werte speichern kann.
Hintergrund: Variablen, die die DLL selbst deklariert sind globale
Variablen. Werte die in diesen Variablen gespeichrt werden, würden sich
gegenseitig überschreiben, wenn man dieselbe DLL mehr als einmal in
einem ProfiLab-Projekt verwendet. Um lokale Werte speichern zu können,
stellt ProfiLab der DLL den lokalen Speicherbereich zur Verfügung, auf
den PUSER zeigt. (Alternativ kann man auch Variablen in der DLL selbst
deklarieren. Dann muß man die DLL aber mehrfach unter verschiedenen
Dateinamen speichern und importieren, um sie mehrfach in einem
ProfiLab-Projekt verwenden zu können.)

Alle drei Pointer PINPUT, POUTPUT und PUSER zeigen jeweils auf einen
Speicherbereich in dem 100 Variablen vom Typ EXTENDED in einem Array
abgelegt sind. Die Pointer sind vom Typ PDLLParams, dessen Deklaration
in Delphi so aussieht:

type TDLLParams = array[0..100] of extended;
     PDLLParams = ^TDLLParams;

Die Extended-Variablen des Pointers PINPUT enthalten die
Eingangszustände des Bauteils. Auf den Wert eines Eingangs des Bauteils
können Sie wie folgt zugreifen:

PInput^[0] enthält den numerischen Eingangswert des 1. Eingangs,
PInput^[1] enthält den numerischen Eingangswert des 2. Eingangs, usw.

Die Extended-Variablen des Pointers POUTPUT nehmen die Ausgangszustände
des Bauteils auf. Um den Wert der Ausgänge des Bauteils zu setzen,
benutzen Sie:

POutput^[0] nimmt den numerischen Ausgangswert des 1. Ausgangs auf,
POutput^[1] nimmt den numerischen Ausgangswert des 2. Ausgangs, usw.

Entsprechend können Sie mit PUser^[0] bis PUser^[99] frei verwenden um
eigene Werte zu speichern. Die Werte in diesen Variablen werden von
ProfiLab mit in der Projektdatei abgespeichert, und sind so beim
nächsten Laden des Projekts wieder verfügbar. Die Variable PUser^[100]
wird von ProfiLab gesetzt, und enthält die Nummer des DLL-Bauteils in
Ihrem Projekt: 1 für DLL1, 2 für DLL2, usw.

Die Routine Calculate wird im RUN-Modus ständig von ProfiLab aufgerufen,
um neue Eingangswerte zu übergeben und neue Ausgangswerte für das
Bauteil abzurufen. Diese Routine muss daher unbedingt zeitoptimiert
programmiert werden, und sollte auf keinen Fall Pausen (in Form von
SLEEP-Befehlen oder Warteschleifen) enthalten. Nach dem Abfragen der
Eingangswerte und dem Setzen der Ausgangswerte sollte die Routine so
schnell wie möglich wieder verlassen werden. Die Rechenzeit für die
Routine wirkt sich unmittelbar auf die Simulationsfrequenz von ProfiLab
aus.

Delphi: Procedure SimStart(PInput,POutput,PUser: PDLLParams);
C++: void _stdcall CSimStart(double *PInput, double *POutput, double
*PUser)
Diese Routine wird beim Starten eines ProfiLab-Projekt aufgerufen, und
kann z.B. benutzt werden, um Anfangswerte Ihrer DLL zu initialisieren.
Die Funktion der Parameter wurde zuvor bereits beschrieben.

Delphi: Procedure SimStop(PInput,POutput,PUser: PDLLParams);
C++: void _stdcall CSimStop(double *PInput, double *POutput, double
*PUser)
Diese Routine wird beim beenden des RUN-Modus eines ProfiLab-Projekt
aufgerufen, und kann z.B. um geöffnete Dateien zu schliessen, etc.. Die
Funktion der Parameter wurde zuvor bereits beschrieben.

Delphi: Procedure Configure(UserValues: PDLLParam);
C++: void _stdcall CConfigure(double *PUser)
Sofern Ihre DLL diese Prozedur exportiert, wird die Schaltfläche
EINSTELLUNGEN... im Eigenschaftendialog des DLL-Bauteils aktiviert. Wird
dann diese Schaltfläche betätigt, so springt ProfiLab die
CONFIGURE-Prozedur in Ihrer DLL an. Hier können Sie dann z.B. einen
eigenen Dialog zum Konfigurieren Ihrer DLL ausführen.

Mit diesen Routinen haben Sie alle Möglichkeiten um eigene Bauteile für
ProfiLab programmieren zu können. Der Fantasie sind dabei keine Grenzen
gesetzt. Sie könnten z.B. Treiber für eigene Hardwaregeräte
programmieren, einen eigene Programminterpreter integrieren, oder
beliebige andere komplexe Berechnungen in einer DLL ausführen. Um
digitale Bauteile zu programmieren, setzen Sie den numerischen
Ausgangswert auf 5 um einen HIGH-Pegel zu erzeugen und auf 0 um einen
LOW-Pegel zu erzeugen. Ebenso entspricht ein Eingangswert >2.5  einem
logischen HIGH-Pegel und ein Eingangswert darunter einem logischen
LOW-Pegel.

Beim Laden einer DLL-Datei über den Eigenschaften-Dialog des
DLL-Bauteils, werden die aus der DLL importierten Routinen zur Kontrolle
aufgelistet. Das Bauteil erscheint danach mit den von Ihnen definierten
Ein- und Ausgängen im Schaltplan.  Um den Aufrufkonventionen von
C-Compilern zu genügen, kann dem Namen von exportierten Funktionen und
Prodeduren jeweils auch ein Unterstrich _ vorangestellt sein, z.B.
_SimStart statt SimStart. Derart exportiere Routinen werden
gleichermassen von ProfiLab erkannt und importiert. Beim Compilieren
eigener DLL-Projekte müssen Sie ggf. darauf achten, dass Sie die
Linkeroption "Dynamische RTL" deaktivieren. Anderfalls kann Ihre DLL auf
Systemen ohne installierte C++-Umgebung nicht geladen werden.
Autor: Peter Dannegger (peda)
Datum: 13.12.2006 08:41

@Karl,

für ellenlange Texte hat der Forenbetreiber den Dateianhang gedacht.


Ein PC für ne Heizungsregelung wäre mir zu unzuverlässig, teuer und
stromfressend.
Hier im MC-Forum nimmt man eigentlich nen MC dafür.


Fragen zur PC-Programmierung sind außerdem besser in der Rubrik
"PC-Programmierung" aufgehoben.


Peter
Autor: Falk (Gast)
Datum: 13.12.2006 11:31

@Peter Dannegger

> Ein PC für ne Heizungsregelung wäre mir zu unzuverlässig, teuer und
> stromfressend.

Der PC IST die Heizung ;-)

MFG
Falk

Autor: Karl (Gast)
Datum: 13.12.2006 12:31

@ Peter

Danke für die schnelle Antwort und den Tip mit dem anderen Forum.
Nur noch eine Frage: Kann man mit einem PC den überhaupt den 1 wire bus
auslesen, ohne ein MC dazwischenzuschalten (ist der PC schnell genug)?

P.S. Die Energiekosten die der PC zur Steuerung braucht, spar ich durch
geringere Pumpenlaufzeiten ein. Außerdem kenne ich mich mit MC nicht so
aus.

MFG
Karl
Autor: Falk (Gast)
Datum: 13.12.2006 14:54

@Karl

> Kann man mit einem PC den überhaupt den 1 wire bus
> auslesen, ohne ein MC dazwischenzuschalten (ist der PC schnell genug)?

Naja, es sollte schon mindestens ein P4 mit 3 GHz sein ;-)

Im Ernst, der PC ist schnell genug, aber das Timing der One-wire ICs ist
recht schnell und du brauchst dafür einen Low-Level Treiber. Knifflige
Sache. Für einen uC kein Problem, der muss nicht WinXP mit sich
rumschleppen.

Ich behaupte mal, der Aufwand sich in uC einzuarbeiten ist geringer als
eine low-level Treiber für winXP zu schreiben. Und am Ende hast du eine
wesentlich bessere und zweckmässigere Heizungssteuerung. uCs kannst du
einfach in C programmieren, so wie deinen PC auch.

MFG
Falk


Autor: irgendein Rahul (Gast)
Datum: 13.12.2006 15:19

>P.S. Die Energiekosten die der PC zur Steuerung braucht, spar ich durch
>geringere Pumpenlaufzeiten ein

Wozu dann die Steuerung, wenn es keine Verbesserung gibt?
(Ich hab mir nicht den langen Post durchgelesen; vielleicht gibt es die
Antwort ja auch in Kurzform...).

>Außerdem kenne ich mich mit MC nicht so aus.

Was spricht dagegen, das zu ändern?

Schade, dass ich sonst nichts zu diesem Thema beitragen kann.
Autor: Pete (Gast)
Datum: 13.12.2006 15:28

Den 1-wire bus kann man sehr schön auch in Java programmieren. Gibt es
auf der Herstellerseite www.maxim.de. Schnell genug ist der PC.

Am einfachsten geht es mit dem DS9490R über USB.

Und hier ein Link für eine einfache Ansteuerung :
lena.franken.de/hardware/temperaturmessung.html

Selbst mit einem Epia-Board braucht der PC immer noch 20W. Mit
Mikrocontroller liegt man eher bei 20mW (!).

20W sind immerhin 175kWh pro Jahr...

Das Problem bei den DS1820 ist die breite Messfläche. Lufttemperatur
lässt sich gut messen, aber als Anlegesensoren sind sie eher weniger
geeignet.
Die Sensoren muss man sehr gut isolieren, wenn man sie direkt auf das
Kupferrohr klebt. Ich habe teilweise bis zu 5 Grad Unterscheid zur
Heizungsregelung gehabt. Wärmeleitpaste und schön Festzurren
(Kabelbinder) hilft auch ein bischen.

Gruss,
Pete
Autor: Axel (Gast)
Datum: 19.12.2006 15:57

"Kann man mit einem PC den überhaupt den 1 wire bus
auslesen, ohne ein MC dazwischenzuschalten (ist der PC schnell genug)?"

Gibt es Digitemp für. Ältere Versionen liefen auch unter Windows. Da
wird die serielle Schnittstelle für verwendet.

Gruss
Axel
Autor: EFI (Gast)
Datum: 19.12.2006 22:45

@Karl

Hallo Karl,

ich betreibe seit ca. 1 Jahr meine kpl. Haus-Heizungssteuerung via PC.
Als Sensorik fungieren 32 DS18B20 (Boden-, Luft-, Vor- und
Rücklauftemperaturen). Die Sensoren sind via DS2482-800 und I2C via
Parallel-Port angeschlossen. Die komplette Steuerung (nebst kpl.
Haussteuerung) ist in C++ geschrieben. Wenn ich Dir diesbezüglich
weiterhelfen kann, gern.
Autor: Karl (Gast)
Datum: 20.12.2006 19:58

Hallo EFI

Danke für dein Angebot. Ich kenne mich in C++ nicht aus, deshalb wollte
ich meine Steuerung mit ProfiLab Expert realisieren. Mit dem Programm
kann man Schaltungen erstellen, ohne eine Zeile zu programmieren. In dem
Programm ist schon einiges an Hardware eingebunden, aus für den 1 wire
bus. Es gibt aber ein Bauteil womit man eine DLL-Datei importieren kann.
Diese DLL-Datei kann in C++ geschrieben werden und müste den 1-wire bus
bzw die angeschlossenen Sensoren auslesen. Bei der Programmierung der
DLL-Datei müssen nur einige Vorgaben eingehalten werden.

Wie leicht oder schwer ist es in C++ zu programmieren und wie lange hast
du für dein Programm gebraucht gebraucht?

Ist deine Steuerung kpl. in C++ und ist sie visualisiert d.h
Temperaturanzeigen, Temperaturganglinien, Optischer und Akustischer
Alarm, Welche Eingabe möglichkeiten gibt es usw..

Wie Regelst du die Heizung nach Vor oder Rücklauftemperatur, Heizkurve,
Zeit, Warmwasseraufbereitung?

Also nochmals Danke!!!
Autor: wesch (Gast)
Datum: 03.01.2007 14:19

Hallo Forum!

Ich hab mal studienhalber die Bibliotheken getestet und alles
funktioniert wunderbar.

Da ich jedoch verstehen will wie das alles so tickt (bin AVR-Anfänger)
hab ich mein Problem bei der Funkion w1_reset

bit w1_reset(void)
{
  bit err;

  W1_OUT &= ~(1<<W1_PIN);
  W1_DDR |= 1<<W1_PIN;
  DELAY( DELAY_US( 480 ));
  cli();
  W1_DDR &= ~(1<<W1_PIN);
  DELAY( DELAY_US( 66 ));
  err = W1_IN & (1<<W1_PIN); // no presence detect
  sei();
  DELAY( DELAY_US( 480 - 66 ));
  if( (W1_IN & (1<<W1_PIN)) == 0 )    // short circuit
    err = 1;
  return err;
}

1. Problem mit der Zeile err = W1_IN & (1<<W1_PIN);
   err ist ein bit und kann 0 oder 1 werden
   W1_IN ist doch der Status des Eingangs
   doch mit dem & (1<<W1_PIN); komm ich nicht klar

   Was passiert da?

2. DELAY( DELAY_US( 480 - 66 ));
   Die DELAY-Funktion bekommt dann als Argument DELAY_US....?


vielen Dank schon mal
Autor: Jankey (Gast)
Datum: 03.01.2007 16:37

@EFI: Wie weit sind deine Sensoren voneinander entfernt?

lg Jan
Autor: Frank Se. (Gast)
Datum: 27.02.2007 22:57

Hallo Peter,

ich habe mir deinen 1Wire C-Code heruntergeladen.
Zuerst habe ich auf dem AT90S8535 (8Mhz Takt) die Reset Funktion
getestet.
Wenn ich die Funktion ResetDS1820 ausführe erhalte ich immer den Wert 2.
Das verstehe ich nicht. Dies bedeutet doch dass der DS1820 nicht erkannt
wurde oder?

// Diese Funktion habe ich zuerst erstellt. Ohne dass ich deinen Code
// kannte
// Bei der Ausführung dieser Funktion erhalte ich "0"
char ResetDS1820(void)
{
 presence = 0xFF;
 DDRD.2=1;    // PORTD.2 --> OUTPUT
 PORTD.2 = 0;           // PORTD.2 den Wert 0 ausgeben
 delay_us(480);   // Zeitverzögerung von 500us
 PORTD.2 = 1;           // PORTD.2 den Wert 0 ausgeben
 delay_us(66);          // Zeitverzögerung von 70us
 DDRD.2=0;              // PORTD.2 --> INPUT
 presence = PIND.2;   // Signal mit PIND.2 einlesen und der Variable
                        // presence zuweisen
 delay_us(480-66);   // Zeitverzögerung von 250us
 DDRD.2=1;              // PORTD.2 --> OUTPUT
 return presence;       // Ausgabe von presence
}// 0=presence, 1=no part


// Diese Funktion habe ich von deiner ZIP Datei übernommen
#ifndef W1_PIN
#define W1_PIN  PORTD.2
#define W1_IN         PIND
#define W1_OUT  PORTD
#define W1_DDR  DDRD
#endif

unsigned char w1_reset(void)
{
  unsigned char err;
  err = 0x00;
  W1_OUT &= ~(1<<W1_PIN);
  W1_DDR |= 1<<W1_PIN;
  delay_us(480);      // 480 us
  W1_DDR &= ~(1<<W1_PIN);
  delay_us(66);
  err = W1_IN & (1<<W1_PIN);      // no presence detect
  delay_us(480-66);
  if( (W1_IN & (1<<W1_PIN)) == 0 )    // short circuit
    err = 1;
  return err;
}

Hier erscheint bei mir immer 2 als Rückgabewert.

Ich programmiere mit dem CodeVision AVR
Autor: Peter Dannegger (peda)
Datum: 27.02.2007 23:27

Frank Se. wrote:


> #define W1_PIN  PORTD.2

So gehts nicht.

Der Code ist für WINAVR geschrieben und der kennt keine Bitvariablen.

Also mußt Du da die Bitnummer (0..7) eintragen.


> Hier erscheint bei mir immer 2 als Rückgabewert.

Das ist möglich, wenn Du Pin 1 eines Ports benutzt.
0 = o.k.
!0 = Fehler


Peter


Autor: Frank Se. (Gast)
Datum: 28.02.2007 10:34

Danke Peter für die Unterstützung.
Ich habe die Funktion nochmals auf den CodeVision_AVR abgestimmt.
An Pin PD2 ist die Datenleitung vom DS1820 angeschlossen.

#define W1_PIN  PORTD.2 // Ausgang
#define W1_IN  PIND.2  // Eingang
#define W1_OUT  PORTD.2 // Ausgang
#define W1_DDR  DDRD.2  // die Richtung kann hiermit bestimmt werden.

unsigned char w1_reset(void)
{
  unsigned char err;
  err = 0x00;
  W1_OUT &= ~(W1_PIN);
  W1_DDR |= W1_PIN;
  delay_us(480);       // 480 us
  W1_DDR &= ~(W1_PIN);
  delay_us(66);
  err = W1_IN & (W1_PIN);      // no presence detect
  delay_us(480-66);
  if( (W1_IN & (W1_PIN)) == 0 )// short circuit
    err = 1;
  return err;
}

Leider erscheint auf meinem Display eine "1".
Dies bedeutet DS1820 wurde nicht erkannt.
Warum eigentlich "W1_PIN" und "W1_IN"?
Es kann sein das ich bei der Definition noch einen Fehler habe.
ich weiss allerdings nicht wo.
Autor: Frank Se. (Gast)
Datum: 28.02.2007 10:37

Ich verstehe es nicht. WIe müsste ich dann die Definitionen unter
CodeVision_AVR deklarieren?
Autor: Frank Se. (Gast)
Datum: 28.02.2007 10:55

Also ich denke die Definition ist bei mir falsch.

Wie müsste die Definition dann bei mir aussehen?
#ifndef W1_PIN
#define W1_PIN  PD6
#define W1_IN  PIND
#define W1_OUT  PORTD
#define W1_DDR  DDRD
#endif
Autor: Frank Se. (Gast)
Datum: 28.02.2007 13:49

So ich habe mal das ganze ohne define erstellt.

unsigned char w1_reset(void)
{
  unsigned char err;
  err = 0x00;
  PORTD.2=0;
  DDRD.2=1;
  delay_us(480);
  DDRD.2=0;
  delay_us(66);
  err = PIND.2;
  delay_us(480-66);
  if( (PIND.2) == 0 )
    err = 1;
  return err;
}

Wenn ich diese Funktion ausführe, dann erhalte ich auch den Wert "0".
Also funktioniert doch das ganze oder?
Autor: Frank Se. (Gast)
Datum: 28.02.2007 13:52

W1_OUT &= ~(1<<W1_PIN); --> PORTD.2=0;
W1_DDR |= 1<<W1_PIN;    --> DDRD.2=1;
W1_DDR &= ~(1<<W1_PIN); --> DDRD.2=0;
W1_IN & (1<<W1_PIN);    --> PIND.2

Stimmt meine Interpetation so?
Autor: Frank Se. (Gast)
Datum: 28.02.2007 18:07

Vielen Dank nochmals!
Der DS1820 läuft bei mir jetzt. Bin jetzt voll happy.
Nur noch eine Sache hätte ich da, ich kann nur ganze Temperaturen
darstellen,
wie z.B. 21 C°. Was muss ich tun, damit ich z.B. so einen Wert 21.5 C°
auslesen kann?
Autor: hansl (Gast)
Datum: 15.03.2007 12:52

Servus Peter,

irgendwie bekomm ich dieses 1wire zeug einfach nicht zum
laufen.

mein hardwaresetup habe ich nun mehrmals aufgebaut.
die strippen und widerstaende ausgetauscht. alles ohne erfolg.
deine software meldet mir BusError.

funktioniert dein code auch mit ds1821?

hast du nen vorschlag wie ich den bus debuggen koennte?

mfg
 hansl
Autor: hansl (Gast)
Datum: 15.03.2007 13:11

ok, der ds1821 hat einen andren befehlssatz und funtionen.

dennoch, debugginbgtips fuer 1wire?
Autor: Peter Dannegger (peda)
Datum: 15.03.2007 19:38

@hansl,

wenn mich nicht alles täuscht, hat der DS1821 gar keine Adresse.
Die ganzen ROM-Kommandos gehen also nicht.

Nach dem Reset macht man sofort die gewünschte Aktion (Messung starten,
Wert auslesen usw.).

Es gibt da allerdings auch noch nen Temperaturschaltermodus. Wenn er da
drin ist, muß man ihn erstmal mit ner speziellen Sequenz zurückschalten.

Er kann auch kein parasite Power.


Peter
Autor: hansl (Gast)
Datum: 15.03.2007 22:46

danke peter,

werd mich jetzt mal ans portieren deines programms machen
und hier hoffentlich bald die ds1821 version hochladen.

mfg
 hansl
Autor: Markus Hiller (Gast)
Datum: 18.03.2007 23:41

Hi Leutz,

bin grad am rumtesten mit dem von P.D. geposteten Code. Mit einem DS1820
Sensor funktioniert alles wunderbar.
Nun hab ich hier ausm Forum/Markt DS1822 gekauft. Leider läuft keiner
dieser Sensoren an der Schaltung. Laut Datasheets sind die Dinger völlig
identisch bis auf die größere Ungenauigkeit des DS1822. Oder hab ich das
was übersehen?

Gruß  -  Markus
Autor: Hansl (Gast)
Datum: 12.04.2007 02:13

mit der portierung auf DS1821 wirds nun endgueltig nix. hab nun meinen
zweiten sensor verpolt und gegrillt. sollt mir mal ne 2.te rolle
litze in ner andren farbe kaufen, bei der gelegenheit hol ich mir
dann auch gleich nen DS1820 und gut ists.

sorry for the inconvenience.

mfg
Hansl
Autor: Peter Dannegger (peda)
Datum: 12.04.2007 09:56

Hansl wrote:
> mit der portierung auf DS1821 wirds nun endgueltig nix. hab nun meinen
> zweiten sensor verpolt und gegrillt.

Gehörst Du etwa auch zu den unbelehrbaren, die ein 5V/100A PC-Netzteil
zum Basteln benutzen ?

Für MC-Experimente nehme ich ne Wandwarze und nen 78L05 dahinter.
Der 78L05 begrenzt auf etwa 100mA, dann wird nichts mehr gegrillt.


Peter
Autor: Andreas Koch (eisenkoch)
Datum: 27.05.2007 13:59

leider erhalte ich immer den folgenden Fehler:
../TEMPMEAS.C:37: error: invalid conversion from 'unsigned char*' to 'char*'
../TEMPMEAS.C:37: error: initializing argument 1 of 'int sprintf(char*, const char*, ...)'
../TEMPMEAS.C:38: error: invalid conversion from 'unsigned char*' to 'char*'
../TEMPMEAS.C:38: error: initializing argument 1 of 'void uputs(char*)'

woran kann das liegen?
Autor: Peter Dannegger (peda)
Datum: 27.05.2007 16:25

@Andreas,

das hat historische Gründe:

Früher wurden nur 7Bit Zeichen verwendet und deshalb sind die
C-Stringfunktionen vom Typ char, was eigentlich Blödsinn ist, denn es
gibt keine negativen Zeichen.

Heutzutage ist ASCII 8Bit unsigned (0..255), aber die Funktionen sind
scheinbar vorzeichenbehaftet geblieben.

Scheinbar deshalb, weil sie die ASCII Zeichen intern als unsigned char
behandeln. Es sind also die ASCII-Zeichen von 0..255 erlaubt und gültig.


Um nun nicht durcheinander zu kommen, machen Compiler üblicher Weise
eine implizite Pointerkonvertierung, wenn der Bassistyp stimmt.

Dein Compiler scheint nun weit über das Ziel hinausgeschossen zu sein,
indem er das verweigert.

Als Workaround bleibt dann nur eine explizite Pointerkonvertierung:

sprintf( (char*)s ...

Man könnte auch das Array als char definieren, dann könnte aber der
Compiler wieder meckern, wenn man ASCII-Zeichen >127 reinschreibt.


Peter


P.S.:
Könnte das ne neue Macke des AVR-GCC 4.1.1 sein ?
Autor: A.K. (Gast)
Datum: 07.06.2007 18:06

Wenn "char" mit Vorzeichen ist, dann ist die "char *" zwar kompatibel
mit "signed char "*, nicht aber mit "unsigned char *". Alles andere wäre
ein Compilerfehler.

Die Entscheidung dafür, "char" vorzeichenbehaftet zu verstehen, geht
zurück auf Eigenschaften der ersten Implementierung auf einer PDP-11.
Und lässt sich mit -funsigned-char beheben.

Soweit C, soweit so einfach. Interessanter wird es bei C++. Hier
möglicherweise relevant, da ohne ausdrückliche Gegenwehr ein gross
geschriebenes ".C" als C++ übersetzt wird.

Da man beim Overloading sonst in Teufel's Küche landet, hat man sich
nach anfänglichem Durcheinander zu 3 Varianten entschlossen. "char",
"signed char" und "unsigned char". Sachlich sind davon zwar 2 gleich, es
sind aber dennoch 3 verschiedene Typen.
Autor: Peter Dannegger (peda)
Datum: 07.06.2007 19:56

A.K. wrote:

> Soweit C, soweit so einfach. Interessanter wird es bei C++. Hier
> möglicherweise relevant, da ohne ausdrückliche Gegenwehr ein gross
> geschriebenes ".C" als C++ übersetzt wird.

Stimmt, daran kanns liegen. Ich schreibe deshalb immer:

avr-gcc.exe -xc ...


Peter
Autor: Paul Reichenbach (Gast)
Datum: 18.06.2007 00:11

Hallo,
ich verstehe in der Datei tempmeas.c folgenden Ausdruck nicht:
 sprintf( s, "%4d.%01d", temp >> 4, (temp << 12) / 6553 ); // 0.1 auflösung 

genauer gesagt den Part wo die Kommastelle gebildet wird. Warum wird
durch 6553 geteilt? Ich versuche das ganze in 0,5° Schritten
darzustellen und komme nicht weiter.

Sehe ich das richtig, wenn ich negative Zahlen darstellen möchte, das
ich das zwölfte Bit auswerten muss ?

Viele Grüße

Paul
Autor: Fabio (Gast)
Datum: 23.07.2007 18:10

hey Leute ich versuche gerade die 1wire zip zu kompelieren und bekomme
da ein paar fehler. kann mir da vieleicht jemand weiter helfen

> "make.exe" all

-------- begin --------
avr-gcc (GCC) 4.1.2 (WinAVR 20070525)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


Compiling: main.c
avr-gcc -c -mmcu=atmega32 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=main.lst  -std=gnu99
-Wp,-M,-MP,-MT,main.o,-MF,.dep/main.o.d main.c -o main.o

Linking: main.elf
avr-gcc -mmcu=atmega32 -I. -g   -Os -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o
-std=gnu99 -Wp,-M,-MP,-MT,main.o,-MF,.dep/main.elf.d main.o 1WIRE.C
DELAY.C TIMEBASE.C TEMPMEAS.C UART.C   --output main.elf
-Wl,-Map=main.map,--cref    -lm
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
TEMPMEAS.C: In function 'void read_meas()':
TEMPMEAS.C:37: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:37: error:   initializing argument 1 of 'int sprintf(char*,
const char*, ...)'
TEMPMEAS.C:38: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:38: error:   initializing argument 1 of 'void uputs(char*)'
TEMPMEAS.C:45: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:45: error:   initializing argument 1 of 'int sprintf(char*,
const char*, ...)'
TEMPMEAS.C:46: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:46: error:   initializing argument 1 of 'void uputs(char*)'
TEMPMEAS.C:47: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:47: error:   initializing argument 1 of 'int sprintf(char*,
const char*, ...)'
TEMPMEAS.C:48: error: invalid conversion from 'unsigned char*' to
'char*'
TEMPMEAS.C:48: error:   initializing argument 1 of 'void uputsnl(char*)'
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is valid
for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
make.exe: *** [main.elf] Error 1

> Process Exit Code: 2
> Time Taken: 00:02


wäre echt klasse wenn wir das hin bekommen würden. viel dank Fabio
Autor: Peter Dannegger (peda)
Datum: 23.07.2007 18:33

Versuch mal:

avr-gcc -xc


Peter
Autor: Fabio (Gast)
Datum: 23.07.2007 19:10

Sorry das verstehe ich nicht so ganz. Ich bin noch in der lernphase und
kenne deswegen noch nicht alle kürzel usw. Vieleicht hilft ja das ich
programmiere mit Programmers Notepad 2. mfg Fabio
Autor: Simon K. (simon) Benutzerseite
Datum: 23.07.2007 19:23

Dein Compiler versucht die Datei(en) nach C++ Standard zu kompilieren.
mit dem Compilerparameter -xc erzwingt man (denke ich?) den C Standard.
Alternativ kannst du die Dateieendung von ".C" nach ".c" ändern. Daran
erkennt der Compiler das nämlich.
Autor: Fabio (Gast)
Datum: 23.07.2007 19:44

alles klar klingt logisch sagt ja auch der compiler. Also habe ich die
datei endungen von "C" auf "c" geändert. Tut sich aber nichts! gleicher
fehler. Kann man das irgendwo einstellen ? mfg Fabio
Autor: Andreas K. (a-k)
Datum: 23.07.2007 19:48

Musst den Namen im Makefile/Projektfile ändern. Wenn im Protokoll .C
statt .c drinsteht hast du verloren.
Autor: Fabio (Gast)
Datum: 23.07.2007 19:58

Sorry das ich euch nochmal belästigen muss aber ich bin leider nicht so
der crack! der alte Fehler ist behoben aber dafür giebt es einen neuen.

Compiling: TEMPMEAS.c
avr-gcc -c -mmcu=atmega32 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=TEMPMEAS.lst  -std=gnu99
-Wp,-M,-MP,-MT,TEMPMEAS.o,-MF,.dep/TEMPMEAS.o.d TEMPMEAS.c -o TEMPMEAS.o
TEMPMEAS.c: In function 'read_meas':
TEMPMEAS.c:37: warning: pointer targets in passing argument 1 of
'sprintf' differ in signedness
TEMPMEAS.c:38: warning: pointer targets in passing argument 1 of 'uputs'
differ in signedness
TEMPMEAS.c:45: warning: pointer targets in passing argument 1 of
'sprintf' differ in signedness
TEMPMEAS.c:46: warning: pointer targets in passing argument 1 of 'uputs'
differ in signedness
TEMPMEAS.c:47: warning: pointer targets in passing argument 1 of
'sprintf' differ in signedness
TEMPMEAS.c:48: warning: pointer targets in passing argument 1 of
'uputsnl' differ in signedness

Compiling: UART.c
avr-gcc -c -mmcu=atmega32 -I. -g   -Os -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=UART.lst  -std=gnu99
-Wp,-M,-MP,-MT,UART.o,-MF,.dep/UART.o.d UART.c -o UART.o
UART.c:1: error: expected identifier or '(' before numeric constant
UART.c:19:11: error: invalid suffix "B9" on integer constant
UART.c:21:11: error: invalid suffix "BC" on integer constant
UART.c:23:11: error: invalid suffix "BB8" on integer constant
UART.c:25:6: error: invalid digit "8" in octal constant
UART.c:26:6: error: invalid suffix "a" on integer constant
UART.c:26:11: error: invalid suffix "BD" on integer constant
UART.c:28:6: error: invalid suffix "c" on integer constant
UART.c:29:6: error: exponent has no digits
UART.c:29:11: error: invalid suffix "AB9" on integer constant
UART.c:31:11: error: invalid digit "9" in octal constant
UART.c:44:11: error: invalid suffix "D9B" on integer constant
UART.c:45:11: error: invalid suffix "C0" on integer constant
UART.c:47:11: error: invalid suffix "CB9" on integer constant
UART.c:49:6: error: invalid digit "8" in octal constant
UART.c:49:11: error: invalid digit "9" in octal constant
UART.c:60:6: error: invalid suffix "a" on integer constant
UART.c:61:6: error: invalid suffix "c" on integer constant
UART.c:61:11: error: invalid suffix "C0" on integer constant
UART.c:67:6: error: exponent has no digits
UART.c:67:11: error: invalid suffix "D9B" on integer constant
UART.c:68:11: error: invalid suffix "C0" on integer constant
UART.c:76:11: error: invalid suffix "CB9" on integer constant
UART.c:83:6: error: invalid digit "8" in octal constant
UART.c:84:6: error: invalid suffix "a" on integer constant
UART.c:84:11: error: invalid suffix "F4" on integer constant
UART.c:86:6: error: invalid suffix "c" on integer constant
UART.c:86:11: error: invalid digit "9" in octal constant
UART.c:98:6: error: exponent has no digits
UART.c:104:11: error: invalid suffix "D9B" on integer constant
UART.c:105:11: error: invalid suffix "C0" on integer constant
UART.c:107:11: error: invalid suffix "DE0" on integer constant
UART.c:108:6: error: invalid digit "8" in octal constant
UART.c:108:11: error: invalid suffix "CB9" on integer constant
UART.c:112:6: error: invalid suffix "a" on integer constant
UART.c:112:11: error: invalid digit "9" in octal constant
UART.c:119: error: stray '\' in program
UART.c:119: error: stray '\' in program
UART.c:119: error: stray '\' in program
UART.c:119: error: stray '\' in program
UART.c:119:56: error: invalid suffix "f" on integer constant
UART.c:120: error: stray '\' in program
UART.c:120: error: stray '\' in program
UART.c:120: error: stray '\' in program
UART.c:120: error: stray '\' in program
UART.c:120:56: error: exponent has no digits
UART.c:121: error: stray '\' in program
UART.c:121: error: stray '\' in program
UART.c:121: error: stray '\' in program
UART.c:121: error: stray '\' in program
UART.c:121:56: error: invalid suffix "d" on integer constant
UART.c:122: error: stray '\' in program
UART.c:122: error: stray '\' in program
UART.c:122: error: stray '\' in program
UART.c:122: error: stray '\' in program
UART.c:123: error: stray '\' in program
UART.c:123: error: stray '\' in program
UART.c:123: error: stray '\' in program
UART.c:123: error: stray '\' in program
UART.c:124: error: stray '\' in program
UART.c:124: error: stray '\' in program
UART.c:124: error: stray '\' in program
UART.c:124: error: stray '\' in program
UART.c:125: error: stray '\' in program
UART.c:125: error: stray '\' in program
UART.c:125: error: stray '\' in program
UART.c:125: error: stray '\' in program
UART.c:126: error: stray '\' in program
UART.c:126: error: stray '\' in program
UART.c:126: error: stray '\' in program
UART.c:126: error: stray '\' in program
UART.c:126:56: error: invalid suffix "a" on integer constant
UART.c:127: error: stray '\' in program
UART.c:127: error: stray '\' in program
UART.c:127: error: stray '\' in program
UART.c:127: error: stray '\' in program
UART.c:127:56: error: exponent has no digits
make.exe: *** [UART.o] Error 1

> Process Exit Code: 2
> Time Taken: 00:01


was könnte das sein ?
Autor: Andreas K. (a-k)
Datum: 23.07.2007 20:05

Un Anbetracht der Tatsache, dass uart.c nur 33 Zeilen hat, möchte ich
mal die These aufstellen, dass du dieses File mittlerweile durch etwas
anderes ersetzt hast.

Und die Fehlermeldungen in tempeas sind m.E. recht selbsterklärend.
Autor: Fabio (Gast)
Datum: 24.07.2007 14:01

Moin Moin,

so hat funktioniert! ich kann alles kompalieren. Ist aber irgendwie
komisch da ich mich nicht errinern kann in der Datei groß was geändert
zu haben aber naja egal.

Aber 1ne hab ich noch. Ich denke mal das die Funktionen Start_meas für
das starten der messung ist und Read_meas für das auslesen der
Temperatur. Ich will die Temperatur auf mein LCD anzeigen lassen und
frage mich nun in welcher Variablen der Wert drin steht! vieleicht kann
mir da ja nochmal jemand helfen. Ach und 1 wollte ich nochmal los
werden. VIELEN VIELEN DANK AN ALLE DIE SICH MEINE TEXTE DURCHLESEN UND
MIR SO WEITERHELFEN! mfg Fabio
Autor: Fabio (Gast)
Datum: 25.07.2007 21:39

hi Leute sagt mal in welcher Variablen ist der Temperatur wert
gespeichert ? mfg Fabio
Autor: Peter Dannegger (peda)
Datum: 26.07.2007 10:31

Fabio wrote:
> hi Leute sagt mal in welcher Variablen ist der Temperatur wert
> gespeichert ? mfg Fabio

Nirgends.

Er wird vom Sensor ausgelesen und per sprintf ausgegeben (erst in hex,
dann dezimal).


Peter
Autor: Fabio (Gast)
Datum: 26.07.2007 11:01

ok danke kannst du mir vieleicht die datei nennen und die zeile in der
das geschieht? vielen dank
Autor: Fabio (Gast)
Datum: 26.07.2007 20:48

moin leute,

also wenn ich das richtig sehe dann wird der temperaturwert mit

sprintf( s, "%4d.%01døC", temp >> 4, (temp << 12) / 6553 ); // 0.1øC;

dieser zeile in der Tempeas.c ausgelesen oder ?

Temperatur = sprintf( s, "%4d.%01døC", temp >> 4, (temp << 12) / 6553 );
// 0.1øC;

dann müste doch der Temperatur wert in der Variablen gespeichert werden
oder ?

danke
Autor: Fabio (Gast)
Datum: 28.07.2007 14:14

hey leute,

wie bekomme mann das hin das der Temparaturwert in eine Variable
geschrieben wird? bitte helft mir. mfg Fabio
Autor: Werner A. (homebrew)
Datum: 28.07.2007 21:52

hast du dir die syntax von sprintf schonmal angeschaut?

ansonsten, der wert steht schon in der variablen temp...
Autor: Fabio (Gast)
Datum: 29.07.2007 09:21

steht er da dezimal drin ? ich habe zu dem befehl irgendwie keine gute
referenz gefunden. nur für php aber ich denke mal das der da vieleicht
ein bischen anders ist. vielen dank fabio
Autor: Manuel B. (baeri3)
Datum: 09.08.2007 14:22

Hallo,

danke erstmal für die Lib. Allerdings bekomme ich hier an einem Mega8
auf dem STK500 (mit 3,86MHz Osz) immer "nur" ein Bus-Error.

Ich habe den DQ Pin mit PD6 und per 4,7KOhm mit +5V verbunden. Den VDD
und GND Pin habe ich auf GND gelegt.

Wenn ich z.B. den Sensor mit +5V auf VDD Speise dann bekommme ich keinen
Bus-Error, dann findet er gar keinen Sensor oder gibt "Short Circuit"
aus!

Was kann ich (noch) tun?
Autor: Sean (Gast)
Datum: 24.08.2007 17:36

Hi,
mich würde das auch mal interessieren in welcher Form der Wert in der
VAriable temp abgespeichert ist....
Autor: KAZERONI (Gast)
Datum: 31.08.2007 04:37
Angehängte Dateien:

SD1 IN
SD2 IN
SD3 GND
SD4 +3.3V
SD5 IN
SD6 GND
SD7 OUT
SD8 D1
SD9 D2
PKN (OFF)
START(ON)
Autor: Christian (Gast)
Datum: 09.09.2007 13:24

Hallo,
ich versuche gerade das Programm auf einen ATMEGA32 mit einem internen
Takt von 1 MHz laufen zu lassen.
Jedoch erhalte ich immer einen Bus Fehler...

Was ich nicht blicke ist, das wenn ich die CPU auf 8 MHz am kaufen habe
klappts. Wenn ich aber die Fuse Bitas auf 1 MHz unstelle und in der
main.h die Frequenz anpasse klappts es nicht mehr...

Der Buss Fehler resultiert aus einem Fehler bei der Verarbeitung der
Funktion w1_bit_io , ich vermute mal das es am Timing liegt, jedoch
steige ich da nicht so ganz durch ;-(

Kann mir hier vielleicht jemand helfen?

Gruss
Autor: Peter Dannegger (peda)
Datum: 09.09.2007 17:04

Christian wrote:

> Der Buss Fehler resultiert aus einem Fehler bei der Verarbeitung der
> Funktion w1_bit_io , ich vermute mal das es am Timing liegt, jedoch
> steige ich da nicht so ganz durch ;-(

Ja, kann sein, daß bei 1MHz das Timing zu knapp wird, d.h. die
Zykluszeit der CPU dominiert.

Warum willst Du nicht 4MHz oder 8MHz nehmen ?


Peter
Autor: Christian (Gast)
Datum: 04.10.2007 21:27

Es ging ums RS232, habe jetzt aber ein 8MHz Quarz genommen und dadurch
lief auch die RS232 stabil ;-)

Kann mir mal jemand erklären wie ich den Messwert ordentlich in ein Char
konvertiert bekomme? Ich möchte den via Funk übertragen und da habert es
noch am Format und ich bin icht gerade der Programmier Held ;-)
Autor: Basingstoke (Gast)
Datum: 10.10.2007 10:32

Also ich habe den "SEARCH ROM" mechanismus noch nicht richtig
verstanden. Nach dem "Flowchart 2" müsste ich beliebig viele Devices
finden können. Das will ich auch aber ich versteh den eine Stelle
einfach nicht! Und zwar handelt es sich um:
"Set search_direction bit to id_bit_number bit in ROM_NO"

ATmega8 6Mhz
DS18s20

link: http://www.maxim-ic.com/appnotes.cfm/appnote_number/187
Autor: Markus (Gast)
Datum: 20.10.2007 13:12

Ich habe da eine Frage zu der Globalen Variable Second...

Alle fünf Sekunden wird ja ein Messwert via UART übertragen. Ich würde
aber gerne nur alle 20 Sekunden durchführen. Dazu würde es doch genügen
in main.c folgenden Code einzufügen/zu ändern:
for(;;)
  {
  
          if( second == 3 )  
    {
      start_meas();
      second = 4;      
      
    }
    if( second == 6 )    
    {
      read_meas();
      //second = 0;
      
    }
    
    if ( second == 20)
    {
      second=0;
    }
  }
  

Leider klappt das nicht. Er wartet zwar, aber überträgt mir dann 32
Messwerte statt nur einen ??!!??

Woran kann das liegen? Bzw. ist meine Überlegung mit der Varibale so
richtig?

Viele Grüße
Autor: Markus (Gast)
Datum: 20.10.2007 13:37

Ich habe herrausgefunden das er in der zweiten ebene read_meas hängen
bleibt und diese mehrmals durchläuft -nur warum?-
Autor: Markus (Gast)
Datum: 20.10.2007 13:42

ok ;-) habs selbst gefunden...

Ich muss im Fall second=6 nach erfolgreicher Durchführung um eins
hochzählen ;-))
Autor: Andreas K. (a-k)
Datum: 04.11.2007 20:23

Kleine Korrektur an Peters Code: Am Ende der w1_bit_io Routine sollte
nach der Deaktivierung des Ausgangs eine Verzögerung von einigen µs
eingebaut werden.

Laut 1-Wire Doku reicht es zwar aus, wenn das Signal für 1µs high ist,
was sich bei langsamen Prozessoren von selbst ergibt, aber das kann je
nach Leitungslänge und sich daraus ergebender kapazitiver Last zu wenig
sein, weil der übliche Pullup-Widerstand die Leitung in der Zeit nicht
schnell genug hochgezogen bekommt. Vor allem wenn man es auch noch mit
einer schnellen CPU zu tun hat.

Also lieber 10µs dort einplanen, bei langen Leitungen darf es auch
deutlich mehr sein.
Autor: Andreas K. (a-k)
Datum: 04.11.2007 21:02

> Also lieber 10µs dort einplanen, bei langen Leitungen darf es auch
> deutlich mehr sein.

Naja, wenn mehr als 10µs nötig, dann scheitert das woanders, da muss der
Widerstand kleiner werden. Aber 10µs erscheinen mir schon sinnvoll.
Autor: VirmAnnem (Gast)
Datum: 22.03.2008 18:30

Hi
:)
G'night
Autor: SedOrdise (Gast)
Datum: 11.04.2008 10:21

Hello my friends :)
;)
Autor: Ricardo (Gast)
Datum: 16.04.2008 09:02

Hallo,


ein sehr Interessanter Thread, der aber leider einige gestellte Fragen
unbeantwortet lässt (ok bei manchen is das verständlich ;) ), aber
manche sind dabei die gerade mich momentan auch interessieren. So zum
Beispiel:


"Ich habe den DQ Pin mit PD'x' und per 4,7KOhm mit +5V verbunden.
Den VDD und GND Pin habe ich auf GND gelegt."

soweit ok... aber:

"Wenn ich z.B. den Sensor mit +5V auf VDD Speise dann bekommme ich
keinen
Bus-Error, dann findet er gar keinen Sensor oder gibt "Short Circuit"
aus!

Was kann ich (noch) tun?"

So auch meine Frage!

Vielen Dank im voraus!
Autor: Peter Dannegger (peda)
Datum: 16.04.2008 13:15

Ricardo wrote:

> Was kann ich (noch) tun?"

Nicht so zugeknöpft sein, das hier ist kein Hellseherzirkel.

Welcher Code, AVR, Takt, Schaltung?

Vielleicht VDD mit GND vertauscht (Datenblattansicht ist von unten!).


Peter
Autor: Ricardo (Gast)
Datum: 16.04.2008 19:55

Sorry, wenn das blöd rüber kam!

Die gestellte Frage war ein Zitat von "Manuel B." un interessierte mich
eben auch. Wurde aber eben leider nicht beantwortet damals.

Bei mir handelt es sich um einen ATmega8 mit 8MHz. Ich verwende im
moment den Code von Dir Peter zum Testen im AVR Studio mit GCC Compiler.
Mittlerweile hab ich nach langer suche doch noch einen ausschlaggebenden
Hinweis bekommen im Forum. Geholfen hat letztendlich der zusätzliche
Compilereintrag "-xc" um alles C-konform und nicht C++-konform zu
kompilieren. Jetzt funktioniert es auch. Vorher hatte ich einfach
versucht den Code so "hinzubiegen" in eines meiner Programme, was aber
fehl schlug. Btw vielen Dank für die Unterstützung in der 1-Wire
Angelegenheit!

Komm jetz erstmal klar soweit! .. bis zum nächsten Prob ;)
Autor: Manuel B. (baeri3)
Datum: 31.07.2008 17:30

Hallo zusammen,
ich muss (leider) nochmals auf meinen Post vom 09.08.2007 zurück kommen
nachdem das Projekt nun fast ein Jahr geschlafen hat. Ich bekomme
weiterhin einen "Bus Error". Verwendet habe ich den Original Quellcode
von Peter, compiliert mit AVR Studio.
Der BUS ERROR tritt auf, sobald ich den Pull-Up Widerstand vom PD6 auf
VCC anklemme. Evtl. kann der Sensor das Signal nicht gegen GND ziehen?
Evtl defekt?
Autor: Marco M. (marco1987)
Datum: 28.08.2008 09:42

@Peter Dannegger


ich wollte deine biblios für meinem Tempsensor nehmen, dazu hätte ich
ein paar Fragen.

Erstmal allgemein, kannst du mir sagen was das an Vorteile bringt ein
Programm in soviele unterprogramme, header und c files zu zerlegen?

Ich habe bisher immer nur im main programm und vllt mal 1,2 datein
eingebunden....

und nun zu meinem hauptproblem was binde ich denn bei dir wo ein, oder
einfach main file compilieren?
Zur info:
Takt: 16 Mhz
AVR Atmega16

Danke marco
Autor: Frank I. (icelase)
Datum: 03.09.2008 14:31

Hallo zusammen,

ich hab auch ein komisches Problem mit meinen DS18S20 Sensoren.

Nutze einen Atmega32 mit dem auf dem STK500 befindlichen Oszillator bei
3,68 MHZ  (UART Timing funktioniert)

Code natürlich angepasst:
#define F_CPU 3686400
#define XTAL 3686400

Habe Pin1 (GND) und Pin3 ( Vdd ) gebrückt und zusammen an GND
angeschlossen.
Pin2 geht an PC6 und via 4,7kOhm an VTG (+5V)


Code hab ich natürlich entsprechend angepasst:

#ifndef W1_PIN
#define W1_PIN  PC6
#define W1_IN  PINC
#define W1_OUT  PORTC
#define W1_DDR  DDRC
#endif


FEHLERBILD:

Wenn alles angeschlossen ist, bekomme ich ein "Bus Error".
Ziehe in den Sensor aus meinem Experimentierboard raus, bekomme ich ein
"No Sensor Found"

Entferne ich das kabel zum PC6  bekomme ich ein "Short Circuit. No
Sensor Found"


Habe auch schon den code von
http://www.siwawi.arubi.uni-kl.de/avr_projects/tem...
probiert.

Selbes Problem/Selbe Fehlermeldungen :-(

Weis einer was ich noch versuchen kann? Bin AVR Anfänger, also ist es
sicher irgend eine kleinigkeit.

Grüße,
Frank
Autor: Peter Dannegger (peda)
Datum: 03.09.2008 21:50

@Frank,

die 15µs könnten etwas zu lang sein:
DELAY( DELAY_US( 15 - 1 ));

Versuch mal statt der 15 Werte von 5..10.


Peter
Autor: Frank I. (icelase)
Datum: 03.09.2008 22:19

Hi Peter,
klappt leider nicht :(

verzweifel
Autor: Kurt.P (Gast)
Datum: 04.09.2008 00:24

Habe das Prg mit dem Pollin Board getestet.
Funktioniert mit DS18S20.
Sensor tauschen?
Gruß
Kurt
Autor: Frank I. (icelase)
Datum: 04.09.2008 13:42

Hi Kurt,

Sensor hab ich schon getauscht. Habe 3 Stück schon probiert... die
werden ja nicht alle kaputt sein oder?

Sind die normalen DS18S20 von Reichelt. (DS1820 steht drauf)

Was kann man sonst noch für anfängerfehler machen bzgl Timing?



Grüße,
Frank
Autor: Peter Dannegger (peda)
Datum: 04.09.2008 14:00

@Frank,

Schreib besser:

#define XTAL 3686400L


Versuch mal nen schnelleren Quarz, z.B. 11.0592MHz


Peter
Autor: Frank I. (icelase)
Datum: 05.09.2008 02:14

Hi Peter,

dank dir :-) das wars!

Hab jetzt erstmal den internen Oszi mit 8 MHZ am laufen... und es funzt
;)
Lag also an den 3,68mhz die wohl zu langsam waren ( komischerweise )

Naja jetzt läufts.

Danke nochmal!


Grüße,
Frank
Autor: Christian J. (elektroniker1968)
Datum: 06.09.2008 21:22
Angehängte Dateien:

Hier ist mein Code in C für PIC, kurz und leicht verständlich.
Autor: athobaben (Gast)
Datum: 09.12.2008 09:24
Angehängte Dateien:

Hallo Peter
Hallo Zusammen

ich verwende das Olimex P28 Board (siehe Datei) und das Program lässt
sich einwandfrei compilieren und rennt auf meinem ATMega8 mit 8Mhz.

Wenn kein Sensor angeschlossen ist, kommt die entsprechende Meldung.
Leider bekomme ich die Meldung "Buss Error", wenn ich einen anschliesse.
Es ist ein DS18S20 - sollte also Funktionieren.

Da ich ein Rookie in Sache MC bin, bin ich sicher, dass ich den
Wiederstand falsch angeschlossen habe.

Kannst Du mir bitte - gerne auch per Hand oder screenshot, PPT oder
sonstwie die Schaltung so ergänzen, dass ein DS18S20 an PC1 dran ist?
Ich möchte damit meinen Aufbau Zuhause kontrollieren.

Vielen Dank - und Asche auf mein Haupt...

Gruss,
Axel
Autor: Peter Dannegger (peda)
Datum: 09.12.2008 19:46

athobaben wrote:
> Kannst Du mir bitte - gerne auch per Hand oder screenshot, PPT oder
> sonstwie die Schaltung so ergänzen, dass ein DS18S20 an PC1 dran ist?

So, wie im Datenblatt, GND an 0V, VCC an 5V und den Datenpin an den IO.
und nen Pullup (2,2k) gegen 5V.


Peter
Autor: Axel Thobaben (athobaben)
Datum: 09.12.2008 23:35

Hallo Peter

mit GND des Sensors an 0V und DG mit 4,7k Pullup gegen den Datenpin
funktioniert meine Schaltung.

ID: 10 60 4F 4E 01 08 00 96   T: 0188 =   24.5?C

Ich habe auch kapiert, wie die Fuse mit dem Takt und der Baudrate
zusammenspielen.

Soweit so gut...

Leider habe ich noch 2 ungereimtheiten.

1) wenn ich VCC an 5V lege bekomme ich einen Bus-Error - da Du irgendwo
im Source etwas von Parasite Power schreibst, habe ich den Pin
weggelassen. Wenn meine Schaltung und das Mess-Objekt Mass-Kontakt haben
ist alles i.O und ich kann wunderbar messen. Ist das richtig?

2) Wenn ich nun 2 DS18S20 an den Anschluss klemme (GND1 und GND2 an OV
und DG1 mit DG2 an den selben Datenpin mit dem selben 4,7k Pullup) kommt
leider wieder ein Bus-Error.

Kannst Du mir den Neben lichten und mir ggf. den Thread nennen, in dem
Du das bestimmt schon zig mal erklärt hast? Es sind sehr viele und z.T.
sehr lange Threads... .

Ich würde gerne mehr als einen Sensor auswerten.

Danke für den Code und die bisher geleistete Hilfe.

Gruss,
Axel
Autor: Peter Dannegger (peda)
Datum: 10.12.2008 09:31

Der Bus-Error kann daran liegen,. daß die 15µs in "w1_bit_io" vielleicht
etwas zu lang sind. Schreib da mal 5 oder 10 rein.
Die älteren Sensoren hatten wohl ein langsameres Timing.


Peter
Autor: AThobaben (Gast)
Datum: 10.12.2008 23:16

Hallo Peter

ich habe
DELAY( DELAY_US( 15 - 1 ));

in "w1_bit_io" von 2 bis 15 in 1-Schritten durchgetestet. Leider immer
noch Buss-Error, wenn ich mehr als einen DS1820 dranhänge.

Weiter oben gibst Du den Rat einen schnelleren Quarz zu nehmen - ATMega8
und 8Mhz - sollten doch aber funktionieren wenn ich oben das so lese...
.

Für prasitäre Spannungsversorgung muss doch GND und VDD vom Sensor
zusammen auf 0V und der DQ mit 4,7k Pullup auf den IO Pin. Wenn ich das
machen komme ich immer Bus-Error, wenn ich VDD offen lasse geht es
wenigstens mit einem Sensor.

Idee?

Danke und GRuss,
Axel
Autor: Werner B. (werner-b)
Datum: 13.12.2008 15:37

Nur weil ich gerade (mal wieder) ein Bild gesehen habe auf dem ein User
den Vcc Pin bei Parasite Power offen gelassen hat (und sich wundert
warum sein DS18x20 nicht funktioniert).

Wer sich das Datenblatt durchliest erfährt: "Den soll man auf GND
legen!"
Autor: Peter Dannegger (peda)
Datum: 13.12.2008 15:51

AThobaben wrote:
> in "w1_bit_io" von 2 bis 15 in 1-Schritten durchgetestet. Leider immer
> noch Buss-Error, wenn ich mehr als einen DS1820 dranhänge.

Benutzt Du die Optimierung -Os ?

Stimmt denn Dein Takt wirklich mit der Definition von XTAL überein?

Hast Du noch andere Interupts im Programm?

Poste mal Dein komplettes Programm mit dem erzeugten Assemblerlisting.


Peter
Autor: Axel Thobaben (Gast)
Datum: 19.12.2008 15:57

Hallo Peter,
Hallo Werner

@Werner:
Das komische ist ja, wenn ich VCC auf GND lege - bekomme ich den
Bus-Error, wenn er offen bleibt funktioniert ein DS18S20 aber eben nur
einer.

@Peter:
Sorry das es länger gedauert hat. Kann Sein, dass die Optimierung
wirklich auf -Os steht. Ich setze die mal auf -O1 oder -O3 und teste
das.

Nein - meines Wissens habe ich keine anderen Dinge drin ausser die, die
Du in Deinem ersten Thread gaaaanz oben geposted hast.

Ich kann aber gerne ein ZIP posten mit allem, was drinnen ist...

XTAL steht auf 800000 (8Mhz) sollte das auf 800000L stehen?

Gruss und Danke,
Axel
Autor: Peter Dannegger (peda)
Datum: 19.12.2008 20:01

Axel Thobaben wrote:

> XTAL steht auf 800000 (8Mhz) sollte das auf 800000L stehen?

weder noch, 8MHz entspricht 8000000L.


Peter
Autor: fantomas (Gast)
Datum: 21.01.2009 17:12

Hallo Petter, mit schnelleren Takt funktioniert alles wunderbar aber
nicht mit 1 MHz. Gibts da neue Lösungen oder Ansätze?

thx

PS
benutze 18s20
Autor: Wolfgang Hopperdietzel (hastekene)
Datum: 04.03.2009 18:28

Hallo Peter,
ich hab mir mal deinen 1 wire Code heruntergeladen und hab jetzt
folgende Probleme mit AVR Studio 4:

AVR Studio melde mir folgende Fehler:
../main.h:11:16: error: io.h: No such file or directory
../main.h:12:23: error: interrupt.h: No such file or directory
../main.h:15:20: error: signal.h: No such file or directory

wenn ich jetz die dateien aus AVR lade mit

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

meckert AVR Studio

../TEMPMEAS.C:37: error: 'sprintf' was not declared in this scope
../TEMPMEAS.C:48: error:   initializing argument 1 of 'void
uputsnl(char*)'
usw.

kannst du mir sagen wo ich den Fehler suchen muss

By
Wolfgang
Autor: Daniel B. (dbuergin)
Datum: 04.03.2009 23:08
Angehängte Dateien:

Hallo Wolfgang

Lies mal den ganzen Thread durch.

Wenn ein C-Programm mit einem GROSSEN .C endet, bedeutet das für
aktuelle C-Compiler, dass dies ein C++ Programm ist. Du hast wohl den
Code von Peter genommen, und nicht alle Files auf Kleinbuchstaben
geändert. Aendere alle Filenamen auf Kleinbuchtstaben, und es sollte
gehen.

Hab das Ganze mal für den GCC 4.3.0 angepasst. Bei mir kommen so keine
Fehlermeldungen mehr. Ob es läuft weiss ich nicht, da ich keinen
ATmega8 habe und ich auch noch nicht weiss, ob der GCC 4.3.0, welcher
bei meinem aktuellen Ubuntu Linux 8.10 dabei ist, fehlerfrei ist.

Daniel
Autor: Wolfgang Hopperdietzel (hastekene)
Datum: 07.03.2009 14:01

Danke für den Tipp c ist halt leider nicht Pascal

By Wolfgang
Autor: Johannes (Gast)
Datum: 07.03.2009 14:58

Hi,

ich habe versucht die hier angegebenen Files zu verwenden. Und zwar für
einen ATmega16 im AVR-Studio mit avrgcc. Beim kompilieren bekomm ich
folgende Fehler:

../../../../../WinAVR-20080610/avr/include/TEMPMEAS.C:37: error: invalid
conversion from 'unsigned char*' to 'char*'
../../../../../WinAVR-20080610/avr/include/TEMPMEAS.C:37: error:
initializing argument 1 of 'int sprintf(char*, const char*, ...)'

Der dazu passende Code-Ausschnitt:

sprintf( s, "%02X ", id[i] );

Diese Fehler bekomm ich bei jeder sprintf().
Kenn mich selber aber nicht so gut aus. Kann mir jemand sagen wo das
Problem liegt und wie ich es beheben kann.

grüße Johannes
Autor: Peter Dannegger (peda)
Datum: 07.03.2009 17:17

Johannes wrote:

> ../../../../../WinAVR-20080610/avr/include/TEMPMEAS.C:37: error: invalid
> conversion from 'unsigned char*' to 'char*'

Kann ich mir nur so erklären, daß Du in Deinem Make nen Schalter hast:
wandle Warnings in Errors um.

Die AVR-GCC-ler haben so nen Spleen, daß es negative Buchstaben gibt,
daher müssen die vom Typ char sein, kein anderer 8-bit Typ wird
geduldet.
Ist ähnlich nervig, wie die überflüssigen Klammer-Warnings.


> sprintf( s, "%02X ", id[i] );

Mach nen cast
> sprintf( (char*)s, "%02X ", id[i] );


Peter
Autor: Johannes (Gast)
Datum: 08.03.2009 22:37

Danke Peter!

Funktioniert nun einwandfrei, vielen dank für die Hilfe.
Übrigens echt tolle software!
Autor: Feissy (Gast)
Datum: 30.04.2009 13:52

hallo, ich würde auch gerne die 1wire ds1820 auslesen, nur möchte ich
die temperaturen auf einem lcd angezeigt bekommen die routinwn für den
lcd sind mir bereits bekannt, nur ist mir nicjht wirklich klar, welche
funktion oder variable ich auf dem lcd ausgeben muss??
kann mir da jm helfen oder hat soetwas schon jm mal gemacht??
mfg
Autor: Daniel L. (grorkef)
Datum: 03.05.2009 19:58

Hallo,

Ich hätte da mal ne Frage. Wenn ich nun einen Systemtakt benutzte der
nicht durch 256 teilbar ist, dann wird ja nach jeweils 256 Overflows der
Rest aus der Divison von Systemtakt durch 256 zum Comparewert
hinzugefügt.

Nun stellt sich mir die Frage: Wird dann nicht jedesmal der Abstand zu
einer Sekunde größer, weil es ja dann von einer zu nächsten sekunde
immer länger dauert bis Prescaler 256 erreicht oder mach ich da einen
Denkfehler?

SIGNAL (SIG_OUTPUT_COMPARE1A)
{
  uchar tcnt1h = TCNT1H;

  OCR1A += XTAL / DEBOUNCE;    // new compare value

  if( ++prescaler == (uchar)DEBOUNCE ){
    prescaler = 0;
    second++;        // exact one second over
#if XTAL % DEBOUNCE      // handle remainder
    OCR1A += XTAL % DEBOUNCE;     // compare once per second
#endif
  }
  TCNT1H = tcnt1h;      // restore for delay() !
}

Ich hoffe es ist verständlich was ich meine.

MFG Daniel L.
Autor: Wen kiat teh Teh (Firma: HS Karlsruhe) (wenkiat84)
Datum: 07.06.2009 18:22

Kann jemand mir vielleicht helfen,ein funktionierende C-Code für
DS18S20,die auf Infineon XC164CM (mit Keil MicroVision3) zu
erzeugen?Oder ein paar Tipps und Links,wo ich die C-Code finden kann?

Gruss
Aaron
Autor: Proteus (Gast)
Datum: 08.07.2009 16:51

Moin,

versuche gerade dem Code auf nem atmega32 zum laufen zu bringen. Benutze
AVR Studio mit GCC Compiler... nachdem ich das "GROßSCHREIBEPROBLEM"
oben schon gefunden habe taucht bei mir was Neues auf:

H:\1 Wire\default/../Main.c:13: undefined reference to `init_timer'
H:\1 Wire\default/../Main.c:14: undefined reference to `uinit'
H:\1 Wire\default/../Main.c:16: undefined reference to `uputsnl'
H:\1 Wire\default/../Main.c:17: undefined reference to `second'
H:\1 Wire\default/../Main.c:20: undefined reference to `second'
H:\1 Wire\default/../Main.c:21: undefined reference to `start_meas'
H:\1 Wire\default/../Main.c:22: undefined reference to `second'
H:\1 Wire\default/../Main.c:24: undefined reference to `second'
H:\1 Wire\default/../Main.c:25: undefined reference to `read_meas'
H:\1 Wire\default/../Main.c:26: undefined reference to `second'

Verstehe nicht warum der die nicht kennt! z.B. wird `init_timer' doch
aus "timebase.h" in "main.h" includiert!
Kann mir mal jemand nen Tip geben was ich hier falsch mache?!?

Danke.
Autor: hastekene (Gast)
Datum: 08.07.2009 17:35
Angehängte Dateien:

Hallo Proteus,

ich kenne zwar deinen Code nicht bei mir funkts aber mit atmega 32
problemlos

sende dir mal meinen bisherigen code beinhaltet Temperaturauswertung
DS18B20
und noch etwas mehr
vielleicht hilft es dir

by
Wolfgang
Autor: Werner B. (werner-b)
Datum: 08.07.2009 22:17

Hast du evtl. ein Leerzeichenproblem?

> H:\1 Wire\default/../Main.c:26: undefined reference to ...
     ---
Autor: Proteus (Gast)
Datum: 09.07.2009 12:45

Wow, danke für die viele schnelle Hilfe!

@ Werner B. War ne gut Idee, hat abe auch nicht geholfen, werde trotzdem
in Zukunft mit sowas aufpassen!
@ Wolfgang Prima, dein Code läss sich Fehlerfrei bei mir compilieren!
Auch der 1wire Part! Damit komme ich auf jeden Fall schon mal weiter!

Gruss Proteus
Autor: Timo P. (latissimo)
Datum: 20.07.2009 12:11

Hallo!

Lt. anderem Beitrag konnte ich jetzt kompilieren. Soweit so gut.

einen Sensor habe ich bisher nicht angeschlossen. Hyperteminal zeigt mir
keinerlei (vom Mega32 gesendete Zeichen) Oszilloskop bestätigt, das der
tx-Pin schön auf high bleibt.


Sendet die SW nur, wenn ein Sensor vorhanden ist?
Oder wann genau wird was gesendet?

Danke im Voraus!
Autor: Karl heinz Buchegger (kbuchegg) (Moderator)
Datum: 20.07.2009 12:58

Timo P. schrieb:

> Sendet die SW nur, wenn ein Sensor vorhanden ist?
> Oder wann genau wird was gesendet?

Schau in den Code und analysiere ihn. So schwer ist das nicht.
Fremden Code einfach so zu übernehmen, ohne zu wissen was man da tut und
ohne ein gewisses Grundlagenwissen in der verwendeten Programmiersprache
zu haben funktioniert nun mal nicht.
Autor: Timo P. (latissimo)
Datum: 20.07.2009 13:28

habe es jetzt gesehen im code.
short circuit und no sensor found kommt beides
Autor: Timo P. (latissimo)
Datum: 20.07.2009 13:33

Den code anzupassen ist nicht das Ding! trotzdem ist es oft hilfreich,
einer zipdatei eine readme beizufügen, wo in ein paar sätzen kurz und
knapp der programmablauf beschrieben ist.

Dies spart zeit und macht den code( wenn er wie hier) für andere
offengelegt wird viel attraktiver.

Bitte nicht als negative Kritik aufnehmen. C-Code ist mir wohl ein
Begriff, also das Verständnis ist nicht das problem, auch wenn es vorhin
mit den includes vllt so schien.

z.B habe ich statt <headerfile> "headerfile" ausprobiert. soweit ich
weiß, sucht der compiler die headers via <> im compilerverzeichnis und
via "" im aktuellen source-verzeichnis.

anmerkung: ich finde es toll, das es Leute gibt, die hier ihren Code
veröffentlichen, und sich auch noch den Problemen der Leute annehmen.
Besten Dank für den Code an PEDA!
Autor: Timo P. (latissimo)
Datum: 22.07.2009 09:47

hallo!


Hat jemand einen sinnvollen tip in Bezug auf Eigenerwärmung? Bisher
betreibe ich einen DS18S20 mit externer Versorgung. Derzeit 5V.

1) Bald habe ich eine Schaltung, die mit 3v3 läuft.(müsste doch
eigentlich
   die Eeigenerwärmung reduzieren??)
2) Den Sensor werde ich dann in Zeitintervallen bestromen(vielmehr die
   SensorEN) sollte auch was bringen.

noch eine Frage:

3) Hat jemand eine Berechnung für negative Temperaturwerte realisiert?
Autor: Timo P. (latissimo)
Datum: 22.07.2009 10:40

im Datenblatt steht was von: Highbyte ist entweder 0xFF oder 0x00.

bei Highbyte = 0xFF hat man ne negative Zahl


die Werte für low und highbyte kombiniert sind bei mir aber

z.B 44 für +22.5°C anstatt:

mindestens 65280 also:  1111 1111 xxxx xxxx
temp =1_byte_rd();      // low byte
temp |= (uint)w1_byte_rd() << 8;  // high byte

sprintf(s,"Hier temp als dezimalzahl : %d \r\n", temp);  
uputs(s );
Autor: Wolfgang-G (Gast)
Datum: 22.07.2009 13:31

>Bald habe ich eine Schaltung, die mit 3v3 läuft.(müsste doch
>eigentlich die Eeigenerwärmung reduzieren??)
Bei +-0.5°C Fehlergrenze würde ich mir keine Gedanken darüber machen
MfG
Autor: R. B. (p1ng)
Datum: 28.07.2009 12:22

Hallo Leute,

ALso momentan basstel ich gerade mit 1-Wire rum und komme net wirklich
weiter.

Ich benutze das myAVR Workpad weil ich mit dem Studio nicht wirklich
klar komme. Irgendwie bekomme das Programm nicht richtig übersetzt, das
ich es sauber in das Workpad bekomme, hatt einer von euch damit schon
gearbeitet und weis rat. Bzw. Hatt das programm schon in dem Format. Ich
benutze die Aktuelle WinAVR. Es reicht mir ja schon das ich nur einen
Sensor auslesen kann.

Hardware: myAVR MKII Board --> ATmega8 --> 3,68400 MHz

Bitte um Hilfe
Danke
Autor: Timo P. (latissimo)
Datum: 07.09.2009 14:21

@p1ng:

Hast du deine Schaltung ans Laufen bekommen? Wenn ja, wie hast du
Timing-Probleme in den Griff bekommen? Bin der Meinung, dass der
gewählte Quarztakt zu niedrig ist wenn du Pedas SW nutzt.
Autor: hakan (Gast)
Datum: 25.12.2009 11:29

Hallo Peter,
erstmal, ein schönes neues Jahr 2010 wünsche ich Dir und schöne
Weihnachten.

Ich habe den Code  1Wire übersetzt und den Stk500 an den PC
angeschlossen.
Aber ich bekomme keine Ausgabe der Temperaturen über RS232.
Was mach ich falsch???
Ich habe Atmega8515 und DS1820.

Viele Grüsse
hakan
Autor: A. K. (prx)
Datum: 25.12.2009 11:37

Da der Code nachweislich funktioniert, jedenfalls bei nicht zu langem
Kabel oder bei längerem Kabel und langsam getaktetem Controller, kann es
nicht an Peters Code liegen.

Folglich hast du was falsch gemacht. Mehr lässt sich aufgrund der
überbordenden Detailfülle deines Beitrags kaum sagen.

Es könnte beispielsweise helfen, wenn du mitteilst wie du den
angeschlossen hast. Und wie die entsprechenden Anpassungen im Code bei
dir aussehen. Ganz ohne geht's ja nicht.
Autor: Harald C (Gast)
Datum: 25.12.2009 18:11

Hallo,
kann mir jemand erklären, wozu der Search Rom Algorithmus in der Praxis
gut sein soll ?
Man kann damit zwar die Rom-IDs aller Bausteine ermitteln, aber: wenn
ich z.B. 10 DS1820 im System habe, bekomme ich 10 IDs, weiß aber
trotzdem nicht, welche ID zu welchem Sensor gehört, kann also keine
sinnvolle Zuordnung des Sensors zu einem bestimmten Meßpunkt machen.

Vielen Dank

Harald
Autor: A. K. (prx)
Datum: 25.12.2009 18:27

Wenn man sie nacheinander dranhängt ist das überhaupt kein Problem. In
manchen Anwendungen kann man die Sensoren auch über den Wert
unterscheiden, d.h. man zeigt in der Systemkonfiguration alle gefundenen
Sensoren mitsamt Wert an und überlässt dem Anwender die Zuordnung zu
beispielsweise Aussen/Innen/Wassertemperatur.
Autor: Harald C (Gast)
Datum: 25.12.2009 18:56

Hallo A.K,
bei zwei, drei Sensoren ist das sicherlich kein Problem.
Was aber wenn man 10 und mehr Sensoren einsetzt, die in einer Anlage
Temperaturen messen, die im gleichen Bereich liegen z.B. 20 - 80 Grad
und dann immer nur um 10 - 20 Grad differieren ?
Dann kommst Du so aber nicht weiter.

Harald
Autor: A. K. (prx)
Datum: 25.12.2009 19:25

(1) Man die steckbar und schliesst sie nacheinander an.
(2) Man hat ein Prüfgerät, das vor Einbau der Sensoren die ID anzeigt.
Autor: Harald C (Gast)
Datum: 25.12.2009 19:57

So hatte ich mir das auch gedacht.
Ich war nur etwas verwundert über den doch recht "aufwendigen" ROM
search algorithmus und was der dann in der Praxis bringen sollte.

Vielen Dank und noch schöne Festtage

Harald
Autor: hakan (Gast)
Datum: 26.12.2009 17:06

Hi,
ich hatte vergessen den kompilierten Code in den Atmega8515 zu brennen.
Jetzt klappt es. Nur ich bekomme irgendwie falsche werte.

Habe schon mit verschiedenen Baudraten versucht.

Kann es daran liegen, dass ich DS1820 verwende und nicht den DS18B20?

Oder vielleicht die Schaltung nicht richtig? da ich GND und VCC des
PORTD
von Stk500 benutze.

Viele Grüsse viel spaaass
hakan
Autor: cloud (Gast)
Datum: 08.01.2010 19:05
Angehängte Dateien:

Hallo,

ich habe das Programm so geändert, dass es mir den Temperaturwert auf
einem LCD darstellt.
(Atmega8 auf Pollin Evu-Board, DS1820, 2x16 LCD. AVR-Studio 4.15,
WinAVR.)

Ich würde aber gerne 2 Temperaturwerte auf dem Display darstellen.

Schließe ich 2 Sensoren an den Bus an wird nur die ID und die Temperatur
eines Sensors angezeigt.

Meine Überlegeung bisher war folgende:
In der tempmeas.c geht der ja in die for-schleife und sucht die Sensoren
und gibt dann die ID und Temperatur nacheinander für beide Sensoren aus.
Beim UART bestimmt kein Problem aber für die Darstellung auf dem LCD
unbrauchbar.
Soll ich in der main.c 2 Messungen aufrufen? Wie ist es mir möglich
einen Sensor gezielt abzufragen? über die ID? Wahrscheinlich ist diese
Herangehensweise total falsch.


Habt ihr Ideen wie ich mein kleines Projekt am Besten umsetzen kann?

Anbei der Code im zip-file.
Autor: Josef D. (Gast)
Datum: 18.01.2010 15:43
Angehängte Dateien:

DS18x20 mit Namen versehen
Die DS1820 haben doch zwei Byte Ram, in die man selbst was reinschreiben
kann, z.B. einen Namen aus zwei Buchstaben; die ID braucht man dann gar
nicht zu kennen.
Ich habe die erforderlichen Änderungen in die Datei „TEMPMEAS.c“ aus
clouds Post vom 08.01.2010 eingepflegt, konnte aber nur bis zur
fehlerfreien Compilierung testen, da ich keine passende Hardware habe
(mein LCD ist mittels I2C angeschlossen).
Die ursprüngliche Version, die ich auch vor ca. zwei Jahren als
Ausgangspunkt genommen habe, stammt wohl von Peter Dannegger (vielen
Dank dafür; seine Programme waren mir schon an vielen Stellen eine große
Hilfe und eine gute Lehre). Meine aktuelle Version ist mittlerweile zu
sehr auf meine eigenen Bedürfnisse zugeschnitten und wäre so für viele
nicht brauchbar, so dass ich diesen Weg vorgezogen habe.
Die Ausgabe-Funktionen gehören eigentlich nach main.c, aber ich habe es
vorgezogen, nur eine Datei zu verändern. Wenn man es so lässt, müssen in
main.c die Zeilen, die für die LCD-Ausgabe zuständig sind, noch entfernt
werden.
Die Funktionsweise ist folgende (weiter Kommentare im Quelltext):
In einer Überschrift (die dann in meinem Projekt zusammen mit den
Messdaten über SD-Karte oder UART schließlich auf dem PC landen und mit
Excel weiter verarbeitet werden) stehen die Namen, die die Sensoren
erhalten sollen.
In der Lese-Funktion wird zusätzlich zu ID und Temperatur noch der
zwei-buchstabige Name ausgelesen. Dann wird geprüft, ob dieser Name in
der Überschrift existiert. Wenn ja, ist damit auch bekannt, an welche
Stelle im Array mit den Temperaturen der Wert eingetragen werden muss.
Zusätzlich wird in einem BitArray (valid) vermerkt, welcher Name schon
gefunden wurde.
Wenn der Name nicht in der Überschrift vorkommt, wird davon ausgegangen,
dass es sich um einen neuen Sensor handelt, dem noch kein Name
zugewiesen wurde. Diese Sonderbehandlung findet aber nur im zweiten
Durchgang statt (initReady==1). Dafür darf im ersten Durchgang
(initReady==0) am Ende valid nicht gelöscht werden, damit im zweiten
Durchgang noch bekannt ist, welche Namen schon erkannt wurden. Dann wird
der erste noch nicht erkannte Name aus der Überschrift in den Sensor
geschrieben.
Bei der Inbetriebnahme schließt man also die Sensoren in der Reihenfolge
einzeln an, wie sie in der Überschrift stehen, und schaltet jeweils
einmal kurz ein. Sollte einmal ein Sensor defekt sein, kann man ihn
einfach durch einen neuen ersetzen, einschalten und fertig.
Autor: strikeforce (Gast)
Datum: 11.02.2010 19:06

Hey  danke schonmal für das C.

Habe nur eine frage
Wie kann ich am einfachsten negative werte ausgeben ?

Mfg strikeforce
Autor: Michael S. (Gast)
Datum: 15.02.2010 10:53

Die Umwandlung der Temperaturen habe ich nach einigen umständlichen
Ansätzen wie folgt gelöst:

1. Das High-Byte mit 10 multiplizieren (als int16).
2. Aus dem Low-Byte die Nachkommastelle berechnen
   (als Wert zwischen 0 .. 9).
3. Diesen Wert zum (High-Byte * 10) addieren.
4. Nun hat man die mit 10 multiplizierte Temperatur incl.
Nachkommastelle.

Um ein Dezimaltrennzeichen einzubauen, kann man die Zahl in einen String
umwandeln, das letzte Zeichen um 1 nach rechts schieben, statt dessen
ein Komma einfügen (und dann ggf. wieder ein terminierendes 0 anhängen.

Die Nachkommastellen berechne ich so:

Das Low_Byte >> 4 um 4 Stellen nach rechts schieben
und mit 0.625 multiplizieren (das geht natürlich so nicht !!).

Statt dessen wird mit 625 multipliziert und durch 1000 dividiert.

Einfacher ist, mit 640 zu multiplizieren und durch 1024 zu dividieren.

Wenn man auch die Schiebeaktion mit in die Berechnung einbaut, dann kann
man alternativ rechnen:

(Low_Byte / 16) * (640 / 1024) = Low_Byte * 40 / 1024.

Im Moment haben wir ja die richtigen Temperaturen, um die
Funktionsfähigkeit dieser Berechnung im Bereich unter 0° zu prüfen.


Michael S.
Autor: Sebastian (Gast)
Datum: 18.02.2010 16:28

Hallo
Mal eine Anfängerfrage :
Da ich erst alles löten muss bevor ich loslegen kann mit dem LCD +
DS1820 fehlen mir noch die Pins für Uart, DS1820 und LCD. Welche Ports
werden benötigt? Ich werde das ganze mit einem ATMEGA8 bauen.

Grüße und Danke
Sebastian aus Stuttgart
Autor: Peter Dannegger (peda)
Datum: 18.02.2010 22:00

Die beiden Pins für die UART findest Du im Datenblatt.
Die Pins für LCD und 1-Wire können beliebige IO-Pins sein.


Peter
Autor: Sebastian (Gast)
Datum: 19.02.2010 08:29

Hallo Peter

Ja aber bezogen auf die CodeBeispiele von :

Autor:  Josef D. (Gast)
Autor:  cloud (Gast)

ich sehe das aus dem code nicht sofort raus wie ich es zusammenlöten
muss.
Ich wollte erst löten und dann den code fertig nehmen zum basteln.

grüße
Sebastian
Autor: Michael S. (Gast)
Datum: 21.02.2010 17:00
Angehängte Dateien:

Konvertierung (negativer) Temperaturwerte beim DS18B20

Zu diesem Thema hatte ich kürzlich eine Anmerkung gemacht.

In der Annahme, dass das Datenformat des DS18B20 und des DS1631 gleich
sind, zumindest sehen die Datenblätter zunächst wie Kopien aus.

Aber leider sind die Formate nur fast gleich.

Während beim DS1631 die 12 Datenbits linksbündig ausgerichtet sind,
stehen sie beim DS18B50 rechtsbündig.
Daher müssen die Nibbles beim DS18B50 anders geschoben werden als ich es
beschrieben habe.

Dazu ein Codeschnipsel als Anlage und Korrektur.

Michael S.
Autor: Timo S. (kaffeetas)
Datum: 25.02.2010 16:56
Angehängte Dateien:

Hallo zusammen,

ich habe die w1_byte_wr() Funktion um eine CRC Prüfung erweitert.

Auslesevorgang:
w1_crc auf 0 setzten.
scratchpad komplett auslesen.
wenn w1_crc gleich null ist dann war die CRC Prüfung erfolgreich.

Vielleicht kann es jemand brauchen.
Ich habe allerdings die Funktion nur mit dem Scratchpad vom DS18S20 und
ohne ROM SEARCH getestet.

Grüße
 Timo
Autor: Sebastian (Gast)
Datum: 26.02.2010 11:19
Angehängte Dateien:

Hallo  Josef D.

ich verwende deinen Code.
Bei mir tritt aber ein Anzeigefehler auf.
Ganze zahlen wie 23,24,25 Grad werden gut angezeigt.
Kommazahlen  wie 23,5 werden als 23.-5 angezeigt (siehe Foto)

Gibt es dafür eine Lösung ?

Grüße
Sebastian
Autor: Josef D. (jogedua)
Datum: 26.02.2010 17:21

Hallo Sebastian,
wenn ich mich recht erinnere, stammt der Code für die Ausgabe nicht von
mir, wohl aber die Bemerkung, dass der für negative Werte falsche
Ergebnisse liefert, mit einem Kommentar, wie man das korrigieren kann.
Aus deinem Beitrag geht nicht hervor, ob du meine vorgeschlagene
Änderung eingebaut hast.
Für eine Hilfe wären die paar Zeilen Code, die bei dir zu der Ausgabe
führen, schon sehr hilfreich.

Josef D.
Autor: Josef D. (jogedua)
Datum: 26.02.2010 18:49

Hallo Sebastian,
erst beim nochmaligen Lesen ist mir aufgefallen, dass es dir gar nicht
um negative Werte geht. Habe daraufhin noch mal den von mir geposteten
Code angesehen und festgestellt, dass doch wohl meine Änderung für den
Fehler verantwortlich ist, die ich nicht testen konnte, wie ich auch
angemerkt hatte.
Vermutliche Lösung (auch nicht getestet):
Es muss in der for-Schleife uint16_t temp statt int16_t temp
heißen, wenn man nur mit nicht-negativen Werte rechnen und den
unveränderten Code verwenden will (eine Variable uint temp wird weiter
ebenfalls benutzt, da hätte ich besser auch einen anderen Namen gewählt)

Sorry

Josef D.
Autor: Sebastian Albrecht (xxlxx)
Datum: 27.02.2010 02:15

Perfekt ! Danke !

jetzt sind Kommawerte kein Problem mehr.

für den Rest der Welt.
Diese Zeile (140) muss geändert werden :

    int16_t  temp=thermoValues[i];
in

    uint16_t temp=thermoValues[i];

Noch eine Frage :
was muss ich anstellen um mehr als einen Sensor zu lesen ?
Ein Sensor T1 wirft den Output aus wie auf dem Bild weiter oben.
Schalte ich einen weiteren Sensor dazu (Parallel) änders sich nichts.
T2 und T3 zeigen nichts an. Werden die ID´s für T1 fest im µProc
abgelegt?
Muss man T2 neu anlernen? Achso ich habe zwei sensoren die beide einzeln
als T1 laufen, nur zusammen eben nicht.

Sorry die Fragen aber ich mache Hardware + AVR + GCC erst seit 5 Tagen.
und bin schon recht weit ...

grüße
Sebastian
Autor: Sebastian Albrecht (xxlxx)
Datum: 27.02.2010 02:53

Problem selber gelöst und neue erkenntnis gewonnen :

- Der EEprom im Ds1820 bleibt dauerhaft geschrieben.
- Der erst Sensor heist T1 und legt das auch im Sensor so ab.
- Wenn man nun wieder einen Sensor anschließt wird er wieder T1 genannt
- Schließt man beide an hat man zwei T1 Sensoren und das geht nicht.

Also

- aus T1 bis T3 in dem Code zb. A1 bis A3 machen
- Sensor 1 an schließen und A1 einlernen
- Sensor 2 dazu anschließen --> sensor zwei bekommt A2 gelernt

jetzt gehts ...

Grüße Sebastian
Autor: Stefan M. (Gast)
Datum: 05.03.2010 20:24

Hallo

ih verwende die 1Wire.zip Routine. ich habe Sie erweitert damit man 0.1
Grad sprünge mit dem DS18S20 sieht. Leider verstehe ich die Routinen von
Peter nicht so genau. Gibt es zum Code von Peter eine Readme?  ich
möchte gerne die Read Messung so abwandeln das ich die sensoren einzeln
ansprechen kann?
Wo werden die ID´s gespeichert? wie kann ich sie einzeln abrufen? Fragen
über Fragen ... eine Readme währe hilfreich.

Thanks Stefan M. aus Eisenach
Autor: Christoph (Gast)
Datum: 09.03.2010 09:09

Hallo

kannst Du dein C Programm mal hier hochladen.

Ich kann jetzt eine Temperatur auf meinem Display (4bit) darstellen,
jedoch nur ein Sensor und keine negativen Temperaturen.

christoph
Autor: JOZO (Gast)
Datum: 09.03.2010 10:29
Angehängte Dateien:

Hallo,
Ich spreche nict Deutsch, please forgive me...

Can anybody help me with reading and store the device ID from 18b20 on
1-wire? I enclose my simple source code. I use the LCD 2x16 and one
18b20 succesfully. I would like improve :
1. The time of temperature reading (with only tvo decimal-pointed, not
four)
2. how to add the second temperature sensor 18b20. ?

In enclosed file there are full functional project for AVRstudio, photos
and schematics (schema.jpg).


I see, that you are good in this area.
THX a lot
JOZO

PS:
(main program:ATmegatest.c, sensor:therm_ds18b20.c and h., owi.c,h is
not used)
In main program for measure the temperature,i use only this:
char x[20] = {0};
therm_read_temperature(x);
lcd_puts("T= ");
lcd_puts(x);
Autor: Sebastian Albrecht (xxlxx)
Datum: 09.03.2010 17:15
Angehängte Dateien:

Messung der Luftfeuchte (psychometer) mittels DS1820

Also ich habe das jetzt so gemacht.

2x Ds1820 mit 0.1C auslösung (formel siehe datenblatt)
1x ATmega8
1x LCD 2x40
1x Modul mit lüfter + bewässerung (eigenbau)

Routinen von Peter mit nur kleinen Änderungen.

Messwete:
- Feuchte
- Taupunkt
- Temperatur

grüße
Sebastian
Autor: Xx Delaware (delaware)
Datum: 10.03.2010 11:47

Sebastian Albrecht schrieb:
> Problem selber gelöst und neue erkenntnis gewonnen :
>
> - Der EEprom im Ds1820 bleibt dauerhaft geschrieben.
> - Der erst Sensor heist T1 und legt das auch im Sensor so ab.
> - Wenn man nun wieder einen Sensor anschließt wird er wieder T1 genannt
> - Schließt man beide an hat man zwei T1 Sensoren und das geht nicht.
>
> Also
>
> - aus T1 bis T3 in dem Code zb. A1 bis A3 machen
> - Sensor 1 an schließen und A1 einlernen
> - Sensor 2 dazu anschließen --> sensor zwei bekommt A2 gelernt

Einen Sensor ran, erkennen lassen, zweiten ran und Prozessor resetten.
Wenn dieser erkannt ist, dritten Sensor ran und Prozessor resetten.

So ging es bei mit.

Christoph.


!!!!!!!!!!!!!!!!!!!!1
Wie kann ich denn die Routine abändern, damit negative Tempraturen und
Nachkomma korrekt dargestellt wird ?.

----------------------------------------
 sprintf( (char*)s, "%3d.%01dC", temp >> 4, (temp << 12) / 6553 ); //
0.1øC
      // Achtung: liefert bei negativen Temperaturen falsche Ergebnisse!
----------------------------------------




>
> jetzt gehts ...
>
> Grüße Sebastian
Autor: Sebastian Albrecht (xxlxx)
Datum: 11.03.2010 18:11

@Christoph Scheicht

Negative Werte habe ich nicht benötigt. Deshalb auch keine Idee.
Die Nachkommawerte sind mit der Formel aus dem Datenblatt recht einfach
zu errechnen.
TEMPERATURE = TEMP READ  -  0.25 +  COUNT PER C- COUNT REMAIN
                                    -------------------------
                                          COUNT PER C
Beispiel : 

TEMPERATURE = 25C  -  0.25    +     16 - 12    =  24,5C
                                    -------
                                       16


COUNT PER C und COUNT REMAIN werden aus dem Scratchpad ausgelesen.

grüße
Sebastian XXlXX
Autor: Alfred (Gast)
Datum: 11.03.2010 18:21

Hallo Sebastian,

wie misst du die Luftfeuchte mit dem DS1820?

Der Taupunkt errechnet sich doch aus Druck, Temperatur und Feuchte,
oder?

Lieg ich falsch?

Grüße,

Konstantin
Autor: Gerhard O. (gerhard_)
Datum: 12.03.2010 04:18

Autor: Sebastian (Gast)
Datum: 14.03.2010 11:50

Ja du hast recht der Druck wird benötigt. ABER : für diesen Wert nutzt
man einen Mittelwert. Das macht keinen großen Unterschied.

Ich habe das Gerät mal zum prüfen einem Wettermann mitgegeben. Mein
Gerät hat 2% Abweichung wenn ich es min 5 Minuten laufen lasse. Zur
bestimmung der Hausfeuchte (neubau) ist das jetzt so prima.

grüße
Sebastian
Autor: Sebastian (Gast)
Datum: 14.03.2010 12:01
Angehängte Dateien:

NACHTRAG

hier mal die Formel als Excel.
Ist dann einfach in C umzusezen.

Grüße
Sebastian
xxlxx
Autor: Gerhard O. (gerhard_)
Datum: 15.03.2010 14:27

Hallo Sebastian,

koenntest Du mir bitte den Titel und ISBN Nummer von Deinem PDF Dokument
bekannt geben.


Gruss,
Gerhard
Autor: Sebastian (Gast)
Datum: 15.03.2010 14:51

Gerhard O. schrieb:

> koenntest Du mir bitte den Titel und ISBN Nummer von Deinem PDF Dokument
> bekannt geben.

Leider habe ich PDF auch nur so von meinem Wettermann bekommen.

Sorry


grüße
Sebastian
Autor: Gerhard O. (gerhard_)
Datum: 15.03.2010 15:22

Vielen Dank, Sebastian !

Gruss,
Gerhard

Sebastian schrieb:
> Gerhard O. schrieb:
>
>> koenntest Du mir bitte den Titel und ISBN Nummer von Deinem PDF Dokument
>> bekannt geben.
>
> Leider habe ich PDF auch nur so von meinem Wettermann bekommen.
>
> Sorry
>
>
> grüße
> Sebastian
Autor: Sebastian (Gast)
Datum: 15.03.2010 16:27

Der Text (PDF) kommt von  :

http://openlibrary.org/b/OL4622634M/Aspirations-Ps...

Deutscher Wetterdienst


grüße
Sebastian

Antwort schreiben

Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate

Hinweis: der Originalbeitrag ist mehr als 6 Monate alt.
Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net