Hallo allerseits Ich hab mir ein Testboard aufgebaut und will in die Programmierung von MCU`s einsteigen. Bascom läuft einwandfrei und ist ja auch leicht zu instalieren und zu bedienen ( mit der Anleitung von Roland Walter). Aber ich möchte eigentlich nicht in Basic programmieren, hab ich noch nie und will ich deshalb jetzt auch nichtmehr lernen. Ausserdem will ich meine c Kenntnisse vertiefen, also hab ich mir GCC gezogen. Aber da finde ich leider keine verständlich Anleitung zu wie ich mit der Softwar umgehen muss. Gibt es da ein Tutorial spezieel für GCC ( nicht für c )? Muss ich erst den Quellcode in einem Editor schreiben, und dann von GCC compelieren lassen, also wäre dann GCC ein reiner Compiler ? oder kann ich in GCC auch editieren?? Sorry ich blick echt nicht wie ich das Ding aunfassen soll. Die Infos unter AVR GCC hier auf der Seite sind auch etwas veraltet und nicht so recht infotmativ für den Einsteiger. Ansonsten ist die Site echt super hier!!!! Bis dann Stephan
Hallo Stephan Da sprichst Du ein heikles Thema an! Denn die Cracks wollen partout nicht verstehen, was denn eine IDE bringen soll. Aber besonders einem Anfänger würde dies die Arbeit erleichtern. Aber Du bist wohl wie ich, jung (erst 47) und MS-Windows "verseucht". Übrigens habe ich im englischen Forum gelesen, dass von den AVR-GCC Vätern an einer IDE gearbeitet wird; es soll aber noch einige Zeit beanspruchen. Hier nun einige Links: IDE aus CHINA die prima funktioniert (Shareware): http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm Tutorial, leider etwas älter (nicht immer die neuste Syntax): http://www.mikrocontroller.net/articles/c/Einleitung.htm Weiter gute Homepage's: http://homepage.sunrise.ch/mysunrise/pfleury/ http://www.kreatives-chaos.com/index.php?seite=avrgcc http://hubbard.engr.scu.edu/avr/avrlib/ http://www.avrside.fr.pl/index.php Gruss Toni
Na vielen Dank Toni Die links beinhalten ja schon mal einige Infos - vielleicht bekomme ich das GCC jetzt ans rennen. Hast schon recht, damit, das ich mich mit DOS schwer tue, die Klicks unter Windos finde ich da schon angenehemer. Die Links von dir sollten eigentlich gleich auf die Site hier eingebunde werden. Die fehlen hier einfach. So ich hab jetzt erstnal zutun!! Danke!!
"Denn die Cracks wollen partout nicht verstehen, was denn eine IDE bringen soll." Völlig falsch ! Die Cracks wollen nur nicht, daß der Compiler unlösbar mit einer IDE verheiratet wird. Du kannst also jede x-beliebige IDE Deiner Wahl nehmen und darin den Compiler aufrufen. Wie komfortabel das geht, hängt dann allein von der IDE ab, z.B. ob sie auch simulieren, debuggen usw. kann. Ich kann natürlich voll verstehen, daß die Cracks wesentlich mehr Arbeit in den Compiler reinstecken, als in Simulator, Debugger, Importfilter von Debuginformationen usw. Ein Fehler im Compiler ist ja wesentlich kritischer, als kleinere Unbequemlichkeiten beim Simulieren. Auch ist es mehr ein Hase und Igel Rennen, für jeden neuen AVR den Simulator immer wieder neu anpassen zu müssen, d.h. man verliert leicht die Lust. Peter
Toni schrieb: > Denn die Cracks wollen partout nicht verstehen, was denn eine IDE > bringen soll. Das stimmt überhaupt nicht (und würde ja auch Deiner unten gemachten Aussage über künftige Pläne für eine IDE bei WinAVR widersprechen, nicht wahr? ;-). ,,Die Cracks'' sehen nur nicht, warum jeder Compiler seine IDE mitbringen soll, und warum man zwangsweise beide miteinander verheiraten muß, d. h. Compiler XYZ läßt sich nur mit IDE VisualFooBar bedienen und sonst gar nicht. (Das ist ungefähr so, wie jedermann bei netwerkbasierten Kalenderlösungen auch gleich einen email-Server impliziert, obwohl beide miteinander ungefähr so viel zu tun haben wie ein Boot mit einem Auto: beide sind Fortbewegungsmittel, aber dann hören die Gemeinsamkeiten schon fast auf.) Das insbesondere angesichts der Tatsache, daß ,,die Cracks'' in der Regel allesamt bereits ihre ,,IDE'' haben (oder was glaubst Du, wie andere Leute Software entwickeln?). Allerdings wird die IDE dort in der Regel Editor genannt, hat Namen wie Emacs oder VIM (oder vielleicht auck KDevelop oder was auch sonst). Ein Compiler hat doch lediglich die Aufgabe, eine Datei in eine andere umzuwandeln -- und diese Funktionalität kann man praktisch beliebig irgendwo an den Editor anflanschen. Modularisierung heißt das Stichwort: wenn schon der Compiler in sich stark modular ist (sonst wäre er unmöglich in der Lage, so viele verschiedene Programmiersprachen für so viele verschiedene CPUs bei guter Codequalität/Optimierung/Standard- Konformität zu bedienen), warum kann dann nicht die IDE als Modul abgesetzt sein? Damit kann die Aufgabe auf viele Programmierer verteilt werden, und man kann deren unterschiedlicher Interessenlage gerecht werden. Der Vorteil dieser Lösungen liegt auf der Hand (und wird von den ewigen Rufern nach ,,der IDE, die dem AVR-GCC fehlt'' immer wieder genauso selbstverständlich ignoriert ;-): man hat einunddieselbe Entwicklungsumgebung für alles. Ich habe einmal gelernt (vor fast 15 Jahren), mit einem Emacs umzugehen (war damals noch schwieriger als heute, da grafische Oberflächen die Ausnahme waren), seither brauchte ich mich nie wieder umgewöhnen, egal ob es sich um professionelle Softwareentwicklung für ein CAD-System im Textibereich (auf DG-UX, einem Unix-Derivat, das heute wohl keiner mehr kennt), um Kernelhacking (einschließlich online-Debugging) für FreeBSD, um ,,gewöhnliche'' Anwendungssoftware für Unixe, um Assemblerprogrammierung für einen PIC (habe ich mal kurz gemacht, bin dann schreiend weggerannt), um GUI-Programmierung in Tcl/Tk (siehe Mfile) oder eben um Controllerprogrammierung in C für den AVR handelt. (Emacs gibt's auch für Windows, aber er ist vermutlich so windows-untypisch, daß ich ihn Dir keinesfalls empfehlen möchte. Andererseits -- für mich ist jeder durchschnittliche Windows-Editor popliger Spielkram, dem wesentliche Funktionalität fehlt, so daß mir ganz schnell die Haare zu Berge stehen.) > Übrigens habe ich im englischen Forum gelesen, dass von den AVR-GCC > Vätern an einer IDE gearbeitet wird; es soll aber noch einige Zeit > beanspruchen. Es gibt ,,die Väter von AVR-GCC'' so nicht. Was Du als AVR-GCC bezeichnest, ist eine Sammlung von Software so vieler Autoren, daß Du diese nicht in einen Topf werfen kannst. Viele derjenigen, die an dieser Software mitgearbeitet haben, wissen vermutlich nichtmal, was überhaupt ein AVR-Controller sein könnte, geschweige denn, daß ihr Werk auch Code für diese Teile erzeugen kann. ;-) Selbst wenn Du ,AVR-GCC' durch ,WinAVR' ersetzt, bist Du zwar der Realität schon ein wenig näher (es gibt dann praktisch nur noch einen Autor), aber immer noch nicht richtig: Eric Weddington stellt in WinAVR die entsprechenden Tools als Windows-Binaries zusammen, um all den Windows-Nutzer (und sich selbst ;-) einen Gefallen zu tun. In diesem Rahmen hat er eine recht enge Zusammenarbeit mit dem Autor von Programmer's Notepad 2 (PN2) entwickelt, bei der dieser Autor auch als Fernziel anvisiert, daß PN2 (das übrigens auch ein völlig allgemeiner Editor ist, also keineswegs ein AVR-GCC-spezifisches Teil! -- siehe oben halt) einmal eine möglichst vollständige IDE-Funktionalität aufweisen sollte. Bislang ist nach meinem (Windows-unkundigen) Verständnis PN2 aber schon recht gut geeignet, viele typische Aufgaben einer IDE wahrzunehmen, so daß es (außer dem bereits genannten URLs) für viele Nutzer offensichtlich durchaus brauchbar für diesen Zweck ist. Der einzige Punkt, der wirklich fehlt, ist die Generierung eines Makefiles (in anderen IDEs oft ,Projekt' genannt), und um diese Lücke rein für AVR-GCC-Nutzer zu stopfen, habe ich Mfile geschrieben: http://www.sax.de/~joerg/mfile/ Ansonten beweise ja die von Dir geposteten Links eindrucksvoll genug, daß man die IDE prima vom eigentlichen Compiler absetzen kann, und daß noch dazu je nach Geschmack für jeden etwas machbar sein sollte.
Hi, fuer einen Anfaenger waere eine IDE sehr hilfreich, weil es so doch sehr schwer verstaendlich ist. z.B. Makefile erstellen und debuggen und den AVR proggen. Eine gute (aktuelle) dt. Tutorial Seite fehlt leider auch :/. Das schlimmste aber an GCC ist das man seinen Quellcode nicht richtig debuggen kann. Zwar bietet AVR Studio diese Unterstuetzung an, aber es kommt doch vermehrt zufehlern (lokale Variablen). Eine eigene IDE wuerde dieses Problem mit Sicherheit minimieren und auch mehr Anfaenger uebereden mit GCC zuproggen. Mfg dirk
> fuer einen Anfaenger waere eine IDE sehr hilfreich, weil es so doch > sehr schwer verstaendlich ist. z.B. Makefile erstellen und debuggen > und den AVR proggen. (,proggen' -- was soll das sein? Gibt's in meinem Duden nicht.) Das alles hat absolut überhaupt nichts mit einer IDE zu tun. Hast Du denn meinen Beitrag überhaupt gelesen? Offenbar nicht. Gerade um die Lücke mit der Erstellung des Makefiles zu schließen, habe ich Mfile geschrieben. Was gefällt Dir daran nicht bzw. was fehlt Dir? Sag's mir, und ich werde sehen, ob ich das mit einbauen kann. (Nicht, daß ich denke, daß man auf Dauer um die Beschäftigung mit `make' herumkommt, aber ich denke, daß Mfile gut genug ist, daß man sich diese Aufgabe für später aufschieben kann.) Wenigstens ein Teil der verfügbaren IDEs (Emacs z. B. :-) kann mit dem GDB umgehen, so daß man einen Debugger hat. Ob Insight was taugt, vermag ich angesichts der funktionierenden Emacs-GDB-Kopplung leider nicht zu sagen, da ich aus diesem Grunde noch nie eine Veranlassung hatte, mir DDD oder Insight anzusehen. ;-) (Von DDD habe ich schon gehört, daß es gut sein soll, aber das hat wohl noch paar Schwierigkeiten, mit Windows klarzukommen.) Daß die Simulation die schwächste Seite der Opensource-Tools für den AVR ist, ist eine völlig unbestrittene Tatsache. Im Gegensatz zum GCC selbst ist die Simulation eben eine reine AVR-Angelegenheit, so daß nicht allzu viel manpower für diese Arbeit zur Verfügung steht. (Beim GCC profiert die AVR-Gemeinde zu großen Teilen einfach davon, daß dieser völlig unabhängig vom AVR von vielen Leuten weiterentwickelt wird.) Daher gibt es einen Simulator (simulavr), aber der hat besonders auf dem Gebiet der Peripherie nicht sehr viel zu bieten (der CPU-Core selbst ist dagegen implementiert). Aber s. o.: mit dem Vorhandensein oder einer Einbindung in eine IDE hat das alles nichts zu tun. Das Fehlen eines guten und umfassenden Opensource-Simulators für den AVR bringt es folglich auch mit sich, daß all die IDEs, deren Existenz Du hier schlicht wiedermal ignorierst, dennoch keine Simulation mit integrieren können. > Eine gute (aktuelle) dt. Tutorial Seite fehlt leider auch :/. Wenn sie keiner schreibt, wird es sie auch nie geben. Also: statt 20mal zu klagen, lieber einmal hinsetzen und eins schreiben. Ausreden (keine Ahnung, keine Zeit, keine Lust) zählen nicht. :) > Das schlimmste aber an GCC ist das man seinen Quellcode nicht > richtig debuggen kann. Warum kann ,,man'' das nicht? Ich kann. Einerseits mit simulavr + GDB (OK, mit den Einschränkungen von simulavr, aber letztlich wird jede Simulation bei IO ohnehin irgendwann an die Grenzen der Möglichkeiten stoßen, daß ist ein allgemeines Dilemma der Controller-Mimiken), oder mit JTAG ICE + AVaRICE + GDB. AVR Studio kommt für mich schon deshalb nicht in Frage, weil ich kein Windows habe. Nach dem, was ich gesehen habe, reicht dessen Debugger aber zumindest zur Zeit bei weitem nicht an die Fähigkeiten eines GDB heran, also brauch' ich dem Debugger kaum nachtrauern. Alternativ kann, wer eine gute IO-Simulation haben will, ja auch VMLAB nehmen. Kostet ein paar Euronen, dafür ist der IO-Teil wirklich gut (der Debugger ist leider nicht besser als der vom AVR Studio). Für die, die wie ich kein Windows haben, läuft das Teil außerdem noch einigermaßen im Wine-Windows-Emulator. > Eine eigene IDE wuerde dieses Problem mit Sicherheit minimieren ... Du weißt einfach nicht, wovon Du redest (sorry), siehe oben: IDEs gibt's genügend, aber an der Simulator-Front haben bisher dennoch nur erstaunlich wenige Mitstreiter mitgekämpft. Folglich ist der Simulations-Teil nach wie vor unterbelichtet.
Insight lief auf meinem Windows mit Cygwin das letzte Mal als ich es probiert habe sehr instabil (ist aber schon ca. 1 1/2 Jahre her), DDD leider gar nicht. Unter Linux verwende ich ausschließlich DDD, das ist um einiges besser als Insight, wenn es noch Syntax-Highlighting unterstützen würde wäre es perfekt. Wenn jemand ein deutschsprachiges AVR-GCC Tutorial anfangen möchte ist der beste Ort dafür wohl das Wiki (http://wiki.mikrocontroller.net).
Hi, "proggen = programmieren" sorry aber das ist jungdeutscher Slang. "Du weißt einfach nicht, wovon Du redest (sorry), siehe oben: IDEs gibt's genügend, aber an der Simulator-Front haben bisher dennoch nur erstaunlich wenige Mitstreiter mitgekämpft. Folglich ist der Simulations-Teil nach wie vor unterbelichtet." Ich weiss schon wovon ich rede , bloss fuer mich gehoeren folgende Sachen zur einer kompletten IDE: Editor , Compiler , Simulator. Als Vorbild sehe ich immer Bascom ... Ich kann leider nur von mir sprechen: Ich habe nur WinAVR gesaugt, installiert und stand dumm da. Ich glaube ich war einfach zu verwoehnt von Bascom-AVR (grafischer Aufbau, ein paar Klicks und schon war das erste Prg. fertig). Jetzt habe ich mir Ultra Edit 32 gedownloaded den Compiler mit eingebunden und bin sehr zufrieden damit. Da ich davor ein Projekt mit AVR Studio 4.08 und ASM erfolgreich geloest hatte und mir der Simulator sehr gut gefallen hat wollte ich AVR Studio auch als C Debugger nutzen. Das Programm Mfile habe ich wirklich uebersehen (sorry). "Wenn sie keiner schreibt, wird es sie auch nie geben. Also: statt 20mal zu klagen, lieber einmal hinsetzen und eins schreiben. Ausreden (keine Ahnung, keine Zeit, keine Lust) zählen nicht. :)" Doch eine Ausrede zaehlt, wenn man C Anfaenger ist sollte man kein Tutorial schreiben. Dieses sollte man erfahrende Menschen ueberlassen (wegen Fehlern). Zu GDB+Simulavr gibt es dazu ein kleines Tutorial? Mfg Dirk
Hallo Na da hab ich ja eine Diskussion losgetretten :-) aber das ganze scheint ja schon ein altes Thema zu sein. Ich bin jetzt soweit, das ich mir ein Programm aus einem Tutorial abgeschrieben hab und die Tool`s im PN2 eingerichtet habe. Bei dem versuch zu komeplieren (über make) erhalte ich aber folgende Meldung > Failed to create process: Der Vorgang wurde ausgeführt. > Process Exit Code: 0 Der Make file liegt im aktuellen Verzeichnis vor! Ich frag mich auch wie das PN den Compiler aufruft, da ich ja nirgendswo den Pfad zum AVR GGC angeben musste. ??
> Ich glaube ich war einfach zu verwoehnt von Bascom-AVR (grafischer > Aufbau, ein paar Klicks und schon war das erste Prg. fertig). Programmieren ist was anderes als das Zusammenklicken eines Klumpens von Quellcode. ;-) > Ich kann leider nur von mir sprechen: Ich habe nur WinAVR gesaugt, > installiert und stand dumm da. README und Doku gelesen? So schlecht kann das eigentlich gar nicht sein, viele sind durchaus mit PN2 zurechtgekommen -- mit der beiliegenden Anleitung. > Doch eine Ausrede zaehlt, wenn man C Anfaenger ist sollte man kein > Tutorial schreiben. Nein, gerade ein Anfänger ist viel besser tauglich dafür als jemand, der schon 15 Jahre lang C programmiert: ein Anfänger, der soeben all das hinter sich gebracht hat, weiß nämlich, an welchen Stellen er ins Stolpern gekommen ist und was der Ausweg war. Was rauskommt, wenn ich nach 20 Jahren Programmiererei auf allerlei Systemen eine Doku schreibe, siehst Du in der avr-libc Doku (OK, in den Teilen, die ich davon verfaßt habe): ich denke, es ist so schlecht nicht, ich hoffe, daß sie einigermaßen präzise ist, aber es taugt bestimmt eben nicht für einen Anfänger. Ich kann einfach nicht mehr sagen, was man einem Anfänger zuerst auf die Reise geben muß. Nee, wenn Ihr, die Ihr gerade beginnt, Euch mit der Materie zu beschäftigen und die Ihr die ersten Schritte getan habt, das nicht anfangt, ein solches Tutorial zu schreiben, sondern immer nur auf ,,jemand'' wartet, der es tut -- dann wird es nie. Wenn was fertig ist, andere darum zu bitten, es auf sachliche Richtigkeit zu prüfen, ist ein anderes Thema. Andreas' Angebot für das wiki steht ja: macht was draus. > Zu GDB+Simulavr gibt es dazu ein kleines Tutorial? Es gibt eine Doku, die nicht zu knapp ist. Kurzfassung: simulavr -g -d <Name des AVRs> & [Keine Ahnung, ob das cmd.exe eines aktuellen Windows das `&' für den Hintergrundprozeß versteht. Wenn nicht, dann für den simulavr und den avr-gdb zwei separate cmd.exe benutzen.] avr-gdb <Name der ELF-Datei> ... (avr-gdb) target remote :1212 (avr-gdb) break main (avr-gdb) continue Letzteres ist der pure GDB; wenn man Insight oder sowas verwendet, wird das vor dem Benutzer irgendwie durch das GUI verborgen. Da ich Insight nicht kenne, kann ich nicht sagen, was dort die äquivalenten Aktionen wären (insbesondere muß es was geben für das `target remote', um dem GDB mitzuteilen, daß das eigentliche Debugging woanders läuft als in seinem eigentlichen Prozeß). simulavr --help gibt in Kurzform alle Optionen aus.
> avr-gdb <Name der ELF-Datei> > ... > (avr-gdb) target remote :1212 > (avr-gdb) break main > (avr-gdb) continue Oh, nach dem target remote fehlt noch (avr-gdb) load `(avr-gdb)' ist dabei jeweils der GDB-Prompt, der Rest ist einzugeben. Alle Kommandos lassen sich weitgehend einkürzen, ich schreibe typischerweise also tar rem :1212 load b main c
Hi, was soll eine IDE bringen? Ich nutze den UltraEdit, den GCC für mehrere Controller (AVR, MSP430, Renesas H8). Als Versionsverwaltung CVS. Zum hübsch machen der Quellcodes Astyle. Zum Dateien vergleichen ExamDif. Wie soll das alles in eine Entwicklungsumgebung, die dann auch noch bei mehreren Controllern kompatibel sein soll? Desweiteren verwende ich ein Verzeichnis für alle obj-Dateien und eins für alle BAK-Dateien. Damit hat auch so manche IDE ein Problem. Der Sinn sind "saubere" Quellcodeverzeichnisse, ohne irgendwelche Hilfsdateien. Wenn man in die Programmierung von C/C++ einsteigen will, sehe ich kaum eine Chance, an make und ähnlichem vorbeizukommen. Das Compilieren über make ist zwar am Anfang schwierig, aber dafür ungemein flexibel. Bei der Softwareentwicklung ist der Quellcode die Wurzel allen übels. Dieser Quellcode wird die meiste Zeit mit dem Editor verarbeitet. Der Compiler ist nur ein "Hilfswerkzeug". Also muß der Editor zu einem passen. Ein Compilerhersteller wird aber immer den Compiler für wichtig halten, Der Editor läuft da mehr so nebenbei. Wenn eine neue Compilerversion gibt, will ich eigentlich nur den neuen Compiler haben. Das Einbinden von PN2 und den anderen Programmen in WINAVR mir fast schon zuviel. Aber so wie jetzt ist es noch ok. Fazit: Ich suche mir lieber die für mich passenden Tools zusammen und intergriere alles in den Editor meiner Wahl. Bei Updates ändert sich immer nur ein Tool. So hat man alles etwas besser unter Kontrolle. Ach ja, wie soll das debuggen und simulieren von einem Microcontroller in einer Steuerungshardware mit angeschlossenen Motoren und Sensoren funktionieren? Während ich im Einzelschritt rumeiere, läuft mein Motor gerade gegen den Endanschlag. Ups. Also noch viel Spass Oryx
Ich muss hier mal ein grosses Lob an Jörg aussprechen. Nicht nur wegen seiner Mitarbeit am gcc-Projekt, auch daß er sein Fachwissen immer ausfürhlich preisgibt und nicht gereizt reagiert. Also von meiner Seite mal ein grosses Danke für Deine Arbeit. Dominic
Stephan Schwarz schrieb: > Failed to create process: Der Vorgang wurde ausgeführt. Deutsche Fehlermeldungen sind doch immer wieder hübsch. :-) > Der Make file liegt im aktuellen Verzeichnis vor! Muß es, aber das ist natürlich (wie Du schon richtig erkannt hast) für das Auffinden des Tools make nebensächlich. Ganz offenbar scheitert genau das. > Ich frag mich auch wie das PN den Compiler aufruft, da ich ja > nirgendswo den Pfad zum AVR GGC angeben musste. ?? Soweit ich mich an Diskussionen in irgendwelchen Foren erinnern kann, fragt Dich doch der Installer von WinAVR, ob Du die nötigen Angaben in Deinen %PATH% mit aufgenommen haben möchtest, oder? (Oder er tut's automatisch, aber dann mußt Du bestimmt Windows nochmal booten, so wie ich Windows kenne...) Jedenfalls denke ich, daß Du genau dort den Finger drauf hast: irgendwie müssen die WinAVR-Verzeichnisse in Deinen PATH mit rein.
Dominic Thomé schrieb: > Nicht nur wegen seiner Mitarbeit am gcc-Projekt, auch daß er sein > Fachwissen immer ausfürhlich preisgibt und nicht gereizt reagiert. Naja, danke für die Blumen. :) Das mit dem nicht gereizt reagieren ist ganz einfach: wer sich zu dumm anstellt, seine Frage vernünftig zu formulieren, den ignoriere ich dann einfach. Damit muß ich nicht gereizt reagieren. ;-) Das fängt mit einem vernünftigen Namen an (das ist schließlich das erste, was man von einem Posting sieht, außerdem mag ich gern mit Personen diskutieren und nicht mit irgendwelchen Computern im Internet), wenn schon nicht Vor- und Nachname, dann wenigstens etwas, was wie ein Vorname aussieht. Wer ein sinnloses Synonym benutzt oder vielleicht meint, daß es besonders schick wäre, das Subject des Postings gleich noch als Namen mißbrauchen zu müssen, der rutscht im Scoring schon deutlich nach unten (sprich: damit ich mit ihm diskutiere, muß mich das Thema bereits deutlich mehr interessieren). Ansonsten gilt dasselbe, was auch im Usenet gilt: ein sinnvoll gestellte Frage, die das Problem konkret auf den Punkt bringt und auch zeigt, daß der Fragesteller bereit ist, seinen eigenen Teil zur Aufbereitung der Fragestellung zu leisten (einem also nicht nur sein ,,das geht nicht!'' im Ganzen und ohne weitere eigene Analyse vor die Füße wirft), wird mich viel eher zu einer Antwort verleiten als einfach nur durch die Gegend motzende Leute, die selbst das, was 5 Threads davor schon diskutiert worden ist, gleich nochmal fragen müssen, um ihre eigene Faulheit zu demonstrieren. ;-)
Hi, ich wollte niemanden zu nahe treten mit meinem Posting ... vielleicht waren meine Aeusserungen einfach zu inkompetent. Ich verspreche Besserung und werde mich weiter mit WinAvr auseinander setzen. Ich wollte mich auch nochmal bedanken fuer die Beschreibung vom GDB Tool. Mfg Dirk(Shazter)
hallo dirk, wenn du eine (nach meinen erfahrungen) eine ganze nette IDE suchst, dann schau dir auch mal eclipse an (www.eclipse.org). diese läuft unter java, und es gibt ein plugin für c-c++ editor. gruß, thomas
Hmmm ich steh leider immernoch vor meinen Problem! PN will einfach meinen Quellcode nicht compelieren. ( Fehlermeldung steht in einen vorigen schreiben) Ich hab WinAVR nochmal komplett neu installiert. (nach Deinstallation) Dabei hab ich dann auch nochmal drauf geachtet, dass die Einträge in der Auoexc.bat für den Suchpfad gemacht wurden. Es hat mich dabei gewundert, das meine Tolls in PN nach der Neuinstallation immernoch eingerichtet waren. Aber eigentlich war doch alles von der Platte geputzt? Also woran kann es noch liegen. Oder soll ich doch auf den Ultraedti umsteigen? oder besser noch zu Bascom zurückgehen? Kann das Problem evtl an AGR GCC liegen, denn hab ich mir noch garnicht angeschaut!!!!
Hmm, im Prinzip ist es doch einfach. Du solltest einfach erstmal das makefile, welches WinAVR beiliegt verwenden, im PN und Tools die entsprechenden Eintragungen vornehmen (siehe auch www.mc-project.de --> Tools) und schon wird auf Knopfdruck das aktuell geöffnete und im makefile angegebene *.c-file compiliert. Alex
Mach mal ein cmd.exe (oder command.com, falls Du noch ein MS-DOS-Derivat hast) auf (,,MS-DOS Eingabeaufforderung'' oder wie das heißt). Mit `set' solltest Du die aktuellen Einstellungen anzeigen können. Such mal (Explorer oder sowas) nach make.exe. Diese muß im PATH zu finden sein. Wenn nicht -> manuell nachtragen. Wo das gemacht wird, weißt Du besser als ich. Ist zwischen MS-DOS++ und WinNT++ meiner Meinung nach an unterschiedlichen Stellen. Ein `make' auf der Kommandozeile muß erstmal funktionieren, eher brauchst Du das nicht mit 'ner IDE probieren.
Wenn ich mich in unter der MS-Dos Eingabeaufforderung befinde und in das Verzeichnis mit dem Test1.c File wechsel kann ich make Ausführen. Da rattert dann einiges runter inkl. Fehlermeldung. Das ist aber wohl OK, da der Quellcode noch Fehler beinhaltet. Danach finde ich in dem Verzeichnis eine "Test1.d" also denke ich mal, das Make ansich funktioniert. In PN kann ich diese Datei dann über make clean wieder entfernen lassen. Alos funktioniert dieses Tool für mich auch. Und die der Eintrag "Target " im Makefile ist auch richtig. Der Pfad in der Autoexec muss ja auch richtig sein, da ich den Befehl "make" ja auch unter meinem Arbeitsverzeichnis ausführen kann. Nur PN schnalt einfach nicht was es mit Make machen soll. Der Fehler ist mit Sicherheit recht einfach nur das Finden ist das Problem. Mittlerweile würde ich auch sagen, dass das Ganze garnichtmehr so schwer ist. Mit den hier verlinkten Anleitungen, erscheint alles recht logisch. Wenn es denn dann mal funktioniert.
Hast Du auch bei command auf die zwei Punkte gedrückt und dann in das Verzeichnis gegeangen in dem Make liegt ? Ich glaube nicht. Mach doch mal einen Screenshot von Deinem Tool's Dialog.
Jörg schrieb: "Mach mal ein cmd.exe (oder command.com, falls Du noch ein MS-DOS-Derivat hast) auf (,,MS-DOS Eingabeaufforderung'' oder wie das heißt). Mit `set' solltest Du die aktuellen Einstellungen anzeigen können." Ehrlöich gesagt, weiss ich nicht geau, was ich da machen soll. cmd.exe sagt mir garnix, und wo soll ich die command.com ausführen? Und set? wo starte ich dass denn ? Sorry, aber da hab ich wohl wirklich nachholbedarf. Ich werde mal am Montag einen Screen shot machen oder am besten mehrere dann sehen wir weiter. Aber ich sehe dass doch richtig , das make Ansich doch wohl funktioniert- das Programm also auch compeliert wird. Naja schönes WE erstmal. Ich komm im Moment nicht an den Rechner, der steht in der Firma, deshalb ist wohl erstmal Pause angesagt
Wie nicht nur diese Diskussion hier zeigt, ist die Konfiguration der kompletten Toolchain zu kompliziert. Vielleicht kann Jörg den Wunsch nach einer vorkonfigurierten und integrierten Umgebung, die diese Arbeit abnimmt, nachvollziehen. Wieso sehen die "Cracks" eine IDE nicht als Option, die den Anfängern den Einstieg erleichtert? (Ich habe aus obigen Ausführungen (Jörg + Oryx) nicht die generelle Zustimmung zu diesem Punkt rauslesen können. Ich habe auch nicht gelesen: "Ack. Es muss sich nur jemand finden, der..."). Wenn die Ansprüche steigen, oder wenn die ersten Gehversuche erfolgreich (dank Voreinstellungen) verlaufen sind, kann jeder Benutzer selbst entscheiden, ob er auf gewohnten Editor usw. umstellen möchte. Die "Hemmschwelle"/Aufwand mehrere Tools installieren und konfigurieren zu müssen bevor das eigentliche Programmieren anfangen kann, ist für Anfänger und Einsteiger zu hoch. Gilt übrigens auch für Profis, die die Zeit dafür nicht haben. (Vor die Wahl gestellt: "Gleich loslegen und evtl. später an eigene Bedürfnisse anpassen" oder "erstmal einstellen und den Generierungsprozess verstehen müssen" wählen die meisten sicherlich a.). Bascom+Co könnten ohne mitgelieferte IDE komplett einpacken. ----, QuadDash - ebenfalls großer Fan von Jörgs Schreibstil und Beiträgen; sorry für das schlechte Wortspiel oben ;)
> cmd.exe sagt mir garnix, und wo soll ich die command.com ausführen? Hmm, Du solltest mal beginnen, Dein Windows kennenzulernen. :-) Ich benutze kein Windows (und möchte keins benutzen), aber zumindest die Namen der Kommandointerpreter kenne ich noch... command.com ist der Kommandointerpreter von MS-DOS. Seit Klickiwindows war der wohl dann unter dem Icon ,MS-DOS- Eingabeaufforderung' zugreifbar gemacht worden, außerdem kannst Du natürlich jederzeit die Kommandoeingabe öffnen (,,Starten...'' oder wie der Menüpunkt da unten heißt) und `command.com' eingeben. Win95/98/ME sind MS-DOS (mit einem ,,grafischen Betriebssystemaufsatz'' -- bis Win 3.11 hieß das noch ganz offiziell so), entsprechend heißt der Kommandointerpreter dort auch immer noch so und ist auch immer noch (fast) genauso primitiv, wie er schon zu MS-DOS 3.30-Zeiten war. WinNT/2k/... sind in der Tat in weiten Teilen eine Neuentwicklung, entsprechend haben sie auch einen neuen Kommandointerpreter. Dieser heißt cmd.exe, und er ähnelt einer Unix-Shell doch ein ganzes Stück mehr als das alte command.com. Versuch mal, unter den MS-DOS- Derivaten die Hilfe-Ausgabe des Kommandos `route' (damit kann man das IP-Routing einstellen) mit Bordmitteln zu lesen -- Du wirst immer nur die letzten 25 Zeilen lesen können, die Ausgabe ist aber um einiges länger. :( Unter cmd.exe (davon abgesehen, daß man dort auch den Scrollbuffer des Fensters dafür benutzen kann, was früher nicht ging) funktioniert die Unix-Variante: route 2>&1 | more Irgendein Spaßvogel bei Microsoft war allerdings nach wie vor der Meinung, man müsse das Icon ,MS-DOS-Eingabeaufforderung' dafür belegen (obwohl das Ding nun mit MS-DOS aber auch gar nichts mehr am Hut hat). Wenn ich mal an einem Windows bin, ist typischerweise die Eingabe von `cmd.exe' (unter Run...) das erste, was ich mache. ;-) OK, ist aber eigentlich nur Geschichte, im Prinzip hattest Du genau das ja schon gemacht. Ich vermute allerdings, daß Du irgendeine MS-DOS-Form von Windows hast und daß dort die Propagierung der PATH-Einstellung bei WinAVR nicht ordentlich funktioniert. Wenn ich das bei Dir richtig lese, funktioniert ja alles im command.com, nicht aber, wenn PN2 das `make' ausführen will. Sorry, aber diese alten Windowsen benutzt keiner mehr von den Entwicklern, auch bei Microsoft wird der Kram nicht mehr supportet. Wenn Du den Bug nicht gerade selbst suchen willst, wirst Du wohl am besten kommen, Dich mal nach was Neuerem umzusehen. (Eric Weddington benutzt Win2k für seine Entwicklungen, das dürfte also die am besten getestete Plattform sein.) Der Herr mit den vier Strichen, begreif doch mal, daß ,,die IDE'' an alldem nichts helfen würde: PN2 gibt sich ja schon Mühe, eine solche zu sein, aber hier stolpert irgendwas über viel tiefer sitzende Dinge, da würde auch eine andere IDE keine Abhilfe bringen -- auch sie würde letztlich nur das make.exe nicht ausführen können. Sie könnte vielleicht eine geilere Fehlermeldung draus machen, aber wäre damit jemandem wirklich geholfen? Ansonsten nochmal: wer eine IDE will, soll doch bitte eine der vorhandenen benutzen. Die URLs sind doch bereits kursiert. Gerade das polnische Teil hat nach dem, was ich so gelesen habe, keine schlechten Kritiken bekommen (und der Autor liest zumindest regelmäßig bei avrfreaks.net mit und fällt durch kompetente Antworten dort auf -- ich traue ihm daher durchaus eine ordentliche WinAVR-Einbindung zu).
> wer eine IDE will, soll doch bitte eine der vorhandenen benutzen. Und wer stellt "mir" diese ein, damit ich nur noch das Icon anklicken muß, das die ganze Maschinerie im Hintergrund anwirft? "Ich" bin nicht mal wählerisch und würde irgendeine voreingestellte IDE verwenden. Jörg, und genau das gibts nicht und deswegen scheitern die meisten am AVR-GCC. Deine Aussage (sinngemäß) "machs doch selbst" geht am Einsteiger vorbei - er ist de facto überfordert (und landet bei den Kommerzcompilern, die das bieten). > stolpert irgendwas über viel tiefer sitzende Dinge, da würde auch eine andere IDE keine Abhilfe bringen Das sollte aber die Aufgabe dieser IDE sein - nämlich solche Dinge vorm Benutzer verstecken, bzw. ihm abnehmen, daß er keine formalen oder typischen Leichtsinnsfehler mehr machen kann. Punkte, die die IDE übernehmen könnte (z.B.): - Projektverwaltung (makefile erstellen - a la mfile) - Parametereinstellungen für Compiler/Linker mit Kommentaren/Hilfetexten über Dialogfelder dem Benutzer präsentieren - nie mehr Formatierungsfehler in irgendwelchen Konfigdateien... (white spaces, tabs, usw.) - weitere Komfortfunktionen (z.B. automatisch die Speicherausnutzung darstellen, usw.) ... Einzeln gibts das natürlich alles - auch alles herrlich über Kommandozeile und Scriptsprachen benutzbar - aber noch nicht wirklich im Dialog mit dem Benutzer und als fertiges Installationspaket. Bascom& Co kanns doch auch. ----, (QuadDash).
> Und wer stellt "mir" diese ein, damit ich nur noch das Icon > anklicken muß, das die ganze Maschinerie im Hintergrund anwirft? Hast Du die vorhandenen denn mal ausprobiert? Sorry, wenn sie nicht gehen, mußt Du deren Autoren einfach nerven. OK, bei AtmanAVR hast Du zumindest das moralische Recht dazu, da es kommerziell ist. > ...und deswegen scheitern die meisten am AVR-GCC. Hmm, dafür, daß Deiner Meinung nach ,,die meisten'' daran scheitern, sind es ganz offenbar immer noch sehr viele, die mit AVR-GCC sehr ordentlich zurechtkommen. ;-) Ansonsten hätten wir dieses Forum hier nicht... (und es wird ja keinesfalls nur über ,,geht beim mir aber alles gar nicht'' hier diskutiert). >> stolpert irgendwas über viel tiefer sitzende Dinge, da würde auch >> eine andere IDE keine Abhilfe bringen > Das sollte aber die Aufgabe dieser IDE sein - nämlich solche Dinge > vorm Benutzer verstecken, bzw. ihm abnehmen, daß er keine formalen > oder typischen Leichtsinnsfehler mehr machen kann. Ganz offensichtlich funktioniert dies aber nicht für jede beliebige schrottige (sorry) steinalte Windows-Installation, die es auf der Erde gibt. Andernfalls hätte Stephan nicht die von ihm beschriebenen Probleme. Es ist immer so schön einfach sich hinzustellen und ,,jemand müßte doch mal ... machen'' zu sagen. Wenn's um konkrete Mitarbeit geht, wird dann das Echo schon recht mager, und gerade wenn es darum geht, den ganzen Krempel vernünftig auf Klickibunti zu integrieren, dann brauchst Du schon nicht mal mehr die Finger einer Hand, um die Freiwilligen zu zählen, die aus Spaß an der Freude (das ist halt wesentliche Motivation für Opensource) an sowas arbeiten wollen. Eric Weddington steht da fast allein auf weiter Flur, Colin O'Flynn wohl noch, noch ein dritter, das war's dann. Das hat durchaus auch damit zu tun, daß die Windows-Plattform einfach ätzend ist, wenn man dafür irgendwas selbst bauen will -- es macht über kurz oder lang einfach keinen Spaß mehr, ständig gegen Windows zu kämpfen, damit ist der Motivatiosfaktor #1 für Opensource-Programmierer weg: es muß Spaß machen. Das ist nach meinem Dafürhalten der wesentliche Grund, warum es in diesem Bereich beinahe nur kommerzielle Software gibt (und sei's Shareware, siehe AtmanAVR). Du kannst das beklagen und bejammern -- solange nicht engagierte Windows-versierte Entwickler daherkommen, die daran auch noch Spaß haben, wird sich an diesem Zustand kaum was ändern. Sorry, ich mache selbst um jedes Windows einen großen Bogen, weil ich weiß, wie gruselig das alles ist. Schon genug, daß ich auf Arbeit hin und wieder nicht drumrumkomme, eins zu benutzen, aber meine wertvolle Freizeit werde ich keiner Rotberg-Software zum Opfer hinwerfen.
Es ging mir nicht pro oder contra Windows zu diskutieren.
Es ging mir nicht darum, daß "mir" jemand die Arbeit machen muß und
ich nur jammern wollte.
Sondern es ging mir darum, die Ursache für den schwierigen Einstieg und
eine prinzipielle Lösungsmöglichkeit dafür zu diskutieren.
> sind es ganz offenbar immer noch sehr viele, die mit AVR-GCC sehr
ordentlich zurechtkommen. ;-)
Was ist mit den thkaisers, Peter Daneggern usw. die ich hier als sehr
kompetent einschätze, die aber dennoch (nach eigenen Aussagen, bzw.
ihren Beschreibungen) Probleme beim Einstieg haben.
Nebenbei bemerkt: Ich unterstelle mal, daß die allermeisten, die an der
Installation scheitern, sich hier nicht im Forum melden, weil sie
keinen Grund für das Scheitern ausmachen können und auch keine
spezielle, gezielte Frage dazu stellen können (es gibt zu viele neue
Parameter/"Dinge", die durchschaut werden müssen, bevor der erste
Compilerdurchlauf gelingt; Kommandozeile, Konfigdateien, WinUmgebung,
Editorintegration, kein Durchblick, daß Präproz., Compiler, Linker nix
miteinander zu tun haben...).
"Habs installiert, geht aber nicht." zu fragen traut sich zum Glück
keiner. Aber die ständige Forderung nach einem "GCC-Tutorial"
beweist, das hier noch Bedarf besteht (aber ich wiederhole mich).
----, (QuadDash).
Wenn keiner ein Tutorial schreibt, dann gibt es keines. So einfach ist das. Wenn jeder der Einsteiger die hier nach einem Tutorial gefragt haben und dann doch irgendwie zurechtgekommen sind ein paar Zeilen zur Anleitung geschrieben hätte, dann... aber irgendwie erwartet das jeder nur von "den anderen". Und ich muss Jörg auch in diesem Punkt zustimmen: niemand ist so gut geeignet ein Tutorial zu schreiben, wie jemand der gerade erst selber den Einstieg geschafft hat, da er noch genau weiß an welchen Stellen die Probleme liegen. Ich glaube keiner der Leute die seit Jahren GCC verwenden hätte daran gedacht in einem Tutorial auf eine Frage wie "wo muss ich die Befehle denn eingeben" einzugehen. Falls doch mal jemand den Anfang machen möchte: http://wiki.mikrocontroller.net/wiki/wiki.phtml?title=AVR-GCC_Tutorial&action=edit
Angehängte Dateien:
-
Autoexec.jpg
89 KB
So neue Woche , neues Glück Ich geb mich ja noch nicht geschlagen und bin sogar schon am überlegen, ob ich so eine Einleitung für so Dummies wie mich später mal erstellen soll. Aber evtl. reichen ja auch die Anleitungen, die bereits existieren - aber das wird sich ja noch zeigen. Ich hab nun mal ein paar screenshots gemacht um das ganze besser zu dokumentieren. Evtl. zeigt sich ja für euch etwas, auf dem Bildschirm, was nicht stimmt. Also Fehlersuchbilder mal anders :-)
Hallo Stephan!
>Das ist aber wohl OK, da der Quellcode noch Fehler beinhaltet.
Der allererste Schritt wäre doch dann, ein ganz einfaches Programm (aka
"Hello World") zu schreiben. Eins, in dem Du wirklich sicher bist,
daß keine Fehler drin sind!
Damit gehst Du dann schrittweise vorwärts, bis Deine Umgebung
reibungslos läuft. Danach spielst Du das "Hello World" auf den
Controller und schaust, daß es auch da ordentlich und ohne Fehler
läuft!
Erst nachdem das alles Einwandfrei funktioniert solltest Du mit
größeren Projekten/Programmen arbeiten.
Gruß,
Patrick...
Angehängte Dateien:
-
Tools.jpg
68 KB
letztes Bild Sorry, aber es geht wohl nur ein File pro posting. Aber feine Sache mit den Anhängen in anderen Foren ist das immer schwierig, etwas zu übermitteln.
Ich habe kein Windows und kenn folglich PN2 auch nicht, aber ein Kommando "make all" und dazu den Parameter "all", das scheint mir nicht das zu sein, was Du willst. Ich würde sagen, das Kommando heißt immer nur "make", die Parameter sind dann "all", "clean", ggf. auch "extcoff" oder "program".
@ ---- > Was ist mit den thkaisers, Peter Daneggern usw. die ich hier als > sehr kompetent einschätze, die aber dennoch (nach eigenen Aussagen, > bzw. ihren Beschreibungen) Probleme beim Einstieg haben. thkaiser sagt mir nichts. Peter Danegger hat das Programmieren von Computern erlernt, als an den seriellen Schnittstellen noch Drucker und Terminals angeschlossen waren statt irgendwelcher Nagetiere :-)... Kann ja sein, daß sein Wissen oft sehr C51-lastig ist, aber daß er den Umgang mit einem beliebigen Compiler nicht beherrschen würde (*), solltest Du ihm wohl besser nicht unterstellen. (*) D. h. dessen Aufruf über eine beliebige Form von Kommandozeile, sei es nun der CCP (CP/M), command.com (MS-DOS), cmd.exe (WinNT), vielleicht auch CLI (RSX-11, VMS?), sh (Unix) oder wie auch immer sie alle heißen.
:) dafür geb ich mal ein ( VB ) virtuelles Bier aus. Natürlich heist der Befehl nur "make" und der Parameter je nach Bedarf. Ich hab mich auch schon gewundert, als ich das so abgetippt habe. Aber ,da hab ich es mal so geglaubt, denn wenn einer sowas im Internet veröffentlich, sollte es auch Richtig sein. Also nun wird auch compeliert was das Zeug hält. Mal schauen, ob ich jetzt Hello World hinbekomme und dann kann es endlich losgehen. Also lag es doch nicht an WINDOWS :-) . sonst wäre meine heile Welt auch zerstört worden *gggggggg
Ähm sag mal, ich war jetzt etwas faul das alles durchzulsesen aber : Rufst Du Dein Make nun aus der cmd auf oder aus dem PN ? Du weisst, das die Autoexec.bat nur geladen wird wenn Du eine DOS-Box aufmachst ? Der Pfad, damit Du den Gerümpel in Deinem Windowspfad drin hast wird unter eigentschaften des Arbeitsplatzes festgelegt. Dominic
Ich rede von W9X und da denke ich dreht sich noch alles um die autoexec.bat. Ansonsten starte ich "Make" von PN aus.
@Jörg:
> [Peter Danegger] ... aber daß er den Umgang mit einem beliebigen
Compiler nicht beherrschen würde (*), solltest Du ihm wohl besser nicht
unterstellen.
Ich unterstelle nix, sondern nehme seine pragmatische Art (*) als
"Beweis" für meine These (Alles zu kompliziert und nicht
(auto)konfiguriert).
(*) Peter hat schon öfters hier erzählt, daß er statt makefile ein
batchfile einsetzt...
Und jetzt kommt meine Interpretation: obwohl ihm klar bewusst ist, daß
die makefile-Variante Vorteile hätte, die es ihm aber nicht wert sind
auch einzusetzen, da zu aufwendig.
Um meine ganze Schreiberei nochmal auf einen Punkt zu bringen:
1. Würdest du mir zustimmen, daß es deutlich einfacher wäre, wenn es
eine IDE (so wie ich oben ausgeführt habe), als benutzbare Option für
die Einsteiger gäbe.
2. Die Erstellung einer solchen IDE ist keine unlösbare Aufgabe, die an
praktischen Grenzen irgendwo scheitern könnte, sondern muß "nur" von
jemanden in Angriff genommen werden, oder siehst du das prinzipiell
anders?
----, (QuadDash).
> (*) Peter hat schon öfters hier erzählt, daß er statt makefile ein > batchfile einsetzt... Das ist richtig. Damit kennt er sich einfach mal besser aus, für heutige Compilergeschwindigkeiten ist der Vorteil eines `make' ohnehin eher marginal, so daß es Geschmackssache ist, ob man make oder einen Script übersichtlicher findet. > 1. Würdest du mir zustimmen, daß es deutlich einfacher wäre, wenn es > eine IDE (so wie ich oben ausgeführt habe), als benutzbare _Option_ > für die Einsteiger gäbe. Kann ich Dir nicht. :-) Ich kann nur mutmaßen, daß dem so wäre, aber für mich wäre eine IDE, die nicht `Emacs' heißt, in jedem Falle deutlich umständlicher. Als benutzbare Option gibt's das doch aber alles schon. Sowohl AtmanAVR als auch AvrSide waren genannt worden, und PN2 will ja offenbar auch mal eine werden. Insofern versteh' ich das ganze Theater langsam nicht mehr.
So nun proggen, wiekommt das schreiben, oder es im Jugendslang heist. Den Programieradapter den ich eigentlich für Bascom benutzt hab, wollte ich auch hier zum Einsatz bringen? erstmal die Frage, ist das möglich. AVRdude scheint ja mit einige Adaptern zu arbeiten. Unteranderem kann ich da auch einen Bascom Adapter beim Aufruf anwählen. Ist dieser Bascom Adapter dann der selbe wie der den ich schon habe? Ich hab mal ein Bild von www.rowalt.de hinzugefügt. In der Kombination funktioniert aber die Kommunikation noch nicht. Fehlermeldung: """"""""""""""""""""""""""""""""""""""""""""" vrdude -p at90s2313 -P lpt1 -c bascom -U flash:w:ledanaus.hex avrdude: initializatio avrdude: AVR device not respondingn failed, rc=-1 Double check connections and try again, or use -F to override this check. avrdude done. Thank you. make: *** [program] Error 1 > Process Exit Code: 2 """""""""""""""""""""""""""""""""""""""""""""" oder sollte ich mir besser einen ISP Adapter basteln, der scheint ja recht gängig zusein?
Na komm, sei mal nicht so faul. Guck einfach ins avrdude.conf rein, wie die dort angegebenen Programmieradapter verdrahtet sind. Man kann diese Datei doch wirklich ganz simpel mit dem Texteditor öffnen, und zumindest dieser Teil davon ist wahrhaftig selbstdokumentierend. > oder sollte ich mir besser einen ISP Adapter basteln, ... Das sind alles ISP-Adapter. ISP = in-system programming, damit wird (beim AVR) die Programmiermethode über MOSI/MISO/SCK bezeichnet. Ansonsten: füge ein paar -v Optionen dazu, dann siehst Du, ob sich auf dem Draht überhaupt was tut, oder ob da nur immer 0xFF zurückkommt.
------------Na komm, sei mal nicht so faul.------------ tzzztzzz Dabei gebe ich mir doch schon Mühe. aber der AVRdude.conf File hilft natürlich schon weiter. Nun kann ich auch schreiben. Ich hab also eine SP 12 Adapter. Muss man nur wissen , das da ein solcher File existiert. Aber das steht bestimmt auch in irgendeinem Manual. Die Maunals sind ja meist in englisch gehalten, womit ich mich etwas schwer tue. Na Ich danke nochmal dem Joerg und allen anderen, die mir geholfen haben. Fürs erste bin ich jetzt versorgt. Aber ich komme bestimmt wieder keine Frage! denn da werden noch viele Fragen folgen.
> aber der AVRdude.conf File hilft natürlich schon weiter. Nun kann > ich auch schreiben. Ich hab also eine SP 12 Adapter. Wußt ich doch, daß Du das dort selbst am schnellsten findest. ;-) > Aber das steht bestimmt auch in irgendeinem Manual. Na klar. :-) > Die Maunals sind ja meist in englisch gehalten, womit ich mich etwas > schwer tue. Du wirst da wohl insgesamt bei diesem Thema nicht umhinkommen. Du findest vielleicht paar deutsche Einführungen zum Thema, im FUNKAMATEUR ist vor einiger Zeit auch eine (allerdings Bascom-zentrische) Beitragsfolge zu AVRs veröffentlich worden, aber letztlich ist diese Welt zu klein (besonders bei einem nicht allgemein interessierenden Thema wie Microcontrollern, die nur einen speziellen Nutzerkreis haben), als daß man das jedesmal in X verschiedenen Sprachen überhaupt gehandhabt bekommt. Mal ehrlich, wir sind froh, überhaupt eine einigermaßen aktuelle Version der avr-libc Dokumentation zu haben, jetzt noch nach Übersetzern für verschiedene Sprachen zu suchen, wäre wohl vergeblich. Außerdem hast Du das Problem ja spätestens wieder bei den Datenblättern, und deren Studium ist schlicht unumgänglich (ganz besonders bei AVR, da sich dort von Controller zu Controller doch kleine aber feine Unterschiede einschleichen).
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.