Forum: Mikrocontroller und Digitale Elektronik Python oder besser bei C bleiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hercules H. (hercules)


Lesenswert?

Moin,

ich würde mal gerne die Erfahrung einiger Nutzer hier lesen, bezüglich 
der Programmierung von Mikrocontrollern. Also ich habe eine kurze Zeit 
lang kleine Erfahrungen gemacht was die Programmierung von 
Mikrocontroller angeht. Meisten waren es nur Kleinigkeiten, z.b LC 
Display zum laufen bringen, oder eine einfache Steuerung einiger LED's. 
Dies habe ich bisher in C gemacht, allerdings auch manchmal mit Mühe, da 
es mir nicht ganz so einfach viel dies passenden Bibliotheken zu finden. 
Immer mehr höre ich von Python und wie gut es auch ist in Bereich 
Eingebettete Systeme. Bibliotheken seien reichlich und umfangreich 
vorhanden. Die Community sei auch sehr groß. Erfahrung habe ich bislang 
keine gemacht. Daher würde ich gerne einiges von euch hören wollen. 
Würdet ihr es empfehlen, klappt das gut? Ihr müsst bedenken das ich kein 
Großes Ding aufziehen werde was meine kleine Projekte angeht. Es wird 
dabei bleiben kleine Elektronik zu steuern, dinge auf einem Display 
anzeigen zu lassen, und wenn es hoch kommt, dann eventuell noch IoT 
Projekte realisieren die vermutlich über meine Handy Steuerung läuft.

Freue mich auf eure Antworten!

von Cyblord -. (cyblord)


Lesenswert?

Hercules H. schrieb:
> Immer mehr höre ich von Python und wie gut es auch ist in Bereich
> Eingebettete Systeme.

Da fragt man sich wo man sowas hört. Vielleicht auf dem Pi? Ansonsten 
kommt Python dort nicht vor. Zumindest nicht im prof. Umfeld.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hast du denn eine Plattform, auf der ein (micro)Python überhaupt läuft?

Wenn nicht, musst du dir keine weiteren Gedanken machen. ;-)

Wenn ja, dann bist du mit einer Scriptsprache sicherlich schneller am 
Ziel was den Entwicklungsaufwand betrifft, und musst dann nur sehen, ob 
die Ausführungsgeschwindigkeit einer interpretierten Sprache für deinen 
Anwendungsfall ausreichend ist.

von Darth G. (darth_g)


Lesenswert?

Das kommt immer auf den Fall an, für deine Zwecke würde ich mir mal ein 
Raspi (ab 3B) holen und schauen was da alles geht mit Python.
C ist super weil kompakt, macht aber nur Sinn wenn wenig Speicher zur 
Verfügung steht.Galsch ist es nicht, vorallem wenn du später wirklich 
kompakt arbeiten wolltest.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Cyblord -. schrieb:
> Zumindest nicht im prof. Umfeld.

Python (+ numpy / scipy) haben wir auf NanoPi auch schon ganz 
professionell (also "für Brötchen") benutzt.

microPython auf den ESPs soll auch nicht so schlecht sein.

von Cyblord -. (cyblord)


Lesenswert?

Jörg W. schrieb:
> Cyblord -. schrieb:
>> Zumindest nicht im prof. Umfeld.
>
> Python (+ numpy / scipy) haben wir auf NanoPi auch schon ganz
> professionell (also "für Brötchen") benutzt.

Ja sicher. Pi und Python "für Brötchen". Irgendein Krauter gibts halt 
immer. Das macht niemand der was auf sich und seine Kunden hält.

von Martin S. (strubi)


Lesenswert?

Es gibt sogar Prozessoren, die mit Python designt sind und Python 'just 
in time' verstehen. Das ist aber eher fortgeschrittene Technik. Mit 
Python hat man sehr schnell robuste Prototypen am Laufen, die man dann 
nach Wahl mit bare-metal C-Modulen oder anderen Compiler-Ansaetzen 
(Cython, LLVM-Erweiterungen) optimiert kriegt. Braucht halt etwas mehr 
Speicher als 'bare metal', aber microPython geht schon mit 64 kB (32kB 
RAM, 32kB ROM). Wuerde aber erst mal klassisch unter Linux anfangen. 
Jupyter Notebooks sind noch was Schoenes, um Ergebnisse 
dokumentierbar/demonstrierbar zu halten.

von Jack V. (jackv)


Lesenswert?

Cyblord -. schrieb:
> Das macht niemand der was auf sich und seine Kunden hält.

… und das ist so, weil? Oder anders gefragt: wenn ich zwei gleiche 
Microcontroller habe, die nach außen hin exakt das Gleiche machen, dann 
ist der, der mit C-Kompilat beschickt wurde, dem, der mit MicroPython 
läuft, aus welchem Grund genau überlegen? Weil der Auftraggeber mehr 
bezahlt hat, weil die Entwicklung in C nunmal teurer ist, oder warum?

On-Topic: um mal in μPython reinzuschauen, könnte man sich für vier Eur 
einen Pi Pico holen. Wenn’s dann doch nicht gefällt, kann man den auch 
gerne in C/C++ bespaßen, und wenn’s einem auch dann nicht gefällt, hält 
sich der finanzielle Verlust in Grenzen.

von Siggy (Gast)


Lesenswert?

Cyblord -. schrieb:
> Jörg W. schrieb:
>> Cyblord -. schrieb:
>>> Zumindest nicht im prof. Umfeld.
>>
>> Python (+ numpy / scipy) haben wir auf NanoPi auch schon ganz
>> professionell (also "für Brötchen") benutzt.
>
> Ja sicher. Pi und Python "für Brötchen". Irgendein Krauter gibts halt
> immer. Das macht niemand der was auf sich und seine Kunden hält.

Es ist davon auszugehen, dass du keinen blassen Schimmer hast, wo und 
von wem Python eingesetzt wird. Du kannst eine eigene Meinung haben, 
aber keine eigenen Fakten. Also halt einfach mal die Klappe und mache 
hier nicht den Trump für Arme.

von Cyblord -. (cyblord)


Lesenswert?

Siggy schrieb:
> Es ist davon auszugehen, dass du keinen blassen Schimmer hast, wo und
> von wem Python eingesetzt wird.

Das stimmt. Aber es reicht mir zu wissen wo Python NICHT eingesetzt 
wird: In prof. und für die Industrie tauglichen Embedded Produkten.

von Marc (gierig) Benutzerseite


Lesenswert?

Jack V. schrieb:
> um mal in μPython reinzuschauen, könnte man sich für vier Eur
> einen Pi Pico holen.

Fürs die ersten schritte  bedarf es keiner Hardware...

https://www.micropython.org/unicorn/

Netter Emulator direkt vom Erzeuger...

von Marc (gierig) Benutzerseite


Lesenswert?

Cyblord -. schrieb:
> Das stimmt. Aber es reicht mir zu wissen wo Python NICHT eingesetzt
> wird: In prof. und für die Industrie tauglichen Embedded Produkten.

Cyber hat gesprochen also ist es wahr!
Versteht es doch endlich. Alle Industriellen Stellenanzeigen
für Python Entwickler sind entweder Ablenkung, fake oder nicht 
Professionell genug. Raking von Programmiersprachen werden
von der klammerlosen python mafia künstlich beeinflusst.
Alt gediente Entwickler wechseln Naserümpfend die Straßenseite
wenn sie so einen Klammerverweigerer auch nur sehen.

Die ewiggestrigen werden am ende den totalen sieg einfahren
nieder mit jeglichen Hochsprachen oder abstrakten Hardwarestrukturen.
Neue Erfindungen wie Programmierbare Hardware oder Prinzipien
der Eingabe-Verarbeitung-Ausgabe werden sich NICHT durchsetzen. Nur 
Hardverdrahtet und handverlötete Dampfrohre taugen für die Industrie.

ps.
Kann spuren von Ironie enthalten.

von Rainer V. (a_zip)


Lesenswert?

Marc D. schrieb:
> Kann spuren von Ironie enthalten.

Wird nur noch getoppt von dem Hinweis auf dieser Nusscreme, "kann Spuren 
von Nüssen enthalten" und sollte einen eigentlich richtig nachdenklich 
machen...
Gruß Rainer

von Martin S. (strubi)


Lesenswert?

Cyblord -. schrieb:
> Das stimmt. Aber es reicht mir zu wissen wo Python NICHT eingesetzt
> wird: In prof. und für die Industrie tauglichen Embedded Produkten.

Nonsense. Ich setze Python schon seit >20 Jahren in professionellen und 
industriebewaehrten Loesungen ein. U.a. werden damit auch Halbleiter 
getestet.

Konkrete Gegenargumente nehmen wir trotzdem gerne entgegen. Es gibt 
immer mal wieder Go(ogle)-Hansels, die Python nicht verstanden haben, 
und das nicht-statische Typing anmeckern. Gibt's aber alles.

von Cyblord -. (cyblord)


Lesenswert?

Martin S. schrieb:
> Nonsense. Ich setze Python schon seit >20 Jahren in professionellen und
> industriebewaehrten Loesungen ein. U.a. werden damit auch Halbleiter
> getestet.

Sind dann nur keine Embedded Anwendungen, sondern Tester.

von Achim M. (minifloat)


Lesenswert?

Cyblord -. schrieb:
> Martin S. schrieb:
>
>> Nonsense. Ich setze Python schon seit >20 Jahren in professionellen und
>> industriebewaehrten Loesungen ein. U.a. werden damit auch Halbleiter
>> getestet.
>
> Sind dann nur keine Embedded Anwendungen, sondern Tester.

und Codegenerierung?
und Build-Automatisierung?
und
mfg mf

Beitrag #6682178 wurde von einem Moderator gelöscht.
von Sheeva P. (sheevaplug)


Lesenswert?

Hercules H. schrieb:
> ich würde mal gerne die Erfahrung einiger Nutzer hier lesen, bezüglich
> der Programmierung von Mikrocontrollern. Also ich habe eine kurze Zeit
> lang kleine Erfahrungen gemacht was die Programmierung von
> Mikrocontroller angeht. Meisten waren es nur Kleinigkeiten, z.b LC
> Display zum laufen bringen, oder eine einfache Steuerung einiger LED's.
> Dies habe ich bisher in C gemacht, allerdings auch manchmal mit Mühe, da
> es mir nicht ganz so einfach viel dies passenden Bibliotheken zu finden.
> Immer mehr höre ich von Python und wie gut es auch ist in Bereich
> Eingebettete Systeme. Bibliotheken seien reichlich und umfangreich
> vorhanden. Die Community sei auch sehr groß. Erfahrung habe ich bislang
> keine gemacht. Daher würde ich gerne einiges von euch hören wollen.
> Würdet ihr es empfehlen, klappt das gut?

Antwort von Radio Eriwan: kommt darauf an. Vorweg: ich habe zwar viele 
Erfahrungen mit und in Python, aber keinerlei eigene mit Micropython. 
Aber das, was ich bisher davon gesehen habe, sah ausgesprochen gut aus.

Letzten Endes läuft Dein Vergleich aber auf die grundsätzlichen 
Unterschiede zwischen einer interpretierten und einer kompilierten 
Sprache hinaus, und die darauf folgende Abwägung zwischen den beiden 
Welten. Im Kern geht es um eine Abwägung zwischen Entwicklungs- und 
Laufzeit.

Kompilierte Sprachen benötigen üblicherweise eine längere 
Entwicklungszeit als interpretierte Sprachen, benötigen dafür aber zur 
Laufzeit weniger Ressourcen. Mit C und / oder C++ kannst Du auch auf 
sehr kleinen Mikrocontrollern arbeiten, Micropython dagegen benötigt 
deutlich leistungsfähigere Hardware.

Für C spricht, daß es nahezu überall sehr performant läuft, auch auf 
winzigen Geräten. Gegen C spricht, daß es -- jedenfalls bei Anfängern -- 
nicht immer ganz einfach zu durchschauen ist, und eine lauffähige, 
stabile Implementierung viel mehr Arbeitszeit des Entwicklers benötigt.

Für Python spricht, daß es sehr leicht zu erlernen ist, eine 
herausragende Infrastruktur in Form von mitgelieferten oder anderweitig 
erhältlichen Modulen gibt, daß es sehr stabil, für viele Anwendungsfälle 
ausreichend performant ist und daß die Entwicklung und Änderungen am 
Code wesentlich schneller gemacht sind als das in C oder C++ der Fall 
ist. Gegen Python spricht, daß es eine gewisse Mindestanforderung an die 
Hardware stellt, nicht so schnell ist wie C oder C++, und daß es im 
laufenden Betrieb wahrscheinlich auch mehr Strom verbraucht.

Wie gesagt: am Ende ist es eine Abwägung zwischen Ressourcenbedarf, 
Entwicklungs- und Laufzeit. Wenn Du lediglich hobbymäßig kleine Projekte 
entwickeln willst, die keine besonderen Anforderungen an Kosten, 
Echtzeit, Energieverbrauch und ähnliche Aspekte stellen, dann ist 
Micropython zweifellos eine gute Wahl, und Du kommst damit deutlich 
schneller ans Ziel als mit C oder C++.

Tatsächlich würde ich Dir aber empfehlen, die Sache nicht so 
eindimensional zu betrachten und beide Sprachen zu lernen: Python und 
nein, nicht C, sondern C++. Mit so ziemlich jeder neuen Sprache, die ich 
in meinem Leben gelernt habe, habe ich auch für die anderen Sprachen ein 
besseres Verständnis und ein paar schicke Tricks und neue Denk- und 
Herangehensweisen gelernt.

Zuletzt möchte ich noch auf eine Erfahrung hinweisen, die ich 
mittlerweile sehr oft gemacht habe. Ich kenne viele, zum Teil auch 
professionelle Entwickler, die eine Sprache hervorragend beherrschen, 
sich aber mit Händen und Füßen dagegen wehren, eine weitere Sprache auch 
nur anzuschauen. Ich vermute, daß das daran liegt, daß das Erlernen 
einer ersten Programmiersprache besonders schwierig ist, denn dabei muß 
man ja nicht nur die Sprache, sondern vor Allem das Programmieren selbst 
erlernen, und der zweite Teil, das Programmieren, ist dabei der weitaus 
schwierigere und langwierigere Teil. Aber wenn man das einmal kann, also 
wie ein Programmierer bzw. Softwareentwickler denken, seinen Code sauber 
strukturieren, ein Programm entwerfen und umsetzen kann: Dann ist eine 
neue Sprache deutlich einfacher zu erlernen, weil man viele 
Grundkonstrukte wie Variablen, Funktionen, Schleifen, Bedingte 
Anweisungen und so weiter bereits kennt.

Schwieriger ist es dann nur noch, ein neues Programmierparadigma (und 
damit eine andere Denkweise) zu erlernen, also etwa von prozeduraler auf 
objektorientierte Programmierung zu wechseln. Das ist nach meinem 
Eindruck einer der wesentlichen Gründe dafür, warum sich viele zum Teil 
auch sehr erfahrene C-Entwickler hier im Forum so heftig gegen C++ 
sträuben -- auch dann, wenn diese recht überschaubare Wissensinvestition 
ihr Leben deutlich einfacher und schöner machen könnte. ;-)

Beitrag #6682219 wurde von einem Moderator gelöscht.
Beitrag #6682222 wurde von einem Moderator gelöscht.
Beitrag #6682228 wurde vom Autor gelöscht.
Beitrag #6682232 wurde von einem Moderator gelöscht.
Beitrag #6682239 wurde von einem Moderator gelöscht.
Beitrag #6682241 wurde von einem Moderator gelöscht.
Beitrag #6682242 wurde vom Autor gelöscht.
Beitrag #6682255 wurde von einem Moderator gelöscht.
von Sheeva P. (sheevaplug)


Lesenswert?

Danke! ;-)

von xyz (Gast)


Lesenswert?

Ein System das 5 W Energie verbraucht um Python laufen zu lassen,
nur weil der Entwickler zu doof ist, C und Assembler zu benutzen.
Das kaeme wohl mit einem Hundertsel von 5 W aus.
Dazu noch megabyteweise zwangsangeheiratete Pythonbibliotheken
von denen vllt 1 % in der Anwendung genutzt werden.

Das ist doch (offensichtlich) Dreck!

Und allenfalls fuer einen fix zusammengehackten Prototypen
(aka Beratungsmuster) zu vertreten.
Aber doch nicht fuer ein Serienprodukt.

von Nop (Gast)


Lesenswert?

Sheeva P. schrieb:

> Gegen C spricht, daß es -- jedenfalls bei Anfängern --
> nicht immer ganz einfach zu durchschauen ist, und eine lauffähige,
> stabile Implementierung viel mehr Arbeitszeit des Entwicklers benötigt.

Und Deine Schlußfolgerung ist dann, das nochmal um den Faktor 10 mit C++ 
zu verschlimmern.

> auch dann, wenn diese recht überschaubare Wissensinvestition
> ihr Leben deutlich einfacher und schöner machen könnte. ;-)

C++ nimmt man auf µCs nur dann, wenn einem die zu entwickelnde Software 
zu trivial ist, man sich langweilt, und man es stattdessen lieber 
kompliziert haben möchte.

Will man es anspruchsvoll und kompliziert, möchte aber auch zumindest 
irgendeinen Nutzen davon haben, dann schaut man sich Rust an.

von Hercules H. (hercules)


Lesenswert?

Das ganze ratet leider etwas aus dem Ruder. Daher möchte ich hier gerne 
das Ende setzen. Ich werde in Zukunft weiterhin mit C programmieren, und 
eventuell Python ausprobieren, wenn es offensichtlich die effizientere 
Methode ist.

Dennoch möchte ich mich bei allen bedanke! Eure, teils 
unterschiedlichen, Antworten haben mir geholfen meinen zukünftigen 
Favoriten heraus zu finden. Danke!

von Nop (Gast)


Lesenswert?

Was man übrigens tatsächlich sieht, ist die Kombination von Python und 
C. Also nicht auf Controllern, wohl aber auf PCs. Python für die leichte 
Entwicklung, und C für die rechenintensiven Teile. Numpy ist da ein 
Beispiel.

Beitrag #6682445 wurde von einem Moderator gelöscht.
Beitrag #6682453 wurde vom Autor gelöscht.
von kannAllesBesser?! (Gast)


Lesenswert?

... ich programmiere beides auf espXXX, also micropython (mpy) und C.
Wer sagt python ist kinderleicht, der hat keine Ahnung von python.
Ich sage, C ist um längen einfacher zu lernen und anzuwenden. In python 
sind nur die ersten Schritte simpel. Danach wird es richtig kompliziert 
und es gibt tonnenweise Libraries.
mpy macht viel Spass, aber erst nach einer langen, langen Lernkurve. 
Anfänglich schreibt man eigentlich C Programe in python Syntax. Nur das 
hat mit python wenig zu tun!

Die gestellte Frage macht für mich keinen Sinn, C UND python sind heute 
Pflicht und beide sind notwendig und unversichtbar für mich.

von chris_ (Gast)


Lesenswert?

Also ... ums mal praktisch zu machen ...

Ich habe Micropython auf 3 System getestet: ESP32, ESP8266 und PiPico

Beitrag "PiPico Micropython"

