Nach Umstieg von Atmega88 auf Atmega328p kann nicht mehr kompiliert werden!

[Martin E. (mrtnernst)]

Hallo zusammen,

ich bräuchte mal Hilfe. Ich bin vom Atmega88 auf den Atmega328p 
umgestiegen, weil der mehr Flash-Speicher hat und angeblich die gleiche 
Pinbelegeung. Genau diese Pins machen mir jetzt Proleme. Wenn ich die 
C-Dateien in meinem Projekt kompiliere, dann erklärt mir AVR GCC im 
AVR-Studio die Ports als undeklariert und kompiliert somit nicht. Kann 
mir jemand sagen was da los sein kann? Der Compiler spuckt, wie im Bild 
zu sehen viele Fehlermeldungen aus, die aber alle mit den Ports zu tun 
haben. Ich dachte, wenn man die  <avr\io.h> über #include <avr\io.h> 
einfügt erkennt er die Portabkürzungen wie Portc PC1 usw.. Bei meinem 
Atmega88 macht er es richtig.

Ich hoffe da kann mir jemand helfen.

Martin

[Flo (Gast)]

vielleicht kennt deine Entwicklingsumgebung den neuen Prozessor noch 
nicht?

Öffne die Datei avr/io.h mal und schau, ob ein Eintrag für den AT 
mega328p existiert, ansosnten fehlen dem Compiler die Informationen über 
den Controller.

[weene (Gast)]

Hallo,

die Ports werden anders bezeichnet:

z.B. Port B:

ATMega88

#define PORTB   _SFR_IO8 (0x05)
/* PORTB */
#define PB7     7
#define PB6     6
#define PB5     5
#define PB4     4
#define PB3     3
#define PB2     2
#define PB1     1
#define PB0     0

ATMega328P

#define PORTB _SFR_IO8(0x05)
#define PORTB0 0
#define PORTB1 1
#define PORTB2 2
#define PORTB3 3
#define PORTB4 4
#define PORTB5 5
#define PORTB6 6
#define PORTB7 7

Evtl kannst du deine benötigten defines umbiegen.
z.B.:
#define PB0 PORTB0

MFG
weene

[Jörg W. (dl8dtl) (Moderator)]

Muss eine alte Version der avr-libc sein, das war mehr ein Bug denn
ein Feature.  PORTBx bezeichnet das Bit x im Register PORTB, während
die Makros wie PBx schon immer "generisch" waren, d. h. sie unter-
scheiden nicht, ob damit PINB, PORTB oder DDRB bearbeitet werden soll.

Lässt sich in aktueller Umgebung auch für einen ATmega328P benutzen.

Btw., Bildformate.  Screenshot als PNG ist Mift, und Fehlermeldungen
postet man besser als Textdatei (ggf. als Anhang) statt als Screenshot.

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:
> Muss eine alte Version der avr-libc sein, das war mehr ein Bug denn
> ein Feature.  PORTBx bezeichnet das Bit x im Register PORTB, während
> die Makros wie PBx schon immer "generisch" waren, d. h. sie unter-
> scheiden nicht, ob damit PINB, PORTB oder DDRB bearbeitet werden soll.

Ist der Zug eigentlich schon abgefahren?
IMHO sollte man den ganzen PB0, PA0, PC0, ... als das ansehen, ws er 
ist: Eine nette Idee, aber eigentlich kompletter Unsinn.

#define BIT_0   0

hätte es auch getan und es suggeriert nicht irgendeine spezielle 
Bedeutung, die magisch in

    PORTB |= ( 1 << PB0 );

steckt.

