Funktion auslagern

[Reinhard (Gast)]

Hallo,
zur Zeit blicke ich nicht mehr durch. Ich möchte die Funktion "meinADC" 
auslagern. (Wenn der Code in der main- Datei steht, funktioniert es).
Wie muss die korrekte .h- Datei aussehen? Habe bisher erfolglos 
Literatur durchgearbeitet. Evtl. kann jemand das Problem einfach lösen. 
Oder auch nur auf der offenen Wunde herumtrampeln (Suchfunktion, Google 
ist dein Freund, bisse blöd? usw.) Danke.
Gruß
Reinhard

[Peter II (Gast)]

könntest du erstmal sagen was nicht geht? Bekommst du eine 
Fehlermeldung?

[Michael R. (dj_motionx)]

Versuch mal die include Datei "meinADC.h" als letztes zu inkludieren.

[Reinhard (Gast)]

Hallo,
Danke für die Reaktion. Die Meldungen:
Build started 14.8.2012 at 11:34:46
./main.c

In file included from ../main.c:7:0:
../meinADC.h:9:11: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'Read_ADC'
../main.c: In function 'main':
../main.c:29:2: warning: implicit declaration of function 'Read_ADC'
../main.c:34:2: warning: implicit declaration of function 'sprintf'
../main.c:34:2: warning: incompatible implicit declaration of built-in 
function 'sprintf'
../main.c:34:2: warning: pointer targets in passing argument 1 of 
'sprintf' differ in signedness
../main.c:34:2: note: expected 'char *' but argument is of type 'uint8_t 
*'
../main.c:42:2: warning: pointer targets in passing argument 1 of 
'LCDWrite' differ in signedness
../m50530.h:118:13: note: expected 'const char *' but argument is of 
type 'uint8_t *'
make: *** [main.o] Fehler 1
Build failed with 1 errors and 5 warnings...
Gruß
Reinhard

[Mike R. (thesealion)]

Moin,

ich rate mal: Du hast die neue C-Datei nicht zum Projekt hinzugefügt.
Deshalb kann der Linker die Funktion nicht finden (da der Compiler sie 
nicht übersetzt hat :)

Ansonsten sind die h-Dateien etwas unübersichtlich, sehen auf den ersten 
Blick aber nicht falsch aus.

Mike

[Karl H. (kbuchegg)]

Ich vermisse sowohl in main.c als auch in MainADC.c den
#include <avr/io.h>


Ansonsten: halte dich an den ersten Fehler
(der bei dir dadurch ausgelöst wurde, dass der COmpiler mit uint16_t nix 
anfangen konnte)
und behebe den erst mal.

In deinem Fall wird er dadurch behoben, dass du den
#include <avr/io.h>
hinzufügst. Der zieht dann gleich einen ganzen Haufen anderer dinge 
rein, unter anderem auch die Definitionen für uint16_t und Konsorten.

Und zwar als ersten Include!

Halte dich an die einfache Regel:
Erst die Systemspezifischen Includes, dann deine eigenen.

[Mike R. (thesealion)]

Ok, erst Versuch zu langsam und falsch.

Zweiter Versuch:

Der Compiler kennt uint16_t nicht.


Gruß Mike

[Reinhard (Gast)]

Hallo,
Danke für die Reaktion. Die Meldungen:
Build started 14.8.2012 at 11:34:46
./main.c

In file included from ../main.c:7:0:
../meinADC.h:9:11: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'Read_ADC'
../main.c: In function 'main':
../main.c:29:2: warning: implicit declaration of function 'Read_ADC'
../main.c:34:2: warning: implicit declaration of function 'sprintf'
../main.c:34:2: warning: incompatible implicit declaration of built-in 
function 'sprintf'
../main.c:34:2: warning: pointer targets in passing argument 1 of 
'sprintf' differ in signedness
../main.c:34:2: note: expected 'char *' but argument is of type 'uint8_t 
*'
../main.c:42:2: warning: pointer targets in passing argument 1 of 
'LCDWrite' differ in signedness
../m50530.h:118:13: note: expected 'const char *' but argument is of 
type 'uint8_t *'
make: *** [main.o] Fehler 1
Build failed with 1 errors and 5 warnings...
Gruß
Reinhard

Mike S. schrieb:
> Du hast die neue C-Datei nicht zum Projekt hinzugefügt.
Hallo,
ist das nicht mit
#include "meinADC.h" in der main.c
geschehen?

[Michael R. (dj_motionx)]

Das war auch meine erste Vermutung. Irgendjemand muss aber die 
Definition von uint_16 inkludieren denn sonst würde es nicht 
funktionieren wenn Read_ADC ins mainfile kopiert wird.