Mein Resume:
Man kann Micropython für einfache Testaufgaben nutzen. Da es aber viele 
Eigenarten hat (nicht den vollen Python3 Sprachumfang) muss man immer 
wieder heraus finden, wie das dann mit Micropython geht. Besonders mit 
Bit- und Byte Operationen habe zumindest ich mit Python ein Problem.
Außerdem ist Python auf den Controllern ca. um den Faktor 100 langsamer 
als C.
Im Moment nutze ich den PiPico mit Micropython um über SPI mein FPGA zu 
steuern. Ich bin aber am überlegen, ob ich doch wieder auf C umsteigen 
soll, weil ich dort schon z.B. den Hexeditor für's Terminal habe.

von Nur_ein_Typ (Gast)


Lesenswert?

xyz schrieb:
> Ein System das 5 W Energie verbraucht um Python laufen zu lassen,
> nur weil der Entwickler zu doof ist, C und Assembler zu benutzen.

Das Pyboard braucht bei maximalem Takt und voller Auslastung 0,2 Watt.

> Das ist doch (offensichtlich) Dreck!

Und Du bist offensichtlich ein Troll. Das wäre ja nicht so schlimm, wenn 
Du wenigstens einen leisen Hauch einer Ahnung hättest, aber leider...

von Nur_ein_Typ (Gast)


Lesenswert?

Nop schrieb:
> Und Deine Schlußfolgerung ist dann, das nochmal um den Faktor 10 mit C++
> zu verschlimmern.

Wer C++ für komplizierter als C hält, der hat es nicht verstanden.

von Rainer V. (a_zip)


Lesenswert?

Sheeva P. schrieb:
> Zuletzt möchte ich noch auf eine Erfahrung hinweisen, die ich
> mittlerweile sehr oft gemacht habe. Ich kenne viele, zum Teil auch
> professionelle Entwickler, die eine Sprache hervorragend beherrschen,
> sich aber mit Händen und Füßen dagegen wehren, eine weitere Sprache auch
> nur anzuschauen.

Diese Erfahrung ist richtig und nicht nur im Hinblick auf Programmierer. 
Es spiegelt das schlichte "watt der Bauer nich kennt, datt frist er 
nich" wieder, wobei die schlaue Argumentation, dass er das ja auch mal 
lernen mußte, keinen wahrnehmbaren Erfolg zeigt. Die Experten sind daher 
weiterhin ratlos, ob es sich hierbei um ein erlerntes oder quasi 
angeborenes Verhalten handelt.
Gruß Rainer

von Stefan F. (stefanus)


Lesenswert?

chris_ schrieb:
> Außerdem ist Python auf den Controllern ca. um den Faktor 100 langsamer
> als C.

Wie kann das sein, ich dachte es handelt sich um compilierten Code?

Beitrag #6683194 wurde von einem Moderator gelöscht.
Beitrag #6683211 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Wie kann das sein, ich dachte es handelt sich um compilierten Code?

Laut Wikipedia ist Python wäre ein "üblicherweise interpretierte" 
Programmiersprache.

Und der Interpreter ist nicht gerade schnell. Ich hatte da mal das "Sieb 
des Eratosthenes" in den Sprachen PHP, Python, Lua und NIC 
gegenübergestellt:

https://www.mikrocontroller.net/articles/NIC#Benchmarks

Python war der weitaus langsamste Interpreter von allen. Das ist aber 
schon eine Weile her, es handelte sich um Python Version 2.7. Es kann 
durchaus sein, dass sich da mittlerweile etwas getan hat.

von Stefan F. (stefanus)


Lesenswert?

Frank M. schrieb:
> Python war der weitaus langsamste Interpreter von allen

Ja aber es ging doch gerade um MicroPython, oder nicht? Ich wurde 
neulich (recht grob) darüber belehrt, dass MicroPython compiliert statt 
interpretiert.

: Bearbeitet durch User
von Rainer V. (a_zip)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich wurde
> neulich (recht grob) darüber belehrt, dass MicroPython compiliert statt
> interpretiert.

Wenn es wirklich compiliert, dann wäre das für Controller auf jeden Fall 
interessant, ansonsten ist doch wohl jedem klar, dass Äpfel mit Birnen 
nicht so ganz vergleichbar sind. Habe mal versucht, zu kapieren, wie man 
ein "normales" Python-Programm compiliert, bin aber kläglich 
gescheitert. Habe einfach nicht geschnallt, was ich alles anstellen muß, 
um ein lauffähiges! Programm zu erzeugen. Allein die ganzen 
Abhängigkeiten richtig zusammenzustellen hat mich heillos überfordert 
und mit Grafik und mehreren Threads hab ich gar nicht mehr kapiert, was 
zu machen wäre :-)
Gruß Rainer

von Vincent H. (vinci)


Lesenswert?

MicroPython compiliert zu Bytecode. Je nach Anwendung ist der sogar 
ziemlich flott. Ich hab mal Benchmarks gemacht für:
- Naive ackermann function
- Counting primes by trial division till 100.000
- 2D lerp of a random set of 2000 integers inside a C for-loop

Und da sind wir bei einem Faktor ~60-150.

Der Code dazu kugelt bei meiner Forth Implementierung herum:
Beitrag "Shi - embeddable Forth Engine"

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Ja aber es ging doch gerade um MicroPython, oder nicht?

Schau, auf welchen Beitrag ich geantwortet habe, dort steht "Python" und 
nicht "MicroPython" ;-)

Wie das mit MicroPython aussieht, weiß ich nicht. Keine Ahnung, ob der 
Compiler das in nativen Maschinencode des Targets übersetzt oder 
lediglich in einen binären Zwischencode, der dann auf dem Target 
interpretiert wird.

: Bearbeitet durch Moderator
von Vincent H. (vinci)


Lesenswert?

Ach, ich wollt noch editieren...
Man kann bei MicroPython den Code sogar vorab zu Bytecode compilieren 
lassen, das muss also nicht zur Laufzeit passieren!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vincent H. schrieb:
> Man kann bei MicroPython den Code sogar vorab zu Bytecode compilieren

Was heisst "bytecode"? Da gibt es 2 mögliche Formen:

1. Anweisungen in Maschinensprache des Targets
2. Code, der in binärer Form (statt ASCII) vorliegt, aber interpretiert
   wird

Ich hatte damals für NIC einen Compiler geschrieben. Der generierte 
aber nicht Maschinensprache, sondern Bytecode, der immerhin so schnell 
interpretiert wurde, dass er doppelt so schnell wie PHP und fünfmal so 
schnell wie Python lief.

von Johannes S. (Gast)


Lesenswert?

guckt doch einfach auf die Micropython Website. Wie es aussieht, kann
- REPL interaktive Codezeilen ausführen
- Bytecode vom Compiler generiert werden
- Nativecode com Compiler generiert werden
- 'Viper' Code, wie native, aber mit weiteren Abweichungen von Python
http://docs.micropython.org/en/latest/reference/speed_python.html

Mir persönlich sind das zuviele inkonsistente Varianten, obwohl ich 
Python auf dem PC nicht so schlecht finde.
Auf dem µC lieber C++, das ist ein Optimum aus Speed und Komfort weil 
ich eine Menge Komponenten benutzen kann.

von Vincent H. (vinci)


Lesenswert?

Frank M. schrieb:
> Vincent H. schrieb:
>> Man kann bei MicroPython den Code sogar vorab zu Bytecode compilieren
>
> Was heisst "bytecode"? Da gibt es 2 mögliche Formen:
>
> 1. Anweisungen in Maschinensprache des Targets
> 2. Code, der in binärer Form (statt ASCII) vorliegt, aber interpretiert
>    wird
>
> Ich hatte damals für NIC einen Compiler geschrieben. Der generierte
> aber nicht Maschinensprache, sondern Bytecode, der immerhin so schnell
> interpretiert wurde, dass er doppelt so schnell wie PHP und fünfmal so
> schnell wie Python lief.

Sry dachte das war klar, ich meine interpretierten Bytecode. Ich kenne 
auch niemanden der das Wort für Maschinencode nutzt.

Scheinbar hat sich Micropython aber mittlerweile weiterentwickelt. Die 
Möglichkeit tatsächlich zu Maschinencode zu compilieren gab es damals 
noch nicht als ich mich damit spielte.

von Nur_ein_Typ (Gast)


Lesenswert?

Frank M. schrieb:
> Laut Wikipedia ist Python wäre ein "üblicherweise interpretierte"
> Programmiersprache.

Korrekt.

> Und der Interpreter ist nicht gerade schnell. Ich hatte da mal das "Sieb
> des Eratosthenes" in den Sprachen PHP, Python, Lua und NIC
> gegenübergestellt:
>
> https://www.mikrocontroller.net/articles/NIC#Benchmarks
>
> Python war der weitaus langsamste Interpreter von allen. Das ist aber
> schon eine Weile her, es handelte sich um Python Version 2.7. Es kann
> durchaus sein, dass sich da mittlerweile etwas getan hat.

Die Referenzimplementierung CPython ist in den 3er-Versionen sogar noch 
ein klein wenig langsamer, aber bei dieser Implementierung ist 
Performanz ausdrücklich kein Designziel. Aber es gibt noch viele andere 
Interpreter, und einige davon sind performanceoptimiert und wesentlich 
schneller als CPython -- zum Beispiel Pypy. Damit hätten Deine 
Ergebnisse sicherlich ganz anders ausgesehen.

Das ist übrigens insofern lustig, als Python vor wenigen Jahren 
hinsichtlich der Performance einer der führenden Interpreter war. PHP 
hat demgegenüber mit Version 7, die nun viele zuvor kommerzielle 
Zend-Erweiterungen enthält, stark aufgeholt; Ruby behauptet immer gerne, 
schneller zu sein, aber in meinen Tests habe ich das bislang (noch?) 
nicht bestätigen können.

Obendrein gibt es dann ja noch eine Reihe anderer Möglichkeiten, 
Python-Code um Größenordnungen zu beschleunigen. Zum Einen gibt es 
Tricks im Datenmodell; zum Beispiel ist ein tuple() performanter als 
eine list(). In dieselbe Kategorie fallen Techniken wie die 
Klassenvariable _slots_, die eine Liste mit den möglichen Attributen 
einer Klasse festlegt, so daß diese nicht mehr in dem (relativ) 
langsamen und speicheraufwändigen dict() _dict_ abgelegt werden, und 
zudem wird die Autovivikation von Attributen verhindert, solange 
_dict__ nicht in den __slots_ enthalten ist. Außerdem gibt es 
verschiedene JIT-Compiler wie Numba und dazu einige Transpiler für 
Python, die Python-Code in C oder C++ übersetzen, die dann in nativen 
Maschinencode übersetzt werden.

Außerdem ist Python auch als Embedded- und Gluesprache konzipiert und 
läßt sich sowohl in anderen Programmen als Skriptinterpreter nutzen, wie 
es etwa Autocad Maya oder auch The GIMP nutzen. Andererseits lassen sich 
performancekritische Teile sehr einfach in native Bibliotheken 
auslagern, weswegen es eine Vielzahl solcher Bibliotheken wie das recht 
bekannte Numpy gibt. Gerade mit Numpy hätten Deine Ergebnisse zweifellos 
anders ausgesehen, wie diese Seite zeigt: [1]. Schon die Verwendung von 
Numbas JIT-Compiler hat das ansonsten unveränderte Programm um den 
Faktor 10 beschleunigt; der Umbau auf Numpy gar um mehr als Faktor 60!

Klar kann man "mal eben" einen Performancetest machen, aber wirklich 
zielführend und aussagekräftig ist das leider selten --, insbesondere im 
Falle von Python mit seinen verschiedenen Interpretern und seinen 
vielfältigen Möglichkeiten, die Performance zu verbessern. Letzten Endes 
sind die Ergebnisse solcher Benchmarks immer nur das Ergebnis der 
eigenen Annahmen und treffen keinerlei Aussagen über die tatsächliche 
Leistungsfähigkeit eines Interpreters für bestimmte Aufgaben aus der 
Praxis, insofern man lediglich seine eigenen Vorgaben und Annahmen 
testet -- wie Du Dein Sieb im nicht performanceoptimierten 
Standardinterpreter. Aber wer praktisches Numbercrunching mit Python 
machen will, benutzt dafür natürlich eine optimierte Library wie Numpy 
(oder Scikit, oder Pandas, oder... you name it).

[1] 
https://glowingpython.blogspot.com/2019/03/speeding-up-sieve-of-eratosthenes-with.html

von Nur_ein_Typ (Gast)


Lesenswert?

Rainer V. schrieb:
> Wenn es wirklich compiliert, dann wäre das für Controller auf jeden Fall
> interessant,

http://docs.micropython.org/en/latest/reference/speed_python.html?highlight=viper#the-native-code-emitter

> Habe mal versucht, zu kapieren, wie man
> ein "normales" Python-Programm compiliert, bin aber kläglich
> gescheitert.

Vorausgesetzt, Du hast build-essential und virtualenv bereits 
installiert und möchtest Dein Python-Programm "programm.py" übersetzen, 
sollte das hier (als einfaches Beispiel zum Start) gehen:
1
~$ virtualenv -p python3 ./v3
2
~$ source ./v3/bin/activate
3
(v3) ~$ pip install nuitka
4
(v3) ~$ nuitka3 programm.py -o programm.exe
5
(v3) ~$ ./programm.exe
6
(v3) ~$ deactivate
7
~$

von Nur_ein_Typ (Gast)


Lesenswert?

Frank M. schrieb:
> Vincent H. schrieb:
>> Man kann bei MicroPython den Code sogar vorab zu Bytecode compilieren
>
> Was heisst "bytecode"? Da gibt es 2 mögliche Formen:
>
> 1. Anweisungen in Maschinensprache des Targets
> 2. Code, der in binärer Form (statt ASCII) vorliegt, aber interpretiert
>    wird
>
> Ich hatte damals für NIC einen Compiler geschrieben. Der generierte
> aber nicht Maschinensprache, sondern Bytecode, der immerhin so schnell
> interpretiert wurde, dass er doppelt so schnell wie PHP und fünfmal so
> schnell wie Python lief.

Deine Implementierung habe ich in Deinem NIC-Artikel (sehr coole 
Angelegenheit ürigens) gefunden und mit Python2, Python3, Pypy2 und 
Pypy3 auf einem Xubuntu 18.04.5 LTS, i3-5010U CPU @ 2.10GHz ausgeführt:

Python2: 45,781
Python3: 22,566
Pypy2: 5,047
Pypy3: 4,788

Hm, daß Python3 schneller ist als Python2 hätte ich nicht erwartet, und 
dann auch noch so deutlich... Aber ansonsten zeigt das IMHO schon recht 
deutlich, wie stark sich die Wahl von Interpreter und Python-Version auf 
die Performance auswirkt. Und wenn ich mir mal die Ergebnisse in Deinem 
Artikel anschaue und hochrechne, bin ich überzeugt, daß Pypy2 und Pypy3 
am Ende auf identischer HW sogar deutlich besser abschneiden als die von 
Dir getesteten Lua, PHP und NIC. Ich meine, Pypy ist bei mir immerhin um 
Faktor 9 schneller als das von Dir getestete Python2.

Ach so, ich habe Dein Programm natürlich leicht anpassen müssen: zum 
Einen habe ich die Klammern beim print() hinzugefügt und zum anderen in 
Zeile 7 den zweiten Parameter der von range() auf ein int() gecastst: 
"range (2, int(zahl / 2))".

von temp (Gast)


Lesenswert?

Eigentlich stellt sich die Frage nicht ob Python oder besser bei C 
bleiben?
Das Project "micropython" auf github besteht aktuell aus 3884 Dateien in 
387 Verzeichnissen, geschrieben in C. Wieviel Bugs da wohl drin lauern?
Am Ende ist es für mich nichts wesentlich anders als z.B. mbed. Also ein 
fettes Framework. Es ist ja nicht die Sprache selbst von dem das lebt 
sondern  die ganze Hardwareabstraction drum herum. Wenn dann erst mal 
alles im Controller ist, wurden wieder 99% vom c/c++ Compiler erzeugt 
und das bischen Python Code maximal unter "ferner liefen". Und wenn man 
für eine bestimmte Hardwareanforderung keine passende Abstraction 
findet, landet man wieder beim Bitschubsen in den Registern. Hat man da 
in Python eigentlich auch den kompletten Satz Register- und Bitnamen aus 
den c-Headern der Hersteller zur Verfügung. Wenn nicht, dann wird es ja 
nur schlimmer statt besser. Dass sich eine LED oder ein Schalter oder 
ein normaler Analogeingang wie in den Micropythodemos elegant 
programmieren lassen steht außer Frage. Aber es gibt ja auch Sachen wo 
es wirklich ans Eingemachte geht. Spätestens wenn man dann erst 
python-Module in C bauen muss wird es lächerlich.
Aber das ist meine Meinung, jeder hat das Recht auf seine eigene.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nur_ein_Typ schrieb:
> in Zeile 7 den zweiten Parameter der von range() auf ein int()
> gecastst: "range (2, int(zahl / 2))".

Noch etwas schneller geht es mit dem //-Operator (ganzzahlige Division),
also "range (2, zahl // 2)", weil dann die explizite Konvertierung nach
int wegfällt. Der /-Operator macht in Python 3 eine Float-Division, auch
wenn beide Operanden Integers sind.

BTW: Das Programm berechnet zwar Primzahlen, aber das Sieb des
Eratosthenes geht anders und zeichnet sich insbesondere dadurch aus,
dass es ohne Divisionen auskommt.

von Der, der alles besser weiß (Gast)


Lesenswert?

C wird langfristig auch Python überleben wenn es um Kompaktheit und 
Effizienz auf anwendungsgerechten Plattformen geht.

Natürlich wird man argumentieren wie viele schnelle uC es gibt und daß 
man mit vielen MHz und Bitbreiten die performanten Mängel doch übersehen 
könnte und man mit der Zeit gehen sollte. Dann kommen die vielen 
Bibliotheken dazu und hat viel fremden Code. Da ist Bare Metal in C und 
dem Datenblatt alleine doch viel schöner.

Ist es dann ein Wunder, wenn erfahrene, praxis getaufte Entwickler bei 
dem bleiben dem sie vertrauen können und alle Stärken und Fußangeln 
kennen um zuverlässige industrielle Lösungen entwickeln zu können? Es 
ist im industriellen Umfeld nicht gut andauernd von vorne anfangen und 
immer neu alle wichtigen Erfahrungen sammeln zu müssen und dieses 
Investment an neuen, ungeprüften Methoden zu verschwenden.

Wer mit zuverlässiger Technik umgehen will verlangt als höchstes Gut 
Stabilität in allen wichtigen Aspekten. Seht, man kann immer dem letzten 
Schrei nachlaufen oder festigen was sich bewährt hat. Heute rennt man 
oft nur noch den Marktschreiern und der Hype nach und nichts ist mehr 
beständig.

Kaum jemand denkt daran, gute, bewährte Fundamente zu pflegen und zu 
erhärten. Es wird vielfach nur noch wild experimentiert und gepfuscht 
weil kaum etwas wirklich richtig funktioniert und erhofft sich eine 
Verbesserung mit der nächsten Hypewelle. Die Tatsache ist, man kauft 
sich meist immer nur neue Probleme ein. Wie oft wird auf teure 
kommerzielle Produkte wie Keil, IAR geschimpft. Trotzdem werden sich 
solche Werkzeuge in der Hand von erfahrenen, praxisnahen Entwicklern 
bewähren und Konsistenz begünstigen.

