Hallo, ich schaue mir gerade den Source-Code von Marlin an: http://marlinfw.org/meta/download/ https://github.com/MarlinFirmware/Marlin/archive/1.1.x.zip Version 1.1.8 Konkret versuche ich dahinter zu kommen was man tun müsste um einen neuen Typ Display da zu integrieren. Dafür versuche ich gerade zu verfolgen, was da mit dem Display gemacht wird das ich an meinem CR-10 jetzt dran habe. Nur so als Hintergrund, das Problem ist sicher universeller. Der Source-Code ist jetzt von vorne bis hinten so heftig mit bedingter Compilierung vollgestopft, vor allem lösen viele Defines wieder neue Defines aus, dass der eigentliche Code der am Ende ausgeführt wird nur schwer zu sehen ist. Bei rund 280 .cpp und .h in dem Verzeichnis ist das schon schwer lästig. Und da kommt noch die u8g Lib oben drauf. Ich suche ein Tool das mir den Source-Code von allem Code befreit der nicht benutzt wird. Kommentare sollten vorzugsweise erhalten bleiben, es sei denn sie stehen innnerhalb von "überflüssigen" #if / #endif Blöcken. Also im Grunde genommen was der Präprozessor macht, aber nur zum Teil. Hmm, okay, mit dem Stichwort gesucht bin ich auf "-save-temps" gekommen. Bei einem eigenen Projekt funktioniert das auch und wäre auch schon hilfreich, wenn das auch nicht mehr so leicht zu lesen ist. Da fehlen eben die Kommentare und alle definierten Konstanten sind eingebaut. Das Marlin ist aber ein Arduino Projekt und ich jage das per Plugin durch Atmel-Studio, was ich in den Projekt-Einstellungen als Optionen setze wird wohl nicht verwendet. Ich suche mir gerade einen Wolf wie man bei Arduino 1.8.5 die Compiler-Flags ändern kann. Aber selbst wenn ich das noch finde, das Ergebnis würde mir zu weit gehen.
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html die -E option sollte das sein was du sucht... 73
Jain, -E für sich macht im Grunde nichts anderes als -save-temps. Nur das die .o Dateien den Präprozessor-Text enthalten und das Projekt nicht compiliert. Mit -save-temps bekommt man für alle Module neben der richtigen .o noch .d, .i und .s Dateien - und das Projekt compiliert. Nur, wie ich schrieb, das geht mir dann schon wieder zu weit. An dem Punkt sind eben auch schon alle Defines eingebaut. Nur noch "Magic-Numbers" statt Text macht das auch nicht lesbarer. Und für Arduino habe ich das immer noch nicht aktiviert bekommen.
Mit GCC kannst du -save-temps verwenden. Die präprozessierte Quelle wird dann in .i (C), .ii (C++) order .s (Assembler) gespeichert. Falls die Quellkommentare übernommen werden sollen, kann zusätzlich -C angegeben werden. Das Präcompilar enthält Line-Notes, so dass sich Diagnostics auf die Zeilen der ursprünglichen Quelle beziehen. Falls diese Notes störend sind oder Diagnostics sich auf die Zeilen des Präcompilats beziehen sollen, kann zusätzlich mit -P compiliert werden. Falls das Präcompilat noch die Makro-Definitionen des Originals enthalten soll — etwa zur Überprüfung — kann zusätzlich mit -g3 oder höherem Dwarf übersetzt werden.
-E prozessiert auch alle includes. Das kann unübersichtlich werden... Guck mal nach unifdef oder coan.
Importiere den Code nach Eclipse, das zeigt allen inaktiven Code grau an.
Ah ja, "coan", stimmt, damit hatte ich irgendwann schon mal gespielt. Jetzt ist nicht mal mehr die Sourceforge Seite dazu zu finden. Mit unifdef habe ich spontan die Herausforderung, dass ich mir das erst noch für Windows compilieren müsste. Wenn das so wie coan funktioniert, dann lohnt sich das aber nicht mal. Bei coan musste ich alle Defines selber angeben, das bezog sich immer nur auf eine Datei. Wenn man aber Defines hat die in Abhängigkeit von anderen Defines gesetzt werden, dann wird das sehr schnell sehr anstrengend. Das Tool müsste schon selber alles berücksichtigen was in die .c oder .cpp includiert wird. Eclipse ist vielleicht einen Versuch wert. Ist aber ein klares no-go für mich, Eclipse und JAVA kommen nicht auf die Kiste. Das ist auch nicht "mal eben so" installiert und läuft dann, so "nackig" wird das wohl auch nicht funktionieren. Aber, Visual Studio Code habe ich bereits in Verwendung und der zeigt schon toten Code in grau an (per Microsoft Intellisense C/C++ Plugin). Das ist schon hilfreich und scheint auch die Includes mit einzubeziehen. Nur ist der Code eben immer noch da und erschwert das Lesen. Und so verschachtelt wie das Projekt ist, ich bin nicht sicher, ob der wirklich alles richtig anzeigt. Hmm, Atmel-Studio, bzw. Visual-Studio müsste das eigentlich auch besser können als es mir jetzt dargestellt wird. Ist auf jeden Fall einen Schritt vorwärts, danke, da hatte ich nicht mehr dran gedacht weil Visual Studio Code ja "nur" ein reiner Editor ist und ich das Projekt im Atmel-Studio geöffnet habe um es auch bauen zu können.
Beitrag #5337262 wurde von einem Moderator gelöscht.
Rudolph R. schrieb: > Nur ist der Code eben immer noch da und erschwert das Lesen. wenn man den Code ordentlich klont sind dafür Änderungen vom Original wesentlich leichter wieder zu übernehmen, deshalb würde ich den nicht so radikal schreddern. Es ist da auch schon Support für viele verschiedene Displays eingebaut, ist deines wirklich nicht dabei? Davon ab finde ich das Handling mit SD-Card und Display nicht besonders praktisch, ein OctoPi mit Netzwerkanschluss bringt viel mehr.
Rudolph R. schrieb: > Jain, -E für sich macht im Grunde nichts anderes als -save-temps. > Nur das die .o Dateien den Präprozessor-Text enthalten und das Projekt > nicht compiliert. .o heißen die nur, wenn du dem Compiler sagst, dass er sie so nennen soll. -E führt einfach nur den Präprozessor aus, und schreibt das Ergebnis in die angegebene Zieldatei, statt den eigentlichen Compiler aufzurufen und es an den weiterzugeben.
[…] Johannes S. schrieb: > wenn man den Code ordentlich klont sind dafür Änderungen vom Original > wesentlich leichter wieder zu übernehmen, deshalb würde ich den nicht so > radikal schreddern. Änderungen würde ich wenn überhaupt nur im Original mache, richtig. Aber erstmal ist die Frage was da überhaupt passiert. Mir scheint das Compilat auch erheblich zu fett zu sein für was das Ding macht. > Es ist da auch schon Support für viele verschiedene Displays eingebaut, > ist deines wirklich nicht dabei? Nope, das wäre ganz was neues. > Davon ab finde ich das Handling mit SD-Card und Display nicht besonders > praktisch, ein OctoPi mit Netzwerkanschluss bringt viel mehr. Jeder wie er mag, ich sehe da quasi Null Vorteil drin. Ich hatte auch schon überlegt eine IP-Cam zu besorgen und auf den Drucker zu richten, das ist aber mehr ein Tribut an die Faulheit. Und so nehme ich den gelegentlichen Gang zum Drucker nicht als Bürde, sondern vielmehr als zusätzliche Gelegenheit mich zu bewegen. Ich drucke aber auch nicht für xx Stunden über Nacht und so, na vielleicht noch nicht.
:
Bearbeitet durch Moderator
Rudolph R. schrieb: > Nur ist der Code eben immer noch da und erschwert das Lesen. In Eclipse kann man sich inaktiven Code automatisch einklappen lassen. Man muss dann nur noch einzelne graue Zeilen überlesen - siehe Screenshots. Rudolph R. schrieb: > Ist aber ein klares no-go für mich, Eclipse und JAVA kommen nicht auf > die Kiste. Wenn man sich natürlich unbedingt einschränken will... Rudolph R. schrieb: > Das ist auch nicht "mal eben so" installiert und läuft dann, so "nackig" > wird das wohl auch nicht funktionieren. Für Eclipse musst du ein .zip-Archiv runterladen und entpacken. Und die Java-Installation ist auch narrensicher. Da sind Visual Studio, Atmel Studio usw. schon deutlich komplizierter (und größer sowieso). http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/oxygen2
Dr. Sommer schrieb: >> Nur ist der Code eben immer noch da und erschwert das Lesen. > In Eclipse kann man sich inaktiven Code automatisch einklappen lassen. > Man muss dann nur noch einzelne graue Zeilen überlesen - siehe > Screenshots. Okay, das ist nett. >> Ist aber ein klares no-go für mich, Eclipse und JAVA kommen nicht auf >> die Kiste. >Wenn man sich natürlich unbedingt einschränken will... Ich habe Eclipse schon gesehen, mich damit nicht rumzuärgern sehe ich nicht als Einschränkung. Dr. Sommer schrieb: > Für Eclipse musst du ein .zip-Archiv runterladen und entpacken. > Und die Java-Installation ist auch narrensicher. > Da sind Visual Studio, Atmel Studio usw. schon deutlich komplizierter (und größer sowieso). Mal davon ab, dass die Größe der Archive nicht relevant ist. In den 890 MB für das Atmel-Studio sind drei Compiler, Includes für zig Controller, USB-Treiber und Firmware-Daten für diverse Debuger enthalten, wahrscheinlich noch mehr Kram der mit dem Editor an sich nichts zu tun hat. Dennoch ist die Installation total einfach. Und Du kennst vscode nicht, der reine Editor hat nur 42 MB, selbst mit Plugins sind das weniger als die 67 MB die alleine die JRE Installation hat: https://code.visualstudio.com/
Na, wenn die anderen Tools so viel besser und Eclipse so schlecht ist, dann sollten die das ja auch können.
Rudolph R. schrieb: > vor allem lösen viele Defines wieder neue > Defines aus, dass der eigentliche Code der am Ende ausgeführt wird nur > schwer zu sehen ist. Nimm eine IDE die unbenutzte ifdefs ausgrauen kann. Eclipse kann das zum Beispiel.
Vielleicht kann ja auch mal einer der Emacs-Verfechter kurz vorbeikommen und zeigen wie man das Ausgrauen von unzutreffenden ifdefs in Emacs aktiviert. /s
Dr. Sommer schrieb: > Na, wenn die anderen Tools so viel besser und Eclipse so schlecht > ist, > dann sollten die das ja auch können. Eclipse braucht ja ganz viel JRE, VS nur ein paar Gig .NET ;-)
Amateur schrieb: > Eclipse braucht ja ganz viel JRE, VS nur ein paar Gig .NET ;-) Fatal! Immerhin muss man zur Installation von VS nicht mehr 5x den PC neu starten wie früher™.
Dr. Sommer schrieb: > Na, wenn die anderen Tools so viel besser und Eclipse so schlecht ist, Komische Aussage, wie kommst Du da jetzt drauf? Aus dem was ich geschrieben habe hast Du das nicht ableiten können, eher im Gegenteil. Aber noch mal ganz langsam getippt, zum langsam lesen, ich will Eclipse nicht haben und das ist für sich keine Wertung. Mein Verlust, mag sein bei dem einen Feature, aber damit kann ich leben. Bernd K. schrieb: > Nimm eine IDE die unbenutzte ifdefs ausgrauen kann. Vielen Dank für diesen wertvollen Hinweis. Ach ja, da sind wir schon drauf gekommen. Amateur schrieb: > Eclipse braucht ja ganz viel JRE, VS nur ein paar Gig .NET ;-) Mal davon abgesehen, dass auch "ein paar Gig" nicht mehr relevant sind? Und davon abgesehen, dass das nicht extra installiert werden muss? Und https://code.visualstudio.com/ braucht .net 4.5.2, da hat der Offline-Installer für Win10 gerade mal 67MB. Aktuell ist wohl gerade 4.7.1 und das ist geringfügig kleiner. Und ich möchte mal festhalten, dass der Dr.Sommer mit dem albernen "schon deutlich komplizierter (und größer sowieso)" angefangen hat. Mich interessiert es eher nicht so, ob das 50MB oder 500MB sind, aber so Unsinn wie das Atmel-Studio ist größer als Eclipse muss nicht sein.
Rudolph R. schrieb: > Und https://code.visualstudio.com/ braucht .net 4.5.2, da hat der > Offline-Installer für Win10 gerade mal 67MB. Braucht das wirklich .net? Wie ich das verstanden habe ist das JavaScript mit einem Framework (Electron?) und soll auch auf dem Raspberry laufen.
Die Windows Version von vscode braucht .net, die Linux und die IOS Versionen haben andere Abhängigkeiten. https://code.visualstudio.com/docs/supporting/requirements
:
Bearbeitet durch User
Rudolph R. schrieb: > code > visualstudio > Atmel-Studio Code hat mit Visualstudio nichts gemeinsam außer den Namen. Atmelstudio basiert auf Visualstudio und hat daher ebenfalls nichts mit Code zu schaffen.
:
Bearbeitet durch User
Bernd K. schrieb: > Code hat mit Visualstudio nichts gemeinsam außer den Namen. Wird wohl der Grund gewesen sein, warum ich das nicht in einem Zug genannt habe.
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.