Hey,
habe neulich Windows runtergeschmissen und hoffte mit Linux
besser zu fahren.
Aber ich habe absolut keine Ahnung wie ich unter Linux AVR's
programmiere.
Kann mir da eventuell jemand weiterhelfen ? Google hat irgendwie keine
Lust.
Was brauche ich genau ?
Habe avr-gcc und avr-libc, sowie avrdude installiert.
Allerdings ist mir ein Rätsel wie Programm vom C-Code über die Hex in
den Controller kommt.
Wie genau muss ich vorgehen ?
Möchte alles ziemlich schlank und spartanisch haben.
Gruß,
Marcel
Hallo,
ich gehe davon aus dass du bis jetzt mit AVR Studio oÄ gearbeitet hast.
Es gibt auch auf linux Eclipse und Co, einfach mal danach suchen.
Sonst lassen sich die Programme (gcc und avrdude) genauso verwenden wie
unter Windows. Kommandozeile ist dein Freund. Einfach die man-Page
aufrufen, das steht alles erklärt
Hey,
danke für die schnellen Antworten!
Ich bin mal wieder begeistert von µC.net.
N. G. schrieb:> ich gehe davon aus dass du bis jetzt mit AVR Studio oÄ gearbeitet hast.> Es gibt auch auf linux Eclipse und Co, einfach mal danach suchen.
Genau das will ich ja nichtmehr.
Am liebsten wäre mir das "Kommandozeilenarbeiten",
darum ja auch mein Sprung zu Linux.
Allerdings ist mir das mit dem makefile usw. nicht ganz so klar.
Muss ich jedes mal ein neues schreiben für einen anderen µC z.B.?
Am liebsten wäre mir:
Gedit oÄ -> C-Code schreiben -> Kommandozeile compilieren ->
AvrDude flashen.
Gibt es irgendwo verständliche und aktuelle Tutorials ?
Habe selber nicht viel gefunden, vielleicht auch die falschen
Suchbegriffe.
Karl M. schrieb:> Hallo Marcel,>> es gibt da auch noch LunaAVR mit der IDE und avrdude kannst Du einen AVR> beschreiben.>> http://avr.myluna.de/doku.php
Hallo Karl, ich danke Dir vielmals für den Link,
eigentlich wollte ich ja weg von den IDE's (s.o.),
aber das sieht ziemlich vielversprechend aus !
Gruß,
Marcel
Marcel B. schrieb:> Genau das will ich ja nichtmehr.> Am liebsten wäre mir das "Kommandozeilenarbeiten",> darum ja auch mein Sprung zu Linux.>> Allerdings ist mir das mit dem makefile usw. nicht ganz so klar.> Muss ich jedes mal ein neues schreiben für einen anderen µC z.B.?
so oft änderst du ja den µC nicht.
Für ein neues Projekt legst du auch ein neues Makefile an. WObei du
natürlich Anleihen bei bereits bestehenden Makefiles nehmen kannst.
So ein Makefile ist ja keine Hexerei. Es organisiert einfach nur die
Aufrufe der einzelnen Teile der Toolchain (Compiler, Linker,
Brennprogramm). Das Werkzeug 'make' sieht sich diese Beschreibung an,
macht Zeitvergleiche der darin genannten Dateien und wenn eine
Ergebnisdatei älter als eine Quelldatei ist, dann wirft es das im
Makefile genannte Tool an, damit das aus der Quelldatei eine neue
Ergebnisdatei macht.
> Gedit oÄ -> C-Code schreiben -> Kommandozeile compilieren ->> AvrDude flashen.
Niemand hindert dich daran.
Den Schritt 'Linken' hast du vergessen. Ist aber nicht so schlimm, weil
der Aufruf des gcc beides übernimmt (übernehmen kann).
make ist nur ein Werkzeug, so dass du dich nicht um Abhängigkeiten
kümmern musst, die man gerne vergisst. Vor allen Dingen dann, wenn das
komplette Projekt aus mehreren C Files und/oder mehreren H Files
besteht.
Jetzt mal ganz davon abgesehen, dass so ein Makefile eine gute 'Doku'
ist, mit welchen Argumenten denn man eigentlich den Compiler angeworfen
hat. Denn das Gedächtnis ist dann des öfteren schon recht trügerisch.
Aber brauchen, brauchen tut man ein Makefile nicht unbedingt. Die ersten
paar mal kannst du ruhig auch alles selber von der Commandline aus
machen. Irgendwann wird es dir dann sowieso von alleine zu blöd,
jedesmal wieder den Compileraufruf mit allen Argumenten erneut
einzutippen.
> Muss ich jedes mal ein neues schreiben für einen anderen µC z.B.?
Innerhalb der AVR-Familie nicht, da reicht es, ein paar
Makefile-Variablen mit dem Typ und Frequenz zu haben, die Compilerflags
sind meistens immer gleich.
Insgesamt läuft es immer nach demselben Schema. Alle .c einzeln nach .o
compilieren, die entstandenen .o zu einem Pseudo-Executable
zusammenlinken und das dann in das Flashformat konvertieren. Gibt noch
ein paar Tricks mit der Erkennung der Abhängigkeiten, kann man aber
genug aus dem Internet klau...äh... recyclen.
Controller-/Programmertyp setzt du jenachdem was du hast, F_CPU ist die
gemäß den Fuses konfigurierte Taktfrequenz (hier für 1 MHz für
fabrikneue AVRs).
Die erste Zeile erzeugt ein ELF-File (kann man nicht flashen, aber z.B.
in einen Disassembler oder Debugger werfen, wenn man möchte).
Die zweite macht daraus ein Hexfile.
Die dritte nutzt avrdude um das Hexfile in den uC zu schieben.
Karl Heinz schrieb:> So ein Makefile ist ja keine Hexerei.
Gerade in Anbetracht des gigantischen WinAVR-Makefiles, welches immer
und immer wieder empfohlen wird, möchte ich dir da widersprechen. Ich
halte das für historisch gewachsen. Das macht es zwar nicht automatisch
schlecht, aber auch nicht automatisch gut.
Mir selbst hat dieses Makefile als totaler Anfänger nur Kopfzerbrechen
bereitet, weil ich mit dessen Komplexität völlig überfordert war und ich
es nicht geschafft habe, damit einen AVR erfolgreich zu programmieren.
(Und fang mir bitte nicht mit
https://www.mikrocontroller.net/articles/C_ohne_Makefile an. Keinerlei
Erklärung, schlecht strukturiert und Zusammenwerfen von Buildsystem und
Code.)
> make ist nur ein Werkzeug, so dass du dich nicht um Abhängigkeiten> kümmern musst, die man gerne vergisst. Vor allen Dingen dann, wenn das> komplette Projekt aus mehreren C Files und/oder mehreren H Files> besteht.
Es gibt seit gut einem Jahrzehnt Rechner, die die Menge von Code, die
auf einen 8-Bit-AVR maximal draufpasst, in wenigen Sekunden neu bauen
können. Abhängigkeiten sind hier nur Overkill und unnötige Komplexität,
die mir schon mehrfach unnötige Bugs mit geänderten, aber nicht neu
kompilierten Files beschert hat.
foo schrieb:> Karl Heinz schrieb:>> So ein Makefile ist ja keine Hexerei.>> Gerade in Anbetracht des gigantischen WinAVR-Makefiles, welches immer> und immer wieder empfohlen wird, möchte ich dir da widersprechen.
Kein Mensch sagt, dass ein Makefile so komplex sein muss. Sicher, das
spielt alle Stückeln. Aber wenn man es spartanisch haben will, dann
stellt man fest, dass es genügt eine ganz einfache Abhängigkeit zu
beschreiben. In meinem Projekt mag es eine einzige C_Datei namens main.c
geben. Dann steht im Makefile, dass main.elf erhalten wird, indem man
den gcc auf main.c loslässt
und das wars dann auch schon.
in der Command line 'make' eingeben und der prozess läuft. Wenn main.c
ein jüngeres Datum als main.elf hat, dann wird das angegebene Kommando
(der Compiler) angeworfen. Wenn main.elf ein jüngeres Datum als main.hex
hat, dann wird objcopy angeworfen.
Der Rest, den du im Standard-Makefile siehst, ist Komfort. Aber aufs
nackte 'bare-metal' reduziert, ist es dieser 4 Zeiler bereits.
Nebenbei: make kann man auch noch für andere Dinge gut einsetzen. Immer
dann wenn es um eine Relation: "Wenn Y jünger als X, dann Kommando
ausführen" geht, leistet make gute Dienste. Das kann die Compilierung
eines Programms sein, das kann aber auch die Sicherungskopie in ein
Backupverzeichnis sein.
foo schrieb:> Schlanker als so gehts nicht:
Aber sicher doch! Den avr-objcopy braucht's nicht, avrdude kann seit
einer Weile direkt das ELF als Input verwenden.
Karl Heinz schrieb:> Aber wenn man es spartanisch haben will, dann> stellt man fest, dass es genügt eine ganz einfache Abhängigkeit zu> beschreiben.
Im Grunde hast du damit das, was ich bei mir als Bashskript "compile"
rumliegen habe, nur in ein Makefile gepackt. Eine eigentlich gar nicht
mal so unsinnige Idee, weil das Vorhandensein eines Makefiles fast immer
professioneller aussieht als ein zusammengebasteltes Skript, egal was im
Makefile drin steht.
Vermutlich weil man in ein heruntergeladenes Projekt schaut und
feststellt, "oh, es gibt ein Makefile, make ausführen reicht also" vs
"was gibtsn da für Files.. main.c, main.h, ..., ah, compile". Und selbst
wenn man die Abhängigkeitsfeatures gar nicht benutzt hat es sich allein
deshalb schon gelohnt. :)
Letztlich gings mir aber auch eher darum, dass ich vor einigen Jahren in
etwa der selben Situation wie der TE war (abgesehen davon, dass ich AVR
Studio nie angefasst habe) und es mir damals deutlich weitergeholfen
hat, als ich später drauf gekommen bin, dass man AVRs auch mit den drei
Zeilen weiter oben programmieren kann. Genau diesen Punkt wollte ich im
Beitrag rüberbringen, keinen weiteren, darum habe ich alles weggelassen
was irgendwie optional ist - also diverse Compilerswitches... und eben
make.
Mich selbst interessiert bei vielen Dingen zunächst, wie das im Prinzip
funktioniert (avr-gcc -> avrdude), danach erst interessiere ich mich
dafür was es da für Sachen gibt um das wegzuabstrahieren. Eventuell
liegts daran.
Dass man das dann später, wenn man erfolgreich einen LED-Blinker o.ä.
gebaut hat, wirklich mal in nem Makefile und nicht nur in seiner
Shellhistory stehen haben möchte, steht natürlich außer Frage ;)
Konrad S. schrieb:> foo schrieb:>> Schlanker als so gehts nicht:>> Aber sicher doch! Den avr-objcopy braucht's nicht, avrdude kann seit> einer Weile direkt das ELF als Input verwenden.
Ich glaube es war wirklich ganz kurz vorm 6.0 Release (davor gabs das
wohl nicht), als ich das letzte mal die Manpage komplett gelesen habe.
Danke!
*schreibt sich "Hexfile" auf die selbe Liste, auf der schon pgm_read_xxx
steht*
Marcel B. schrieb:> Gedit oÄ -> C-Code schreiben -> Kommandozeile compilieren ->> AvrDude flashen.
gedit kann externe Tools aufrufen, die Kommandozeile kannst Du dir also
sparen. Standardmäßig wird mit Strg+F8 'make' im Verzeichnis, in dem die
bearbeitete Datei liegt, gestartet. Niemand hindert einen, einen eigenen
Shortcut für "make flash" (oder wie auch immer das Target im Makefile,
das von der .hex abhängig ist und avrdude startet, heißt) einzustellen.
So kann man mit einem Tastendruck compilieren und (falls keine Fehler
auftraten) flashen.¹
Wenn man Intellisense und Simulation/Debugging nicht benötigt und ein
brauchbares Makefile hat², ist man so nach meiner Erfahrung nach etwas
Einarbeitung deutlich komfortabler unterwegs als bei vielen IDEs, die
die wichtigen Dinge im 7. Untermenü verstecken. Ich erinnere mich mit
Grausen an das Flashen in AVR-Studio 4³.
¹ Die externen Tools kann man mit etwas Fantasie noch weiter nutzen,
z.B. den Fensterinhalt auf Tastendruck durch indent schicken und
automatisch formatieren usw.
² Das kann man meist von Projekt zu Projekt weiterkopieren.
³ das außer zum Simulieren zu gar nichts zu gebrauchen war, nicht mal
zum Editieren von Code.
Also ist das makefile im Grunde nur eine Zusammenfassung der einzelnen
avr-gcc Befehle die benötigt werden aus C Hex
Zu erstellen?
Dann muss ich also die avr-gcc Optionen nachschlagen und kann so das
Makefile
Erstellen.
Danke an Karl Heinz und foo für den Beispielcode,
Dieser macht alles ein wenig übersichtlicher.
Muss denn f_CPU und MCU auch im Makefile
Stehen?
Ich kenne das vom Atmelstudio, das alles
direkt im Sourcecode angegeben wird/werden muss.
Danke nochmal!
Gruß,
Marcel
Marcel B. schrieb:> Also ist das makefile im Grunde nur eine Zusammenfassung der> einzelnen> avr-gcc Befehle die benötigt werden aus C Hex> Zu erstellen?
Richtig.
>> Dann muss ich also die avr-gcc Optionen nachschlagen und kann so das> Makefile> Erstellen.
Ja. Die Optionen, die ich im Beispiel angegeben habe, halte ich fürs
notwendige Minimum, aber schon damit kann man problemlos Programme
bauen.
-mmcu definiert den Typ des Controllers. Notwendig, weil der Umfang des
Befehlssatzes sich zwischen den AVRs unterscheidet. Außerdem notwendig
damit die AVR-libc die richtigen Definitionen (Register etc.) benutzt.
Wird es nicht angegeben, dann wird ein sehr eingeschränkter Befehlssatz
("avr2") verwendet und es gibt keine Defines für Pins, Register, etc.
(es wird eine Warning "device type not defined" geben)
-DF_CPU=1000000UL macht dasselbe als würdest du in die C-Files "#define
F_CPU 1000000UL" reinschreiben. Ist eine Geschmacksfrage ob man das im
C-File oder beim Compileraufruf haben möchte. Wahrscheinlich gibt es für
beides gute Argumente
-std=gnu99 - moderner C-Dialekt (der Standard ist sonst C89, viele
Sachen gibts da nicht, z.B. Variablen direkt in for-Schleifen
deklarieren).
-Os - Optimieren auf Codegröße. Für AVR mit relativ wenig Flash meist am
sinnvollsten. Optimizer ist Pflicht u.a. weil die _delay_* Funktionen
irritierenderweise ohne Optimizer nicht korrekt funktionieren.
-Wall aktiviert die meisten (nicht alle, wie der Name vermuten lässt)
Warnings.
> Muss denn f_CPU und MCU auch im Makefile> Stehen?
MCU muss auf jeden Fall im Makefile/Compileraufruf stehen, weil das auch
die verfügbaren Assembler-Instruktionen beeinflusst.
Wenn du _delay_* nicht benutzt, kann F_CPU auch komplett undefiniert
bleiben. (Benutzt du sie trotzdem, wird dich eine Warning daran
erinnern)
> Ich kenne das vom Atmelstudio, das alles> direkt im Sourcecode angegeben wird/werden muss.
Habe nie mit Atmelstudio zu tun gehabt, kann also nur vermuten. Entweder
kann man den Controllertyp noch in einem extra Fenster
("Projekteinstellungen" oder sowas in der Art) einstellen, oder aber die
IDE sucht vorm Kompilieren nach passenden #defines im Code.
avr-gcc musst du jedenfalls immer auf der Kommandozeile sagen, für
welchen Controller du baust. Die notwendigen #defines für die avr-libc
erzeugt der daraus dann selbst.
Hallo Marcel,
Marcel B. schrieb:> Genau das will ich ja nichtmehr.> Am liebsten wäre mir das "Kommandozeilenarbeiten",> darum ja auch mein Sprung zu Linux.
Als bekennender Shellfreund mache ich das immer so: ich benutze den
Emacs als Editor und make(1) zur Steuerung von avr-gcc, avr-objcopy und
avrdude.
> Allerdings ist mir das mit dem makefile usw. nicht ganz so klar.> Muss ich jedes mal ein neues schreiben für einen anderen µC z.B.?
Nein. Im Prinzip reicht ein Skelett bzw. eine Vorlage, in der die
üblichen Operationen als Targets vordefiniert sind und die jeweiligen
Einstellungen wie F_CPU, BAUDRATE, Fuses etc. am Anfang als Variablen
gesetzt werden.
> Am liebsten wäre mir:>> Gedit oÄ -> C-Code schreiben -> Kommandozeile compilieren ->> AvrDude flashen.
Kein Problem, genau so mache ich es auch, nur eben automatisiert über
make(1) -- dabei fehlt nur noch der Zwischenschritt vom Kompilat zum
Hexfile mit avr-objcopy:
Hallo Marcel,
Marcel B. schrieb:> Also ist das makefile im Grunde nur eine Zusammenfassung der einzelnen> avr-gcc Befehle die benötigt werden aus C Hex> Zu erstellen?
Jaein. Wenn man die Features von make(1) ausnutzt stehen da zum Beispiel
Variablen und Regeln drin wie:
Die Variable "CC" enthält dabei den zu verwendenden Compiler (hier g++),
die Variable "CCFLAGS" enthält die Compilerflags, die beim Übersetzen
verwendet werden sollen. Die Regel "%.o: %.cpp" sagt make, daß beliebige
.ccp-Dateien mit dem folgenden Befehl in .o-Dateien übersetzt werden;
die Eingangsdatei ist $<, die Ausgangsdatei $@. Für die Datei "ding.cpp"
wird die Regel also zu dem Befehl
Auf diese Weise kann man alle .cpp-Dateien automatisch mit den korrekten
Einstellungen übersetzen, ohne für jede Datei ein eigenes Make-Target
erstellen zu müssen. Das ist bei Mikrocontroller-Projekten mit meistens
weniger als funf bis zehn .c- oder .cpp-Dateien wahrscheinlich nicht so
wichtig, aber in konventionellen Projekten mit Hunderten solcher Dateien
erspart das eine Menge fehleranfällige Arbeit und verbessert den
Überblick über das Makefile ganz enorm -- zumindest wenn man sich
erstmal mit der gewöhnungsbedürftigen Syntax von Makefiles angefreundet
hat.
> Muss denn f_CPU und MCU auch im Makefile> Stehen?> Ich kenne das vom Atmelstudio, das alles> direkt im Sourcecode angegeben wird/werden muss.
Das kann man machen, muß man aber nicht.
Liebe Grüße,
Karl
Karl Käfer schrieb:> %.o: %.cpp> $(CC) $(CFLAGS) -o $@ -c $<
Diese Regel ist überflüssig - zumindest dann, wenn man die für C++
vorgesehenen Variablen verwendet und nicht den C-spezifischen Variablen
artfremdes Zeug aufdrückt. Dann klappt es auch mit gemischten
C/C++-Projekten problemlos.
Ich hab im Makefile nach dem eigentlichen Linken noch ein 'nm $@ | grep
etext'. Geht sicher auch schöner, aber gibt schnell die Grösse des
normalen Flashbereichs an (von Bootloadern etc. abgesehen). Dann kann
man abschätzen, wie weit man noch im Code rumsauen kann, bevor das Flash
platzt ;)
Georg A. schrieb:> Ich hab im Makefile nach dem eigentlichen Linken noch ein 'nm $@ |> grep> etext'. Geht sicher auch schöner, aber gibt schnell die Grösse des> normalen Flashbereichs an (von Bootloadern etc. abgesehen). Dann kann> man abschätzen, wie weit man noch im Code rumsauen kann, bevor das Flash> platzt ;)
Ich erweitere um:
1
# kompilieren mit -fstack-usage -Wstack-usage=4 -> Stackverbrauch pro Funktion
Hallo Konrad,
Konrad S. schrieb:> Karl Käfer schrieb:>> %.o: %.cpp>> $(CC) $(CFLAGS) -o $@ -c $<>> Diese Regel ist überflüssig - zumindest dann, wenn man die für C++> vorgesehenen Variablen verwendet und nicht den C-spezifischen Variablen> artfremdes Zeug aufdrückt. Dann klappt es auch mit gemischten> C/C++-Projekten problemlos.
Das stimmt. Kommt davon, wenn man Zeug aus verschiedenen Makefiles
zusammenkopiert. ;-)
Liebe Grüße,
Karl
Marcel B. schrieb:> igi@hogmints ~/AVR/LED1 $ make> makefile:4: *** Fehlendes Begrenzungszeichen. Schluss.
Make hat eine sehr eigenwillige Syntax, z.B. müssen die Kommandos
unbedingt mit einem Tab eingerückt werden, nicht mit Leerzeichen,
sonst verschluckt sich der Parser. Ich glaube, das ist hier das Problem.
> -DF_CPU=16000UL
Der läuft echt mit 16 KILOhertz?
> /usr/lib/gcc/avr/4.8.2/../../../avr/bin/ld: cannot find crttn13a.o:
Spontan keine Lösung für, ich guck aber noch mal.
Danke Dir foo für die schnelle Antwort.
Ja hab noch in Atmelstudio INTOSC125kHz eingestellt und die CKDIV 8
gesetzt.
Des reicht mir als geschwindigkeit vollkommen aus und spart Strom :D !
Ich probiere es mal eben mit dem einrücken.
Edit: Make funktioniert!
DANKE!
Jetzt bleibt nurnoch das Problem mit der crttn13a.o
er sucht se aber "alle". Mit crttn2313.o kommt der Fehler auch.
Gruß,
Marcel
Marcel B. schrieb:> Des reicht mir als geschwindigkeit vollkommen aus und spart Strom :D !
Wollte nur sichergehen dass du nicht eigentlich 16 MHz meintest, aber in
dem Fall ist das dann richtig.
> Jetzt bleibt nurnoch das Problem mit der crttn13a.o> er sucht se aber "alle". Mit crttn2313.o kommt der Fehler auch.
Zumindestens für crttn13a ist das Problem wohl bekannt, es handelt sich
wohl um einen Bug in der Toolchain:
https://lists.nongnu.org/archive/html/avr-libc-dev/2012-12/msg00015.html
Warum das auch bei crttn2313 auftritt, kann ich dir aber auch nicht
sagen.
Hey Foo,
ich habe mal den workaround probiert.. aber meine Verzeichnisstruktur
ist toal anders.
Ich habe kein "/tiny-stack" verzeichnis..
Hier mal mein "Workaroundversuch" bzw meine "Diagnose"
Marcel B. schrieb:> Ich habe kein "/tiny-stack" verzeichnis..
In dem Bugreport war genau das auch das Problem. Leg es an.
Bzw. ich würde, damit nicht irgendwann was anderes kaputt geht, die
Dateien kopieren und die Originale da lassen wo sie sind.
(Alternativ einen Symlink erstellen:
1
ln -s . /usr/lib/avr/lib/avr25/tiny-stack
das lässt "tiny-stack" wiederum auf avr25 zeigen. Aber ich weiß nicht,
was dein Paketmanager dazu sagt, wenn du auf eine neue Version
upgradest, bei der die den Bug fixen.)
Marcel B. schrieb:> Edit: allerdings sagt gcc dass dort was sein sollte :
Was wiederum nur heißt dass gcc dort sucht. Und da ist eben nichts (weil
existiert nicht). Fehler gefunden... ;)
siehe da.. Läuft!
Endlich!
Bleibt denn das Dir bestehen falsl ich update oder deinstalliere?
Er "kennt" es ja nicht.
Jetzt mal sehen wie ich avrdude mit dem STK500 zum laufen kriege,
also keine Angst hier im Thread gehts noch weiter*lach*!
Danke nochmals und Gruß,
Marcel
Marcel B. schrieb:> Bleibt denn das Dir bestehen falsl ich update oder deinstalliere?> Er "kennt" es ja nicht.
Ich kenne Mint und damit auch den Paketmanager dort nicht, aber ich gehe
davon aus, dass das bestehen bleibt, wenn du deinstallierst, weil der
die Datei eben nicht kennt.
Über die dann fehlende /usr/lib/avr/lib/avr25/crttn13a.o wird es
wahrscheinlich eine Warnung geben, mehr nicht.
Was beim Update passiert keine Ahnung. Entweder das Update behebt den
Bug: dann weiß ich nicht, ob der Paketmanager das mit aktueller Version
überschreibt (gut), nachfragt (gut) oder ignoriert (weniger gut, kann
aber trotzdem funktionieren). Oder das Update behebt den Bug nicht, dann
bleibt der Fix bestehen, du wirst nur natürlich weiterhin die crttn13a.o
von der alten Version weiterbenutzen.
> Jetzt mal sehen wie ich avrdude mit dem STK500 zum laufen kriege,
-c stk500 oder stk500v1 oder stk500v2
Also Mint basiert auf Ubuntu, hat apt als Paketverwaltung
und ist meines Wissens genau wie Ubuntu zu bedienen.
Bin zwar noch totalNoob aber ich kann keine großen Unterschiede
zu Ubuntu erkennen.
Zum flashen:
Das hier ist mein Makefile :
Die generelle Struktur einer derartigen Regel ist IMMER
1
Zieldatei: Quelldatei[en]
2
Kommando, wie man aus den Quelldateien die Zieldatei bekommt
Kommandos sind IMMER in einer Zeile, die mit einem Tabulator beginnt.
Und dann gibt es noch die Variante mit einem 'Target'. Die sieht so aus
1
Target : prerequisites ; recipe
2
recipe
Ein Target ist etwas, das du dem make beim Aufruf aus der Commandline
mitgeben kannst. Du kannst also zb sagen
1
make flash
dann muss es in deinem Makefile eine Regel geben, die so aussieht
1
flash:
2
avrdude -p attiny13 -c stk500 -U flash:w:main.hex
(wieder: da muss ein Tab rein)
Du kannst auch sagen: Der Vorgang des Flashens(*) ist davon abhängig,
dass es ein main.hex gibt
1
flash: main.hex
2
avrdude -p attiny13 -c stk500 -U flash:w:main.hex
dann wird make bei einem
1
make flash
erst mal untersuchen, ob es das wirklich gibt und wenn nicht, sich mit
den anderen Regeln erst mal das main.hex zu erstellen versuchen.
Es wird Zeit, dass du dir die Syntax der makefiles mal etwas genauer
ansiehst.
(*) make weiss natürlich nichts von Compilern, Linkern oder Flashen.
make kümmert sich nur um die Beziehung: was ist wovon abhängig und
welches Kommando muss ich ausführen um das Ziel aus der Quelle zu
erzeugen. Welche Bedeutung Quelldatei, Zieldatei oder gar Kommandos
haben, ist nicht das Bier von make.
Karl Heinz schrieb:> Kommandos sind IMMER in einer Zeile, die mit einem Tabulator beginnt.
Und ja. Man kann mehrere Kommandos in mehreren Zeilen schreiben.
Aber dann beginnt jede Zeile immer noch trotzdem mit einem Tabulator
1
main.hex: main.elf
2
avr-objcopy -O ihex -R .eeprom main.elf main.hex
3
avrdude -p attiny13 -c stk500 -U flash:w:main.hex
es ist dieser Tabulator am Zeilenanfang, an dem make erkennt, ob du von
einer Regel (oder sonstwas) sprichst, oder von einem Kommando, das du
ausgeführt haben willst.
Karl Heinz schrieb:> es ist dieser Tabulator am Zeilenanfang, an dem make erkennt, ob du von> einer Regel (oder sonstwas) sprichst, oder von einem Kommando, das du> ausgeführt haben willst.
Mit anderen Worten, wenn man es geschafft hat, nicht nur zufällig ein
funktionierendes Makefile zu schreiben, dann hat man auch die richtige
Einstellung für die Anzeige von Tabs und führenden Spaces in seinem
Editor gefunden.
Hallo Marcel,
Marcel B. schrieb:> Bleibt denn das Dir bestehen falsl ich update oder deinstalliere?
Ja.
> Er "kennt" es ja nicht.
Genau deswegen. Ein (vernünftiger) Paketmanager faßt ausschließlich
Dateien und Verzeichnisse an, die er er kennt. Wenn da auf einmal ein
Verzeichnis ist, das er nicht kennt, gibt er eine Warnung wie "directory
not empty so not removing" oder so ähnlich aus und löscht weder Dein
manuell angelegtes, noch das übergeordnete Verzeichnis.
Liebe Grüße,
Karl
Hey,
ich bisn nochmal..
Meine zwei, drei Beispielprogrämmchen habe ich flashen können.
Allerdings möchte ich jetzt als nächstes die Batteriespannung über
ADC checken, damit die Akkus nicht zerstört werden (Li-Ion).
Kann mir jemand verraten wie ich die Fuses setze?
Habe das hier im Netz gefunden :
Allerdings stellt sich mir nun die Frage, ob das format hex sein muss.
oder ob auch sowas wie 0bxxxxxxxx geht.
Find das übersichtlicher.
Kann ich die interne Referenzspannung auch per Fuse einstellen ?
Oder hab ich nur die Referenzspannung auf dem stk500 eingestellt? :-o
Sry, aber im Atmelstudio ging das immer so schön über Häkchen
und Schieberegler.
Lieben Gruß,
Marcel
Marcel B. schrieb:> Allerdings stellt sich mir nun die Frage, ob das format hex sein muss.> oder ob auch sowas wie 0bxxxxxxxx geht.
Laut Manpage geht das. Aber wozu? Der allseits bekannte
http://www.engbedded.com/fusecalc gibt Hex aus und zusätzlich sogar die
Argumente für avrdude zum Copypasten.
> Kann ich die interne Referenzspannung auch per Fuse einstellen ?
Nein, nur per Register, steht so im Datenblatt.
> Oder hab ich nur die Referenzspannung auf dem stk500 eingestellt? :-o
Halte ich für nahezu ausgeschlossen, dazu musst du den uC auf dem
Programmer selbst flashen und dazu muss man (abhängig vom Typ; kenne den
stk500 nicht) mindestens einen Jumper irgendwo setzen.
> Sry, aber im Atmelstudio ging das immer so schön über Häkchen> und Schieberegler.
(du suchst die oben bereits verlinkte Webseite)
>> Lieben Gruß,> Marcel
Hey foo!
foo schrieb:> Der allseits bekannte> http://www.engbedded.com/fusecalc gibt Hex aus und zusätzlich sogar die> Argumente für avrdude zum Copypasten.
Dankesehr!
foo schrieb:> Halte ich für nahezu ausgeschlossen, dazu musst du den uC auf dem> Programmer selbst flashen und dazu muss man (abhängig vom Typ; kenne den> stk500 nicht) mindestens einen Jumper irgendwo setzen.
Doch hier:
http://www.robotroom.com/STK500/STK500-voltage-settings-in-AVR-Studio.jpg
Dort ist ein Bild.
foo schrieb:> (du suchst die oben bereits verlinkte Webseite)
Und wie!
Wir versteh'n uns! lach
Danke nochmal und Gruß,
Marcel
Marcel B. schrieb:> Doch hier:> http://www.robotroom.com/STK500/STK500-voltage-set...>> Dort ist ein Bild.
Ah. Der STK500 kann eine Referenzspannung selbst erzeugen und wenn man
einen Jumper setzt, dann gibt er die auf den ARef-Pin des AVRs der im
Sockel steckt.
Das ist also ein reines Feature von deiner
Programmer-/DevelopmentBoard-Kombination, die du da hast. ;)
In einer nackten Schaltung müsstest du diese Spannung selbst irgendwie
an ARef bringen.
Achsoooo!
Nagut das ist ohne Atmelstudio ja dann unter Linux so nicht nutzbar,
nehme ich an.
Wäre sowieso nicht ganz so Hilfreich.
In meinem jetzigen Schaltplan brauche ich eine änderbare Spannung am
ADC2-Pin.
Jetzt kommt ja erst der Spaß - Die Software.
Gruß,
Marcel
Thread beobachten
Seitenaufteilung abschalten