Man kann es eben auch so sehen. Der Fortschritt ist meistens ein 
zweiseitiges Schwert und ein leeres Blatt das erst noch beschrieben 
werden muß. Meistens weiß man erst nach einer Menge Lerngeld wie die der 
Hase wirklich läuft. Wie oft ergeht man sich in theoretischen 
Streitfragen anstatt C vernünftig einzusetzen? C größtes Gut ist die 
Hardwarenahe Umsetzung.

Nachvollziehbares 50 Jahre altes C mit allen sein Stärken und Schwächen 
wird noch lange gebraucht werden, ob es dem Establishment der neuen 
Generation passt oder nicht. Mit dem Feind den man kennt, kommt man oft 
besser klar. Mit C ist nichts unmöglich. Allen neuen Sprachkonzepten ist 
oft gemeinsam, daß es oft ultra komplizierte Buildmethoden verwendet und 
viel externe Ressourcen benötigt. Ob das wirklich ein Vorteil ist, kann 
fraglich sein.

von xyz (Gast)


Lesenswert?

> C wird langfristig auch Python überleben
...
> wird noch lange gebraucht werden, ob es dem Establishment der neuen
> Generation passt oder nicht.

+++

von Rainer V. (a_zip)


Lesenswert?

Nur_ein_Typ schrieb:
> Vorausgesetzt, Du hast build-essential und virtualenv bereits
> installiert und möchtest Dein Python-Programm "programm.py" übersetzen

Hallo, danke für das Beispiel. Leider habe ich nach einigen 
unerklärlichen (für mich :-)) Systemabstürzen das virtualenv nicht 
wieder installiert. Ist auch alles schon ein paar Jahre her. Hatte da zu 
Übungszwecken mit Python ein Neurales-Netzwerk gebaut und habe versucht, 
damit die Qualität von Zufallsgeneratoren zu bewerten. Dabei hat mich 
die lange Laufzeit dann irgendwann doch genervt....aber das gehört hier 
natürlich nicht hin...
Gruß Rainer

von Yalu X. (yalu) (Moderator)


Lesenswert?

Nur_ein_Typ schrieb:
> Python2: 45,781
> Python3: 22,566
> Pypy2: 5,047
> Pypy3: 4,788

Ich habe Franks Benchmark auf mal auf meinem Rechner laufen lassen, der
eine ähnliche Rechenleistung wie die PCs von Frank zu haben scheint.
MicroPython ist danach (zumindest auf diesem Rechner und bei diesem
Benchmark) etwas langsamer als das entsprechende normale Python (CPython
3):

1
Compiler/Interpreter   Version   Zeit/s   Art derAusführung
2
───────────────────────────────────────────────────────────
3
CPython 2              2.7.18    24,094   Bytecode
4
CPython 3              3.9.4     10,649   Bytecode
5
MicroPython            1.14      12,925   Bytecode
6
MicroPython native¹    1.14       8,253   Native Code (JIT)
7
PyPy 2                 7.3.4      2,891   Native Code (JIT)
8
PyPy 3                 7.3.4      2,526   Native Code (JIT)
9
Cython                 0.29.23    6,292   Native Code
10
Cython mit Typdekl.²   0.29.23    0,663   Native Code
11
GCC (C)                10.2.0     0,567   Native Code
12
───────────────────────────────────────────────────────────
13
CPU: i5-6267U CPU @ 2.90GHz
14
15
¹) Nutzung des Native Code Emitters:
16
17
     @micropython.native
18
19
²) Typdeklaration aller Variablen in der Funktion main() als int:
20
21
     cdef int limit, primzahl, zahl, zaehler, letzte_primzahl

Ich persönlich mag Python auf dem PC und dem Raspberry Pi sehr gerne,
aber auf Mikrocontrollern wie den STM32 oder ESP{8266,32} kann ich mich
damit noch (noch) nicht so richtig anfreunden.

: Bearbeitet durch Moderator
von xyz (Gast)


Lesenswert?

Python eignet sich im uebrigen vorzueglich, um mit minimalem Aufwand
unter Android/Symbian/WM eine Furz-App mit wenigen Zeilen zu schreiben.

Fortgeschrittenere koennen fakultativ auch das T.T.S. des Systems
fuer eine sprechende Kuckucksuhr benutzen.

Das will man ganz sicher nicht in C oder Assembler programmieren 
muessen!

von Jack V. (jackv)


Lesenswert?

Der, der alles besser weiß schrieb:
> Mit C ist nichts unmöglich.

Doch, du musst nur mal über den Tellerrand schauen: beispielsweise ein 
schneller Einstieg und eine geringe Codekomplexität (und damit 
Fehleranfälligkeit), wenn das Projekt dann doch mal umfangreicher wird – 
viele, teils kritische, Fehler, die in C gemacht werden, lassen sich in 
Python gar nicht machen. Sowas wie REPL gibt’s bei C auch nicht. Und 
wenn jemand gegen Python die Abhängigkeit von Libs, und damit fremdem 
Code, anführt, dann ist er einer der vermutlich eher Wenigen, die in C 
alles jedes einzelne Mal selbst zusammenschreiben – mit der erwähnten 
Fehleranfälligkeit. Die meisten anderen Leute suchen sich auch da 
passende Libs, und binden damit fremden Code ein.

Interessant finde ich, wie hier das „professionelle Umfeld“ angeführt 
wird. Abgesehen davon, dass mir in ’ner professionellen Anwendung 
ziemlich egal ist, in welcher Sprache der Entwickler das umgesetzt hat, 
solange es die Anforderungen erfüllt, ist doch ziemlich deutlich zu 
sehen, dass der TE nicht unbedingt professionelle Ambitionen hat, 
sondern die Zugänglichkeit ein wichtiges Kriterium ist – dem da von der 
„reinen Lehre“ erzählen zu wollen, halte ich für nicht ganz durchdacht. 
Manchmal habe ich das Gefühl, es geht um Neid: was manche Leute sich 
über Jahre mit C draufgeschafft haben, bringt ein Einsteiger heute in 
wenigen Wochen in ’ner anderen Sprache zustande, und das tut natürlich 
weh – da muss man was gegen wettern, ganz klar …

Was die geringere Performance angeht: einerseits ist Micropython etwas 
anders aufgebaut, als das herkömmliche Desktoppython, und wer sich das 
sogar schon mal selbst angeschaut hat, wird gefunden haben, dass die 
Zahlen dort etwas anders sind, als die der Benchmarks oben, und 
andererseits steht heute mehr als genug Leistung zur Verfügung, so dass 
zumindest im Feld des TE die Ressourcen kein Punkt sind, der die reine 
Lehre C erzwingen würde.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Der, der alles besser weiß schrieb:
> C wird langfristig auch Python überleben

Ach Quatsch. Schau mal in die Industrie, wie viele hochbezahlte 
Cobol-Jobs dort immer noch angeboten werden, um zum Teil jahrzehnte 
Codebasen zu pflegen. Wenn eine Sprache mal eine signifikante 
Verbreitung erreicht hat -- und das hat Python schon sehr, sehr lange -- 
dann stirbt sie nicht mehr so leicht aus.

von Sheeva P. (sheevaplug)


Lesenswert?

Yalu X. schrieb:
> Ich habe Franks Benchmark auf mal auf meinem Rechner [...]
>
>
1
> Compiler/Interpreter   Version   Zeit/s   Art derAusführung
2
> ───────────────────────────────────────────────────────────
3
> CPython 2              2.7.18    24,094   Bytecode
4
> CPython 3              3.9.4     10,649   Bytecode
5
> PyPy 2                 7.3.4      2,891   Native Code (JIT)
6
> PyPy 3                 7.3.4      2,526   Native Code (JIT)
7
> MicroPython            1.14      12,925   Bytecode
8
> GCC (C)                10.2.0     0,567   Native Code
9
> ───────────────────────────────────────────────────────────
10
> CPU: i5-6267U CPU @ 2.90GHz
11
>

Spannend... das ist dann im Falle von Pypy nurmehr Faktor 5 langsamer 
als C -- und, etwa um Faktor zwei schneller als die anderen Interpreter, 
die Frank getestet hat.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Yalu X. schrieb:
> Ich habe Franks Benchmark auf mal auf meinem Rechner laufen lassen

Ich habe im obigen Beitrag noch die Zeiten für MicroPython mit dem
Native Code Emitter und für Cython eingetragen.

In Cython können Variablen als C-Datentypen wie bspw. int oder double
deklariert werden, wodurch die dynamische Typisierung umgangen wird und
int-Variablen eine feste Bitbreite erhalten.

Mit einer solchen Typdeklaration (eine zusätzliche Zeile im Python-Code)
wird Franks Benchmark nur 17% langsamer als in C ausgeführt.

: Bearbeitet durch Moderator
von Sheeva P. (sheevaplug)


Angehängte Dateien:

Lesenswert?

Yalu X. schrieb:
> Yalu X. schrieb:
>> Ich habe Franks Benchmark auf mal auf meinem Rechner laufen lassen
>
> Ich habe im obigen Beitrag noch die Zeiten für Cython, einem weiteren
> Python-Compiler, eingetragen.
>
> In Cython können Variablen als C-Datentypen wie bspw. int oder double
> deklariert werden, wodurch die dynamische Typisierung umgangen wird und
> int-Variablen eine feste Bitbreite erhalten.
>
> Mit einer solchen Typdeklaration (eine zusätzliche Zeile im Python-Code)
> wird Franks Benchmark nur 17% langsamer als in C ausgeführt.

Wow, cool! Unterdessen hab' ich mir dann mal den Pseudocode des 
Wikipedia-Eintrags zum besagten Sieb geschnappt und in Python-Code 
gegossen -- auf dem NUC i3 von oben läuft das in allen Interpretern in 
unter 0.1 Sekunden, mithin einem Zeitbereich, in dem sinnvolle Messungen 
auf einem Multitasking-System ohnehin nicht mehr möglich beziehungsweise 
sinnvoll sind.

: Bearbeitet durch User
von Mucky F. (Gast)


Lesenswert?

Hercules H. schrieb:
> Daher würde ich gerne einiges von euch hören wollen.
> Würdet ihr es empfehlen, klappt das gut?

Keine Ahnung, nutze Py nur für Testsysteme in kleinem Umfang.

Aber eine "Hochsprache" für embedded halte ich erst ab einer gewissen 
Komplexität des Systems für sinnvoll. Dann aber unter einem OS wie z.B. 
Linux.

C ist imo ein besserer Makroassembler, aber gerade dadurch sehr 
hardwarenah. Wird überall benutzt um Betriebssysteme zu erstellen, 
nichts anderes macht man auf einem uC.


Gibt es auch für nahezu jeden Controller, falls nicht gibt es auch meist 
kein Py.

von Stefan F. (stefanus)


Lesenswert?

Die Sprüche, dass C Compiler kaum mehr als primitive Marko-Assembler 
seien, kann ich langsam nicht mehr hören. Ihr bildet euch wohl ein, dass 
nur neue Programmiersprachen weiterentwickelt wurden. Da irrt ihr euch 
aber gewaltig.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Mucky F. schrieb:
> C ist imo ein besserer Makroassembler,

Da hier +90% auch nicht wirklich in C programmieren können, erklärt dann 
ansatzweise solche "Einsichten" ...

von Sheeva P. (sheevaplug)


Lesenswert?

Mucky F. schrieb:
> Aber eine "Hochsprache" für embedded halte ich erst ab einer gewissen
> Komplexität des Systems für sinnvoll.

Ja, natürlich.

> Dann aber unter einem OS wie z.B. Linux.

Ach, ich weiß nicht... die kleinen OpenMV-Dinger [1] sollen unter 
Micropython ganz wunderbar auch ohne OS laufen -- und dann auch 
Bewegungs- und Gesichtserkennung beherrschen... und sowas will ich nicht 
in C machen müssen.

[1] https://openmv.io/

von c-hater (Gast)


Lesenswert?

Jack V. schrieb:

> Oder anders gefragt: wenn ich zwei gleiche
> Microcontroller habe, die nach außen hin exakt das Gleiche machen, dann
> ist der, der mit C-Kompilat beschickt wurde, dem, der mit MicroPython
> läuft, aus welchem Grund genau überlegen? Weil der Auftraggeber mehr
> bezahlt hat, weil die Entwicklung in C nunmal teurer ist, oder warum?

Weil das beweist, das der verwendete µC viel zu fett (und damit viel zu 
teuer) war. Der C-Code wird auch auf einem sehr viel langsameren (und 
damit billigeren) µC laufen.

Letztlich hängt es von der Stückzahl ab. Ein Einzelstück oder 
Versuchsmuster kann man sicher auch mal in Python programmieren, wenn 
man halt einen hinreichend leistungsfähigen µC nimmt.

Für eine geplante Serie ist das aber i.d.R. Bullshit.

Letzlich ist es davon abhängig, was die Software-Entwicklung kostet, im 
Verhältnis zur Größe der Serie.

Der Witz ist: bei erfahrenen C-Progrmmierern sind die Entwicklungkosten 
sicherlich nicht höher als die mit erfahrenen Python-Programmierern. Nur 
wird halt das C-Programm schneller sein und auf einem kleineren, 
langsameren und billigeren µC lauffähig sein...

Und zwar sofort ab Start der Serie...

von Rainer V. (a_zip)


Lesenswert?

HimmelHerrGott, eine interpretierende Sprache gegen eine compilierte 
auszupalavern ist doch echt Pillepalle. Als der RasPi kam, habe ich 
gelesen, "barebone" GPI-Toggle, "C" 1 MHz....geil Py, 60Khz 
Scheiße...Pearl, P1 oder wie,  alle unter 60KHz...alle Scheiße! 
Kindergarten, in den ich meinen Sohn nie geschickt hätte!!
Rainer

von Sheeva P. (sheevaplug)


Lesenswert?

c-hater schrieb:
> Letzlich ist es davon abhängig, was die Software-Entwicklung kostet, im
> Verhältnis zur Größe der Serie.

Das hatte ich ja schon weiter oben geschrieben, vielen Dank für die 
Bestätigung.

> Der Witz ist: bei erfahrenen C-Progrmmierern sind die Entwicklungkosten
> sicherlich nicht höher als die mit erfahrenen Python-Programmierern.

Doch. Das ist ja der ganze Deal bei Skriptsprachen: man tauscht 
Performanz und Ressourcenbedarf gegen kürzere Entwicklungszeiten und 
-kosten.

von Der, der alles besser weiß (Gast)


Lesenswert?

Da Python, auf uC angewendet, gewisse Grundvoraussetzungen voraussetzt, 
ist es nachteilig nur auf den dafür gewählten 32-Bit uC Plattformen 
laufen können die dafür genug Ressourcen haben. Das schliesst schon mal 
viele alternative uC aus, die effizient programmiert, ihre Aufgaben mit 
viel schmalbrüstigeren und billigeren uC erfüllen könnten.

Aber wie dem auch sei und wie so oft im Leben wird man eben mit Kanonen 
auf Spatzen schießen wollen um diese Bolliden der uC-Welt krampfhaft 
einsetzen zu wollen. Man fragt sich dann nur warum der gesunde 
Menschenverstand so oft auf der Strecke gelassen werden muß.

Es ist wohl eine Krankheit unserer Zeit alles so komplex wie möglich 
machen zu wollen anstatt die technisch richtig, schlanke Lösung eines 
Problems auszuarbeiten und Komplexität aufs Notwendige zu beschränken. 
Die Sucht alles mit dem Internet verbinden zu wollen hat mittlerweile 
perverse Auswüchse angenommen.

Schon Antoine de Saint-Exupéry drückte diese Wahrheit aus, wenn er 
behauptete, daß ein Design erst dann perfekt ist wenn nichts Unnötiges 
mehr entfernt werden kann.

Wie oft werden heutzutage 32-Bit Bolliden für Aufgaben eingesetzt die 
ein professionell programmierter 8-Bitter genauso gut erfüllen könnte?

Nein! Die Welt der embedded Gerätschaften ist gespickt mit 
Mißgeburt-Gerätschaften die ihren Zweck nur mangelhaft und mit vielen 
funktionellen Kompromissen erfüllen und oft ihre Benutzer unnötig 
irritieren.

Python auf uC scheint voller HW-Zugangskompromisse zu sein die einen 
effizienten Einsatz am Ende erschweren und viele Zugeständnisse seitens 
des Entwicklers erzwingen. Auf größeren Plattformen hat Python natürlich 
viel Wert.

von Jack V. (jackv)


Lesenswert?

Der, der alles besser weiß schrieb:
> Wie oft werden heutzutage 32-Bit Bolliden für Aufgaben eingesetzt die
> ein professionell programmierter 8-Bitter genauso gut erfüllen könnte?

Wieso schreibst du deine Texte von ’nem 64-Bit-Boliden (mit einem l), 
bei dem das OS alleine zweistellige GB an Plattenplatz und mehrere GB 
RAM benötigt, wo doch ein professionell eingerichteter 16-Bitter für die 
Aufgabe doch genausogut eingesetzt werden könnte?

Willkommen in der Gegenwart, wo 32-Bit-μC nicht zwangsweise 
nennenswert teurer sind, als viele 8-Bit-Controller – die zudem teils 
noch um den Faktor 10 niedriger getaktet, und trotzdem nicht sonderlich 
sparsamer sind.

von Rainer V. (a_zip)


Lesenswert?

Rainer V. schrieb:
> HimmelHerrGott

Ich sag es nochmal. All die 100Mio Led-Blinker brauchen, kennen, sollen 
keinen kennen, müssen sowieso nicht...und werden ihr Programm immer 
wieder so (versuchen zu) schreiben, wie sie es gerade auch getan haben. 
Es ist schlicht wahr! Einmal Violett, immer Violett... und genau damit 
geht die Welt unter! Für mich ein ästhetischer Gedanke.
Rainer

von Johannes S. (Gast)


Lesenswert?

Der, der alles besser weiß schrieb:
> Da Python, auf uC angewendet, gewisse Grundvoraussetzungen voraussetzt,
> ist es nachteilig nur auf den dafür gewählten 32-Bit uC Plattformen
> laufen können die dafür genug Ressourcen haben.

Nein, MicroPython kann Ethernet, Grafik, USB, Speicherkarten, und das 
alles auf einmal. Eben das was 32 Bitter mitbringen einfach bedienbar 
machen. Aber das machen die 8 Bit Meister ja alles im Schlaf und viel 
billiger. Ja nee, is klar.

von xyz (Gast)


Lesenswert?

> in dem sinnvolle Messungen
> auf einem Multitasking-System ohnehin nicht mehr möglich beziehungsweise
> sinnvoll sind.

0.1 s sind fuer eine CPU eine Ewigkeit.
Du bist nur zu doof die Zeit exakt zu messen.

von Nop (Gast)


Lesenswert?

Mucky F. schrieb:

> C ist imo ein besserer Makroassembler

Das ist doch gar nicht der Punkt. Der Punkt ist, daß C ein portabler 
Makroassembler ist! :-)

von Mucky F. (Gast)


Lesenswert?

