Embedded System Scripting [geschlossen]

Hat jemand coole Ideen für die Verwendung einer Skriptsprache auf einem eingebetteten System? Ich denke speziell an das eLua- Projekt.

Grundsätzlich benötigen Sie ein Mikro mit mindestens 64 KB RAM, 256 KB Flash, die Newlib C-Bibliothek und einen gcc-Compiler (AVR32, ARM7, Cortex-M3 werden derzeit unter anderem unterstützt), und Sie können es senden ( oder programmieren Sie es, um Skripte zu laden. Es benötigt kein Betriebssystem, aber Sie können Ihr Mikro (das für eingebettetes Linux viel zu klein ist) viel mehr wie ein Allzweck-Computergerät verwenden, indem Sie Programme ausführen lassen, die nicht in den Programmspeicher geflasht wurden.

Das aktuelle Projekt enthält eine Reihe von Beispielanwendungen, aber keine von ihnen scheint etwas zu tun, was Sie mit einem in Flash gebrannten Programm nicht tun können. Der große Unterschied, den ich sehen kann, ist, dass Sie jedes Programm separat senden und verschiedene Programme ausführen können, ohne es zurückzusetzen. Darüber hinaus können Sie es interaktiv verwenden (Ändern Sie Ihren Programmablauf mit Ihren Entscheidungen auf der Tastatur, anstatt alles codieren zu müssen.

Wie würden Sie ein solches Gerät verwenden? Würden Sie ihm eine Tastatur und ein Zeichen-LCD geben und Ihre eigenen Skripte schreiben, während es auf Ihrem Schreibtisch liegt? Würden Sie einfach die Skriptsprache verwenden, um die Programmierung komplexerer Anwendungen zu vereinfachen? (Wie die Spiele, die derzeit auf der Projektseite verfügbar sind?) Oder würden Sie etwas völlig anderes machen? Ich fange damit an und suche nach Projektideen.

Bearbeiten : Sie können Programme über jedes gewünschte Protokoll (UART, SPI / I2C usw., USB, Ethernet) senden und von einer SD-Karte laden, unabhängig davon, was Ihr Chip unterstützt. Ich wollte nur klarstellen, dass es sich nicht um eine reprogrammierfreundliche Umgebung handeln muss.

Edit2 : Die meisten meiner Projekte sind für meinen persönlichen Gebrauch oder zum Teilen mit gleichgesinnten Freunden bestimmt und werden nicht oft an die breite Öffentlichkeit verkauft. Ich erwarte, dass Benutzer meiner Projekte an eingebetteten Systemen interessiert und mit diesen vertraut sind und in der Lage sind, die rudimentäre Verwendung einer Skriptsprache ohne allzu große Probleme zu erlernen. Ich könnte sie im Haus oder im Auto oder eher im Laden als Hilfe beim Entwerfen und Debuggen neuer Projekte verwenden. Ich könnte es auch meinem Chef bei der Arbeit vorschlagen, wo wir eingebettete Systeme herstellen und entwerfen. Oder ich könnte es für ein Ingenieurprojekt für die Schule verwenden.

Ich plane, eine Skriptsprache in mein kleines Mom-Find-Me-Gerät einzubetten (endlich wieder Fortschritte, hoffe, nächsten Monat einen funktionierenden Prototyp von der Detroit Maker Faire zu haben).

Es ist eine kleine Plattform mit GPS, Kompass, SD-Karte und ZigBee, die mir helfen soll, meine jüngeren Kinder in großen Parks im Auge zu behalten und ihnen die Möglichkeit zu geben, mich leicht zu finden, wenn sie mich brauchen.

Die eingebettete Skriptsprache bietet eine geschützte Sandbox, in der einfache Anwendungen wie Spiele, Karten, Geocaching-Programme oder Multiplayer-Spiele (mehrere Kinder mit jeweils einer Einheit können erweiterte Versionen von Flaggenerfassung, Verstecken, Taggen usw. spielen). ohne die Grundfunktion zu beeinträchtigen, meine Kinder verfolgen zu können. Diese werden als Textdateien auf die SD-Karte übertragen, sodass sie ohne spezielle Hardware oder Software problemlos bearbeitet und aktualisiert werden können.

Es gibt viele andere Möglichkeiten und Gründe, eine Skriptsprache in eingebetteten Systemen zu verwenden. Um jedoch zu sehen, wie oder warum sie in Ihre Anforderungen passt, müssen wir mehr über Ihr bestimmtes System wissen.

Ich habe mir eLua und einen eingebetteten Python-Interpreter für einige Projekte angesehen, an denen ich in meinem Tagesjob arbeite. Wir entwickeln ein Basissteuerungssystem, aber diese Systeme gehen aus und werden vor Ort umfassend angepasst. Anstatt die Endverwendung zum Hinzufügen zusätzlicher Verarbeitungsmodule zu erfordern, können diese unser System konfigurieren und in einigen Fällen ihre eigenen Funktionen schreiben. Da es unzulässig ist, dass Endbenutzer vor Ort erneut flashen (sie könnten leicht Dinge blockieren), bieten wir eine Skriptschnittstelle.

Derzeit haben wir eine proprietäre Sprache, die in Bytecode kompiliert und vom Kernel in der richtigen Reihenfolge durchgearbeitet wird. Wir versuchen jedoch, die Standards standardisierter und einfacher zu pflegen.

Hier ist ein Vergleich verschiedener interpretierter Sprachen, die auf "Bare Metal" ausgeführt werden können: /programming/1082751/what-are-the-available-interactive-languages-that-run-in-tiny-memory

Sobald das Gerät einmal im Werk geflasht wurde, möchten wir im Allgemeinen kein erneutes Flashen mehr durchführen müssen. Es ist langsam, fehleranfällig und für Endbenutzer schwierig. Um die Funktionalität nach der Produktion zu erweitern, ist eine Art Skripterweiterung eine gute Lösung.

Überprüfen Sie http://en.wikibooks.org/wiki/Atmel_AVR#Firmware_Programming

Es werden viele verschiedene Skriptsprachen für den Atmel AVR aufgelistet, einschließlich eines minimalen Python-Aufrufs PyMite http://wiki.python.org/moin/PyMite und http://code.google.com/p/python-on-a-chip/

Einige Projekte und Ideen mit eLua werden im eLua User Labs-Wiki unter http://wiki.eluaproject.net v0.8 gespeichert, das irgendwann in diesem Monat (Januar 2011) aus dem Ofen kommt.