Guten Tag erstmal. Ich habe mich jetzt zwar länger mit diesem DS18B20 auseinandergesetzt und andere Forenbeiträge durchstöbert, bin aber noch zu keiner funktionierenden Lösung gelangt. Muss dazu sagen, das ich auf dem Gebiet ziemlicher Anfänger bin. In meinem Fall müsste ich "einfach" nur mit diesem 1 Wire temp. Sensor einen Vergleich mit einer bestimmten Temperatur erzielen um daraufhin in diesem Fall ein Relais anzusteuern. In meinem Projekt (die temperatur ist nur ein teil davon) existiert in dem Sinne nur der uC und Ausgänge bzw Eingänge und kein LCD oder ähnliches. Ich war nur bisher nicht in der Lage mir eine Temperatur auszulesen und diese zu vergleichen, deswegen hoffe ich hier auf Hilfe, wenn nicht sogar einen fertigen Code. PS: Von den Ansätzen her hab ich bisher einfach mal alle gefundenen fertigen Codes probiert, habe aber keinen zum Laufen bringen können. Mfg patch
Hallo, also um evtl. Hilfe zubekommen würde es helfen, wenn du ein paar mehr Informationen bereitstellst. D.h. in deinem Fall: µC, Programmiersprache evtl. auch die verwendeten Codes, Entwicklungsboard oder on fly Aufbau. Codes für diesen sensor gibt es haufenweise, leider kann ich dir keinen passenden empfehlen da ich ja nicht weis welchen µC du benutzt. MfG Richi
Kauf dir einfach ein Arduino Uno clon Lcd shield den ds1820 etwas googlemail und du bist fertig
Oh, sry da hab ich wohl was vergessen. Programmiersprache C Atmega16 ist der uC Das Board ist aktuell zum testen das avrispmkii was die codes angeht hab ich mich auf noch nichts festgelegt sondern nur mit verschiedenen gefundenen herumgetestet, bin da noch offen. Was genau ein on Fly aufbau sein soll, weiß ich nich 100% aber hier liegt nur das board mit einem steckbrettchen herum sowie verbindungskabeln :) Und es ist leider nicht ziel meines Projekts oder im Rahmen dieses, so etwas wie diese fertigbauteile zu benutzen, leider. mfg
Patch schrieb: > PS: Von den Ansätzen her hab ich bisher einfach mal alle gefundenen > fertigen Codes probiert, habe aber keinen zum Laufen bringen können. Was heisst du hast keinen zum laufen bringen können. DS18B20 Code gibt es doch wie Sand am Meer. AUch hier in der Codesammlung (die jetzt Projekte&Code heisst) gibt es genügend fertigen Code, der das auselesen übernimmt. > ... und kein LCD oder ähnliches. und das ist schon mal ein Fehler, den die meisten Anfänger begehen. Gerade weil man Anfänger ist, ist eine Möglichkeit für eine Ausgabe unumgänglich. Da ist eien simple LED zu wenig, bzw. es ist unendlich mühsam für einen Anfänger damit nach der Methode 'Rückschluss aus unvollständigen Informationen' auf Fehlerursachen bzw. weiteres Vorgehen in der Fehleranalyse zu schliessen. Wenn man das beherrscht ist man nämlich kein Anfänger mehr. Für alle anderen gilt: eine Ausgabe auf LCD bzw. UART kann in Gold aufgewogen werden. Vorausgesetzt natürlich, dass der Code prinzipiell schon kompipilert. Aber davon geh ich naiver Weise bis zum Beweis des Gegenteils sowieso immer aus.
:
Bearbeitet durch User
Da es mehr Codes mit LCD gibt als ohne, gehe ich ohnehin davon aus, das es mit einfacher wäre, problem bleibt nur, ich soll keines nutzen und habe auch keines zur hand.
Patch schrieb: > Das Board ist aktuell zum testen das avrispmkii Das macht man dann aber nicht mit einem Projekt, in dessen Zuge schon eine Menge Dinge schief gehen können, die nichts mit dem Brenner zu tun haben. Ganz im Gegenteil reicht es völlig aus, ein Programm in den µC brennen zu lassen, welches eine LED einschaltet, ausschaltet oder blinken lässt. Blinkt die LED, dann ist der Nachweis erbracht, dass der MKII das Programm übertragen konnte und der µC läuft. Und das dafür notwendige zu übertragende Programm ist so simpel, dass man davon ausgehen kann, das es auf Anhieb funktionieren wird, sofern nur die Hardware in Ordnung ist.
:
Bearbeitet durch User
Patch schrieb: > Da es mehr Codes mit LCD gibt als ohne, gehe ich ohnehin davon aus, das > es mit einfacher wäre, problem bleibt nur, ich soll keines nutzen und > habe auch keines zur hand. Räusper: Es ist nicht verboten, den LCD Code nach erfolgter Inbetriebnahme wieder aus dem Programm rauszunehmen. Es ist nicht in Stein gemeisselt, dass einmal im Programm vorhandener Code auch auf immer und ewig im Programm bleiben muss. Und wenn du keines hast, dann besorg dir eines. Alternativ kannst du natürlich auch deinen Mega16 mit LED an den Ports spicken und dir auf die Art Statusmeldungen bzw. Werte ausgeben lassen. Aber wie gesagt: das ist sehr sehr mühsam.
Also das Ausgangspost ist doch glasklar: Er kann nichts selber machen. Er kann keinen vorhandenen Code anpassen. Er kann seine Aufgabe schlicht NICHT umsetzen. Er sucht fertigen Code für seine Aufgabe. Kein Beispielcode der Welt würde ihm helfen. Davon gibt's ja auch genug. Ein typischer Fall von: "Ich will viel, kann nix.". Mal wieder.
Ich dachte da hauptsächlich an ne art IF abfrage des temp registers mit dessen hilfe ich etwas einschalte, hab das auch mit einem code aus dem 1 wire forenthread getestet, wobei sich da aber nichts getan hatte. Dieser war allerdings auch so umfangreich (sprich 4 oder 5 header und main dateien) das ich da nicht vollkommen durchgestiegen bin. Was die hardware von dem board angeht, die hab ich fertig gestellt bekommen, ist mehr oder minder ja ein schulprojekt, die läuft mit testprogrammen auf jedenfall.
Patch schrieb: > Ich dachte da hauptsächlich an ne art IF abfrage des temp registers mit > dessen hilfe ich etwas einschalte, hab das auch mit einem code aus dem 1 > wire forenthread getestet, wobei sich da aber nichts getan hatte. > Dieser war allerdings auch so umfangreich (sprich 4 oder 5 header und > main dateien) das ich da nicht vollkommen durchgestiegen bin. Wie wäre es wenn du vorher mal C programmieren lernen würdest?
:
Bearbeitet durch User
Ich hab halt vorher mit C nur in codeblocks und am rechner selbst gearbeitet. Ich kenne mich halt mit diesen externen bauteilen und dem uC nicht so recht aus.
Cyblord -. schrieb: > Also das Ausgangspost ist doch glasklar: Er kann nichts selber machen. :-) natürlich ist mir das genauso klar, wie dir. > Kein Beispielcode der Welt würde ihm helfen. Den braucht er auch nicht. Was er braucht, das ist fertiger COde, den er einfach auf den Mega16 brennt und der bereits läuft. Maximal noch 1 Zahlenwert anpassen und dann muss es auch schon fertig sein. Aber: das ganze klingt nicht nach "Ich würde brauchen", sondern nach "Ich habe als Aufgabe bekommen und werde dafür benotet". Und in dem Fall wende ich strengere Massstäbe an. Edit: Jup, wurde inzwischen auch bestätigt, dass es sich um eine Aufgabe handelt.
Eine Aufgabe ist es ja, aber eigtl. ist es eher ein selbstauferlegtes Projekt, deren Umfang auch größer ist und auch mechanik verlangt, da ist der temp sensor eher etwas kleineres. Dieser baustein ist im endeffekt auch nur deswegen im gespräch, da er billiger als ein PT100 (was ja kein problem wäre, auch für mich) ist und es alles über software steuerbar wäre.
OMG Dann erzähl doch einfach mal, welchen Code du nicht zum laufen bringst und woran es scheitert. Eines dürfte dir mittlerweile auch schon klar geworden sein: fix fertigen Code zum brennen spielt es nicht.
Habe mich bisher mit 2 Codes näher beschäftigt, einer davon compiliert erst gar nicht richtig ohne fehler und der andere ist eben etwas umfangreich. Dabei ist der 1wire.zip der der nicht läuft und 1wire_Mega16.zip durch den ich nicht durchsteige.
Patch schrieb: > Dieser baustein ist im endeffekt > auch nur deswegen im gespräch, da er billiger als ein PT100 (was ja kein > problem wäre, auch für mich) Wie kann ein analoger PT100 kein Problem sein, der viel einfacher abzufragende DS18B20 aber schon?
Das dürfte wohl daran liegen, das mich in der fachrichtung elektrotechnik wesentlichst besser auskenne als im programmieren :) Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil beklauen müsste durch externe beschaltung.
Na ja. Peters COde ist natürlich schon alt. Er stammt im Kern aus 2004 und einige Dinge werden heutzutage anders geschrieben. Zudem ist er so geschrieben, dass er mit beliebig vielen DS18B20 am Bus klar kommt. Aber so wild ist der in 1Wire.zip dann auch wieder nicht.
Patch schrieb: > Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil > beklauen müsste durch externe beschaltung. Ja nur klappt bei dir ja noch nicht mal das Code klauen. Tip: Programmieren besteht NICHT aus dem Copy&Paste von fertigem Code den man nicht versteht.
Cyblord -. schrieb: > Patch schrieb: >> Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil >> beklauen müsste durch externe beschaltung. > Ja nur klappt bei dir ja noch nicht mal das Code klauen. Tip: > Programmieren besteht NICHT aus dem Copy&Paste von fertigem Code den man > nicht versteht. Ich weiß, aber irgendwie muss ich mir behelfen, wenn ich nicht wochenlang an einem problem arbeiten möchte :/
Patch schrieb: > Cyblord -. schrieb: >> Patch schrieb: >>> Bzw. weil ich diesen ja notfalls einfach nur um seinen Code-Anteil >>> beklauen müsste durch externe beschaltung. >> Ja nur klappt bei dir ja noch nicht mal das Code klauen. Tip: >> Programmieren besteht NICHT aus dem Copy&Paste von fertigem Code den man >> nicht versteht. > > Ich weiß, aber irgendwie muss ich mir behelfen, wenn ich nicht > wochenlang an einem problem arbeiten möchte :/ Tja. Daran sollte man aber denken, BEVOR man sich um ein Projekt bewirbt. Egal. Peters Kernroutinen sind in 1WIRE.C/H bzw. TEMPREAD.C/H Der Rest ist nur Geplänkel um das Gemessene per UART auszugeben bzw. ein Timer der dafür sorgt, dass die Messung alle 2 Sekunden neu angestossen bzw. das Messergebnis abgefragt wird. 1_wire.zip solltest du eigentlich zum Laufen kriegen können und dann wird erst mal überprüft, ob sich überhaupt der Baustein am Bus meldet (zb. indem eine LED eingeschaltet wird, wenn dem so ist)
Schau ins Datenblatt vom DS18B20. Da ist beschrieben wie man den Sensor ausliest. Das musst du nur in C implementieren. Kein Problem, kostet nur bissl Zeit. Hat man keine Probleme mit zip entpacken oder fremden Code verstehen.
Patch schrieb: > Habe mich bisher mit 2 Codes näher beschäftigt, einer davon compiliert > erst gar nicht richtig ohne fehler und der andere ist eben etwas > umfangreich. habe mir beide angesehen, finde da nichts verdächtiges. Da du die Fehler ja nicht benennst wüsste ich nicht wie man da helfen soll. Ein Code schreibt auf die UART, wenn da nix die Zeichen abholt weisst du noch nicht mal ob der Code nicht funktioniert, vielleicht funktioniert er ja nur du siehst es nicht.
:
Bearbeitet durch User
rm -rf ProjektTemP.o 1WIRE.o DELAY.o MAIN.o TEMPMEAS.o TIMEBASE.o UART.o ProjektTemP.elf dep/* ProjektTemP.hex ProjektTemP.eep ProjektTemP.lss ProjektTemP.map Build succeeded with 0 Warnings... avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT 1WIRE.o -MF dep/1WIRE.o.d -c ../../../../Downloads/1wire/1WIRE.C cc1plus.exe: warning: command line option "-std=gnu99" is valid for C/ObjC but not for C++ In file included from ../../../../Downloads/1wire/1WIRE.C:9: ../../../../Downloads/1wire/main.h:11:16: error: io.h: No such file or directory ../../../../Downloads/1wire/main.h:12:23: error: interrupt.h: No such file or directory ../../../../Downloads/1wire/main.h:13:20: error: signal.h: No such file or directory ../../../../Downloads/1wire/1WIRE.C: In function 'unsigned char w1_reset()': ../../../../Downloads/1wire/1WIRE.C:24: error: 'PORTD' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:24: error: 'PD6' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:25: error: 'DDRD' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:27: error: 'cli' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:30: error: 'PIND' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:31: error: 'sei' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C: In function 'unsigned char w1_bit_io(unsigned char)': ../../../../Downloads/1wire/1WIRE.C:41: error: 'cli' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:42: error: 'DDRD' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:42: error: 'PD6' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:47: error: 'PIND' was not declared in this scope ../../../../Downloads/1wire/1WIRE.C:51: error: 'sei' was not declared in this scope make: *** [1WIRE.o] Error 1 Build failed with 14 errors and 1 warnings... Das sind die Fehler die mir beim nur reinkopiern von 1wire.zip kommen. Compiliert mit AVR Studio 4 übrigens
Patch schrieb: > rm -rf ProjektTemP.o 1WIRE.o DELAY.o MAIN.o TEMPMEAS.o TIMEBASE.o UART.o > ProjektTemP.elf dep/* ProjektTemP.hex ProjektTemP.eep ProjektTemP.lss > ProjektTemP.map > Build succeeded with 0 Warnings... > avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char > -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT 1WIRE.o -MF > dep/1WIRE.o.d -c ../../../../Downloads/1wire/1WIRE.C > cc1plus.exe: warning: command line option "-std=gnu99" is valid for > C/ObjC but not for C++ > In file included from ../../../../Downloads/1wire/1WIRE.C:9: > ../../../../Downloads/1wire/main.h:11:16: error: io.h: No such file or > directory Der Header io.h ist jetzt in avr/io.h, wie eigentlich jeder wissen sollte, der schon mindestens 1 mal ein AVR Programm geschrieben hat Also in main.h:
1 | #include <avr/io.h> |
>> dep/1WIRE.o.d -c ../../../../Downloads/1wire/1WIRE.C >> cc1plus.exe: warning: command line option "-std=gnu99" is valid for >> C/ObjC but not for C++ Der Dateiname ist schlecht. Eine Endung mit einem grossen C ist das Kennzeichen, dass es sich um C++ Code handelt. Datei umbenennen auf 1WIRE.c (kleines c). Denn das ist alles reiner C Code.
:
Bearbeitet durch User
Beides befolgt, noch immer 3 fehler: rm -rf 1WIRE.o DELAY.o MAIN.o TEMPMEAS.o TIMEBASE.o UART.o ProjektTemP.elf dep/* ProjektTemP.hex ProjektTemP.eep ProjektTemP.lss ProjektTemP.map Build succeeded with 0 Warnings... avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT 1WIRE.o -MF dep/1WIRE.o.d -c ../../../../Downloads/1wire/1WIRE.c In file included from ../../../../Downloads/1wire/1WIRE.c:9: ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory ../../../../Downloads/1wire/main.h:13:23: error: interrupt.h: No such file or directory ../../../../Downloads/1wire/main.h:14:20: error: signal.h: No such file or directory ../../../../Downloads/1wire/1WIRE.c: In function 'w1_reset': ../../../../Downloads/1wire/1WIRE.c:27: warning: implicit declaration of function 'cli' ../../../../Downloads/1wire/1WIRE.c:31: warning: implicit declaration of function 'sei' make: *** [1WIRE.o] Error 1 Build failed with 3 errors and 2 warnings...
ich nehm mal die nicht existenten libs einfach rauslöschen?
Patch schrieb: > Beides befolgt, noch immer 3 fehler: Und? Wie wäre es mal mit LESEN der Fehlermeldung? > In file included from ../../../../Downloads/1wire/1WIRE.c:9: > ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or > directory Nö. Du hast nichts befolgt. Immer noch gleiches File, gleicher Header, gleiches wird nicht gefunden > ../../../../Downloads/1wire/main.h:13:23: error: interrupt.h: No such > file or directory selber Typ > ../../../../Downloads/1wire/main.h:14:20: error: signal.h: No such file > or directory und noch einmal
Patch schrieb: > ich nehm mal die nicht existenten libs einfach rauslöschen? ne lernen, hab auch mal grad probiert <io.h> wird <avr/io.h> usw. für andere signal.h ist nicht mehr aktuell -> auskommentieren einige Warnungen sind nur weil evtl. cast fehlen uputsnl( "Bus Error" ); damit der compiler glücklich ist caste ich uputsnl( (char *)"No Sensor found" );
Karl H. schrieb:
Ich versteh nicht, was daran jetzt so schwer ist
Der Compiler schreibt hin, in welchem Source Code File das Prpoblem
existiert1 | ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory |
2 | ****** |
Er schreibt hin in welcher Zeile und innerhalb der Zeile in welcher Spalte
1 | ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory |
2 | ****** |
Er schreibt hin, welches andere File er gesucht hätte, weil es offenbar an dieser Stelle verwendet wird (was in 99% aller Fälle mit einem #include zu tun hat)
1 | ../../../../Downloads/1wire/main.h:12:16: error: io.h: No such file or directory |
2 | ****** |
Wo liegt also das Problem, ausser das man den kompletten Fehlertext lesen müsste?
Naja, jetzt spuckt er nur noch wegen dem interrupt.h rum, find aber nix dazu. gibt keine file in dem ordner oder im main.h wenn ich das rauskommentier kommen auch nur mehr fehler.
Patch schrieb: > Naja, jetzt spuckt er nur noch wegen dem interrupt.h rum, für interrupt.h gilt dasselbe wie für io.h Es wurde in ein Subverzeichnis namens "avr" verbannt, weil es nichts mit Standard-C zu tun hat, trotzdem aber als System-Header anzusehen ist.
:
Bearbeitet durch User
Karl H. schrieb: > Patch schrieb: >> Naja, jetzt spuckt er nur noch wegen dem interrupt.h rum, > > für interrupt.h gilt dasselbe wie für io.h > Es wurde in ein Subverzeichnis namens "avr" verbannt, weil es nichts mit > Standard-C zu tun hat, trotzdem aber als System-Header anzusehen ist. Im übrigen leicht erkennbar daran, dass Peter völlig korrekt in main.h
1 | ...
|
2 | #ifndef _main_h_
|
3 | #define _main_h_
|
4 | #include <io.h> |
5 | #include <interrupt.h> |
6 | ....
|
die Spitzklammern < > benutzt hat und nicht
1 | ...
|
2 | #ifndef _main_h_
|
3 | #define _main_h_
|
4 | #include "io.h" |
5 | #include "interrupt.h" |
6 | ...
|
geschrieben hat. Die Spitzklammern < > sind immer ein Indiz dafür, dass es sich in irgendeiner Form um einen System-Header handelt, der im eigentlichen Sinne nicht zum Projekt gehört und daher auch nicht auf dem Projektverzeichnis zu finden ist. Nur dass diese Header Files früher eben auf dem Haupt-System-Include Verzeichnis rumgelungert sind und im Laufe der Jahre (ebenfalls korrekterweise) in ein AVR spezifisches Subverzeichnis verschoben wurden. Daher ist die korrkte Schreibweise heute
1 | ...
|
2 | #ifndef _main_h_
|
3 | #define _main_h_
|
4 | #include <avr/io.h> |
5 | #include <avr/interrupt.h> |
6 | ...
|
:
Bearbeitet durch User
Kaufe dir einen Arduino Uno oder Nano (kannste so ins Steckbrett stecken) und mach das komplett mit Arduino. Auch die IDE, denn dann kannst du die Daten in einem zugehörigen Terminalfenster anzeigen lassen. Der Code ist fertig und läuft (selbst getestet).
Patch schrieb: > Du meinst, ich muss es mit avr/ erweitern? Du könntest einfach selbständig auf deiner Festplatte nachsehen, wo das Ding ist. Der Rest sind Grundkenntnisse zu deiner IDE.
Patch schrieb: > Naja, jetzt spuckt er nur noch wegen dem interrupt.h Frage steckt interrupt.h im ZIP File? wenn nein wird es wohl in der LIB sein und wenn wir die LIB Pfade um avr/ erweitern müssen, wie würdest du diese Frage beantworten? Patch schrieb: > Du meinst, ich muss es mit avr/ erweitern? Der Unterschied #include <mein.h> #include "mein.h" im Studio ist bekannt? (nur dem Arduino solls egal sein, warum auch immer)
Ok, so hatte ich das auch eingetragen, nur dass sich dadurch noch mehr fehler zeigen: Build started 2.11.2015 at 17:56:09 avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT MAIN.o -MF dep/MAIN.o.d -c ../../../../Downloads/1wire/MAIN.c avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT TEMPMEAS.o -MF dep/TEMPMEAS.o.d -c ../../../../Downloads/1wire/TEMPMEAS.c ../../../../Downloads/1wire/TEMPMEAS.c: In function 'read_meas': ../../../../Downloads/1wire/TEMPMEAS.c:37: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness ../../../../Downloads/1wire/TEMPMEAS.c:38: warning: pointer targets in passing argument 1 of 'uputs' differ in signedness ../../../../Downloads/1wire/TEMPMEAS.c:45: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness ../../../../Downloads/1wire/TEMPMEAS.c:46: warning: pointer targets in passing argument 1 of 'uputs' differ in signedness ../../../../Downloads/1wire/TEMPMEAS.c:47: warning: pointer targets in passing argument 1 of 'sprintf' differ in signedness ../../../../Downloads/1wire/TEMPMEAS.c:48: warning: pointer targets in passing argument 1 of 'uputsnl' differ in signedness avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT TIMEBASE.o -MF dep/TIMEBASE.o.d -c ../../../../Downloads/1wire/TIMEBASE.c ../../../../Downloads/1wire/TIMEBASE.c:19: warning: 'SIG_OUTPUT_COMPARE1A' appears to be a misspelled signal handler avr-gcc -mmcu=atmega16a -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT UART.o -MF dep/UART.o.d -c ../../../../Downloads/1wire/UART.c avr-gcc -mmcu=atmega16a -Wl,-Map=ProjektTemP.map 1WIRE.o DELAY.o MAIN.o TEMPMEAS.o TIMEBASE.o UART.o -o ProjektTemP.elf 1WIRE.o: In function `w1_bit_io': C:\Users\Dom\Documents\Projekt C\ProjektTemP\default/../../../../Downloads/1wire/1WIRE.c:41: undefined reference to `cli' C:\Users\Dom\Documents\Projekt C\ProjektTemP\default/../../../../Downloads/1wire/1WIRE.c:51: undefined reference to `sei' 1WIRE.o: In function `w1_reset': C:\Users\Dom\Documents\Projekt C\ProjektTemP\default/../../../../Downloads/1wire/1WIRE.c:27: undefined reference to `cli' C:\Users\Dom\Documents\Projekt C\ProjektTemP\default/../../../../Downloads/1wire/1WIRE.c:31: undefined reference to `sei' make: *** [ProjektTemP.elf] Error 1 Build failed with 4 errors and 7 warnings... In der main.h steht bei mir aktuell oben: #include <avr/io.h> #include <avr/interrupt.h> #ifndef main_h #define main_h //#include <io.h> //#include <avr/interrupt.h> //#include <signal.h> #include <stdlib.h> #include <stdio.h>
Patch schrieb: > Du meinst, ich muss es mit avr/ erweitern? Jetzt hast du Glück gehabt, dass ich meine Erklärung schon gschrieben hatte, ehe ich diese Frage gesehen habe.
Patch schrieb: > #define _main_h_ > //#include <io.h> > //#include <avr/interrupt.h> von auskommentieren war aber nicht die Rede
Karl H. schrieb: > von auskommentieren war aber nicht die Rede doch für <signal.h> aber logisch nicht für alles :-)
Joachim B. schrieb: > Karl H. schrieb: >> von auskommentieren war aber nicht die Rede > > doch für <signal.h> aber logisch nicht für alles :-) Wobei. Ist das immer noch so, dass bei signal.h eine Warnung kommt, dass das File mitlerweile obsolet ist und wegfallen kann? Wenn ja dann ... Ach was solls, er liest ja sowieso keine Fehlermeldungen.
Patch schrieb: > In der main.h steht bei mir aktuell oben: > > #include <avr/io.h> > #include <avr/interrupt.h> > #ifndef main_h > #define main_h > //#include <io.h> > //#include <avr/interrupt.h> > //#include <signal.h> > #include <stdlib.h> > #include <stdio.h> und warum machst du sowas? #ifndef bleibt immer vorne um Mehrfacheinbindungen zu verhindern #ifndef main_h #define main_h #include <avr/io.h> #include <avr/interrupt.h> //#include <avr/signal.h> ERSATZLOS gestrichen -> steckt nun in interrupt.h #include <stdlib.h> #include <stdio.h>
Karl H. schrieb: > Ist das immer noch so, dass bei signal.h eine Warnung kommt ja die kommt immer noch und erleichert das Leben
Muss es unbedingt C sein? Falls Du Dir das nicht antun musst, geh mit Bascom an die Sache. Das gibt es als Demoversion, die in der Lage ist 4KB große Quelltexte zu kompilieren. Es gibt dort auch eine Reihe von sog. Application Notes: http://www.mcselec.com/index.php?option=com_content&task=view&id=75&Itemid=57 Eines noch: Gehe nicht auf jeden Provokateur ein, das bremst Dich nur aus und bindet Kraft und Nerven.
Ja, leider muss ich mich auf reines C beschränken was den programmierteil angeht.
Patch schrieb: > Ja, leider muss ich mich auf reines C beschränken was den > programmierteil angeht. Das ist aber äußerst blöd, denn offensichtlich kannst du noch kein bisschen C, vom DS18B20 weißt du auch nichts und von uC's hast du wahrscheinlich auch keine Ahnung. Da wird es schon schwer..
Fang klein an: zuerst eine main.h mit leerer main-Funktion, dann eine LED anschalten dann die LED mit einem Timer blinken lassen dann ein Lcd anschließen und erst dann einen ds1820 anschließen jeden Schritt einzeln abarbeiten bis er funktioniert und erst dann den nächsten Schritt beginnen, dann klappt das auch.
Patch schrieb: > Ja, leider muss ich mich auf reines C beschränken was den > programmierteil angeht. Wer schreibt das vor? Der Lehrer, Meister, ...? Wenn's nur darum geht so ein Teil zu bauen: (wie oben schon mal geschrieben) Arduino nano (China:<3€, "DIL36", inclusive Bootloader per USB), Arduino IDE und 1wire-Lib, die garantiert mit Beispiel für DS18x20 kommt. Oder eben BASCOM. (auch wenn ich selber erschrecke. Hab ich das wirklich geschrieben?)
C-Compiler Meldungen sind nunmal ohne hinreichend Erfahrung schwer zu interpretieren. Bzw. aus dem Verständnis dann eine zielgerichtete Handlung abzuleiten. Schreib es selbst. Am Ende hast du genug Erfahrung um die fertige Lösung zu portieren und zu benutzen. Ein wechsel der Programmiersprache ersetzt keine Erfahrung sondern kostet erstmal nur Zeit. Die Stunden die du jetzt schon reingesteckt hast, sind bereits die ersten Stückchen gesammelte Erfahrung. Schätze sie wert und bau drauf auf. Eine erkannte Sackgasse richtet den Blick automatisch auf unbeschrittene Wege. Gehe sie, am Wegrand wirst du helfende Gefährten treffen, aber auch Trolle und andere Gestalten. Sie werden dich versuchen zu locken, mit Schlangenölen und -balsamen, die da STM32, PIC oder Bascom heißen. Notier sie dir. Das Schlangenöl von heute ist die Lösung von morgen. Aber die Lösung für heute liegt direkt vor dir.
Robin R. schrieb: > C-Compiler Meldungen sind nunmal ohne hinreichend Erfahrung schwer zu > interpretieren. Bzw. aus dem Verständnis dann eine zielgerichtete > Handlung abzuleiten. > Schreib es selbst. Am Ende hast du genug Erfahrung um die fertige Lösung > zu portieren und zu benutzen. > Ein wechsel der Programmiersprache ersetzt keine Erfahrung sondern > kostet erstmal nur Zeit. > Die Stunden die du jetzt schon reingesteckt hast, sind bereits die > ersten Stückchen gesammelte Erfahrung. Schätze sie wert und bau drauf > auf. Eine erkannte Sackgasse richtet den Blick automatisch auf > unbeschrittene Wege. Gehe sie, am Wegrand wirst du helfende Gefährten > treffen, aber auch Trolle und andere Gestalten. Sie werden dich > versuchen zu locken, mit Schlangenölen und -balsamen, die da STM32, > PIC oder Bascom heißen. Notier sie dir. Das Schlangenöl von heute ist > die Lösung von morgen. Aber die Lösung für heute liegt direkt vor dir. Amen!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.