Frage:
Gibt es programmierbare Geräte für modernere Sprachen?
arussell84
2011-05-21 12:01:20 UTC
view on stackexchange narkive permalink

Verzeihen Sie meine Naivität, aber es scheint, dass die meisten programmierbaren Geräte (FPGAs, SPSs, PICs usw.) mit den Sprachen C oder C ++ oder einer Variante davon programmiert werden können. Gibt es Geräte, die D, Mozilla Rust oder Google Go verwenden? Mir ist klar, dass insbesondere die beiden letzteren unreife Sprachen sind; Aber sicherlich hat irgendwo jemand ein experimentelles Produkt veröffentlicht.

Hat jemand Vorschläge?

Magst du Forth? Das ist eine beliebte Sprache für eingebettete Geräte. Es gab einen kürzlich erschienenen Artikel [hier] (http://www.forth.org/lost-at-c.html) und eine Diskussion über Hacker News [hier] (http://news.ycombinator.com/item?id=) 2574204), mit sehr informativen Kommentaren. Im Moment haben Sie jedoch keine Zeit, etwas davon hierher zu bringen. Wenn jemand diese Informationen in eine Antwort umwandeln möchte, wäre ich sehr dankbar!
@reemrevnivek Ich habe diesen Artikel heute tatsächlich gesehen, und ich glaube nicht, dass Forth meinem persönlichen Geschmack entspricht, aber auf jeden Fall danke, dass Sie das geteilt haben!
@arussell - Ja, ich war mir nicht sicher, ob es in die Form von D, Rust oder Go passt.
Was würden die modernen Sprachen zur (wirklich) eingebetteten Programmierung bringen? PS. In diesem Zusammenhang meine ich mit eingebetteter Programmierung die Programmierung, bei der ein Cortex-M3 ein schreiendes Leistungstier ist und Sie immer nur On-Chip-SRAM und Flash verwenden.
Verwandte Themen: [Was sind gute Optionen für den Beginn der Hardwareprogrammierung mit Hochsprachen?] (http://stackoverflow.com/questions/366991/what-are-good-options-for-beginning-hardware-programming-using-high -Level-Sprache)
Verwandte: [Was sind die verfügbaren interaktiven Sprachen, die in winzigem Speicher ausgeführt werden?] (http://stackoverflow.com/questions/1082751/what-are-the-available-interactive-languages-that-run-in-tiny-memory )
@davidcary Ich suchte eher nach Antworten zu Systemprogrammiersprachen als nach höheren oder interpretierten Sprachen, aber diese Links enthalten immer noch einige gute Informationen. Vielen Dank.
@jpc Es scheint mir, dass Sie, anstatt wirklich neugierig zu sein, einfach implizieren, dass Sie nicht an den Antworten auf meine Frage interessiert sind. Wenn Sie an nichts anderem als C interessiert sind, können Sie meine Frage einfach ignorieren. Ansonsten würde ich gerne spezifischere Fragen beantworten.
@arussell84: Ich bin wirklich interessiert an der Antwort auf Ihre und meine Frage. Außerdem: Glauben Sie mir, dass ich in der eingebetteten Programmierung wirklich genug von einfachem C habe. Ich glaube, dass es im Bereich der eingebetteten Programmiersprachen viel zu verbessern gibt, aber ich glaube nicht, dass "normale" Programmiersprachen für große Computer viel von dieser Verbesserung bieten werden. Deshalb habe ich gefragt, wie Sie erwarten, dass sie helfen.
@jpc In diesem Fall, nehmen Sie mit, da Kommentare nur so viele Zeichen haben dürfen. D soll eine Verbesserung gegenüber C ++ sein. Ich meine nicht übergeordnete Ebenen wie C # oder Java. Kann den Speicher weiterhin manuell verwalten und Zeiger verwenden. Lesen Sie die [D-Übersicht] (http://www.digitalmars.com/d/2.0/overview.html). Zwei Funktionen, die mich besonders interessieren, sind Schließungen und anonyme Funktionen. Go and Rust Ich glaube, es könnte populär werden, ist aber möglicherweise nicht für eingebettete Geräte geeignet. Zu früh, um es zu sagen. Objective-C könnte jedoch funktionieren. Ich habe nicht geschaut.
Ich hatte immer den Eindruck, dass Schließungen ohne Müllabfuhr ein Schmerz sind. Vielleicht sollten Sie sich Blöcke ansehen (eine aktuelle LLVM-Funktion von Apple). Sie können Objective-C überprüfen, da es einige nette Ersetzungen für Schließungen enthält (das Ziel- / Aktionsprotokoll) und ich glaube, dass ein eingebettetes systemfreundliches libobjc nicht viel Arbeit wäre. OTOH Wenn Sie anfangen, Dinge wie HTTP-Server oder ähnliches zu schreiben (wo ich glaube, dass dynamische Bindung und moderne Sprachen am nützlichsten sind), wird Ihnen schnell der Speicher mit oder ohne eine moderne Sprache ausgehen.
Neun antworten:
#1
+14
starblue
2011-05-21 17:12:20 UTC
view on stackexchange narkive permalink

Sie benötigen keine unterschiedlichen Geräte, um diese Sprachen zu verwenden, sondern nur das entsprechende Softwaresystem.

Die Hauptprobleme, warum dies nicht häufiger durchgeführt wird, sind:

  • Diese Sprachen benötigen normalerweise mehr Ressourcen (Speicher, Laufzeit) für dieselbe Aufgabe. Bei großen Volumes würde der geringere Programmieraufwand durch höhere Hardwarekosten mehr als ausgeglichen.

  • Die meisten übergeordneten Sprachen benötigen eine dynamische Speicherzuweisung mit Speicherbereinigung, was schwierig ist in einer Echtzeiteinstellung.

  • Es ist schwieriger, eingebettete Entwickler für diese Sprachen zu finden.

Das heißt, Es gibt solche Dinge wie Echtzeit-Java, die in echten eingebetteten Systemen verwendet werden.

Obwohl ich nicht alle Details angegeben habe, nach denen ich gesucht habe, hat mich Ihre Antwort letztendlich zu meiner Antwort geführt. Am Beispiel eines PIC gibt es mehrere Schritte zwischen dem Schreiben von Code auf Ihrem Computer und dem Ausführen dieses Codes auf dem PIC. Sie müssen es kompilieren und hochladen, und es gibt verschiedene Möglichkeiten, auch diese zu tun. Um beispielsweise mit D für einen PIC zu schreiben, müsste jemand ein Äquivalent von [SDCC] (http://sdcc.sourceforge.net/) für D schreiben.
Zusätzlicher Punkt: In eingebetteten Systemen (insbesondere kleinen ohne Betriebssystem usw.) sind viele der Funktionen (und Gemeinkosten / Strafen) höherer / moderner Sprachen bestenfalls irrelevant oder tatsächlich unerwünscht.
#2
+4
Dr. Watson
2011-05-21 17:18:43 UTC
view on stackexchange narkive permalink

Es gibt Open Source-Projekte, die an solchen Zielen arbeiten. Es gibt ein Projekt für Ada auf Atmel-MCUs (obwohl ich es nicht zum Laufen bringen konnte). Einer meiner Mitarbeiter programmiert seine 68HC11-MCU mit einer verkleinerten Version von Ruby, an der er selbst gearbeitet hat. Und es gibt ein Unternehmen, BlueSpec, das eine neue HDL für FPGAs / ASICs hat, die auf Haskell basiert. Es ist jedoch kein Tool, auf das die meisten Zugriff haben würden.

Anbieter tendieren dazu, sich an C zu halten, da es ein großes Publikum für C gibt und es weithin akzeptiert wird. Ebenso sind VHDL / Verilog für FPGAs / PLDs weithin akzeptiert und bewährt. Anstatt viele verschiedene Sprachen unterstützen zu müssen, konzentrieren sich die meisten lieber auf ihre Chips, versuchen die Leistung ihrer C-Compiler zu verbessern und bieten bessere Tools zum Konfigurieren und Verwalten von Ressourcen auf ihren Chips. Ich stimme diesem Ansatz selbst zu. Ich bevorzuge es sehr, dass Texas Instruments seine Tools zum Konfigurieren erweiterter Peripheriegeräte auf ihren Chips verbessert, als die erweiterte Metaprogrammierung von Vorlagen auf ihrem minimalen C ++ - Compiler zu implementieren.

#3
+3
Gorgen
2011-05-21 14:08:15 UTC
view on stackexchange narkive permalink

Sie werden begnadigt.

Der Grund dafür, dass C und weniger C ++ (unter anderem VHDL) für diese Art von Geräten verwendet wird, ist, dass es einfach ist, von den Sprachkonstrukten auf die zugrunde liegende Hardware zu übersetzen. C wird von vielen als Verkehrssprache angesehen und es ist die Mühe nicht wert, eine neue Sprache auf das Gerät zu portieren, insbesondere wenn das Lesen / Schreiben in Registern umständlich ist, wenn die Sprache nützliche Konstrukte nicht viel besser ausdrücken kann.

Die Beispiele, die Sie als neuere, glänzendere Sprachen verwenden, z. B. D, könnten ein Kandidat für eine "Low-Level" -Sprache sein, wenn mehr Programmierer sie verwenden. D wird als das moderne C ++ ohne Kompromisse mit C angepriesen und von Anfang an implementiert. Leider ohne alle C ++ - Bibliotheken. Ich denke, Sie können C libs von D aus aufrufen.

Die Frage ist nicht, ob es neuer ist, sondern ob es sich um bessere Tools handelt. Soweit ich sehen kann, ist dies nicht der Fall.
Bearbeiten
Wenn ich eingebetteten Code (in C) geschrieben habe, habe ich mir bessere Makros / Vorlagen gewünscht als C Angebot. Da es sich um ein Konstrukt zur Kompilierungszeit handelt, hat es wirklich nichts mit der zugrunde liegenden Hardware zu tun. Die Implementierung in einem Compiler ist jedoch viel komplizierter.

Sie können einen externen Makroprozessor wie m4 verwenden. Es ist sehr mächtig.
Ich wünschte mir die Möglichkeit, Inline-Funktionen zu überladen, je nachdem, ob der Compiler einen Parameter als Konstante auswerten kann. In einer Funktion wie "x auf die Potenz y erhöhen" wäre es für eine Inline-Version sinnvoll, konstante Potenzen von 0 bis 3 im Sonderfall zu verwenden und eine Bibliotheksfunktion für andere Potenzen aufzurufen. Es würde sich jedoch nicht lohnen, Inline-Code zu generieren, um diese Konstanten zu testen. Leider kenne ich keine Compiler für irgendeine Sprache, die Überladungen anhand konstanter Werte unterscheiden können.
@supercat: Sie können eine Vorlagenspezialisierung in C ++ durchführen, um einige dieser Probleme zu beheben. Dabei müssen sich Ihre Argumente jedoch in der Vorlageninstanziierung "<>" anstelle der Funktionsargumente "()" befinden, was nicht ideal ist.Ich kann deinen Kuchen nicht haben und ihn auch essen.
#4
+2
Leon Heller
2011-05-21 14:06:00 UTC
view on stackexchange narkive permalink

Geräte wurden entwickelt, um andere Sprachen wie LISP / Scheme, Forth und Java effizient zu verwenden. Ich glaube nicht, dass irgendwelche für die von Ihnen erwähnten Sprachen entwickelt wurden, vielleicht sind sie nicht für eingebettete Systeme geeignet (abgesehen von D, das auf allen für C / C ++ entwickelten Sprachen effizient laufen sollte). Sie könnten vermutlich auf jeder geeigneten MCU implementiert werden, wenn jemand dies wünscht.

Vielleicht sind Go und Rust letztendlich nicht für die eingebettete Programmierung geeignet. Sie sind ein bisschen neu, denke ich, aber sie behaupten, Systemprogrammiersprachen zu sein, weshalb ich sie als Beispiele aufgeführt habe. In letzter Zeit gab es in Programmierkreisen auch einige Neuigkeiten zu diesen Sprachen, daher habe ich versucht, Sprachen auszuwählen, die nicht zu dunkel waren.
#5
+2
jamesotron
2011-05-24 09:18:51 UTC
view on stackexchange narkive permalink

Es gibt immer Netduino, mit dem Sie in .NET codieren können.

Ich bin kein Fan von .NET, aber das ist so ziemlich das, wonach ich gesucht habe. =)
#6
+2
Peter Gibson
2014-06-19 16:50:32 UTC
view on stackexchange narkive permalink

Schauen Sie sich Micro Python an http://micropython.org/

Micro Python ist eine schlanke und schnelle Implementierung der Programmiersprache Python 3 optimiert für den Betrieb auf einem Mikrocontroller. Die Micro Python-Karte ist eine kleine elektronische Leiterplatte, auf der die Micro Python-Sprache ausgeführt wird.

Sie wurde im Dezember 2013 erfolgreich als Kickstarter-Projekt finanziert und hat eine Referenzkarte.

#7
+1
Philippe
2011-05-21 18:03:21 UTC
view on stackexchange narkive permalink

Sie suchen einen Mikroprozessor. Intel verkauft sie ebenso wie AMD und ARM. Sie können auf diesen Geräten eine beliebige Programmiersprache verwenden.

Bei FPGAs: Ihre Sprachauswahl ist begrenzt. Dies liegt daran, dass Sie ein Synthesetool benötigen, das Ihren Code in eine Netzliste übersetzt. Zusätzlich zu VHDL, Verilog und (eingeschränktes C) können Sie modernere Sprachen wie MyHDL (basierend auf Python) oder Bluespec (Haskell-ähnlich) verwenden.

Mikrocontroller sind lediglich Mikroprozessoren mit geringem Stromverbrauch und integrierten Peripheriegeräten. Sie können keine alte Programmiersprache auf einem FPGA (mit Softcore, glaube ich) oder einem Mikrocontroller ausführen, da diese zu langsam, zu klein und zu niedrig sind, als dass andere Sprachen gut funktionieren könnten (und Folglich haben sie keine Compiler für diese Sprachen geschrieben. Mikroprozessor vs. Mikrocontroller ist nicht die Unterscheidung, die uns hier interessiert.
Ich sagte nicht Mikrocontroller, ich sagte Mikroprozessor, der Mikrocontroller enthält, aber auch Ihren regulären Intel Core i7 Prozessor. Wie bei FPGAs mit weichen oder harten Kernen; Sie kommen in vielen verschiedenen Größen und ja, sie können jede Sprache ausführen. Sie führen ein ganzes Linux-Betriebssystem aus.
Ihr Zitat von Intel erinnert mich an diesen alten Chip: 8052AH-BASIC.http://www.dusko-lolic.from.hr/i8052fract/sbc1.jpg.Es hatte einen BASIC-Interpreter im ROM!
#8
+1
Johan
2011-05-24 18:47:53 UTC
view on stackexchange narkive permalink

Erstens sind Ihre Beispiele kleine Geräte mit begrenzten Ressourcen, dann machen die alten Sprachen, die der Hardware nahe stehen, wie c und vhdl, die Arbeit gut.

Die neuen "coolen" Sprachen benötigen mehr Ressourcen, um gut zu laufen, also denke ich, dass das, was Sie suchen, ziemlich bald kommen wird, da die MCU mit der Zeit immer leistungsfähiger wird.

Mein Punkt ist, dass die meisten MCUs: s immer noch in C programmiert sind. und der coole Typ hat gerade angefangen, auf diesen Geräten mit C ++ zu spielen.

Aber wenn Sie sich die 32-Bit-ARM-basierte MCU ansehen, die viel mehr Ressourcen als die alten 8-Bit-MCUs bietet kann verrücktes Projekt wie eLua finden, das versucht, die Skriptsprache lua auf einem Cortex-M3-basierten mcu auszuführen ...

Also werden wir dorthin gelangen, aber es wird gehen Nehmen Sie sich noch ein paar Jahre Zeit. Und ich glaube nicht, dass eines dieser verrückten Projekte (noch) für die Produktion bereit ist, aber einige davon werden, da es schneller ist, sich in Sprachen mit einem höheren Abstraktionsgrad entwickeln.

#9
+1
Unslander Monica
2014-10-06 21:23:20 UTC
view on stackexchange narkive permalink

Auf STM32F4xx ARM-Mikrocontrollern läuft unter Rust eine Proof-of-Concept-Anwendung. Die überraschend kleinen Änderungen, die zum Portieren von Rust erforderlich sind, sind in dieser Rust-Gabel verfügbar.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...