Johannes S. schrieb:
> Nein, MicroPython kann Ethernet, Grafik, USB, Speicherkarten, und das
> alles auf einmal. E

Wird sicher seine Anwendung haben, bei den Voraussetzungen ist evtl ein 
embedded OS die bessere Wahl. Imo gibt es da aber keine allgemeine 
Lösung.

Nop schrieb:
> Der Punkt ist, daß C ein portabler Makroassembler ist! :-)

Auch eine Frage der Anwendung. Die Möglichkeit z.B nicht mehr lieferbare 
Controller relativ einfach zu ersetzen bietet langfristig nur C. Also 
nach meiner Erfahrung.

von Dieter H. (kyblord)


Lesenswert?

ich denke es wird immer mehr in schlange programmiert, wenn überaupt 
noch. heute wird ja eher der ganze murks aus simulink generiert

von Andreas H. (ahz)


Lesenswert?

Hercules H. schrieb:
> Meisten waren es nur Kleinigkeiten, z.b LC
> Display zum laufen bringen, oder eine einfache Steuerung einiger LED's.
> Dies habe ich bisher in C gemacht, allerdings auch manchmal mit Mühe, da
> es mir nicht ganz so einfach viel dies passenden Bibliotheken zu finden.

Gibt es denn immer alle Bibliotheken auch auf den aktuellen 
Pythonversionen?
Wie überprüft Du, ob die Bibliothek korrekt funktioniert?
Und was machst Du, wenn es auch in Python keine Libs gibt?

Auch in Python sind Bibliotheken nicht die Lösung eines Problems, 
sondern höchstens eine Vereinfachung.


Martin S. schrieb:
> Ich setze Python schon seit >20 Jahren in professionellen und
> industriebewaehrten Loesungen ein. U.a. werden damit auch Halbleiter
> getestet.

Das klingt spannend.
Auf welcher Testmaschine läuft denn Python?
Wird das Handling für Multi-site auctomatisch gemacht? Da fluchen unsere 
TIngs immer am meisten wenn sie die verfügbaren Messgeräte auf vier 
Heads scedulen müssen ;)
Wie ist denn die Testzeit/Die im Vergleich zu einem in C programmierten 
Test?
Schlau mich bitte mal auf. Danke :)


Johannes S. schrieb:
> MicroPython kann Ethernet, Grafik, USB, Speicherkarten, und das
> alles auf einmal.

Also ich habe sicherheitshalber nochmal nachgesehen.
Weder meine elektrische Zahnbürste, noch mein Rasieraparat, haben 
Ethernet, Grafik, USB, Speicherkarten.

Und irgendwie fallen mir unzählige Anwendungen ein, wo ich absolut kein 
Ethernet, Grafik, USB, Speicherkarten gebrauchen kann, ein uP an sich 
die Sache aber deutlich vereinfacht.

Meinst Du,ich sollte da eher an zukünfige Erweiterungen denken und z.B. 
Ethernet für die Temeraturreglung meines nächsten Teekochers einplanen 
damit ich da MicroPython einsetzen kann?

/regards

von Der, der alles besser weiß (Gast)


Lesenswert?

Johannes S. schrieb:
> Der, der alles besser weiß schrieb:
>> Da Python, auf uC angewendet, gewisse Grundvoraussetzungen voraussetzt,
>> ist es nachteilig nur auf den dafür gewählten 32-Bit uC Plattformen
>> laufen können die dafür genug Ressourcen haben.
>
> Nein, MicroPython kann Ethernet, Grafik, USB, Speicherkarten, und das
> alles auf einmal. Eben das was 32 Bitter mitbringen einfach bedienbar
> machen. Aber das machen die 8 Bit Meister ja alles im Schlaf und viel
> billiger. Ja nee, is klar.

Johannes, darum geht es ja nicht. Wie viele neue Paradigmen, 
funktioniert Python nur mit einem langen Rattenschwanz an Frameworks die 
man alternativ nicht in dem Maße hat. Natürlich sind schnellere und 
breitere Mikros für Deine erwähnten Anwendungen die richtige Wahl. Muß 
es aber gerade Python sein? Auch in C/C++ braucht man praktischerweise 
externen Bibliothekensupport, nur ist es oft einfacher.

Ich arbeite seit 2013 mit STM32 und LPC Typen die USB und Ethernet, TFT 
Graphik und SD Karten können müssen. Nur machen wir das mit IAR und 
einem RTOS und haben solide Performanz damit. Da ist Python in 
Anbetracht der Umstellungskosten nicht so günstig und würde auch nicht 
die notwendige Leistung bringen. Abgesehen davon würde die GL gegen eine 
Umstellung sein, wenn es nicht klare Verbesserungen bringt. Jedenfalls 
hat es keinen Sinn ein gut funktionierendes Ökosystem wegzuwerfen. Für 
unser Tram ist C/C++ kein Thema. Das Alter unseres Entwicklungsteams ist 
übrigens zwischen 25 bis 55. Für andere und interne Zwecke wird auch bei 
uns schon jahrelang Python verwendet, aber nicht für unsere kritischen 
industriellen Steuergeräte in der Energietechnik die harte Bedingungen 
erfüllen müssen.

Was den Pythonsyntax betrifft, gibt es ja auch nicht viel auszusetzen. 
Ist ja leicht erlernbar und man gewöhnt sich daran. Python finden wir 
eher nützlich als ein praktisches Labor- und Entwicklungswerkzeug.

Deinen beiden letzten Sätze finde ich aber trotzdem etwas voreilig;-)

Was mich betrifft, programmiere ich meine Hobby uC Projekte lieber in C 
und komme ganz gut damit zu recht weil ich für meine HW Anwendungen 
lieber mit 5V Logik arbeite und mehr Auswahl an (vorhandenen) 8-Bittern 
habe. Abgesehen davon machen 8-Bitter im Hobbybereich viel weniger 
Arbeit und verschlingen bei der Umsetzung weniger Zeit. Im Kontrast zu 
umfangreichen Arbeitsprojekten machen 8-Bitter mehr Spaß und für 
einfachere Projekte reichen sie fast immer aus; und wenn nicht, ist es 
leicht auf STM32 umzusteigen.

Wir alle haben unsere eigenen Vorstellungen was uns interessiert. Wir 
brauchen uns deshalb nicht in die Haare fahren;-)

von Andreas H. (ahz)


Lesenswert?

xyz schrieb:
> 0.1 s sind fuer eine CPU eine Ewigkeit.
> Du bist nur zu doof die Zeit exakt zu messen.

Dann erklär es ihm doch mal bitte.
Insbesondere den Teil wie man die Zeiten, die der Multitaskingkernel 
während der Messung selber verbrät, rausrechnet.
Ist auch mir bei Non-Realtime OS etwas unklar.

/regards

: Bearbeitet durch User
von Rainer V. (a_zip)


Lesenswert?

Der, der alles besser weiß schrieb:
> Was den Pythonsyntax betrifft, gibt es ja auch nicht viel auszusetzen.
> Ist ja leicht erlernbar und man gewöhnt sich daran. Python finden wir
> eher nützlich als ein praktisches Labor- und Entwicklungswerkzeug.

Genau das ist es doch...aber nützlich und praktisch schließt sich doch 
nicht aus! Und wenn wir mal beim ambitionierten Bastler bleiben, was 
programmiert man denn so für einen Controller, was eine Hochsprache 
benötigen würde?? Die jetzt massig verbreiteten Sketche in C oder C+ 
oder was auch immer, sprechen doch genau die Leute an, die erst noch 
Bastler werden wollen. Und die lernen eben was ganz anderes als die 
Generationen vor ihnen. Als unser Chef damals mit dem Doktor an der Hand 
verkündete, der würde unser neues Produkt entwickeln, waren alle 
begeistert. Tatsächlich hatte der (woher auch immer) alles an Software, 
was man brauchte...leider in LabVIEW und nachdem er nach 2 Jahren 
gegangen ist und ein produktionsreifes System hinterlassen hat, haben 
unsere armen Programmierer ca. 3 Jahre gebraucht, das alles in eine 
pflegbare Software auf C/C++ Basis umzuschreiben. Natürlich sind diese 
Kosten in der Bilanz des Doktors nie aufgetaucht. Trotzdem haben auch 
heute noch einige Leute einen dicken Hals, wenn wir auf diese Sache zu 
sprechen kommen...ich weiß auch nicht warum...was ich damit sagen 
wollte...
Gruß Rainer

von Johannes S. (Gast)


Lesenswert?

Andreas H. schrieb:
> Weder meine elektrische Zahnbürste, noch mein Rasieraparat, haben
> Ethernet, Grafik, USB, Speicherkarten.

wie altmodisch :) Also meine Zahnbürste hat ein Display und Bluetooth. 
Oder das Fitnessarmband hat eine nette Farbgrafik und ebenfalls Funk.
Die laufen vermutlich nicht mit Micropython, aber wenn man sieht was so 
ein kleiner nRF Chip schon drauf hat, wäre das sicher auch nicht 
unmöglich. Ich habe ein kleines Modul mit BT, das ist groß wie mein 
kleiner Fingernagel.

Ich benutze auch lieber C++, mir käme es aber nicht in den Sinn andere 
Programmiersprachen/Systeme oder gar die Programmierer so runter zu 
machen. Und die MP Entwickler haben eine Menge drauf.
Typischerweise kommt da ein Student in einen Betrieb, bringt z.B. das 
Micropython Wissen mit und erledigt eine Aufgabe in 1-2 Wochen wo der 
alte C Programmierer ziemlich in die Röhre guckt. Würde er auch 
schaffen, aber nicht in der Zeit. Wenn man sich bisher nicht mit 
Ethernet, schöner Grafik, USB oder schneller SDC beschäfftigt hat, dann 
schüttelt man das auch nicht dem Ärmel. In Micropython ist sowas eben 
als Modul vorhanden und kann eingebunden und benutzt werden wie am PC.
Und nicht alle Serienprodukte werden in 100k Stückzahlen hergestellt, 
oft sind die Entwicklungskosten und -zeiten relevanter.

Der, der alles besser weiß schrieb:
> Was mich betrifft, programmiere ich meine Hobby uC Projekte lieber in C
> und komme ganz gut damit zu recht weil ich für meine HW Anwendungen
> lieber mit 5V Logik arbeite und mehr Auswahl an (vorhandenen) 8-Bittern
> habe. Abgesehen davon machen 8-Bitter im Hobbybereich viel weniger
> Arbeit und verschlingen bei der Umsetzung weniger Zeit.

Und die 8 Bitter werden ja nicht durch die 32 Bitter abgeschafft, das 
Thema wurde doch schon oft genug diskutiert. Nur haben die 8 Bitter 
nicht die genannte Peripherie mit der Power. Meine Kollegen haben einen 
AVR+XPort durch F7+Hühnerfutter ersetzt, ist billiger und kann bedeutend 
mehr. Ich habe gerade ein Disco F769 hier liegen, da hat der 
Grafikspeicher mit 1,5 MByte schon mehr als ein 8 Bitter überhaupt 
adressieren kann.
Und auch fürs Hobby interessieren mich die 8 Bitter nicht mehr, ein 
LPC8xx ist auch klein und billig und bringt schon genug Speicher mit um 
bequem programmieren zu können, 5 V Toleranz haben viele 32 Bitter 
ebenfalls und auf vielen Modulen sitzen dann wieder Vreg und 
Pegelwandler für 5 V, also auch Quatsch.
So brauche ich nicht verschiedene Entwicklungsumgebungen (Ausnahme: ESP) 
und die Weiterentwicklungen der vielen Prozessoren zu verfolgen kostet 
mir auch zuviel Zeit.

von Der, der alles besser weiß (Gast)


Lesenswert?

Rainer V. schrieb:
> Genau das ist es doch...aber nützlich und praktisch schließt sich doch
> nicht aus!

O weh! Da habe ich mich wohl zweideutig ausgedrückt. Mit "als" wollte 
ich nicht "nützlich" mit "praktisch" abwägen. Ich wollte damit 
"nützlich" UND "praktisch" ausdrücken.

Was LabVIEW betrifft verwenden wir es im Labor für die Steuerung von 
Testgeräten, Klimaschrank mit guten Erfolg schon seit über zwanzig 
Jahren. Es gibt mindestens drei Kollegen die damit regelmässig arbeiten. 
Ich glaube nicht, daß wir das von Dir beschriebene Problem haben würden.

von Der, der alles besser weiß (Gast)


Lesenswert?

Johannes S. schrieb:
> Und die 8 Bitter werden ja nicht durch die 32 Bitter abgeschafft, das
> Thema wurde doch schon oft genug diskutiert.

Wir haben lediglich grundverschiedene Interessengebiete. Für meine in 
Frage kommenden Aufgabengebiete sind die 8-Bitter einfach zweckmässiger 
als die von Dir bevorzugten moderneren Typen. Auch sind montierte uC wie 
bei den Pro-Minis und Nanos recht nützlich.

von Rainer V. (a_zip)


Lesenswert?

Der, der alles besser weiß schrieb:
> Was LabVIEW betrifft verwenden wir es im Labor für die Steuerung von
> Testgeräten, Klimaschrank mit guten Erfolg schon seit über zwanzig
> Jahren. Es gibt mindestens drei Kollegen die damit regelmässig arbeiten.
> Ich glaube nicht, daß wir das von Dir beschriebene Problem haben würden.

Ja danke, ich habe deinen Beitrag eigentlich auch so verstanden...war 
nur unglücklich ausgedrückt. Und das Problem ist einfach, wenn du eine 
Software in LabView hast, dann ist das fürs Labor ok. Wenn du ein 
Produkt hast, dass du pflegen mußt...was hat allein die Anpassung von 
Windoof 1 über 6 auf 10 gekostet! Und dann such mal einen Softi auf dem 
Arbeitsmarkt, der LabView in seiner Vita stehen hat (und auch damit 
arbeiten will!). Will sagen, Softwarelösung haben und Pflegen sind zwei 
Paar Schuhe, die doch einige Nummern auseinander liegen! Klar, dem 
Dokter geht das alles am A vorbei, ich glaube aber der Chef schaut das 
nächste Mal bestimmt genauer hin, wenn er einen Doker an die Hand 
bekommt.
Gruß Rainer

von Stefan F. (stefanus)


Lesenswert?

Ich denke auch dass die Programmiersprache Python an sich nichts ist, 
was mir Freudentränen in die Augen bringt. Aber die ganzen Bibliotheken, 
die dazu entwickelt wurden machen es für viele zur Scriptsprache erster 
Wahl.

Aus genau dem gleichen Grund musste ich vor vielen Jahren damit 
beginnen, in Java zu entwickeln.

Es ist einfach so, dass die Ansprüche an unsere Software in den 
vergangenen 40 Jahren massiv gestiegen sind. Früher waren Anwender 
zufrieden, wenn Geräte funktionierten. Und sie waren glücklich, wenn sie 
ihre Einstellungen speichern konnten.

Heute muss alles Bunt, Smart und mit Bluetooth sein, um es mal salopp 
auszudrücken. Alleine diese drei Punkte, die von Anwendern als "Nette 
Nebensache" betrachtet werden, lassen den Entwicklungsaufwand 
explodieren - es sei denn, man setzt auf fertige Bibliotheken.

Und genau deswegen fallen allmählich alle Programmiersprachen raus, wo 
das Einbinden fremder Bibliotheken von Anfang nicht vorgesehen oder nur 
rudimentär vorgesehen waren.

C hat da im Gegensatz zu einigen praktisch ausgestorbenen 
Programmiersprachen das große Glück, nicht ganz mit leeren Händen da zu 
stehen. Doch die Zeiten hardwarenaher Programmierung neigen sich dem 
Ende zu. Wer mit Softwareentwicklung bis zur Rente kommen will, sollte 
besser nicht damit rechnen, mit C alleine durch zu kommen.

Was ich mich Frage: Wenn man an der Uni in ferner Zukunft nur noch 
lernt, die richtigen Legosteine zu finden und zusammen zu stöpseln, wer 
macht dann die Legosteine?

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Was ich mich Frage: Wenn man an der Uni in ferner Zukunft nur noch
> lernt, die richtigen Legosteine zu finden und zusammen zu stöpseln, wer
> macht dann die Legosteine?

Die dann noch übrigen C Programmierer mit dann grauen Haaren. Also so 
wie heute die COBOL und Fortran Experten. Ich hoffe da dazu zu gehören 
und mich dann fürstlich dafür entlohnen zu lassen ;-)

von Andreas H. (ahz)


Lesenswert?

Johannes S. schrieb:
> Andreas H. schrieb:
>> Weder meine elektrische Zahnbürste, noch mein Rasieraparat, haben
>> Ethernet, Grafik, USB, Speicherkarten.
>
> wie altmodisch :) Also meine Zahnbürste hat ein Display und Bluetooth.
> Oder das Fitnessarmband hat eine nette Farbgrafik und ebenfalls Funk.

Du hast den Witz leider nichtverstanden, schade. Also noch mal zum 
mitschreiben:
Die meisten, heutzutage eingesetzten uPs haben kein Ethernet, Grafik, 
USB, Speicherkarten weil es in der Anwendung garnicht nutzbar wäre.
Überleg mal wo überall uPs verbaut sind, die man normalerweise garnicht 
zur Kenntnis nimmt.

Ein Beispiel (vom Hobbytisch, gewerblich darf man ja nicht posten):
Ein Alps Motorfader bekommt einen 8-Bit uP über den per I2C der 
eingestellte Wert abgefragt und auch gesetzt werden kann.
Ausserdem stellt der uP nach dem Wiedereinschalten den eingestellten 
Wert (im EE gemerkt) wieder her, die Einstellung überlebt also auch 
gelegentliche Putzorgien.
Dieser uP kann mit einem Display genausowenig anfangen wie mit einer SD 
Karte.

> Typischerweise kommt da ein Student in einen Betrieb, bringt z.B. das
> Micropython Wissen mit und erledigt eine Aufgabe in 1-2 Wochen wo der
> alte C Programmierer ziemlich in die Röhre guckt. Würde er auch
> schaffen, aber nicht in der Zeit.

Und wer macht den Support wenn der Student wieder weg ist? Wer fixt 
Bugs, ggf auch im MicroPython?

Normalerweise lässt man Studenten ja durchaus neue Ideen einbringen. 
Dann sollte man aber unbedingt auch den "alten C Programmierern" die 
Zeit geben sich das mal anzueignen. Die sind idR nämlich auch nicht 
dümmer als die Studenten.
Nur deutlich erfahrener. Die wissen nämlich, u.a., was es bedeutet 
externe Software  über 10 Jahre Produktlaufzeit mitschleppen zu müssen.

> Und nicht alle Serienprodukte werden in 100k Stückzahlen hergestellt,
> oft sind die Entwicklungskosten und -zeiten relevanter.

Und genau dann ist der Kunde richtig happy, wenn er bei einer zwingend 
notwendigen Änderung, in 8 Jahren, plötzlich einen horrenden Preis 
bezahlen muss, weil die Software seit Jahren nicht an die Änderungen der 
externen Software angepasst wurde (hat ja keiner bezahlt) und die "alten 
C Programmierern" jetzt erst anfangen, sich mit den Internals zu 
beschäftigen. Klingt nicht wirklich nach einem guten Plan^^

