LCD lib lässt sich nicht Compil.

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.

Hi,
vielleicht hilft das weiter:
http://www.avrfreaks.net/phorum/read.php?f=2&i=4102&t=4102#4102

cu

@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