Aber zuerst system dann user includes ist wie gesagt nie falsch :-)

[Phil (Gast)]

Reinhard schrieb:
> Hallo,
> ist das nicht mit
> #include "meinADC.h" in der main.c
> geschehen?

Nein, dies ist nur eine Header Datei. Du musst schon noch die C Datei 
hinzufügen.

In einem Makefile z.B. mit SRC += file.c

In Atmel Studio im Solution Explorer -> aktuelles Projekt -> rechtsklick 
-> add -> existing file

[Karl H. (kbuchegg)]

Karl Heinz Buchegger schrieb:

> Halte dich an die einfache Regel:
> Erst die Systemspezifischen Includes, dann deine eigenen.

Und die Definition für F_CPU ziehst du vor alles andere. Denn ein 
utils/delay benötigt dieses #define bereits. Definierst du F_CPU erst 
danach, dann hilft dir das nichts.

#ifndef F_CPU
#define F_CPU 1600000
#endif

#include <avr/io.h>
#include <util/delay.h>

#include "meinADC.h"
#include "m50530.h"


....

Ich geh eigentlich immer mehr davon ab, den F_CPU mit einem #ifndef zu 
sichern. Ist im Makefile eine enstprechende Definition, dann soll das 
ruhig einen Fehler ergeben. Ist mir immer noch lieber, als wenn 
stillschweigend die Definition aus dem Makefile genommen wird, die 
natürlich nicht mit dem hier angegebenen Zahlenwert übereinstimmt und 
ich dann für mich von falschen Zahlen ausgehe.

#define F_CPU 1600000

#include <avr/io.h>
#include <util/delay.h>

#include "meinADC.h"
#include "m50530.h"


....

[Reinhard (Gast)]

Hallo,
danke für die Antworten. #include <avr/io.h> vergessen (?!) Es geht.
Gruß
Reinhard

[Mike R. (thesealion)]

Ich denke mal die Typen werden in der

#include "m50530.h"

definiert sein. Deshalb funktioniert es in main, aber in der ADC nicht.

Das ADC ans ende der includes wird wahrscheinlich schon helfen, da dann 
die Reihenfolge auch stimmt. allerdings ist dann der nächste Fehler, das 
der Compiler die meinADC.c nicht übersetzen kann.

[Michael R. (dj_motionx)]

Compilerfehler ?

[Karl H. (kbuchegg)]

Michael Rathmair schrieb:
> Compilerfehler ?

Wenn ein Newbie ein Problem hat, kann man Compilerfehler zu 99.9% 
ausschliessen.
Es gibt zwar seltsame Compilerfehler und ja, auch der gcc hatte in der 
Vergangenheit ein paar, sagen wir mal Eigenheiten, die ich eigentlich 
nicht für möglich gehalten hätte, aber solche Dinge sprechen sich 
schnell rum und werden behoben. Meistens sind es irgendwelche Dinge in 
der Codegenerierung oder im Optimizer. Beim sprachabhängigen Teil, 
lexikalischem und syntaktischem Parsen ist die Wahrscheinlichkeit für 
einen unentdeckten Fehler, den ein Newbie findet, bei kleiner 0.000001%. 
Also praktisch 0.

Einen include, der nicht vorhanden ist, kann auch der tollste 
Compilerfehler nicht vertuschen.

[Michael R. (dj_motionx)]

Ich meine nicht dass der Compiler einen Fehler hat sondern was der 
Compiler noch meckert weil Mike S. noch geschrieben hat, dass er 
meinADC.c nicht übersetzten kann.

[Karl H. (kbuchegg)]

Michael Rathmair schrieb:
> Ich meine nicht dass der Compiler einen Fehler hat sondern was der
> Compiler noch meckert weil Mike S. noch geschrieben hat, dass er
> meinADC.c nicht übersetzten kann.

gleiches Problem. avr/io.h fehlt
Und der Rest sind Folgefehler.

[Reinhard (Gast)]

