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
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
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
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
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
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
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
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
was sollem mir eigentlich diese zeilen sagen? was sollt das -1 und -2 ? #define PIN(x) (*(&x - 2)) #define DDR(x) (*(&x - 1))
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.
@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
> 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.
@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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.