mikrocontroller.net

Forum: Compiler & IDEs WinAVR aktualisieren


Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich hab jetzt schon ein bissel mit WinAVR gespielt, aber ich hab
festgestellt das das ganze schon ein bissel älter ist. Ich hab
mittlerweile mitbekommen das man den AVR-GCC von WinAVR aktualisieren
kann. Ich hab auch gesehen das man dafür ein paar Sachen braucht. Aber
ganz kapiert hab ich das noch nicht. Wäre für ein paar Tips dankbar die
mir weiterhelfen

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dennis

Du kannst Dir die neuste avr.libc-1.4.0 runterladen un einfach ins
WinAVR Verzeichniss entpacken, überschreibe bestehende Files.

Etwas komplizierter wird's, wenn Du auch den neusten GCC(4.0.2) und
die neusten BinUtils(2.16) benutzen willst. Die musst Du Dir selber
patchen und zusammen compilieren, ist offenbar nicht ganz einfach,
trotz Anleitungen die im Internet zu finden sind.

Ich empfehle, auf den nächsten WinAVR Release zu warten. Dieser wäre
eigentlich schon längst fällig, leider hat Eric Weddington kaum Zeit,
daran zu arbeiten. Aber ich denke es wird sich in den nächsten Wochen
etwas tun....

Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ich hab noch was...   ;o))

Es gibt eine simple Möglichkeit, WinAVR zu aktualisieren, AtmanAVR
enthält ein neueres und fertig compiliertes AVR-GCC Paket für Win32:

_______________________________________________________________

AtmanAvr C new version 5.1 is available:
AVR-GCC tool chain (gcc-3.4.4, binutils-2.16.1, avr-libc-1.4.0)
Added support for new devices
- AT90PWM2/3
- ATmega329/3290/649/6490
- ATtiny25/45/85
- ATmega164/324/644
- ATmega640/1280/1281.
_______________________________________________________________

Link zum Download des AtmanAVR AVR-GCC Package:
http://www.atmanecl.com/download/avrgccUpdate.exe
_______________________________________________________________

Update WinAVR AVRGCC tool chain with AtmanAVR AVRGCC package:
1) Download AVRGCC package AVRGCCUpdate.exe from Atman site
2) Install it to a specified directory
3) Copy the subdirectories (avr, bin, lib and libexec) under the
   created directory \avrgcc and paste them to \WinAVR directory
4) Uninstall it (AVRGCC 3.4.4)
_______________________________________________________________

Bei mir hat's funktioniert... ;o)

Gruss Peter

Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cool, danke. Werd ich probieren

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fiel bei der Version auf, dass da die #define(s) für sbi(), cbi(),
inp, etc wieder drin sind. Die waren doch eigentlich schon längst
entfernt worden. Da ich für einige alte Projekte schon eigene Lösungen
entwickelt hatte, kam es hier zu Warnings.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yes, these macros are defined in <avr\sfr_defs.h> for backward
compatibility. Nevertheless, you shouln't use them in new projects.


/* Backwards compatibility, do not use in new programs.
   These macros are removed.*/

#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))
#define inb(sfr) _SFR_BYTE(sfr)
#define outb(sfr, val) (_SFR_BYTE(sfr) = (val))
#define inw(sfr) _SFR_WORD(sfr)
#define outw(sfr, val) (_SFR_WORD(sfr) = (val))
#define outp(val, sfr) outb(sfr, val)
#define inp(sfr) inb(sfr)
#define BV(bit) _BV(bit)

#endif  /* SFR_DEFS_H */

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Antwort ist falsch.

Da wir jetzt ein <compat/deprecated.h> haben, haben wir darin nicht
nur die Dinge aufgenommen, die in Version 1.4 neu "deprecated"
geworden sind, sondern auch noch die ,,beliebten'' alten IO-Makros
mit
nachgezogen.

<compat/deprecated.h> sollte aber ausschließlich zur Pflege
existierender Altlasten benutzt werden, alles darin enthaltene ist
eben nicht nur komplett überflüssig, sondern wurde aus irgendwelchen
Gründen ,,entsorgt''.

Übrigens: bitte <avr/sfr_defs.h>, nicht <avr\sfr_defs.h>.  Das
erleichtert die Portierbarkeit des Codes.  Der Vorwärtsstrich
funktioniert auch unter sämtlichen existierenden Windowsvarianten (ja,
bis zurück zu Windows 1.x, sogar bis zurück zu MS-DOS wenigstens
Version 3.x) als Pfadnamentrenner.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha..  ;o)

Danke für die Präzisierungen, ich hatte bloss den Kommentar nochmals
rezitiert.

Gruss Peter

Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was wäre denn der aktuelle Ersatz für sbi, cbi & co?

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PORTB|=_BV(1) setzt das 2.Bit in PORT B
PORTB&=~_BV(1) löscht es.

Der Compiler macht dann draus sbi usw. aber nicht wenn man

PORTB|=_BV(1)|BV(2)

macht, dann ist out schneller, aber das weiss der Compiler selbst.
Muss aber glaub ich mind. mit -Os optimiert werden.

Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso wird in C eigentlich immer nur mit solchen Operatoren gearbeitet
die man nur versteht wenn man sich damit auskennt? Was spricht gegen
Befehle wie sbi und cbi? Sind doch immerhin die normalen
Maschinenbefehle

