www.mikrocontroller.net

Forum: Compiler & IDEs GCC Tutorial


Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hübsch, wie doch Peters Aussage meiner gleicht... ;-)

Autor: Shazter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

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

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Shazter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ??

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Oryx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: tbrandner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!!!

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: QuadDash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: QuadDash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: QuadDash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

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

Bewertung
0 lesenswert
nicht lesenswert
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?ti...

Autor: Stephan Schwarz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Stephan Schwarz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
noch `n Bild

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stephan Schwarz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ ----

> 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.

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:)    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

Autor: Dominic Thomé (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ä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

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich rede von W9X und da denke ich dreht sich noch alles um die
autoexec.bat.
Ansonsten starte ich "Make" von PN aus.

Autor: QuadDash (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> (*) 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.

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stephan Schwarz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ups  hatte das Pic vergessen

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
------------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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

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.