/regards

von Andreas H. (ahz)


Lesenswert?

Μαtthias W. schrieb:
> Stefan ⛄ F. schrieb:
>> Was ich mich Frage: Wenn man an der Uni in ferner Zukunft nur noch
>> lernt, die richtigen Legosteine zu finden und zusammen zu stöpseln, wer
>> macht dann die Legosteine?
>
> Die dann noch übrigen C Programmierer mit dann grauen Haaren. Also so
> wie heute die COBOL und Fortran Experten. Ich hoffe da dazu zu gehören
> und mich dann fürstlich dafür entlohnen zu lassen ;-)

Hihi.

Μαtthias W., Stefan ⛄ F.

YMMD. Da fängt die Arbeitswoche doch gleich mit einem suffizienten 
Lächeln an. Vor allem weil man ja auch noch ausreichende Asmkenntnisse 
in der Hinterhand hat ;)

/regards

von Stefan F. (stefanus)


Lesenswert?

Andreas H. schrieb:
> Klingt nicht wirklich nach einem guten Plan

So läuft es leider oft in der Praxis.

Wo ich derzeit arbeite wird Kundenspezifische Server Software entwickelt 
und für die Kunden betrieben. Also keine Massenproduktion, dafür 95% 
individuelle Sonderlocken. Das können Firmen wie SAP nämlich nicht in 
dem Umfang.

Jedenfalls kommt es mehrmals im Jahr vor, dass unsere Verkäufer 
versehentlich eine Funktion verkaufen, die gar nicht vorhanden ist. 
Einfach weil sie die Systeme unterschiedlicher Kunden mental 
durcheinander gebracht haben oder weil sie Features in das DB Schema 
hinein interpretiert haben, die nie existierten. Das passiert schnell, 
wenn man sich "universelle" Datenstrukturen ausdenkt (ich kämpfe stets 
dagegen an).

Das Projekt ist nicht selten >10 Jahre alt, die Entwickler sind längst 
entlassen, und damals legte man noch keinen Wert auf Dokumentation. Nun 
soll ich eine kryptische Fehlermeldung "mal eben schnell" anhand des 
Stack-Trace erklären, ohne Zugriff auf die produktiven Systeme. Kein 
Problem, das kann ich. Aber nicht selten stellt sich dann heraus, dass 
die fragwürdige Konfiguration für die bestehende Software vollkommen 
sinnlos ist. Man hat es aber bereits verkauft und den Zieltermin 
überschritten. Es muss sofort gerettet werden, denn jeden Tag verlieren 
wir 5% von der Bezahlung. Ach ja, es darf auch quasi nichts kosten, denn 
man hat es ja als simple Konfigurationsänderung verkauft.

Dann frickelt man (ich) in Windeseile in das bereits vermurkste und 
nicht dokumentierte Projekt eine neue nicht klar spezifizierte Funktion 
hinein, für die man normalerweise 3 Wochen (Entwicklung+Test) eingeplant 
hätte. Das Projekt wird dadurch immer schlechter. Man kann es aber nicht 
abwerfen, weil der Kunde unser Täglich Brot bezahlt. Man kann es auch 
nicht auf eigene Kosten neu machen, weil die Doku fehlt. Niemand weiß so 
richtig, welche Funktionen das System überhaupt alles hat. Nicht einmal 
die Projektleiter, die das Projekt/den Kunden von Anfang an betreut 
haben.

Das ich die Kacke, die ich in meinem Job am meisten hasse. Solche 
Situationen bereiten mir mehr Stress, als Überstunden und Notfälle.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Μαtthias W. schrieb:
> Ich hoffe da dazu zu gehören und mich dann fürstlich dafür entlohnen zu
> lassen ;-)

Das wird erst beim Y3K-Problem passieren. Bist dahin müsstest du schon 
noch durchhalten.

Kann aber auch sein, dass dann doch wieder die COBOL-Programmierer 
gefragt sein werden. :-)

von Johannes S. (Gast)


Lesenswert?

Andreas H. schrieb:
> Du hast den Witz leider nichtverstanden, schade. Also noch mal zum
> mitschreiben:
> Die meisten, heutzutage eingesetzten uPs haben kein Ethernet, Grafik,
> USB, Speicherkarten weil es in der Anwendung garnicht nutzbar wäre.
> Überleg mal wo überall uPs verbaut sind, die man normalerweise garnicht
> zur Kenntnis nimmt.

ich habe das schon verstanden, wir sehen vermutlich nur unterschiedliche 
Geräte. Seit über 10 Jahren habe ich eine logitech Harmony One 
Fernbedienung. Fernbedienungen brauchen auch kein Display und kein USB, 
die hat es aber. Und nutzt es dazu, besser sein zu sein als das was es 
vorher auf dem Markt gab: ersetzt viele andere, hat ein besseres 
Bedienkonzept und durch das Farbdisplay war/ist die flexibler und 
einfacher zu bedienen als andere.
Mir geht es darum, das man die bessere Technik nutzen kann um besseres 
UI/UX oder leistungsfähigere Geräte zu bauen. Ethernet finde ich besser 
als Turnschuh Netzwerk (SD-Karten), aber puh, Ethernet, kompliziert, 
teuer. Nein, ein Phy kostet einen Euro und Controller mit EMAC sind auch 
nicht teurer. Ebenso wie Controller mit viel Speicher, viel Takt oder 
ordentlichen Displayschnittstellen. Man muss nur die PS auf die Strasse 
bringen können, das ist die krux. Und da greift eine ordentliche C++ Lib 
oder µP ein. Für C muss man nur lange lernen, für C++ noch länger. Jetzt 
kommt Python und macht alles ganz 'einfach'. Das man sich erstmal 
Gedanken um eine ordentliche Programmstruktur machen muss lernen Python 
Programmierer hoffentlich auch.

Für ein intelligentes Poti sehe ich auch keinen Bedarf für µP, aber das 
dürfte auch kaum das Ziel sein. Eventuell wenn man das virtualisiert 
durch ein Touchdisplay und es per USB an einen Rechner anschliessen 
kann. USB ist ja auch so eine Schnittstelle die man vermeiden wollte, 
aber mit einem CubeMX, C++ Klassen oder µP ist auch USB einfach zu 
benutzen.

Andreas H. schrieb:
> Und genau dann ist der Kunde richtig happy, wenn er bei einer zwingend
> notwendigen Änderung, in 8 Jahren, plötzlich einen horrenden Preis
> bezahlen muss,

Projektspezifische Entwicklung ist sehr teuer, da muss man sich erstmal 
einen Ruf aufbauen und auch Kunden haben die das bezahlen. "Günstig" ist 
heute nur von Stange, Sonderwünsche und deren Verwaltung sowie Wartung 
lohnt sich für viele schon lange nicht mehr.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich denke auch dass die Programmiersprache Python an sich nichts ist,
> was mir Freudentränen in die Augen bringt.

Ich habe vor 2-3 Jahren mit Micropython (MPY) auf ESP8266/ESP32 
angefangen und habe echt Spass damit!
Ich cross-compile auf WSL2 unter Docker den gesamten MPY Core, meine 
eigenen Libraies und den eigentlichen Applikation Source Code.

Ich denke, ich habe bis jetzt vielleicht so 30% von Python kapiert und 
verwendet. Ich glaube, dass ich die nächsten Jahre mit Python 
beschäftigt bin, auch weil Python z.B. Metaprogrammierung kennt.

In MPY HW-nah zu programmieren ist kein Problem, wenn man erstmal 
kapiert hat, wie das geht. Dazu schaut man sich z.B. mal die in Python 
geschriebenen Quellen der Libraries an und lernt von diesen.

In MPY kannst du aber auch eigene Funktionen in C/C++ schreiben, 
vorausgesetzt, du hast die Tool chain am laufen, um alles zusammen zu 
übersetzen.

Die Möglichkeiten in Python Daten schnell beliebig zu 
transformieren/manipulieren anhand von komplexen Regelwerken ist genial, 
da erschein mir, verblasst C++ recht schnell.

Platt ausgedrückt, für 30 Zeilen in Python benötigt C++ für das selbe 
Problem vielleicht 100-200 Zeilen - echt irre!
ABER man muss die vielen Möglichkeit von Python auch recht gut kennen 
und das kann sehr lange dauern. Wie gesagt, ich stehe erst bei +- 30% 
oder so.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Apollo M. schrieb:
> für 30 Zeilen in Python benötigt C++ für das selbe
> Problem vielleicht 100-200 Zeilen - echt irre!

Syntactic sugar aber nicht mehr.

Beitrag #6685933 wurde von einem Moderator gelöscht.
von W.S. (Gast)


Lesenswert?

Hercules H. schrieb:
> Meisten waren es nur Kleinigkeiten, z.b LC
> Display zum laufen bringen, oder eine einfache Steuerung einiger LED's.
> Dies habe ich bisher in C gemacht, allerdings auch manchmal mit Mühe, da
> es mir nicht ganz so einfach viel dies passenden Bibliotheken zu finden.

Ah, du bist also einer, der vornehmlich Bibliotheken zusannenstöpselt. 
Na, dann ist Python wohl genau das Richtige für dich. Also freunde dich 
damit an - Python ist vermutlich leichter zu lernen als z.b. LUA.

W.S.

von Stefan F. (stefanus)


Lesenswert?

Apollo M. schrieb:
> In MPY kannst du aber auch eigene Funktionen in C/C++ schreiben,
> vorausgesetzt, du hast die Tool chain am laufen, um alles zusammen zu
> übersetzen.

Aber wer will das schon? Ein Projekt aus mehreren Programmiersprache zu 
kombinieren ist immer hässlich.

Ich finde das Argument "Python kann alles, weil Python kann C" irgendwie 
absurd. Wenn ich mich auf Python verlasse, weil ich ja notfalls auch C 
kann, warum programmiere ich dann nicht direkt in C (oder C++)?

Klar, Python hat stärken bei High-Level Bibliotheken. Aber ist das auf 
µC wirklich ein großer Vorteil? So groß, dass ich mir zwei Sprachen 
antun mus?

von Jack V. (jackv)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich finde das Argument "Python kann alles, weil Python kann C" irgendwie
> absurd. Wenn ich mich auf Python verlasse, weil ich ja notfalls auch C
> kann, warum programmiere ich dann nicht direkt in C (oder C++)?

Warum du‘s nicht machst, weiß ich nicht.

Ich mach’s nicht, weil ich meinen Kram (Einzelstücke, Bastlerniveau und 
ohne Kunden) so schneller und vor Allem erheblich bequemer 
zusammenbekomme (direktes Ausprobieren auf dem Board ohne den 
„kompilieren → hochschieben → debuggen → ändern → kompilieren → 
hochschieben → […]“-Zyklus), und nur zeit- oder sonstwie 
ressourcenkritische Sachen, die üblicherweise einen überschaubaren 
Umfang haben (wenn sie denn überhaupt notwending sind), in C oder ASM 
bauen und dranstecken muss.

Für jemanden, der jeden Tag damit arbeitet, mag das vielleicht nicht 
ganz nachvollziehbar sein, aber wer „nur“ von Zeit zu Zeit ein Projekt 
hat, bei dem ein μC mit Logik beschickt werden muss, wird möglicherweise 
eine Idee haben, warum Python nicht so schlecht ist.

von Stefan F. (stefanus)


Lesenswert?

Jack V. schrieb:
>> warum programmiere ich dann nicht direkt in C (oder C++)?
> Warum du‘s nicht machst, weiß ich nicht.

Irrtum, ich programmiere Mikrocontroller in C und manchmal in C++.

: Bearbeitet durch User
von Andreas H. (ahz)


Lesenswert?

Stefan ⛄ F. schrieb:
> Andreas H. schrieb:
>> Klingt nicht wirklich nach einem guten Plan
>
> So läuft es leider oft in der Praxis.

Ja, ich weiss :/

Und das was Du von Deinem Job schreibst habe ich auch schon oft genug 
selber erlebt.
Darum bin ich ja auch so grantelig wenn ich sowas lese wie "hat der 
Student ganz schnell gemacht".

/regards

von Stefan F. (stefanus)


Lesenswert?

Andreas H. schrieb:
> was Du von Deinem Job schreibst habe ich auch schon oft genug selber erlebt.
> Darum bin ich ja auch so grantelig wenn ich sowas lese wie "hat der
> Student ganz schnell gemacht".

Anderseits werden wir dafür gut bezahlt. Wenn ich sehe, wie manch 
anderer trotz Mindestlohn herum gescheucht wird ... es ist eine Schande.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Stefan ⛄ F. schrieb:
> Aber wer will das schon? Ein Projekt aus mehreren Programmiersprache zu
> kombinieren ist immer hässlich.

Ist doch auch in C/C++ Thema, wenn ASM Funktioen zum optimieren 
(Runtime, Size) eingebaut werden. Aus dem selben Grund baue ich manchmal 
und nur dann C/C++ Funktionen ein.

> Ich finde das Argument "Python kann alles, weil Python kann C" irgendwie
> absurd. Wenn ich mich auf Python verlasse, weil ich ja notfalls auch C
> kann, warum programmiere ich dann nicht direkt in C (oder C++)?

Das war nicht mein Argument.

> Klar, Python hat stärken bei High-Level Bibliotheken. Aber ist das auf
> µC wirklich ein großer Vorteil? So groß, dass ich mir zwei Sprachen
> antun mus?

Mein letztes Project - multi-face Clock mit allen möglichen Environment 
Sensors (Weather Station) hat davon sehr profitiert bzw. der statisch 
relevanten Datenverarbeitung, -speicherung und dem Reporting sowie der 
Grenzwertüberwachung.

Das Project hatte ich zuvor schonmal bzgl. multi-face Clock und reine 
Sensordatenerfassung in C/C++ relalisiert.
Aber die weitere Sensor-Datenverarbeitung sowie 
-verteilung/-serveranbindung war mir zu anstrengend in C/C++.

Ich dachte gute Gelegenheit um mal Micropython auszuprobieren, aber mein 
Anfang war schwer und schmerzhaft - ich hatte wenig Ahnung von 
OO-Programmierung
Ich habe zuerst meinen vorhandenen C-Code in "einfachste" Python Syntax 
übersetzt und dann viel später schrittweise den pythonic Approach 
realisiert.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Jack V. schrieb:
> so schneller und vor Allem erheblich bequemer
> zusammenbekomme (direktes Ausprobieren auf dem Board ohne den
> „kompilieren → hochschieben → debuggen → ändern → kompilieren →
> hochschieben → […]“-Zyklus),

Ich debug nur die HW-Driver auf dem Board ansonsten mache ich alles 
unter PyCharm oder auch VSC und habe z.B. Python-Funktionen um einfache 
IO-HW zu simulieren - wie 8x8 LED Matrix mit MAX7219 ...
Ansonsten habe ich ein bash script (das erste Mal!) geschrieben, das auf 
Knopfdruck unter W10/WSL2 alles durchzieht 
compilieren/Flash-Erease/UpLoad/Terminal-Start.

Ich mache das nur, aus Spass an der Freude, um mal wieder was zu lernen 
...

von Nur_ein_Typ (Gast)


Lesenswert?

Apollo M. schrieb:
> Ich mache das nur, aus Spass an der Freude, um mal wieder was zu lernen
> ...

Es ist schon lustig, daß alle, die Micropython mal ausprobiert haben, es 
recht nützlich und cool finden, während die forenüblichen Trolle und 
Miesmacher kein einziges valides Sachargument, sondern nur Gepöbel und 
dämliches Gesabbel wie "sowas macht man einfach nicht" zu bieten haben. 
Oder das großartige "aber für MICH...", als ob ihre Irrelevanz ein 
Maßstab sei...

von Stefan F. (stefanus)


Lesenswert?

Nur_ein_Typ schrieb:
> Es ist schon lustig, daß alle, die Micropython mal ausprobiert haben, es
> recht nützlich und cool finden, während die forenüblichen Trolle und
> Miesmacher kein einziges valides Sachargument, sondern nur Gepöbel und
> dämliches Gesabbel wie "sowas macht man einfach nicht" zu bieten haben.

Du scherst da "alle" über einen Kamm, als ob es nur zwei Schubladen für 
sie gäbe.

