Ist die Programmierung mit Lazarus Free-Pascal zeitgemäß??

[pluto]

Wie mans nimmt. Wenn ich AVR Embedded für Lazarus installieren will, ist das selbst mit FPCupdeluxe noch sehr "Expertenwissen", dauert mitunter schonmal ein Stündchen, ist ein Sackgang, wenn man es für mehrere Subarchs (verschiedene ATmega, ATtiny) einrichten will und man hat gute Chancen sich die Installation beim nächsten Update zu zerschießen

Ich hatte in der Vergangenheit oft das Problem, dass irgendwelche Libs sich nicht mehr kompilieren lassen, wegen irgendwelchen Fehlern, die vorher aber keine rolle gespielt haben.
Gerade bei Updatest und der gleichen.

Die Arduino IDE lade ich mir runter, installiere sie und kann loslegen. Wenn das so aufwendig wäre wie den Crosscompiler für AVR Embedded zu installieren hätte von Arduino nie jemand was gehört.

Mit allen nach und vorteilen, aber es geht...

Aber: Ja, die Erfahrung mit Atmel unter Lazarus habe ich auch gemacht... bis man da eine lauffähige IDE hat, vergeht schon einige Zeit

Eigentlich nicht, beim erste mal war ich richtig überrascht wie einfach das inzwischen geworden ist... Dank FPCupdeluxe.

Was ist Arduino

Das ist eine gute Frage...

Atmel ist inzwischen min Microchip übernommen worden, ATMega wird also sicher auf die Dauer unwichtig werden, weil die Microchip-native PIC32 Serie für industrielle groß-Serien besser erscheint und für andere Anwendungen Hardware-mäßig auch sehr gut geeignet ist).

Die PIC32 lassen sich, soweit ich weiß nicht so schön Entwickeln wie ein atMega... auch wenn die atMegas nicht mehr Zeitgemäß sind....

[mschnell]

"schön" ist eine sehr individuelles Kriterium
-Michael

[pluto]

"schön" ist eine sehr individuelles Kriterium

schön kann man auch ersetzten mit "nicht so einfach" oder extrem kompliziert das habe ich von Leuten gehört, die extrem viel Ahnung davon haben.
Wenn das schon für die nicht so einfach ist, wie soll das dann jemand machen, der von Arduino verwöhnt ist?

[Timm Thaler]

Atmel ist inzwischen min Microchip übernommen worden, ATMega wird also sicher auf die Dauer unwichtig werden...

Ach Gottchen, die ATmegas sind schon so oft totgesagt worden. Selbst wenn Microchip ernsthaft so blöd wäre auf das Geschäft mit den ATmega328 in den ganzen Arduino Uno und Nano zu verzichten - würde ein Chinese die als Klon auflegen. Gut, die hätten dann ein bißchen höheren Stromverbrauch und das Standardpasswort wäre 12345. aber geben wird es die weiterhin.

[Warf]

Wie mans nimmt. Wenn ich AVR Embedded für Lazarus installieren will, ist das selbst mit FPCupdeluxe noch sehr "Expertenwissen", dauert mitunter schonmal ein Stündchen, ist ein Sackgang, wenn man es für mehrere Subarchs (verschiedene ATmega, ATtiny) einrichten will und man hat gute Chancen sich die Installation beim nächsten Update zu zerschießen, weil mal wieder irgendwelche Pfade ins Leere laufen. Und dann habe ich immer noch keinen Uploader, sondern muss mir AVRdude und AVR-Burn-o-mat installieren, das veraltete Configfile des Burn-o-mat für moderne ATmegas anpassen...

Die Arduino IDE lade ich mir runter, installiere sie und kann loslegen. Wenn das so aufwendig wäre wie den Crosscompiler für AVR Embedded zu installieren hätte von Arduino nie jemand was gehört.

Man könnte jetzt die frage in den raum werfen, warum du dir nicht einfach einmal die arbeit machst, das dockerst (1 docker tag pro target), und dann einfach die docker container benutzt. Die entsprechenden Dockerfiles könnte man dann z.B. hier teilen, und jeder der dann avr fpc benutzen möchte kann über 2 zeilen in der Kommandozeile sich ein voll konfigurierten container runterladen und du musst dich nie darum kümmern das irgendwas kaputt geht, weil du kannst den container immer wiederherstellen... Rein hypothetisch

[Timm Thaler]

Rein hypothetisch

Genau. Rein hypothetisch.

Praktisch muss man für AVR Embedded mit der aktuellen Trunk arbeiten und da auch immer mal ein Update holen, wenn es ein Bugfix gab.

