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
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.
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.
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)
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
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
1
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...
Jörg Wunsch schrieb:> Im Prinzip kann man sich den ganzen Quark auch sparen und gleich>>
1
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.
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
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
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.
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 :-(
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.
portfehler.jpg
(260 KB)