von Nur_ein_Typ (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Du scherst da "alle" über einen Kamm, als ob es nur zwei Schubladen für
> sie gäbe.

Okay, stimmt, Du hast auf das Gepöbel, die Provokationen und das 
Selbstherrliche weitestgehend verzichtet, aber Du warst auch mit den 
"forenüblichen Miesmachern und Trollen" auch gar nicht gemeint. 
Allerdings hast Du außer "das macht man nicht", "wozu soll das gut sein" 
"ich kann C/C++" und "also brauch ich das nicht" diesmal leider auch 
nicht allzu viel Sinn- oder Gehaltvolles beigetragen, oder?

von Stefan F. (stefanus)


Lesenswert?

Nur_ein_Typ schrieb:
> Allerdings hast Du außer "das macht man nicht", "wozu soll das gut sein"
> "ich kann C/C++" und "also brauch ich das nicht" diesmal leider auch
> nicht allzu viel Sinn- oder Gehaltvolles beigetragen, oder?

Es ist halt so, dass ich wenig Sinn darin sehe, Python auf einem 
Mikrocontroller einzusetzen. Das ist meine Antwort zu

> Würdet ihr es empfehlen, klappt das gut?

Meine begründete nicht-Empfehlung ist eine sinnvoller Beitrag im Sinne 
der Frage. Das wir hier niemals alle der gleichen Meinung sein werden, 
oder uns auf eine gemeinsame Abschlusserklärung einigen werden, ist 
sowieso klar.

: Bearbeitet durch User
von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Hercules H. schrieb:
> Daher würde ich gerne einiges von euch hören wollen.
> Würdet ihr es empfehlen, klappt das gut?

Ich empfehle Micropython ohne Einschränkung und denke man hat damit 
richtig viel Spaß!
Die verfügbaren HW Plattformen, auf denen MPY läuft, sind ja sehr 
überschaubar. Somit sehe ich da keinen Ausschluss im Sinne MPY oder 
C/C++.

: Bearbeitet durch User
von Nur_ein_Typ (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Nur_ein_Typ schrieb:
>> Allerdings hast Du außer "das macht man nicht", "wozu soll das gut sein"
>> "ich kann C/C++" und "also brauch ich das nicht" diesmal leider auch
>> nicht allzu viel Sinn- oder Gehaltvolles beigetragen, oder?
>
> Es ist halt so, dass ich wenig Sinn darin sehe, Python auf einem
> Mikrocontroller einzusetzen.

Hast Du es denn ausprobiert? Wenn nicht, sind Deine Empfehlungen nun 
einmal keine Erfahrungsberichte und nicht tatsachenbasiert, sondern eine 
lediglich auf Deinen Vorurteilen und Gefühlten beruhende 
Meinungsäußerung.

> Das ist meine Antwort zu
>
>> Würdet ihr es empfehlen, klappt das gut?
>
> Meine begründete nicht-Empfehlung ist eine sinnvoller Beitrag im Sinne
> der Frage.

Wie gesagt: das mag ja gerne Deine Meinung sein, beruht aber lediglich 
auf Deinen eigenen Vorurteilen und Gefühlen. Bei Dir bin ich mit 
vergleichsweise sicher, daß Du vernünftig und professionell genug bist, 
das selbst zu erkennen, und daß Du Deine Voruteile, Gefühle und Deine 
darauf fußende Meinung als genau solche zu verstehen und bei Bedarf zu 
hinterfragen.

Im Übrigen ist ein ausgesprochen sinnvoller Anwendungsbereich in diesem 
Thread leider noch gar nicht beleuchtet worden, nämlich das Prototyping. 
Häufig ist es eine sehr gute Idee, einem Kunden bereits frühzeitig einen 
funktionsfähigen Prototypen zu demonstrieren, so lassen sich Probleme 
bei der Entwicklung schon frühzeitig erkennen und mit relativ geringen 
Aufwänden und Kosten korrigieren. Genauso kann es oft sinnvoll sein, 
früh einen Prototypen zu haben, mit dem die Kollegen arbeiten können, 
welche die anderen Bestandteile eines Gesamtprodukts entwickeln. In 
solchen Fällen kann eine Erstimplementierung in Micropython sehr 
sinnvoll sein. Während dann nach und nach zuerst die 
performancekritischen und danach andere Teile als C-Module für 
Micropython reimplementiert werden, können die Kunden und / oder 
Kollegen bereits mit den Prototypen arbeiten. Am Ende, wenn alle Module 
in C reimplementiert sind, wird der übrige Glue-Code von Python auf C 
oder C++ portiert. Zu diesem Zeitpunkt haben die Hardware-Entwickler 
meist schon ein sehr viel genaueres Bild davon, was die letztendliche 
C/C++-Implementierung tatsächlich an Hardware benötigt.

> Das wir hier niemals alle der gleichen Meinung sein werden,
> oder uns auf eine gemeinsame Abschlusserklärung einigen werden, ist
> sowieso klar.

Wie gesagt: es gibt erhebliche Unterschiede zwischen dem Wert einer 
Meinung, die ausschließlich auf Vorurteilen und Gefühlen basiert, und 
einer Ansicht, die sich auf reale Erfahrungen im praktischen Einsatz 
stützen kann. Und wenn diese beiden sich gegenseitig widersprechen, 
neige ich persönlich dazu, mich an jene Aussagen zu halten, die sich auf 
praktische Erfahrungen stützen können. Mal ehrlich: das machst Du doch 
hoffentlich ganz genauso, oder?

von Stefan F. (stefanus)


Lesenswert?

Nur_ein_Typ schrieb:
> Hast Du es denn ausprobiert? Wenn nicht, sind Deine Empfehlungen nun
> einmal keine Erfahrungsberichte und nicht tatsachenbasiert, sondern eine
> lediglich auf Deinen Vorurteilen und Gefühlten beruhende
> Meinungsäußerung.

Ich habe nicht behauptet, dass ich damit Erfahrung habe. Es war ganz 
klar eine Meinung.

> Wie gesagt: das mag ja gerne Deine Meinung sein,

Siehst du, es war klar.

Die Sache ist die: ich habe damit keine Erfahrung, weil MicroPython gar 
nicht auf den Mikrocontrollern laufen kann, mit denen ich mich 
beschäftige. Die sind dafür zu klein.

Wer geeignete Mikrocontroller verwendet, der darf gerne auf andere 
Meinungen hören. Damit habe ich überhaupt kein Problem.

Ich kenne allerdings Python von meiner kommerziellen Arbeit an Odoo. 
Insofern bin ich nicht völlig ahnungslos.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Andreas H. schrieb:
> xyz schrieb:
>> 0.1 s sind fuer eine CPU eine Ewigkeit.
>> Du bist nur zu doof die Zeit exakt zu messen.
>
> Dann erklär es ihm doch mal bitte.

Das kann er natürlich nicht -- große Klappe, nix dahinter... ;-)

Tatsache ist: ich habe das oben gezeigte Programm fünfmal hintereinander 
auf derselben Hardware ausgeführt, und die Ausführungszeiten lagen alle 
zwischen 0.037 und 0.089 Sekunden -- der schlechteste Wert war mehr als 
doppelt so groß wie der beste. Das sagt mir: diese Meßergebnisse sind 
absolut sinnlos und nicht aussagekräftig. Bestenfalls zeigen sie nur 
eine grundsätzliche Tendenz.

Natürlich könnte ich etwas sinnvollere Ergebnisse erzeugen, indem ich 
mein System in den Single-User-Modus boote, dem Kernel über den 
Bootparameter "isolcpus" sage daß der Prozeßscheduler die so genannten 
CPU-Kerne nicht mit Prozessen beschicken soll, und das Progrämmchen dann 
mit taskset(1) an eben diese CPU-Kernen binden.

Zudem ließen sich auch noch einige nifty tricks mit nice(1), ionice(1) 
und/oder chrt(1) nutzen, um dem Progrämmchen auch sonst die maximale 
Priorität zu geben und so eine wesentlich konstantere Laufzeit zu 
erreichen.

Oder ich weise den Kernel mit dem Parameter "init" an, das betreffende 
Programm anstelle des Initprozesses auszuführen. Dann laufen auf dem 
ganzen Rechner nur noch ein paar Kernelthreads und natürlich das 
betreffende Programm.

Eine andere Möglichkeit wäre das Python-Standardmodul "timeit", das das 
Programm einfach n-Mal ausführt und die Ausführungszeiten wahlweise mit 
time.perf_counter oder mit time.process_time mißt. Aber das wäre 
natürlich unfair, weil Frank und Yalu für ihre Messungen vermutlich das 
Bash-Builtin "time" oder das "richtige" Programm time(1) benutzt, und 
deswegen auch die Startup- und Shutdownzeiten des Python-Interpreters 
mitgemessen haben. (Auch dabei hätte ich noch ein bisschen pfuschen 
können, indem ich den Interpreter vorher einmal aufrufe und so dafür 
sorge, daß das Binary und die Libraries bereits im FS-Puffer sind, aber 
diesen habe ich wohlweislich vor jedem Aufruf geleert.)

Am Ende ließen sich diese Möglichkeiten auch wunderbar miteinander 
kombinieren, allein: entgegen der großmäuligen Annahme unseres 
Vorposters bin ich keineswegs doof, sondern nur ausgesprochen faul. 
Faulheit ist übrigens laut Larry Wall, dem Schöpfer von Perl, eine der 
vier Kardinaltugenden guter Entwickler. Trotzdem möchte ich gern noch 
darauf hinweisen, daß es mir nicht um präzise Messungen, sondern um 
etwas ganz anderes ging: nämlich darum, zwei Aspekte zu zeigen.

Nämlich erstens, daß unser hochgeschätzter Mitforist Frank nur einen 
bestimmten Interpreter getestet hat, während andere eine Interpreter mit 
demselben Code eine viel höhere Performance zeigen. Sowie zweitens, daß 
Frank nur einen bestimmten und offenbar nicht besonders performanten 
Algorithmus getestet hat, während ein anderer Algorithmus dasselbe 
Ergebnis erzeugt und trotzdem um Größenordnungen performanter ist.

Diese beiden Punkte sind der Grund dafür, weshalb solche Performanztests 
fast immer nur die Annahmen des Testenden überprüfen, jedoch nur sehr, 
sehr selten valide Aussagen über eine Programmiersprache zulassen.

von Sheeva P. (sheevaplug)


Lesenswert?

Rainer V. schrieb:
> Die jetzt massig verbreiteten Sketche in C oder C+
> oder was auch immer, sprechen doch genau die Leute an, die erst noch
> Bastler werden wollen. Und die lernen eben was ganz anderes als die
> Generationen vor ihnen.

Ja, das stimmt. Mein Wissen stammt im Wesentlichen noch aus diesen 
komischen Dingern aus totem Holz, aus viel Spielerei und aus noch mehr 
Erfahrung.

Aber vor knapp zwei Jahren haben wir einen neuen Azubi bekommen. Mit 25 
Jahren und einem Meisterbrief als Metzger in der Tasche hat er seinen 
Eltern dann erklärt, daß er den elterlichen Betrieb jetzt zwar 
fortführen könne, jetzt aber bitte erstmal etwas machen wolle, das ihm 
wirklich Spaß macht. Oh...

Nun, der junge Mann hat sich mittlerweile als ausgesprochen motiviert, 
intelligent und extrem wißbegierig erwiesen. Der lernt ganz anders als 
unsereins damals: sieht sich einige Videos auf Youtube an, spielt dabei 
herum und liest in der Doku, wenn er etwas nicht verstanden hat oder 
genauer wissen will.

Und ich muß sagen, daß ich wirklich tief beeindruckt bin, wie schnell 
der junge Mann auch komplizierte Dinge auf diese Weise lernt und 
versteht. Bewegte Bilder scheinen eine gute Möglichkeit zu sein, 
technische Inhalte zu vermitteln... ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ich denke auch dass die Programmiersprache Python an sich nichts ist,
> was mir Freudentränen in die Augen bringt.

Bringen C, C++, Pascal, Rust, Go, Fortran, Haskell, Cobol oder andere 
Werkzeuge Dir denn die Freudentränen in die Augen? ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Andreas H. schrieb:
> Und wer macht den Support wenn der Student wieder weg ist? Wer fixt
> Bugs, ggf auch im MicroPython?

Entschuldige bitte, daß es gerade Dich trifft, aber dieser FUD wegen 
angeblicher Bugs in (Micro-)Python kam ja jetzt schon mehrmals, und ich 
frage mich ernsthaft, welcher erfahrene Entwickler so etwas schreiben 
kann...

Klar, jede Software hat Bugs. Aber gut gepflegte und vielfach benutzte 
Libraries haben meiner Erfahrung nach weniger Fehler, sind flexibler und 
erweiterbarer als selbstgestricktes Zeugs. Und man muß sie nicht selbst 
pflegen -- das ist dort wo Softwareentwicklung Geld kostet ein enormer 
Vorteil.

Und, nebenbei bemerkt, haben wir zwar auch unsere "Studenten", aber 
keiner davon darf irgendeine neue Technologie mitbringen, ohne 
mindestens zwei von unseren erfahrenen Entwickler an die Seite gestellt 
zu bekommen, die er mitnehmen und in seine Technologien einführen zu 
müssen.

von Sheeva P. (sheevaplug)


Lesenswert?

Cyblord -. schrieb:
> Apollo M. schrieb:
>> für 30 Zeilen in Python benötigt C++ für das selbe
>> Problem vielleicht 100-200 Zeilen - echt irre!
>
> Syntactic sugar aber nicht mehr.

Also ein schlechter Verlierer ohne Sinn für Ökonomie.

von Sheeva P. (sheevaplug)


Lesenswert?

W.S. schrieb:
> Ah, du bist also einer, der vornehmlich Bibliotheken zusannenstöpselt.
> Na, dann ist Python wohl genau das Richtige für dich. Also freunde dich
> damit an - Python ist vermutlich leichter zu lernen als z.b. LUA.

Noch so ein schlechter Verlierer ohne Sinn für Ökonomie...

von Sheeva P. (sheevaplug)


Lesenswert?

Stefan ⛄ F. schrieb:
> Ein Projekt aus mehreren Programmiersprache zu
> kombinieren ist immer hässlich.

Aber wirtschaftlich oft absolut sinnvoll. Mein Arbeitgeber entwicklelt 
eine etwas umfangreichere Suite aus Werkzeugen zur Datenanalyse, die im 
Wesentlichen für die Echtzeit-Betrugsprävention bei Banken und 
Versicherungen genutzt wird. Dabei ist die Serverkomponente eine 
Java-Applikation mit einem C++-Rechenkern...

von dfIas (Gast)


Lesenswert?

Sheeva P. schrieb:
> Mein Arbeitgeber entwicklelt [...]
Darfst du Betriebsinterna einfach so ausplaudern? Ich halte gerade 
diesen Sektor für äußerst sensibel.

von Sheeva P. (sheevaplug)


Lesenswert?

dfIas schrieb:
> Sheeva P. schrieb:
>> Mein Arbeitgeber entwicklelt [...]
>
> Darfst du Betriebsinterna einfach so ausplaudern?

Ja, natürlich. Sonst würde ich das ja nicht tun.

> Ich halte gerade diesen Sektor für äußerst sensibel.

Ja, ist er ;-)

von John L. (johnli)


Lesenswert?

Ich benutze am meisten c, die meiste Zeit verwende ich arduino und 
einige andere Mikrocontroller.

von chris_ (Gast)


Lesenswert?

SheevaPlug
>Und ich muß sagen, daß ich wirklich tief beeindruckt bin, wie schnell
>der junge Mann auch komplizierte Dinge auf diese Weise lernt und
>versteht. Bewegte Bilder scheinen eine gute Möglichkeit zu sein,
>technische Inhalte zu vermitteln... ;-)

Da sprichst Du etwas Wahres an: Die heutigen Möglichkeiten für 
autodidaktisches Lernen sind wirklich grandios und für Leute die das 
gerne machen ist es ein Schlaraffenland. Vor 30 Jahren hatte ich immer 
nur ein Buch über ein Thema und es war entweder so gut beschrieben, dass 
man es verstehen konnte oder man musste ewig rätseln. Heute schaut man 
sich einfach Youtube-Videos an und wenn es in einem nicht gut erklärt 
ist, kann man einfach eine besseres suchen. Didaktische Fähigkeiten 
waren schon früher nicht jedem Lehrer gegeben und wenn man sich den 
besten aussuchen kann, ist das phantastisch.
Ich schaue mir manchmal über mehrere Tage sehr viele Videos zu einem 
Thema an und es bleibt immer was hängen, selbst wenn man schon müde ist.

von Stefan F. (stefanus)


Lesenswert?

Sheeva P. schrieb:
>> Ich denke auch dass die Programmiersprache Python an sich nichts ist,
>> was mir Freudentränen in die Augen bringt.

> Bringen C, C++, Pascal, Rust, Go, Fortran, Haskell, Cobol oder andere
> Werkzeuge Dir denn die Freudentränen in die Augen? ;-)

Gute Frage!

Warnung: Wer sich nicht für PC Programmierung interessiert möge diesen 
Beitrag bitte ignorieren.

Von den genannten Spracen kenne ich nur C, C++ und Pascal. Wie du schon 
ahntest, auch diese Sprachen erfreuen mich nicht wirklich. Bei C 
vermisse ich Mittel zur ordentlichen Strukturierung großer Projekte. 
Womit wir zu den beiden Objektorientierten Sprachen kommen.

Von Pascal hatte ich mich in den 90er Jahren wieder abgewendet, weil die 
Doku zur Windows API damals immer C/C++ Beispiele enthielt und ich 
dadurch gezwungen war, immer zu übersetzen. Dazu kam, dass unsere Kunden 
das Look&Feel der Borland GUI ablehnten. Dann kann ich auch gleich in 
Visual C++ programmieren, was ich dann auch tat.

C++ gibt mir das Gefühl, akademisch aufgebläht zu sein. Man hat da 
lauter kompliziertes Zeugs eingebaut, dass ich nie brauchte. Dazu kommt 
die ewige Abwärtskompatibilität zu alten Versionen und auch zu C. Wenn 
ich alleine daran denke, wie uneindeutig "static" ist, wird mir übel. 
Und Operatorüberladung scheint mir so unnötig, wie ein Pickel am 
Hintern. jedes mal, wennn ein Operator nicht das tut, was ich erwarte, 
frage ich mich, warum man nicht einfach eine normale Methode geschrieben 
hat. Zum Beispiel addItem(), addAllItems(), addIfNotExist() und 
addIfNotNull() anstelle von "<<". Sprechende namen finde ich 10x besser, 
als kryptische Operatoren. Die Art und Weise wie Shift-Operatoren von 
std::cout missbraucht wurden, jagt mir immer wieder einen kalten Schauer 
ein.

Aber immerhin laufen die Programme stabil und schnell, wenn man sich 
damit abgefunden hat.

Go habe ich evaluiert aber noch nicht kommerziell genutzt. Mein erster 
Eindruck war, dass sich das wohl ein ehemaliger C++ Entwickler 
ausgedacht hat, der mit den ganzen Hässlichen Entlein und übermäßig 
komplexen Konstrukten aufräumen wollte. Teilweise fragte man sich dann: 
"reicht das, fehlt da nicht was"? Existierende Projekte beweisen, dass 
der Umfang dieser stark reduzierten Sprache tatsächlich reicht. Die 
Kröte muss man erstmal schlucken, wenn man sich vorher an 
C++/Java/Pascal gewöhnt hatte.

Was ich bei Go nicht gut finde, sind folgende zwei Punkte:

1) Keine konsequente Verwendung von Unicode-Strings. Teilweise werden 
sie als Folge von Bytes behandelt, teilweise als Unicode Zeichen. Damit 
erreicht man zwar eine "bessere" Performance aber auch mehr Verwirrung 
und potentielle Fehler - was der Designer der Sprache nach eigener 
Aussage unbedingt vermeiden wollte. Hier würde ich sagen, dass er sein 
ziel ziemlich stark verfehlt hat.

2) Arrays versus Slices. Da gibt es kleine gemeine Unterschiede bei der 
Übergabe als Funktions-Parameter. Warum man slices nicht verlängern kann 
(ohne ein neues Object zu erzeugen), das wüsste ich auch gerne mal.

Zu Java könnte ich einen sehr langen Roman schreiben, was mir da alles 
auf die Nerven geht. Denn damit habe ich mit weitem Abstand die meiste 
Erfahrung. Andererseits verdiene ich mit Java recht effizient mein 
täglich Brot. Das ist letztendlich wichtiger, als die Eleganz der 
Sprache.

Aber lass uns mal auf Mikrocontroller zurück kommen und auf die dort 
relevanten Sprachen beschränken.

von Andreas H. (ahz)


Lesenswert?

Sheeva P. schrieb:
> Andreas H. schrieb:
>> xyz schrieb:
>>> 0.1 s sind fuer eine CPU eine Ewigkeit.
>>> Du bist nur zu doof die Zeit exakt zu messen.
>>
>> Dann erklär es ihm doch mal bitte.
>
> Das kann er natürlich nicht -- große Klappe, nix dahinter... ;-)
>

Darum ja auch meine Frage ;)

Das Du in der Lage bist sowas zu messen und Deine Aussage sinnvoll 
begründet ist, davon bin ich ausgegangen. Ist ja nicht der erste Post 
den ich von Dir gelesen habe.

/regards

von Andreas H. (ahz)


Lesenswert?

Sheeva P. schrieb:
> Andreas H. schrieb:
>> Und wer macht den Support wenn der Student wieder weg ist? Wer fixt
>> Bugs, ggf auch im MicroPython?
>
> Entschuldige bitte, daß es gerade Dich trifft, aber dieser FUD wegen
> angeblicher Bugs in (Micro-)Python kam ja jetzt schon mehrmals, und ich
> frage mich ernsthaft, welcher erfahrene Entwickler so etwas schreiben
> kann...

Kein Problem, ich bin da hart im nehmen ;)

Diese Frage ist das allererste was einem unsere GL um die Ohren haut, 
wenn man mit so einem Vorschlag kommst. Und man kann es, zumindest 
teilweise, sogar nachvollziehen. Die GL rechnet einfach mit potentiellen 
Hürden und den daraus entstehenden Kosten. Dann sind andere Alternativen 
oft günstiger.

