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 User
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?
Hab den Code nochmal umgeschrieben ( Anhang), was muss ich ändern, damit ich die i2c ausgänge von atmega8 benutze und nicht die von ATMEGA32?
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 ;-)
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
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*
wie kann ich den code optimieren lassen? habe zwar das: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_optflags gefunden, weiß aber nicht welche einstellungen ich im avr studio 4 machen muss...
http://images.google.de/images?q=avrstudio+optimize&hl=de&um=1&ie=UTF-8&sa=N&tab=wi => http://mexlewiki.hs-heilbronn.de/UserFiles/Image/software/Bild2.jpg
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?
gibt es vielleicht im code noch einstellungen vom atmega32 die ich auf atmega8 umstellen muss?
Habe das Programm mal analysiert, und herausgefunden, das es bei warte() steckenbleibt. Die Optimierung müßte doch -Os sein oder?
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.
krieg´s einfach nicht gebacken... )-: gibt es den niemand der schonmal die temp mit nen atmega8 ausgelesen hat???? danke für deine Mühe!
Angehängte Dateien:
-
IMG_0973.jpg
43 KB
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.
Danke für die Tipps! werd mich gleich ans löten machen.... mfg tillt
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.
Thread beobachten
Seitenaufteilung abschalten