Hallo, ich wurde gerne ein AVR (z.B. Atmega328) mit einem AVRSPmkii unter Linux programmieren, leider habe keine Ahnung wie man anfangen kann, bzw ich bin ein Windows Nutzer der umsteigen möchte. Kennt jemand ein gutes Tutorial wo man von NULL afangen kann? Linux Mint habe bereits installiert. Danke im Voraus
Hallo Rosberg 1) Eine C(++) IDE deiner Wahl installieren. Ich selbst benutze KDevelop. Netbeans oder Eclipse geht aber auch. Wenns unbequem sein darf, reicht natuerlich auch ein einfacher Texteditor... Mittlerweile gibt es auch gute IDEs die im Browser laufen und keiner Installation bedarfen, z.B. Cloud9 ( http://matrixstorm.com/avr/avrstick/#bideavr ). 2) Toolchain installieren. Entweder ueber deinen Paketmanager (meist sind da die Versionen aber etwas aelter), oder mittels http://matrixstorm.com/avr/tinyusbboard/#asmorc_linux Die AVR Toolchain enthaelt alle Programme die notwendig sind um aus Quellcode den AVR Binaercode zu "generieren". 3) Ein Tool um den AVR Binaercode in den Chip zu transportieren - ueblicherweise AVRDUDE (der spricht auch AVRMKII). Hier wieder entweder aus deinem Paketbaum, oder von http://download.savannah.gnu.org/releases/avrdude/ MfG
Hallo Rosberg, hallo Stephan, Stephan B. schrieb: > 1) Eine C(++) IDE deiner Wahl installieren. Ich selbst benutze KDevelop. > Netbeans oder Eclipse geht aber auch. Wenns unbequem sein darf, reicht > natuerlich auch ein einfacher Texteditor... unter Linux / UNIX gibt es eine Menge Editoren, auf die die Bezeichnung "einfacher Texteditor" nicht so richtig zutrifft. Mein Favorit ist der GNU/Emacs, der über einen Texteditor deutlich hinausgeht und sicherlich alles andere als einfach, sondern ein sehr mächtiges Werkzeug ist -- manche sprechen von "Gottes eigenem Editor mit eingebautem Betriebssystem und eigener Programmiersprache", was dem Ganzen schon recht nahe kommt. Dieses ganze IDE-Gefumsel habe ich immer mal wieder ausprobiert und jedes Mal wieder gelöscht. Dabei bräuchte ich dann für jede meiner Sprachen eine eigene IDE mit etlichen Anzeigebereichen und Unterfensterchen, die mir letztlich doch nur den Blick auf das Wesentliche versperren -- nämlich meinen Code. Obendrein bräuchte ich aber immer noch einen Texeditor, um LaTeX, Javascript und CSS zu schreiben. Außerdem scheue ich mich, so viel von meiner ganzen schönen Rechenleistung und Darstellungsfläche für Dinge zu verschwenden, die ich nur für einen Bruchteil meiner Zeit brauche. Man glaubt es kaum, aber ein leistungsstarker Editor wie Emacs oder vi(m) sowie eine Shell reichen zur Bedienung einer Entwicklungs-Toolchain völlig aus und sind, wenn man sie beherrscht, tausendmal schneller, flexibler und sogar komfortabler als eine oder gar mehere IDEs. Das gilt insbesondere dann, wenn die Integration eines Teils des Entwicklungsprozesses -- hier: des Debugging -- in die IDE ohnehin nicht geht, weil für eine andere Zielplattform crosskompiliert wird. Mir persönlich fällt nur ein einziger Bereich in der Entwicklung ein, in dem eine IDE nützlich und sinnvoll ist, nämlich bei der Entwicklung von GUIs, wo man sich die Komponenten komfortabel zusammenklicken kann. Ich möchte keinen Glaubenskrieg pro oder contra IDEs vom Zaun brechen, aber nur darauf hinweisen: es geht auch ohne, ganz prima sogar. > 2) Toolchain installieren. Entweder ueber deinen Paketmanager (meist > sind da die Versionen aber etwas aelter), oder mittels > http://matrixstorm.com/avr/tinyusbboard/#asmorc_linux > > Die AVR Toolchain enthaelt alle Programme die notwendig sind um aus > Quellcode den AVR Binaercode zu "generieren". > > 3) Ein Tool um den AVR Binaercode in den Chip zu transportieren - > ueblicherweise AVRDUDE (der spricht auch AVRMKII). Hier wieder entweder > aus deinem Paketbaum, oder von > http://download.savannah.gnu.org/releases/avrdude/ Linux-Mint ist IIRC ein Ubuntu-Derivat. Da sollte sich die gesamte AVR-Toolchain mit "apt-get install gcc-avr binutils-avr gdb-avr avdude avrdude-doc" in einem Rutsch installieren lassen, ggf. dazu noch simulavr. HTH, Karl
Hallo Rosberg, hier wären deine evtl. unter Windows erworbenen Vorkenntnisse hilfreich. Hast du unter Windows schon AVRs oder andere µC programmiert, wenn ja mit welchen Tools? Evtl. gibt es diese oder sehr ähnliche auch für Linux, dann würde dir der Umstieg leichter fallen. Eclipse als IDE bietet z.B. ein AVR-Plugin, um mit Hilfe der AVR-Toolchain zu compilieren und den AVR zu programmieren. Wenn du Eclipse von Windows her schon kennst, kannst du das unter Linux genauso verwenden. Gruß Markus
Karl Käfer schrieb: > Dieses ganze IDE-Gefumsel habe ich immer mal wieder ausprobiert und > jedes Mal wieder gelöscht. Ich habs nicht jedes Mal wieder gelöscht, aber doch fast jedes Mal. Das heißt, ich kann dir zwar nicht zu 100 % zustimmen, aber zu 80 %. :-) Ein einfacher und - soweit ich weiß - vom Syntax her mit dem Atmel-Original weitgehend kompatibler Assembler ist AVRA. Den verwende ich immer, wenn ich mal eben ein kleines AVR-Programm erstelle.
1 | avra xyz.asm |
erzeugt automatisch xyz.hex. Ohne viel Schnickschnack. Avra als Binary hab ich vor längerer Zeit hier hochgeladen: http://guloshop.de/f/avr/ Für einfache C-Programme ist das hier mein Favorit: C ohne Makefile
:
Bearbeitet durch User
Hallo, vielen Dank für eure Beiträge. Markus schrieb: > hier wären deine evtl. unter Windows erworbenen Vorkenntnisse hilfreich. > > Hast du unter Windows schon AVRs oder andere µC programmiert, wenn ja > mit welchen Tools? Ja, ich habe schon ein wenig Erfahrung mit AVRs in C mit WINAVR + AVRDUDE. Momentan kämpfe ich mit dem frisch installiertes Linux, irgendwas ist eventuell beim installation schief gelaufen da Linux von ein Moment auf der andere einfriert und nicht mehr reagiert und muss jedes Mal wieder neu Starten.
Vielleicht hätte ich als erstes fragen müssen was für ein Linux installieren muss.
Markus Weber schrieb: > Ein einfacher und - soweit ich weiß - vom Syntax her mit dem > Atmel-Original weitgehend kompatibler Assembler ist AVRA. Aber auch nur mit der Syntax der ersten Assemblerversion. Irgendwann hatte Atmel dann nochmal nachgelegt. > erzeugt automatisch xyz.hex. Ohne viel Schnickschnack. Und ohne Debuginformationen. ;-) Hexfiles braucht man inzwischen eigentlich nicht mehr, aktuelle Tools können alle ELF direkt lesen.
Hallo, ich komme leider nicht wieter, Linux einfriert und reagiert nicht mehr, ich glaube fange wieder von Vorne an und installiere Linux noch Mal. Frage: Ich habe hier eine Version "Ubuntu 9.04 Desktop Edition DVD", kann man damit was anfangen? Version installieren und aktualisieren? oder besser aktuelle Version runterladen?
Rosberg schrieb: > ich komme leider nicht wieter, Linux einfriert und reagiert nicht mehr, > ich glaube fange wieder von Vorne an und installiere Linux noch Mal. Vielleicht solltest du ja erstmal den Memtest drüber laufen lassen? > Ich habe hier eine Version "Ubuntu 9.04 Desktop Edition DVD", kann man > damit was anfangen? Ist natürlich schon mächtig angestaubt. Ich würde an deiner Stelle nicht unter Version 12.04 anfangen.
Jörg Wunsch schrieb: > Vielleicht solltest du ja erstmal den Memtest drüber laufen lassen? Habe auch gedacht, glaube ich hatte mal mit Windows früher Mal gehabt. Jörg Wunsch schrieb: > Ist natürlich schon mächtig angestaubt. Ich würde an deiner Stelle > nicht unter Version 12.04 anfangen. Alles klar.
Karl Käfer schrieb: > Man glaubt es kaum, aber ein leistungsstarker Editor wie Emacs oder > vi(m) sowie eine Shell reichen zur Bedienung einer > Entwicklungs-Toolchain völlig aus und sind, wenn man sie beherrscht, > tausendmal schneller, flexibler und sogar komfortabler als eine oder gar > mehere IDEs.... Das mag ja alles sein und für dich Puristen so passend sein. Aber es mangelt da schon an einer brauchbaren Dokumentation oder einem ausführlichen Tutorial. Selbst wenn man bereit wäre, für entsprechende Literatur zu zahlen. Es gibt einfach nichts gescheites. Das beste, was ich bisher gefunden habe ist ftp://ftp.fernuni-hagen.de/pub/pdf/urz-broschueren/broschueren/a028.pdf Was kannst du als weiterführende Literatur empfehlen?
Rosberg schrieb: > Ich habe hier eine Version "Ubuntu 9.04 Desktop Edition DVD", kann man > damit was anfangen? Version installieren und aktualisieren? oder besser > aktuelle Version runterladen? Wenn dann eine aktuelle Version. OpenSUSE 13.1 ist auch sehr angenehm.
kopfkratz Also wenn Du von Windows auf Linux umsteigen willst, dann schaue Dir mal diverse Distris an und nimm die die Dir am meisten gefällt. Schau mal da durch: https://www.linux.com/directory/Distributions http://distrowatch.com/ Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. heranzugehen. Welche IDE Du nimmst oder ob Du EMACS in LISP anpaßt ist Deine Entscheidung. Wichtig ist das der GCC als Crosscompiler für AVR funktioniert und Du ein Programm für Deinen Progger hast (avrdude wurde ja schon genannt). Erstmal mit dem neuen Betriebssystem vertraut machen, läßt sich ja ohne Probleme parallel zu Windows installieren. Dann, wenn Du es bedienen kannst nach für Dich passenden Tools für die AVR Entwicklung suchen und austesten. Das nehmen mit dem Du persönlich am besten klarkommst und gut ist ;-)
kopfkratzer schrieb: > Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in > den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. > heranzugehen. Ganz ehrlich: das ist nun wirklich keine Voraussetzung mehr heutzutage. Im Gegenteil, wenn man den normalen Weg geht, wird der Kernel relativ regelmäßig automatisch (zusammen mit den anderen Updates) aktualisiert, da ist ein custom kernel eher im Weg. > Wichtig ist das der GCC als Crosscompiler für AVR funktioniert und Du > ein Programm für Deinen Progger hast (avrdude wurde ja schon genannt). Ja, aber für beides muss man gewiss nicht in der Lage sein, einen Linux-Kernel zu bauen.
Jörg Wunsch schrieb: > kopfkratzer schrieb: > >> Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in >> den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. >> heranzugehen. > > Ganz ehrlich: das ist nun wirklich keine Voraussetzung mehr heutzutage. > Im Gegenteil, wenn man den normalen Weg geht, wird der Kernel relativ > regelmäßig automatisch (zusammen mit den anderen Updates) aktualisiert, > da ist ein custom kernel eher im Weg. Er soll sich erstmal mit Un*x Betriebssystemen beschäftigen, um die Unterschiede zu Windows zu erkennen. Und ein Custom-Kernel hat genau das was man haben will. Mal abgesehen davon das unter Un*x die universellste Installation nunmal
1 | #> ./configure |
2 | #> make |
3 | #> make install |
ist ... Aber muß ja nicht sein, Hauptsache er weiß wo was installiert wird und was es tut. Nur dann kann er auch mal wenn was klemmt weil ein Script wildgeworden ist oder eine falsche Distri-Installation configs woanders hineinschreibt nachsehen was wo und warum falsch gelaufen ist. Jörg Wunsch schrieb: >> Wichtig ist das der GCC als Crosscompiler für AVR funktioniert und Du >> ein Programm für Deinen Progger hast (avrdude wurde ja schon genannt). > > Ja, aber für beides muss man gewiss nicht in der Lage sein, einen > Linux-Kernel zu bauen. Wenn man einen Kernel bauen kann, weiß man in jedem Falle wie GCC auf der Kommandozeile geht. Und das ist das wesentliche ;-)
kopfkratzer schrieb: > Wenn man einen Kernel bauen kann, weiß man in jedem Falle wie GCC auf > der Kommandozeile geht. Das bezweifle ich. Das lernt man eher, wenn man sich den K&R schnappt und dort das berühmte "Hello, world!" compiliert. Das bisschen "make menuconfig; make; make install" eines Linux-Kernels versteckt einem die Compilerdetails genauso wie eine x-beliebige IDE.
kopfkratzer schrieb: > Er soll sich erstmal mit Un*x Betriebssystemen beschäftigen, um die > Unterschiede zu Windows zu erkennen. Klar. > Und ein Custom-Kernel hat genau das was man haben will. Was hat dieser Satz mit dem vorhergehenden zu tun? Nichts? Und Distro-Kernel haben in 99.9% der Fälle auch alles, was man haben will. Dank Kernel-Modulen wird auch nur das geladen, was man braucht. > Mal abgesehen davon das unter Un*x die universellste Installation > nunmal > #> ./configure > #> make > #> make install > ist ... Jein. Im Gegensatz zu Windows haben alle Linux-Distros eine funktio- nierende Paketverwaltung. Der klar zu bevorzugende Weg ist darum die Installation eines entsprechenden Pakets. Der zweitbeste Weg ist das selberbauen eines solchen Pakets. Die Installation mit "make install" an der Paketverwaltung vorbei ist die letzte und schlechteste Alternative. > Aber muß ja nicht sein, Hauptsache er weiß wo was installiert wird und > was es tut. Wieder im Gegensatz zu Windows hat Linux einen Filesystem-Standard. Es gibt für jedes installierte File nur ziemlich genau einen richtigen Installationsort. Geheimwissen um die Installationsspezifika einzelner Pakete erübrigt sich damit. Es ist einfach alles am kanonischen Platz. Nachtrag: nicht zu vergessen, daß einem das System für richtige Pakete auch jederzeit eine Liste der zum Paket gehörigen Files liefern kann. Oder umgekehrt zu einem bestimmten File herausfinden kann, zu welchem Paket es gehört. > Nur dann kann er auch mal wenn was klemmt weil ein Script wildgeworden > ist oder eine falsche Distri-Installation configs woanders > hineinschreibt nachsehen was wo und warum falsch gelaufen ist. ... was genau das ist, was man von vornherein vermeiden will. Und dank Paketverwaltung auch einfachst vermeiden kann. Anders ausgedrückt: dieses Problem stellt sich gar nicht, wenn man es gleich richtig macht. > Jörg Wunsch schrieb: >> ... für beides muss man gewiss nicht in der Lage sein, einen >> Linux-Kernel zu bauen. > > Wenn man einen Kernel bauen kann, weiß man in jedem Falle wie GCC auf > der Kommandozeile geht. Eher nicht. "make menuconfig" und "make bzImage modules install" erfordern nur unwesentlich mehr Fingerfertigkeit und genau gar kein bisschen mehr Wissen als der Klick auf "jetzt installieren" im typischen Windows-Installer. XL
:
Bearbeitet durch User
Viel hilfreiches zu AVR mit Ubuntu steht hier: http://wiki.ubuntuusers.de/AVR Einem Einstieger zu empfehlen einen eigenen Kernel zu erzeugen ist wirklich nur Unsinn. Das kann man machen, wenn einem langweilig ist oder man wirklich tief in System einstiegen will, aber sonst braucht das keiner. Das wäre so, als wenn man dem Windows-Neueinsteiger erstmal die Registry lernen lässt. Erst danach darf er Programme installieren.
Hallo, für einfache Projekte würde ich einfach einen Text-Editor mit Syntax-Highlighting deiner Wahl vorschlagen, plus ein offenes Shell-Fenster fürs komplilieren mit geeignetem Makefile. Wenns ein wenig komfortabler sein darf kannst du auch mal Geany versuchen, da kann man den Make- und auch AVR-Brenn Vorgang integrieren, wenn man ein bisschen schummelt. Diese ganzen großen Entwicklungsumgebungen wie Eclipse sind mir für AVRs einfach zu aufgeblasen. Wenn man mal ein funktionierendes Makefile [1] hat ist es auch auf der Kommandozeile einfach. [1] Beispiel-Makefile, nicht von mir, siehe Anhang
:
Bearbeitet durch User
Hi, wenn du deinen AVR nicht per Kommandozeile brennen willst, schau dir mal den AVR-Burn-O-Mat an. Das ist ein nettes kleines Java-Programm, mit dem du sehr einfach Fuses setzen kannst, sowie den Flash und EEPROM schreiben und auslesen. Nehme ich sehr gerne, weil ich mir dann nicht jedesmal die ganze Syntax für avrdude raussuchen muss. Natürlich kann man auch im Makefile ein target fürs schreiben erstellen, welches dann den avrdude aufruft... aber auch hier muss man erstmal die Syntax rausfischen.
Rosberg schrieb: > Kennt jemand ein gutes Tutorial wo man von NULL afangen kann? Linux Mint > habe bereits installiert. Muss es zwingend C sein? Wenn nicht, bist du mit Luna gut bedient: http://avr.myluna.de/doku.php?id=de:about http://avr.myluna.de/doku.php?id=de:screenshots /Hannes
So, bin wieder da, erst Mal vielen Dank für die unterstützung! Rosberg schrieb: > Jörg Wunsch schrieb: >> Vielleicht solltest du ja erstmal den Memtest drüber laufen lassen? > > Habe auch gedacht, glaube ich hatte mal mit Windows früher Mal gehabt. Habe das PC erst auf der Seite gelassen und Ubuntu auf ein Laptop installiert, musste aber wirklich kämpfen bis die Wlan Karte funktioniert hat, muss aber Linux loben da alles bis auf dem Wlan Karte funktioniert hat, hab sogar meine Drucker angeschlosen und war sofort da!! T.roll schrieb: > Viel hilfreiches zu AVR mit Ubuntu steht hier: > http://wiki.ubuntuusers.de/AVR Jap, vielen Dank, sieht gut aus bin dabei erst mein AVRISPmkII in ubuntu einzubinden Johannes S. schrieb: > Muss es zwingend C sein? Wenn nicht, bist du mit Luna gut bedient: Ich hab schon mit C und AVR was gemacht deswegen möchte weiter in der Richtung machen. matic schrieb: > Hi, > wenn du deinen AVR nicht per Kommandozeile brennen willst, schau dir mal > den AVR-Burn-O-Mat an. Ja, kenne ich vielen Dank.
Hallo Markus, Markus Weber schrieb: > Karl Käfer schrieb: >> Dieses ganze IDE-Gefumsel habe ich immer mal wieder ausprobiert und >> jedes Mal wieder gelöscht. > > Ich habs nicht jedes Mal wieder gelöscht, aber doch fast jedes Mal. Das > heißt, ich kann dir zwar nicht zu 100 % zustimmen, aber zu 80 %. :-) ;-) > Ein einfacher und - soweit ich weiß - vom Syntax her mit dem > Atmel-Original weitgehend kompatibler Assembler ist AVRA. Den verwende > ich immer, wenn ich mal eben ein kleines AVR-Programm erstelle. > >
1 | avra xyz.asm |
> erzeugt automatisch xyz.hex. Ohne viel Schnickschnack. > Avra als Binary hab ich vor längerer Zeit hier hochgeladen: > http://guloshop.de/f/avr/ Unser Freund mit Linux Mint kann mit .exe-Dateien aber vermutlich wenig anfangen und wird avra daher eher mit
1 | apt-get install avra |
installieren wollen. ;-) Liebe Grüßße, Karl
Angehängte Dateien:
-
Emacs-Startscreen.png
200 KB
Hallo Paul, Paul M. schrieb: > Das mag ja alles sein und für dich Puristen so passend sein. Aber es > mangelt da schon an einer brauchbaren Dokumentation oder einem > ausführlichen Tutorial. Selbst wenn man bereit wäre, für entsprechende > Literatur zu zahlen. Es gibt einfach nichts gescheites. > Das beste, was ich bisher gefunden habe ist > ftp://ftp.fernuni-hagen.de/pub/pdf/urz-broschueren/broschueren/a028.pdf > > Was kannst du als weiterführende Literatur empfehlen? Oh. Also wenn ich meinen Emacs starte, kommt der im Anhang befindliche Startscreen und bietet mir das "Emacs Tutorial", die "Emacs Guided Tour" und das "Emacs Manual" an. Außerdem installiert mein Ubuntu zum Emacs das Paket "emacs23-common-non-dfsg", welches 91 Info-Seiten (das GNU-Projekt benutzt statt Manpages das Info-Format für die Dokumentation; rufe "info emacs" für das Hauptmenü auf) zum Emacs selbst sowie zu allen Haupt-Modi mitbringt. Dazu gibt es die offizielle Doku unter http://www.gnu.org/software/emacs/manual/ sowie http://www.gnu.org/software/emacs/manual/pdf/emacs_7x9.pdf als PDF-Download, und wer Bücher mag und ein paar Euro investieren kann, dem seien die Emacs-Publikationen des O'Reilly-Verlages ans Herz gelegt. Und wem das alles noch nicht ausreichend hilft, die letzten Details der Implementierung zu ergründen: use the source, luke. Emacs ist OpenSource und die meisten seiner Module und Modi sind in Emacs Lisp geschrieben. Das heißt man kann alles in ganz genau dem Code nachlesen (und ändern, wenn gewünscht) der dann auch ausgeführt wird. Wenn Du die gerade erwähnte Dokumentation nur kurz überfliegst, wirst Du vermutlich feststellen, daß das Wort "Purismus" im Zusammenhang mit Emacs vollkommen deplatziert wirkt. Tatsächlich hat Emacs alle Funktionen einer modernen IDE -- nicht wenige davon hat zuerst das Emacs-Team erfunden und implementiert, lange bevor es die ersten IDEs im heutigen Sinne gab. Ich sag's mal so: man kann dem Emacs sicherlich vieles vorwerfen, etwa die manchmal suboptimale Integration in moderne Desktops und die unüblichen Tastaturkürzel (wobei der Emacs älter ist als alle modernen Desktops und ihre Tastaturkürzel). Aber was man dem Emacs ganz sicher nicht vorwerfen, kann, sind ein Mangel an Funktionalität oder an Dokumentation. Übrigens: unter "emacs documentation" findet Google 1,8 Millionen Seiten, allen voran die oben erwähnte offizielle Dokumentation vom GNU-Projekt. Wie um alles in der Welt hast Du es bloß geschafft, nur diese Broschüre von der Fernuni Hagen und sonst nichts zu finden? Liebe Grüße, Karl
Hallo kopfkratzer, kopfkratzer schrieb: > *kopfkratz* > Also wenn Du von Windows auf Linux umsteigen willst, dann schaue Dir mal > diverse Distris an und nimm die die Dir am meisten gefällt. > Schau mal da durch: > https://www.linux.com/directory/Distributions > http://distrowatch.com/ > Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in > den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. > heranzugehen. Diese Herangehensweise halte ich, mit Verlaub, für völligen Quatsch. Als Anfänger kann man die Unterschiede zwischen den Distributionen ohnehin nicht beurteilen, und einen eigenen Kernel zu kompilieren ist heute a) sehr einfach und b) macht das schon seit Jahren keiner mehr, jedenfalls nicht auf normalen Desktop-Systemen. > Welche IDE Du nimmst oder ob Du EMACS in LISP anpaßt ist Deine > Entscheidung. > Wichtig ist das der GCC als Crosscompiler für AVR funktioniert und Du > ein Programm für Deinen Progger hast (avrdude wurde ja schon genannt). > Erstmal mit dem neuen Betriebssystem vertraut machen, läßt sich ja ohne > Probleme parallel zu Windows installieren. > Dann, wenn Du es bedienen kannst nach für Dich passenden Tools für die > AVR Entwicklung suchen und austesten. > Das nehmen mit dem Du persönlich am besten klarkommst und gut ist ;-) Du empfiehlst das Herumprobieren, was an sich nicht die schlechteste Idee ist. Aber wenn der OP herumprobieren wollte, dann würde er nicht nach Empfehlungen fragen. Ihm geht es offensichtlich darum, die Anfangshürden zu überwinden und die gebräuchlichen Werkzeuge kennenzulernen. Liebe Grüße, Karl
Karl Käfer schrieb: > Hallo kopfkratzer, > > kopfkratzer schrieb: >> *kopfkratz* >> Also wenn Du von Windows auf Linux umsteigen willst, dann schaue Dir mal >> diverse Distris an und nimm die die Dir am meisten gefällt. >> Schau mal da durch: >> https://www.linux.com/directory/Distributions >> http://distrowatch.com/ >> Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in >> den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. >> heranzugehen. > > Diese Herangehensweise halte ich, mit Verlaub, für völligen Quatsch. Als > Anfänger kann man die Unterschiede zwischen den Distributionen ohnehin > nicht beurteilen, und einen eigenen Kernel zu kompilieren ist heute a) > sehr einfach und b) macht das schon seit Jahren keiner mehr, jedenfalls > nicht auf normalen Desktop-Systemen. > Du empfiehlst das Herumprobieren, was an sich nicht die schlechteste > Idee ist. Aber wenn der OP herumprobieren wollte, dann würde er nicht > nach Empfehlungen fragen. Ihm geht es offensichtlich darum, die > Anfangshürden zu überwinden und die gebräuchlichen Werkzeuge > kennenzulernen. > > Liebe Grüße, > Karl @Karl, du hast es auf dem Punkt gebracht, genau so ist es. Ich habe schon geschaft mit dem AVRISPmkII ein Atmega zu flashen! vielen Dank. Gruß Rosberg
>> Also wenn Du von Windows auf Linux umsteigen willst, dann schaue Dir mal >> diverse Distris an und nimm die die Dir am meisten gefällt. >> Schau mal da durch: >> https://www.linux.com/directory/Distributions >> http://distrowatch.com/ >> Wenn Du dann in der Lage bist einen neuen Kernel zu compilieren und in >> den Bootmanager einzubinden bist Du soweit an Crosscompiling usw. >> heranzugehen. Also ne, ich würde folgendes machen: Erst in den Urlaub an einen geeigneten Sandstrand fahren und dort Sand für die Siliziumschmelze mitnehemn. Dann zu Hause einen Schmelzoffen bauen, Wafer erzeugen und diese mit einer geeigneten Computerarchitecktur belichten und ätzen. Dann würde ich nach einem geeigneten Betriebssystem suchen und einen Emulator für das eigene Betriebsystem schreiben. Wenn Du so weit bist, nur noch die AVR-Entwicklungsumgebung portieren, einen Programmer bauen und den AVR programmieren. Fertig. So einfach kann es gehen.
@Herbert Schinde Dich doch nicht so! :-) Du kannst auch mal das sog. "LUBUNTU" als Betriebssystem ausprobieren. Das ist zumindest für die "Hauptaufgaben" eines Rechners gut und man kommt auch ohne Linuxkenntnisse gut zurecht. MfG Paul
Hallo, das AVRISPmkII funktioniert soweit ganz gut mit meine Ubuntu, bin einfach nach dem hier beschriebene Methode vorgegangen: http://www.mikrocontroller.net/articles/AVRDUDE#USB-Programmer das "015_usbprog.rules" angelegt und hat gleich funktioniert. Nun habe ich mein STK500 ausgegrabt und wollte damit ausprobieren und das STK500 Seriell flashen (also ttyS0 ??) aber da sagt AVRDUDE:
1 | avrdude: ser_open(): can't open device "/dev/ttyS0": Permission denied |
Muss ich auch etwas wie "015_usbprog.rules" für RS232 anlegen damit es funktioniert?
Karl Käfer schrieb: > Mein Favorit ist der > GNU/Emacs, der über einen Texteditor deutlich hinausgeht und sicherlich > alles andere als einfach, sondern ein sehr mächtiges Werkzeug ist -- > manche sprechen von "Gottes eigenem Editor mit eingebautem > Betriebssystem und eigener Programmiersprache", was dem Ganzen schon > recht nahe kommt. Hast Recht sieht nicht schlecht aus, Bedienung ist aber etwas ungewöhnlich, habe schon ein bisschen probiert allerdings jedes Mal wenn ich Emacs starte, kommt eine kleine Fenster, ich ändere die Größe aber bei nächste start ist wieder klein, kann man irgendwo die Größe einstellen?
>"Ubuntu 9.04 Desktop Edition DVD" Die ist ja aus dem letzten Jahrhundert. Ubuntu ist bereits bei Version 14.04. AVR-Programmieren und Linux ist eigentlich sehr einfach. Ich habe einfach den in Ubunt eingebauten Editor verwendet ( gedit, der hat auch gleich ein Syntax-Highlighting für C ). Wenn man Programm in nur ein File geschrieben hat, kann man einfacht mit gcc compilieren: avr-gcc test.c und fertig. Wenn Du das neueste Ubuntu installiert hast, empfehle ich den Synaptics-Paket Manager zu installieren: sudo apt-get install synaptic Den kannst Du dann aufrufen und dort einfach mal nach avr suchen. Dann die Packete installieren und fertig.
>aber da sagt AVRDUDE: >avrdude: ser_open(): can't open device "/dev/ttyS0": Permission denied Hier gibt es eine Lösung für Ubuntu: http://rurandom.org/justintime/index.php?title=Running_avrdude_from_eclipse_under_linux
chris_ schrieb: > avr-gcc test.c Das bezweifel ich - mindestens der verwendete AVR muesste noch angegeben werden:
1 | avr-gcc -o test.elf -mmcu=atmega8 test.c |
MfG
Hallo @chris_ Es geht jetzt im Prinzip nur um Emacs, Rosberg schrieb: > wenn > ich Emacs starte, kommt eine kleine Fenster, ich ändere die Größe aber > bei nächste start ist wieder klein, kann man irgendwo die Größe > einstellen? Die andere sachen sind schon in Griff, übrigens das hier: chris_ schrieb: >>aber da sagt AVRDUDE: >>avrdude: ser_open(): can't open device "/dev/ttyS0": Permission denied > > Hier gibt es eine Lösung für Ubuntu: > http://rurandom.org/justintime/index.php?title=Running_avrdude_from_eclipse_under_linux Das war für STK500 und funktioniert wie "Simon S." geschrieben hat ---> sudo adduser deinusername dialout Kannst du mehr über das hier erzählen? chris_ schrieb: > Wenn Du das neueste Ubuntu installiert hast, empfehle ich den > Synaptics-Paket Manager zu installieren: > > sudo apt-get install synaptic Wofür ist das gut? avr gcc & Co. laufen schon, ich habe die aktuelle Version kompilliert und installiert.
Hallo, habe das Atmel AVR Toolchain runtergeladen und in HOME/avr entpackt (Ubuntu), habe den Path so aktualisiert: export PATH=$PATH:$HOME/avr/bin ; soweit alles i.O. Nun jedes Mal wenn ich was machen will muss erst den Path über Terminal aktualisieren, wie mache ich damit es permanent bleibt? Gruß Martin
Martin schrieb: > habe das Atmel AVR Toolchain runtergeladen und in HOME/avr entpackt > (Ubuntu), habe den Path so aktualisiert: > > export PATH=$PATH:$HOME/avr/bin ; soweit alles i.O. > > Nun jedes Mal wenn ich was machen will muss erst den Path über Terminal > aktualisieren, wie mache ich damit es permanent bleibt? Es gibt in deinem Home eine Datei .bashrc. Jedesmal, wenn du eine neue Shell [1] startest, dann wird die ausgeführt. Wenn du also bestimmte Umgebungsvariablen immer gesetzt haben willst, dann solltest du das da rein schreiben. Hier mal ein Stück von meiner .bashrc
1 | PS1='\w \$' |
2 | PS2='> ' |
3 | export PS1 PS2 |
4 | |
5 | export EDITOR=vim |
6 | export LC_CTYPE=de_DE.UTF-8 |
7 | export LC_MESSAGES=C |
8 | export LANG=C |
9 | |
10 | echo "$PATH" | fgrep -q "$HOME/bin" || PATH=$HOME/bin:$PATH |
11 | echo "$PATH" | fgrep -q "/sbin" || PATH=/sbin:/usr/sbin:$PATH |
12 | export PATH |
[1] die Standard-Shell auf Linux ist /bin/bash. Falls das bei dir eine andere Shell sein sollte, dann heißt deren rc-File vermutlich anders. Welche Shell du verwendest kriegst du mit "echo $SHELL" heraus.
Allerdings frage ich mich, warum di nicht einfach die Tools installierst, die zur Linux Distribution gehören. Dann brauchst du dich um Pfade nicht zu sorgen. Kleine Starthilfe: http://stefanfrings.de/avr_hello_world/index.html
Stefan U. schrieb: > Allerdings frage ich mich, warum di nicht einfach die Tools > installierst, die zur Linux Distribution gehören. Dann brauchst du dich > um Pfade nicht zu sorgen. Ist natürlich die eifache Variante aber das AVR Toolchain ist neu. Inwiefern lohnt sich ist die Frage.
Stefan U. schrieb: > Allerdings frage ich mich, warum di nicht einfach die Tools > installierst, die zur Linux Distribution gehören. Warum nicht einfach die Toolchain vom Hersteller nutzen?
mit VMware Windows laufen lassen, dann geht das voll super unter Linux, wie fastt alles andere auch was gut ist.
Thomas schrieb: > mit VMware Windows laufen lassen, dann geht das voll super unter Linux, > wie fastt alles andere auch was gut ist. Ne. Eher nicht. Fast alles was unter Windows so "alternativlos" besser läuft als unter Linux, tut es nicht innerhalb einer VM. Lieber Dual-Boot. Das Problem hier ist schon bei den Ersten Posts entstanden: Der TE ist Doppelter Anfänger. Anfänger bei Linux und Anfänger bei µC-Programmierung. Das war wohl nicht allen von Anfang an klar. Der TE hätte eine Anleitung gebraucht wie: - Öffne den Software-manager - Such nach "avr" - mach ein Häkchen bei avrdude, eins bei gcc-avr, ... - Klick auf OK - Gib dein Passwort ein - warte kurz - fertig. Stattdessen hat er, wie viele Windows-Umsteiger in Erwartung dass Linux zwingend Konsolen-Frickelei erfordert, erstmal nach der kompliziertest möglichen Lösung gesucht, mit selbstentpakter Fremdsoftware im Homeverzeichnis usw. Linux-Software installiert man immer über den Distributions-eigenen Paketmananger. Punkt. Klar gibt es Ausnahmen. Wenn du aber fragen musst, wann/warum man solche Ausnahmen macht: Nö. Nimm den Paketmanager.
Planlos schrieb: > Thomas schrieb: >> mit VMware Windows laufen lassen, dann geht das voll super unter Linux, >> wie fastt alles andere auch was gut ist. > > Ne. Eher nicht. Fast alles was unter Windows so "alternativlos" besser > läuft als unter Linux, tut es nicht innerhalb einer VM. Darf ich fragen, was das denn wäre?
Martin schrieb: > Stefan U. schrieb: >> Allerdings frage ich mich, warum di nicht einfach die Tools >> installierst, die zur Linux Distribution gehören. Dann brauchst du dich >> um Pfade nicht zu sorgen. > > Ist natürlich die eifache Variante aber das AVR Toolchain ist neu. > Inwiefern lohnt sich ist die Frage. Was bedeutet in diesem Zusammenhang "neu"? Vom November 2014? Ich habe die Versionsnummern der Atmel-Pakete einmal mit jenen verglichen, die auf meinem KUbuntu/14.10-LTS installiert sind, und es sind genau dieselben: avr-gcc in Version 4.8.1, avr-libc in Version 1.8.0, und so weiter. Also: warum sollte jemand sich eine Toolchain von Atmel herunterladen und in seinem ~ installieren, wenn er exakt dieselben Pakete mit dem Befehl
1 | apt-get install gcc-avr |
installieren und dann den Komfort eines modernen Paketmanagements (Auflösung von Abhängigkeiten, automatische Updates etc.) genießen kann?
Planlos schrieb: > Das Problem hier ist schon bei den Ersten Posts entstanden: Allerdings vor 1,5 Jahren. wendelsberg
Axel S. schrieb: > Hier mal ein Stück von meiner .bashrc Da Du darin sowieso alle Variablen exportierst, reicht ein einmaliges Ausführen in .profile. Das wird nur einmal ausgeführt - nämlich beim Einloggen. Nochmaliges Setzen der ganzen Variablen in allen Subprozessen ist wegen export überhaupt nicht notwendig.
>>> mit VMware Windows laufen lassen, dann geht das voll super unter Linux, >>> wie fastt alles andere auch was gut ist. >> Ne. Eher nicht. Fast alles was unter Windows so "alternativlos" besser >> läuft als unter Linux, tut es nicht innerhalb einer VM. > Darf ich fragen, was das denn wäre? Meine persönliche Erfahrung ist, dass USB Geräte in einer virtuellen Windows Maschine unter Linux meustens nicht funktionieren. Auf meine drei Programmieradapter trifft das zu. Hinzu kommt, das mein Notebook virtuelle Maschinen mangels entsprechender CPU Funktionalität unerträglich lahm ausführt.
Stefan U. schrieb: > Meine persönliche Erfahrung ist, dass USB Geräte in einer virtuellen > Windows Maschine unter Linux meustens nicht funktionieren. Das liegt an der miserablen USB-Implementierung der VirtualBox. Die ist unter aller Sau, und die schlechte USB-2.0-Implementierung (EHCI) haben sie nicht einmal als Opensource, sondern nur als Binärklumpen als "Add-on". In der Opensource-Variante ist nur USB 1.1 dabei. Nimm dir einen VMware Player (nicht "Pro", der kostet Geld, sondern den ohne "Pro"), der macht USB ordentlich. Selbst Firmwareupgrades, die infolge der Umschalterei zwischen Bootloader und endgültigem Gerät, die sich USB-seitig als zwei verschiedene Geräte präsentieren und die daher eine ziemliche Herausforderung für die VM sind, gehen mit VMware klaglos. Auch einen USB-Analyzer, der seine Daten selbst wieder über USB in seinen Host befördern muss, kann ich damit betreiben. Oder halt Geld für die VMware Workstation ausgeben. Dann hat man außerdem noch Snapshots, etwas, was man auf einer physischen Maschine nicht so bequem hat. ;-)
Stefan U. schrieb: >>>> mit VMware Windows laufen lassen, dann geht das voll super unter Linux, >>>> wie fastt alles andere auch was gut ist. > >>> Ne. Eher nicht. Fast alles was unter Windows so "alternativlos" besser >>> läuft als unter Linux, tut es nicht innerhalb einer VM. > >> Darf ich fragen, was das denn wäre? > > Meine persönliche Erfahrung ist, dass USB Geräte in einer virtuellen > Windows Maschine unter Linux meustens nicht funktionieren. Auf meine > drei Programmieradapter trifft das zu. Das geht per USB-Passthrough (bei KVM+qemu mit "-usbdevice host:bus.addr" oder "-usbdevice host:vendor_id:product_id") relativ gut. Allerdings muß der Host davon abgehalten werden, die Kernelmodule für das USB-Gerät zu laden, sonst kommen sich die Host- und die Gast-Treiber gegenseitig in die Quere und resetten das Device ständig. Wenn man das beachtet, funktioniert das hier sogar mit einem timing-kritischen DVB-T-USB-Stick sehr stabil. YMMV. Aber eigentlich zielte meine Frage vielmehr darauf ab, was es denn unter Windows gibt, das so alternativlos besser läuft? ;-)
Sheeva P. schrieb: > was es denn unter Windows gibt, das so alternativlos besser läuft? Virenscanner? ;-)
Jörg W. schrieb: > Sheeva P. schrieb: >> was es denn unter Windows gibt, das so alternativlos besser läuft? > > Virenscanner? ;-) F-Prot, Kaspersky, Sophos und Comodo existieren auch für Linux. Allerdings werden diese nur auf File-, Mail- und ähnlichen Servern benötigt, um arme kleine Windows-Clients zu beschützen. ;-)
> was es denn unter Windows gibt, das so alternativlos besser läuft?
Bundestrojaner
neuer PIC Freund schrieb im Beitrag #4267212: >> was es denn unter Windows gibt, das so alternativlos besser läuft? > > Bundestrojaner Touché.
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.