Scriptsprachen im Embedded Bereich

Hallo,

mir geht es weniger um die Sprachen an sich. Ich wollte halt wissen 
wofür diese Sprachen im Embedded Umfeld eingesetzt werden.
Trotzdem danke.

Matthias schrieb:
> Hallo,
>
> mir geht es weniger um die Sprachen an sich. Ich wollte halt wissen
> wofür diese Sprachen im Embedded Umfeld eingesetzt werden.
> Trotzdem danke.

Für zeitkritische Sachen wird Phython nicht taugen, irgendwelche 
einfachen Anwendungen kann man damit aber bestimmt realisieren. Weit 
verbreitet dürfte es aber nicht sein.
Wo studierst du eigentlich? Normalerweise ist doch C oder C++ bei uC 
weit verbreitet und in C hast du ja bereits Erfahrung gesammelt.

Moin,

die Python-Frage ist recht knifflig, 'embedded' kann viel bedeuten. Ich 
fasse mal ein paar use-cases zusammen:

1) Auf dem Embedded-Gerät
   a) Standalone, kein Embedded-Linux:
     * 'python-on-a-chip'
     * Roher Python-Interpreter mit ein paar emulierten System Calls
   b) Embedded (uC)linux als OS:
     * Standard-Python-Interpreter lauffähig

Beispiele: SRV1-Roboter mit uClinux, div Plattformen mit Raspberry Pi, 
Beagleboard, etc.

2) Auf dem PC
   a) OpenEmbedded: Python wird nur zum Bauen genutzt!
   b) Systemtests, Testbenches, Fernsteuerung des Embedded-Geräts


Punkt 1a) ist aufwendig zu implementieren. 1b) kriegt man quasi 
geschenkt.
Wenn die Geräte nur per Script ferngesteuert werden sollen, macht es 
u.U. mehr Sinn, einfache Schnittstellen in C zu implementieren und sie 
per netpp-Backend via Python anzusteuern. Das Gerät wird dann einfach 
zum Python-Objekt, und man konfiguriert das Ding z.B. so:

1

import device

2

3

d = device.connect("DEV:/dev/ttyUSB1")

4

root = d.sync() # Synchronisieren

5

6

root.LED.red.set(1) # LED anschalten

Bei den meisten Geräten muss man sich gut überlegen, wieviel eingebaute 
Intelligenz sie benötigen und ob eine Python-Lösung in der Firmware 
wirtschaftlich ist, bzw. von den Resourcen her machbar ist (im Endeffekt 
die Entscheidung: Linux oder nicht)

Grüsse,

- Strubi

Ein Prof hatte mal erzählt, dass in der Praxis CAN-Matrizen eingesetzt 
werden. Also Excel-Tabellen, in denen alle CAN-Botschaften mit ID und 
Inhalt aufgeschlüsselt sind. Ich könnte mir vorstellen, dass man mit 
einem Script ein Header generiert, in dem dann alle IDs oder so stehen.

Ich vermute mal, dass ein Bosch oder Conti keine Python-Applikation oder 
generell keine Scripte auf deren Steuergeräte laufen?!

Es gibt z.B. von Telit auch GSM-Module für den Embedded Bereich auf 
denen ein Phyton Interpreter läuft. Die kann man wahlweise klassisch per 
Controller und UART mit AT Kommandos betreiben oder die Anwendung als 
Phyton Skript direkt auf dem Modem laufen lassen.

Ab 4Kb Ram läuft der abgespeckte Python Interpreter.
AarLogic bzw Telit GSM/GPRS/GSM Systeme haben den Python Interpreter 
eingebaut und man spart sich vielfach so eine externe CPU.
Als Beispiel, ich kenne einige Getränkeautomaten sowie Kaffeemaschinen, 
welche ausschließlich in Python programmiert sind, mit solchen Modulen 
und
der Zentrale dann die Meldung geben. Die Rede ist von Automaten, welche
Firmen verliehen werden und nicht und vom Verleiher aufgefüllt werden,
nicht von solchen, welche vom Betreiber aufgefüllt werden und Bluetooth
verwenden. Diese Module haben generell 10 GPIO, einen Seriellen Bus
sowie 2x rs232, wie auch ADC und USB.

