Funktion auslagern

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

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

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.

Ok, erst Versuch zu langsam und falsch.

Zweiter Versuch:

Der Compiler kennt uint16_t nicht.


Gruß Mike

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 :-)

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.

1

#ifndef F_CPU

2

#define F_CPU 1600000

3

#endif

4

5

#include <avr/io.h>

6

#include <util/delay.h>

7

8

#include "meinADC.h"

9

#include "m50530.h"

10

11

12

....

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.

1

#define F_CPU 1600000

2

3

#include <avr/io.h>

4

#include <util/delay.h>

5

6

#include "meinADC.h"

7

#include "m50530.h"

8

9

10

....

Ich denke mal die Typen werden in der

1

#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.

Compilerfehler ?

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.

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.

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 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.

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!

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.

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.

1

uint8_t puffer[4];

2

3

  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 schrieb:
> Von hier aus geht es langsam
> weiter...

Super !!! Noch viel Erfolg und Spaß