Hallo,
ich bin am verzweifeln und hoffe ihr könnt mir weiterhelfen..
Ich versuche den Example-Code für den Bosch BMA180 Beschleunigungssensor
auf einem Atmega zum laufen zu bekommen.
Example-Code: http://www.sparkfun.com/products/9723
Im Moment versuche ich es mit einem Atmega8. Ich habe den Quellcode
bereits an den Atmega8 angepasst, bekomme jetzt aber folgenden Fehler:
expected primary-expression before '.' token
Müsste soviel heißen, wie: es wird ein Anfangsausdruck vor dem '.'
Zeichen erwartet.
Der Fehler erscheint 4x hintereinander.
Die betreffende Zeile ist folgende:
Die Stdio.h wurde eingebunden. In dieser Header-Datei habe ich folgendes
gefunden:
1
#if defined(__DOXYGEN__)
2
/**
3
\brief Initializer for a user-supplied stdio stream
4
This macro acts similar to fdev_setup_stream(), but it is to be
5
used as the initializer of a variable of type FILE.
6
The remaining arguments are to be used as explained in
7
fdev_setup_stream().
8
*/
9
#define FDEV_SETUP_STREAM(put,get,rwflag)
10
#else /*!DOXYGEN*/
11
#define FDEV_SETUP_STREAM(p,g,f) \
12
{
13
.put=p, \
14
.get=g, \
15
.flags=f, \
16
.udata=0, \
17
}
18
#endif /*DOXYGEN*/
Kann es sein, das die Stdio.h fehlerhaft ist, oder das der Fehler an
ganz anderer Stelle in meinem Programm liegt?
Die Fehler scheinen sich ja auf den #else-Teil zu beziehen (.put , .get
, .flags , .udata).
Gegen halb sechs werde ich mal den kompletten Code meines Programms
schicken.
Hattet ihr dieses Problem schon einmal? Könnt ihr mir weiterhelfen?
Vielen Dank schon einmal!
MfG Martin
Martin schrieb:> Kann es sein, das die Stdio.h fehlerhaft ist, oder das der Fehler an> ganz anderer Stelle in meinem Programm liegt?
Beidesmal ja, aber mit 99% Wahrscheinlichkeit auf dem 2. ja.
Der gezeigte Auszug aus der stdio.h ist richtig, und wenn du darin
weiter oben nachschaust, findest du dort sogar ein komplettes
Codebeispiel. Wenn das fehlerfrei compiliert, ist deine stdio.h in
Ordnung.
Dann
@Oliver: Vielen Dank schon mal für deine Antwort!! :-)
Ich habe das Beispiel in der Stdio.h gesehen, bin mir aber eigentlich
ziemlich sicher das der Code übereinstimmt. Aber vielleicht hab ich ja
noch was übersehen.
Ich habe im Anhang den Programmcode als SisyAVR-Projektdatei und als PDF
bzw. Rtf-Datei in Textform.
Die Stdio.h, die ich verwende habe ich sicherheitshalber auch mal mit
angehangen.
Es wäre klasse, wenn ihr mal drüber schauen könntet, wo sich der Fehler
eingeschlichen hat, danke schon mal im Vorraus.
MfG Martin
Was wird denn "vor" der <stdio.h> includiert?
bzw. was steht davor?
upps. Gerade gesehen.
Das ist C++. Da gibt es iirc einiges zu beachten. Nur was? Da mache ich
mit C++ zu wenig auf dem AVR bzw. mit GCC.
Martin schrieb:> Kann es sein, das die Stdio.h fehlerhaft ist, oder das der Fehler an> ganz anderer Stelle in meinem Programm liegt?
Wie man's nimmt. Das hier:
> #define FDEV_SETUP_STREAM(p,g,f) \> {> .put=p, \> .get=g, \> .flags=f, \> .udata=0, \> }
setzt einen C99-Compiler voraus. C++ kennt diese Form der
Initialisierung nicht. Du kannst dieses Makro so also nicht mit C++
verwenden.
@Rolf: Danke vielmals!!!
Mir ist es gleich komisch vorgekommen, dass mein Entwicklungsprogramm
(Sisy AVR3) eine .cc-Datei angelegt hat. Hatte aber nicht gedacht, dass
ich damit solche Probleme bekomme...
Jetzt weiß ich auf alle Fälle wo ich weitersuchen muss - danke für eure
Antworten:-)
MfG Martin
Entweder kein C++ benutzen, oder statt FDEV_SETUP_STREAM dann
fdev_setup_stream benutzen. Dann muss man die Definition der
Variablen allerdings vom Befüllen der initialen Elemente trennen.
Im Prinzip müsste man etwas zu FDEV_SETUP_STREAM vergleichbares in
C++ auch als Konstruktor schreiben können, nur dass sich die Mühe
halt noch keiner gemacht hat. Patches welcome. ;-) (Quellcode-
kompatibel zu C wird es allerdings nicht werden, weil die
Konstruktorsyntax ein wenig anders ist; da wäre dann das Gleicheits-
zeichen im Weg.)
Jörg Wunsch schrieb:> Im Prinzip müsste man etwas zu FDEV_SETUP_STREAM vergleichbares in> C++ auch als Konstruktor schreiben können, nur dass sich die Mühe> halt noch keiner gemacht hat. Patches welcome. ;-) (Quellcode-> kompatibel zu C wird es allerdings nicht werden, weil die> Konstruktorsyntax ein wenig anders ist; da wäre dann das Gleicheits-> zeichen im Weg.)
Nein, eine Konstruktorsyntax kann man dafür nicht verwenden, zuminest
nicht vor C++0x. Man könnte aber FDEV_SETUP_STREAM so abändern, daß es
in beiden Sprachen geht. Das Problem ist ja nur die Initialisierung über
Namen der Strukturelemente. Wenn man die klassisch positional schreiben
würde, ginge es mit C (und zwar nicht nur C99) und mit C++.
Sorry. Wenn man einen Konstruktor definiert, kann man natürlich auch die
Konstruktorsyntax zur Initialisierung verwenden. Aber dann ist es kein
POD mehr und die klassische Initialisierungssyntax geht gar nicht mehr.
Rolf Magnus schrieb:> Man könnte aber FDEV_SETUP_STREAM so abändern, daß es> in beiden Sprachen geht.
Ja, aber dann würde sich das Interface inkompatibel zum bereits seit
mehreren Jahren existierenden ändern. Da hätte ich eher dran denken
müssen, jetzt mag ich das auch nicht mehr ändern.
Wenn mir aber jemand einen C++-Konstruktor als Patch liefert, dann
bau' ich das gern ein. Bitte die Doku nicht vergessen (am besten
als Beispiel im einleitenden Text in stdio.h).
Jörg Wunsch schrieb:> Rolf Magnus schrieb:>> Man könnte aber FDEV_SETUP_STREAM so abändern, daß es>> in beiden Sprachen geht.>> Ja, aber dann würde sich das Interface inkompatibel zum bereits seit> mehreren Jahren existierenden ändern.
Warum sollte sich das ändern müssen?
Rolf Magnus schrieb:>> Ja, aber dann würde sich das Interface inkompatibel zum bereits seit>> mehreren Jahren existierenden ändern.>> Warum sollte sich das ändern müssen?
Nun, wenn ich das seinerzeit so geschrieben hätte, dass man es benutzt
wie:
dann hätte ich kein Problem gesehen, für C++ dahinter einen
Konstruktor zu verstecken und für C die jetzige Konstruktion.
Wie aber willst du den Konstruktor gestalten, damit in C++
das hier geht?
Hmm, naja, die blöde Positionsabhängigkeit wollte ich eigentlich
vermeiden, indem ich die benannten Elemente benutze. Wird mir wohl
nichts anderes übrig bleiben. :-( Schade, dass C++ sich dazu nicht
durchringen konnte.
Ist schon klar, warum du das so gemacht hast. Ich finde das auch
praktisch, aber leider kam C++ ein Jahr vor C99 raus und setzt deshalb
noch auf C90 auf.
