Coocox Site bzw Coocox IDE tot?

http://downforeveryoneorjustme.com

Frickelfritze schrieb:
> oder geht's euch von "Zuhause" aus genauso?

Geht nicht.

sw4stm32 ist ne gute Alternative.

... wenn du merkst das du ein totes Pferd reitest, ... steig ab!

53453453454353 schrieb:
> ... wenn du merkst das du ein totes Pferd reitest, ... steig ab!

Hab ja nicht mal das alte lebende geritten.

Die war vor nem Monat schonmal down. Davon ab, inhaltlich ist das 
Projekt schon lange tot. Das Forum war nur noch Spam, null Reaktion 
mehr, und da die CoIDEv2 in eine vollkommen verkehrte Richtung abgebogen 
ist (alles nur noch online), hat die auch keiner benutzt.

Zurecht, denn man sieht ja, was man davon gehabt hätte, sich auf den 
Online-Unsinn einzulassen.

Naja, ich hab CoIDE ganz gerne genutzt, aber meine eigentlichen Builds 
mache ich per Batchfile, unabhängig von irgendwelchen IDEs. Deswegen 
werden meine Projekte auch in 10 Jahren noch durchcompilieren.

Nop schrieb:
> unabhängig von irgendwelchen IDEs. Deswegen
> werden meine Projekte auch in 10 Jahren noch durchcompilieren.

Auch eclispe erzeugt "echte" makefiles ;-)

hp-freund schrieb:
> Auch eclispe erzeugt "echte" makefiles

Hab noch nie ein unechtes makefile gesehen.

Frickelfritze schrieb:
> Hab noch nie ein unechtes makefile gesehen.

Will sagen das auch der reine gcc ohne eclipse Bestandteile in Zukunft 
funktionieren wird.

hp-freund schrieb:
> Auch eclispe erzeugt "echte" makefiles ;-)

Jo. Und sollte man zu den überwältigenden 2% gehören, die Linux am 
Desktop einsetzen, dann reicht das ja auch schon aus zum Build. Super 
Idee.

Hier gibts noch die alte IDE zum Download.
Falls sich jemand noch was "Sichern" möchte.

https://web.archive.org/web/20150425052426/http://www.coocox.org/download/Tools/CoIDE-1.7.8.exe

Ansonsten ist Atollic TrueStudio Lite absolut zu empfehlen!
Hat keine Code-Size limitierung mehr.

Mw E. schrieb:
> Is ja nich so, dass es gcc und make.exe auch für Windows gäbe...

Klar, und notfalls kann man ja auch "einfach" Cygwin installieren. 
Nichts gegen Cygwin, das ist super, aber barocke Build-Chains sind ein 
sehr eleganter Weg, wie man unwartbare Projekte erzeugen kann.

Der geniale Trick daran ist nämlich, daß bei Codereviews meist nur auf 
den Code geachtet wird, während man das absehbare Chaos mit der Methode 
der Buildchain unter dem Radar der Reviewer hindurchschmuggeln kann. 
Natürlich ist make da nur ein ganz kleiner Baustein, der aber wenigstens 
das Prinzip verdeutlicht.

Profis generieren aber auch noch Code mit irgendwelchen Scripten, die 
dann noch eine spezielle Version irgendeiner anderen Sprachumgebung 
verlangen. Gut umgesetzt ist das z.B. bei libopencm3, wo zum Lib-Build 
auf dem Host allen Ernstes Python 2.7 gebraucht wird.

Den Compiler und Linker braucht man funktional gesehen, keine Frage. 
Aber alles andere ist IMO unnötiger Ballast, der in die "dependency 
hell" führt - das Linux-Äquivalent zur "DLL hell".

Nop schrieb:
> Aber alles andere...

Du sprichst mir aus dem Herzen.

Aber sowas hier in diesem Forum öffentlich zu schreiben, ruft gewöhnlich 
eine Flame-Welle hervor. Denk mal an die Legion von Anfragen wie "Ich 
möchte mich mit µC beschäftigen, welche IDE würdet ihr mir empfehlen?"

W.S.

W.S. schrieb:
> Du sprichst mir aus dem Herzen.

Jepp, Du bist ja auch einer der wenigen, die ein simples 
Shellscript/Batchfile irgendwelchen kryptischen Makefiles vorzieht, die 
ohnehin meist unverstanden per copy/paste realisiert werden, und wo die 
Leute dann dicke Backen machen, wenn es nicht geht wie gedacht. Und wo 
auch die make-Cracks hier mehrere Iterationen brauchen, bis sie mal was 
Funktionierendes vorstellen - weil's ja so einfach ist. Ja nee, is klar.

