unter https://sys.cs.fau.de/lehre/ss22/spic/vorlesung findet man Vorlesungsfolien, Übungen und Projekte zur Vorlesung "Systemnahe Programmierung in C (SPiC)" der FAU Erlangen-Nürnberg zur Programmierung von AVR-Controllern (ATmega328) in C.
Die Seite vom SS22 enthält ein Gesamtskript als pdf. Es gibt auch eine Seite zum SS24. Da gibt es die Folien aber nur in einzelnen Teilen.
Einen Schaltplan zum SPiCboard V3 findet man auf der Seite zum WS17 unter https://www4.cs.fau.de/Lehre/WS17/V_GSPIC/Uebungen/Board/spicboard-v3.pdf
Na die selbstgestrickten z.B. oder FPGA oder alte Grafikkarten oder recht neue Sachen - wobei natürlich so ein Mittelding dann Linux sein kann. Indirekt gesehen geht ja dann wieder einiges.
Hier geht z.B. Debian, da kann man nicht meckern:
https://wikidevi.wi-cat.ru/BeagleY-AI
Hä? Es ging um C-Compiler. Plattformen, für die es ein Linux gibt, für
die existiert naturgemäß eine C-Compiler.
Jaja.. indirekt meint aber auch, dass man z.B. zuwenig Platz haben kann, dann hat man keinen C-Compiler, sondern vielleicht etwas Platzsparenderes.
Allerdings muss man das Linux natürlich anpassen können, so gesehen müsste ja mindestens schon eine C-Runtime vorhanden sein bzw. so ein paar C-Grundfunktionen.
Und dann noch: Was ist eigentlich Cygwin? Ist Cygwin eine eigene "Plattform"? ;)
Jaja.. indirekt meint aber auch, dass man z.B. zuwenig Platz haben kann,
dann hat man keinen C-Compiler, sondern vielleicht etwas
Platzsparenderes.
Sowohl "Plattform" als auch "C-Compiler" ist missverständlich (hier und in den Folien)
In den Folien bezeichnet "Plattform" die µC-Umgebung ("Zielplattform") als auch die Entwicklungsplattform ("Betriebssystem-Plattform", mit nennung von Linux).
"Es gibt für jede Plattform einen C-Compiler" kann interpretiert werden als "also auch auf jeder Zielplattform". Das ist natürlich nicht so.
Für die meisten µC gibt es einen C-Compiler auf Linux, Windows oder einem anderen Betriebssystem. Dass brandneue noch keinen haben oder Exoten (in irgendeiner Peripherie eines FPGAs in einem Hybridchip) auch nicht, geschenkt.
Die Fälle, wo es irgendeine Hochsprache gibt und kein C, dürften noch exotischer sein. Fasst man das ein wenig weiter, sind sie es nicht, z.B. SPS-Steuerungen oder Taschenrechner.
Also C gibt es immer, in der Vergangenheit, in der Zukunft, auf immer. Hallejulia!
Deshalb haben die anderen Sprachen (vgl Rust) aus der Sicht der wahren Glaeubigen immer sowas sektenartiges.
Extrem kleine Kröten wie PIC10 oder alte AtTinys vermiesen einem schon die Laune etwas wie einen C-Compiler dafür zu portieren.
Wobei ich hier ausdrücklich auch die Cross-Compiler meine, also von der Zielplatform des Compilats schreibe. Wenn der eigentliche Compiler auf der Platform laufen soll, wird es natürlich noch viel bitterer.
Was soll diese absolut sinnbefreite Aufzählung nun aussagen?
Assembler ist keine Hochsprache.
Selber sinnfrei. Assembler können ja auch Dialekte haben. Aber sind es nicht Sprachen, die Dialekte haben?
Basic ist auch nicht exotisch, kann auch einen Interpreter haben, kann man auch compilieren.
Das Argument ging nur gegen den Hinweis auf "exotisch" - was da bestimmte Alternativen eigentlich nicht unbedingt sind.
Die C-Scripts vom Bellard sind da schon eher exotischer.
und viele Basic-Dialekte werden durch Interpreter
ausgeführt, die i.d.R. in C geschrieben sind.
Das ist nun kompletter Unfug - kann natürlich sein, war aber früher eher gar nicht so. Und JS und andere sind Schlicht Browsersprachen - und Browser kann man sehr wohl schon als "Plattform" einordnen.
Freilich nicht Hardware- bzw. Systemprorammier-Nahe.
Nun könnte man sich aber auch Pascal für Systemnahe Programmierung vorstellen.
Pascal und Basic wurden früher überall in Europa vermittelt - aber mit Sicherheit nicht, weil diese Programmiersprachen so "exotisch" sind.
Freilich nicht Hardware- bzw. Systemprorammier-Nahe.
Deine Antwort ging am Thema vorbei. Vielleicht hast Du das Papier auch gar nicht gelesen und die Antworten deshalb nicht einordnen können.
Es ging darum, dass für eine µC-Plattform "immer" ein C-Compiler existiert. Dass es für µC, die älter als C sind, nicht unbedingt zutrifft, ist klar und ohne Belang hier. (Wobei man sich fragen kann, ob man da von µC statt von µP spreche kann)
Dass es zudem geschlossene Systeme (nicht "µC-Plattformen") gibt, die einen µC enthalten aber keinen C-Compiler, habe ich auch geschrieben und Beispiele genannt (SPS/Taschenrechner).
Selbst Ausnahmen, wo es echte oder virtuelle µC sind aber ohne C-Compiler, habe ich benannt.
Eine µC-Plattform aus diesem Jahrtausend, mit Cobol oder Python aber ohne C, dürfte selten sein.
Es geht um "Plattformen", für die in einer von C verschiedenen Hochsprache entwickelt werden kann, NICHT ABER in C.
Was zum Teufel ist daran so schwer zu verstehen?
Für STM32 und Pi Pico gibt es natürlich C-Compiler, und für die übrigen der oben zitierten Aufzählung höchstwahrscheinlich auch. Dass es daneben Compiler/Interpreter für andere Sprachen gibt, ist für die Aussage, um die es geht, völlig egal! Davon abgesehen: In welcher Sprache sind Python-Interpreter wohl geschrieben?
Es geht um "Plattformen", für die in einer von C verschiedenen
Hochsprache entwickelt werden kann, NICHT ABER in C.
Hmm....
Und ich dachte es geht um:
Alexander S. schrieb im Beitrag #7962073:
unter https://sys.cs.fau.de/lehre/ss22/spic/vorlesung findet man
Vorlesungsfolien, Übungen und Projekte zur Vorlesung "Systemnahe
Programmierung in C (SPiC)" der FAU Erlangen-Nürnberg zur Programmierung
von AVR-Controllern (ATmega328) in C.
Wobei mich eher der Einsatz von modernem C++ interessiere würde.
De facto geht es in diesem Thread seit der ersten Antwort auf den
Eröffnungsbeitrag um die These, es gebe für jede Plattform einen
C-Compiler.
Das ist erstens Unsinn, und zweitens Thread hijacking, zumindest das
Python gehackel.
(1) Dann zitiere mir doch einen Beitrag dieses Threads, der sich auf etwas anderes bezieht. (2) Mag sein, aber (a) habe ich damit nicht angefangen, (b) ist mir nicht bekannt, dass "Thread hijacking" in diesem Forum zumindest generell unerwünscht wäre, und (c) steht es dir frei, auf das Ursprungsthema einzugehen, anstatt ein neues anzuschneiden, das mit dem des TO rein gar nichts mehr zu tun hat.
Du ignorierst Arduino. Das hat sich durch gesetzt.
Ja, unter einer gewissen Teilmenge von Bastlern/Hobbyisten/Makern... Für eine generelle Aussage über C vs. C++ bei allen Anwendern einschließlich der Industrie kaum relevant.
Das ist eine der dümmsten Ansagen die mir je unter gekommen ist.
In entnehme deiner Ansage, dass du keine deiner Gründe benennen kannst!
Entnimm meiner "Ansage", was auch immer du willst; auf diesem Niveau werde ich jedenfalls nicht weiter diskutieren. Wenn du zu faul oder anderweitig nicht in der Lage bist, eine schnelle Google-Suche zu bemühen, ist das nicht mein Problem.
In welcher Sprache sind Python-Interpreter wohl geschrieben?
CPython (C), Jython (in Java), IronPython (in C#), PyPy (Python)
ich schrieb:
Was ist denn ein Python-Interpreter?
Lustigerweise wurde die Frage negativ bewertet. Die wenigsten könnten sie aber korrekt beantworten, sie lautet nämlich:
"Python besteht aus einem Compiler und einem Interpreter. Der Compiler wandelt den Codetext in Bytecode um und dieser Bytecode wird dann von einer virtuellen Maschine ausgeführt. Diese virtuelle Maschine ist der Python-Interpreter. Damit besteht Python sowohl einem Compiler als auch einem Interpreter. Es kombiniert beide Konzepte"
Python besteht aus einem Compiler und einem Interpreter. Der Compiler
wandelt den Codetext in Bytecode um und dieser Bytecode wird dann von
einer virtuellen Maschine ausgeführt.
1
$ python
2
Python 3.13.7 (main, Aug 15 2025, 12:34:02) [GCC 15.2.1 20250813] on linux
3
Type "help", "copyright", "credits" or "license" for more information.
Unter Erwachsenen ist es üblich, die eigenen Behauptungen selbst zu
belegen,
Das kann er sicherlich nicht.
Habe mal einige seiner Beiträge untersucht.
Er scheint eher ASM zu nutzen.
Und ASM Programmierer scheinen manchmal irgendwas gegen C++ zu haben.
Z.B. Vorurteile oder einfach nur aus Prinzip.
Ein Realitätsbezug ist da nicht immer gegeben.
Ich habe übrigens nichts gegen Assembler und ihre Programmierer!
Allerdings einiges gegen komische Behauptungen.
Python besteht aus einem Compiler und einem Interpreter. Der Compiler
wandelt den Codetext in Bytecode um und dieser Bytecode wird dann von
einer virtuellen Maschine ausgeführt.
1
> $ python
2
> Python 3.13.7 (main, Aug 15 2025, 12:34:02) [GCC 15.2.1 20250813] on
3
> linux
4
> Type "help", "copyright", "credits" or "license" for more information.
5
>>>> print("Hier auch?")
6
> Hier auch?
7
>>>>
8
>
1
Python 3.14.0 (main, Nov 18 2025, 05:53:34) [GCC 14.2.0] on linux
2
Type "help", "copyright", "credits" or "license" for more information.
Unter Erwachsenen ist es üblich, die eigenen Behauptungen selbst zu
belegen,
Das kann er sicherlich nicht.
Das vermute ich auch -- und wenn, kommen vermutlich nur die altbekannten Vorurteile wie Codegröße, Performance und Ähnliches.
Habe mal einige seiner Beiträge untersucht.
Er scheint eher ASM zu nutzen.
Und ASM Programmierer scheinen manchmal irgendwas gegen C++ zu haben.
Ach, manche Menschen haben etwas gegen alles, das sie nicht kennen, und auch nicht lernen wollen, weil sie ja was dagegen haben. Ich glaube jedoch nicht, daß das an einer bestimmten Sprache liegt, solche Leute findet man überall.
Unter Erwachsenen ist es üblich, die eigenen Behauptungen selbst zu
belegen, spätestens auf ausdrückliche Nachfrage.
Noch einer, der alles auf dem Silbertablett serviert haben will...
Eigentlich sind Vorteile von C doch schon offensichtlich, wenn man die Motivation bedenkt, aus der heraus Stroustrup C++ entwickelt hat. Es ging im Kern darum, sehr umfangreiche Programme durch Anhebung des Abstraktionsniveaus für den Programmierer übersichtlicher zu machen.
Dass die damit einhergehende erhöhte Komplexität der Sprache bzw. deren hinzugekommener Features sich nachteilig auswirken kann, wenn es eben nicht um sehr große, sondern eher kleinere Programme geht -- die bei Mikrocontrollern den Löwenanteil bilden, verglichen mit leistungsfähigeren "Plattformen" --, ist für meine Begriffe mindestens naheliegend. Binsenweisheit: Wo Licht ist, ist auch Schatten. Hier: Höheres Abstraktionsniveau => weniger Hardware-Nähe. Komplexere Compiler, die bekanntlich weniger gut optimieren können als fähige Programmierer, und auch mehr Potential für Bugs haben, usw.
Siehe z.B. Raspberry Pi Pico C/C++ SDK. Warum wohl sind die Libraries in C geschrieben und nicht C++? Man kann das SDK natürlich auch mit C++ verwenden, muss allerdings Exceptions und RTTI explizit aktivieren, falls man sie verwenden will, per default werden diese C++-Features nicht unterstützt.
Für alle, die ebenfalls zu faul sein sollten, den Text zu überfliegen, hier ein paar wesentliche Aussagen davon:
"Die Sprachsyntax von C++ verschleiert mehr als die von C, womit man sich in einem Programm möglicherweise einen hohen, in der Programmierung von Mikrocontrollern unerwünschten Overhead ohne konkreten Nutzen einhandelt."
"Die tatsächlichen Implementierungen von C++ bemühen sich weniger als die von C, ausführbare Programme (Executables) in der sparsamsten möglichen Form zu erzeugen."
"Mit der Einführung von Exceptions musste in C++ aber auch die Leitlinie "You only pay for what you use" verletzt werden. Das heißt es entsteht stets etwas Overhead, wenn der C++-Compiler Exceptions unterstützt, auch für Programme, die Execptions überhaupt nicht benutzen."
Natürlich können bei (sehr) umfangreichen Programmen und insbesondere bei High-End-MCUs -- in Mikrocontroller-Verhältnissen gesehen -- auch die Vorteile von C++ gegenüber C überwiegen. Dass das der Fall sein kann, habe ich auch nie bestritten. Meine ursprüngliche "Behauptung" war einzig und allein die Existenz objektiver Gründe dafür, im Bereich der Mikrocontroller-Programmierung mit ihren doch verhältnismäßig wesentlich kleineren Programmen in C anstatt C++ zu entwickeln.
Meine ursprüngliche "Behauptung" war
einzig und allein die Existenz objektiver Gründe dafür, im Bereich der
Mikrocontroller-Programmierung mit ihren doch verhältnismäßig wesentlich
kleineren Programmen in C anstatt C++ zu entwickeln.
Und, warum bist du dann nicht in der Lage einen einzigen dieser objektiven Gründe klar zu benennen?
Mir scheint, dass deine einzige Referenz, ein 20 Jahre alter Artikel zu sein scheint.
Nach persönlicher Erfahrung/Wissen hört sich das alles nicht an.
Nach persönlicher Erfahrung/Wissen hört sich das alles nicht an.
Der selbsternannte Arduino Fanboy ist dagegen natürlich die erleuchtete Weisheit in Person.
Kopiere du deine LED-Blinkprogramme doch weiter aus irgendwelchen Maker-Codeschnipseln und vorgefertigten, maximal Hardware-verschleiernden Libraries zusammen. Für mich ist hier EOT.
Unter Erwachsenen ist es üblich, die eigenen Behauptungen selbst zu
belegen, spätestens auf ausdrückliche Nachfrage.
Noch einer, der alles auf dem Silbertablett serviert haben will...
Im Grunde wollte ich nur wissen, ob es dasselbe Geschwätz ist, das wir hier schon von etlichen "Entwicklern" gelesen haben. Und siehe da: wie erwartet, ist es wieder einmal haargenau das.
Tausendmal behauptet, tausendmal widerlegt, und trotzdem poppen immer wieder neue Überforderte auf und behaupten immer wieder denselben dummen Unsinn.
Obwohl sie es natürlich längst besser wissen könnten. Wenn sie wollten. Wollen sie aber nicht. Das wär' zu schlecht fürs eigene Selbst- und Weltbild.
Darum hab' ich so gar keinen Bock mehr auf solche Diskussionen, und noch viel weniger auf solche Leute. BTDT. Immerhin weiß ich jetzt, was ich von Deinen "Argumenten" halten darf -- und Du weißt es auch. :-D
Das wär' zu schlecht fürs eigene Selbst- und
Weltbild.
Glücklicherweise beschränkt sich mein Weltbild, anders als bei einigen anderen hier, nicht auf die Bevorzugung der einen oder anderen Programmiersprache für einen bestimmten Zweck.
Glücklicherweise beschränkt sich mein Weltbild, anders als bei einigen
anderen hier, nicht auf die Bevorzugung der einen oder anderen
Programmiersprache für einen bestimmten Zweck.
Bevorzugung?
Du meinst Ablehnung!
Anfangs sprachest du von Gründen, die gegen C++ auf µC sprechen.
Leider bist/warst du bisher nicht in der Lage einen einzigen dieser Gründe zu benennen.
Ja, du hast eine paar Punkte aus einem 20 Jahre alten Artikel abgeschrieben. Und ja, der Artikel ist an sich gar nicht so schlecht. Bemerkenswert ist dabei, dass in dem Artikel nichts davon steht, dass C++ für µC ungeeignet ist. Er liefert also keine Munition gegen C++.
Eigentlich sind Vorteile von C doch schon offensichtlich, wenn man die
Motivation bedenkt, aus der heraus Stroustrup C++ entwickelt hat. Es
ging im Kern darum, sehr umfangreiche Programme durch Anhebung des
Abstraktionsniveaus für den Programmierer übersichtlicher zu machen.
Wo sind da die offensichtlichen Vorteile von C?
Mein erster Gedanke war, als ich das von dir gelesen habe:
Wenn ein höheres Abstraktionsniveau große Projekte übersichtlicher macht, dann kann es das auch bei kleinen Projekten.
Ich stufe Übersichtlichkeit als einen positiven Effekt ein.
Übersichtlichkeit hilft bei der Fehlersuche.
Erleichtert die Wiederverwendung und Wartung.
Natürlich muss man die Sprache dazu verstehen, gelernt haben, zumindest zum grundlegenden Teil,.
Hat man sie verstanden, dann ist die mögliche Abstraktion ein Feature.
Hat man sie nicht verstanden, ist es eine Qual. Bei dir heißt es dann Verschleierung.
"Die Sprachsyntax von C++ verschleiert mehr als die von C, womit man
sich in einem Programm möglicherweise einen hohen, in der Programmierung
von Mikrocontrollern unerwünschten Overhead ohne konkreten Nutzen
einhandelt."
Beherrschbar, wenn man weiß, was man tut.
Unbedarfte können sich verrennen.
"Die tatsächlichen Implementierungen von C++ bemühen sich weniger als
die von C, ausführbare Programme (Executables) in der sparsamsten
möglichen Form zu erzeugen."
In den letzten 20 Jahren hat sich da viel getan.
Es sind neue Sprachmittel hinzu gekommen und die Optimierung ist besser/umfangreicher geworden.
"Mit der Einführung von Exceptions musste in C++ aber auch die
Leitlinie "You only pay for what you use" verletzt werden. Das heißt es
entsteht stets etwas Overhead, wenn der C++-Compiler Exceptions
unterstützt, auch für Programme, die Execptions überhaupt nicht
benutzen."
Exceptions sind eine feine Sache!
Insbesondere bei großen Anwendungen, auf PCs usw., denn da sind die Umgebungsbedingungen schlecht vorhersagbar.
Mit µC hat man eher stabile/unveränderliche Umgebungen, kein OS.
Je stabiler, desto weniger fallen die fehlenden Exceptions ins Gewicht.
Wenn man nett ist, kann man das mögliche abschalten der Exceptions als ein Feature betrachten.
Deine Liste von "Gründen" belegt nicht, dass C++ für µC ungeeignet ist. Aber sie belegt deine Einstellung zu C++. Und Einstellung/Meinung ist nicht objektiv, sondern subjektiv.
Es ist völlig ok, wenn du mit C++ nicht warm wirst!
Aber das kann/sollte für andere kein Grund sein, einen Bogen darum zu machen.
Auch belegt dein Unwohlsein damit, nichts.
Natürlich könnte ich hier eine kleine Liste machen, was C++ attraktiv macht.
Auch auf µC.
Wo C++ besser ist, als C.
Glücklicherweise beschränkt sich mein Weltbild, anders als bei einigen
anderen hier, nicht auf die Bevorzugung der einen oder anderen
Programmiersprache für einen bestimmten Zweck.
Es ist offenbar auch nicht die Bevorzugung, sondern die Ablehnung.
Möglicherweise ist gerade in China ein Sack Reis umgefallen.
Mein erster Gedanke war, als ich das von dir gelesen habe:
Wenn ein höheres Abstraktionsniveau große Projekte übersichtlicher
macht, dann kann es das auch bei kleinen Projekten.
Offensichtlich sollte hier sein, dass ein höheres Abstraktionsniveau auch hinderlich sein kann. Nämlich genau dann, wenn es um relativ einfach gestrickte Plattformen mit geringen Ressourcen geht. Abstraktionsniveau und Hardwarenähe/Effizienz sind nämlich konkurrierende Aspekte.
Aber mit einem "Arduino-Fan" über dieses Thema versuchen zu diskutieren, kann natürlich nur scheitern.
Hier behauptest du, dass es Gründe gegen C++ gibt.
Keine Rede von Arduino.
Du hast ganz offensichtlich große Probleme, die Begrifflichkeit "Ablehnung" von der Feststellung, es gebe in gewissen abgegrenzten Bereichen (hier: AVR und einige andere kleinere MCU-Architekturen) Gründe, einem bestimmten Werkzeug (hier: C++) Alternativen vorzuziehen, inhaltlich zu unterscheiden.
Der Herr muß sich offenbar erstmal mit sich
selbst einigen, ob er Arduino, C++, oder beides nicht leiden kann. ;-)
Ihm kultiviert seine Ablehnung.
Hat dabei leider ein paar Fakten übersehen.
Z.B. dass der Arduino AVR Core zu einem großen Teil in C geschrieben ist, digitalWrite() das Millis Gedönse usw.
Sogar ein Teil in ASM.
Die Arduino IDE unterstützt C, C++ und ASM gleichermaßen.
Ich habe kein Problem damit, wenn einer C++ nicht mag, oder Arduino.
Möchte aber betonen, dass das nicht objektiv ist, sondern eher auf persönlichen Vorlieben/Ablehnungen/Vorurteilen beruht.