Praktisch ist meine Lazarus für AVR Embedded Installation 4GB groß. Ich hab hier Bauern-DSL, da dauert das einen Tag, das hochzuladen. Und 4GB als Anhang im Forum - glaub ich nicht.

[Warf]

Genau. Rein hypothetisch.

Praktisch muss man für AVR Embedded mit der aktuellen Trunk arbeiten und da auch immer mal ein Update holen, wenn es ein Bugfix gab.

Praktisch ist meine Lazarus für AVR Embedded Installation 4GB groß. Ich hab hier Bauern-DSL, da dauert das einen Tag, das hochzuladen. Und 4GB als Anhang im Forum - glaub ich nicht.

Ok ich wusste nicht das es so instabil ist das man auf updates angewiesen ist (aufm desktop versuche ich innerhalb eines Projekts wenn möglich weder FPC noch lazarus version zu wechseln). Und du musst ja nicht den container hochladen, sondern nur den dockerfile, das ist ein script was dann praktisch den dockercontainer baut. Der würde dann z.B. einen Debian Testing container nehmen, dort drin avr-gcc, etc, fpc und svn installieren, die fpc sources auscheckt, und so compilen das es mit einem bestimmten board kompatibel ist z.B. dem Arduino mega. Daraus kann jeder sich lokal einen Image erstellen, und wenn man dann ein Mega projekt hat, könnte man einfach in docker einen neuen container von avrfpc:atmega2560 oder so starten, der dann voll konfiguriert ist.

Wenn der entwicklungsstand aber so ist das man auch innerhalb eines projekts den fpc updaten muss, macht das natürlich keinen sinn. Ansonsten kann man mit docker sehr einfach verschiedene Compilerversionen behalten, ohne sein eigenes OS zuzumüllen.

Ich hab ma mit nem projekt gearbeitet da war das buildsystem so fürn arsch, mit so vielen dependencies (z.T. wurde eine bestimmte commit version eines git repos benötigt), das ein docker container zu benutzen bei dem alle build tools installiert sind praktisch der einzige weg war um irgendwas produktiv (und vor allem reproduzierbar) zu machen. Daher bin ich grundsätzlich bei exotischen toolchains (also welche die viel konfiguration brauchen) ein fan von docker

[Timm Thaler]

Ok ich wusste nicht das es so instabil ist das man auf updates angewiesen ist

Es ist nicht instabil, aber es wurde im letzten Jahr viel dran optimiert, da anscheinend das Interesse gestiegen ist AVR Controller mit Pascal zu programmieren. Ich hab auch schon ein paar Bugs oder Feature Requests gemeldet, und die wurden innerhalb weniger Stunden bis Tage umgesetzt. Und wenn man die Optimierungen mitnehmen will, muss man halt updaten.

[Warf]

Ja instabil meinte ich nicht im sinne von geht oft kaputt oder so, sondern einfach in dem sinne, da ändert sich viel dran. Aber ich gehe mal davon aus, das sich dann auch in der benutzung noch einiges ändern wird, vielleicht gibts auch bald ne out of the box version, avrLazarus, was man einfach installiert und loslegen kann.

Tatsächlich hab ich wegen der diskussion hier auch mal wieder einen meiner Arduinos ausgepackt und wollte MPLab X installieren, aber das geht auch nicht schmerzfrei. MPLab kann nicht mit dem open Source AVR gcc arbeiten den es bei mir in den Package repositories gibt, sondern braucht den speziellen von Microchip, für den aktuell die Downloadserver nicht erreichbar sind.

[marcov]

...eben, meine ich ja auch, mit Lazarus sind wir da schon verwöhnt

Wie mans nimmt. Wenn ich AVR Embedded für Lazarus installieren will, ist das selbst mit FPCupdeluxe noch sehr "Expertenwissen", dauert mitunter schonmal ein Stündchen, ist ein Sackgang, wenn man es für mehrere Subarchs (verschiedene ATmega, ATtiny) einrichten will und man hat gute Chancen sich die Installation beim nächsten Update zu zerschießen, weil mal wieder irgendwelche Pfade ins Leere laufen. Und dann habe ich immer noch keinen Uploader, sondern muss mir AVRdude und AVR-Burn-o-mat installieren, das veraltete Configfile des Burn-o-mat für moderne ATmegas anpassen...

Die Arduino IDE lade ich mir runter, installiere sie und kann loslegen. Wenn das so aufwendig wäre wie den Crosscompiler für AVR Embedded zu installieren hätte von Arduino nie jemand was gehört.

Also dort ist distribution auch eine sache einer 3rd Party, man ladet es nicht vom GCC's Seite herunter

[Warf]

