Ist die neue Arduino Entwicklungsumgebung eine Alternative zum Atmel-Studio? Kann man mit der Arduino Umgebung ohne Probleme "normale" Atmel-Programme schreiben? http://blog.arduino.cc/2015/02/09/arduino-ide-1-6-is-released-download-it-now/
:
Verschoben durch Moderator
>Ist die neue Arduino Entwicklungsumgebung eine Alternative zum >Atmel-Studio? Kann man mit der Arduino Umgebung ohne Probleme "normale" Atmel-Programme schreiben? Nein, die Alternative ist winavr oder avr-gcc für linux mit makefiles. http://www.mikrocontroller.net/articles/AVR-GCC
>Nein, die Alternative ist winavr oder avr-gcc für linux mit makefiles.
... und Eclipse
Habe die mal gerade runter geladen. Was ist jetzt so anders? Das mit den Makefiles habe ich auch schon probiert. Ich finde das Studio ist die beste und einfachste Möglichkeit zum programmieren.
Horst schrieb: > Kann man mit der Arduino Umgebung ohne Probleme "normale" > Atmel-Programme schreiben? Ja, natürlich, man kann alle Programme schreiben, die man will, solange es irgendwie mit C zu tun hat. Da steckt nämlich der altbekannte gcc drunter. Allenfalls der Speicherplatz, den der Bootlader beansprucht, ist nicht verfügbar und die fuses sind (bei ausschließlicher Bootlader-Programmierung) vorgegeben. Wer was anderes schreibt, hat einfach mal gar keine Ahnung. Was verstehst Du denn unter "normalen" Programmen. foldi schrieb: > Ich finde das Studio > ist die beste und einfachste Möglichkeit zum programmieren. Das ist Ansichtssache, somit subjektiv.
google schrieb: > Allenfalls der Speicherplatz, den der Bootlader beansprucht, > ist nicht verfügbar und die fuses sind (bei ausschließlicher > Bootlader-Programmierung) vorgegeben. Wenn man einen Programmer nutzt, gelten auch diese Einschränkungen nicht. Nur bei Prozessoren, die nicht direkt unterstützt werden (z.B. ATtiny), ist es etwas schwieriger. Bernd
Horst schrieb: > Ist die neue Arduino Entwicklungsumgebung eine Alternative zum Die ist gar keine Alternative zu irgendwas. Außerdem hat sie den Namen "Entwicklungsumgebung" nicht verdient weil ihr dafür selbst die grundlegendsten Dinge fehlen. Selbst ein mittelmäßig guter Texteditor wäre wahrscheinlich auf Dauer ergonomischer und hilfreicher als diese vollkommen sinnfreie Arduino-Software. Alternativen sind: (1) Selbstgeschriebenes Makefile, Konsole und ein guter Texteditor (2) Eclipse mit dem AVR-Plugin (oder ähnliche vollwertige IDE) (3) Atmel-Studio 6 Punkt 1 ist die Grundlage, das sollte man auf jeden Fall beherrschen, auch wenn man später darauf aufbauend sich viele Dinge automatisiert (z.B) bestimmte make targets die man geschrieben hat später bequem in der IDE mit nem Mausklick startet oder dergleichen. Wenn Du wirklich in das Thema einsteigen willst dann fange bei Punkt 1 an und bleibe dort für mindestens 6 Monate, solange bis Dich dort nichts mehr schrecken kann. Das ist interessant und macht Spaß. Mit diesem Wissen gehst Du dann irgendwann zu Punkt 2. Wenn Du (1) und (2) beherrschst dann wird Dir (3) nur noch ein müdes Lächeln und Kopfschütteln abgewinnen können und Du wirst bei (2) bleiben. Daher habe ich es in weiser didaktischer Voraussicht in genau dieser Reihenfolge angeordnet und nicht anders. Wenn Du Dich jedoch nicht tiefergehend damit beschäftigen willst weil Du nur mal kurz mit ein paar vorgefertigten Spielzeugen rumspielen willst ohne Interesse daran wie sie funktionieren dann nimm irgendein Spielzeug (egal welches) und spiel ne Weile damit rum.
Bernd K. schrieb: > Wenn Du wirklich in das Thema einsteigen willst dann fange bei Punkt 1 > an und bleibe dort für mindestens 6 Monate, solange bis Dich dort nichts > mehr schrecken kann. Das ist interessant und macht Spaß. Wie weit die Meinungen doch auseinander liegen können. Diesen kryptischen Scheiß mit dem Makefile würde ich nie wieder anfassen und einem Anfänger gar nicht erst empfehlen. Das Studio, in der aktuellsten Version, würde ich jedem Anfänger empfehlen. Denn damit klappt schon mal dieser Einstieg. Sechs Monate! Man, das Leben ist kurz und viele (so wie ich) sind vielleicht nicht mehr ganz so jung und haben sicher noch viel mehr als nur die µC's zu lernen. Bei den heutigen leistungsstarken Rechnern spricht nichts gegen das Studio. Man kann ja später das ältere Studio installieren, wenn das wirklich schneller läuft. Wenn es einmal gestartet ist, dann ist 6.2 ja verfügbar und der Rest geht dann doch auch schnell. Für mich hören sich diese Aussagen so an, "Du musst erstmal 6 Monate über Dioden lesen und Versuche damit machen, bevor du eine einbaust!" und diese Empfehlungen sind für einen Anfänger demotivierend.
Bernd K. schrieb: > Alternativen sind: > > (1) Selbstgeschriebenes Makefile, Konsole und ein guter Texteditor Bevor Du Dein erstes Steak essen darfst, musst Du erst Bienen kauen, sie mit Whisky herunterspülen und das Whiskyglas zerkauen ... eine Alternative mag es sein ... > Punkt 1 ist die Grundlage, das sollte man auf jeden Fall beherrschen, > auch wenn man später darauf aufbauend sich viele Dinge automatisiert > (z.B) bestimmte make targets die man geschrieben hat später bequem in > der IDE mit nem Mausklick startet oder dergleichen. Warum sollte man bei einfachen Controllern, die man ab und zu fürs Basteln benutzt, solche Dinge beherrschen? Ich gehe mal davon aus, dass er nicht Informatiker/Ingenieur werden will, sondern ab und zu in der Freizeit mal was aufbauen/ausprobieren will. > Wenn Du wirklich in das Thema einsteigen willst dann fange bei Punkt 1 > an und bleibe dort für mindestens 6 Monate, solange bis Dich dort nichts > mehr schrecken kann. Das ist interessant und macht Spaß. Masochisten vielleicht, mag sein, dass die Spaß daran haben ... 99 % der Anfänger haben das Hobby spätestens nach den sechs Monaten in die Ecke geschmissen. (oder sind zu Arduino oder zum AVR-Studio gewechselt) Wir haben nicht mehr die 80-er Jahre ...
F. Fo schrieb: > wenn das wirklich > schneller läuft. Darum gehts nicht. Es geht darum daß man den Pelz nicht waschen kann ohne ihn nass zu machen. Darum gehts. Mal ganz davon abgesehen daß ein einfaches Makefile für ein einfaches Hello-World um Größenordnungen einfacher zu handhaben und vollständig zu verstehen ist als eine komplexe IDE mit all ihren Befindlichkeiten und internen undurchsichtigen Problemchen oder Behinderungen. Daher ist etwas so simples und einfach zu beherrschendes wie ein Makefile bei weitem der bessere Einstiegspunkt für einen Anfänger.
google schrieb: > Wir haben nicht mehr die 80-er Jahre ... Eben!!! Diese ganzen Schwätzer hier. Möchte mal sehen, ob die auch alle ihre Zahnriemen vom Auto selbst wechseln und Kopfdichtungen oder was auch immer selbst reparieren. Wer ein Auto fahren will braucht neben dem Führerschein nur das Wissen was die Kontrolllampen aussagen, wo die Betriebsstoffe und welche wo rein kommen und wo die nächste Werkstatt ist. Das wird auch sicher die Mehrheit der Autofahrer sein.
F. Fo schrieb: > Wie weit die Meinungen doch auseinander liegen können. Diesen > kryptischen Scheiß mit dem Makefile würde ich nie wieder anfassen und > einem Anfänger gar nicht erst empfehlen. > Das Studio, in der aktuellsten Version, würde ich jedem Anfänger > empfehlen. Denn damit klappt schon mal dieser Einstieg. Volle Zustimmung. Wobei ich ergänzen möchte dass damit durchaus auch Profis arbeiten. Und wäre der Compiler nicht GCC, sondern der IAR, wäre das Studio die beste zur Verfügung stehende Entwicklungsumgebung die es zZt. gibt. Wer meint es sei nötig in irgendwelchen MAKE's herunzucoden der kann das auch beim Studio machen. Auf diese Art kann dann,wenn man gerne Resourcen verschwendet und meint einen mikrokontroller unbedingt in C++ programmieren zu müssen die kompletten Arduino Libs für seine Prijekte verwenden.
Bernd K. schrieb: > Außerdem hat sie den Namen > "Entwicklungsumgebung" nicht verdient weil ihr dafür selbst die > grundlegendsten Dinge fehlen. Selbst ein mittelmäßig guter Texteditor > wäre wahrscheinlich auf Dauer ergonomischer und hilfreicher als diese > vollkommen sinnfreie Arduino-Software. Das magst Du bestimmt auch noch erklären ...
F. Fo schrieb: > Wer ein Auto fahren will braucht neben dem Führerschein Genau. Und das ist in meinem Beispiel eben das Wissen um Makefiles, Compiler, Linker, etc. Das ist die Mindestgrundlage, darum kommst Du nicht rum. Der Vorschlag erstmal ohne irgendwelches Vorwissen direkt mit der IDE anzufangen und dann damit planlos herumzufuhrwerken entspricht in Deinem Vergleich der Benutzung eines Fahrzeugs ohne zunächt mal wenigstens ein paar Monate lang die grundlegendsten Verkehrsregeln gelernt zu haben um zu verstehen warum, die IDE an irgendeiner Stelle geradeausfahren muss und nicht links abbiegen kann.
Meine Meinung unterscheidet sich die Umgebung von Arduino und Atmel-Studio stark. So dass eine nicht eine Alternative zum anderen Darstellt. Das Arduino hat eher den "BASIC" Touch. Es ist sehr mächtig und einfach, aber auch langsam und unflexibel. Wobei "langsam" nicht "zu langsam" bedeutet, es ist meistens schnell genug. Vieleicht kann man es so grob zusammenfassen: Wenn das Programmieren ein notwendiges Übel ist und ein schnelle Ergebnis wichtig ist: Arduino Bei hoher Flexibilität (alle Atmel-Controller incl. Fuse-Bits) ohne Bootloader: Atmel-Studio Beim Studio ist man auch ganz dicht am Datenblatt des Controllers. Beim Arduino verlässt man sich auf die Library. Wenn man mit dem Studio klar kommt (ist nicht so schwierig), dann lieber damit einsteigen.
google schrieb: > Selbst ein mittelmäßig guter Texteditor >> wäre wahrscheinlich auf Dauer ergonomischer und hilfreicher als diese >> vollkommen sinnfreie Arduino-Software. > > Das magst Du bestimmt auch noch erklären ... Ganz einfach. Die Arduino-Software enthält ein paar grüne Buttons oben am Rand mit fest definierten Funktionen und eine rechteckige Fläche zweifelhafter Funktion in der Mitte. Leider ist jedoch kein gescheiter Texteditor enthalten.
Angehängte Dateien:
-
screenshot.jpg
60 KB
Bernd K. schrieb: > Ganz einfach. Die Arduino-Software enthält ein paar grüne Buttons oben > am Rand mit fest definierten Funktionen und eine rechteckige Fläche > zweifelhafter Funktion in der Mitte. Leider ist jedoch kein gescheiter > Texteditor enthalten. Scheint wohl nicht ganz zu stimmen, siehe screenshot ... Die Arduino-IDE ähnelt vom Funktionsumfang her notepad bzw. Wordpad von Windows ... kann zusätzlich z.B. Syntax-highlighting, Autoformat usw. Was fehlt, um Programme zu schreiben?
Das Studio ist dem Arduino in jedem Fall vorzuziehen, aber Makefile? Ich habe mir zwei Tage und zwei Nächte damit um die Ohren gehauen. Kaum änderst du was und schon musst du an diesem blöden Makefile rum schnitzen. Nein Danke, ganz schlechte Empfehlung. @Thomas Holmes Thomas, ich lese deine Beiträge gern, denn du hast einen gesunden Menschenverstand und stehst im Leben.
Man könnte auch sagen, bevor du in einem Topf kochst, dann dengel dir einen. Und schon kommt der nächste um die Ecke und verlangt, dass du erstmal Stahl gießen lernen musst. Man sollte immer die Mittel nehmen, die einem das Arbeiten leicht machen und dabei alle Möglichkeiten offen lassen.
F. Fo schrieb: > Man sollte immer die Mittel nehmen, die einem das Arbeiten leicht machen > und dabei alle Möglichkeiten offen lassen. Sag ich doch: Makefile: Maximal einfach, maximal übersichtlich und alle Möglichkeiten offen.
Bernd K. schrieb: > Sag ich doch: Makefile: Maximal einfach, maximal übersichtlich und alle > Möglichkeiten offen. Schönes Beispiel für ideologische Scheuklappen ... ... oder soll ich eher kindisch ("ich hab aber recht, egal, was Du sagst") dazu sagen? Der TE wird wohl eh seinen thread nicht wiederfinden und wenn doch, schon lange verschwunden sein.
Ein Glaubenskrieg! Fein! Im Ernst: Ich habe schon bescheidende IDEs gesehen/genutzt, z.B. SUCOS4 Grausam! Aber tuts. Und so mag es auch so manchem mit der Arduino IDE gehen. Oder mit Makefiles. Grüne Tapeten, Rauhfaser, Putz .... Bridgestone oder Michelin? Über Geschmack kann man vortrefflich streiten. Aber keine Einigung erzielen.
google schrieb: > Bernd K. schrieb: >> Sag ich doch: Makefile: Maximal einfach, maximal übersichtlich und alle >> Möglichkeiten offen. > > Schönes Beispiel für ideologische Scheuklappen ... Scheuklappen? Ich habe die Realität gesehen und die Umstellung aller Builds von wackeligem IDE-Voodoo (das nur in der Version x.y.z funktioniert und nur wenn auch bla und blub installiert sind und foobaz konfiguriert ist) auf pures simples make hat alles so viel einfacher zu handhaben und reproduzierbarer gemacht daß es schon kaum noch in Worte zu fassen ist. Das heißt nicht daß ich nicht jeden Tag eine IDE zum arbeiten am Code verwende, selbstverständlich tue ich das wegen der vielen Helferlein beim Schreiben, Suchen, Finden, Erklären, etc, jedoch der Superkleber der alles zusammenhält ist ein übersichtliches kleines aber feines Makefile und nicht mehr ein undurchsichtiges proprietäres Etwas in einer IDE dessen reproduzierbares Funktionieren von tausend Sachen und Konfigurationen beeinflusst wird die über dutzende von Dialogen verteilt sind, nein bei mir stehen die in 3 oder 4 glasklaren knackig kurz und unmißverständlich formulierten Regeln in einer einzigen kurzen menschenlesbaren Datei. Würdest Du mal Deine Scheuklappen absetzen dann hättest Du eine Chance das irgendwann auch zu erkennen.
Ich bin ganz dem Bernd seiner Meinung, ich würde meine Makefiles (oder die Kontrolle darüber) auch niemals mehr hergeben (genausowenig wie meinen emacs, aber das ist eine andere Geschichte). ich verstehe aber die Ablehnung gegen makefiles, und ich glaube zu wissen woher die kommt: Weil die "Templates" für Makefiles unglaublich komplex sind, vor 17-facher Indirektion nur so strotzen, riesig und unübersichtlich sind. Dafür können sie Kaffee kochen. Aber das braucht keiner. Da nehme ich auch die tutorials hier nciht aus meiner Kritik aus: Auch diese makefiles sind meiner Meinung nach für einen Anfänger unbrauchbar, ein Fortgeschrittener wird sie sowieso auf 5% eindampfen. Meine makefiles (und ich hab viele davon) sehen bis auf eine Zeile (welche Source-Files hab ich) im wesentlichen gleich aus. Mahc ich ein neues Projekt, kopier ich das Makefile, und ändere/ergänze sie Angaben zu den Sourcen, maximal schau ich noch ob die libm gelinkt werden soll oder nicht. beispiel gefällig?
1 | MCU = atmega328p |
2 | F_CPU = 12000000UL |
3 | |
4 | SOURCES = main.c uart.c qprintf.c sample.sx fft.sx |
5 | |
6 | CFLAGS = -W -Wall -Wextra -std=gnu99 -Os -flto -fshort-enums -fno-strict-aliasing -fverbose-asm -save-temps -Wl,-Os,-flto,--relax,--gc-sections |
7 | |
8 | COMPILE = avr-gcc $(CFLAGS) -DF_CPU=$(F_CPU) -mmcu=$(MCU) |
9 | |
10 | all: main.hex |
11 | |
12 | main.hex: $(SOURCES) |
13 | $(COMPILE) -o main.elf $(SOURCES) -lm |
14 | avr-objcopy -O ihex -j .text -j .data main.elf main.hex |
15 | avr-size --format=avr --mcu=$(MCU) main.elf |
16 | |
17 | flash: all |
18 | avrdude -c stk500v2 -P /dev/ttyUSB1 -p atmega328p -q -U flash:w:main.hex:i |
Das sind 12 (zwölf) Zeilen, wirklich relevant sind die ersten drei. Einfach und übersichtlich.
:
Bearbeitet durch User
Bernd K. schrieb: > nicht mehr ein undurchsichtiges proprietäres Etwas in einer > IDE dessen reproduzierbares Funktionieren von tausend Sachen und > Konfigurationen beeinflusst wird die über dutzende von Dialogen verteilt Du sprichst hier aber nicht von der Arduino-Umgebung. Ja, ich verstehe Deine Ausführungen zum makefile und widerspreche ihnen auch nicht, aber trotzdem ist das kein anfängertauglicher Ansatz und für einen Anfänger nur mit sehr hoher Motivation (Studium, Lehre) zu bewältigen. Um beim bereits bemühten Verkehrsbeispiel zu bleiben: Die C-Syntax formt die Verkehrsregeln, Dein makefile ist das Motorsetup, nicht Verkehrsregel. Fahren (programmieren) kann man, ohne das Standard-Motorsetup zu kennen oder gar zu modifizieren. Wenn man dann fahren gelernt hat, kann man natürlich auch am Motor schrauben oder ihn wechseln, um diesen besser oder schneller zu machen.
Und hier ist beispielhaft mal ein makefile für nen Arm (STM32F401RE Nucleo Demo board), ist zwar nicht AVR aber das Prinzip ist das selbe, Unkompliziertheit und Klarheit in ihrer reinsten Form:
1 | ######################################## |
2 | ## bare bones makefile for ARM Cortex ## |
3 | ######################################## |
4 | |
5 | NAME = stm32-demo |
6 | |
7 | SRCS = $(wildcard src/*.c) |
8 | SRCS += $(wildcard src/*.s) |
9 | |
10 | INCDIRS = inc/ |
11 | INCDIRS += stm_inc/ |
12 | |
13 | DEFINES = -DSTM32F401xE |
14 | DEFINES += -DNO_LIBC_INIT_ARRAY |
15 | |
16 | LSCRIPT = stm_inc/gcc.ld |
17 | |
18 | BUILDDIR = build/ |
19 | |
20 | CFLAGS = -ffunction-sections |
21 | CFLAGS += -mlittle-endian |
22 | CFLAGS += -mthumb |
23 | CFLAGS += -mcpu=cortex-m4 |
24 | CFLAGS += -mfloat-abi=hard |
25 | CFLAGS += -mfpu=fpv4-sp-d16 |
26 | CFLAGS += -std=c99 |
27 | CFLAGS += -ggdb |
28 | CFLAGS += -Os |
29 | CFLAGS += -flto |
30 | |
31 | LFLAGS = --specs=nano.specs |
32 | LFLAGS += --specs=nosys.specs |
33 | LFLAGS += -Wl,--gc-sections |
34 | LFLAGS += -T$(LSCRIPT) |
35 | LFLAGS += -lm |
36 | |
37 | WFLAGS = -Wall |
38 | WFLAGS += -Wextra |
39 | WFLAGS += -Warray-bounds |
40 | WFLAGS += -Wno-unused-parameter |
41 | |
42 | GCCPREFIX = arm-none-eabi- |
43 | CC = $(GCCPREFIX)gcc |
44 | OBJCOPY = $(GCCPREFIX)objcopy |
45 | OBJDUMP = $(GCCPREFIX)objdump |
46 | SIZE = $(GCCPREFIX)size |
47 | |
48 | OOCD = openocd |
49 | OOCD_CFG = board/st_nucleo_f401re.cfg |
50 | |
51 | INCLUDE = $(addprefix -I,$(INCDIRS)) |
52 | OBJS = $(addprefix $(BUILDDIR),$(addsuffix .o,$(basename $(SRCS)))) |
53 | |
54 | |
55 | ########### |
56 | ## rules ## |
57 | ########### |
58 | |
59 | .PHONY: all |
60 | all: clean |
61 | all: $(OBJS) |
62 | all: $(BUILDDIR)$(NAME).elf |
63 | all: $(BUILDDIR)$(NAME).bin |
64 | all: $(BUILDDIR)$(NAME).s19 |
65 | all: $(BUILDDIR)$(NAME).lst |
66 | all: print_size |
67 | |
68 | .PHONY: install |
69 | install: all |
70 | $(OOCD) -f $(OOCD_CFG) -c "program $(BUILDDIR)$(NAME).s19 verify reset" |
71 | |
72 | .PHONY: clean |
73 | clean: |
74 | $(RM) -rf $(BUILDDIR)* |
75 | |
76 | # compiler |
77 | $(BUILDDIR)%.o: %.c |
78 | @mkdir -p $(dir $@) |
79 | $(CC) -c -o $@ $(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS) $^ |
80 | |
81 | # assembler |
82 | $(BUILDDIR)%.o: %.s |
83 | @mkdir -p $(dir $@) |
84 | $(CC) -c -x assembler-with-cpp -o $@ $(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS) $^ |
85 | |
86 | # linker |
87 | $(BUILDDIR)%.elf: $(OBJS) |
88 | $(CC) -o $@ $(CFLAGS) $(LFLAGS) $^ |
89 | |
90 | %.bin: %.elf |
91 | $(OBJCOPY) -O binary -S $^ $@ |
92 | |
93 | %.s19: %.elf |
94 | $(OBJCOPY) -O srec -S $^ $@ |
95 | |
96 | %.lst: %.elf |
97 | $(OBJDUMP) -D $^ > $@ |
98 | |
99 | .PHONY: print_size |
100 | print_size: $(BUILDDIR)$(NAME).elf |
101 | $(SIZE) $(BUILDDIR)$(NAME).elf |
Bernd K. schrieb: > Unkompliziertheit und Klarheit in ihrer reinsten Form lol Das ist für einen Profi sicher an Klarheit und Übersichtlichkeit kaum zu überbieten, aber ein Anfänger fängt jetzt an zu fragen, wozu brauche ich die ganzen Dollarzeichen und kryptischen Abkürzungen? Was ist OBJS und LFLAGS und dieses komische Dachzeichen da drin? Wie geb ich das überhaupt ein? Muss das alles sein? Kann ich nicht einfach mein Blink-Programm in der IDE eingeben und dann mit den Standardeinstellungen kompilieren lassen?
google schrieb: > aber ein Anfänger fängt jetzt an zu fragen Irgendwo muss man anfangen und das ist ein guter Anfang. Von der Syntax hat man bereits nach einem Tag eine grobe Idee und nach einer Nacht düber schlafen beginnt man langsam die dahinter stehende Philosophie zu erahnen. Die restlichen 6 Monate verbringt man dann damit sich zu erfreuen wie einem jeden Tag neue strahlende Lichter aufgehen und sich jeden Tag neue ungeahnte Möglichkeiten eröffnen und wie sich zuvor bereits irgendwo mal aufgeschnappte Puzzleteile sich plötzlich wie von selbst zu einem Bild zusammenfügen. Ein unbeschreibliches und unvergessliches Erlebnis, man sollte auf gar keinen Fall darauf verzichten.
Bernd K. schrieb: > Irgendwo muss man anfangen und das ist ein guter Anfang. Von der Syntax > hat man bereits nach einem Tag eine grobe Idee und nach einer Nacht > düber schlafen beginnt man langsam die dahinter stehende Philosophie zu > erahnen. In dieser Zeit habe ich selbst als absoluter, aber nicht völlig dummer Anfänger schon die ersten Sensoren am Arduino und zeige die Messergebnisse auf einem LCD-Modul an. Bei Dir habe ich noch keine einzige Zeile AVR programmiert. > wie einem jeden Tag neue strahlende Lichter aufgehen und sich jeden Tag > neue ungeahnte Möglichkeiten eröffnen > Ein unbeschreibliches und unvergessliches Erlebnis, man sollte auf gar > keinen Fall darauf verzichten. Von dem Zeug, was Du da nimmst, hätte ich auch gern was. Sorry, aber am makefile sich ergötzen (das andere Wort habe ich dann doch weggelassen) ist nur was für absolut nerdige freaks. Das ist ein (sicher wichtiges und notwendiges) Hilfsmittel für die Programmierung, aber auch nicht mehr. Als Anfänger bin ich schon froh, wenn ich verstehe, warum ich die Befehle meines Programmes genau so in der Reihenfolge und genau in dieser Schreibweise eintippen muss, warum der Computer keine Tippfehler verzeiht usw. Wo in Windows ist überhaupt die (wie heißt das?) Konsole?
google schrieb: > Wo in Windows ist überhaupt die (wie heißt das?) Konsole? Nur zur Klarstellung, ich weiß, wo ich die Konsole finde und was das ist ... das waren eher Beispiele für Fragen, die ich als Anfänger stellen würde ...
@ Bernd K. (prof7bit) >> aber ein Anfänger fängt jetzt an zu fragen >Irgendwo muss man anfangen und das ist ein guter Anfang. SCHWACHSINN!!! Das ist Folter! Ein Anfänger und auch Fortgeschrittener will nur eins! Quelltext eintippen, Taste für BUILD all, fertig! Unf genau DAS tun IDEs. Man stellt bestenfalls noch den Prozessortyp und das Optimierunglevel ein fertig. Und ob du es glaubst oder nciht, damit können sogar Profis leben und produktiv Firmware erzeugen! WOW! > Von der Syntax >hat man bereits nach einem Tag eine grobe Idee und nach einer Nacht >düber schlafen beginnt man langsam die dahinter stehende Philosophie zu >erahnen. Diesen Krümelkram interssiert keine Sau! Die meisten wollen das Zielproblem lösen und sich nicht sinnlos mit kryptischen Innereien des Werkzeugs auseinandersetzen. Es gibt auch normale Leute, die nicht immer in den Innereien iheres Compiler/Linux/whatever rummurksen wollen! Ich hab noch nie ein Makefile geschrieben und dennoch ziemlich viele, produktive AVR-Programme und anderen Kram programmiert. Nach deiner Aussage wäre das unmöglich. Wir leben im 21. Jahrhundert anno domini. Nicht in den wilden 1960ern mit LSD, Love&Peace & mainframes.
Bernd K. schrieb: > F. Fo schrieb: >> Wer ein Auto fahren will braucht neben dem Führerschein > > Genau. Und das ist in meinem Beispiel eben das Wissen um Makefiles, > Compiler, Linker, etc. Das ist die Mindestgrundlage, darum kommst Du > nicht rum. Tja, da muss ich mich wohl wundern, dass ich seit Jahren ohne Makefiles auskomme ...
Falk Brunner schrieb: > Wir leben im 21. Jahrhundert anno domini. Nicht in den wilden 1960ern > mit LSD, Love&Peace & mainframes. Schade.... ;-) MfG Paul
lächler schrieb: > Tja, da muss ich mich wohl wundern, dass ich seit Jahren ohne Makefiles > auskomme ... Ich dagagen wundere mich, dass ich seit vielen Jahren ohne IDE auskomme (obwohl, böse Zungen behaupten, Emacs wäre eine geniale IDE, nur der Editor ist scheisse :-) Falk Brunner schrieb: > Wir leben im 21. Jahrhundert Das Argument kann ich nicht nachvollziehen... Falk Brunner schrieb: > Ein Anfänger und auch Fortgeschrittener will nur eins! Quelltext > eintippen, Taste für BUILD all, fertig! Und dann hier rumheulen, warum nix funktioniert, bis man zum gefühlt hudertdreiundzwanzigtaudsendsten Mal draufkommt dass F_CPU dreimal unterschiedlich definiert ist. Übrigens, wo war schnell die Taste für Build, Flash, Fuse, Run im SichtbarenStudio?
Falk Brunner schrieb: > Ein Anfänger und auch Fortgeschrittener will nur eins! Quelltext > eintippen, Taste für BUILD all, fertig! Unf genau DAS tun IDEs. Und Makefiles (handgeschrieben wenn klein oder autotools, cmake, whatever wenn komplizierter) tun das auch, mit dem zusätzliche Vorteil daß man auch genau sehen und nachvollziehen kann was sie tun und warum sie es tun. Und weil das Ergebnis dann reproduzierbar ist, und gerade das ist wichtig für Anfänger, sonst gibts nur Frust. Was glaubst Du wohl warum so ziemlich jedes ernstzunehmende Softwareprojekt an dem mehr als ein einzelner Held herumwurschteln ein vollkommen IDE-agnostisches Build-System verwendet und sich sich nicht auf den magischen "Build"-Button der XY-IDE? Glaubst Du die tun das um sich gegenseitig zu foltern? Die tun das weil es Erleichterung bringt, weil nichts anderes in irgendeiner Weise praktikabel wäre und weil es auch morgen noch genauso funktionieren soll wie heute! Und ich hab doch weiter oben schon geschrieben, gleich in meiner Eröffnung, hast Du das etwa überlesen? Ich schrieb: Wenn Du stattdessen lieber nur kurzfristig mit einem vorgefertigten Spielzeug ein bisschen rumspielen willst ohne irgend ein tieferes Verständnis zu erlangen oder irgendeinen Einfluss darauf zu haben dann spiel halt damit rum. Und wenn Du lieber Tiefkühlpizza in den Ofen schiebst anstatt sie selber zu machen ist das auch ok. Du kannst sogar einen anheuern der an Deiner Stelle in mit der Maus der IDE auf den "BUILD"-Button klickt hast Du gar nix mehr damit zu tun, ist alles nicht schlimm, zwingt Dich überhaupt keiner zu irgendwas. Ich hab nur einen Vorschlag gemacht wie man sich die Sache einfacher machen kann wenn man tatsächlich ernsthaft in das Thema einsteigen will. Und wenn man nicht will dann halt eben nicht. Soll jeder machen was er will.
Michael Reinelt schrieb: > Ich dagagen wundere mich, dass ich seit vielen Jahren ohne IDE auskomme Weil es damals, als Du gelernt hast, nicht anders ging und Du bei dem, was Du einmal gelernt hast, geblieben bist. Das ist, bei Licht betrachtet, nicht schmeichelhaft für Dich. > Das Argument kann ich nicht nachvollziehen... Aus Deiner Sicht kann ich das gut verstehen ... warum was Neues machen, wenn das alte noch funktioniert? Ich hoffe nur, das Du das nicht beruflich machst ...
@ Michael Reinelt (fisa) >> Tja, da muss ich mich wohl wundern, dass ich seit Jahren ohne Makefiles >> auskomme ... >Ich dagagen wundere mich, dass ich seit vielen Jahren ohne IDE auskomme >(obwohl, böse Zungen behaupten, Emacs wäre eine geniale IDE, nur der >Editor ist scheisse :-) Es gibt auch heute noch Naturvölker, die auf einem nahezu steinzeitlichen Niveau leben. Es sei ihnen gegönnt. Ich habe daran wenig Interesse. >> Wir leben im 21. Jahrhundert >Das Argument kann ich nicht nachvollziehen... Das erklärt einiges ;-) >> Ein Anfänger und auch Fortgeschrittener will nur eins! Quelltext >> eintippen, Taste für BUILD all, fertig! >Und dann hier rumheulen, warum nix funktioniert, bis man zum gefühlt >hudertdreiundzwanzigtaudsendsten Mal draufkommt dass F_CPU dreimal >unterschiedlich definiert ist. Ach herje. >Übrigens, wo war schnell die Taste für Build, Flash, Fuse, Run im >SichtbarenStudio? F7 Build Im alten AVR tudio konnte man mit einem Mausclick ein Autoprogramm starten, im neuen Atmelstudio gib es das anscheinend nicht, man muss erst das Programmierfenster aufclicken und dort auch dreimal clicken. Nicht schön, aber erträglich. Und glaubst du, weil du vielleicht DREI Clicks einsparst, bist du rasend schnell in der Entwicklung? Dream on ;-)
google schrieb: > Ich hoffe nur, das Du das nicht beruflich machst ... Du hoffst daß die Konkurrenz keine richtigen Werkzeuge einsetzt? Das kann ich verstehen. Geht mir genauso.
Falk Brunner schrieb: > Und glaubst du, weil du vielleicht DREI Clicks einsparst, bist du rasend Er spart sich ALLE Klicks, nicht nur 3.
@ Bernd K. (prof7bit) >> Ein Anfänger und auch Fortgeschrittener will nur eins! Quelltext >> eintippen, Taste für BUILD all, fertig! Unf genau DAS tun IDEs. >Und Makefiles (handgeschrieben wenn klein oder autotools, cmake, >whatever wenn komplizierter) tun das auch, mit dem zusätzliche Vorteil >daß man auch genau sehen und nachvollziehen kann was sie tun und warum >sie es tun. Das brauchen und wollen die allermeisten Leute NICHT! > Und weil das Ergebnis dann reproduzierbar ist, und gerade >das ist wichtig für Anfänger, sonst gibts nur Frust. Schwachsinn die 2. >Was glaubst Du wohl warum so ziemlich jedes ernstzunehmende >Softwareprojekt an dem mehr als ein einzelner Held herumwurschteln ein >vollkommen IDE-agnostisches Build-System verwendet und sich sich nicht >auf den magischen "Build"-Button der XY-IDE? Bla. Auch dort werden IDEs verwendet, nicht zu knapp. > Glaubst Du die tun das um >sich gegenseitig zu foltern? Die tun das weil es Erleichterung bringt, >weil nichts anderes in irgendeiner Weise praktikabel wäre und weil es >auch morgen noch genauso funktionieren soll wie heute! Das bei bestimmten, ziemlich tief in im System angesiedelten Projekten ein manuelles Makefile Vorteile bieten KANN, ist dich gar nicht die Frage! Sondern ob es ANFÄNGER brauchen bzw. ob es für sie Vorteile bringt. Die Antwort ist NEIN! >Und ich hab doch weiter oben schon geschrieben, gleich in meiner >Eröffnung, hast Du das etwa überlesen? Ich schrieb: Wenn Du stattdessen >lieber nur kurzfristig mit einem vorgefertigten Spielzeug ein bisschen >rumspielen willst ohne irgend ein tieferes Verständnis zu erlangen Totschlagargument! Ich arbeite seit Jahren OHNE Makefile und habe in der Zeit deutlich mehr als Hello World programmiert! Nein, irgendwelche Kernellibs etc. habe ich nicht gemacht. > oder >irgendeinen Einfluss darauf zu haben dann spiel halt damit rum. Und wenn >Du lieber Tiefkühlpizza in den Ofen schiebst anstatt sie selber zu >machen ist das auch ok. Du baust lieber das Getreide und Gemüse an, fänsgt deine Sardellen selber, ebenso züchtest du deine Schwein für den Schinken selber. Viel Spaß Ich geh liber in die Pizzeria und nutze die Vorteile einer arbeitsteiligen Gesellschaft, auch wenn ich dabei nicht im Detail Einfluß auf den Pizzateig, den Schinken und den Thunfisch nehmen kann. Wenn das Endprodukt schmeckt komme ich wieder. Wenn nicht, war es ein Versuch. > Du kannst sogar einen anheuern der an Deiner >Stelle in mit der Maus der IDE auf den "BUILD"-Button klickt hast Du gar >nix mehr damit zu tun, ist alles nicht schlimm, zwingt Dich überhaupt >keiner zu irgendwas. Bla. Wenn du es halt rustikal magst, bitte sehr. Ich lebe in der Moderne. >Ich hab nur einen Vorschlag gemacht wie man sich die Sache einfacher >machen kann FALSCH! Du hast und willst nicht begreifen, dass der EINSTIEG mit einem selbstgeklöppelten makefile nicht sinnvoll und deutlich aufwändiger ist. Weil auch du schon lange vergessen hast, wie du vor Jahrzehnten angefangen hast und auch für dich jeder Begriff erstmal ziemliches Neuland war. Und auch DU wärst für eine IDE dankbar gewesen. > wenn man tatsächlich ernsthaft in das Thema einsteigen >will. Schon wieder Quark. Das beweisen tausende von (semi)professionellen IDE Anwendern. Den Leuten fehlt nichts. Nicht jeder will und muss den Compiler bis in die allerletzte Kommandozeilenoption ausreizen. > Und wenn man nicht will dann halt eben nicht. Soll jeder machen > was er will. Genau, und du hast trotzdem Recht. Jaja.
@ Bernd K. (prof7bit) >> Und glaubst du, weil du vielleicht DREI Clicks einsparst, bist du rasend >Er spart sich ALLE Klicks, nicht nur 3. Sag doch gleich, worum es WIRKLICH geht! In deinem Herzen hasst du doch eigentlich alle modernen GUIs. Den Herz schlägt für die Unix-Konsole, davon hat man doch schließlich problemlos ein Dutzend auf den Funktionstasten. Dieser moderne Kram ist doch nur was für Weicheier! ISP Flash und ICE Debugger? Teufelszeug! Richtige EEPROMs mit Glasfenster und UV-Löschgerät nutz der echte Mann! Debugging per RS232, mehr ist Verrat!
google schrieb: > Weil es damals, als Du gelernt hast, nicht anders ging und Du bei dem, > was Du einmal gelernt hast, geblieben bist. Das ist, bei Licht > betrachtet, nicht schmeichelhaft für Dich. Kommen wir dann wieder über die Gürtellinie? Geht das für dich? > Aus Deiner Sicht kann ich das gut verstehen ... warum was Neues machen, > wenn das alte noch funktioniert? Zu jeder zeit gab es Möglichkeiten etwas schlecht, gut oder besser zu machen. Zu jeder zeit ist das bessere der Feind des guten. Das bessere. nicht das Modernere. > Ich hoffe nur, das Du das nicht beruflich machst ... Und wieder die Gürtellinie... nebenbei: ich mach das beruflich, wenn auch nicht fokussiert. Und ich verdiene verdammt viel Geld damit. Falk Brunner schrieb: > Naturvölker komm, Falk, das hast du nicht notwendig.... Falk Brunner schrieb: > man muss erst das Programmierfenster aufclicken und dort auch dreimal clicken. Ist zwar nebensächlich (und vermutlich erträglich) aber in der zeit wo du dein Dings hochgefahren hast, hab ich schon drei Läufe hinter mir, den Output vom Uart im Octave und neue Korrektur-Koeffizienten berechnet und ins Source-File automatisch eingefügt. Und das beim Kunden in der Mittagspause per ssh auf den Rechner mit angehängtem AVR der bei mir im Keller steht. Aber wir wollen jetzt nicht kindisch werden, oder? Back to Topic: auch ich hab mein erstes "Blink" am Arduino gemacht. Deswegen schließe ich mich generell nicht dem Arduino-Bashing an. Aber wenn man als Anfänger sich weiterentwickeln will, so ist das mit einem Makefile mindestens genauso gut möglich wie mit einer der IDEs. Nicht dass ich IDEs grundsätzlich für schlecht halte (oh doch, Vosual Studio schon :-). Ich bin halt produktiver (und zwar signifikant produktiver) ohne, bzw. mit "meiner" IDE. Das muss jeder "fortschreitende" Anfänger für sich entscheiden. Aber es ist aus meiner Sicht falsch, dass ein (vernünftiges) Makefile nix für Anfänger ist.
:
Bearbeitet durch User
@ Michael Reinelt (fisa) >> Naturvölker >komm, Falk, das hast du nicht notwendig.... Wo ist das Problem? Es ist eine bildliche Darstellung, wenn gleich ein wenig übertrieben. Ich will keinem seine geliebte Kommandozeile und das makefile wegnehmen. Für einen Vollprofi haben diese ihre Berechtigung und Vorteile. Für Anfänger und Fortgeschittene aber nicht. >Back to Topic: auch ich hab mein erstes "Blink" am Arduino gemacht. >Deswegen schließe ich mich generell nicht dem Arduino-Bashing an. Aber >wenn man als Anfänger sich weiterentwickeln will, so ist das mit einem >Makefile mindestens genauso gut möglich wie mit einer der IDEs. Was zum Geier lernt denn ein Anfänger im Makefile? So gut wie keiner will einen Compiler oder wenigstens eine neue IDE ala Eclipse schreiben! Und nur DAZU ist das Ding gut. Wilde Stunts mit zusätlichen sections, compile Optionen etc. machen auch die Wenigsten! Man muss nur den WESENTLICHEN Ablauf eines Compilers verstehen. Dazu reicht ein Blockschaltbild und bissel intelligenter Text. > Nicht >dass ich IDEs grundsätzlich für schlecht halte (oh doch, Vosual Studio >schon :-). Ich bin halt produktiver (und zwar signifikant produktiver) >ohne, bzw. mit "meiner" IDE. Jaja. Deswegn quälst du dich auch mit Inlineassember und ähnlichen Scherzen. > Das muss jeder "fortschreitende" Anfänger >für sich entscheiden. Aber es ist aus meiner Sicht falsch, dass ein >(vernünftiges) Makefile nix für Anfänger ist. Es ist nix für Anfänger! Was interessieren die Compileroptionen und Reihenfolgen im Compileprozess? Dazu noch die vorsintflutliche Syntax mit Positionsensitivität! Siehe oben! Ich wiederhole mich.Ich bin auch kein Softwerker, habe nie ein makefile geschieben und dennoch immer zum Ziel gekommen. Und nicht gerade so und ewig spät, sondern SCHNELL und performant! Wie ist das mit einer IDE möglich?
Michael Reinelt schrieb: > Kommen wir dann wieder über die Gürtellinie? Geht das für dich? Ich passe mich meinem Gegenüber an, damit er mich versteht. > Und dann hier rumheulen, warum nix funktioniert, bis man zum gefühlt > hudertdreiundzwanzigtaudsendsten Mal draufkommt dass F_CPU dreimal > unterschiedlich definiert ist. > > Übrigens, wo war schnell die Taste für Build, Flash, Fuse, Run im > SichtbarenStudio? ... denn das glänzt nur so vor Sachlichkeit ...
Falk Brunner schrieb: > Ich will keinem seine geliebte Kommandozeile und das makefile wegnehmen. Dann sind wir uns ja in dem Punkt einig: ich will auch niemandem seine IDE wegnehmen (und jetzt nicht wegen meines beruflichen Vorteils ;-) Falk Brunner schrieb: > Für Anfänger und Fortgeschittene aber nicht. Da sind wir halt nicht einer Meinung... Falk Brunner schrieb: > Jaja. Deswegn quälst du dich auch mit Inlineassember und ähnlichen > Scherzen. Ach ja, ich vergaß: Inline-Assembler nimmt einem die IDE ja ab :-) im ernst - das hat damit jetzt aber ungefähr ziemlich genau gar nix zu tun, oderrr? Falk Brunner schrieb: > [...] immer zum Ziel gekommen. [...] Wie ist das mit einer IDE > möglich? Hätte das irgendwer bezweifelt? (ich nicht) google schrieb: > Ich passe mich meinem Gegenüber an, damit er mich versteht. Nimm den Spiegel weg...
Michael Reinelt schrieb: > Nimm den Spiegel weg... Dann seh ich Dich nicht mehr, denn direkt anblicken wollte ich das Grauen schon lange nicht mehr ... wir können uns jetzt noch lange mit billiger Polemik zupflastern. Aber Fakt bleibt, dass Arduino einen unschlagbar preiswerten, guten und didaktisch klugen Einstieg für den (absoluten) Laien bietet, den Du sonst kaum findest. Dabei handelt es sich beim Arduino-Konzept eigentlich nur um eine Abstraktion, denn unter der "Motorhaube" werkelt mit dem gcc und den diversen ATMegas/MSP430-launchpads und was sonst noch arduino-/energiakompatibel ist, altbekannte Technik. Wem Arduino dann nicht mehr reicht, der wird das über kurz oder lang selbst aufbohren und fragen bzw. sich schlau lesen, je nach Charakter ...
google schrieb: > wir können uns jetzt noch lange mit > billiger Polemik zupflastern Wir? hast du gerade "wir" gesagt?
Mußt jetzt aber allein mit Dir weiterspielen, ich hab wichtigeres zu tun, das Kino ruft ...
@ Michael Reinelt (fisa) >> Für Anfänger und Fortgeschittene aber nicht. >Da sind wir halt nicht einer Meinung... Sieht wohl so aus. Ist aber nicht schlimm. Pluralismus halt. >> Jaja. Deswegn quälst du dich auch mit Inlineassember und ähnlichen >> Scherzen. >Ach ja, ich vergaß: Inline-Assembler nimmt einem die IDE ja ab :-) Nein, aber . . . >im ernst - das hat damit jetzt aber ungefähr ziemlich genau gar nix zu >tun, oderrr? Doch. Nämlich mit Effizienz und sinnvoller Wahl der Werkzeuge. "Ich bin halt produktiver (und zwar signifikant produktiver) >ohne, bzw. mit "meiner" IDE." Ein makefile ist ein Profiwerkzeug, dass man nur sinnvoll nutzt, wenn es WIRKLICH nötig ist und WIRKLICH substantielle Vorteile bringt. Denn es ist mit VIEL Aufwand verbunden, es zu beherrschen. Ebenso wie Inlineassembler. Niemand wird Getreide anbauen, Mehl mahlen und Brötchen backen, wenn er die auch im Laden in guter Qualität kaufen kann! >> [...] immer zum Ziel gekommen. [...] Wie ist das mit einer IDE >> möglich? >Hätte das irgendwer bezweifelt? (ich nicht) Du nicht, aber der Bernd K.
Bernd K. schrieb: > Und hier ist beispielhaft mal ein makefile für nen Arm (STM32F401RE > Nucleo Demo board), ist zwar nicht AVR aber das Prinzip ist das selbe, > Unkompliziertheit und Klarheit in ihrer reinsten Form: Sorry, aber wenn ich das Makefile sehe wird mir einfach nur schlecht. Nur ein Beispiel für extrem schlechten Stil: Alle C- und Assembler-Files werden blind als benötigte Source betrachtet - wenn man mal ein C-File nur bis zum Assembler-Output kompilieren läßt, z.B. um sich den erzeugten Code genauer anzusehen, dann dürfte das recht unlustig werden. Von dem Ansatz, keine Header-Files zu verwenden bzw. sie im Makefile zu ignorieren und keine Abhängigkeiten der Files untereinander zu kodieren ganz zuschweigen - da tut es auch ein Batchfile, das alles blind durchkompiliert und zusammenlinkt, das dürfte dann sogar zuverlässiger sein als jener Schrotthaufen eines Makefiles.
@ google (Gast) >Aber Fakt bleibt, dass Arduino einen unschlagbar preiswerten, guten und >didaktisch klugen Einstieg für den (absoluten) Laien bietet, den Du >sonst kaum findest. Dabei handelt es sich beim Arduino-Konzept >eigentlich nur um eine Abstraktion, denn unter der "Motorhaube" werkelt >mit dem gcc und den diversen ATMegas/MSP430-launchpads und was sonst >noch arduino-/energiakompatibel ist, altbekannte Technik. Genau! >Wem Arduino dann nicht mehr reicht, der wird das über kurz oder lang >selbst aufbohren und fragen bzw. sich schlau lesen, je nach Charakter >... EBEN! Damit hat man eine sanften Einstieg in die Materie und muss nur schritt für Schritt kleine Stufe erklimmen (sanfte Lernkurve). Mit makefile und Kommandozeile muss man aus dem Stand 2m hoch springen! Ganz toll!
google schrieb: > dass Arduino einen... > ...didaktisch klugen Einstieg für den (absoluten) Laien bietet Bullshit! Das erste was ein Einsteiger bei Arduino gezeigt bekommt ist das Blinken einer LED mit Hilfe der Funktion delay(). Aber sobald er eine zweite simultane Sache dazuprogammieren will merkt er dass das mit delay() nicht funktioniert! Die Funktion delay() hat in einem professionellen Programm absolut nichts zu suchen!
>Die Funktion delay() hat in einem professionellen Programm absolut >nichts zu suchen! Ich weiß nicht warum du daraus unbedingt eine Weltanschauung machen mußt? Btw, du kennst den Unterschied zwischen Hobby und Profession?
@ Max Mustermann (jens2001) >> dass Arduino einen... >> ...didaktisch klugen Einstieg für den (absoluten) Laien bietet >Bullshit! Naja, dazu müsste man es sich genauer ansehen. Ich hab es bisher nur überflogen. >Das erste was ein Einsteiger bei Arduino gezeigt bekommt ist das Blinken >einer LED mit Hilfe der Funktion delay(). Was für einen Anfänger vollkommen OK ist. >Aber sobald er eine zweite simultane Sache dazuprogammieren will merkt >er dass das mit delay() nicht funktioniert! Doch, man muss es den Leuten nur richtig erklären. Geht für den Anfang auch mit delay. https://www.mikrocontroller.net/articles/Multitasking#Ein_einfaches_Beispiel_f.C3.BCr_den_AVR >Die Funktion delay() hat in einem professionellen Programm absolut >nichts zu suchen! Bla. Ich nutze sie auch in professionellen Programmen. Ist immer nur eine Frage das wann, wie und wo!
Falk Brunner schrieb: > @ google (Gast) > >>Aber Fakt bleibt, dass Arduino einen unschlagbar preiswerten, guten und >>didaktisch klugen Einstieg für den (absoluten) Laien bietet, den Du >>sonst kaum findest. Dabei handelt es sich beim Arduino-Konzept >>eigentlich nur um eine Abstraktion, denn unter der "Motorhaube" werkelt >>mit dem gcc und den diversen ATMegas/MSP430-launchpads und was sonst >>noch arduino-/energiakompatibel ist, altbekannte Technik. > > Genau! > >>Wem Arduino dann nicht mehr reicht, der wird das über kurz oder lang >>selbst aufbohren und fragen bzw. sich schlau lesen, je nach Charakter >>... > > EBEN! Damit hat man eine sanften Einstieg in die Materie und muss nur > schritt für Schritt kleine Stufe erklimmen (sanfte Lernkurve). Mit > makefile und Kommandozeile muss man aus dem Stand 2m hoch springen! Ganz > toll! Genau so!!! Diese Makefilejunkies pochen doch nur drauf, weil sie sich den Scheiß mal reinziehen mussten, als es nichts einfacheres gab. Ich habe mich da dermaßen mit gequält. Denn gute Sachen zum lesen gab es nicht. Am Ende funktionierte es ... für einen Controller ... Im Studio mache ich "klick", "klick" und schon funktioniert alles. Genau wie es im Zitat steht, mit Arduino angefangen, heute mit C und gerade will ich Assembler lernen (um die Tiefen zu verstehen). Aber das Werkzeug soll schon fertig sein. Ich baue mir doch auch nicht für jede Arbeit ein neuen Hammer.
Falk Brunner schrieb: >>Aber sobald er eine zweite simultane Sache dazuprogammieren will merkt >>er dass das mit delay() nicht funktioniert! Wie das geht, das steht ein paar Seiten weiter im Buch.
Falk Brunner schrieb: > Bla. Ich nutze sie auch in professionellen Programmen. Ist immer nur > eine Frage das wann, wie und wo! Musste nur ein Relais nach einer gewissen Zeit abfallen lassen und dann eine Led anschalten - mehr nicht. Bevor ich mir den Timer zusammen gebastelt habe, mit Prescaler, habe ich ohne nachzusehen eben ein Delay eingebaut und war fertig. Ganze Schaltung mit Programm, keine halbe Stunde. Kommt immer auf den Zweck an.
An all die Makefile Hasser: Ihr dürft euch auch gerne ein Shell Script schreiben, wenn euch das lieber ist. Für das technische Verständnis wäre das gar nicht mal so schlecht, denn dann weiß man, welche Befehle in welcher Reihenfolge mit welchen Parameter aufgerufen werden müssen, um aus den Quelltexten ein fertiges Programm zu erzeugen. Die integrierten Funktionen sämtlicher IDE's sind für einige meiner Projekte jedenfalls unzureichend. Deswegen habe ich den Umgang mit Makefiles an nur einem Abend gelernt. Doch am Anfang genügte mir das AVR Studio und ich war erstmal froh, mich nicht mit Makefiles herum schlagen zu müssen. Konkretes Beispiel: Ein Perl Script erzeugt C-Quelltext (char-arrays) aus Binärdateien, die Bestandteil des Programms sind. In ein Makefile kann man sowas problemlos einbinden.
@ Stefan Us (stefanus) >An all die Makefile Hasser: Wo siehst du diese? Du leidest wie so viele Zeitgenossen am Schwarz-Weiß Syndrom. Niemand hier HASST die makefiles, sie sind nur für Anfänger und viele Fortgeschrittene weder nötig noch vortielhaft. >Ihr dürft euch auch gerne ein Shell Script >schreiben, wenn euch das lieber ist. Ist das selbe in Grün! > Für das technische Verständnis wäre >das gar nicht mal so schlecht, denn dann weiß man, welche Befehle in >welcher Reihenfolge mit welchen Parameter aufgerufen werden müssen, um >aus den Quelltexten ein fertiges Programm zu erzeugen. Eben DAS interessiert nicht wirklich! Nur dann, wenn man einen Compiler schreiben will. Willst du das? Hast du das schon mal getan? >Die integrierten Funktionen sämtlicher IDE's sind für einige meiner >Projekte jedenfalls unzureichend. Beispiel? > Deswegen habe ich den Umgang mit Makefiles an nur einem Abend gelernt. Das habe ich so meine Zweifel. Und selbst wenn, gilt das sicher nicht für Anfänger. >Doch am Anfang genügte mir das AVR >Studio und ich war erstmal froh, mich nicht mit Makefiles herum schlagen >zu müssen. AHA! >Ein Perl Script erzeugt C-Quelltext (char-arrays) aus Binärdateien, die >Bestandteil des Programms sind. In ein Makefile kann man sowas >problemlos einbinden. Wozu? Wie oft änderst du deine char arrays, um sie immer wieder neu zu erzeugen? Ausserdem hat das mit dem makefile nichts zu tun. Woher die Quellen kommen ist dem egal.
Stefan Us schrieb: > An all die Makefile Hasser: Ihr dürft euch auch gerne ein Shell Script > schreiben, wenn euch das lieber ist. Es gibt eine Menge Leute die brauchen weder das eine, noch das andere. > Die integrierten Funktionen sämtlicher IDE's sind für einige meiner > Projekte jedenfalls unzureichend. Deswegen habe ich den Umgang mit > Makefiles an nur einem Abend gelernt. Ich bin mir sicher die Meisten die den direkten Kontakt mit Make-Files aus guten Gründen meiden wären sicher auch in der Lage das ebenfalls an einem Abend zu verstehen, ebenso wie ich auch DOS an einem Abend begreifen würde, aber einige haben erkannt das es elegantere Wege gibt und DOS kein Mensch mehr braucht. > Konkretes Beispiel: > Ein Perl Script erzeugt C-Quelltext (char-arrays) aus Binärdateien, die > Bestandteil des Programms sind. In ein Makefile kann man sowas > problemlos einbinden. Das man aus einem Makefile andere Skript's oder Programme aufrufen kann ist hier sicher jedem klar. Und was ein CodeWizard in Perl programmiert mit dem ursprünglichen Thema zutun hat bis auf die hier abseits beliebte Selbstdarstellung und Beweihräucherung dürfte nicht nur mir unklar sein. Auch wenn es nichts zur Sache tut für die AutoCode Erzeugung gibts gerade in dem hier oft zitierten AVR Studio weitaus elegantere Lösungen und ganz ohne glyphische MakeFiles.
F. Fo schrieb: > Diese Makefilejunkies pochen doch nur drauf, weil sie sich den Scheiß > mal reinziehen mussten, als es nichts einfacheres gab. > Ich habe mich da dermaßen mit gequält. Übersetzt heisst das: Es gibt da offensichtlich ein Werkzeug, das ich nicht beherrsche da es meinen geistigen Horizont übersteigt, und ich will das auch nicht lernen, am besten ich bezeichne es als "schlecht". Aber es gibt da draußen Leute, die es gelernt haben, und es beherrschen, die müssen also besser sein als ich. Am besten, ich mach die mal nieder, und bezeichne sie als "Junkies" Falk hat es (fast) auf den Punkt gebracht: Falk Brunner schrieb: > Ein makefile ist ein Profiwerkzeug, dass man nur sinnvoll nutzt, wenn es > WIRKLICH nötig ist und WIRKLICH substantielle Vorteile bringt. Denn es > ist mit VIEL Aufwand verbunden, es zu beherrschen. Ebenso wie > Inlineassembler. Unter Weglassen von ein paar Wörtern ist das meine Meinung: Ein makefile ist ein Profiwerkzeug, dass substantielle Vorteile bringt. Es ist mit etwas Aufwand verbunden, es zu beherrschen. Wer den Aufwand scheut, weil er die Vorteile nicht nutzen kann oder will, oder Lernen schwer fällt, dem sei das unbenommen. Nur - weil ich das nicht lernen will oder kann, heisst das nicht dass es automatisch schlecht ist. > Ebenso wie Inlineassembler. Hat mich einen halben Tag gekostet das zu verstehen, und ich habe damit meinen "Werkzugkoffer" um ein hocheffizientes Tool erweitert. Gut investierte Zeit.
Ich wollte ein konkretes Beispiel nennen, wo ein Makefile sinnvoll ist. Dem Atmel Studio kannst du (ohne Build Script) nicht sagen, dass es zwischendurch noch einen besonderes Befehl ausführen muss, um das Programm zu bauen. Sicher braucht man das auch nicht in jedem Projekt, und für den Anfang ganz bestimmt nicht. Also finde ich es nicht verkehrt, erstmal mit den eingebauten Features einer IDE zu arbeiten. Aber wenn das nicht ausreicht, dann ist ein Makefile nicht verkehrt.
@ Michael Reinelt (fisa) >> Diese Makefilejunkies pochen doch nur drauf, weil sie sich den Scheiß >> mal reinziehen mussten, als es nichts einfacheres gab. >> Ich habe mich da dermaßen mit gequält. >Übersetzt heisst das: Es gibt da offensichtlich ein Werkzeug, das ich >nicht beherrsche da es meinen geistigen Horizont übersteigt, Du solltest an deinem sinnerfassenden LEsen arbeiten. Das war früher eine Übung im Deutsch- und Mathematikunterricht. > und ich >will das auch nicht lernen, am besten ich bezeichne es als "schlecht". Das ist auch Deutschunterricht, nennt sich Polemik. >Aber es gibt da draußen Leute, die es gelernt haben, und es beherrschen, >die müssen also besser sein als ich. Am besten, ich mach die mal nieder, >und bezeichne sie als "Junkies" Bla. >Falk hat es (fast) auf den Punkt gebracht: >> Ein makefile ist ein Profiwerkzeug, dass man nur sinnvoll nutzt, wenn es >> WIRKLICH nötig ist und WIRKLICH substantielle Vorteile bringt. Denn es >> ist mit VIEL Aufwand verbunden, es zu beherrschen. Ebenso wie >> Inlineassembler. >Unter Weglassen von ein paar Wörtern ist das meine Meinung: >Ein makefile ist ein Profiwerkzeug, dass substantielle Vorteile bringt. Dann beweise das doch einfach mal an einem Beispiel. Was kann man mit makefile sooo viel besser als mit IDE? >das nicht lernen will oder kann, heisst das nicht dass es automatisch >schlecht ist. Siehe oben. >> Ebenso wie Inlineassembler. >Hat mich einen halben Tag gekostet das zu verstehen, Das wage ich zu bezweifeln ;-) Mal sehen wann der nächste Thread zu dem Thema von dir dazu kommt. >und ich habe damit >meinen "Werkzugkoffer" um ein hocheffizientes Tool erweitert. Gut >investierte Zeit. Dann kannst du dich ja mit unserem Freund C-hater zusammmentun. Mal sehen wann du es mit wieviel Performancegewinn einsetzen kannst.
Michael Reinelt schrieb: > Übersetzt heisst das: Es gibt da offensichtlich ein Werkzeug, das ich > nicht beherrsche da es meinen geistigen Horizont übersteigt, und ich > will das auch nicht lernen, am besten ich bezeichne es als "schlecht". > Aber es gibt da draußen Leute, die es gelernt haben, und es beherrschen, > die müssen also besser sein als ich. Am besten, ich mach die mal nieder, > und bezeichne sie als "Junkies" Wenn du das aus meine Texten lesen kannst, dann kannst du auch hellsehen. Recht beachtlich. Wer sagt dir, dass ich zu doof dazu war? Ich hatte es ja hin bekommen, aber wenn ich allein einen anderen Controller benutzen will, muss ich das wieder umschreiben, ins richtige Verzeichnis kopieren ... Wenn ich doch nur klick, klick im Studio machen muss, wozu soll ich mir den antiquierten Mist dann antun? Nur damit ich "Programmers Notepad" benutzen kann und das von dort aus auf den Controller schieben kann? Muss ich nicht haben.
@Thomas Holmes > Eben DAS interessiert nicht wirklich! Programmieren kann man natürlich auch ohne diese Kenntnisse. Ich fühle mich jedoch wohler, wenn ich verstehe, was da unter der Haube passiert. Offensichtlich kennst du Features im Atmel Studio, die mir entgangen sind. Wie würdest du denn eine Hand voll HTML, CSS und Javascript Dateien in den so in den Flash Speicher bringen? > Wie oft änderst du deine char arrays, um sie immer wieder > neu zu erzeugen? Öfters, als den C-Quelltext. Deswegen lege ich auf einen vollautomatischen Build wert.
Stefan Us schrieb: > Programmieren kann man natürlich auch ohne diese Kenntnisse. Ich fühle > mich jedoch wohler, wenn ich verstehe, was da unter der Haube passiert. Deswegen lerne ich jetzt auch erstmal Assembler. Aber das durch den Compiler zu kriegen und auf den µC, das muss ich im Moment sicher nicht auch noch wissen, wenn das auch so gut klappt. Mag sein, dass es irgendwann nötig ist und es einen speziellen Grund dafür gibt, jetzt sehe ich jedenfalls keinen.
google schrieb: > Wir haben nicht mehr die 80-er Jahre ... Und dann wundern sie sich, warum unter Arduino das simple setzen/löschen eines simplen Port-Pins bei 16MHz CPU-Clock etliche µs dauert.
@ Wolfgang (Gast) >Und dann wundern sie sich, warum unter Arduino das simple setzen/löschen >eines simplen Port-Pins bei 16MHz CPU-Clock etliche µs dauert. In JAVA sind es dutzende Millisekunden ;-)
Falk Brunner schrieb: > Du solltest an deinem sinnerfassenden LEsen arbeiten. Das kann ich glaub ich recht gut... Falk Brunner schrieb: >> und ich >>will das auch nicht lernen, am besten ich bezeichne es als "schlecht". > > Das ist auch Deutschunterricht, nennt sich Polemik. halb. Richtige Polemik wäre es gewesen, wenn ich das original zitiert hätte: "bezeichne es als Scheiss" (nebenbei: Falk regt sich über Polemik auf ;-) Falk Brunner schrieb: >>Hat mich einen halben Tag gekostet das [ Inline-Assembler] zu verstehen, > > Das wage ich zu bezweifeln ;-) > Mal sehen wann der nächste Thread zu dem Thema von dir dazu kommt. Ach, du beobachtest mich? ;-) Ich habe mir in den letzten Tagen Inline-asm und klassischen asm reingezogen, war damit sehr erfolgreich (ElmChan-FFT PostProcessing Faktor 5 schneller, für meine Anwendung nötig, polyphase decimator in asm realisiert) und ja, ich habe dazu ein paar Anfänger-Fragen gestellt, diese (z.T. auch privat von bekannten/anerkannten Forumsteilnehmern wie Johann und Jörg) beantwortet bekommen, meinen Horizont beträchtlich erweitert, und meine Aufgabe gelöst. Hätte nicht besser laufen können. Woran genau störst du dich jetzt? Falk Brunner schrieb: > Dann kannst du dich ja mit unserem Freund C-hater zusammmentun. der ist sicher nicht mein Freund :-) > Mal sehen wann du es mit wieviel Performancegewinn einsetzen kannst. siehe oben.
Ralf Döblitz schrieb: > Nur ein Beispiel für extrem schlechten Stil: Alle C- und Assembler-Files > werden blind als benötigte Source betrachtet Ja. Weil sie es sind. Oder was glaubst Du hab ich sonst im src folder dieses Projekts rumfliegen? Liebesgedichte mit der Dateiendung .c oder was schwebt Dir da vor? Das großartige Eclipse (welches ich übrigens ebenfalls verwende aufgrund seiner mächtigen C-Editierfunktionen) kompiliert und linkt übrigens ebenfalls blind alles was in seinen Source-Ordnern rumliegt. > wenn man mal ein C-File > nur bis zum Assembler-Output kompilieren läßt, z.B. um sich den > erzeugten Code genauer anzusehen, dann dürfte das recht unlustig werden. Bullshit! Was soll dieser schwachsinnige Einwurf? Weißt Du überhaupt wie makefiles funktionieren? Wenn ich nur src/foo.c kompilieren will dann sag ich bei diesem Exemplar einfach make build/src/foo.o > Von dem Ansatz, keine Header-Files zu verwenden bzw. sie im Makefile > zu ignorieren und keine Abhängigkeiten der Files untereinander zu > kodieren ganz zuschweigen Bullshit! Die Abhängigkeiten die die beim Build erzeugten Dateien und Secondaries betreffen sind alle im Makefile kodiert wenn Du mal genau hinsehen möchtest, Du kannst jedes Target einzeln aufrufen, jede Datei und Zwischendatei einzeln bauen. Probiers aus. Und auf das Abbilden irgendwelcher meta-Abhängigkeiten der Quellen untereinander im Makefile habe ich bei diesem Beispiel absichtlich verzichtet weil das Thema der heutigen Veranstaltung hier ist "UNKOMPLIZIERT" falls Du Dich noch erinnern kannst. Wenn Du einen Fehler findest in diesem sehr eleganten Makefile dann nenne ihn beim Namen oder schweig.
:
Bearbeitet durch User
Wolfgang schrieb: > google schrieb: > Wir haben nicht mehr die 80-er Jahre ... > > Und dann wundern sie sich, warum unter Arduino das simple setzen/löschen > eines simplen Port-Pins bei 16MHz CPU-Clock etliche µs dauert. Das ist dem Anfänger total wurst. Und wenn es für ihn wichtig wird, liest er nach oder fragt hier. Die Schlauen hier wundern sich dann, dass man beim Lernen Fragen stellt, denn sie sind ja mit dem STK500 in der Hand zur Welt gekommen.
Max Mustermann schrieb: > google schrieb: > dass Arduino einen... ...didaktisch klugen Einstieg für den (absoluten) > Laien bietet > > Bullshit! > Das erste was ein Einsteiger bei Arduino gezeigt bekommt ist das Blinken > einer LED mit Hilfe der Funktion delay(). > Aber sobald er eine zweite simultane Sache dazuprogammieren will merkt > er dass das mit delay() nicht funktioniert! ... und schon hat er was gelernt, genau wie der, der das makefile nutzt, um ein blink mit delay zu übersetzen. Merkst Du was? Das hat mit IDE, compiler und Co nullkommanix zu tun.
Bernd K. schrieb: > Ralf Döblitz schrieb: >> Nur ein Beispiel für extrem schlechten Stil: Alle C- und Assembler-Files >> werden blind als benötigte Source betrachtet > > Ja. Weil sie es sind. Oder was glaubst Du hab ich sonst im src folder > dieses Projekts rumfliegen? Das habe ich direkt danach geschrieben: >> wenn man mal ein C-File >> nur bis zum Assembler-Output kompilieren läßt, z.B. um sich den >> erzeugten Code genauer anzusehen, dann dürfte das recht unlustig werden. > > Bullshit! Was soll dieser schwachsinnige Einwurf? Weißt Du überhaupt wie > makefiles funktionieren? Wenn ich nur src/foo.c kompilieren will dann > sag ich bei diesem Exemplar einfach make build/src/foo.o Es geht nicht darum, daß du aus einer C-Source ein linkbares File erzeugst, sondern daß du z.B. um nachzuprüfen, was der Compiler aus einer Funktion genau erzeugt, die C-Source mal nur bis zur Assembler-Source kompilieren läßt statt bis zum linkbaren Object-File. Eine nicht unübliche Praxis. Nur führt das bei deinem Brachial-Ansatz ("alles mit .c und .s ist Source") zu häßlichen Nebenwirkungen. >> Von dem Ansatz, keine Header-Files zu verwenden bzw. sie im Makefile >> zu ignorieren und keine Abhängigkeiten der Files untereinander zu >> kodieren ganz zuschweigen > > Bullshit! Die Abhängigkeiten die die beim Build erzeugten Dateien und > Secondaries betreffen sind alle im Makefile kodiert wenn Du mal genau > hinsehen möchtest, Du kannst jedes Target einzeln aufrufen, jede Datei > und Zwischendatei einzeln bauen. "Files untereinander" war das Thema, nicht einzelne Files. Denn genau dafür ist make da. Wenn man das nicht nutzt, dann kann man sich das makefile auch gleich sparen. > Probiers aus. Und auf das Abbilden > irgendwelcher meta-Abhängigkeiten der Quellen untereinander im Makefile > habe ich bei diesem Beispiel absichtlich verzichtet weil das Thema der > heutigen Veranstaltung hier ist "UNKOMPLIZIERT" falls Du Dich noch > erinnern kannst. Ein Makefile ist also genau dann unkompliziert, wenn es keine Vorteile bietet. Und sobald man die Funktionalität von make auch nutzen will wird es kompliziert. Genau das haben doch die Kritiker deines Ansatzes, auch einem Anfänger Makefiles aufdrücken zu wollen, geschrieben - zu Recht. > Wenn Du einen Fehler findest in diesem sehr eleganten Makefile dann > nenne ihn beim Namen oder schweig. Das ist nicht elegant, es ist überflüssiger Schrott, ein paar Gründe habe ich bereits aufgeführt.
bernd59 schrieb: > Wenn man einen Programmer nutzt, gelten auch diese Einschränkungen > nicht. Nur bei Prozessoren, die nicht direkt unterstützt werden (z.B. > ATtiny), ist es etwas schwieriger. ATinys gehen wohl jetzt auch, wußte ich auch noch nicht: http://www.arduino-hausautomation.de/wp-content/uploads/2014/05/neueboards.png
Ralf Döblitz schrieb: > die C-Source mal nur bis zur > Assembler-Source kompilieren läßt statt bis zum linkbaren Object-File. > Eine nicht unübliche Praxis. Eine vollkommen unübliche Praxis und überflüssig obendrein. Was glaubst Du warum ich noch ein .lst erzeugen lasse? Wenn mich der Assembleroutput jemals interessiert dann immer nur das was nach dem Linken (und nach dem -flto während des Linkens) in der .elf noch davon übrig bleibt und nicht ein theoretisches Zwischenergebnis. > Das ist nicht elegant, es ist überflüssiger Schrott, > ein paar Gründe habe ich bereits aufgeführt. Das ist ein sogenanntes Makefile. Es ist übliche Praxis ein solches zu verwenden. Deine Behauptung ein Makefile sei überflüssig wenn es nicht unleserlich und unnötig Kompliziert ist ja wohl an Lächerlichkeit kaum noch zu überbieten.
Bernd K. schrieb: [angeblich "elegantes" Makefile] >> Das ist nicht elegant, es ist überflüssiger Schrott, >> ein paar Gründe habe ich bereits aufgeführt. > > Das ist ein sogenanntes Makefile. Das bestreitet auch niemand. Nur deine Behauptung, dieser Haufen Müll wäre elegant, ist strittig. > Es ist übliche Praxis ein solches zu > verwenden. Deine Behauptung ein Makefile sei überflüssig wenn es nicht > unleserlich und unnötig Kompliziert ist ja wohl an Lächerlichkeit kaum > noch zu überbieten. Offensichtlich unterscheiden sich unsere Wertmaßstäbe dermaßen, daß eine weitere Diskussion sinnlos ist. Agree to disagree?
Ralf Döblitz schrieb: > Das bestreitet auch niemand. Nur deine Behauptung, dieser Haufen Müll > wäre elegant, ist strittig. Nein, ist es nicht. Deine Behauptung er wäre Müll stellt eine grundlose Beleidigung dar und es ist Dir nicht gelungen diese Behauptung in irgendeiner Weise angemessen zu begründen. Stattdessen reitest Du darauf herum man solle Makefiles nicht verwenden wenn sie nicht so kompliziert sind daß man sie nicht mehr überblicken kann. Das ist absurd. Und dann bleibst Du geflissentlich die Antwort schuldig was man stattdessen als Alternative verwenden sollte. Und als weiteren Punkt noch: Du hast mein Makefile offensichtlich überhaupt nicht gelesen sonst wäre Dir der Fehler beim Target all aufgefallen, da ist mir nämlich was reingerutscht was ich anschließend wieder entfernen wollte aber vergessen habe, als kompetentem Makefile-Kritiker hätte Dir das sofort ins Auge stechen sollen, ist es aber nicht, stattdessen gibst Du schwammige Pauschalbeleidigungen von Dir wie "Müll" und dergleichen. Hier ist nun also die korrigierte Version und extra für Dich habe ich das sogar das header-Tracking wieder eingebaut: Und jetzt mach das bitte als Batchfile oder Shellscript (war ja Dein eigener Vorschlag) genauso kompakt (und zwar beide Versionen, einmal das vorherige ohne header und dann fügst du noch deine 3 Zeilen Script an die dann meine 3 Zeilen Makefile-Ergänzung aus der unten nachgereichten zweiten Variante implementieren um die selbe Funktionalität zu erreichen). Hier bitte schön:
1 | ########################################
|
2 | ## bare bones makefile for ARM Cortex ##
|
3 | ########################################
|
4 | |
5 | NAME = stm32-demo |
6 | |
7 | SRCS = $(wildcard src/*.c) |
8 | SRCS += $(wildcard src/*.s) |
9 | |
10 | INCDIRS = inc/ |
11 | INCDIRS += stm_inc/ |
12 | |
13 | DEFINES = -DSTM32F401xE |
14 | DEFINES += -DNO_LIBC_INIT_ARRAY |
15 | |
16 | LSCRIPT = stm_inc/gcc.ld |
17 | |
18 | BUILDDIR = build/ |
19 | |
20 | CFLAGS = -ffunction-sections |
21 | CFLAGS += -mlittle-endian |
22 | CFLAGS += -mthumb |
23 | CFLAGS += -mcpu=cortex-m4 |
24 | CFLAGS += -mfloat-abi=hard |
25 | CFLAGS += -mfpu=fpv4-sp-d16 |
26 | CFLAGS += -std=c99 |
27 | CFLAGS += -ggdb |
28 | CFLAGS += -Os |
29 | CFLAGS += -flto |
30 | |
31 | LFLAGS = --specs=nano.specs |
32 | LFLAGS += --specs=nosys.specs |
33 | LFLAGS += -Wl,--gc-sections |
34 | LFLAGS += -T$(LSCRIPT) |
35 | LFLAGS += -lm |
36 | |
37 | WFLAGS = -Wall |
38 | WFLAGS += -Wextra |
39 | WFLAGS += -Warray-bounds |
40 | WFLAGS += -Wno-unused-parameter |
41 | |
42 | GCCPREFIX = arm-none-eabi- |
43 | CC = $(GCCPREFIX)gcc |
44 | OBJCOPY = $(GCCPREFIX)objcopy |
45 | OBJDUMP = $(GCCPREFIX)objdump |
46 | SIZE = $(GCCPREFIX)size |
47 | |
48 | OOCD = openocd |
49 | OOCD_CFG = board/st_nucleo_f401re.cfg |
50 | |
51 | INCLUDE = $(addprefix -I,$(INCDIRS)) |
52 | OBJS = $(addprefix $(BUILDDIR),$(addsuffix .o,$(basename $(SRCS)))) |
53 | |
54 | |
55 | ###########
|
56 | ## rules ##
|
57 | ###########
|
58 | |
59 | .PHONY: all |
60 | all: $(OBJS) |
61 | all: $(BUILDDIR)$(NAME).elf |
62 | all: $(BUILDDIR)$(NAME).bin |
63 | all: $(BUILDDIR)$(NAME).s19 |
64 | all: $(BUILDDIR)$(NAME).lst |
65 | all: print_size |
66 | |
67 | .PHONY: install |
68 | install: all |
69 | $(OOCD) -f $(OOCD_CFG) -c "program $(BUILDDIR)$(NAME).s19 verify reset" |
70 | |
71 | .PHONY: clean |
72 | clean: |
73 | $(RM) -rf $(BUILDDIR)* |
74 | |
75 | # compiler
|
76 | $(BUILDDIR)%.o: %.c |
77 | @mkdir -p $(dir $@) |
78 | $(CC) -c -MMD -o $@ $(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS) $< |
79 | |
80 | # assembler
|
81 | $(BUILDDIR)%.o: %.s |
82 | @mkdir -p $(dir $@) |
83 | $(CC) -c -x assembler-with-cpp -o $@ $(INCLUDE) $(DEFINES) $(CFLAGS) $(WFLAGS) $< |
84 | |
85 | # linker
|
86 | $(BUILDDIR)%.elf: $(OBJS) |
87 | $(CC) -o $@ $(CFLAGS) $(LFLAGS) $^ |
88 | |
89 | %.bin: %.elf |
90 | $(OBJCOPY) -O binary -S $^ $@ |
91 | |
92 | %.s19: %.elf |
93 | $(OBJCOPY) -O srec -S $^ $@ |
94 | |
95 | %.lst: %.elf |
96 | $(OBJDUMP) -D $^ > $@ |
97 | |
98 | .PHONY: print_size |
99 | print_size: $(BUILDDIR)$(NAME).elf |
100 | $(SIZE) $(BUILDDIR)$(NAME).elf |
101 | |
102 | |
103 | #####################
|
104 | ## Advanced Voodoo ##
|
105 | #####################
|
106 | |
107 | # try to include any compiler generated dependency makefile snippet *.d
|
108 | # that might exist in BUILDDIR (but don't complain if it doesn't yet).
|
109 | DEPS = $(addprefix $(BUILDDIR),$(patsubst %.c,%.d,$(filter %.c,$(SRCS)))) |
110 | -include $(DEPS) |
111 | |
112 | # make the object files also depend on the makefile itself
|
113 | $(OBJS): Makefile |
Ralf Döblitz schrieb: > Nur führt das bei deinem Brachial-Ansatz > ("alles mit .c und .s ist Source") zu häßlichen Nebenwirkungen. Dir ist schon aufgefallen dass dieses Makefile einen out-of-tree build erzeugt? Ist es nicht? Wie kommts? Ich warte auf Deine öffentliche Bitte um Entschuldigung.
:
Bearbeitet durch User
Bernd K. schrieb: > Ralf Döblitz schrieb: >> Nur führt das bei deinem Brachial-Ansatz >> ("alles mit .c und .s ist Source") zu häßlichen Nebenwirkungen. > > Dir ist schon aufgefallen dass dieses Makefile einen out-of-tree build > erzeugt? Ist es nicht? Wie kommts? Seufz, auch wenn ich nicht glaube, daß es bei dir hilft: Ich schrieb, daß es zu Problemen führen kann, wenn man mal eine C-Source nur bis zur Assembly-Stufe durchlaufen läßt, um sich den erzeugten Code anzusehen. Da das nicht in deinem Makefile drin ist, sollte eigentlich offensichtlich sein, daß das ein manueller Schritt, den man zu Prüfzwecken ausführt (eben indem man dem Compiler ein -S mitgibt). Und da ist eben nicht automatisch drin, daß das Resultat an anderer Stelle landet als die Quelle.
Zum Thema Makefiles: Einige empfehlen, sich gleich zu Beginn der Programmiererei mit ihnen zu beschäftigen, während andere sie für unnötig und nur von Überprofis beherrschbar halten. Meiner Meinung nach liegt die Wahrheit – wie so oft – dazwischen: Kaum jemand von den Makefile-Nutzern (mich selbst eingeschlossen) wird wohl sein erstes Makefile schon vor seinem ersten Hello-World- oder LED-Blink-Programm geschrieben haben. Interessant werden Makefiles erst, wenn die Programme etwas größer werden, so dass man sie modularisieren möchte. Auf der anderen Seite sind Makefiles, wie man sie üblicherweise für die Mikrocontrollerprogrammierung einsetzt, auch keine Raketentechnik. Die paar Konstrukte, die 99,9% aller Fälle abdecken, kann man tatsächlich an einem Abend lernen. Man kann Makefiles so strukturieren, dass sie von einem Unerfahrenen leicht anzupassen sind, ohne dabei die von einem Fortgeschrittenen geforderte Flexibilität zu verlieren. Dazu unterteilt man sie in die folgenden drei Abschnitte: 1. Informationen, die öfter geändert werden, wie bspw. Quellcodemodule, verwendete Bibiotheken, Defines (wie bspw. F_CPU beim AVR) usw. Das sind alles nur Variablenzuweisungen und sogar von einem Anfänger problemlos beherrschbar, wenn man ihm ein Muster vorgibt. 2. Ggf. projektspezifische Regeln, wie bspw. für die Verwendung von Generatoren für Code und Dokumentation Dazu muss man lediglich eine kleine Untermenge die Regelsyntax beherrschen. In vielen Projekten kann dieser Teil aber auch komplett entfallen. 3. Regeln, die sich praktisch nie ändern. Dazu zählen die Regeln für Kompilieren, Linken, Generierung von Hex-Files und Header-Abhängigkeiten. Da diese Teile aber weitgehend projektunabhängig sind, muss man sie nicht selber schreiben, sondern kann auch fertige Beispiele aus dem Netz verwenden. Für meine privaten Projekte halte ich diesen Abschnitt in einer eigenen Datei, die an zentraler Stelle abgelegt und von den einzelnen projektspezifischen Makefiles per Include eingebunden wird. Verbesserungen an diesem Teil sind damit immer sofort in sämtlichen Projekten verfügbar. Gut strukturierte Makefiles haben gegenüber der Projektkonfiguration mittels GUIs (wie es in IDEs gemacht wird) schon ein paar Vorteile, die auch für einen etwas fortgeschritteneren Gelegenheitsprogrammierer interessant sein können: - Sämtliche projektspezifischen Compiler- und Linker-Optionen liegen räumlich beieinander und können so mit einem Blick erfasst werden. Bei IDEs sind die häufig benötigten Optionen meist als Checkboxen u.ä. auf mehrere Dialoge verteilt (müssen also gesucht werden), der ganze Rest muss sowieso in Textform eingegeben werden, was praktisch keinen Unterschied zum Eintrag in ein Makefile darstellt. - Auf Makefiles basierende Projekte können praktisch überall gebaut werden, wo die benötigte Toolchain installiert ist, da zu dieser meist auch ein Make gehört. Ein Arduino-User kann kein Atmel-Studio-Projekt nutzen und umgekehrt. Aber beide können können ein Makefile-Projekt nutzen. - Wenn mit Compiler-Optionen u.ä. herumexperimentiert wird, können von Makefiles leicht Sicherheitskopien angelegt werden, die bei Misserfolg einfach wieder zurückkopiert werden. - Makefiles können problemlos versioniert werden, so dass man sich jederzeit die in der Vergangenheit gemachten Änderungen an den Projekteinstellungen anzeigen lassen kann. Falk Brunner schrieb: > Dazu noch die vorsintflutliche Syntax mit Positionsensitivität! Meinst du die Einrückung der Shell-Kommandos in Regeln mit Tabs? Wenn dich diese Tabs arg stören, kannst du sie mit .RECIPEPREFIX wie in diesem Beispiel durch ein druckbares Zeichen ersetzen:
1 | .RECIPEPREFIX = | |
2 | target: prerequisites |
3 | | step1 |
4 | | step2 |
Aber Makefile hin oder her: Horst hat sich wahrscheinlich schon längst für das Arduino- oder das Atmel-IDE entschieden und schon die ersten Erfolge erzielt, während wir hier noch über Makefiles diskutieren ;-)
Ralf Döblitz schrieb: > Seufz, auch wenn ich nicht glaube, daß es bei dir hilft: > > Ich schrieb, daß es zu Problemen führen kann, wenn man mal eine C-Source > nur bis zur Assembly-Stufe durchlaufen läßt, um sich den erzeugten Code > anzusehen. Nein kann es nicht, verdammt noch mal, jetzt wirf endlich mal wenigstens einen flüchtigen Blick auf das Makefile das Du dauernd kritisierst! -S wirft bekanntermaßen das Ergebnis immer in die mit -o angegebene Datei falls angegeben oder ins aktuelle Arbeitsverzeichnis falls nicht, beim Linken gibts dann halt nen Fehler weil die .o files keine echten .o files mehr sind aber der Assemblerklartext steht dann halt in den .o files. Aber das macht man sowieso nicht mit -S, man nimmt stattdessen die -save-temps Option, die wirft die Files in das momentane Arbeitsverzeichnis und der Build läuft ohne Probleme durch. Und da, wie Du deutlich sehen kannst, weder das momentane Arbeitsverzeichnis von make noch das BUILDDIR jemals in irgendeinem der Sourceordner liegt wird niemals je irgendeine beim Build erzeugte Datei in den src-Ordner geworfen! Zum Aufräumen der ganzen save-temps Dateien kann man meinetwegen noch was in die clean Regel mit reinbauen wenn man das öfter machen will, aber da würd ich mir dann eher ne separate Regel machen die das gezielt bauen kann und als -s anstatt als .o speichert:
1 | $(BUILDDIR)%.s: %.c |
2 | $(CC) -S -c -o $@ undsoweiter... |
und dann
1 | make build/src/main.s |
Probiers aus wenn Du mir nicht glaubst. Häng ein -save-temps an die CFLAGS und keinerlei Probleme treten auf. Häng probhehalber ein -S in die CFLAGS und auch dann treten keine Probleme auf! Probiers aus wenn Du es nicht im Kopf simulieren kannst (aber das kannst Du doch, oder?) Und das nächste mal wenn Du was kritisieren und pauschal als Müll beleidigen willst dann les es Dir wenigstens vorher mal kurz durch.
:
Bearbeitet durch User
Bernd K. schrieb: > Ralf Döblitz schrieb: >> Seufz, auch wenn ich nicht glaube, daß es bei dir hilft: >> >> Ich schrieb, daß es zu Problemen führen kann, wenn man mal eine C-Source >> nur bis zur Assembly-Stufe durchlaufen läßt, um sich den erzeugten Code >> anzusehen. > > Nein kann es nicht, verdammt noch mal, jetzt wirf endlich mal wenigstens > einen flüchtigen Blick auf das Makefile das Du dauernd kritisierst! Ich fürchet wir reden konsistent aneinander vorbei. Du gehst von deiner Arbeitsweise aus, zu der wohl auch das Makefile paßt bzw. bei der es keine Probleme verursacht, während ich durchaus anders arbeite und da würden diese Probleme auftreten. > -S wirft bekanntermaßen das Ergebnis immer in die mit -o angegebene > Datei falls angegeben oder ins aktuelle Arbeitsverzeichnis falls nicht, ACK > beim Linken gibts dann halt nen Fehler weil die .o files keine echten .o > files mehr sind aber der Assemblerklartext steht dann halt in den .o > files. Ähm, ich würde für so einen Test niemals ein Ziel angeben. Das ist bei mir einfach ein gcc-Aufruf mit -S und den anderen CFLAGS im Sourcedir - wie oben geschrieben: total andere Arbeitsweise. > Aber das macht man sowieso nicht mit -S, man nimmt stattdessen die > -save-temps Option, die wirft die Files in das momentane > Arbeitsverzeichnis > und der Build läuft ohne Probleme durch. s.o., wir haben offensichtlich total unterschiedliche Arbeitsweisen. Daher wundert es mich nicht, daß du meine Probleme mit deinem makefile-konzept nicht nachvollziehen kannst, denn bei deiner Arbeitsweise entstehen diese ja nicht. Und da du dir ja anscheinend von mir auf den Schlips getreten fühlst (was nicht von mir beabsichtigt war), obwohl ich ständig nur das Makefile bzw. das zugehörige Konzept kritisiere und nicht dich persönlich: Für deine Arbeitsweise ist das sicherlich ein passender und sinnvoller Ansatz. Aber du solltest evtl. auch ein klein wenig darauf hinweisen, unter welchen Rahmenbedingungen (sprich: deiner Arbeitsweise bzw. welchen von dir implizierten Voraussetzungen) dein Makefile-Ansatz entwickelt wurde, damit niemand böse überrascht wird, der evtl. anders arbeitet als du. Wir sollten das jetzt wirklich beenden und nicht weiter eskalieren lassen.
Ralf Döblitz schrieb: > Aber du solltest evtl. auch ein klein wenig darauf hinweisen, unter > welchen Rahmenbedingungen (sprich: deiner Arbeitsweise bzw. welchen von > dir implizierten Voraussetzungen) dein Makefile-Ansatz entwickelt wurde, > damit niemand böse überrascht wird, der evtl. anders arbeitet als du. Ganz einfach: Das Makefile dient dazu die benötigten Dateien aus den Qellen zu bauen. Also genau das was alle machen, keine Überraschungen. Welche ausgefallene unkonventionelle Arbeitsweise bzw. Verwendungszweck schwebt Dir denn so vor?
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.