Microcontroller mit Python programmieren

So, bevor ihr mich jetzt für verrückt erklärt, bitte zu Ende lesen. Ich beschäftige mich zurzeit mit Compilerbau. Ein Front-End mit LLVM war sogar recht flott geschrieben, da fehlt mir aber jetzt noch das Wissen Maschinencode zu erstellen, da mir das ja LLVM abnimmt. Um eben mich jetzt mit der ganzen Kette vom Source Code, über Lexer/Parser zum AST bis hin zum fertigen Maschinencode beschäftigen kann, möchte ich jetzt da eben mehr selbst bauen. Da die Komplexität des Projektes ja doch von der Zielarchitektur abhängt, ziele ich da auf Atmels AVR RISC Architektur ab. Als Source Sprache Python, da diese ja doch eine gewisse Beliebtheit hat.

TL;DR: Also wie stellt ihr es auch vor (anhand konkrete Source Beispiele) wie man einen AVR am schönsten in Python programmieren könnte. Besonders weil ja alles eigentlich nur auf Registerzugriffe hinausläuft, wie sollte dies umgesetzt sein?

Ich bin jetzt nicht der Experte für Programmiersprachen.
Python kenne ich nur von Raspi. Da war ich eigentlich der Meinung das Python ein Interpreter ist.
Das bedeutet doch das die Interpretersoftware auf dem µC vorhanden sein muss.
Würde das denn auf einem µC mit begrenztem Speicher überhaupt funktionieren?
Oder liege ich da komplett falsch?

Hallo!

Auf µC mit weniger Speicher kann es nicht funktionieren und muss die "Übesetzung" von einer Hochsprache zu Maschinencode ausserhalb sein. Vor zig Jahren war einfacher BASIC-Interpreter meistens in einem ROM untergebracht (z.B. 8 kB oder mehr). Ich habe zwei mir bekannte Möglichkeiten von einem Compiler für Hochsprachen vereinfacht skizziert:

Code:

.-------------. .--------------. .---------------. | | | | | | | Text einer | | Text vom ASM | | Maschinencode | V1 | | | | * | | | Hochsprache | --> | (Mnemonics) | --> | (Hexzahlen) | | | | | | | | TH | | TM | | MC | | | | | | | '-------------' '--------------' '---------------' .-------------. .---------------. | | | | | Text einer | | Maschinencode | V2 | | | | | Hochsprache | -----------------------> | (Hexzahlen) | | | | | | TH | | MC | | | | | '-------------' '---------------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

Die erste Version (V1) wäre dafür einfacher, weil es mit "*" gekenzeichnete "Übersetzung" ASM -> Maschinencode für meiste µC schon fertig gibt.

Es gab da mal ein Projekt für Python auf dem mbed LPC1768
https://developer.mbed.org/users/dwh...hon-on-a-chip/
scheint aber eingeschlafen zu sein, keine Änderungen mehr seit 2011.

Ich rede schon von einer richtigen Kompilierung des Python-Code zu Maschinencode und keinen Interpreter. Ob jetzt Umweg über ASM oder direkt, wobei ASM eigentlich immer ein Zwischenschritt im Compiler ist, egal ob extern oder selbstgemacht, stellt sich noch raus. Für mich ein Lernprojekt, eher nichts produktives, bzw. dann halt mit fehlenden Optimierungen.

Mir geht es hier mehr um Input, wie man sich die Programmierung mit Python vorstellt. Hab zwar auch schon Ideen, das z.B. die Register als jeweilige Klassen/Objekte abgebildet sind, aber mehr Input schadet nicht :) Aber ja, die Kompilierung zu Maschinencode muss wie bei C natürlich am Entwicklerpc passieren.

MicroPython

Ältere Fragestellung, trotzdem aus aktuellem Anlass eine frische Antwort :p

MicroPython gewinnt langsam an Bedeutung.
https://github.com/micropython/micropython
Meines Wissens wurde (noch?) nicht auf AVR portiert. Aus eigener Erfahrung kann ich feststellen, dass der Interpreter stabil auf den Prozessoren STM32F4 und CC3200 läuft. Und in zwei Wochen soll MicroPython für ESP8266 (in Vorabversion) veröffentlicht werden :cool:. Die Crowdfunding-Erwartung für Entwicklungsaufwand wurde bereits 3-fach übertroffen.

Hier eine Demo von Chefentwickler Damien George von gestern:
https://www.youtube.com/watch?v=_voIwFB4mu0

Überlege gerade, eine kleine Roboter-Idee mit MicroPython hier im Forum zu "erarbeiten". Mal sehen.
Gruß

Zitat:

Zitat von Hubert.G

Ich bin jetzt nicht der Experte für Programmiersprachen.
Python kenne ich nur von Raspi. Da war ich eigentlich der Meinung das Python ein Interpreter ist.
Das bedeutet doch das die Interpretersoftware auf dem µC vorhanden sein muss.
Würde das denn auf einem µC mit begrenztem Speicher überhaupt funktionieren?
Oder liege ich da komplett falsch?

Es kommt drauf an welche Python Implementierung man verwendet.
Viele Python Entwickler verwenden für andere Aufgaben meistens von CPython und PyPy und sind dadurch in der Hardware stark eingeschränkt, und an den Prozess gebunden,
weil sie sich von der GIL, den Interpreter abhängig gemacht haben.
Multithreading und Multicore sind die bekanntesten Probleme in Python, weil die Entwickler ursprünglich einen anderen Ansatz mit der GIL verfolgt haben.

Man kann aber auch Cython nutzen, als static compiler, um zum Beispiel nativen C/C++ code aufzurufen.
Das setzt man z.B für bessere und Maschinennahe Performance ein, möglich wird das dadurch, weil man den Interpreter umgeht indem man ihn komplett deaktiviert.
http://cython.org/

Mikropython verfolgt glaube ich einen ähnlichen Ansatz, denn eigentlich werden über die C-API nur Pointer zwischen registrierten Funktionen hin und her geschoben.
Zur Performance und zum eigenen Memory Managment kann ich nichts sagen.

Geht es nur um Sensorik oder Steuerung würde ich wahrscheinlich keine Python Lösung empfehlen, sondern besser gleich alles in C/C++ umsetzen , oder eine Alternative die sich bewährt hat.
Will man aber auch andere Anwendungszwecke kombinieren wie zum Beispiel Analysen, oder auch machine learning Methoden in seine Roboter einbinden, wäre eine Python Lösung sicher nicht uninteressant.