Also dort ist distribution auch eine sache einer 3rd Party, man ladet es nicht vom GCC's Seite herunter

Aufm mac kann man sich den avr gcc mit homebrew installieren, das lädt die sources runter und kompiliert vom source. Auf meinem MacBook Air mit nem dual core i3 braucht das schlappe 2-3 stunden. Also was das angeht sind wir mit dem fpc richtig verwöhnt, das man ihn "nur" in 10-20 minuten gebaut bekommt. Und dabei kann man den FPC nicht mal parallel kompilieren, den GCC schon, und selbst auf 12 cores (24 hyperthreads) dauert das bei mir immernoch länger als der fpc single core

[pluto]

Und dabei kann man den FPC nicht mal parallel kompilieren, den GCC schon, und selbst auf 12 cores (24 hyperthreads) dauert das bei mir immernoch länger als der fpc single core

Da wäre die Spannende Frage: Warum ist das so? Warum ist der GCC in diesen Fall so extrem Langsam.... FPC muss ja irgendwas anders machen...

[Warf]

Da wäre die Spannende Frage: Warum ist das so? Warum ist der GCC in diesen Fall so extrem Langsam.... FPC muss ja irgendwas anders machen...

Allein durch das sprachdesign ist Pascal deutlich effizienter zu kompilieren als C. C benötigt allein 7 durchläufe übder die Datei um den Abstract syntax tree zu bauen, bei Pascal ist es nur einer. Dann macht der GCC denke ich mal auch noch mehr im bezug auf optimierungen, und C hat noch einen präprozessor indem man auch beliebig komplizierte Programme implementieren kann. Dann glaube ich das pascal das includen von anderen units effizienter gestaltet (z.B. mit vorkompilierten headern, die man in C nicht standardmäßig verwendet), da kenn ich mich aber zu wenig aus.

Und dann dauert das linken von C programmen noch unfassbar lange, eventuell kompilieren die kleinschrittiger, oder der fpc hat da irgendwelche tricks. Und man darf nicht vergessen das der gcc ein größeres software projekt ist, da ist ein C, ein C++ ein Fortran und ein Ada compiler dabei (nur C und C++ dauert auch viel länger als der fpc), sowie noch die glibc, asan und ubsan und die unittests (wenn man die vergisst auszuschalten dauerts gut ma 1-2 stunden länger bis alle tests durch sind), ist also nur teilweise mit dem fpc vergleichbar

[mschnell]

Der Fokus von C liegt darauf, optimalen Code zu erzeugen. Einerseits durch automatische Optimierungen, andererseits dadurch, dass dem Programmierer die Möglichkeit gegeben wird, genau zu spezifizieren, was optimiert werden kann (z.B. durch "volatile"). Das macht beim Compilieren natürlich erheblichen Aufwand.
-Michael

[Warf]

Der Fokus von C liegt darauf, optimalen Code zu erzeugen. Einerseits durch automatische Optimierungen, andererseits dadurch, dass dem Programmierer die Möglichkeit gegeben wird, genau zu spezifizieren, was optimiert werden kann (z.B. durch "volatile"). Das macht beim Compilieren natürlich erheblichen Aufwand.
-Michael

Ich geb dir da zweifellos recht, aber volatile ist ein schlechtes beispiel, da man das genau nicht damit machen soll (also versuchen die optimierung zu steuern), zumindest nicht im allgemeinen. Volatile hat genau einen anwendungszweck und exsistenzgrund, zur ermöglichung von direct memory access auf ring 0 (kernel ebene/mikrocontroller). Volatile garantiert lediglich das alle Memoryoperationen genau in der reihenfolge ausgeführt werden wie sie definiert sind, nicht mehr nicht weniger. Es gibt zwar viele die volatile als debug trick benutzen damit die variable nicht wegoptimiert wird, das ist aber eigentlich nicht so im standard definiert. Das einzige was nicht wegoptimiert werden kann sind die zugriffsoperationen, aber z.B. wenn ich nur die addresse von einem volatile objekt benutze, und damit rumrechne, ohne einen store oder read von dem objekt selbst zu machen (ich kann ja später über den pointer als void pointer zugreifen, z.B. via memset) kann der Optimizer das trozdem schön wegoptimieren. Daher hat, außerhalb von DMA auf kernel ebene / auf dem Microcontroller, volatile eigentlich nichts zu suchen.

Ein besseres Beispiel wären die __attribute__((attr)) gewesen, mit denen man den Compilevorgang sehr feingranular anpassen kann z.B. mit __attribute__((optnone)) kann man die optilierung einer funktion komplett ausschalten (Clang). Leider sind die alle compiler abbhängig und im C standard nicht definiert