Bei hunderten von C-Files verstehe ich, daß man nicht immer alles neu 
übersetzen will, und da ergibt make auch Sinn. Aber für embedded ist das 
angesichts heutiger PC-Geschwindigkeiten beim Build einfach unnütz.

> Aber sowas hier in diesem Forum öffentlich zu schreiben, ruft gewöhnlich
> eine Flame-Welle hervor.

Was ist eigentlich aus KISS/YAGNI geworden? ;-)

> Denk mal an die Legion von Anfragen wie "Ich
> möchte mich mit µC beschäftigen, welche IDE würdet ihr mir empfehlen?"

Das gibt es noch in viel krasser. Ich kann da nicht ins Detail gehen, 
aber ich habe es beruflich tatsächlich erlebt: eine embedded-IDE, die 
aus den Projekt-Einstellungen mit einem Zoo aus verschachtelten 
Klickibunt-Optionen das Startupfile generiert hat. Und zwar bei jedem 
Build erneut, so daß man im generierten Code nichts nach Datenblatt 
ändern konnte. Das war vielleicht ein Horror, wenn man irgendwas gesucht 
hat. Und besonders, wenn Kollegen die Sourcen eingecheckt haben, aber 
die Projektsettings nicht. Zumal die dann eh wieder auch noch von 
lokalen Pfaden auf dem jeweiligen Rechner abhingen - da kam Freude auf.

Statt daß man einfach mal ganz normal mit Startup-Assembler die 
Grundeinstellungen macht und gut, aber nee, das wäre ja zu einfach 
gewesen.

Bernd K. schrieb:
> Prinzipiell richtig, aber zum Glück ist weder an make noch an Python
> irgendwas barockes

Doch. Versuch mal, in zehn Jahren ein Python mit der richtigen Version 
von damals zu installieren. Achso, ich vergaß, in zehn Jahren ist die 
Frickelsoftware von heute ja sowieso schon längst weggeworfen.

Die Situation, daß man ein Projekt von vor zehn Jahren tatsächlich 
nochmal anfassen muß, hatte ich schon. Und das wird dann drollig, weil 
das Zeug von damals auf einem heutigen Windows nicht mehr unbedingt 
läuft, und bei Linux ist das auch nicht anders.

Abgesehen davon ist scriptgenerierter Code an sich schon schlecht, weil 
es zu unwartbaren Projekten führt. Man kann dann nämlich den Code nicht 
mehr direkt warten. Das ist artverwandt zu Spaghetticode, nur in der 
anderen Richtung: Lasagnecode. Zuviele Schichten und Indirektionen.

> Die meisten C und C++ Projekte setzen an
> zentraler Stelle auf make, das kann man also guten Gewissens auf jedem
> Rechner auf dem mit gcc gearbeitet werden soll voraussetzen.

Nope. Wenn man sich ARM-GCC auf Windows holt, ist da erstmal kein Make 
dabei. Und auch kein Python und weiß der Geier. Je mehr man "guten 
Gewissens" voraussetzt, desto mehr geht daran am Ende schief.

Was kann eigentlich daran so grundverkehrt sein, daß man schlicht und 
ergreifend KEINE Abhängigkeiten voraussetzt?! Ist es wirklich so 
schlimm, wenn ein nachfolgender Entwickler nur auf eine 
Batchdatei/Shellscript klicken muß und gut?

Scheint wohl so: "Ich mußte mir den ganzen Kram auch erstmal aufsetzen, 
und durch diese Reifen muß der andere dann auch springen, haha!".

Also wer "Tage" braucht, um aus einem Batchfile ein Shellscript zu 
machen, das vernünftig unter Linux läuft, der sollte einfach mal auf 
Dieter Nuhr hören.

Oder alternativ lesen lernen, denn ich schrieb ausdrücklich, daß sich 
bei großen Projekten mit hunderten Files make sehr wohl lohnt.

Nop schrieb:
> Scheint wohl so: "Ich mußte mir den ganzen Kram auch erstmal aufsetzen,
> und durch diese Reifen muß der andere dann auch springen, haha!".

Nein, das glaube ich eher nicht. Sowas würde ein gewisses Maß an Denken 
voraussetzen. Nun ja, bösartiges Denken, aber eben Denken immerhin.

Hier haben wir es jedoch mit dressierten Leuten zu tun. Denen ist make 
oder Python eben mal eingetrichtert worden und ab da können sie nicht 
mehr anders.

Das Bedenkliche dabei ist, daß eben diese Leute, die zu doof sind, um 
mal aus ihrer Furche zu gucken, sich selbst für die Allergrößten halten 
- mit der Begründung, daß sie vor sich in selbiger Furche ja den 
Allerwertesten eines Anderen sehen... also sagen sie sich "Aha, noch 
einer, also jaja, das MUSS eben so sein, was Anderes ist gar nicht 
denkbar."

