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!
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.
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.
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.
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.
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 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.
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.
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.
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.
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...
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.
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
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.
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.
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.
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.
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.
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.
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!
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.
... 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.
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.
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...
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.
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
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.
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.
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.
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
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"
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
Ach, ich wollt noch editieren... Man kann bei MicroPython den Code sogar vorab zu Bytecode compilieren lassen, das muss also nicht zur Laufzeit passieren!
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.
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.
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.
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
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 | ~$ |
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))".
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.
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.
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.
> C wird langfristig auch Python überleben ... > wird noch lange gebraucht werden, ob es dem Establishment der neuen > Generation passt oder nicht. +++
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
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
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!
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
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.
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.
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
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
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.
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.
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" ...
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/
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...
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
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.
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.
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.
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
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.
> 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.
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! :-)
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.
ich denke es wird immer mehr in schlange programmiert, wenn überaupt noch. heute wird ja eher der ganze murks aus simulink generiert
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
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;-)
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
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
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.
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.
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.
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
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?
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 ;-)
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
Μα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
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.
Μα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. :-)
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.
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
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.
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.
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?
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.
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++.
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
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.
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.
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 ...
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...
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.
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?
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.
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
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?
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.
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.
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... ;-)
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? ;-)
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.
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.
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...
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...
Sheeva P. schrieb: > Mein Arbeitgeber entwicklelt [...] Darfst du Betriebsinterna einfach so ausplaudern? Ich halte gerade diesen Sektor für äußerst sensibel.
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 ;-)
Ich benutze am meisten c, die meiste Zeit verwende ich arduino und einige andere Mikrocontroller.
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.
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.
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
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
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... :-(
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. ;-)
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.
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.
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...
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.
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 : ><((((*>
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?
>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.
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.
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...
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.
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
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).
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.
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.
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?
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
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.
> 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.
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.
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.
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.
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.
Eine Frage an den Profi. Macht es Sinn etwa 10.000 Programmzeilen in C, C++ nach Micropython zu portieren? (für den RP2040)
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.
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.
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.
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.
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
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…
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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.