(Und Hand aufs Herz: Wie oft sieht man, dass zwar ein Port gewechselt 
wurde, aber die Pxx Makros nicht angepasst wurden.

     PORTA |= ( 1 << PC3 );

ist nun mal nicht schön, aber auch nicht 'fälscher' als

     PORTA |= ( 1 << PA3 );


IMHO, würde ein

     PORTA |= ( 1 << BIT_3 );

die Sache auch nicht weiter verwirren, und man wäre diese ganzen 
Zig-Konstanten für Ports, Pins, und DDR Bits ein für alle mal los (zumal 
die ja sowieso nichts bringen)

[Peter D. (peda)]

Jörg Wunsch schrieb:
> Muss eine alte Version der avr-libc sein, das war mehr ein Bug denn
> ein Feature.  PORTBx bezeichnet das Bit x im Register PORTB, während
> die Makros wie PBx schon immer "generisch" waren, d. h. sie unter-
> scheiden nicht, ob damit PINB, PORTB oder DDRB bearbeitet werden soll.

Nö, das hängt vom Typ ab, zumindest beim aktuellen WINAVR:

Die ATmega48 .. 168 ohne 'P' definieren PINB0, DDB0, PB0 usw.

Die ATmega48P .. 328P definieren aber PINB0, DDB0, PORTB0.


Peter

[Jörg W. (dl8dtl) (Moderator)]

Peter Dannegger schrieb:

> Nö, das hängt vom Typ ab, zumindest beim aktuellen WINAVR:

Nein, alle definieren alles:

$ echo "#include <avr/io.h>" > test.c
$ for device in 48 48p 88 88p 168 168p 328p
> do
> dev="atmega${device}"
> echo "${dev}:"
> avr-gcc -mmcu=$dev -dM -E test.c | egrep 'PORTB0|PB0'
> done
atmega48:
#define PORTB0 PB0
#define PB0 0
atmega48p:
#define PORTB0 0
#define PB0 PORTB0
atmega88:
#define PB0 0
#define PORTB0 PB0
atmega88p:
#define PORTB0 0
#define PB0 PORTB0
atmega168:
#define PB0 0
#define PORTB0 PB0
atmega168p:
#define PORTB0 0
#define PB0 PORTB0
atmega328p:
#define PORTB0 0
#define PB0 PORTB0

Ich kann mir nicht vorstellen, dass WinAVR das irgendwie versaut haben
könnte, aber du kannst ja gern obiges ausprobieren.  Eine bash ist ja
bei WinAVR dabei, in die du das 1:1 abtippen kannst.

Karl heinz Buchegger schrieb:
> Ist der Zug eigentlich schon abgefahren?

Naja, einigermaßen schon, der fährt schon zu lange so. ;-)

Im Prinzip kann man sich den ganzen Quark auch sparen und gleich

PORTB = _BV(0) | _BV(3);

schreiben.  Man sollte ja nie "nie" sagen, aber hier würde ich
wirklich sagen, dass nie jemals jemand auf die Idee käme, PORTB0
vielleicht auf Bit 7 zu legen...

[Karl H. (kbuchegg)]

Jörg Wunsch schrieb:

> Im Prinzip kann man sich den ganzen Quark auch sparen und gleich
>
>

PORTB = _BV(0) | _BV(3);

>
> schreiben.

Oder so.

> Naja, einigermaßen schon, der fährt schon zu lange so. ;-)

Eventuell könnte man zumindest mit Tutorial bzw. Arbeit im Forum 
zumindest ein paar Waggons auf eine weniger holprige Parallelstrecke 
umleiten.

[Peter D. (peda)]

Jörg Wunsch schrieb:
> Ich kann mir nicht vorstellen, dass WinAVR das irgendwie versaut haben
> könnte, aber du kannst ja gern obiges ausprobieren.

Stimmt, beides geht bei allen (WinAVR - 20100110).
Ich hab ein Testprogramm für ATmega8, 88, 88P compiliert, geht.

Aber im "iom8.h" und "iomx8.h" finde ich kein PORTB0.
Und im "iom88p.h" kein PB0.
Merkwürdig.

Edit:
Habs gefunden, im "portpins.h".

Peter

[Roland B. (rolandb)]

Habe das gleiche Problem. Heisst das jetzt man muss die portpins.h 
includieren? Kann es jetzt nicht testen, da ich hier keinen 328p habe. 
Ab er ich muss das in meiner DA machen.



mfg

[Jörg W. (dl8dtl) (Moderator)]

Roland Bumm schrieb:
> Problem. Heisst das jetzt man muss die portpins.h
> includieren?

Nein, es heißt, dass du auf eine aktuelle Version (der avr-libc, um
genau zu sein) upgraden musst.

[Rolf Magnus (Gast)]

Jörg Wunsch schrieb:
> PORTBx bezeichnet das Bit x im Register PORTB, während die Makros wie
> PBx schon immer "generisch" waren, d. h. sie unterscheiden nicht, ob
> damit PINB, PORTB oder DDRB bearbeitet werden soll.

Inwiefern unterscheidet PORTBx das? Ist das nicht auch einfach nur ein 
Makro, das den Wert x hat, genau wie PBx?

> Btw., Bildformate.  Screenshot als PNG ist Mift,

Na was ein Glück, daß er es stattdessen als JPG gepostet hat :-(

[Jörg W. (dl8dtl) (Moderator)]

Rolf Magnus schrieb:

> Inwiefern unterscheidet PORTBx das?

Gar nicht.  Ist halt nur der Name des Bits gemäß Datenblatt.  Ich
schrieb ja weiter unten, dass man sich den ganzen Zinnober mit den
Bitnamen auch getrost klemmen kann.

>> Btw., Bildformate.  Screenshot als PNG ist Mift,
>
> Na was ein Glück, daß er es stattdessen als JPG gepostet hat :-(

Verschreibselfehler.  Genau darüber wollte ich mich ja beklagen. ;)
PNG wäre natürlich OK, plain text jedoch besser.