> Und, nebenbei bemerkt, haben wir zwar auch unsere "Studenten", aber
> keiner davon darf irgendeine neue Technologie mitbringen, ohne
> mindestens zwei von unseren erfahrenen Entwickler an die Seite gestellt
> zu bekommen, die er mitnehmen und in seine Technologien einführen zu
> müssen.

Ja, so macht es ja auch Sinn. Dann sind Eure erfahrenen (!) Entwickler 
dafür eingeplant und können beurteilen ob die neue Idee brauchbar ist.
Wenn ja, dann sind sie schon gut damit vertraut und das Wissen 
verschwindet nicht "magisch", wenn der Student ausscheidet.
Wenn es sich als unbrauchbar herausstellt, dann hat man kalkulierte 
Kosten gehabt, die aber vorher bereits geplant und abgesegnet waren.

/regards

von Sheeva P. (sheevaplug)


Lesenswert?

Stefan ⛄ F. schrieb:
> Sheeva P. schrieb:
>> Bringen C, C++, Pascal, Rust, Go, Fortran, Haskell, Cobol oder andere
>> Werkzeuge Dir denn die Freudentränen in die Augen? ;-)
>
> Gute Frage!

Auch ein blindes Huhn findet mal ein Korn, ne... ;-)

> Von den genannten Spracen kenne ich nur C, C++ und Pascal. Wie du schon
> ahntest, auch diese Sprachen erfreuen mich nicht wirklich.

Letzten Endes findet man an jeder Sprache etwas, das nicht so schön 
ist... Und letztlich ist das der Punkt, auf den ich hinaus wollte. Eine 
Sprache ist ja am Ende nur ein Werkzeug mit -- ich stelle mal ein 
Schälchen Allgemeinplätzchen auf den Tisch des Hauses -- spezifischen 
Stärken und Schwächen.

Ich kannte mal Perl (das immerhin viele Jahre lang meine 
Standardskriptsprache war, bis ich Python für mich entdeckt habe), das 
war nett und hatte eine prima Infrastruktur mit dem CPAN, aber aus 
meiner heutigen Sicht krankt es an einer Schwäche, die es mit Ruby 
teilt: den eingebauten Regular Expressions, mit denen man unglaublich 
schlecht lesbaren Code schreiben kann. Und bei Perl kamen dann noch die 
Unsicherheiten wegen Perl6 und die krude OO-Syntax hinzu...

Vor Jahrzehnten hab' ich auch mal Visual Basic und PHP benutzt, konnte 
mich aber nie mit deren Syntax und bei VB mit den Werkzeugen anfreunden, 
und bei PHP gab es damals so viele Designfehler... die OO von Java, die 
Stringfunktionen von C (ausgerechnet!), und alles in einem riesigen, 
globalen Namensraum... brrr! :-(

> Von Pascal hatte ich mich in den 90er Jahren wieder abgewendet, weil die
> Doku zur Windows API damals immer C/C++ Beispiele enthielt und ich
> dadurch gezwungen war, immer zu übersetzen.

Pascal sollte ich in der Schule lernen, aber da konnte ich schon C... 
insofern empfand ich die Syntax als unelegant, und damals gab es nur 
kommerzielle Tools, für die ich kein Geld hätte ausgeben wollen... oder 
können. ;-)

> C++ gibt mir das Gefühl, akademisch aufgebläht zu sein. Man hat da
> lauter kompliziertes Zeugs eingebaut, dass ich nie brauchte. Dazu kommt
> die ewige Abwärtskompatibilität zu alten Versionen und auch zu C. Wenn
> ich alleine daran denke, wie uneindeutig "static" ist, wird mir übel.

Ja...

> Und Operatorüberladung scheint mir so unnötig, wie ein Pickel am
> Hintern. jedes mal, wennn ein Operator nicht das tut, was ich erwarte,

Das wiederum sehe ich etwas anders, sorry. Wenn ein Operator nicht tut, 
was Du erwartest, dann hat derjenige, der das implementiert hat, Mist 
gemacht. Und es kann manchmal echt schick sein und sehr lesbaren Code 
produzieren, zusätzlich zu einer Funktion einen Operator zu überladen 
-- zum Beispiel operator<< und operator>> für Ein- und 
Ausgabeoperationen auf Streams, oder "+" und "-" um Produkte zu einem 
Warenkorb hinzuzufügen oder sie daraus zu entfernen. Aber natürlich, 
Operatorenüberladung ist ein sehr mächtiges Feature, das viel zu häufig 
mißbraucht wird... weil man's ja kann(?!).

In Python kann man mit Operatorenüberladung übrigens eine Reihe sehr 
hübscher Sachen manchen, und da sehe ich irreführende Verwendungen auch 
nur sehr, sehr selten -- warum auch immer.

> Zu Java könnte ich einen sehr langen Roman schreiben, was mir da alles
> auf die Nerven geht.

Sei mir nicht böse, aber das finde ich ähnlich akademisiert wie C++ -- 
okay, nur ohne die vermaledeite Abwärtskompatibilität zu C. Immerhin 
haben sie es nach über zwanzig Jahren endlich geschafft, einen halbwegs 
brauchbaren Garbage Collector zu entwickeln, der kein "Stop the World" 
macht, keine Memory Leaks hat, und zudem in einer halbwegs annehmbaren 
Zeit abläuft. Aber okay, mein Urteil über Java ist von meiner 
persönlichen Geschichte verfälscht -- als Java entwickelt wurde, war ich 
bei Sun Microsystems, und habe es (sehr zum Leidwesen meiner 
Vorgesetzten) schon damals für einen Irrweg gehalten... :-(

von Sheeva P. (sheevaplug)


Lesenswert?

Andreas H. schrieb:
> Das Du in der Lage bist sowas zu messen und Deine Aussage sinnvoll
> begründet ist, davon bin ich ausgegangen. Ist ja nicht der erste Post
> den ich von Dir gelesen habe.

Lieben Dank für das tolle Kompliment. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Andreas H. schrieb:
> Kein Problem, ich bin da hart im nehmen ;)

Danke! ;-)

> Diese Frage ist das allererste was einem unsere GL um die Ohren haut,
> wenn man mit so einem Vorschlag kommst. Und man kann es, zumindest
> teilweise, sogar nachvollziehen. Die GL rechnet einfach mit potentiellen
> Hürden und den daraus entstehenden Kosten. Dann sind andere Alternativen
> oft günstiger.

Najaaa... so waren meine Vorgesetzte früher auch, und ich hatte meistens 
das Gefühl, daß da eine gehörige Portion "könnwanich, wollnwanich, 
machnwanich" sowie "das haben wir schon immer so gemacht" hintersteckte 
-- im Prinzip also primär eine Verweigerungshaltung. Wenn sie nämlich 
offen für Veränderung oder gar für Verbesserung gewesen wären, wäre die 
zweite der beiden ersten Fragen gewesen, welche Vorteile das uns und 
unseren Kunden bringen kann.

Aber natülich, am Ende ist sowas natürlich auch eine Frage von Ökonomie 
und Business Continuity -- und da steht OpenSource-Software in der Regel 
deutlich besser da als proprietäre Angebote. Im Zweifelsfall kann man da 
nämlich Fehler selbst korrigieren und sogar das Projekt fortführen, wenn 
es aufgegeben werden sollte. Wobei ich das bei Micropython zumindest in 
der nächsten Zeit für enorm unwahrscheinlich halte, schließlich wird das 
Projekt bei Institutionen wie der European Space Agency genutzt und 
gefördert, sowie beim CERN, der NASA und bei der BBC genutzt.

> Ja, so macht es ja auch Sinn. Dann sind Eure erfahrenen (!) Entwickler
> dafür eingeplant und können beurteilen ob die neue Idee brauchbar ist.
> Wenn ja, dann sind sie schon gut damit vertraut und das Wissen
> verschwindet nicht "magisch", wenn der Student ausscheidet.

Letzten Endes geht es bei sowas ja auch um Business Continuity 
Management. Es kann nicht sein, daß an einem Projekt nicht 
weiterentwickelt werden kann, weil die zuständige Mitarbeiterin mit dem 
Fachwissen gerade in Mutterschutz, krank, ausgeschieden, oder 
schlimmstenfalls sogar verstorben ist. Je nach Unternehmen und 
betroffenem Produkt kann das sogar existenzbedrohlich werden, aber 
seider haben sich derartige Ansichten noch nicht überall verbreitet.

von Stefan F. (stefanus)


Lesenswert?

Sheeva P. schrieb:
> Aber natürlich, Operatorenüberladung ist ein sehr mächtiges Feature

Immerhin muss man nicht alles von C++ benutzen. Man kann auch mit einem 
Bruchteil des Sprachumfangs brauchbare Programme schreiben. Arduino und 
auch das Qt Framework führen es vor.

Sheeva P. schrieb:
>> Zu Java könnte ich einen sehr langen Roman schreiben, was mir da alles
>> auf die Nerven geht.

> Sei mir nicht böse, aber das finde ich ähnlich akademisiert wie C++

Eben!

> als Java entwickelt wurde, war ich bei Sun Microsystems, und
> habe es (sehr zum Leidwesen meiner Vorgesetzten) schon damals
> für einen Irrweg gehalten.

Meine erste Version war 1.2, die sollte ich damals als möglichen 
Nachfolger für Borland Pascal evaluieren als ich meinem Chef den Wechsel 
zu Visual C++ nahelegte. Java war damals für Desktop Hardware (die 
unsere Kunden auch in Servern verwendeten) viel zu klobig und lahm. Ich 
kam erst viele Jahre später wieder zu Java (1.5) als Vodafone es mir 
vorsetzte. Mit 1.6 war dann auch endlich die Performance OK. Aber wie du 
schriebst, bereitete der unberechenbare Garbage Collector Sorgen.

Was man aber sehr schön sehen kann ist, dass Java einen sehr langen 
steinigen Weg hatte, stabil und gut zu werden. Jetzt wo wir endlich so 
weit sind, sprießen rundherum neue Pilze aus dem Boden. Da bin ich schon 
skeptisch, ob diese Pilze wirklich gut sind und Bestand haben.

Ich hab keine Angst davor, eine neue Sprache unnötig zu lernen, sondern 
eher davon, dass ich in 15 Jahren alte Projekte pflegen muss, deren 
Entwicklungstools quasi ausgestorben sind. Wenn man dann irgend eine 
neue komplexe Sache mit Zertifikaten und Verschlüsselung eingebaut 
werden soll, wird es schnell hässlich.

Im Gegensatz dazu bieten mir C/C++ das Gefühl, ewig verfügbar zu sein. 
Die gerade noch kritisierte ewige Abwärtskompatibilität wird plötzlich 
zu einen geschätzten Vorteil. Ich kann es nicht sachlich begründen, aber 
mein Bauch sagt mir, dass man auch in 20 Jahren nicht um C herum kommen 
wird. Es wird noch lange die Basis zahlreicher höherer 
Programmiersprachen bleiben.

Deswegen kann es kein Fehler sein, C zumindest als Zweitsprache zu 
lernen. Und weil das so hardwarenah ist und auf µC manchmal nicht tut, 
was man erwartet, ist ein bisschen Assembler als Drittsprache auch noch 
hilfreich.