Natürlich ist es weder schlimm noch schwierig, mit dem modernen 
Faustkeil auf ein ccc.bat zu hauen (oder im TC einmal auf die 
Entertaste).

Aber Leute, die auf "make" gedrillt wurden, kommen von sich aus nicht 
drauf, über sowas jemals nachzudenken. Stattdessen werden sowohl 
Linkerscripte als auch Makefiles kopiert und editiert, immer nach dem 
Motto "das hatte beim letzten Projekt gut funktioniert".

W.S.

Hallo,

ich finde das Thema "make" sehr interessant. Kann mir jemand sagen, wie 
schwer es für einen Anfänger ist sich da einzuarbeiten?

Mein Hintergrund:

- Ich Habe stm32-CortexM3 mit Coocox bisher programmiert und komme damit 
auch gut zurecht. Prinzipiell würde ich gerne ein etablierteres Programm 
wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make 
eine gute Alternative?

- Was wird eigentlich in der Industrie verwendet? Ist da eher Make oder 
Keil bevorzugt?

Frank M. schrieb:

> Ich habe ein Projekt mit ca. 120 C-Dateien und fast ebensoviel
> Header-Dateien. Wenn ich nun eine Header-Datei ändere, werden mit make
> nur die relevanten C-Dateien, welche diese Datei per #include benutzen,
> neu übersetzt und nicht sämtliche 120 C-Sources.

Deswegen schrieb ich am 01.11.2016 23:30:
"Bei hunderten von C-Files verstehe ich, daß man nicht immer alles neu 
übersetzen will, und da ergibt make auch Sinn."

Aber das hat offenbar auch der Axel sehr gekonnt überlesen.

Flipp schrieb:
> Prinzipiell würde ich gerne ein etablierteres Programm
> wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make
> eine gute Alternative?

lol Gut getrollt. (:

Nop schrieb:
> Flipp schrieb:
>> Prinzipiell würde ich gerne ein etablierteres Programm
>> wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make
>> eine gute Alternative?
>
> lol Gut getrollt. (:

Das war wirklich eine ernstgemeinte Frage ^^

Flipp schrieb:
> - Was wird eigentlich in der Industrie verwendet? Ist da eher Make oder
> Keil bevorzugt?

da gibt es keinen Standard. Selbst innerhalb einer Firma gibt es genau 
wie hier die einen die eine IDE bevorzugen und die anderen die lieber 
mit make/batch arbeiten.

Einfach mal nach 'make tutorial' googeln, da wirst du schon was finden. 
Das Grundprinzip ist einfach: es gibt ein Ziel (target) und wovon das 
abhängig ist. Und zu den Abhängigkeiten gibt es Regeln wie die erstellt 
werden.

Der erste Treffer bei Google sieht doch schon gut aus, sogar in Deutsch:
http://www.ijon.de/comp/tutorials/makefile.html

hp-freund schrieb:
> Auch eclispe erzeugt "echte" makefiles ;-)

Ja, mit absoluten Pfaden drin. Dabei wäre es so einfach, ich sag nur

BASEDIR = $(realpath ..)

Dann alle Pfade relativ zu $BASEDIR angeben. Dieses Makefile
funktioniert dann ohne Änderungen unter Linux und Windows, egal wo man 
es hinlegt bzw. die Sourcen entpackt.
Klar, man muss als Toolchain 
https://launchpad.net/gcc-arm-embedded/+download noch installieren und 
dazu ein make.exe (http://gnuwin32.sourceforge.net/packages/make.htm). 
Dazu Editor nach Wahl.
O.k., beim Debuggen kann eine IDE Sinn machen.

Flipp schrieb:
> ich finde das Thema "make" sehr interessant. Kann mir jemand sagen, wie
> schwer es für einen Anfänger ist sich da einzuarbeiten?

Einfache Dinge sind einfach, komplizierte Dinge manchmal kompliziert. 
Man merkt make die Herkunft aus dem Unix-Bereich an, zusammen mit 
typischen Linux-Tools fühlt sich make am wohlsten.

Werkzeuge um automatisch Makefiles zu erzeugen, haben sich als Irrweg 
herausgestellt. Angefangen von imake (Benutzung des C-Preprozessor um 
Makefiles zu generieren) bis zu autoconf (Benutzung des M4 
Macroprozessors um Makefiles zu generieren), arten alle diese Werkzeuge 
in eine Materialschlacht aus.

> - Ich Habe stm32-CortexM3 mit Coocox bisher programmiert und komme damit
> auch gut zurecht. Prinzipiell würde ich gerne ein etablierteres Programm
> wie zb. Keil verwenden. Leider ist das codesize beschränkt. Ist da Make
> eine gute Alternative?

make beseitigt keine Codegrößenbeschränkungen des Compiler.

geht wieder..