Hallo, kann mir jemand schreiben, wie man unter Windows98 das avr-gcc starten kann? Wenn man es direkt anklickt, huscht des DOS-Fenster über den Bildschirm, wenn man ein DOS-Eingabefenster öffnet und avr-gcc aufruft, kommt eine Fehlermeldung von wegen keiner Inputdatei. Ich erinnere mich dunkel, daß man es irgendwie starten konnte und sich dann nur noch zum Verzeichnis mit der C-Datei und der makefile navigieren mußte. Aber mir fällt partout nicht mehr ein, wie das erreicht wurde. Sicher ein Frühsympton von Alzheimer. Kann mir jemand helfen? Vielen Dank Günther
Also falls du WinAVR installiert hast (solltest du, falls du es noch nicht hast), dann schaue mal in das Verzeichnis WnAVR/examples/demo Da ist ein Beispielprojekt. Prinzipiell muss man nur in das VErzeichnis wchseln und "make all" eingeben. Man kann das Projekt als Beispiel für seine eigenen verwenden. Zusätzlich .c un .h File müssen dann lediglich im Makefile eingefügt werden. Mit "make extcoff" kann man ein .cof File erzeugen, welches das Debuggen im AVRStudion von Atmel erlaubt (ab Vesion 4.0.8). Helfen dir die Hinweise wieder auf die Sprünge ? :) MfG Sebastian
hi, hab zwar bis jetzt die AVRs in assembler programmiert (werde ich auch weiterhin, nach 7 jahren assemblererfahrung) aber die infos kann ich dir geben.... die GCC - Compiler kommen ursprünglich aus der Linuxecke (konsolenfetischisten, sorry) d.h.: der gcc ist ein textbasiertes kommandozeilen-konsolenprogramm, für den es aus der windowswelt noch kaum einer geschafft eine GUI zu schreiben, bis auf einer Software: "AVREdit" kostet: nix gibts bei: http://www.avrfreaks.net/AVRGCC/index.php? PHPSESSID=cd58cd644299ed00eca56431657081ff -> bildschirm nach unten scrollen der zweite eintrag un downloaden... generell: würde ich an deiner stelle, jedoch üben, den gcc direkt zu verwenden... bei www.avrfreaks.net gibts da einen guten startpunkt, um sich über den avrgcc zu informieren...
Vorsicht: soweit ich weiß, schleppt AVRedit eine hornalte Version von Compiler und Bibliothek mit sich rum. Nicht benutzen. Daß Unixer ,,Consolenfetischisten'' seien, ist ein Gerücht, daß sich in Windows-Kreisen ganz hartnäckig hält. ;-) Nein, ich drücke beispielsweise auf die Taste F5, um den Job zu compilieren, oder mit der mittleren Maustaste (ein Luxus, den es seit der Microsoftschen Segnung der Wühlmaus ja nun auch für Windowser gibt :-) auf eine Fehlermeldung, um zur entsprechenden Codezeile zu kommen. GUI? Hmm, einfach Emacs. Ein Texteditor für alles: zum Schreiben und Debuggen von Code (gleiches ,,GUI'' für alle Plattformen, AVR, IA32, Kerneldebugging, ... -- Windows ist heute noch lange nicht dort), von emails, Textdokumenten, oder selbst zum Posten in diesem Forum. Ansonsten bringt wohl WinAVR ebenfalls einen Editor mit, den man so einigermaßen als IDE für den Job ansehen kann.
Wollte nicht falsch verstanden werden... bin doch selbst auf linux... zu gui: günther hat ja anscheinend eine gui erwartet, als er es in seinem (wahrscheinlich) explorer "doppelklickte". zumindest erwartete er eine ui (user interface) (übrigens kenne ich den emacs, und ich hab ihn nicht gemeint, und ich liebe in ebenfalls... :-)) man kann avredit übrigens ohne bedenken benutzen, schliesslich wurden avrs mit dieser compilerversion sehr lange und auch erfolgreich programmiert... also wozu unnötige Panikmache mit !!!nicht benutzen!!!?????? Jörg Wunsch : "Ansonsten bringt wohl WinAVR ebenfalls einen Editor mit, den man so einigermaßen als IDE für den Job ansehen kann." -> dann schreib ihm doch rein wie er es machen muß, und hack nicht beleidigt auf meinem post rum... er kann den avrgcc auch ganz einfach ins AVRStudio 3.56 einbetten und hat ne komplette IDE!!! wie das im detail funktioniert ist auch unter www.avrfreak.net beschrieben.... übrigens günther, was zu makefiles, und beispielmakefiles findest du hier: http://www.avrfreaks.net/AVRGCC/index.php und jörg: tut mir leid, dich mit konsolenfetischist beleidigt zu haben...
> man kann avredit übrigens ohne bedenken benutzen, schliesslich > wurden avrs mit dieser compilerversion sehr lange und auch > erfolgreich programmiert... also wozu unnötige Panikmache mit > !!!nicht benutzen!!!?????? Weil es dafür keinerlei Support mehr gibt, weil es keine Doku gab damals (so daß die Leute hier dieselben uralten Fragen alle nochmal stellen), etc. pp. AVR Studio 3 ist ebenfalls tot. Wenn es Probleme mit einem COFF-File dort gibt, wird Atmel sie nicht mehr beseitigen. > dann schreib ihm doch rein wie er es machen muß, ... Windows löschen, FreeBSD installieren, Emacs benutzen. :-)) Sorry, ich habe keine wirkliche Ahnung, wie man das unter Windows anstellen muß. Schließlich benutze ich extra kein Windows, damit ich mich nicht mit dessen Problemen herumschlagen muß. Aber viele andere sind mit den existierenden Anleitungen für WinAVR und PN zurechtgekommen, es kann also gar nicht so sehr schwer sein. Ich habe allerdings Ahnung von der avr-libc, zumindest so viel, daß ich dort einer der Entwickler bin, und habe selbst genügend Stunden auch in die Doku gesteckt, als daß ich hier vor der Benutzung von überalterten Versionen warnen möchte. Das war das Hauptanliegen meines Postings.
Hallo,
vielen Dank für die Antworten.
Es funktioniert jetzt ganz gut, seitdem ich gemerkt habe,
daß ich im DOS-Fenster nicht gcc, sondern make aufrufen
muß. Ich benutze jetzt pn2, make und TwinAVR nebeneinander
und seitdem ich W2k gelöscht und Win98 installiert habe,
geht es ganz gut, um nicht zu sagen, hervorragend.
Allerdings finde ich auch, daß die Dokumentation
erweiterungsbedürftig ist. Ich versuche verzweifelt,
da und dort ein paar Zeilen Assembler in einem C-Programm
unterzubringen, aber man findet kaum etwas, und solche
Konstuktionen wie asm("Anweisung") "/n/t" verschmäht
der Compiler.
Man hat es halt nicht leicht.
Gruß
Günther
Umm, hast Du denn die Doku überhaupt mal gesucht? Gerade der inline-Assembler ist ausnehmend gut dokumentiert worden. Ganz davon abgesehen: gerade am Anfang solltest Du wohl von inline asm erstmal absehen. Es gibt nur ganz selten Gründe, warum man das machen will, fast immer ist ein C-Konstrukt, selbst wenn er auf den ersten Blick gar nicht so ,,schlank'' aussieht, im Kompilat am Ende genauso effektiv. Das klassische Beispiel ist sowas wie: PORTB |= _BV(2); ...dem man sicher auf den ersten Blick nicht ansieht, daß ein einziger SBI-Befehl dabei rauskommt.
Hi Günther Wenn du schon mit PN2 arbeitest kannst du den Aufruf von Make ganz einfach als Tool integrieren. Dann braucht's keine DOS-Box mehr. Das geht so: -Im Menu Tools den Eintrag Options auswählen. -Im Options-Dialog auf Tools klicken. -Als Scheme C/C++ auswählen. -Auf Add klicken. -Formular ausfüllen: - Name: beliebig, z.B. Make all - Command: make - Folder: leer lassen - Parameters: all - Capture Output: aktivieren und use an individual output window - Clear output before running: aktivieren - Use the built in error parser: aktivieren Das Ganze gut umrühren, speichern und loslegen. Ich habe mir übrigens auch entsprechende Einträge für andere Tools (z.B. PonyProg2000) auf die gleiche Weise eingerichtet. Gruss Christian
kleiner Nachtrag, falls die von Christian beschriebene Methode etwas "bockt": bei Folder ein %d eintragen.
Hi Jörg doch in der AVR-doku lese ich auch, ich finde sie sehr gut, aber für einen Anfänger nicht ausreichend. Und das Kapitel mit dem asm inline habe ich noch nicht erfolgreich nachvollzogen. Die Assemblerzeilen ist nur ein Notbehelf mangels solider C-Kenntnisse (ich schaffe es z.B. nicht, bei der I2C-Ansteuerung die wörtlich (!) aus dem ATmega-Manual abgeschriebene while- Schleife mit ";" zum Laufen zu bringen. Wenn ich in ein Unterprogramm springe und ein paar Lämpchen blinken lasse, geht es, wenn ich dann wieder zum ";" oder wenigstens zu einer Delayschleife zurückkehre, geht es nicht mehr. Deshalb mein Bedarf nach Assembler-inline Günther
Analyse des Problems wäre aber besser, als sich nur nach der Methode ,,Zurechtwurschteln, bis da was funktioniert'' rumzudrücken. Erster Versuch: Du benutzt einen ATmega128 im Auslieferungszustand? Das wäre wieder ein typischer Fall für FAQ nicht gelesen...
@Jörg ich habe einen ATmega16 auf einem Entwicklungsboard von Olimex. Den programmiere ich mit TwinAVR. Im Auslieferungszustand ist er nicht mehr, allerdings ist der Compiler fabrikfrisch, also noch nicht für die max. Speichergröße (avr5) eingestellt, weil ich das für meine Exercitien z.Zt. nicht brauche. Aber zu meinen Problemen mit C, warum z.B. Funktionen nicht aufgerufen werden, kann ich in meinen Manuals nichts finden. Es bleibt nichts anderes übrig, als weiter zu suchen - auch in den FAQs. Gruß Günther
Mit der Bemerkung: > Im Auslieferungszustand ist er nicht mehr, allerdings ist der > Compiler fabrikfrisch, also noch nicht für die max. Speichergröße > (avr5) eingestellt, weil ich das für meine Exercitien z.Zt. nicht > brauche. Heißt das, daß Du den richtigen MCU-Typ beim Compilieren nicht verwendest? Dann brauchst Du Dich auch nicht wundern, warum Deine Funktionsaufrufe nicht funktionieren... Dein Problem ist vermutlich eine falsche Initialisierung des Stackpointers, aber mit den paar Brocken, die Du durchblicken lassen hast, kann man das schwer einschätzen. Eigenwerbung: http://www.sax.de/~joerg/mfile/ falls Du Dich jetzt erstmal noch nicht mit den Details von `make' befassen willst, aber schnell zum Zuge kommen möchtest.
Hallo Jörg >Heißt das, daß Du den richtigen MCU-Typ beim Compilieren nicht >verwendest? doch, natürlich schon, aber sonst nabe ich in der makefile nichts verändert, insbesondere den Optimierungsgrad nicht. Und in einer FAQ habe ich gelesen, daß manche Delayschleifen einfach wegoptimiert würden, wenn man nicht "volatile" an passender Stelle einfügt. >Dein Problem ist vermutlich eine falsche Initialisierung des >Stackpointers, aber mit den paar Brocken, die Du durchblicken lassen >hast, kann man das schwer einschätzen. Ich schicke Dir sehr gern das Programm. Es wäre nett, wenn Du mal einen Blick draufwerfen künntest. Es ist nur ganz kurz und ein geübter C-Programmierer hat sicher mit einem Blick den Fehler entdeckt. Es handelt sich um die Ansteuerung eines I2C-Bausteins. Ich habe ea aus dem AVR-Manual genommen, nicht weil ich Deine Ein-Bier-Lizenz aus avr-libc nicht bezahlen wollte (eigentlich schulde ich Dir inzwischen mehr als nur ein Bier für die anderen Informationen aus avr-libc), sondern weil das Manualbeispiel nur das Gerippe für TWI enthält. >Eigenwerbung: >http://www.sax.de/~joerg/mfile/ Kenne ich. Noch einfacher: makefile aus gcctest anpassen. Vielen Dank Günther
> doch, natürlich schon, aber sonst nabe ich in der makefile nichts > verändert, insbesondere den Optimierungsgrad nicht. D. h. -O0? Das ist immer eine schlechte Idee. Der dabei entstehende Code ist um ein Vielfaches größer als optimierter Code, viele Fehler werden erst durch die Optimierung offensichtlich. Aus diesem Grunde taugt Weglassen der Optimierung m. E. nicht einmal fürs Debuggen. Kommt hinzu, daß viele Compilerwarnungen erst durch die Codeflußanalyse des Compilers produziert werden können, die bei -O0 nicht aktiviert ist. Für Verzögerungsschleifen nimmt man ohnehin besser die Makros aus <avr/delay.h> statt irgendwelcher Versuche, das mit einer einfachen for-Schleife zu tun. Die haben wenigstens den Vorteil, daß schon mal jemand durchgerechnet hat, wie lange ein Schleifendurchlauf braucht. (Mit -O0 stimmen die Angaben allerdings trotzdem nicht exakt, weil der Compiler dann die inline-Aufforderung ignoriert.) > Ich schicke Dir sehr gern das Programm. Es wäre nett, wenn Du mal > einen Blick draufwerfen künntest. Ich kann Dir nicht exakt beschreiben warum, aber irgendwie finde ich es von der Formatierung her sehr unübersichtlich und schwer zu lesen. Dadurch werde ich auch kaum irgendwelche Fehler sehen können. > Die while-Schleifen (unten markiert durch xxxxxxxxxxxxx ). Nimmt > man den Sprung zu blink(...) heraus, endet das Programm in der > if-Zeile, d.h. TWSR nicht ok. Unverständlich. Wenn Du mal gegen meinen Beispielcode vergleichst (den ich natürlich getestet habe und der im Wesentlichen auch nur aus der Atmel-Doku abgeschrieben ist), funktioniert die leere while-Schleife dort sehr wohl. > int main() > { > DDRC=252; /* Port 1 u.2.(TWI) naturbelassen, Rest Ausgänge */ > /* AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA */ > {led=119; k=99000 ; blink(k,led);} /* gn rt außen = 119*/ > start(); > main(); Hmm, meinst Du wirklich, daß es sinnvoll ist, aus main() heraus wieder main() aufzurufen? ;-)
Das Muesste Dir weiterhelfen ! http://www.avrfreaks.com/Tools/ToolFiles/376/install_config_WinAVR.pdf mfg Sebastian
>D. h. -O0? Das ist immer eine schlechte Idee. Nein, ist "naturbelassen", steht auf -O2. >Ich kann Dir nicht exakt beschreiben warum, aber irgendwie finde ich >es von der Formatierung her sehr unübersichtlich und schwer zu lesen. Stimmt genau, ist aber nur die erste Version auf dem Weg zu einer ordentlichen Struktur. Ich wollte bei schrittweiser Veränderung testen ob alles noch funktioniert und bin schon beim allerersten Schritt gescheitert. Zuvor war alles in einem Sück, wo es zwar funktionierte, aber nicht zur Weiterverwendung taugte. >Dadurch werde ich auch kaum irgendwelche Fehler sehen können. Nun enttäusche einen Anfänger nicht; wer, wenn nicht Du. > Wenn Du mal gegen meinen Beispielcode vergleichst >(den ich natürlich getestet habe und der im Wesentlichen auch nur aus >der Atmel-Doku abgeschrieben ist), funktioniert die leere >while-Schleife dort sehr wohl. Bei funktionierte die dritte Schleife ja auch. Ich werde Deinen Code nochmals genau durchsehen und ggf. übertragen. Aber findet Du an meinen while-Schleifen syntaktische Fehler? >Hmm, meinst Du wirklich, daß es sinnvoll ist, aus main() heraus wieder main() aufzurufen? ;-) Im Prinzip ja, damit man das Leuchten der LED's schön lange sieht, auch wenn sie nur kurz geschaltet werden. Zum Gebrauch des Programms muß der ganze Kram natürlich raus. Gruß Günther nospam.schubert@ine.fzk.de
>> Dadurch werde ich auch kaum irgendwelche Fehler sehen können. > Nun enttäusche einen Anfänger nicht; wer, wenn nicht Du. Mach's halblang, ich bin doch nicht Jesus. ;-) > Aber findet Du an meinen while-Schleifen syntaktische Fehler? Zumindest keine auf Anhieb offensichtlichen. >> Hmm, meinst Du wirklich, daß es sinnvoll ist, aus main() heraus >> wieder main() aufzurufen? ;-) >Im Prinzip ja, damit man das Leuchten der LED's schön lange sieht, >auch wenn sie nur kurz geschaltet werden. Trotzdem nicht: main() ruft ja wieder main() auf, das wieder main() aufruft... bis irgndwann Dein Stack übergelaufen ist. Nee, wenn Du die LEDs verzögern willst, nimm einen Timer.
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.