Hallo, beim Raspi soll wiringPi/wiringSerial in ein vorhandenes C-Beispielprogramm (https://github.com/Sensirion/raspberry-pi-i2c-scd4x) integriert werden. WiringPi liegt entpackt und betriebsbereit (gpio -v: Version 3.4) in einem zweiten Verzeichnis. Wie ist das dem Beispielprogramm beiliegende Make-File (im Anhang) nun zu ergänzen daß es beim Linken keine Fehler gibt (undefined reference to ... )? Dank&Gruß Gerhard
Wie ich das sehe wird wiring Pi nicht verwendet. Es sollte reichen build-essential zu installieren wie im readme beschrieben.
J. S. schrieb: > Wie ich das sehe wird wiring Pi nicht verwendet Es soll aber später verwendet und deshalb ins Programm integriert werden.
Dann würde ich mich an einem wiring Pi Beispiel orientieren: https://github.com/WiringPi/WiringPi/tree/master/examples Die zusätzlichen libs werden mit -l angegeben und müssen im Suchpfad für die libs vorhanden sein.
J. S. schrieb: > Die zusätzlichen libs werden mit -l angegeben und müssen im Suchpfad für > die libs vorhanden sein. Ja, soweit hab ich es auch schon durchschaut... Doch egal wie ich es anstelle- es hagelt Fehler. Immer wieder absurd, wie kryptisch und umständlich diese C-Programmierung funktioniert. Make - eine Geheimwissenschaft :)
Gerhard H. schrieb: > Ja, soweit hab ich es auch schon durchschaut... > Doch egal wie ich es anstelle- es hagelt Fehler. Kompiliert denn das wiring Pi Beispiel ohne Fehler? Welche Fehlermeldung kommen denn? Vielleicht sind sie für andere Leute leichter verständlich und führen zu einer Lösung?
Gerhard H. schrieb: > Ja, soweit hab ich es auch schon durchschaut... > Doch egal wie ich es anstelle- es hagelt Fehler. Zeig' doch mal. Hast Du dran gedacht, daß Du für "libblafusel.a" als Linkeroption "-lblafusel" und nicht "-llibblafusel.a" verwenden musst? Hast Du --wie in einem anderen Thread hier-- den Unterschied zwischen Library und Headerdatei verstanden? Wenn eine "lib" im Arduino-Sprech gemeint ist, ist das meistens keine Library, sondern eine Headerdatei, und die wird nicht mit -l dem Linker übergeben, sondern in Deinem Sourcefile mit #include eingebunden. Alternativ ließe sich das als Kommandozeilenoption für den Compiler angeben, da ist das dann "-include blafusel.h". Das ist aber aus Gründen der Übersichtlichkeit und Nachvollziehbarkeit nicht zu empfehlen.
Das Build-File = die Lib wiringPi.h wurde ordnungsgemäß in usr/local/include als wiringPi.h erzeugt und wird von mir im Beispielprogramm beschwerdefrei #include t. Damit sollte der Compilier-Maschinerie doch alles bekannt sein. Aber warum einfach wenn es auch kompliziert geht: Sobald nun eine Funktion daraus aufgerufen wird folgt unverständlicherweise trotzdem ein Linker-Fehler "undefined reference to". Der wiredPi Dokumentation zufolge ist den Compilierparametern (zusätzlich?) -lwiringPi hinzuzufügen. Das müsste ja nun irgendwo in obigem Make-File geschehen, genauso wie die Angabe weiterer wiringPi Files !??
Gerhard H. schrieb: > Der wiredPi Dokumentation zufolge ist den Compilierparametern > (zusätzlich?) -lwiringPi hinzuzufügen. Das ist die klassische Vorgehensweise. Deine "wiringpi.h" ist keine Library, sondern nur eine Headerdatei, in der Deklarationen für Funktionen und Typen drinstehen, aber kein Code. Der Code kommt (in vorverdauter Form) aus der Library libwiringpi.a, und Du musst diese dem Linker vorwerfen, damit der den Code zu Deinem Programm dazulinken* kann. Zeig' doch mal Dein makefile. Da sollte man den Compiler- und den Linkeraufruf erkennen können; ich nehme mal an, daß Dein Projekt aus mehr als einem Sourcefile besteht, oder? *) manche finden es schicker, hier "gegen" zu sagen, warum auch immer.
Harald K. schrieb: > Zeig' doch mal Dein makefile. Siehe ganz oben. Es ist das Makefile des Beispielprogramms welches entsprechend abgeändert werden soll.
Ach so, ich hatte angenommen, daß Du da schon was eigenes gestrickt hättest. Du schreibst "wie auch immer Du es anstellst" - und genau das wollte ich eigentlich sehen, nicht das, wo Du noch gar nichts angestellt hast. Denn daß dem Linker mit -l mitgeteilt werden muss, welche Library zu verwenden ist, hat Dir schon jojos mitgeteilt. Ich hatte angenommen, daß Du daraufhin schon was gemacht hättest. Nun gut. Da in dem Makefile da oben alles über den Compileraufruf $(CC) erfolgt, würde ich der Zeile CFLAGS noch die Option -lwiringPi einsetzen. Und wenn das nicht genügt, würde ich noch die Option -L verwenden, bei der das Verzeichnis anzugeben ist, in dem libwiringPi.a liegt.
Harald K. schrieb: > würde ich der Zeile CFLAGS noch die Option -lwiringPi einsetzen Habe ich. Ändert nichts. > würde ich noch die Option -L verwenden, bei > der das Verzeichnis anzugeben ist, in dem libwiringPi.a liegt In der Dokumentation zur Verwendung von wiringPi habe ich von keiner solchen Datei gelesen. Im wiringPi Verzeichnis existiert sie ebensowenig. Wo sollte die denn zu finden sein? Nach wie vor verstehe ich nicht, warum ein #include <wiringPi.h> im Beispielprogramm scd4x_i2c_example_usage.c nicht ausreicht. Hoch undurchsichtig das Ganze.
Gerhard H. schrieb: > Im wiringPi Verzeichnis existiert sie > ebensowenig. Wo sollte die denn zu finden sein? Dann musst Du die Library erst aus dem Sourcecode von wiringpi erzeugen. Sieh Dir mal das Makefile hier an: https://github.com/WiringPi/WiringPi/blob/master/wiringPi/Makefile Die Library setzt sich aus einer ganzen Menge einzelner Sourcefiles zusammen (sie werden mit SRC = aufgelistet). Und dieses Makefile erzeugt, wenn Du es korrekt aufrufst, eine Datei namens libwiringPi.a bzw. libwiringPi.so (der Name steht in Zeile 34/35) Gerhard H. schrieb: > Nach wie vor verstehe ich nicht, warum ein > > #include <wiringPi.h> > > im Beispielprogramm scd4x_i2c_example_usage.c nicht ausreicht. Hast Du Dir die Datei mal angesehen? https://github.com/WiringPi/WiringPi/blob/master/wiringPi/wiringPi.h Da steht nur drin, daß es irgendwo Funktionen gibt. Das nennt man Funktionsprototypen oder Deklarationen. Der Quelltext der Funktionen ist da aber nicht drin. Damit kann Dein Compiler Deinen Sourcecode übersetzen, aber der Linker ist nötig, um den zu den Funktionen gehörenden Code dazuzupacken. Und der muss natürlich wissen, wo der zu finden ist - deswegen gibt es die Optionen -l und -L. Wenn Du z.B. die Funktion printf verwendest, musst Du #include <stdio.h> angeben. Aber auch in dieser Datei steht nicht der Quellcode dieser Funktion drin, sondern nur die Deklaration dieser Funktion. Der Binärcode der Funktion ist in der libc zu finden, die standardmäßig zu Deinen Programmen dazugelinkt wird. Das ist bei Libraries in C immer so organisiert. In C++ kann es auch anders organisiert werden, ist es aber zu großen Teilen auch nicht. So etwas wird unter anderem aus Geschwindigkeitsgründen gemacht - es ist völlig sinnlos, den Quellcode von Funktionen wie printf jedes Mal erneut zu übersetzen. Es bedeutet aber nicht, daß zu Deinem Programm immer alles dazugestopft wird, was in der Library drin ist; der Linker holt sich aus der Library nur den Code der benötigten Funktionen. Das Dateiformat von Libraries (*.a) ist eine Sammlung mehrerer Objektdateien (*.o), die beim Übersetzen der Librarysourcen aus den Quelltextdateien erzeugt werden. Zurück zu Deinem Makefile-Problem. Sieh Dir mal dieses Makefile an: https://github.com/WiringPi/WiringPi/blob/master/wiringPi/test/Makefile Das baut ein paar Testprogramme für wiringPi. (Ausschnitt)
1 | wiringpi_test1_sysfs:
|
2 | ${CC} ${CFLAGS} wiringpi_test1_sysfs.c -o wiringpi_test1_sysfs -lwiringPi |
Und siehe da, da steht -lwiringPi -- Ich sehe gerade, daß die Library nicht mehr als statische Library gebaut wird, sondern nur als dynamische (oder "shared") Library, damit sollte Dein Buildsystem aber klarkommen. Orientiere Dich am Test-Makefile.
Gerhard H. schrieb: > Nach wie vor verstehe ich nicht, warum ein > > #include <wiringPi.h> > > im Beispielprogramm scd4x_i2c_example_usage.c nicht ausreicht. > > Hoch undurchsichtig das Ganze. Nö, ist eigentlich recht simpel. Im Header (das ist die Sache mit *.h) steht normalerweise bloß, dass es da irgendwo eine Funktion gibt, wie die heisst und welche Signatur sie hat. Das genügt erstmal für den Compiler, um das Objektfile für deine C-Datei zu erzeugen, die diese Funktion benutzt. In diesem Objectfile steht dann drinne, dass da noch eine Funktion fehlt (genau genommen: nur deren konkrete Adresse fehlt noch). Diese fehlende Funktion kann nun aus zwei Quellen kommen. Entweder gibt es auch noch eine wiringpi.c. Dann musst du dem Compiler sagen, dass er diese Datei bitte auch zu einem Objectfile verarbeiten möge. Dann ist diese Funktion halt in der Objectdatei, die aus der wiringpi.c erzeugt wird. Und da steht wiederum drinne: hallo, ich habe hier eine Funktion mit diesem und jenen Namen, die aufgerufen werden könnte. Oder irgendjemand hat dir diesen Teil schon abgenommen und sozusagen vorab compiliert. Dann landet das Ergebnis in einer Datei mit der Endung "a". Der Compiler bei dir hat mit dieser *.a-Datei aber überhaupt nichts zu tun. Der eigentliche Trick passiert in der zweiten Stufe, beim Linken. Der Linker entscheidet in letzter Instanz, auf welcher Adresse eine Funktion konkret landet. Und er durchsucht alle anderen Objekte nach Referenzen auf diese Funktion und trägt dort die korrekte Adresse ein. Das ganze nennt sich Relozierung oder Relokation. Der Name kommt daher, das jedes einzelne Objekt vom Compiler zunächst erstmal so übersetzt wird, als würde es bei Adresse 0 beginnen. Das geht natürlich in der Realität nicht. Der Linker zieht das glatt und sorgt dafür, dass im realen Speicher später nix überlappt. Kann er aber nicht, wenn es die referenzierte Funktion nirgendwo gibt. Dann kommt genau deine Fehlermeldung. Der Linker muss also mitgeteilt bekommen, dass und wo es entweder eine wringpi.o gibt (falls bei dir vom Compiler aus der wiringpi.c erzeugt) oder halt die wiringpi.a. Diese ganze Sache mag ziemlich aufwendig erscheinen, hat aber deutliche Vorteile. Z.B. kann der Linker feststellen, dass es einen Arschvoll Funktionen gibt, die überhaupt niemals referenziert werden. Dann kann er die einfach rauswerfen, bevor er das Endergebnis produziert. Sprich: den Code kleiner machen.
Angehängte Dateien:
-
c-output.jpg
70 KB
Wiegesagt, die Ergänzung von -lwiringPi in der Makefile- CFLAGS Zeile bewirkt nichts. Harald K. schrieb: > Dann musst Du die Library erst aus dem Sourcecode von wiringpi erzeugen. Eine solche infrage kommende ist mit dem ./build des installierten wiringPi offensichtlich erzeugt und fand ich (nicht als .a aber) unter /usr/local/lib/libwiringPi.so.3.4. > Und > der muss natürlich wissen, wo der zu finden ist - deswegen gibt es die > Optionen -l und -L. Zu finden ist die Lib also in einem dafür offensichtlich vorgesehenen Verzeichnis /usr/local/lib und die offensichtliche Frage ist, warum das nicht automatisch berücksichtigt wird...?? Bislang habe ich das DazuLinkenMüssen der fertigen Lib noch in keinem einzigen wiringPi Beispiel gesehen und war der Meinung, dies würde schon irgendwie mit #include <wiringpi.h> realisiert wie eigentlich jeder gesunde Menschenverstand vermittelt. Und nein, da hatte ich deshalb noch nicht reingeschaut. Was tut nun eigentlich obiges -lwiringPi Hilfreiches zur Sache? Ob S. schrieb: > Diese ganze Sache mag ziemlich aufwendig erscheinen Sie ist es, noch wohlmeinend. Vor allem wenn man hier das lächerlich kleine Endergebnis (permanente Anzeige von 3 I2C-Messwerten) ins Verhältnis setzt. Da ist ja das Makefile fast schon größer als der eigentliche Code :) Wenn, dann gewinnt dieser aufwendige Compilier/Link-Zirkus für riesige Programme mit x Quellen Sinn. Erst dann kann man auch die Ziele Code + Compilierzeit Reduzierung nachvollziehen. Ich bin bislang keinen Millimeter weiter. Das Prozedere ist doch einfach nur irre. Im Anhang das mit einem wiringPi-Lib Aufruf erweiterte Hauptprogramm, das mit -lwiringPi erweiterte Make-File und das unverändert unbefriedigende Compilier-Ergebnis auf der Pi-Kommandozeile.
Gerhard H. schrieb: > das mit -lwiringPi erweiterte Make-File NEIN, das mit "-lwiringPi." erweiterte Make-File, der abschließende Punkt hat dort nichts zu suchen.
Martin H. schrieb: > NEIN, das mit "-lwiringPi." erweiterte Make-File, der abschließende > Punkt hat dort nichts zu suchen. Soweit war ich bereits mit Experimentieren um herauszufinden, daß dieser Punkt (im Originalprogramm) durchaus notwendig war! Das Entfernen hat für mein obiges Compilierergebnis übrigens keinerlei sichtbare Auswirkung.
der Punkt gehört eher zum Schalter -I, also aktuelles Verzeichnis inkludieren. Ja es ist kompliziert, aber nur wenn man Grundlagen überspringen will und wild herumprobiert.
J. S. schrieb: > der Punkt gehört eher zum Schalter -I ... womit Du den entscheidenden Nagel auf den Kopf getroffen hast, denn mit Punkt hinterm -I plus -lwiringPi läuft die Compilierung fehlerlos! Besten Dank an Dich und Martin. Angelegenheit geklärt. Ich dachte der Punkt wär irgendein notwendiger Zeilenabschluss. Das empfohlenene DazuLinkenMüssen der ganzen Lib ist damit wohl gegenstandslos. > Ja es ist kompliziert Bei meiner Einschätzung der Geschichte bleibe ich selbstredend. Der eine bezeichnet es als "Grundlagen", der andere als in der Sache überflüssig...
Gerhard H. schrieb: > Bei meiner Einschätzung der Geschichte bleibe ich selbstredend. > Der eine bezeichnet es als "Grundlagen", der andere als überflüssig... Der eine weiß wovon er redet, der andere tendenziell eher nicht… Wer nicht weiß an welcher Seite der Lötkolben heiß wird, wird es schon aus purem Eigennutz lernen wollen. (Oder ständig mit dampfenden Flossen herum laufen)
Das läuft unter Unix schon seit Anno Tubak so. Ich benutze es auch selten, aber durch die vielen Anleitungen im Netz komme ich da meist schnell genug wieder rein. Es ist eben das Gleiche auf einem RPi wie unter irgendeinem Linux auf dem Desktop oder alter Unix Gurke. Auf Unix System gibt es afaik die Umgebegungsvariablen für die (compiler) Includes und Libraries. Nur für Crosscompiling was ich eher mache müssen die Verzeichnisse explizit angegeben werden, aber im Prinzip ist das Kompilieren auf System einfacher. Vor allem einfacher als unter Windows wo Compiler nicht zum System gehören.
Norbert schrieb: > Der eine weiß wovon er redet, der andere tendenziell eher nicht… Wieviel vom Wovon Wo Sinn macht ist eher die Frage lieber Norbert. J. S. schrieb: > Das läuft unter Unix schon seit Anno Tubak so. Das ist ja super, ist aber auch keine Entschuldigung für maßlose Umständlichkeit. Zumindest hier. Aus diesem Fenster lehne ich mich stur weiter. Wie man sieht sind sich ja selbst C-Experten da nicht einig. Welchen Berg künstlicher Probleme ein C-Compiler so alles schaffen kann sieht man gerade recht anschaulich im Beitrag "GCC v14 Release" Gleiches Problem in grün: Riesiger bürokratischer Aufwand für ein paar KB Endergebnis.
Gerhard H. schrieb: > Wieviel vom Wovon Wo Sinn macht ist eher die Frage lieber Norbert. Dieser Thread beweist präzise, das vom ›Wovon‹ wohl noch so Einiges notwendig wäre.
Nun egal Norbert, Jojos & Martin haben eine überaus lästige Nuss für mich geknackt- da will ich hier nicht weiter auf C und dessen Compilier- Gewürge herumreiten. Meine C-Episode beschränkt sich darauf, obiges Programm mit etwas seriellem I/O und Datei-Abspeicherung zu erweitern. Das müsste ich jetzt alleine schaffen.
Gerhard H. schrieb: > Nun egal Norbert, Jojos & Martin haben eine überaus lästige Nuss für > mich geknackt- da will ich hier nicht weiter auf C und dessen Compilier- > Gewürge herumreiten. Das ist nicht nur bei C so, sondern praktisch bei jedem Compiler. Weil alle festgestellt haben, dass es (aus verschiedenen Gründen) sehr nützlich ist, die Codegenerierierung vom Adress-Mapping zu trennen. Wenn dir das noch nie untergekommen ist, zeigt das nur eins: du bist wohl ein Scriptsprachen-Anfänger. Nunja. Jeder hat mal angefangen. Aber: Als Script-Kiddie sollte man in Diskussionen mit den Erwachsenen eher kleine Brötchen backen...
Ob S. schrieb: > Jeder hat mal angefangen ... und manch einer gleich wieder aufgehört. Aus Erfahrung soll man schließlich schlau werden. Ich habe wirklich nicht vor, aus dem Gewürge ein Hobby zu machen, Herr Erwachsener :) Danke nochmal für die gutgemeinten erklärenden Worte weiter oben. Man kann den Aufwand aber nicht schönreden.
Gerhard H. schrieb: > Man kann den Aufwand aber nicht schönreden. Es ist keiner. Wenn man das Konzept, wie ein C-Compiler und der dazugehörige Linker arbeitet, einmal verstanden hat, dann sind solche Dinge fast so selbstverständlich wie zu atmen. Das ist elementares Grundlagenwissen. Hier hat leider die Arduino-Fraktion durch ihren Versuch, das alles möglichst idiotensicher zu verstecken, und durch die ungeschickte Wortwahl viel Schaden angerichtet.
Harald K. schrieb: > Das ist elementares Grundlagenwissen. Nun ich würde eher sagen, das sogenannte "Grundlagenwissen" vergangener Zeiten hast Du Dir mal mühsam angeeignet und das sollte irgendeine dahergelaufene Arduino- Fraktion mit ihrer Forderung nach Vereinfachung bitteschön jetzt nicht so schamlos entwerten. Ich fordere das Gleiche. Das Leben ist einfach zu kurz für irgendwelche Parameter- Wüsten. Der fehlgesetzte Punkt steht einfach in keinem Verhältnis mehr zum Zeitbedarf und Ärger seiner Nichtbeachtung :)
Dir wurde angeboten, Dir das nötige Grundlagenwissen anzueignen. Die hier relevanten Grundlagen wurden Dir nicht nur von mir erzählt. Klar, Du kannst auch aufstampfen und schreien, daß das alles zu kompliziert ist und man Dir doch bitte einen neuen Lolli geben soll. Aber dann kommst Du nicht weiter, und rennst jedesmal gegen die gleiche Wand. Kann man so machen, ist dann halt nur blöd. Und das bizarre ist: Anderswo schreibst Du, daß Du etliches bereits in Assembler veranstaltet hast. Also hast Du sogar einiges an Grundlagenwissen, das Dich weit über den Level der Arduino-rosa-Plüscheinhornfraktion erhebt. Einen Linker kann man auch als Assemblerprogrammierer gebrauchen. Spätestens, wenn man nicht nur ganz triviale Projekte macht, kommt man doch eh' kaum dran vorbei.
:
Bearbeitet durch User
Harald K. schrieb: > Aber dann kommst Du nicht weiter, und rennst jedesmal gegen die gleiche > Wand. Keine unnötigen Sorgen Harald. Gerhard H. schrieb: > Meine C-Episode beschränkt sich darauf, obiges Programm mit etwas > seriellem I/O und Datei-Abspeicherung zu erweitern. Das müsste ich jetzt > alleine schaffen. *** Harald K. schrieb: > Einen Linker kann man auch als Assemblerprogrammierer gebrauchen. > Spätestens, wenn man nicht nur ganz triviale Projekte macht, kommt man > doch eh' kaum dran vorbei. Meine Asm-Projekte sind weder trivial noch werden sie jemals einen Linker brauchen. Dann hätte ich was falsch gemacht...
Testet der Hauptmann gerade aus, in wievielen Threads man sich gleichzeitig zum Horst machen kann bevor auch dem letzten auffällt dass man trollt?
Le X. schrieb: > Testet der Hauptmann gerade aus, in wievielen Threads man sich > gleichzeitig zum Horst machen kann bevor auch dem letzten auffällt dass > man trollt? Da Du hier nichts zum Thema beiträgst fällt Dein Beitrag in genau diese Kategorie. Zu Deiner Info: Das Thema ist geklärt.
Gerhard H. schrieb: > Zu Deiner Info: Das Thema ist geklärt. Andere nutzen sich bietende Möglichkeiten zur Weiterbildung. Aber das würde den Horizont erweitern, und das kann natürlich bei besonders engstirnigen Zeitgenossen schmerzhaft werden.
Harald K. schrieb: > Andere nutzen sich bietende Möglichkeiten zur Weiterbildung. Zunächst sieht man hier jetzt welche die es gerne zur persönlichen Herabwürdigung nutzen. Nicht wahr, Harald? Die nötige "Weiterbildung" habe ich erhalten. Danke der Fürsorge. Umständliches Gewürge mag den einen erfreuen, dem anderen aber Schmerzen bereiten. Nun rate mal wohin meine Tendenz geht...
Gerhard H. schrieb: > Zunächst sieht man hier jetzt welche die es gerne zur persönlichen > Herabwürdigung nutzen. Den Schuh musst Du Dir schon selbst anziehen. Gerhard H. schrieb: > Die nötige Weiterbildung habe ich erhalten. Nö, Du verweigerst Dich ihr. Wie auch Deine Behauptung, nichttriviale Assemblerprojekte ohne Gebrauch eines Linkers durchzuziehen. Ich kannte mal einen Entwickler, der der Ansicht war, sämtlicher zu einem Assemblerprojekt gehörender Quelltext gehörte in eine Datei. Weil das ja viel übersichtlicher wäre. Mit den ganzen Dateien käme man ja nur durcheinander. (Und das war zu einer Zeit, wo man froh war, im Editor etwas über 20 Zeilen Quelltext auf einmal sehen zu dürfen) Aus irgendeinem Grund erinnerst Du mich an den.
Harald K. schrieb: > Den Schuh musst Du Dir schon selbst anziehen. Den dummdreisten Stil eines Herrn, der Null zum Thema beigetragen hat noch so zu relativieren ist wenig redlich. Den Schuh mußt Du Dir anziehen! > Ich kannte mal einen Entwickler, der der Ansicht war, sämtlicher zu > einem Assemblerprojekt gehörender Quelltext gehörte in eine Datei Eine Frage bequemer Handhabung und Minimierung organisatorischer Komplexität. Ab einem gewissen Umfang wiegt der Vorteil thematischer Gliederung in Include-Files dann schwerer. Echter wohlgemerkt. Daß aber bei dem winzigen Funktionsumfang obigen Beispielprogramms schon schweres Linker-Gerät samt Makefile in Stellung gebracht wird ist einfach nur hochgradig lächerlich. Den Umfang bringe ich in einem einzigen Asm-File unter! Ich denke dabei können wir es belassen.
Ja warum hast das dann nicht gleich bare metal und in Assembler auf dem Pi programmiert?
J. S. schrieb: > Ja warum hast das dann nicht gleich bare metal und in Assembler auf dem > Pi programmiert? Assembler ist doch nur etwas für Warmduscher. Echte Kerle nehmen eine Tabelle mit Mnemonics und zugehörigen Hex-Werten in die Hand.
J. S. schrieb: > Ja warum hast das dann nicht gleich bare metal und in Assembler auf dem > Pi programmiert? Ich programmiere Asm auf 8Bit-AVR. Da passt es hin, dafür ist es geeignet. 32Bitter aufwärts sind was für Hochsprache. Daß aber C-Programme obigen Umfangs immer noch so textlastig daherkommen ist doch recht typisch. Dabei sollte Hochsprache eigentlich den nötigen Programmtext verkleinern. Der kann sich auf dem RPi zusätzlich auf die Dienste eines Betriebssystems stützen. Wirklich verwunderlich ist das alles nicht mehr, wenn man allein schon den Compilierzirkus einmal in Aktion gesehen hat. C-Programmierung ist bürokratisch aufgeblasen wohin man schaut. Und sorry, in Kategorien wie Norbert schrieb: > Echte Kerle oder Harald K. schrieb: > Arduino-rosa-Plüscheinhornfraktion denken nur Leute, die Programmierung möglichst kompliziert halten wollen um sich darin dann ziemlich herablassend sonnen zu können.
Gerhard H. schrieb: > Daß aber C-Programme obigen Umfangs immer noch so textlastig daherkommen > ist doch recht typisch. Dabei sollte Hochsprache eigentlich den nötigen > Programmtext verkleinern. > Der kann sich auf dem RPi zusätzlich auf die > Dienste eines Betriebssystems stützen. Und was braucht man dazu, was nimmt man dazu? Bibliotheken! Und was macht man mit denen? Zu den eigenen Objekt-Dateien hinzu linken! Und womit geschieht das? Mit dem Linker! Kleiner Tipp Gerhard. Aus dem tiefen Loch das du dir bereits recht frühzeitig gegraben hast, kommst du nicht heraus indem du immer weiter immer tiefer gräbst.
Norbert schrieb: > Aus dem tiefen Loch das du dir bereits recht frühzeitig gegraben hast Erstaunlich, ich schnuppere eher Höhenluft. In tiefen (C-) Löchern sitzen andere... Nix für ungut. Die Welt ist wie sie ist. Jeder Kläger müsste sich den Vorwurf gefallen lassen, selber nichts zu einer Verbesserung beigetragen zu haben. Soweit möchte ich es hier besser nicht kommen lassen ;-)
Gerhard H. schrieb: > Den dummdreisten Stil eines Herrn, der Null zum Thema beigetragen hat > noch so zu relativieren ist wenig redlich. Ach, ich habe "Null zum Thema beigetragen"? Beitrag "Re: RPi: Wie Linker-Integration von wiringPi" Beitrag "Re: RPi: Wie Linker-Integration von wiringPi" Beitrag "Re: RPi: Wie Linker-Integration von wiringPi" Beitrag "Re: RPi: Wie Linker-Integration von wiringPi" Magst Du Dich entschuldigen?
Harald K. schrieb: > Ach, ich habe "Null zum Thema beigetragen"? Wie kommst Du dazu es auf Dich zu beziehen? Ich schlage vor Du gehst den Chatverlauf nochmal zurück. Wenn Du mit dieser Gewissenhaftigkeit auch programmierst dann weiß ich nicht was dabei rauskommt... :(
Gerhard H. schrieb: > Wie kommst Du dazu es auf Dich zu beziehen? Weil Du gestörter Charakter MICH zitiert hast. "Schuh anziehen", schon vergessen?
Hinterfrage Dich nochmal was Du mit Harald K. schrieb: > Den Schuh musst Du Dir schon selbst anziehen. gemeint hast. Nämlich meine Bemerkung Gerhard H. schrieb: > Zunächst sieht man hier jetzt welche die es gerne zur persönlichen > Herabwürdigung nutzen. Preisfrage: Wer wird das wohl gewesen sein? Und nein Harald, bloß weil Du Dich geirrt hast musst Du mir nicht gleich einen gestörten Charakter vorwerfen. Legitim wäre das allenfalls beim Troll weiter oben gewesen... Für Deine sachlichen Einlassungen weiter oben bin ich dankbar- auch wenn ich in ebendieser Sache widerspreche.
Gerhard H. schrieb: > Preisfrage: Wer wird das wohl gewesen sein? Da Du Dich auch bei diesem Beitrag wieder auf MICH bezogen und MICH zitiert hattest, ist es naheliegend, daß Du Dich auch bei Deiner Aussage auf MICH bezogen hast. Genauso, wie wir das gerade schon mal hatten. Insbesondere Dein nachgesetztes "Nicht wahr, Harald?" lässt kaum auf anderes schließen, vor allem, wo in diesem Thread auch kein anderer Harald auftaucht. Nicht wahr, Gerhard?! Es wäre dem Diskussionsstil gedient, wenn Du nicht MICH zitieren würdest, um dann doch ganz andere Personen (ungenannt bleibende) meinen zu wollen.
Harald K. schrieb: > Es wäre dem Diskussionsstil gedient, wenn Du nicht MICH zitieren > würdest, um dann doch ganz andere Personen (ungenannt bleibende) meinen > zu wollen. Ja Harald. Eine Sache über mehrere Ecken im Verständnis zu behalten ist in der Schnelle des Lebens und der Reaktionen wohl nicht so einfach. Bloß weil Du zitiert wirst muß es ja noch lange nicht um Dich gehen, dazu sollte man dann schon die konkrete Aussage berücksichtigen. OK falsch verstanden, Schwamm drüber.
Gerhard H. schrieb: > Bloß weil Du zitiert wirst muß es ja noch lange nicht um Dich gehen, > dazu sollte man dann schon die konkrete Aussage berücksichtigen. Dann lern' Du das mal, wenn Du schon zitierst. > OK falsch verstanden, Schwamm drüber. Meinetwegen.
Le X. schrieb: > Testet der Hauptmann gerade aus, Das ist doch nur Moby, den kennen wir doch schon. Da er hier zurecht seit einigen Jahren Hausverbot hat, hat er seine Wortwahl leicht verändert, um nicht mehr sofort erkannt und gelöscht zu werden.
Oh da schiebt Ein T roll aber mächtig Frust. Hab ich Dir in der Vergangenheit auch wehgetan? Das tut mir aber leid :(
Das ist den Moderatoren mit Sicherheit bekannt. Ich würde sagen Bewährung verkackt. Die Geschichte vom Frosch und dem Skorpion.
Danke Jojos nochmal für den Tipp. Auch wenn es nur ein . war :)
J. S. schrieb: > Das ist den Moderatoren mit Sicherheit bekannt. Ich würde sagen > Bewährung verkackt. Ach, wer weiß. Aber es ist schon witzig, daß er jedesmal sofort reagiert und mich zu provozieren versucht, wenn ich an seine Identität erinnere. Offenbar habe ich ihn genug geärgert, daß er sich noch an mich erinnert, hihihi. :-)
Ein T. schrieb: > Das ist doch nur Moby, den kennen wir doch schon. Meinst Du? Den hatte ich anders in Erinnerung. Das ist hier ein doch massiv abweichender Stil, ohne diese hämische Überheblichkeit, die bei "moby" aus jeder sich bietenden Körperöffnung quoll. Nee, das halte ich für 'ne Fehldiagnose.
Harald K. schrieb: > Nee, das halte ich für 'ne Fehldiagnose. Ich hingegen bin da absolut überzeugt, bitte erinnere Dich an die Frühphase seiner Trollerei in allen C- und C++-Threads hier im Forum. Derselbe Duktus, derselbe Stil, eine trotz Verstellung sehr ähnliche Wortwahl, dasselbe Thema, grundsätzlich ist das alles genau wie weiland bei Moby. Auch daß es immer auf mich reagiert, und mich trotz fortwährender Mißerfolge immer und immer wieder auf dieselbe dumme Weise provozieren versucht, war für Moby typisch. Nee, Du, das da ist definitiv Moby.
Das muss ja in Deiner Historie eine wichtige Person gewesen sein.
> Auch daß es immer auf mich reagiert
Du meinst mich? Was wäre daran ungewöhnlich? Solange Du über einem
gewissen Level bleibst kann man selbstverständlich antworten. Mach Dich
doch hier zu nix besonderem...
hüstel
Harald K. schrieb: > Das ist hier ein doch > massiv abweichender Stil, ohne diese hämische Überheblichkeit, die bei > "moby" aus jeder sich bietenden Körperöffnung quoll. Dann schau dir mal seine Beiträge im Haus & Smart Home an.
Um den Gedankenaustausch mal wieder ein wenig zurück in Richtung "PC-Programmierung" (so der Titel dieser Forensektion) zu bringen und auf eine etwas sachlichere Ebene zu stellen :) Norbert schrieb: > Assembler ist doch nur etwas für Warmduscher. > Echte Kerle nehmen eine Tabelle mit Mnemonics und zugehörigen Hex-Werten > in die Hand. ... und klickern das Programm über die Schalter auf der Rechnerfront ein. Wenn es z.B. um den "Bootloader" geht, hat man das bald automatisch drin, so wie Klavierspielen, ohne auf die Noten zu schauen.
Martin H. schrieb: > Um den Gedankenaustausch mal wieder ein wenig zurück in Richtung > "PC-Programmierung" (so der Titel dieser Forensektion) zu bringen Einmal Assembler immer Assembler? Schwachsinn, so wie Eingabe über Schalter. Beiträge über Asm-PC Programmierung kannst Du von mir sehr lange suchen... Aber für 8Bit AVR passt's eben wie die Faust aufs Auge. Da käm mir nix anderes in den Sinn. Deshalb darf es trotzdem jeder halten wie er mag. Wer ohnehin überall C & Konsorten einsetzt und beherrscht darf selbstredend auch die kleinsten Chips damit quälen :)
Gerhard H. schrieb: > Aber für 8Bit AVR passt's eben wie die Faust aufs Auge. > Da käm mir nix anderes in den Sinn. > Deshalb darf es trotzdem jeder halten wie er mag. Wer ohnehin überall C > & Konsorten einsetzt und beherrscht darf selbstredend auch die kleinsten > Chips damit quälen :) Einer der Moderatoren, weiß nicht mehr ob das Chris oder Jörg war, hat dich vor vielen Jahren doch mal ziemlich blöd dastehen lassen als du beweisen wolltest dass dein handoptimierter Asm-Code performanter und ressourcensparender sei als der Output eines moderner C-Compilers. Muss mal den Thread raussuchen. In Anbetracht dieser Historie ist es etwas verwunderlich wie man das Maul soweit aufreissen kann.
:
Bearbeitet durch User
Le X. schrieb: > In Anbetracht dieser Historie ist es etwas verwunderlich wie man das > Maul soweit aufreissen kann. Welche Historie? Permanent Unterstellungen am laufenden Band. Tipp: Führ Dir den Thread hier nochmal zu Gemüte. Dann kommst Du der Vorstellung näher, was mich persönlich und nicht irgendwelche Gestalten der Foren-Vergangenheit an C-Programmierung bzw. deren Umfeld massiv stört. Danke, sehr ungern als Hobby. Soll aber hier jetzt nicht als Stoff für völlig sinnlose Endlos-Diskussionen dienen :)
Ich bleibe übrigens bei meiner Einschätzung. Gerhard mag sehr schräg drauf sein, aber er ist nicht "moby". Der spielt in einer ganz anderen Klasse. (Auf heise kann man ihm übrigens begegnen, da nennt er sich "ttloop").
Harald K. schrieb: > Gerhard mag sehr schräg drauf sein Mit meinen solchen Urteilen halte ich solang es irgendwie geht lieber hinterm Berg. Schließlich soll doch die Sache im Vordergrund stehen. Sobald das Beteiligten aber nicht mehr möglich ist wirds immer persönlich :(
Gerhard H. schrieb: > Schwachsinn, so wie Eingabe über > Schalter. Hast Du schon einmal eine PDP-11 gesehen, die standen im letzten Jahrtausend in vielen Unis und Instituten. Siehe: https://de.wikipedia.org/wiki/PDP-11#/media/Datei:Pdp11-70.jpg
Martin H. schrieb: > Hast Du schon einmal eine PDP-11 gesehen Nein. Die hat auch so gar keine Ähnlichkeit mit den kleinen Platinchen und aktuellen Chips die ich verarbeite- mit vermutlich deutlich mehr Rechenleistung ... Nur einem Z80-Rechner aus meinem Inventar https://de.m.wikipedia.org/wiki/LC80 waren Asm Programme dereinst etwas umständlicher einzugeben :)
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.