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
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.
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.
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?
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.
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:
>> 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.
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...
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
existiert
1
../../../../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.
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
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)
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.
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.
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.
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 abschalten