: Bearbeitet durch User
von sp103 (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Im Gegensatz dazu bieten mir C/C++ das Gefühl, ewig verfügbar zu sein.
> Die gerade noch kritisierte ewige Abwärtskompatibilität wird plötzlich
> zu einen geschätzten Vorteil. Ich kann es nicht sachlich begründen, aber
> mein Bauch sagt mir, dass man auch in 20 Jahren nicht um C herum kommen
> wird.

Sachliche Begründung: Das größte laufende C Projekt ist 30 Jahre alt und 
es
gibt Organisationen, die im Infrastrukturbereich 50! Jahre lang eine 
bestimmte Version davon pflegen wollen...

> Es wird noch lange die Basis zahlreicher höherer
> Programmiersprachen bleiben.

Hierzu die Frage: Zeichnet sich schon ein noch höher abstrahierender 
Python Nachfolger ab?

Ansonsten Python>C>Assembler>Hardware, je nach 
Entwicklungs/Geschwindigkeits/Latenzanforderungen usw. wie von vielen 
dargelegt: Auf der richtigen Ebene
bleiben.

An den TE: Hardwarebitschubsen mit Python macht (zumindest mir) übrigens 
viel Spass, gerade mit so Dingen wie im OP beschrieben...

von Mucky F. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Die Sprüche, dass C Compiler kaum mehr als primitive Marko-Assembler
> seien, kann ich langsam nicht mehr hören.

Apollo M. schrieb:
> Mucky F. schrieb:
>> C ist imo ein besserer Makroassembler,
>
> Da hier +90% auch nicht wirklich in C programmieren können, erklärt dann
> ansatzweise solche "Einsichten" ...

Das "primitiv" habe ich nicht benutzt. Für mich ist C komplexer als 
viele andere Sprachen. Makroassembler meine ich von der Funktionalität, 
C kann nun mal nativ mit Adressen und Registern und hat auch einen eher 
kleinen "Befehlssatz".

Selber arbeite ich fast nur damit, liegt aber an den Anwendungen und ist 
nicht zu verallgemeinern.

Stefan ⛄ F. schrieb:
> Im Gegensatz dazu bieten mir C/C++ das Gefühl, ewig verfügbar zu sein.

Das ist auch bei mir so. Selbst uralte längst abgekündigte Controller 
lassen sich mit wenig Aufwand auf aktuelle portieren. Das man das meist 
nicht macht weil man seinen eigenen alten Source Code nicht erträgt, 
Neuerungen und Reserven einbaut oder das ganze besser dokumetieren will 
ist dann bei mir die Praxis.

von Framp L. (framp)


Lesenswert?

Als ich das Thread Thema gelesen habe dachte ich nur - oh nicht schon 
wieder ein C vs Python Flame war :-((

Nach zwei Seiten habe ich aufgehoert zu lesen. Es sind immer wieder 
dieselben Argumente :-(

Eine jede Programmiersprache hat ihre Vor- und Nachteile und die sind 
abhaengig vom Einsatzgebiet und von vorhandener Programmiererfahrung.

Warum der TE diesen Thread erstellt hat obwohl es zig tausend Threads im 
Netz zu diesem Thema zu finden sind verstehe ich nicht ganz. Ich habe > 
1E6 Hits bei meiner Suche zu dem Thema gefunden :-D

Mal provokant formuliert: Ein jeder der in diesem Thread antwortet ist 
ein : ><((((*>

von Sheeva P. (sheevaplug)


Lesenswert?

Framp L. schrieb:
> Als ich das Thread Thema gelesen habe dachte ich nur - oh nicht schon
> wieder ein C vs Python Flame war :-((
>
> Nach zwei Seiten habe ich aufgehoert zu lesen.

Das ist schade. Nachdem die Trolle sich erschöpft hatten, wurde das ein 
ebenso gesitteter wie angenehmer Thread.

> Eine jede Programmiersprache hat ihre Vor- und Nachteile und die sind
> abhaengig vom Einsatzgebiet und von vorhandener Programmiererfahrung.

Die Allgemeinplätzchen hatte ich schon auf den Tisch gestellt, aber 
vielen lieben Dank für den Nachschub. ;-)

> Mal provokant formuliert: Ein jeder der in diesem Thread antwortet ist
> ein : ><((((*>

Dann wärst Du aber auch ein Fisch, oder?

von Le Chuck (Gast)


Lesenswert?

>Es wird
>dabei bleiben kleine Elektronik zu steuern, dinge auf einem Display
>anzeigen zu lassen, und wenn es hoch kommt, dann eventuell noch IoT
>Projekte realisieren die vermutlich über meine Handy Steuerung läuft.

Dann würde ich evtl. zu Arduino greifen. Für kleine lokalisierte 
Aufgaben ist das good enough.

von Stefan F. (stefanus)


Lesenswert?

Mir waren die Sprachen mit VM oder Interpreter lange Zeit suspekt, also 
wo die *.exe Datei selbst gar nicht direkt ausführbar war.

Allerdings habe ich mich inzwischen daran gewöhnt, aufgrund der 
zahlreichen alltäglichen Programme, die so aufgebaut sind. Wenn man 
sieht, was JIT Compiler so leisten, kann die Idee gar nicht so schlecht 
sein.

Noch sind Mikrocontroller für JIT Compiler zu klein, aber ich denke das 
wird auch noch irgendwann kommen. Die fortschreitende Standardisierung 
der CPU Kerne in den Mikrocontrollern macht das ja relativ einfach. Es 
ist eigentlich nur noch ein Größenproblem.

von foo (Gast)


Lesenswert?

Hier kann man mit nem virtuellen Rasperry Pi Pico RP2040 spielen:
https://wokwi.com/arduino/projects/297322571959894536  (als arduino)
https://wokwi.com/arduino/new?template=micropython-pi-pico (micropython)

Man kann auch ne *.hex simulieren, im Editor F1 und dann 'load hex' 
tippen...

von Christopher J. (christopher_j23)


Lesenswert?

foo schrieb:
> Hier kann man mit nem virtuellen Rasperry Pi Pico RP2040 spielen

Ich sehe zwar grundsätzlich nur sehr begrenzt einen Sinn hinter solchen 
Simulatoren aber "Hut ab", dass das so schön in einem Webinterface 
läuft.

Stefan ⛄ F. schrieb:
> Noch sind Mikrocontroller für JIT Compiler zu klein, aber ich denke das
> wird auch noch irgendwann kommen.

JIT-Compiler machen meiner Meinung nach auf Microcontrollern überhaupt 
keinen Sinn. JIT macht Sinn, wenn man seinen PC als überdimensionierten 
Taschenrechner mit ständig wechselnden Aufgaben nutzt, siehe etwa Julia 
oder Numba. Auf einem Microcontroller ändert sich die Firmware aber 
nicht ständig sondern eben nur während der Entwicklung, weshalb hier - 
auf Python bezogen - eher "ahead of time"-Compiler Sinn machen und genau 
das kann man mit Micropython auch jetzt schon machen (mittels 
mpy-cross). Am Ende erhält man eine .mpy-Datei, die entweder 
Python-Bytecode oder direkt "native machinecode", sprich ein natives 
Binary, enthält, was wiederum z.B. aus C-Sourcecode generiert wurde. Der 
Vorteil solcher .mpy-Dateien liegt darin begründet, dass man die zur 
Laufzeit dynamisch nachladen kann, ohne die eigentliche Firmware neu zu 
flashen. Der Nachteil ist, dass man für "native machinecode" einige 
Einschränkungen hat, z.B. darf es kein .data Segment geben bzw. dieses 
wird einfach ignoriert.

Hier ist ein Beispiel wie das auf einem RPi Pico aussehen kann:
https://picockpit.com/raspberry-pi/c-extension-for-micropython-on-raspberry-pi-pico/

und hier noch die Doku zu mpy-Dateien:
https://docs.micropython.org/en/latest/reference/mpyfiles.html

Quintessenz und Antwort auf die Frage im Titel des Threads ist demnach 
nicht Python oder C, sondern Python und C.

von Peter (Gast)


Lesenswert?

Hercules H. schrieb:
> Immer mehr höre ich von Python und wie gut es auch ist in Bereich
> Eingebettete Systeme. Bibliotheken seien reichlich und umfangreich
> vorhanden.

Ich finde das sehr interessant, was da so alles zum Thema geschrieben 
wird. Und ich bin auch sehr überrascht, da ich bisher immer dachte, dass 
es bei Microcontrollern ( unter 1MB RAM / ROM) eigentlich wie bei einem 
100 Meter Lauf bei den Olympischen Spielen ist:

- Auf Platz 1: C
- Danach: Egal was, aber im Unterschied zur Olympiade misst sich der 
Abstand nicht in Millisekunden sondern in Sekunden.

Gruß Peter

von c-hater (Gast)


Lesenswert?

Peter schrieb:

> Ich finde das sehr interessant, was da so alles zum Thema geschrieben
> wird. Und ich bin auch sehr überrascht, da ich bisher immer dachte, dass
> es bei Microcontrollern ( unter 1MB RAM / ROM) eigentlich wie bei einem
> 100 Meter Lauf bei den Olympischen Spielen ist:
>
> - Auf Platz 1: C

Nö. Auf Platz 1 landet immer und unter allen Umständen Assembler von 
fähigen Asm-Programmierern. Logischerweise. Weil: besser geht nicht.
Deswegen benutzen auch alle üblichen Compiler für viele Sachen 
Asm-Einschübe.

> - Danach: Egal was

Naja. Fairerweise muss man sagen, dass auch hier die 
Programmiererkompetenz entscheidend ist. In vielen Fällen ist trotz des 
höheren Abstraktionsgrads hier C++ gegenüber C im Vorteil. Es ist in C++ 
einfach viel einfacher, dem Compiler klarzumachen, dass irgendwelche 
Soße zur Compilezeit vollständig berechenbar ist. Bzw.: man muss keine 
radebrechenden Klimmzüge machen, um ihm das beizubiegen, er bekommt es 
"von alleine" raus (weil er mehr impliziten Input durch den drastisch 
vergrößerten Sprachumfang hat, sofern er denn kompetent genutzt wird).

> aber im Unterschied zur Olympiade misst sich der
> Abstand nicht in Millisekunden sondern in Sekunden.

Das betrifft alles, was "Script" ist. Also Sachen, bei denen fundamental 
das Sprachkonzept dagegen ist, dass IRGENDETWAS zur Compilezeit 
aufgelöst werden kann. Zwar sind auch die Compiler von Scriptsprachen 
auch besser geworden und erkennen viele Stellen, an denen sie sich 
verhalten können, wie klassische Compiler, aber was bleibt, ist immer 
noch ziemlich blähig. Und das ist ein vollständig konzeptionelles 
Problem: Nur unter Augfgabe der Vorteile des "Scripting" könnte man 
daran etwas ändern (und landet dann bei normalen Compiler-Fähigkeiten).

von W.S. (Gast)


Lesenswert?

Peter schrieb:
> Und ich bin auch sehr überrascht, da ich bisher immer dachte, dass
> es bei Microcontrollern ( unter 1MB RAM / ROM) eigentlich wie bei einem
> 100 Meter Lauf bei den Olympischen Spielen ist

Dich würde es ein wenig überraschen, wie häufig bei handelsüblichen 
Geräten noch immer eine BASCOM Firmware drinsteckt.

Und nein, ich programmiere seit über 30 Jahren nicht mehr mit BASIC. 
Aber wie man sieht, gibt es nach wie vor einen Bedarf an Skriptsprachen.

W.S.

von W.S. (Gast)


Lesenswert?

c-hater schrieb:
> In vielen Fällen ist trotz des
> höheren Abstraktionsgrads hier C++ gegenüber C im Vorteil.

Naja.. wenn man Objekte nicht benötigt, dann schrumpft auch der Bedarf 
an C++ gar sehr. Aber für Objekte braucht es viel Platz im RAM und eine 
wirklich gute Heap-Verwaltung und das können kleinere Plattformen nicht 
bringen.

Und nochwas: wer den Stroustrup gelesen und durchgeackert hat, dem ist 
die Lust auf C++ zumeist vergangen. Da hat man es mit simplem C ja doch 
leichter, obwohl C eigentlich eine recht häßliche Programmiersprache 
ist. Ist aber Geschmackssache.

W.S.

von Johannes S. (Gast)


Lesenswert?

W.S. schrieb:
> Aber für Objekte braucht es viel Platz im RAM und eine wirklich gute
> Heap-Verwaltung

Wieviel Platz brauchen die Objekte denn im RAM? Und warum darf man 
Objekte nicht statisch instanziieren?

von Dieter H. (kyblord)


Lesenswert?

Python nervt bisschen, weil man auch nicht so genau weiß, wie viel 
Speicher da eigentlich verballert wird. Was für ein datentyp da jetzt 
verwendet wird ist macnhmal nicht klar. für ressourceneffiziente 
programmierung ist python müllll

von Norbert (Gast)


Lesenswert?

Manchmal kann es aber auch richtig praktisch sein, kommt immer darauf an 
was man (in welcher Zeit) erreichen möchte.
STM Discovery board:
1
def Test():
2
    t0 = pyb.micros()
3
    a = 10
4
    for _ in range(1000):
5
        a = a * 1000
6
    b = a + 1
7
    t1 = pyb.elapsed_micros(t0)
8
9
    print('A:',a)
10
    print('B:',b)
11
    print(type(a), type(a))
12
    print('Diff (AB):', b - a)
13
    print('Time:{:d}µs'.format(t1))
14
   
15
Test()
Ausgabe:
1
A:100000000000000000000000000…
2
… tausende von Nullen gekürzt …
3
000000000000000000000000000 
4
5
B:100000000000000000000000000…
6
… tausende von Nullen gekürzt …
7
000000000000000000000000001
8
<class 'int'> <class 'int'>
9
Diff (AB): 1
10
Time:136462µs

Für 15 Sekunden Tipparbeit gar nicht mal so übel.

von Lutz (Gast)


Lesenswert?

Gesundheit!

von Stefan F. (stefanus)


Lesenswert?

> W.S. schrieb:
>> Aber für Objekte braucht es viel Platz im RAM und eine wirklich gute
>> Heap-Verwaltung

Johannes S. schrieb:
> Wieviel Platz brauchen die Objekte denn im RAM? Und warum darf man
> Objekte nicht statisch instanziieren?

Ich bin jetzt auch verunsichert, was er meint. Statische Objekte mit 
nicht virtuellen Methoden brauchen kein einziges Byte zusätzlich.

Zusätzliche Funktionalität kostet natürlich, das sollte niemanden 
überraschen. Tatsache ist, dass alle Programmiersprachen nach Assembler 
dem Ziel dienen, Entwicklungs-Aufwände auf Kosten von Hardware-Leistung 
zu reduzieren.

Wenn man sich mal anschaut, wie die Leistung von Mikrocontrollern in den 
letzten 50 Jahren gestiegen ist, macht das so total Sinn. Denn 
Assembler-Programmierer werden weder billiger noch schneller.

Beitrag #6796300 wurde von einem Moderator gelöscht.
Beitrag #6796301 wurde von einem Moderator gelöscht.
von Jens G. (jensg)


Lesenswert?

für µC gibt es unterschiedliche Scriptsprachen die man verwenden kann. 
Etwa: "Lua-Script Micro-Phyton CircuitPython" Der Nachteil jeder sieser 
Scriptsprachen ist die Abhängigkeit zu einem bestimmten Hersteller und 
auch zu bestimmtem µicrocontrollern. CircuitPython wird von Adafruit 
bevorzugt. Nehme ich C oder C++ da lerne ich etwas, wo man jeden 
µicrocontrollern verwenden kann. Im Zusammenarbeit mit Arduiono ist der 
Einstieg in C sogar sehr einfach. Es gibt eine große Community und viel 
Unterstützung. AUch ein RP2040 lässt sich in C++ programmieren (wird von 
Arduino mittlerweile unterstützt. Wer Scriptsprachen bei 
µicrocontrollern lernt. Der lernt etwas etwas wo man später nur sehr 
wenige µicrocontroller verwenden kann. Der Stromverbrauch bei 
Prozessoren mit 100MHz dürfte auch höher sein .. und mit 8-bit 
Controllern kann man auch schon sehr viel machen (12 MHz Taktfrequenz 
bei 3.3V). Phyton ist mehr etwas für Betriebssysteme wie Windows oder 
Linux. Wo es auf das schnelle Prototyping ankommt.

Lange Rede kurzer Sinn: Bitte C oder C++ lernen. In der Welt von 
µicrocontrollern kann man da viel machen.. und da gab es auch noch Java. 
Auch ein Scriptsprache, wo sogar spezielle µicrocontroller entwickelt 
wurden. Davon redet heute niemand mehr. In Java gab es einen Bug der vor 
einigen Wocheen einen großen Pressewirbel ausgelöst hat. Die Abhängikeit 
zu einem Hersteller ist da schon sehr groß. In diesem Fall ist es 
Oracle. Open Source (GCC) hat auch einige Vorteile. Keine Kosten für den 
Hobyyisten wie die Österreicher es sagen würden.

von Stefan F. (stefanus)


Lesenswert?

Jens G. schrieb:
> und da gab es auch noch Java. Auch ein Scriptsprache

Java ist und war noch nie eine Scriptsprache.

> In Java gab es einen Bug der vor einigen Wochen
> einen großen Pressewirbel ausgelöst hat.

Der allerdings mit Mikrocontrollern genau gar nichts zu tun hat.Außerdem 
war das kein Fehler in Java, sondern in einer 3rd party Bibliothek 
(log4j). Auch in C kann man unsichere Bibliotheken programmieren. Ich 
erinnere nur an Openssl, da gab es mehrmals wesentlich schwerwiegendere 
Bugs.

> Die Abhängikeit zu einem Hersteller ist da schon sehr groß.
> In diesem Fall ist es Oracle.

Nein. Die Java Spezifikation ist offen. Die bekannteste Java 
Implementierung steckt in Android Smartphones. IBM hat eine kommerzielle 
Java Implementierung im Programm. Das Oracle Java ist übrigens eine 
Offenes Community Projekt, zu dem Oracle lediglich Support und 
Erweiterungen liefert. Es gab mal ein Java von Microsoft. Die Gnu 
Compiler Collection (GCC) enthält einen Java Compiler. Für Lego 
Mindstorms gibt es das Lejos Projekt. Es gibt eine Open-Source 
Implementierung für AVR Mikrocontroller, Namens NanoVM.

Also wenn man schon 1,5 Jahr später seinen Senf dazu gibt, sollte es 
wenigstens Hand und Fuß haben.

In einem Punkt stimme ich dir allerdings zu: Wer Mikrocontroller 
ernsthaft programmieren will, sollte mit C anfangen. Aber auch offen für 
Neues sein.

: Bearbeitet durch User
von Norbert (Gast)


Lesenswert?

Jens, normalerweise versuche ich ja auf so etwas eher diplomatisch zu 
antworten. Aber bei dir mache ich mal eine Ausnahme.
So einen gequirlten Mist habe ich schon lange nicht mehr gelesen.
Zuerst einmal sollte man die Dinge über die man schreibt zumindest 
buchstabieren können. Python, es heißt Python, nicht Phython.

Dann vielleicht noch Folgendes zum Nachdenken (wenn es sich denn 
einrichten lässt (das mit dem Nachdenken))
Ich schreibe gerade einen USB-Stack vollständig in Micropython. Der 
läuft bereits.
Des weiteren arbeitet das kleine RP2040 Ding hier bereits mit Multi-DMA 
(ausschließlich Python Code)
usw. usw.

Also, nur weil Du etwas nicht kannst, muss nicht automatisch bedeuten 
das andere es auch nicht können. Das Wichtigste ist das Verständnis für 
die Datenblätter, Register, Architektur, usw. Danach kommt die 
Programmiersprache.

Und nur mal so nebenbei: Ich habe noch nie so schnell einen lauffähigen 
USB-Stack in derart kurzer Zeit gebaut.

von EAF (Gast)


Lesenswert?

Jens G. schrieb:
> Bitte C oder C++ lernen.

So:
> Stop teaching C!

Jens G. schrieb:
> Im Zusammenarbeit mit Arduiono ist der
> Einstieg in C sogar sehr einfach.
Arduino ist C++, in Hauptsache.
Auch wenn im Core viel C steckt.

von Jens G. (jensg)


Lesenswert?

Eine Frage an den Profi. Macht es Sinn etwa 10.000 Programmzeilen in C, 
C++ nach Micropython zu portieren? (für den RP2040)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Nein, aber davon hat doch auch keiner geschrieben.

Was da ist, ist da. Ist aber kein Grund zu proklamieren, dass man das 
nur so machen könne.

von Norbert (Gast)


Lesenswert?

Jens G. schrieb:
>  Macht es Sinn …

Wenn überhaupt, dann ergibt etwas Sinn.

Wenn man Sinn machen könnte, dann hätte diese Welt zumindest noch eine 
kleine Chance.

Kann man nicht, hat sie nicht.

von chris_ (Gast)


Lesenswert?

Jens G. (jensg)
28.04.2022 21:13
>Eine Frage an den Profi. Macht es Sinn etwa 10.000 Programmzeilen in C,
>C++ nach Micropython zu portieren? (für den RP2040)

Solche Sachen sollte man dem Computer überlassen, der kann vieles 
besser.

https://cython.org/

Ob's für Micropython Cython gibt, weiß ich nicht.

von Stefan F. (stefanus)


Lesenswert?

Jens G. schrieb:
> Macht es Sinn etwa 10.000 Programmzeilen in C,
> C++ nach Micropython zu portieren? (für den RP2040)

Wenn du damit etwas sinnvolles erreichen kannst, dann ja. Pauschal 
betrachtet ist die Frage nicht vernünftig zu beantworten.

Um das mal zu verdeutlichen: Macht es Sinn, gläserne Salatschüsseln 
durch Tupperdosen auszutauschen? Kommt auch drauf an, was man damit 
erreichen will.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

chris_ schrieb:
> Jens G. (jensg)
> 28.04.2022 21:13
>> Eine Frage an den Profi. Macht es Sinn etwa 10.000 Programmzeilen in C,
>> C++ nach Micropython zu portieren? (für den RP2040)
>
> Solche Sachen sollte man dem Computer überlassen, der kann vieles
> besser.
>
> https://cython.org/

"Besser" würde ich nicht sagen, höchstens "mit weniger Aufwand". Der von
Cythen erzeugte C-Code ist gegenüber einer manuellen Portierung i.Allg.
weniger effizient (sowohl was die Rechenzeit als auch den Speicherplatz
betrifft) und schlechter lesbar (falls er weiterentwickelt werden soll).

> Ob's für Micropython Cython gibt, weiß ich nicht.

Cython an sich muss ja nicht auf dem RP2040 laufen, sondern nur auf dem
Entwicklungs-PC. Allerdings müssten die verwendeten Laufzeitbibliotheken
auf den RP2040 portiert werden. Ich weiß nicht, ob dafür schon jemand
die Muße gefunden hat.


Norbert schrieb:
> Jens G. schrieb:
>>  Macht es Sinn …
>
> Wenn überhaupt, dann ergibt etwas Sinn.

Wenn überhaupt, dann ergibt es einen Sinn.

Aber einmal abgesehen davon, dass schon Luther, Lessing und sogar Goethe
Sinn "gemacht" haben und deswegen das "Machen" nicht generell verteufelt
werden sollte, ist im vorliegenden Kontext "Sinn ergeben" genauso
unsinnig wie "Sinn machen", denn der Sinn (oder Unsinn) ist fest mit der
Art der Handlung (im konkreten Fall der Portierung von C[++] nach
Micropython) verbunden und muss sich deswegen nicht erst ergeben.

Eine bessere Formulierung der Frage wäre meiner Meinung nach:

"Ist es sinnvoll, etwa 10.000 Programmzeilen in C oder C++ nach
Micropython zu portieren?"

Wenn man unbedingt das Wort "Sinn" mit einem Verb verwenden möchte,
würde "haben" noch am ehesten passen, also:

" Hat es einen Sinn, etwa 10.000 Programmzeilen in C oder C++ nach
Micropython zu portieren?"

: Bearbeitet durch Moderator
von Norbert (Gast)


Lesenswert?

Solange jemand nicht die geringste Ahnung hat (und das ist ja nun 
geradezu schmerzhaft offensichtlich) warum etwas getan wird, ist es 
anmaßend sich in dieser Richtung negativ zu äußern. Gerade in diesem 
Forum ist zunehmend erkennbar:
1
Lautstärke = 1 / Wissen
Zu Lessing und Goethe, ja wenn die es gesagt haben, dann muss es ja 
stimmen. Für alle Zeit natürlich, nicht nur im Kontext der damaligen 
Ausdrucksweise.

Und abschließend: Ich habe nie von Portieren gesprochen, das gesamte 
Gerüst ist von Grund auf neu errichtet worden. Einzig aus den 
Dokumentationen der USB.org.

Und für die neugier^H^H^H^H wissbegierigen unter den Lesern:
Es dient primär Schulungszwecken…

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Cyblord.

Cyblord -. schrieb:

> Ja sicher. Pi und Python "für Brötchen". Irgendein Krauter gibts halt
> immer. Das macht niemand der was auf sich und seine Kunden hält.

Dann geh mal auf eine Haustechnik Messe, und schau dir an, was die an 
den Schauschalttafeln auf Hutschine und hinter Plexiglas haben: Rasbpis 
und Arduinos.

Geh in die Steuerung einer kleinen mittelständichen Ferigungsstrasse und 
schau Dir an, was da so läuft: Rasbpis und Arduinos. Auch auf Hutschine, 
aber ohne Plexiglasdeckel, darum siehst Du es nur, wenn Du den Deckel 
aufmachst.

Nicht überwiegend, aber so häufig, das es nicht ungewöhnlich ist.

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bernd W. schrieb:
> Rasbpis und Arduinos

Warum auch nicht, sind halt relativ preiswerte, "ready to go" zu habende 
Lösungen.

Beim RasPi würde ich mir höchstens Sorgen um die Lebensdauer der 
SD-Karte machen bzw. alles so aufsetzen, dass da nur möglichst wenig 
drauf geschrieben wird und maximal die Sachen im RAM laufen.

von Bernd W. (berndwiebus) Benutzerseite


Lesenswert?

Hallo Jörg.

Jörg W. schrieb:

>> Rasbpis und Arduinos

>
> Warum auch nicht, sind halt relativ preiswerte, "ready to go" zu habende
> Lösungen.

Eben. Für den Arduino gibt es sogar Watchdog Shields und solchen Kram. 
Geht alles schneller als alles neu zu entwickeln, und man hat eine 
Lösung "von der Stange" und keinen Exoten.

> Beim RasPi würde ich mir höchstens Sorgen um die Lebensdauer der
> SD-Karte machen bzw. alles so aufsetzen, dass da nur möglichst wenig
> drauf geschrieben wird und maximal die Sachen im RAM laufen.

Ist seit etlichen Jahren sowieso passe. Durch passende Einträge wird von 
der SD-Karte nur noch beim Booten gelesen, der Rest geht alles über eine 
SSD-Platte.
Bei aktuellen Raspis geht das glaube ich sogar vorkonfiguriert.

Meine Frau nutzt einen Raspi als Desktop- und Surfrechner. ;O)

Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.