www.mikrocontroller.net

Forum: Compiler & IDEs Atmega8 - DS1621 auslesen ( über TWI[ i2c])


Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

versuche jetzt schon seit 2 Tagen ein DS1621 mit einem Atmega 8 über TWI 
auszulesen und dann die Temperatur durch die Anzahl des Blinken einer 
LED auszugeben.

Ich habe schon mindestens 10 verschiedene Projekte mit AVR-Studio 4 
(gcc) erstellt, aber es hat nie geklappt!

Das Problem liegt nicht an der Hardware, sondern daran, dass mein 
Projekt nie richtig kompiliert bzw. "make" nicht ausgeführt werden kann.

Nach zahlreichen "Google anfragen" und ausprobieren von 1000 
Beispielcodes( ...auf atmega8 umgeschrieben) bin ich jetzt nahe daran zu 
verzweifeln....

Habe mir auf dieser Seite die TWI Beschreibung durchgelesen, auch die 
i2c lib von peter fleury habe ich mehrmals versucht zu nutzen....

Bevor ich meine Tastatur jetzt ( vor hemmungsloser Wut) in mein Monitor 
ramme, dachte ich mir, dass mir vielleicht jemand hier ein 'einfaches' 
Beispielprogramm ( bzw. Projekt) zum Auslesen eines DS1621 mit einem 
Atmega8 über AVR-Studio 4 (gcc) posten kann...
Dies ist keine Anfrage, ob mir jemand ein Projekt erstellt... vielmehr 
ob irgendjemand schonmal mit den DS1621 Temperatursensor gearbeitet hat, 
und sein Code hier posten könnte....

mfg tillt


Pinbelegung des DS1621:

VDD  -> +5V
A0   -> GND
A1   -> GND
A2   -> GND
SDA  -> -( 4,7K)-( +5V)
       - PD4
SCL  -> -( 4,7K)-( +5V)
       - PD5
TOUT -> NC
GND  -> GND

PS: Bitte kein "Google Links zu Projekten", da ich diese bereits 
durchforstet habe!

: Gesperrt durch Moderator
Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was nutzt der fremde Beispielcode, wenn du deine Toolchain nicht im 
Griff hast?

Ich würde an deiner Stelle das eigenes Projekt zusammenpacken und in den 
Anhang stellen.

Vielleicht findet sich jemand, der versucht den Fehler in dem 
Projektaufbau zu knacken.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hy, danke für deine Antwort.

Ein Versuch war den ds1621 mit den Code von 
http://www.grilec.com/index-Dateien/Page684.htm
auszulesen...

Hab es aber nicht geschaft, den UART zu 'löschen' und mit den blinken 
der LED zu ersetzen... über Ansätze würde ich mich freuen!

mfg tillt

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich dachte das Problem sei:

> Das Problem liegt nicht an der Hardware, sondern daran, dass mein
> Projekt nie richtig kompiliert bzw. "make" nicht ausgeführt werden kann.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das stimmt auch, ich habe es nicht hingekriegt, das prog so 
umzuschreiben, das per LED die Temp. ausgegeben wird ( z.B. 23 Grad 
Celsius -> 23xBlinken)...

grüße tillt

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgenwie schreiben wir aneinander vorbei.

Schaffst du es das Originalprogramm auf deinem Rechner zu übersetzen 
(kompilieren)?

Wenn nein, dann s.o. zur Kontrolle des Projektaufbaus und deiner 
Toolchain. Und Wenn das Kompilieren des Originalprogramms (und/oder 
deiner Änderungen) beim make Fehler auswirft, dann bitte auch die Fehler 
mitprotokollieren und ebenfalls in einen Anhang oder Nachrichtentext 
posten.

Wenn das Kompilieren des Originals klappt: Welche Änderungen hast du 
gemacht (Anhang posten) so dass man nachsehen kann, was in deinen 
Änderungen noch fehlt oder was fehlerhaft ist.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier die Fehlermeldung:

Loaded plugin STK500
Loaded plugin AVR GCC
Loaded partfile: C:\Programme\Atmel\AVR 
Tools\PartDescriptionFiles\ATmega8.xml
gcc plug-in: Created and added C:\TempDS1621\main.c to the project
gcc plug-in: Output directory C:\TempDS1621\default\ does not exist
gcc plug-in: Created directory C:\TempDS1621\default\
gcc plug-in: Error: Object file not found on expected location 
C:\TempDS1621\default\TempDS1621.elf
gcc plug-in: Error: Object file not found on expected location 
C:\TempDS1621\default\TempDS1621.elf

Hab das Projekt genauso aufgebaut wie im Link...

Autor: tillt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...

Autor: Jörg X. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dein Projekt lässt sich doch problemlso compilieren, /sobald/:
- die .c-dateien eingbaut sind (Im AVR-GCC-Fenster rechtsklick auf 
"Source Files", "add existing source file"
- die .h dateien eingebaut sind, s.o. unter "Header Files"
- in "Project" -> "Configration Options" der Avr-typ und -takt 
eingetragen sind

rtfm, Jörg

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... i don´t know...

mit deinen Anhang klappt´s... mit meinem nicht???

naja wie auch immer DANKE!

PS: kannst du mir sagen, wie ich ich den CHAR Wert in INT umwandeln kann 
( für eine for() - Schleife, für die LED)

mfg tillt

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn ich im projekt-explorer die Datei twimaster.c nicht "add" dann 
klappt das kompilieren des Proj., wenn ich sie hinzufüge kommt die 
angezeigte Fehlermeldung...

muss ich sie den projekt hinzufügen, wenn sie in main included wird?

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab den Code nochmal umgeschrieben ( Anhang), was muss ich ändern, damit 
ich die i2c ausgänge von atmega8 benutze und nicht die von ATMEGA32?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tillt wrote:
> wenn ich im projekt-explorer die Datei twimaster.c nicht "add" dann
> klappt das kompilieren des Proj., wenn ich sie hinzufüge kommt die
> angezeigte Fehlermeldung...
>
> muss ich sie den projekt hinzufügen, wenn sie in main included wird?

Die Funktionen und Variablen aus twimaster.c dürfen nicht doppelt im 
Projekt sein.

Wenn doch, kotzt der Linker und wenn der Linker kotzt, wird kein 
Programm erzeugt und wenn kein Programm erzeugt wird, kann das 
gcc-plugin auch keins finden (gcc plug-in: Error: Object file not found 
on expected location C:\TempDS1621\default\TempDS1621.elf).

Die Fehlermeldung des Linkers steht eventuell auf einem anderen Fenster 
(Tabellenreiter Build?) in AVRStudio.

Wieso doppelt?

Doppelt einbinden machst du, wenn du einmal twimaster.c mit ADD ins 
Projekt nimmst und einmal mit #include...

Der richtige Weg ist, twimaster.c nur einmal ins Projekt zu nehmen, 
bevorzugt mit ADD. Das #include sollte man für *.h Dateien (Header) 
nehmen. Näheres zu Includefiles findest du übrigens hier in der 
Artikelsammlung.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, das hat jetzt schonmal geklappt (-:

weisst du, wie ich die Adress Angaben vom atmega32 in den vom atmega8 
umwandeln kann?

hab mal nen bißchen gegoogelt und auf

#define DS1621_Write  0xA0
#define DS1621_Read   0xA1

abgeändert.... die LED blinkt trotzdem nicht?

gruß tillt

Autor: tillt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal das abgeänderte Projekt

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Adressangaben meinst du?

> #define DS1621_Write  0xA0
> #define DS1621_Read   0xA1

Das hat nichts mit dem Atmega8 oder Atmega32 zu tun. Das sind Adressen 
für das per TWI angeschlossene IC. Je nach dem welche davon der AVR auf 
den TWI Bus legt, werden andere Funktionen ausgeführt. Welche Adressen 
bei dem DS1621 was machen, steht in dessen Datenblatt. Hast du das?

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du grundsätzlich schon mal eine blinkende LED geschafft, also temp 
mit beliebiger Zahl vorbesetzt und den I2C Kram mal nicht beachtet 
(auskommentiert oder Rückgabewert nicht benutzt)?

Ich frage aus zwei Gründen:

Der Code für LED an/aus ist ungewöhnlich. Du schaltest indem du DDR 
zwischen Ausgang/Eingang toggelst, während man das normalerweise fix auf 
Ausgang lässt und mit PORT den Pegel am Ausgang toggelt. Ich kenne 
deinen Schaltplan für den LED-Anschluss nicht - es kann so funktionieren 
oder auch nicht.

Wenn das Blinken der LED klappt - entspricht die Blinkrate deinen 
Erwartungen, d.h. stimmen die tatsächliche Taktrate des µC und die im 
Programm durch F_CPU vermutete Taktrate überein?

Im Programm werden ja Warteschleifen benutzt. Nur zur Sicherheit: Hast 
du daran gedacht, das Programm mit Optimierung zu übersetzen, so wie es 
die delay... funktionen brauchen?

In dem Teil

  i2c_start(DS1621_Read);
  data = i2c_readAck();
  TempH = data;
  data = i2c_readNak();
  TempL = data;
  i2c_stop();
  UDR = TempH;
  Temp= atoi( TempH);

sind definitiv 2 Bugs.

Die Zuweisung an UDR = TempH; ist wohlmöglich ein Rest der Übertragung 
per UART. Das muss raus.

Die Zuweisung Temp = atoi(TempH); ist auch nix. TempH ist kein String, 
so wie ihn die Funktion atoi() als Argument bräuchte. Ich denke die 
Zuweisung Temp = TempH; reicht. Jedenfalls solange du positive 
Temperaturen am Sensor hast ;-)

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Hilfe!
Bin echt froh, dass es hier so nette Leute gibt!

Werd es gleich mal ausprobieren,
...bin Anfänger (-; ...

mfg tillt

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tillt wrote:

> ...bin Anfänger (-; ...

Ich auch ;-)

Nicht wundern, wenn sich jetzt zwar was ändert, aber es nich nicht so 
funktioniert, wie du dir das vorstellst.

Im lögischen Programmablauf ist noch ein weiterer Bug. Derzeit machst du 
eine Messung und wiederholst in der endlosen while-schleife die Ausgabe 
des einmalig gemessene Wertes mit 2s Pausen.

Ich denke du willst was anderes machen: Messen und den Messwert 
ausgeben, eine kleine Pause (2s) und dann von vorne *mit der Messung 
starten*

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie kann ich den code optimieren lassen?

habe zwar das: 
http://www.nongnu.org/avr-libc/user-manual/FAQ.htm...
gefunden, weiß aber nicht welche einstellungen ich im avr studio 4 
machen muss...

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
optimierung habe ich.... os3 "schande über mich"...

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hy, habe versucht das projekt jetzt richtig einzurichten, die LED geht 
am anfang der main (wie vorgegeben) an, aber in der schleife tut sich 
nichts?

auch wenn ich einen festen wert und nicht temp nehme?

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
....

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es vielleicht im code noch einstellungen vom atmega32 die ich auf 
atmega8 umstellen muss?

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe das Programm mal analysiert, und herausgefunden, das es bei warte() 
steckenbleibt.
Die Optimierung müßte doch -Os sein oder?

Autor: tillt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
SORRY; hab vergessen die datei zu posten

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
tillt wrote:
> Habe das Programm mal analysiert, und herausgefunden, das es bei warte()
> steckenbleibt.
> Die Optimierung müßte doch -Os sein oder?

welche Optimierung ist egal. Hauptsache irgendeine und nicht keine 
(-O0).

Woher weisst du, dass der Hänger in warte() steckt?

Ich denke, der Hänger steckt eher in einer der Funktionen

i2c_start(DS1621_Write);
i2c_write(0xEE);
i2c_start(DS1621_Read);
i2c_readAck();
i2c_readNak();
i2c_stop();

Wo genau, kannst du herausfinden, wenn du das Programm mit Debugausgaben 
spickst.

Eine möglichkeit dazu mit den Rückgabewerten bestimmter Funktionen wäre 
im Anhang. Im Fehlerfall hält das Programm an und zeigt durch Blinken 
die Stelle, wo ein Fehler zurückgegeben wurde. Fehler in Funktionen ohne 
(Fehler-)Rückgabewert findet man so aber nicht

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, der fehler liegt in TempH = data;  ?

wo kann ich eigentlich die i2c pins definieren, wenn ich zusätzlich zu 
mein projekt die *.S - datei von pfleury hinzufüge und dort die pins 
definiere will er nicht mehr kompilieren:

Coordinator: None of the available object file readers can read the 
specified object file. Please check the format of the object file.
Error loading object file C:\Dokumente und 
Einstellungen\Administrator\Desktop\TempDS1621(2)\TempDS1621\default\Tem 
pDS1621.elf

...nehm ich sie wieder raus klappt das kompilieren?

wie muss ich die .s - datei einbinden; bzw. wo kann ich die Pins sonst 
definieren?

mfg tillt

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tillt wrote:

> danke, der fehler liegt in TempH = data;  ?

Definitiv nicht. Wieso kommst du da drauf?

Im Moment benutzt du den über I2C ausgelesenen Wert nicht, um das 
Blinken in der while Schleife zu steuern. Die LEDs sollten - wenn die 
I2C Kommunikation sich nicht aufhängt - 10x blinken.

Wenn sich die I2C Kommunikation aufhängt, und davon gehe ich aus, kommst 
du nicht bis zum 10x Blinken.

Mein Debugcode ist ein Versuch herauszufinden, ob die I2C Funktionen 
noch so weit leben, dass sie einen Fehler bei der Kommunikation melden 
können.

In deinem Code ohne diesen Check hättest du einfach trotz Fehler 
weitergemacht und ggf. den µC ganz ausgebremst. Jetzt wird bei einem 
Fehler nicht weitergemacht, sondern der Fehler wird angezeigt.

Das ist keine 100% Lösung. Wenn das nicht hilft, kann man jede einzelne 
Anweisung auf diese Weise verfolgen und nachsehen bis wo hin der AVR 
kommt.

> wo kann ich eigentlich die i2c pins definieren,

Kannst du nicht. Die sind am AVR fest vorgegeben, nämlich dort wo die 
TWI Schnittstelle herausgeführt ist (Pins mit SCL und SDA Bezeichnung).

Das wirft eine andere Frage auf: Wie sieht deine Schaltung aus?

Du brauchst Pullups an den SDA und SCL Leitungen sowie Pullups an den 
Pins 5,6 und 7 des DS1621 (damit bei dem die Adressen 9E und 9F passen)

> wenn ich zusätzlich zu
> mein projekt die *.S - datei von pfleury hinzufüge

Mach das nicht. Die Dateien aus deinem Archiv sind vollkommen 
ausreichend. Ein weiteres *.S von pfleury braucht du nicht.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann werden die PINS automatisch definiert?

Pullup Widerstände habe ich an sda u. scl dran ( siehe oben)...
Hab das Projekt nochmal analysiert und es hängt sich definiv in der 
Zeile TempH = data; auf.
Habe vor und nach der Zeile ein LED-blinken reingebaut, vor der Zeile 
blinkt die LED, nach der Zeile blinkt sie nicht... daraus schließe ich, 
dass das programm an der Stelle einen Hänger hat?

...danke für deine Geduld...

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Durch die Optimierung kann es sein, dass die Zeile aus dem C-Code so 
nicht im Maschinencode erscheint. Der Compiler kann (wird!) bei der 
Optimierung merken, dass data nur eine Hilfsvariable ist und er kann die 
eliminieren.

Du könntest in den Projektoptionen von AVRStudio anstellen, dass eine 
*.LSS Datei erzeugt wird. Das ist gemischter C und Assemblercode. Darin 
kann man nachsehen, was konkret beim Übersetzen erzeugt wird.

Nach deiner Beschreibung könnte der Hänger in den Funktionen 
i2c_readAck() oder i2c_readNak() stecken. Fürs weitere Nachschlagen bei 
der Fehlersuche hänge ich mal das twimaster.c (Original) an.

ADD: Bin gleich weg und weiss nicht, ob ich heute abend noch mal 
reinschauen kann.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
krieg´s einfach nicht gebacken... )-:

gibt es den niemand der schonmal die temp mit nen atmega8 ausgelesen 
hat????

danke für deine Mühe!

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
An dem C-Code hängt es wohl nicht.

Ich habe mir einen DS1621 in 8-Pin DIP Version beschafft und die 
wichtigen Abschnitte aus obigen C-Code in eines meiner Programme fürs 
Pollin Funk-AVR-Evaluationsboard eingebaut.

Das PFA habe ich genommen, weil ich da schon einen fertigen 
7-Segment-Display Treiber geschrieben habe und ich so den Wert gleich 
anzeigen lassen kann. Das PFA läuft auch mit einem ATmega8 und bei 12 
MHz.

Die 4 Leitungen (Vcc, GND, SDA und SCL) zwischen PFA und DS16212 waren 
ca. 3-4m lang. Ich hatte 2 RS232 Kabel zusammengestöpselt und bin dann 
mit Drähten auf die Buchsen und auf ein Breadboard gegangen. Als 
Pullups für SDA und SCL habe ich je einen 2K2 Widerstand benutzt. Die 
Adresspins hatte ich alle auf GND gelegt (=> Basisadresse 0x90). Die 
Geschwindigkeit des Busses war auf 100 kHz eingestellt (keine Änderung 
in Peter Fleurys Lib.).

Ich kann mir nur vorstellen, dass dein Projekt ein Hardwareproblem hat. 
Also noch mal die Schaltung kontrollieren und ggf. Fotos oder 
Zeichnungen machen und hier zeigen. Oder den DS1621 tauschen.

PS: Die nächste Anschaffung ist Kältespray. Ich denke, beim Testen ist 
das ganz nützlich. Die tiefgekühlte Butter auflegen ist nur eine 
Notlösung ;-)

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Hardware...