Dasselbe gilt für Kameras.
Kameras mit OpenCV sowie Python binding können diverse Funktionen 
ausführen,
ohne dass man Cross Compiling braucht, sowie sind auch sehr flexibel.
Generell wird der Python Interpreter durch ein Webinterface vom Benutzer
abgeschirmt, aber wenn man Sachen braucht, welche nicht durch das 
Webinterface machbar sind, ist Python sehr angenehm.

Sind zwar nur Nischenbereiche, aber dort hat Python einen großen Einzug.
Ausserhalb würde ich Python eher nicht einsetzen. Python braucht viel
Flash, zumindest als Interpreter.

Hallo Martin,

was genau meinst du mit Testumgebungen? Hättest du da ein Beispiel 
parat?
Das mit der Softwaregenerierung im Automobilbereich habe ich auch schon 
gehört aber es gibt ja noch andere Bereiche in denen händisch C-Code 
geschrieben wird. Aber das soll ja auch nicht das Thema sein.

Also sind Scriptsprachen eher ein Nive-to-have in der Entwicklung von 
Embedded Software oder genauer gesagt bei der Entwicklung von Software 
für Steuergeräte?!

Ok so langsam dämmerts ;-)

Deine Erfahrung mit Python kann ich nur bestätigen. Ich habe mich in den 
letzten Tagen etwas damit beschäftigt und man kann relativ schnell 
eigene Programme erstellen.

Aber zum Thema Scripte für Testumgebungen findet man realtiv wenig im 
Internet. Wir arbeiten auch derzeit in einer Vorlesung mit CANape und 
dort gibts auch die Möglichkeit eigene Funktionen und Skripte zu 
schreiben aber von Vector erhält man da auch wenig Infos wenn man nicht 
einen Workshop mitmachen möchte.

Matthias schrieb:
> Oder werden Scripte eher genutzt um Headerfiles oder ähnliches
> zu generieren?

Ja, so macht es ein weltgrößter Automotive-Zulieferer, allerdings mit 
Perl.

Martin H. schrieb:
> CANape und CAPL sind die Vector-Welt

Martin H. schrieb:
> CANape und CAPL sind die Vector-Welt

Das ist ein bisschen einseitig ;-)
Bei CANoe/CANalyzer hast du neben CAPL auch die Möglichkeiten C#, VB, 
Java und XML zur definition von Tests zu verwenden. Zusätzlich gibt es 
ein COM Interface, dass sich gut eignet um Tests mit Scriptsprachen 
(Python, VBS etc.) zu schreiben. Neuerdings wird auch die ASAM HIl API 
unterstützt, die ebenfalls über C#, Python etc. angesprochen werden 
kann. Es gibt also reichlich Möglichkeiten...

Ich dachte die Tools von Vector sind Alleskönner. Trotzdem gibts 
Schnittstellen um eigene Skripte einzubauen. Ich sehe schon es ist kein 
Fehler eine Skriptsprache zu kennen bzw sie auch programmieren zu 
können.

Matthias schrieb:
> rotzdem gibts
> Schnittstellen um eigene Skripte einzubauen.

Darüber wird gewährleistet, dass du verschiedene Tools von 
unterschiedlichen Herstellern austauschen kannst. Ein Testwerkzeug wie 
EXAM kannst du dann also problemlos mit einem Vector HIL oder einem 
DSPACE HIL verwenden, ohne deinen Test umschreiben zu müssen. Dank ASAM 
HIL wird diese austauschbarkeit nun auch standardisiert.
Und in diesem umfeld spielen Scriptsprachen natürlich eine große Rolle. 
Es ist also definitiv kein Fehler diese zu beherrschen, wenn man im 
Automotive Bereich (insbesondere Testing) unterwegs ist.

