Hallo zusammen, so langsam muss ich Bewerbungen bezüglich meiner Bachelorarbeit schreiben. Das Gebiet steht für mich auch schon fest. Es soll in Richtung Embedded Software gehen also Software für Steuergeräte oder ähnliches schreiben. Ich hab auch schon mehrere Projekte mit Mikrocontrollern in C realisiert und daher würde ich gerne in diesem Bereich arbeiten. Mittlerweile lese ich auch, dass Python einzug im Embedded Bereich gehalten hat. So wirklich vorstellen kann ich mir darunter nichts! Ist damit gemeint, dass Python Scripte direkt auf Steuergeräten bzw. µC laufen? Oder werden Scripte eher genutzt um Headerfiles oder ähnliches zu generieren? Vielleicht kann mir jemand darüber etwas sagen. Besten Dank im Voraus. gruß Matthias
Python im Embedded Bereich hab ich mal openembedded.org gesehen, kann jetzt aber auch nicht sagen wie abgespeckt der Interpreter wirklich ist. Falls du noch nicht festgelegt bist, schau dir auch mal eLua an: http://www.eluaproject.net/overview/status
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
Also ich habe eine ziemlich umfangreiche Applikation, wo ich Python einsetze: 4 Karten mit STM32F103 werden von einem mini2440 gesteuert. Die 4 Karten werden mit C++, der mini2440 mit Python (+nCurses) programmiert.
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.
Matthias schrieb: > Es soll in > Richtung Embedded Software gehen also Software für Steuergeräte oder > ähnliches schreiben. Nachdem Du weiter unten was von CAN Matrizen schreibst, gehe ich davon aus, dass Du Steuergeräte für Autos meinst... Da muss ich Dich leider enttäuschen. Diese Software wird in der Regel nicht mehr geschrieben, sondern nur noch generiert. Das was das Gerät eigentlich tun soll (also der Algorithmus) wird modelliert (z.B. Matlab/Simulink) und dann wird aus diesem Modell C-Code generiert. Der Rest (Bus Kommunikation, Hardware-Abstraktion, Betriebssystem, etc.) wird in Form einer sog. Basissoftware realisiert. Diese wird i.d.R. auch generiert. Skriptsprachen kommen nicht auf dem Steuergerät zum Einsatz, dafür aber ganz gerne bei den Code-Generatoren, Konfigurationstools und vor allem bei Test-Umgebungen. Mit der größte Aufwand (neben Powerpoint-Folien malen ;-) bei der Steuergeräteentwicklung ist nämlich der Test.
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?!
Hallo Matthias, Testumgebung kann "alles Mögliche" sein. z.B.: 1. Ein Stück Software, das für den generierten Code automatisiert Modul-/Unittests, statische Codeanalysen, etc. durchführt und die Ergebnisse entsprechend aufbereitet. 2. Ein Testsystem (z.B. PC mit entsprechender Zusatzhardware), der dem Steuergerät Daten/Signale sendet und die Antwort auswertet. Kommt natürlich immer auch die Anforderungen an - wenn da Echtzeitanforderungen dazu kommen wird es schwerig. Gerade entwicklungsbegleitende Tests, die mitunter nicht so umfangreich wie z.B. Prüfstandtests sind, schreien quasi nach einer Skriptsprache, mit der man mal schnell einen Testfall dazuschreiben kann. Es gibt viele fertige Lösungen für sowas (auch in Python geschriebene: ECUtest/TestCASE), aber man braucht auch oft mal ein Stück GlueCode. Da ist halt eine Skriptsprache angenehmer/schneller als Batch oder C. Dass Python in dem Bereich eine so große Anhängerschaft gefunden hat, liegt vermutlich daran, dass diese Sprache für C-Programmierer sehr leicht zu erlernen und dazu noch sehr gut dokumentiert ist. Eine Skriptsprache ist meiner Meinung nach etwas mehr als ein Nice-To-Have. Gerade in der SW-Entwicklung gibt es sehr viele langweilige aber automatisierbare Abläufe, bei denen es mit einer Batch oder einem Makefile schwierig wird. Da baut man sich halt ein Skript und die Sache ist gegessen. Aus eigener Erfahrung kann ich sagen, dass man bei Python innerhalb eines Tages das Wichtigste kann, weiß wo man die Doku und Erweiterungen (Stichwort PyPI) findet und das was man vorhatte auch schon fertig hat ;-). Man ist natürlich kein Experte, aber "es tut".
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.
CANape und CAPL sind die Vector-Welt, von der ich mich gott-sei-dank fernhalten konnte... Da man ausser Bussen oft auch noch andere Stimuli für das Steuergerät bieten möchte, bastelt man halt ein Skript aussenrum, dass CANape/CAPL anstösst und noch diverse andere Sachen macht (z.B. Testfälle/-daten von irgendwo her holen, Stromversorgung/Signale schalten, OEM-Spezifische Tools steuern, Testberichte generieren und irgendwo ablegen). Bronco schrieb: > allerdings mit Perl. Iiiiiih 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.
Vector-Kenner schrieb: > Martin H. schrieb: >> CANape und CAPL sind die Vector-Welt > > Das ist ein bisschen einseitig ;-) CANape und CAPL sind sind doch Vector-proprietär, oder täusche ich mich da? Ich habe mich halt nie mit den Vector-Produkten anfreunden müssen, da die Alternativen leichter zu bekommen waren (aus dem eigenen Haus). Inzwischen habe ich eh die Branche gewechselt und darf wieder richtiges C programmieren, ohne API direkt in Register schreiben und hab mein Powerpoint auch schon lange nicht mehr offen gehabt :-) Matthias schrieb: > Kennt ihr vielleicht > Literatur zu diesen Themen oder sind das so Sachen, die man sich im > Arbeitsleben selbst aneignet? Ich stimme für die zweite Variante. Gerade bei Abschlussarbeiten kann man sich da mehr auf "Neues lernen" konzentrieren und das "Produktive" etwas in den Hintergrund stellen. > 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. Du solltest Dir überlegen, ob Du eher in Richtung "Basissoftware" (teilweise hardwarenah) oder Applikation (die eigentliche Funktion des Steuergerätes) willst. Im ersten Fall könntest Du versuchen Dich über das Thema "AUTOSAR" schlau zu machen, im zweiten Fall wahrscheinlich eher "Modellgetriebene Softwareentwicklung" oder "Matlab/Simulink".
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).
Wir hatten uns hier Tcl so umgeschrieben, dass es auf größeren AVRs läuft. Je nach Bedarf können wir auswählen, welche Befehle mit eingepackt werden sollen. Da AVR bei uns ausläuft, wird das Paket demnächst auf ARM (hier STM32) portiert, dann ist da auch genug Platz für weitere schöne Dinge. Insbesondere würde ich demnächst gerne Tk von X auf Framebuffer (hier mit SSD1963) umschreiben. Dann hätte man eine sehr schöne Grafikbibliothek. Dazu noch eine Touchscreenerweiterung und ich wäre glücklich. Ja, das ist noch sehr viel Arbeit ... Auf jeden Fall ist das eine schöne Sache, weil man prinzipiell direkt auf dem Controller seine Shell einrichten und programmieren kann. Kein Compilerlauf, kein Linken. Programme kann man in Echtzeit ändern usw. Letztendlich soll es dann so sein, dass ich zumindest für alles GUI-mäßige die Programmteile in Ruhe auf dem PC in TCL/Tk schreibe und teste und dann nur noch ein Knöppken drücke und es auf den STM32 schiebe :-) Und wenn dann doch mal etwas wirklich schnell oder speziell sein muss, kann man Tcl schnell per C erweitern. Das ist aber zumindest hier sehr selten.
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?
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.