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
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
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
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.
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 */
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.
Aha.. ;o) Danke für die Präzisierungen, ich hatte bloss den Kommentar nochmals rezitiert. Gruss Peter
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.
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
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?
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
> 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.
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
> 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).
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
> Dieser Operator Kauderwelsch > ist nur mit viel Übung lesbar. Dann ist C für dich einfach mal die falsche Programmiersprache. Nimm Ada.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.