Autor: Fritz Ganter (fritzg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sbi() ist ein Makro, das heisst halt zufällig so wie der
Assemblerbefehl. Aber sbi() ist halt kein C, auf einem anderen
Controller gibts den Befehl vielleicht nicht.
Die Schreibweise mit PORTB|=_BV(1) ist portabel wenn PORTB ein gültiger
Portname ist.

| ist ein binäres ODER, & ein Binäres UND, ~ die Negation.

man kann auch schreiben
PORTB=PORTB|(1<<1);

Ich könnte auch als C Programmierer sagen: was ist sbi? Muss ich jetzt
Assembler können um C zu programmieren?

Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber _BV ist doch auch ein Makro. Da ist mir die Logik nicht ganz klar.
Für mich ist sbi & co verständlicher, egal in welcher Sprache

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich könnte auch als C Programmierer sagen: was ist sbi? Muss ich
> jetzt Assembler können um C zu programmieren?

Genauso könntest du fragen "was ist PORTB?" oder "was ist _BV?".

Ich habe nie verstanden warum diese Makros plötzlich böse sein sollte.
Wem "sbi" nicht gefällt, der kann es ja "set_bit" nennen. Aber das
"PORTB &=~ _BV(1)"-Kauderwelsch macht den Code nur unnötig
fehleranfällig und unleserlich.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der richtige C-Weg um Bit's zu setzen oder zu löschen ist zB:

PORTB |=   (1<<PIN3)|(1<<PIN2);   // Setzt Pin 2+3
PORTB &= ~((1<<PIN3)|(1<<PIN2));  // Löscht Pin 2+3

Gruss Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe nie verstanden warum diese Makros plötzlich böse sein
> sollte.

Sie waren seit ca. 2001 überflüssig.  Sie waren einfach nur Krücken
zuvor, damit man an die entsprechenden Maschinenbefehle überhaupt
herankam, als der Compiler noch zu blöd war dafür.  Seinerzeit waren
sie inline-asm-Makros, die direkt die entsprechenden Maschinenbefehle
abgebildet haben -- mit allen Fallstricken.  Wenn das entsprechende
Register nicht SBI-fähig war, bekam man für scheinbar syntaktisch
richtigen Code plötzlich seltsame Assemblerfehlermeldungen an den Kopf
geworfen.

,,Böse'' sind sie nicht, aber genügend Leute haben sie sinnlos und
blindlings eingesetzt in der Annahme, da sei auch das drin, was drauf
steht (das ist es keineswegs immer).  Davon abgesehen, dass ich diesen
Makros persönlich die Hauptschuld gebe, dass von allen
Lowlevel-C-Programmierer-Gemeinden die AVR-C-Programmierer diejenigen
sind, die als einzige nach wie vor ziemlich lernresistent gegenüber
C-Bit-Operatoren sind, spätestens wenn man dann sowas sieht wie:

sbi(DDRB, 0);
sbi(DDRB, 1);
sbi(DDRB, 2);
sbi(DDRB, 3);
sbi(DDRB, 4);
sbi(DDRB, 5);
sbi(DDRB, 6);
sbi(DDRB, 7);

fragt man sich schon, ob nicht vielleicht beim Schreiben der richtigen
Bitnotation manch einem die Idee gekommen wäre, dass es auch ein

DDRB = 0xff;

getan hätte.

Aber `deprecated' hat diese Makros bereits Marek Michalkiewicz,
nachdem er dem Compiler endlich beigebracht hat, mit der üblichen
Notation für IO-Register ordentlich umzugehen (sofern ich mich recht
erinnere).

Autor: dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schließe mich da Andreas' Meinung an. Dieser Operator Kauderwelsch
ist nur mit viel Übung lesbar. Allerdings muß ich ein's gestehen: bei
anderen C-Compilern dürfte man diese Macros von Haus aus nicht finden

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dieser Operator Kauderwelsch
> ist nur mit viel Übung lesbar.

Dann ist C für dich einfach mal die falsche Programmiersprache.
Nimm Ada.

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich persönlich habe schon lange sbi() & co. aus meinen Programmen
verbannt. Ich benutze wie oben geschrieben nur sowas:
PORTB |=   (1<<PIN3)|(1<<PIN2);   // Setzt Pin 2+3
PORTB &= ~((1<<PIN3)|(1<<PIN2));  // Löscht Pin 2+3

Mit _BV kann ich auch nicht viel anfangen. Dabei kann PORTB erstmal als
ein Zeiger auf einen unsigned char gesehen werden. Alle darüber
hinausgehenden Konstrukte sind nicht wirklich C und bei Programmen, die
mit abenteuerlichen #define aus C Pascal oder Basic machen wollen, kann
ich mich ebenfalls nur schütteln. Und Assembler hat in einem C-Programm
eigentlich nicht wirklich was verloren. Wenn man meint sowas gebrauchen
zu müssen, so gehört sowas in eine individuelle Header-Datei aber nicht
in den Compiler selber.

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh je, ich lese grad meinen älteren Beitrag und möchte mich bzw. mein
Copy&Paste korrigieren:
PORTB |=   (1<<PORTB2)|(1<<PORTB3);   // Setzt Pin 2 u.3
PORTB &= ~((1<<PORTB4)|(1<<PORTB7));  // Löscht Pin 4 u.7

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.