Im Zusammenhang mit dem Einstieg in Microcontroller gibt es immer wieder die C vs. Assembler Debatte. Mit Assembler programmiert man den Microcontroller in seiner nativen Sprache und hat maximale Kontrolle. C ist portabel und in den richtigen Händen nicht langsamer oder resourcenfressender als Assembler. Allerdings ist K&R-C inzwischen 40 Jahre alt. Für viele Anwendungsbereiche haben sich inzwischen mächtigere und effizientere Programmiersprachen etabliert. Gerade im Hinblick auf die anstehende Vernetzung durch MCUs im Internet of Things, muss man sich doch die Frage stellen, ob es nicht Zeit ist auch hier mit der Zeit zu gehen? Es ist Zeit, sich von der SPS/Blinky/Ich-muss-jedes-Byte-kontrollieren Mentalität zu lösen. Welche Kandidaten gibt es hier? Javascript? Hat sich als de-Fakto Standard für Web-Anwendungen durchgesetzt. Mit node.js sogar auf der Serverseite. Was spricht gegen den Einsatz auf Microcontrollern? Go? Finde ich sehr spannend, und der C-Erfinder arbeitet ja auch daran. Java?
Thorsten R. Ollemann schrieb: > C > ist portabel und in den richtigen Händen nicht langsamer oder > resourcenfressender als Assembler. ... und erheblich einfacher in der Anwendung. Nach meinen erfahrung (in einem Anfall von Wahn hatte ich das mal probiert), liegt Assembler klar vor C: Faktor ca. 1,6. In der Zeit für die Programmentwicklung tut man sich in C ganz erheblich einfacher.
Joachim Drechsel schrieb: > ... und erheblich einfacher in der Anwendung. > > Nach meinen erfahrung (in einem Anfall von Wahn hatte ich das mal > probiert), liegt Assembler klar vor C: Faktor ca. 1,6. Yep, und je nach Anwendung gibt es den gleichen Faktor dann noch einmal zwischen C und moderneren Sprachen.
Thorsten R. Ollemann schrieb: > Was spricht gegen den Einsatz auf Microcontrollern? Alles. Javascript wird nicht mal auf Syntaxfehler beim hochladen auf den uC überprüft, deine Waschmaschine könnte beim Schleudern mit einem Syntaxfehler abstürzen. Vergiss also Scriptsprachen. Nehmen wir Java: Ja, wird auf dicken Microcontrollern mit Gigabytes an Speicher verwendet, und der ist dann üblicherweise auch voll: Android Smartphones. Für alles, was kleiner ist, also offensichtlich unbrauchbar. Ebenso ergeht es objektorientierten C, obwohl natürlich viele uC heute grösser und schneller sind als es die ersten PC und Mac je waren. Aber die hat man auch nicht mit objektorientiertem Ballast programmiert, sondern mit PL/M oder Pascal. Hat man aber 1MB oder mehr, kann man durchaus C++ nutzen, man muss ja nicht so grausam uneffektiv programmieren wie auf aktuellen PCs. Die hobbyüblichen haben aber selten 1MB, manchmal nur 1kB, da bleibt dann nur Assembler.
Bin zu dem Ergebniss gekommen - Diese Frage lässt sich nur hiermit beantworten: http://www.random.org/coins/
MaWin schrieb: > Alles. > > Javascript wird nicht mal auf Syntaxfehler beim hochladen auf den uC > überprüft, deine Waschmaschine könnte beim Schleudern mit einem > Syntaxfehler abstürzen. Das ist ein einfach zu lösendes Problem. Man überpruft die Software einfach vor dem hochladen. Es spricht auch nichts dagegen, Javascript vorzucompilieren. Übrigens gibt es bereits Javascript für microcontroller: http://www.espruino.com/ MaWin schrieb: > Nehmen wir Java: Ja, wird auf dicken Microcontrollern mit Gigabytes an > Speicher verwendet, und der ist dann üblicherweise auch voll: Android > Smartphones. Ja und? 512kb flash und 128kb sram gibt es bereits jetzt für Kleckerbeträge. Und so viel braucht man nicht: http://www.harbaum.org/till/nanovm/index.shtml > Ebenso ergeht es objektorientierten C, obwohl natürlich viele uC heute > grösser und schneller sind als es die ersten PC und Mac je waren. Arduino basiert auf C++. Insgesamt klingt das für mich eher nach dem üblichen "Haben wir immer schon so gemacht, was neues brauchen wir nich"-Argument. Es ändern sich aber eben doch Dinge: - Microcontroller werden in extrem komplexe Netzwerke eingebunden. - 32 Bit hält Einzug in Billigst-Controller.
Thorsten R. Ollemann schrieb: > Allerdings ist K&R-C inzwischen 40 Jahre alt. In diesem ursprünglichen C-Dialekt programmiert man heute auch nicht mehr. Aktuell ist C99 bzw. C11, und das ist schon deutlich moderner. > Für viele > Anwendungsbereiche haben sich inzwischen mächtigere und effizientere > Programmiersprachen etabliert. Aber nicht auf (kleineren) Mikrocontrollern. Wenn's hochkommt ist mit Einschränkungen C++ möglich. Sprachen, die eine virtuelle Maschine und/oder Garbage Collection verwenden oder interpretiert werden, kann man auf Mikrocontrollern praktisch kategorisch ausschließen. Wenn GC verwendet wird, kann man Echtzeit vergessen, und wenn kein nativer Code ausgeführt wird, ist das einfach zu lahm und speicherfressend. Weiterhin hat man das Problem, dass moderne High-Level-Programmiersprachen umfangreiche Bibliotheken mitbringen, die für die sinnvolle Nutzung der Sprache essentiell sind. Auf einen Mikrocontroller passen die aber niemals rauf, da kann man nicht mal schnell ein paar Megabyte verschwenden.
So ein STM32F429-Discovery ist billiger als ein Touch LCD alleine. Wenn Thorsten eine Java Entwicklungs-Umgebung dafür zusammen stellen will - was spricht dagegen? Vielleicht wird es ein Erfolg wie der Arduino. Vielleicht passt nicht mal die Library in den Speicher. Sollte aber mal jemand ausprobieren.
Die Frage ist ja auch, was für eine Art von Devices im Aruduino-Preissegment noch auftauchen werden. Es bahnen sich eine Menge interessanter und sehr mächtiger SoCs für IoT und Wearable-Anwendungen an: http://androidcommunity.com/mediatek-tipped-to-be-aiming-for-cheap-wearables-for-china-20140203/ Aster wird in Stückzahlen bei deutlich unter $10 liegen. Auf so einem Device interessiert die C vs. ASM Frage einfach nicht mehr.
Kein Name schrieb: > Wenn Thorsten eine Java Entwicklungs-Umgebung dafür zusammen stellen > will - was spricht dagegen? Vielleicht wird es ein Erfolg wie der > Arduino. Vielleicht passt nicht mal die Library in den Speicher. Wie oben gepostet, es gibt eine javavm für ATMega8: http://www.harbaum.org/till/nanovm/index.shtml
Thorsten R. Ollemann schrieb: > Insgesamt klingt das für mich eher nach dem üblichen "Haben wir immer > schon so gemacht, was neues brauchen wir nich"-Argument. Es ändern sich > aber eben doch Dinge: Es gab doch schon genug Experimente in dieser Richtung. Moderne Hochsprachen funktionieren einfach nicht ordentlich auf Mikrocontrollern. NanoVM ist doch ein super Beispiel dafür: ein nettes Experiment, aber in der Praxis unbenutzbar:
1 | What the NanoVM is and what it isn't |
2 | |
3 | There seems to be some confusion about what the NanoVM is and can do and what it can't and isn't. |
4 | |
5 | It is not a full featured Java VM and it will never be. It will always be limited to a small subset of the java language and the standard java libraries and a few application specific methods. Furthermore, it is not meant to replace C as the standard way of programming microcontrollers. It is less flexible and has a lower performance than C or assembler programs. |
> - Microcontroller werden in extrem komplexe Netzwerke eingebunden. Meinst du Sensornetze & co? Gerade da kann man doch ressourcenverschwendende Programmierung überhaupt nicht gebrauchen, da zählt jedes µA, damit der Akku länger mitmacht. > - 32 Bit hält Einzug in Billigst-Controller. Ja, aber das heißt nicht, dass man dann auf Billigst-Controllern große Mengen Flash und RAM hat. Die billigen ARMs haben auch nur wenige KB. Das höchste der Gefühle wäre Lua, das ist optimiert für geringen Ressourcenverbrauch. eLua z.B., aber da sollte man schon 256 KB Flash und 64 KB RAM mitbringen.
greg schrieb: > Es gab doch schon genug Experimente in dieser Richtung. Moderne > Hochsprachen funktionieren einfach nicht ordentlich auf > Mikrocontrollern. ... funktioniert nicht auf alten Microcontrollern. Was in den Formfaktor Microcontroller passt, ändert sich aber gerade gewaltig. greg schrieb: > Mikrocontrollern. NanoVM ist doch ein super Beispiel dafür: ein nettes > Experiment, aber in der Praxis unbenutzbar: Naja, ein Mega8 ist aber auch der Stand von vor 10 Jahren. Die nanovm auch. greg schrieb: > Meinst du Sensornetze & co? Gerade da kann man doch > ressourcenverschwendende Programmierung überhaupt nicht gebrauchen, da > zählt jedes µA, damit der Akku länger mitmacht. Ressourcenverschwendung muss aber nicht nur im Device, sondern auch in der Entwicklung vermieden werden. An einem $10 Produkt kann niemand ein Jahr lang herumfrickeln, auch wenn es um 100000er Stückzahlen geht. In Sensornetzen sind die kritischen Stromfresser ja auch die Tranceiver und Sensoren selbst. Ob die CPU 10% oder 12% beiträgt ist nicht ausschlaggebend. greg schrieb: > Das höchste der Gefühle wäre Lua, das ist optimiert für geringen > Ressourcenverbrauch. eLua z.B., aber da sollte man schon 256 KB Flash > und 64 KB RAM mitbringen. Das stimmt. Lua ist eine gute Option.
Ich bin begeistert vom .NET Micro Framework (NETMF). Man ist in der Entwicklung rasend schnell, und hat duch den Gadgeteer Standard auch irrsinnig schnell erste Erfolge und Prototypen zusammen gestellt. Wenn man C# gewohnt ist, gibt es so gut wie garkeine Hürden bei der Entwicklung. Einziges Manko: es ist nicht für realtime Anwendungen konzipiert. Es kommt hald auf den Anwendungsfall an. Wenn ich eine Applikation mit einer Kamera, einem Display und einigen Sensoren erstellen möchte, dann habe ich das mit dem .Net Micro Framework innerhalb eines Tages zusammen. Wenn ich jedoch beispielsweise einen Quadrokopter bauen möchte, werde ich damit relativ schnell an die Grenzen stoßen. Hier ist ein normaler Mikrocontroller definitiv die bessere Wahl. Gruß W
Von welcher Sorte Mikrocontroller sprechen wir? Es gibt nach wie vor ganz mickrige 8-Bit-Controller, die sich nur in Assembler sinnvoll programmieren lassen. Auf der anderen Seite gibt es Quad-Core-ARMs mit Taktfrequenzen im GHz-Bereich, riesigem Adressraum und virtueller Speicherverwaltung, auf denen man (bei entsprechendem Speicherausbau) praktisch jede Programmiersprache aus dem PC-Bereich verwenden kann. Und schließlich gibt es noch – ziemlich fein abgestuft – alles zwischen diesen beiden Extremen. Von welcher Sorte von Programmen sprechen wir? Ein Programm, dass direkt mit Hardwareregistern interagiert und Prozessabläufe auf 10µs genau steuern muss, stellt andere Anforderungen an die Programmiersprache als eine Smartphone-App. Während man im High-Level-Bereich zwischen Hunderten von Programmiersprachen auswählen kann, gibt es im hardwarenahen Bereich nur wenig Auswahl.
:
Bearbeitet durch Moderator
Thorsten R. Ollemann schrieb: > Allerdings ist K&R-C inzwischen 40 Jahre alt. Für viele > Anwendungsbereiche haben sich inzwischen mächtigere und effizientere > Programmiersprachen etabliert. > > Gerade im Hinblick auf die anstehende Vernetzung durch MCUs im Internet > of Things, muss man sich doch die Frage stellen, ob es nicht Zeit ist > auch hier mit der Zeit zu gehen? Es ist Zeit, sich von der > SPS/Blinky/Ich-muss-jedes-Byte-kontrollieren Mentalität zu lösen. Man könnte sich auch mal fragen, warum sich C so lange gehalten hat und weshalb sich außer den Compiler-Herstellern heute überhaupt noch jemand mit Assembler auseinander setzt. Das liegt vielleicht gar nicht daran, dass die µC Programmierer so innovationsfeindlich wären und sie das Bit-Schupfen so geil fänden. Die machen das vielleicht ganz einfach deshalb, weil es für das was sie machen notwendig ist. Je höher die Programmiersprache wird umso weiter abstrahiert man sich von der Maschine. So ein Java Programmierer weiß überhaupt nicht mehr was die Maschine auf der sein Programm läuft macht. Fragen Sie den mal wie lange die Ausführung seines Codes dauern wird. Der wird sie komisch ansehen und nicht verstehen warum das relevant sein sollte. Bei den Mikrocontrollern geht es aber um technische Probleme. Da ist Zeit sehr relevant (Stichwort Echtzeitsystem) und das ganze soll natürlich auch stabil sein. Man muss da einfach wissen was die Maschine macht und auch das sie das macht was sie soll. Bei Mikrocontrollern ist man schon alleine aufgrund ihres Einsatzgebietes immer sehr nahe an der Hardware und man kann sich daher natürlich auch nur begrenzt von ihr abstrahieren. Und auch im PC-Bereich ist man sehr schnell wieder bei C und Assembler wenn es zum Beispiel um Betriebssystem-Kern oder Treiberprogrammierung geht. Wie weit man sich von der Maschine abstrahieren kann hängt eben immer vom Anwendungsfall ab. Die µCs werden heute meiner Meinung nach ganz einfach deshalb noch von C und Assembler dominiert, weil es hier das Anwendungsgebiet ganz einfach nicht erlaubt sich weiter von der Hardware zu entfernen. Da geht es eben um Technik und nicht um Klicki-Bunti.
Wolfgang W. schrieb: > Ich bin begeistert vom .NET Micro Framework (NETMF). > Man ist in der Entwicklung rasend schnell, und hat duch den Gadgeteer > Standard auch irrsinnig schnell erste Erfolge und Prototypen zusammen > gestellt. Wenn man C# gewohnt ist, gibt es so gut wie garkeine Hürden > bei der Entwicklung. Einziges Manko: es ist nicht für realtime Sieht superspannend aus. http://www.netmf.com Allerdings ist auf der Site nicht all zu viel Los? Fast keine Projekte, letztes Forenposting vor 11 Tagen. Gibt es irgendwie ein Beispielprojekte mit Source usw, ohne dass man sich das ganze Framework installieren muss?
> Allerdings ist K&R-C inzwischen 40 Jahre alt. Für viele > Anwendungsbereiche haben sich inzwischen mächtigere und effizientere > Programmiersprachen etabliert. Du laberst Quatsch. Gerade fuer Microcontroller hat sich C Hersteller- uebergreifend etabliert. Marktdurchdringung vermutlich so 99%. Und das schon seit >15Jahren. Jeder in der Branche kann C oder er ist draussen. Es gibt bergeweise alten Code denn man weiter verwenden kann. Die Sprache muss einem nicht gefallen, aber es ist gut so das es nur eine gibt. > Gerade im Hinblick auf die anstehende Vernetzung durch MCUs im Internet > of Things, BINGO! Was hab ich gewonnen? > muss man sich doch die Frage stellen, ob es nicht Zeit ist > auch hier mit der Zeit zu gehen? Die Frage darfst du stellen, aber die Antwort ist nein. All diese modernen Schickimickisprachen brauchen naemlich mehr Resourcen. Das bedeutet das in jedem produziertem Geraet der Controller dann nicht mehr 40-60Cent sondern 2-3Euro kostet. Wenn du soetwas baust dann machst du pleite. Das nennt man Marktwirtschaft. Ausserdem braucht dein dicker Controller dann mehr Strom. Ich muss mit 30mW fuer ein komplettes System auskommen. Gerade an den Android-Handys sieht man doch was da fuer ein Muell bei rausgekommen ist. Fuer groessere Projekte wuerde ich eine objektorientierte Sprache wie C++ auch besser und angemessen finden. (Aber ganz bestimmt nicht den hirntoten Griff ins Klo wie Java) Das Problem ist nur du brauchst zwingend Leute als Programmierer die von der Hardwareseite kommen, die eine Vorstellung davon haben was ein Microcontroller ist, sonst kommt da naemlich auch nur abstrahierter Mist bei rum. Diese Leute tun sich aber alle mit objektorientierten Sprachen sehr schwer. Das duerfte der eigentliche Grund sein warum keiner soetwas verwendet. Was ich als sinnvoll ansehen wuerde das waere eine C-aehnliche Sprache die um eine Syntax fuers Multitasking erweitert ist. Aber das wird einfach nicht kommen weil C eben den Markt absolut beherscht. Olaf
Yalu X. schrieb: > Von welcher Sorte Mikrocontroller sprechen wir? > > Es gibt nach wie vor ganz mickrige 8-Bit-Controller, die sich nur in > Assembler sinnvoll programmieren lassen. > > Auf der anderen Seite gibt es Quad-Core-ARMs mit Taktfrequenzen im > GHz-Bereich, riesigem Adressraum und virtueller Speicherverwaltung, auf > denen man (bei entsprechendem Speicherausbau) praktisch jede > Programmiersprache aus dem PC-Bereich verwenden kann. > Naja, die Dinger nennt man aber nicht mehr Mikrocontroller. Die sind auch nicht voll integriert, da braucht man externen RAM und externen Flash. Das fetteste, was man voll integriert als Mikrocontroller vermarktet zu kaufen bekommt, hat irgendwas bei 200 MHz Taktfrequenz, Flash um 1-2 MB herum und RAM um die 256 KB. > Von welcher Sorte von Programmen sprechen wir? Da hier irgendwas von 10 USD Produktpreis erzählt wurde... wohl nicht letzteres. ;)
greg schrieb: >> Von welcher Sorte von Programmen sprechen wir? > > Da hier irgendwas von 10 USD Produktpreis erzählt wurde... wohl nicht > letzteres. ;) Korrektur: das sollte eine Antwort auf "Von welcher Sorte Mikrocontroller sprechen wir?" sein.
Yalu X. schrieb: > Von welcher Sorte Mikrocontroller sprechen wir? Das ist eine gute Frage. Es scheint im Moment einen fließenden Übergang zu immer mächtigeren SoCs in immer einfacheren Systemen zu geben. Wo ist die Grenze zwischen einem SoC wie Aster, einem STM32F4 und einem AVR? Yalu X. schrieb: > Von welcher Sorte von Programmen sprechen wir? Grenzen wir es vielleicht auf alles, was Arduino kann und will, ein. Damit sind ausdrücklich auch vernetzte Sensoranwendungen eingeschlossen. > Ein Programm, dass direkt mit Hardwareregistern interagiert und > Prozessabläufe auf 10µs genau steuern muss, stellt andere Anforderungen > an die Programmiersprache als eine Smartphone-App. Während man im > High-Level-Bereich zwischen Hunderten von Programmiersprachen auswählen > kann, gibt es im hardwarenahen Bereich nur wenig Auswahl. Ja, Echtzeit wird eine Domäne der klassischen Microcontrollern mit C bleiben. Allerdings ist zu beobachten dass immer mehr Anwendungen gar keine harten Echtzeitanforderungen mehr haben. z.B. bekommen die Sensoren immer mehr eigene Intelligenz. Vor 10 Jahren musste man zur Auswertung eines Drehratensensors das Ausgangssignal per ADC auslesen und mit harten Echtzeitanforderungen aufintegrieren. Jetzt kommt ein Quaternion mit Zeitstempel aus dem FIFO.
Thorsten R. Ollemann schrieb: > Wolfgang W. schrieb: > Ich bin begeistert vom .NET Micro Framework (NETMF). > Man ist in der Entwicklung rasend schnell, und hat duch den Gadgeteer > Standard auch irrsinnig schnell erste Erfolge und Prototypen zusammen > gestellt. Wenn man C# gewohnt ist, gibt es so gut wie garkeine Hürden > bei der Entwicklung. Einziges Manko: es ist nicht für realtime > > Sieht superspannend aus. > http://www.netmf.com > > Allerdings ist auf der Site nicht all zu viel Los? Fast keine Projekte, > letztes Forenposting vor 11 Tagen. Gibt es irgendwie ein > Beispielprojekte mit Source usw, ohne dass man sich das ganze Framework > installieren muss? https://www.ghielectronics.com/community Hier ist das eigentliche Forum mit Projekten, Sourcecode und interessanten Beiträgen
Thorsten R. Ollemann schrieb: > Allerdings ist K&R-C inzwischen 40 Jahre alt. Für viele > Anwendungsbereiche haben sich inzwischen mächtigere und effizientere > Programmiersprachen etabliert. a) 40 Jahre sind für eine Programmiersprache nicht alt. COBOL (darauf laufen nicht-Investment-Banken) ist von 1959, Fortran (damit wird das Wetter vorhergesagt) ist von 1957. Lisp (damit überprüfen Mikrochiphersteller ihre Designs auf logische Fehler, AutoCAD ist darin programmiert) ist von 1958. C wurde 1969 angefangen und ist somit relativ neu. Bedenke, es gibt sehr viele Programmiersprachen die nach 10-20 Jahren (quasi) aussterben, obwohl sie anfangs populär waren. (Rexx, PL/1, usw) b) Diese Sprachen sind für die diese Anwendungsbereiche optimiert. Mit awk wirst Du Dich zum Beispiel schwer tun eine Steuerung zu programmieren. Die Stärke von C ist es, keine besonders gute oder effiziente Programmiersprache sein zu wollen. Deshalb lagert der erfahrene C-Programmierer Code in Datenstrukturen aus wann immer es komplex wird. Das Ergebnis ist eine de-facto Programmiersprache die genau an die Anforderungen angepasst ist. Lese Dir mal das hier durch: http://catb.org/esr/writings/taoup/html/ Wenn Du mit den Meinungen nicht übereinstimmst, ist C vielleicht nicht die richtige Sprache für Dich.
Wolfgang W. schrieb: > https://www.ghielectronics.com/community > Hier ist das eigentliche Forum mit Projekten, Sourcecode und > interessanten Beiträgen Aha, und es gibt auch einen Port für das STM32F429-Discovery board. Dann sollte ich mir mal eins zulegen.
Übrigens eine kleine Anmerkung. Wenn Du eine sehr kleine Hochsprache für Mikrocontroller suchst, nimm Forth. Das ist so das meiste "Bang for the Buck". Da reden wir dann von wenigen Kilobytes für den Forth Compiler... der dann auf dem Mikrocontroller läuft und in den Du zur Laufzeit neuen Code rein bringen kannst. Dabei fällt so nebenbei eine Kommandozeile ab. :)
Christian Berger schrieb: > a) 40 Jahre sind für eine Programmiersprache nicht alt. COBOL (darauf > laufen nicht-Investment-Banken) ist von 1959, Fortran (damit wird das > Wetter vorhergesagt) ist von 1957. Lisp (damit überprüfen > Mikrochiphersteller ihre Designs auf logische Fehler, AutoCAD ist darin > programmiert) ist von 1958. C wurde 1969 angefangen und ist somit > relativ neu. Bedenke, es gibt sehr viele Programmiersprachen die nach > 10-20 Jahren (quasi) aussterben, obwohl sie anfangs populär waren. > (Rexx, PL/1, usw) Das sind allerdings alles Beispiele, bei denen es eine existierende Codebasis gab, die weiter gepflegt wurde. Niemand wird ein neues Datenbankprojekt in Cobol anfangen, oder eine FEM-Bibliothek in Fortran. Christian Berger schrieb: > b) Diese Sprachen sind für die diese Anwendungsbereiche optimiert. Mit > awk wirst Du Dich zum Beispiel schwer tun eine Steuerung zu > programmieren. Die Stärke von C ist es, keine besonders gute oder Klar, und bei den embedded Systems tun sich gerade einige neue Anwendungsbereiche auf. Die Konsequenz ist dann doch eigentlich klar? Christian Berger schrieb: > Lese Dir mal das hier durch: http://catb.org/esr/writings/taoup/html/ > Wenn Du mit den Meinungen nicht übereinstimmst, ist C vielleicht nicht > die richtige Sprache für Dich. ESR...
Christian Berger schrieb: > Übrigens eine kleine Anmerkung. Wenn Du eine sehr kleine Hochsprache für > Mikrocontroller suchst, nimm Forth. Das ist so das meiste "Bang for the > Buck". Da reden wir dann von wenigen Kilobytes für den Forth Compiler... Forth ist elegant, aber zu den aktuellen Prozessorarchitekturen nicht wirklich kompatibel. Ich verstehe auch nicht wo Sinn und Anwendungen für die Greenarray-Prozessoren von Chuck Moore zu suchen sind, aber vielleicht bin ich dafür zu blöd.
Die Frage nach einer "guten" Programmiersprache und wie "modern" sie ist hat meiner Erfahrung nach nicht unbedingt was mit dem tatsächlichen Namen der Sprache zu tun. So ist es meiner Erfahrung nach viel wichtiger, einen gut lesbaren und leicht verständlichen Code zu erzeugen, als die Frage, in welcher Sprache ich das mache. Ein vollkommen unverständliches Java Programm, bei dem der Programmierer die Variablen mit a b und c "durchnummeriert" hat ist nämlich "älter" als das gleiche Programm in C mit gut gewählten Namen und einem leicht verständlichen Aufbau. Die Programme selbst benötigen je nach Sprache unterschiedliche viel Ressourcen, wobei der klare Trend ist: Je höher und abstrahierter die Sprache, desto mehr Ressourcen und desto höher auch der Energiebedarf. Und gerade der Energiebedarf wird immer wichtiger, da zum Einen Energie teuerer wird und zum Anderen immer mehr Geräte mit stark begrenzten Energiemengen auskommen müssen, die beispielsweise über Akkus bereitgestellt werden. Ein weiterer Punkt düften auch die Kosten sein, die Sprache zu wechseln. Wenn beispielsweise von C auf Java umgestellt werden soll muss in C vorliegender Code nach Java portiert bzw. neu geschrieben werden, was Geld kostet. Welche Sprache am Ende wirklich verwendet wird ist eher zweitrangig (was man ja auch an den vielen endlosen Diskussionen über Sprachen sieht), wichtiger ist es, die Sprache zu können und gut verständlich und wartbaren Quellcode zu schreiben. Gruß Kai
Thorsten R. Ollemann schrieb: > Klar, und bei den embedded Systems tun sich gerade einige neue > Anwendungsbereiche auf. Die Konsequenz ist dann doch eigentlich klar? Naja, es gibt halt da nicht wirklich geeignete Sprachen. Es gibt zwar Modesprachen wie C++ oder C#, die irgendwie eierlegende Wollmilchsäue sein wollen, aber die einzigen halbwegs erfolgreichen Versuche einer "Embedded-Sprache" sind Fortran und BASIC. Beide Sprachen haben gemein dass sie eine komplette Betriebssystemsumgebung mit bringen und es ermöglichen Code interaktiv auszuführen. Man muss nicht Code ändern, compilieren, drauf laden, ausprobieren, ändern, compilieren... sondern man kann zum Beispiel eine Funktion einfach mal mit neuen Parametern ausführen um was zu testen. Das ist so die größte Gemeinsamkeit die man bei solchen Projekten hat.
Thorsten R. Ollemann schrieb: > Yalu X. schrieb: >> Von welcher Sorte Mikrocontroller sprechen wir? > > Das ist eine gute Frage. Es scheint im Moment einen fließenden Übergang > zu immer mächtigeren SoCs in immer einfacheren Systemen zu geben. Wo ist > die Grenze zwischen einem SoC wie Aster, einem STM32F4 und einem AVR? Auf diesem Aster, der jeweils 4MB Flash und RAM haben soll, dürfte es kaum Einschränkungen in der Wahl der Programmiersprache geben. Mit so viel RAM ist bei nicht allzu datenintensiven Anwendungen auch automatische Speicherverwaltung möglich, wie sie von den meisten neueren Pogrammiersprachen praktiziert wird. Ob, Assembler, C, C++, C#, Python, Haskell oder was auch immer, ist hauptsächlich eine Frage der Anwendung (bspw. Echtzeitanforderungen) und des persönlichen Geschmacks.
Christian Berger schrieb: > die einzigen halbwegs erfolgreichen Versuche einer > "Embedded-Sprache" sind Fortran und BASIC. Das halte ich für, vorsichtig ausgedrückt, eine äußerst gewagte These... > Beide Sprachen haben gemein dass sie eine komplette > Betriebssystemsumgebung mit bringen und es ermöglichen Code interaktiv > auszuführen. Das allerdings ist etwas, was man im µC nicht braucht und, viel wichtiger: oft auch garnicht will. Ich hätte jedenfalls ein Problem mit einem Controller eines A380-Triebwerks, dessen Firmware sich "on the fly" (hier im wahrsten Sinne des Wortes) ändern ließe. Das gäbe dem Terrorismus völlig neue Möglichkeiten... > Man muss nicht Code ändern, compilieren, drauf laden, > ausprobieren Die Entwicklungsphase ist im Vergleich zur Nutzungsphase völlig irreleveant. Davon mal abgesehen dauert ein Kompilierungslauf mit Upload heute nur noch Sekunden oder sogar Bruchteile von Sekunden, je nach Umfang der Änderungen im Quelltext. Jedenfalls, wenn man nicht gerade OpenSource-Toolchains beschäftigt...
Was ich mich gerade frage ist, wozu ineffiziente Programmiersprachen verwenden (die überaus effektiv in der Anwendung auf ihrer Problemdomäne sind!), wenn man keine Problemkomplexität hat, für die sie erschaffen wurden? Bei den allermeisten µC-Programmen entsteht die Komplexität aus der technischen Sachlage, nicht aus der Komplexität der Programmiersprache. Sobald man UI-Programme mit Drag&Drop, Multitasking und so einen Kram braucht, Interop etc., da ist man doch schon bei einem Smartphone. Was versprichst Du Dir für einen Entwicklungseffizienz-Vorteil, eine Spannung in Javascript zu messen und dann einen Pin über einen querreferenziertes Lua-Skript zu setzen? Ich finde da überwiegen eindeutig die Nachteile. Auch connectivity ist bei den Teilen doch sehr eingeschränkt, da braucht man eher eine gute Bibliothek, denn eine effektivere Programmiersprache. Naja, meine Meinung... Wobei es natürlich ohne Frage cool wäre, wenn man selbst auf µCs stets soviel Zeit und Strom verschleudern darf, wie auf ausgewachsenen PCs, zum hundertstel des Preises. Aber wozu dann noch PCs? :)
Ich würde meinen Kommentar gerne zurückziehen, der T.R.Olle Mann ist ja hier nur zum T.R.Ollen unterwegs.
Ada2012 ist eine moderne Sprache, die wunderbar für embedded geeignet ist. Compiler für AVR und ARM gibt es auch.
Habe mir das hier mal durch gelesen..... Welche Sprache? Das scheint ja hier im Forum ganz wichtig zu sein. Eine Glaubensfrage, zumindest größtenteils. Mit Priestern an allen Fronten. Vergleichbar mit Schlüsselthemen in anderen Foren. PHP -- OOP oder nicht, Singletons sind böse, usw. Motorrad --- Welches ist das beste Öl, die besten Reifen .. :-) Eine gute Gelegenheit mal ein bisschen Öl ins Feuer zu gießen :-) Meine Lieblingssprache ist Forth! Ganz eindeutig. Verwende ich sie? Nöö... (kaum noch) Mittlerweile hat sich bei mir ein gewisser Pragmatismus eingestellt. Es wird die Sprache eingesetzt, welche am besten "passt". Die Frage ist dann natürlich, wie beurteilt man das? Muss an der Zielplattform gespart werden, wirds eng mit Speicher und Zeit. Also bleibt fast nur Assembler. Sind reichlich Ressourcen vorhanden, ist die Sprache egal, Hauptsache sie gibts für das Zielgerät. Dann werden andere Zielrichtungen interessanter. Qualität der IDE. (wenn man ein Beißhölzchen vermisst, ist es die falsche) Entwicklungszeit (z.B. fertige Libs nutzen können) Sind alle im Team "warm" mit der Sprache?
Christian Berger schrieb: > Lisp (damit überprüfen > Mikrochiphersteller ihre Designs auf logische Fehler, AutoCAD ist darin > programmiert) Selbstverständlich ist AutoCAD nicht in Lisp programmiert. AutoCAD beinhaltet aber einen Interpreter für eine Lisp-artige Sprache.
c-hater schrieb: > Das allerdings ist etwas, was man im µC nicht braucht und, viel > wichtiger: oft auch garnicht will. Ich hätte jedenfalls ein Problem mit > einem Controller eines A380-Triebwerks, dessen Firmware sich "on the > fly" (hier im wahrsten Sinne des Wortes) ändern ließe. Das gäbe dem > Terrorismus völlig neue Möglichkeiten... Wow! Entschuldigung aber die Aussage ist ziemlich doof. Denn wenn ein "Terrorist" Zugriff auf die Kommunikationsschnittstellen eines Triebwerks hat, dann kann er schon alles damit machen. Im einfachsten Falle schaltet er das einfach ab und blockiert weitere Kommunikation. > Die Entwicklungsphase ist im Vergleich zur Nutzungsphase völlig > irreleveant. Das ist nicht richtig, denn je besser die Entwicklungsphase läuft, um so besser wird das Produkt. Jeder von uns kennt ja solche typischen "Wegwerfprodukte" bei denen die Entwickler das Teil gerade mal so hinbekommen haben. Leider kommen die halt immer öfter aus Deutschland. Auf TopGear lacht man sich schon halb tot über unsere Firmwarefehler in Autos. > Davon mal abgesehen dauert ein Kompilierungslauf mit Upload > heute nur noch Sekunden oder sogar Bruchteile von Sekunden, je nach > Umfang der Änderungen im Quelltext. Jedenfalls, wenn man nicht gerade > OpenSource-Toolchains beschäftigt... Geil und jetzt noch gegen OpenSource ranten, das zeigt ja wirklich, dass Du ein totaler Überchecker bist.
Thorsten R. Ollemann schrieb: > Das ist ein einfach zu lösendes Problem. Man überpruft die Software > einfach vor dem hochladen. Oh! Du hast Das Halteproblem gelöst? Wurdest Du schon für die Fields-Medaille vorgeschlagen? Hat sich Gödel aus seinem Grab erhoben?
Micro Python: Python for microcontrollers https://www.kickstarter.com/projects/214379695/micro-python-python-for-microcontrollers
Achim_42 schrieb: > Micro Python: Python for microcontrollers Naja, von der Ausführungsgeschwindigkeit wäre ich persönlich jetzt nicht gerade begeistert, wenn ich mir das Demovideo anschaue. Game of Life mit so nem dicken µC mit vielleicht 5 fps ist doch ziemlich erbärmlich. Aus nem ATMega mit 16 MHz schafft das in C geschrieben auf 128x64 Pixel ca. 20 fps. Das ist schon ein ganz gewaltiger Unterschied dafür, das vielleicht die Sprache etwas einfacher zu Programmieren ist. Gruß Kai
Kai S. schrieb: > Achim_42 schrieb: >> Micro Python: Python for microcontrollers > > Naja, von der Ausführungsgeschwindigkeit wäre ich persönlich jetzt nicht > gerade begeistert, wenn ich mir das Demovideo anschaue. Game of Life mit > so nem dicken µC mit vielleicht 5 fps ist doch ziemlich erbärmlich. Und dazu erwähnen sie noch, dass das der Idealfall ist: Kein Heap wird genutzt, daher muss auch kein GC laufen. So ein STM32F405 kostet übrigens alleine schon gut 10 EUR... Nein, das überzeugt mich nicht. Wieder so ein "Experiment".
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.