www.mikrocontroller.net

Forum: Compiler & IDEs LCD lib lässt sich nicht Compil.


Autor: Sebastian__ (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin blutiger anfänger in C und versuche in GCC die LCD Lib aus dem 
anhag zu comilieren. warum geht das nicht , ich erhalte immer folgende 
fehlermeldungen :

-------- begin --------
avr-gcc -c -g  -Os -Wall -Wstrict-prototypes -Wa,-ahlms=lcd.lst 
-mmcu=at90s8535 -I. lcd.c -o lcd.o
lcd.c: In function `lcd_write':
lcd.c:93: error: invalid lvalue in unary `&'
lcd.c: In function `lcd_read':
lcd.c:136: error: invalid lvalue in unary `&'
lcd.c:140: error: invalid lvalue in unary `&'
lcd.c:147: error: invalid lvalue in unary `&'
lcd.c: In function `lcd_init':
lcd.c:296: error: invalid lvalue in unary `&'
make.exe: *** [lcd.o] Error 1
--------  end  --------


für etwas hilfe von euch wäre ich sehr dankbar,

Sebastian

Autor: MBraun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
das ligt an dem Makro DDR(x) ( (x-1) ) oder so ;-) und an dem PIN(X) 
Makro. Keine Ahnung wieso er das nicht kompiliert. Wenn du die makros 
durch konkrete Port/Pinangaben ersetzt, sollte es gehen.

cu
MB

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke, aber so weit war ich dann auch schon, wenn ich anstatt 
DDR(Displ_Port) oder so ählich schreibe DDRA oder DDRC dann gehts, aber 
waru geht das nicht so? der sinn des ganzen is ja das man alles im LCD.h 
file konfigurieren kann in nicht immer in den einzelnen routinen 
rumfingern muss , oder ? dafür muss es doch ne sinvolle erklärung geben.

Sebastian

Autor: MBraun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
K.A. wieso das so ist. Mir war's nach einem Weilchen rumprobieren 
einfach zu dumm, und dannn hab ich's direkt reingeschrieben. Klar wär's 
besser, wenn das makro funktionierte.

gruß
MB

Autor: MBraun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
du kannst mal probieren es so zu machen:
Die DDR und PIN Funkionen durch LCD_PORT_DDR und LCD_PORT_PIN 
austauschen.
#define LCD_PORT_DDR (LCD_PORT-1)
#define LCD_PORT_PIN (LCD_PORT-2)

könnte funktionieren - getestet hab ich's noch nicht.

gruß
MB

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich habe es jetzt so gemacht

#if LCD_IO_MODE  /* only necessary in IO mode */
#define LCD_PORT         PORTC     /* all lcd pins must be on SAME port 
*/
#define LCD_DDR     DDRC
#define LCD_PIN     PINC


das mit #define LCD_PORT_PIN (LCD_PORT-2) hat auch nicht funkt..

Sebastian

Autor: MBraun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich weiß jetzt wie's mit der 3.2er Version funktioniert:

#define PIN(x)  (*(&x - 2))
#define DDR(x)  (*(&x - 1))

Man kann dann so drauf zugreifen:

outb(DDR(PORTB)), value);
outp(value, DDR(PORTB));
DDR(PORTB) = value;

gruß
MBraun

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das ist ja mal eine tolle Lösung! Ich für meinen Teil habe die 3.2er 
Version des AVRGCC wieder runtergeschmissen weil die Jungs hier echten 
Murks geleistet haben! Wenn das die einzige Macke ist, die er in der 
nächsten Zeit bei der 3.2 feststellt, dann darf er ein rotes Kreuz in 
den Kalender machen. Ich arbeite nun wieder mit der Version 3.02, mit 
der ich eigentlich recht zufrieden bin.

Gruss,

Peter

Autor: BUB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was sollem mir eigentlich diese zeilen sagen?
was sollt das -1 und -2 ?
#define PIN(x) (*(&x - 2))
#define DDR(x) (*(&x - 1))

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich zitiere nochmal von MBraun:
> #define PIN(x) (*(&x - 2))
> #define DDR(x) (*(&x - 1))
> Man kann dann so drauf zugreifen:
> DDR(PORTB) = value;
Um die Verwendung wie in der letzten Zeile gehts.
PORTB ist eine Konstante, die die Adresse des PORTB-Register beinhaltet. 
Die Adresse (PORTB-1) repräsentiert das DDRB-Register (siehe 
Datenblatt), (PORTB-2) steht für das PINB-Register - mehr nicht.
Du kannst also jetzt:
DDR(PORTB) = value;   oder DDR(PORTC) = ...
schreiben und mußt _nicht_:
DDR(DDRB) = value;    schreiben.

Schmittchen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Schmittchen

soweit ist die Sache ja wohl schon klar. Aber vielleicht erklärst du 
auch mal, wieso bei der Version 3.2 der Term ((x-1)) in dem o.a. Makro 
durch den äusserst sinnvollen Ausdruck (*(&x-1)) ersetzt werden muss. 
Das würde mich (und bestimmt viele Andere hier) wesentlich mehr 
interessieren.

Gruss,

Peter

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> soweit ist die Sache ja wohl schon klar.
So habe ich aber die Frage von BUB verstanden.

> Aber vielleicht erklärst du auch mal [...]. Das würde mich (und bestimmt viele 
Andere hier) wesentlich mehr interessieren.
Tut mir leid, daß ich deine Forderungen(?) nicht erfüllen kann. ;-)

Schmittchen.

Autor: MBraun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
vielleicht hilft das weiter:
http://www.avrfreaks.net/phorum/read.php?f=2&i=410...

cu

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MBraun

Danke für den Hinweis, jetzt blicke ich auch, wie so eine verrückte 
Geschichte zustande kommt. Dummerweise funktioniert der neue Befehl outb 
in diesem Fall auch nicht besser (wie von einigen besserwissenden Leuten 
im avrfreaks-Forum empfohlen!), da er auch nur mittels eines einfachen 
Makros aus dem alten outp-Befehl abgeleitet wurde.
Die Information, dass ein Befehl wie DDRB=0xff so geschrieben nun 
funktionieren soll, kommt reichlich spät! Darüber habe ich in der 
beigefügten Doku der Version 3.2 nicht eine einzige Silbe gelesen. Aber 
wie schon erwähnt, die V3.2 ist sowieso in mehrerlei Hinsicht ein 
verunglücktes Kind, bei dem man wohl krampfhaft versucht hat, die Fehler 
der Vergangenheit wegzukorrigieren. Und das mit dem Ergebnis, dass nun 
die ganze Rückwärtskompatibilität über den Haufen geworfen wurde und die 
Anwender herumrätseln, wieso nun syntaktisch richtig geschriebener Code 
plötzlich nicht mehr übersetzt wird und mit obskuren Fehlermeldungen 
abbricht.
Aber da die Version 3.2 noch einige Macken mehr hat, habe ich, wie 
bereits geschrieben, das Problem für mich persönlich ganz einfach durch 
ein Downgrade auf die vorige Version gelöst, mit der ich auch ganz 
zufrieden bin. Die fehlenden Befehle, wie outb, inb und inw, kann man 
sich selbst recht einfach durch kleine einzeilige #defines definieren, 
dafür braucht man die neue Version nicht. Soweit meine bescheidene 
Meinung über den neuen avrgcc V3.2

Gruss,

Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.