Ihr scheint mit der Thematik ja vertraut zu sein. Kennt ihr vielleicht 
Literatur zu diesen Themen oder sind das so Sachen, die man sich im 
Arbeitsleben selbst aneignet?
Wie gesagt ich könnte mir gut vorstellen im Bereich Software für 
Steuergeräte zu arbeiten und daher bin ich da für sämtliche Infos offen.

Servus,

interessanter Thread. Ich arbeite seit kurzem als Softwareentwickler für 
Landmaschinen und habe daher auch mit vielen Cs zu tun. Angefangen von 
der Programmiersprache C bis hin zu den Tools von Vector. Da ich seitens 
der Hochschule schon mit Skriptsprachen konfrontiert wurde wollte ich 
diese auch im Arbeitsleben einsetzen aber auch mir fehlt da eine 
Anwendung.
Ich schreibe Applikationen für Landmaschinen und teste diese an einem 
Musteraufbau, der das Steuergerät und entsprechende Sensoren und Aktoren 
beinhaltet. Mein Wunsch wäre es die Tests zu automatisieren aber dafür 
brauche ich wieder eine zusätzliche Hardware wie z.B. von dSpace oder?

Matthias schrieb:
> Ist damit gemeint, dass Python Scripte direkt auf Steuergeräten bzw. µC
> laufen?

Eher nicht.
Es wird z.B. angewendet um für die Testautomatisierung mehrere 
verschiedene Testsysteme unterschiedlicher Hersteller über deren API 
miteinander zu Koordinieren und die Testauswertung z.B. für die 
Diagnoseschnittstelle durchzuführen.

http://www.elektroniknet.de/automotive/tools/artikel/90368/4/

Gruß Anja

Justus schrieb:
> Mein Wunsch wäre es die Tests zu automatisieren aber dafür
> brauche ich wieder eine zusätzliche Hardware wie z.B. von dSpace oder?

Oder eben von Vector (VT System) ;-)
So oder so: HW brauchst du schon (nennt sich dann "HIL Prüfstand"), um 
z.B. deine Sensoren und Aktoren zu simulieren. So kannst du das 
Steuergerät komplett isolieren und nur dessen Schnittstellen abprüfen. 
Dabei hast du dann volle Kontrolle über deine Virtuellen Sensoren, 
Aktoren und auch die Busse (Restbussimulation).

Hallo,

Danke für die vielen Antworten. Mir stellt sich nun aber eine andere 
Frage. An meiner Hochschule ist eine Arbeit ausgeschrieben, bei der ein 
Labcar entwickelt werden soll. Also ein Controller mit CAN anbindung, 
der die Ausgangssignale der Steuergeräts einliest und die Sensoren des 
Fahrzeugs simuliert bzw können die Sensorwerte über eine GUI 
eingestelltbwerden. Soweit verstehe ich die Aufgabe und sie ist sehr 
interssant. Meine Frage bezieht sich nun aber auf einen Byte Code 
Interpreter. Ich habe das so bestanden, dass ich dem Controller ein 
Stück Python Code schicke und er führt ihn dann aus?!

Schau Dir mas das Projekt "python-on-a-chip" an:
http://code.google.com/p/python-on-a-chip/

Gruß,
Alex

Hi

Wenn ich das hier lese, fühle sofort ich mich um 30 Jahre 
zurückversetzt.

MfG Spess

Servus zusammen,

beim Stöbern bin ich auf diesen Thread aufmerksam geworden. Vor allem 
interessiere ich mich für das VT System von Vector, das auch hier zur 
Sprache kam.
Kann ich mit den einzelnen Modulen des VT Systems auch gängige 
Schnittstellen aus der Automatisierungtechnik, wie z.B. 4 - 20 mA oder 0 
- 8,5 V ausgeben? Oder generell gefragt kann ich die Spannungs- und 
Stromausgänge so konfigurieren wie ich möchte?