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!
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.
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
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.
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
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.
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...
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
... 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
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?
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.
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
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?
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
1
i2c_start(DS1621_Read);
2
data=i2c_readAck();
3
TempH=data;
4
data=i2c_readNak();
5
TempL=data;
6
i2c_stop();
7
UDR=TempH;
8
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 ;-)
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*
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?
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
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
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.
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...
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.
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 ;-)
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.
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
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.