Im allerersten Posting schreibst du:

> VDD  -> +5V
> A0   -> GND
> A1   -> GND
> A2   -> GND
> SDA  -> -( 4,7K)-( +5V)
>        - PD4
> SCL  -> -( 4,7K)-( +5V)
>        - PD5
> TOUT -> NC
> GND  -> GND

Da sind zwei Haken drin:

1/ Mit A0, A1 und A2 auf GND ist die Basisadresse 0x90. Darauf wird dann 
I2C_READ (1) oder I2C_WRITE (0) aus der Library aufaddiert.

In deinem Code ist eine andere Definition, nämlich

#define DS1621_Write  0x9E
#define DS1621_Read   0x9F

Das wäre OK, wenn A0, A1 und A2 auf Vcc hängen. Bei A0, A1 und A2 auf 
GND ist dort anzugeben:

#define DS1621_Write  0x90
#define DS1621_Read   0x91

2/ Die TWI Pins SDA und SCL sind beim ATmega8 an PORTC und nicht an 
PORTD. Es sind dort die Pins PC4 und PC5.

Beide Fehler führen dazu, dass sich der DS1621 nie angesprochen fühlt 
und dass dadurch die I2C Routinen endlos warten.

Autor: tillt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Tipps!

werd mich gleich ans löten machen....

mfg tillt

Autor: Elektroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf Assembler eine Sekunde verzögerung finde ich nicht besonders schlau, 
verschwendest viel zeit... ungenau ist die Verzögerung dadurch auch. 
Hast du schon mal das gleiche Projekt in C geschrieben?

lg

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Elektroniker schrieb:
> Auf Assembler eine Sekunde verzögerung finde ich nicht besonders schlau,
> verschwendest viel zeit... ungenau ist die Verzögerung dadurch auch.
> Hast du schon mal das gleiche Projekt in C geschrieben?


Ich denke, nach 7 Jahren ist die Frage wirklich obsolet.
Wenn er es bis jetzt nicht hingekriegt hat, dann wird das auch nichts 
mehr.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.