Hallo,
1. die meinADC.c hatte ich hinzugefügt
2. F_CPU ganz vorn, kommt zwr die Warnung, sicher kein Problem.
3. Es geht alles, jedoch sind noch einige Warnungen vorhanden (implicit 
deklaration... :

../main.c:7:0: warning: "F_CPU" redefined

<command-line>:0:0: note: this is the location of the previous 
definition
../main.c: In function 'main':
../main.c:32:2: warning: implicit declaration of function 'sprintf'
../main.c:32:2: warning: incompatible implicit declaration of built-in 
function 'sprintf'
../main.c:32:2: warning: pointer targets in passing argument 1 of 
'sprintf' differ in signedness
../main.c:32:2: note: expected 'char *' but argument is of type 'uint8_t 
*'
4. die Format Warnung finde ich sicher noch raus(siehe alter Beitrag)
Gruß
Reinhard

[Karl H. (kbuchegg)]

Reinhard schrieb:
> Hallo,
> 1. die meinADC.c hatte ich hinzugefügt
> 2. F_CPU ganz vorn, kommt zwr die Warnung, sicher kein Problem.
> 3. Es geht alles, jedoch sind noch einige Warnungen vorhanden (implicit
> deklaration... :
>
> ../main.c:7:0: warning: "F_CPU" redefined
>
> <command-line>:0:0: note: this is the location of the previous
> definition

sprich:
Es gibt im Makefile eine Definition für F_CPU

> ../main.c: In function 'main':
> ../main.c:32:2: warning: implicit declaration of function 'sprintf'

sprintf ist im Header stdio.h enthalten.

> ../main.c:32:2: warning: incompatible implicit declaration of built-in
> function 'sprintf'

selber Fehler

> ../main.c:32:2: warning: pointer targets in passing argument 1 of
> 'sprintf' differ in signedness

selber Fehler

> ../main.c:32:2: note: expected 'char *' but argument is of type 'uint8_t
> *'

Ist ein kleineres Problem, das sich mit einem Cast beheben lässt.


Du musst schön langsam lernen, welche Systemfunktionen in welchen Header 
Files 'beheimatet' sind und welche Header Files du daher includieren 
musst, wenn du eine Funktion benutzt. Wenn du es nicht auswendig weißt: 
nach der Funktion googeln. In den Funktionsdokus stehts normalerweise 
dabei.

[Rufus Τ. F. (rufus)]

Reinhard schrieb:
> ../main.c:7:0: warning: "F_CPU" redefined

Das bedeutet, daß "F_CPU" bereits definiert ist - vermutlich per 
Compilerkommandozeilenoption -DF_CPU=...

> ../main.c:32:2: warning: implicit declaration of function 'sprintf'

Das heißt, daß die Headerdatei, in der sprintf deklariert wird, nicht 
eingebunden wurde.

Lerne Compilerfehlermeldungen lesen!

[Rufus Τ. F. (rufus)]

Karl Heinz Buchegger schrieb:
> Du musst schön langsam lernen, welche Systemfunktionen in welchen Header
> Files 'beheimatet' sind. Wenn du es nicht auswendig weißt: nach der
> Funktion googeln.

Da braucht es kein Google, eine simple Textsuche in den Headerdateien im 
include-Verzeichnis des Compilers reicht aus.

[Karl H. (kbuchegg)]

Rufus Τ. Firefly schrieb:
> Karl Heinz Buchegger schrieb:
>> Du musst schön langsam lernen, welche Systemfunktionen in welchen Header
>> Files 'beheimatet' sind. Wenn du es nicht auswendig weißt: nach der
>> Funktion googeln.
>
> Da braucht es kein Google, eine simple Textsuche in den Headerdateien im
> include-Verzeichnis des Compilers reicht aus.

Geht natürlich auch. Viele Wege führen nach Rom.
Und mit der Zeit kennt man dann ohnehin seine Pappenheimer.

[Karl H. (kbuchegg)]

uint8_t puffer[4];

  sprintf(puffer,"%4d",value);

abgesehen davon, dass puffer hier besser als char definiert wäre (immer, 
wenn es sich um Textverarbeitung handelt, ist char der Datentyp der 
Wahl), hast du auch einen schönen Array-Overflow gebaut. %4d erzeugt 
einen String mit mindestens 5 Bytes Länge (aber einer minimalen strlen 
von 4). Du hast das abschliessende \0 Byte vergessen.

[Reinhard (Gast)]

Hallo,
vielen Dank für die Hilfestellung. Ich habe vor etwa 4 Jahren das letzte 
Mal
in C versucht, kleine Dinge zu programmieren. Sprich- (damals)durch 
Elektor infiziert aus Codestücken etwas mit CodeVision 
zusammenzuflicken. Aus Zeitgründen aber verworfen. Jetzt im Vorruhestand 
habe ich Zeit, mich wieder damit zu befassen. Manchmal sieht man die 
einfachsten Dinge nicht, wenn man stunden(Tage-)lang an dem gleichen 
Problem sitzt. Das Ganze dauert eben lange. Der Einstieg war eben, einen 
ADC- Wert auf einem Display anzuzeigen.  Von hier aus geht es langsam 
weiter...
Gruß
Reinhard

[Michael R. (dj_motionx)]

Reinhard schrieb:
> Von hier aus geht es langsam
> weiter...

Super !!! Noch viel Erfolg und Spaß