Hallo!
Problem: Studium ist vorbei und ich muss Geld verdienen.
Glück1: zweite Bewerbung war schon Volltreffer.
Glück2: meine Firma entwickelt elektrotechnische Produkte.
Beispiel: ein autonomes Wasserfahrzeug mit allerhand Sensorik.
Pech1: der Entwicklungschef ist von Controllern überhaupt nicht angetan
(alter Linux- Hase) sondern schwört auf embedded Linux Boards
Pech2: mit Linux verbindet mich nix (aufgerundet). (geklauter Joke)
Zustand: vor mir liegt ein nacktes, kaltes, totes eLBoard.
Frage1: wie komm ich in die Materie?
Frage2: hab ich mir 6 Jahre µC-Schaltungen bauen umsonst beigebracht?
Das Board wird ja irgendwo gekauft worden sein und auch die
Linux-Distribution und die Toolchain (Compiler, Debugger).
Also dazu die Doku beschaffen und lesen.
Und dann ein "Hallo Welt" drauf laufen lassen.
Programmieren wie bei MCs wirst Du damit kaum, sondern einfach nur
fertige Lego-Steinchen zusammen schieben.
Da liegen doch sicherlich irgendwo EvalBoards rum? Unter den Nagel
krallen, anwerfen, los geht`s.
Es hilft sicherlich, wenn man auch einen Linux-Entwicklungsrechner (PC)
hat.
Da der Cheffe sich auskennt, hast du doch den perfekten Ansprechpartner.
Dass du mit Linux noch nichts gemacht hast, dürfte ja aus deiner
Bewerbung hervorgehen, also hast du die "Lizenz zum Fragen". Zumal du
Berufsanfänger bist.
Die ersten 6 Monate wirst du sicherlich "rumeiern", dann wirds besser
:-)
Also, Zähne zusammen beissen, einfach anfangen, zuhause mal
spasseshalber Linux aufsetzen.
Du kannst nur (Erfahrungen) gewinnen!
Zuerst solltest du eine passende Toolchain auf deinem PC installieren,
vorzugsweise ebenfalls unter Linux.
Wie du das Board wirklich zum Laufen bringst hängt jetzt von mehreren
Faktoren ab:
Liefert der Hersteller vielleicht sogar schon ein fertiges Image, von
dem du ausgehen kannst?
Ist das nicht der Fall, so musst du dir dieses Image selbst erstellen.
Das funktioniert für auf Debian basierende Distributionen mit
debootstrap.
Linux Embedded oder Windows Embedded verwendet man sobald Multimedia und
Connectivitaet gefragt ist. Ein peppiges hochaufloesendes GUI, mit
Ethernet, Bluetooth, WLAN, macht man besser mit einem ARM oder Atom wie
mit einem Controller.
Controller verwendet da wo es an die Hardware geht, schnelle IO
Vorgaenge gefragt sind.
http://www.aaeonusa.com/products/details/?item_id=1649
Wenn es sowas ist, dann definitiv NEIN. Es ist eine X86 Platform und
kein ARM. Das Ding ist so Leistungsfähig, da könnte sogar Windows 8
drauf.
Aber denk dran, gerad für solche Anwendungen
Stephan R schrieb:> ein autonomes Wasserfahrzeug mit allerhand Sensorik
ist Echtzeitverarbeitung gefragt. Deine Hardware könnte maximal als
Human-Maschine-Interface dienen und zum Anzeigen/Parametrieren. Die
Steuerung buw. Sensor/Aktor Schnittstelle sollte auf jeden Fall
Echtzeitfähig sein.
PS: Natürlich gibt es auch Echtzeiterweiterungen für Linux/Windows.
Das Board da ist nen normaler x86 PC (nur halt auf einer einzigen
Platine und paar speziellen Anschlüssen) da kannste auch Windows drauf
installieren wenn Du willst.
Und Du kannst Deine Software direkt auf dem Board oder halt auf dem x86
Rechner ganz normal mit dem gcc übersetzen oder irgendwas anderes nutzen
- brauchst nichtmal nen cross compiler wie bei Mikrocontrollern.
Die grundlegenden Linux Sachen bekommt auch ein 16 jähriger hin (ich
spreche aus Erfahrung ;-)).
4toTakoe schrieb:> Das Ding ist so Leistungsfähig...4toTakoe schrieb:> Deine Hardware könnte maximal als> Human-Maschine-Interface dienen...
Ääähm.. Dieses kleine Board ist soo leistungsfähig ABER könnte maximal
als HMI dienen?
Stephan R schrieb:> Ääähm.. Dieses kleine Board ist soo leistungsfähig ABER könnte maximal> als HMI dienen?
Der Echtzeitanforderung wegen, und fehlender Schnittstellen. In einem
Fahrzeug wird üblicherweise ein Bussystem verwendet und es gibt mehrere
Messwandler für die Sensorik. Also muss ohnehin eine
Aktor/Sensor-Schnitstelle irgendwo eingebaut sein/werden. Da kann auch
gleich ein richtiger Controller die Steuerung übenehmen und er
Embedded-PC übernimmt die Visualisierung und das Bling-Bling...
GENE heißt bei AAEON ziemlich viel...
Da gibt es dann Boards mit Intel ATOM, i3, i5, i7, Celeron, Core2Duo,
AMD G, Geode LX,
TI Omap
Marvell PXA, ...
Also nicht nur x86.
hmm studium vorbei, solltest du dann nicht ungefähr wissen was du hast
x86, ARM, etc. und auf dem studium ein werkzeug mit bekommen haben um
dich in die Materia einzuarbeiten? Oder wird das heutzutage nicht mehr
gelernt...
Also Pobacken zusammen und die nächsten durchackern und den chef
ausquetschen und los gehts - auch ja und nicht zuviel in mk.net herum
treiben ;)
Ich versuche grad ein wenig über den Tellerrand heraus zu schauen und in
meinem Gehirn eine Brücke (bzw Schneise) zwischen µC und embedded PC zu
schlagen.
Ist es also so, dass ich zum Betrieb des ePC ein Betriebssystem brauche.
Das werd ich jawohl kaum selber schreiben. Ich stelle mir also vor, mein
Laptop wäre ein ePC samt Betriebssystem:
Ich wüsste nicht, wie ich ein Lämpchen an PortXY zum Blinken bringen
sollte. Ich wüsste nicht mal, wonach ich suchen müsste, um auf ein
Portbeinchen zuzugreifen. VisualBasic?
Anderes Schlachtfeld (keine Detaillösung gefragt) : mal so rein optisch:
worin unterscheidet sich ein C- Programm, das für einen AVR geschrieben
wurde, von einem, das für einen z.B. ARM geschrieben wurde
(Pinbezeichnungen usw mal ausgenommen)? Verlangt ARM eine ganz andere
"Grammatik" oder würde eine Aufgabe für einen ARM, die in für AVR
geschriebenem Code gelöst werden soll, nur langsamer ausgeführt?
Fragen über Fragen..
exstudent schrieb:> hmm studium vorbei, solltest du dann nicht ungefähr wissen
Mechatronik und Feinwerktechnik studiert, da war nicht sooo viel µC. Ist
aber meine Leidenschaft und das soll meine Profession werden.
> Ich wüsste nicht, wie ich ein Lämpchen an PortXY zum Blinken bringen sollte.
Das ist unter Linux vom Ansatz her nicht weiter schwer.
Denn in allen Unixen gilt die Devise: Jeglicher I/O kann erst mal als
'File' aufgefasst werden. Da gibt es also eine spezielle Datei und wenn
man die öffnet und was reinschreibt, dann sorgt das System dafür, dass
das dann auch bei der Hardware landet.
> Ich wüsste nicht mal, wonach ich suchen müsste, um auf ein Portbeinchen
zuzugreifen.
Na, wo wohl?
In der zugehörigen Doku. Entweder auf der papierenen, auf der
Online-Hilfe (oftmals HTML) oder wenn alle Stricke reißen bei Tante
Googel.
Stephan R schrieb:> Ich versuche grad ein wenig über den Tellerrand heraus zu schauen und in> meinem Gehirn eine Brücke (bzw Schneise) zwischen µC und embedded PC zu> schlagen.>
Mach dir mal nicht zu viele Gedanken.
Der grösste Unterschied wird der Controller sein. Ein Atmel-AVR ist halt
kein ARM/x86. Besorg dir das Datenblatt/Refrencemanual um Controller,
dann siehst du wo das Problem liegt. Eventuell bist du dann sogar froh,
wenn du ein OS hast, das dir so manches abnimmt.
Trotzdem kannst du auf Portpins etc. ähnlich zugreifen, wie mit dem AVR.
Allerdings solltest du dir im Klaren sein, was du machst, sonst crasht
dein OS...
> Verlangt ARM eine ganz andere "Grammatik"
Hmm.
Was denkst du?
Warum sind führende Programmiersprachen wohl genormt?
Warum gibt es Gremien, die sich regelmässig treffen und darüber
diskutieren, wie und in welcher Form sich eine Programmiersprache
weiterentwickeln soll und diese Ergüsse dann in Form eines nächsten
Standards publizieren?
Stephan R schrieb:> sondern schwört auf embedded Linux Boards
Wenn du innerlich anders orientiert bist, also kein ausgesprochener
Linux-Fan, dann wird das in dieser Firma auf längere Zeit nix. Es wird
dann immer Reibereien geben, entweder zwischen dir und deinem Chef oder
innerhalb von dir. Beides macht nicht glücklich.
Ansonsten gebe ich den Vorrednern Recht: So ein PC-AllInOne-Board mit
nem Linux drauf taugt nicht für eine Fahrzeug-Automatisierung, sondern
wirlich nur als Treiber für ein schönes buntes User-Interface. Ich
schreib aus Erfahrung, hatte mal vor rund 20 Jahren Geräte mit
eingebautem PC104 entwickelt. Wir hatten jahrelang Streß mit den Kunden
- NIE WIEDER SOWAS!!!
Bedenke mal, daß so ein BS gebootet sein will und das dauert bei fast
jedem Linux ne halbe Ewigkeit, also 20 Sekunden mindestens. In der
Zwischenzeit ist dein Boot gestrandet oder vor nem Baum im Wasser
zerschellt. Nee, die eigentliche Steuerung gehört in einen µC mit
Programm im Flash, eingeschaltetem Watchdog und Startupzeiten im Bereich
von ner halben Sekunde oder weniger - und mit Interrupts, die SOFORT
reagieren können - nicht erst, wenn der Scheduler im BS meint, alle
anderen Threads hätten grad mal nix zu tun.
W.S.
Karl Heinz Buchegger schrieb:> Warum sind führende Programmiersprachen wohl genormt?
Heißt das, es gibt keinen C- Code, der nur von einem 32Bit, nicht aber
von einem 8-Bit- µC ausgeführt werden kann?
W.S. schrieb:> Board mit> nem Linux drauf taugt nicht für eine Fahrzeug-Automatisierung
Also eine Schnittstelle schaffen, mit der der für die Steuerung
verwendete µC mit dem GUI-Board redet?
Stephan R schrieb:> worin unterscheidet sich ein C- Programm, das für einen AVR geschrieben> wurde, von einem, das für einen z.B. ARM geschrieben wurde
Grob gesagt, ein ARM hat viel mehr Stellschrauben. 10 Init-Zeilen auf
dem AVR entsprechen etwa 100 Init-Zeilen auf dem ARM.
Der Hauptunterschied ist aber das IO-Handling.
Bei den ARM hat sich allgemein das Set-/Clear-Register Schema
durchgesetzt. Um einen Pin zu löschen, muß man ein 1-Bit an die Stelle
im Clearregister schreiben.
Ein gleichzeitiges Setzen und Löschen einzelner Pins ist also nicht
möglich.
Manche ARM können das allerdings doch. Die haben ein Maskenregister, wo
man zuerst die zu ändernden Pins einträgt und danach mit dem
Datenregister nur diese Pins ändert.
Aber mit nem OS sieht das eh alles ganz anders aus, da kannst Du
nirgends direkt zugreifen.
Stephan R schrieb:> Heißt das, es gibt keinen C- Code, der nur von einem 32Bit, nicht aber> von einem 8-Bit- µC ausgeführt werden kann?
So ist es. Solange beide genügend Speicher haben.
W.S. schrieb:> Stephan R schrieb:>> sondern schwört auf embedded Linux Boards> Bedenke mal, daß so ein BS gebootet sein will und das dauert bei fast> jedem Linux ne halbe Ewigkeit, also 20 Sekunden mindestens. In der> Zwischenzeit ist dein Boot gestrandet oder vor nem Baum im Wasser> zerschellt.
Nun, es gibt auch Boards, die wesentlich schneller Booten (0,69s):
http://www.embeddedarm.com/products/board-detail.php?product=TS-7800> Nee, die eigentliche Steuerung gehört in einen µC mit> Programm im Flash, eingeschaltetem Watchdog und Startupzeiten im Bereich> von ner halben Sekunde oder weniger - und mit Interrupts, die SOFORT> reagieren können - nicht erst, wenn der Scheduler im BS meint, alle> anderen Threads hätten grad mal nix zu tun.
Dazu gibt es Realtime Kernel oder man benutzt die Vorteile aus beiden
Welten wie beim AM335x des BeagleBones z.B.. Der hat zwei PRUSS an
Board, die unabhängig vom Hauptprozessor laufen. Siehe z.B.:
http://www.phytec.de/fileadmin/user_upload/pictures/Produkte/Microcontroller-Boards/D_phyCORE-AM335x.pdf
Gruß
Gerd
Hier wird ja immer wieder geschrieben, dass man Echtzeitanwendungen eher
in einen eigenen Controller auslagern soll und das Board nur als HMI
benutzen soll.
Wie sieht es eigentlich mit RTLinux oder der RTAI Erweiterung aus?
Hat damit jemand Erfahrung?
Für einen Anfänger ist das wahrscheinlich dennoch nicht geeignet.
>ist Echtzeitverarbeitung gefragt. Deine Hardware könnte maximal als>Human-Maschine-Interface dienen und zum Anzeigen/Parametrieren. Die>Steuerung buw. Sensor/Aktor Schnittstelle sollte auf jeden Fall>Echtzeitfähig sein.
Die X86-Hardware wäre wohl auch echtzeitfähig, wenn die darauf laufende
Softw. (bsp. langsames OS) das nicht bremsen würde.
>Der Hauptunterschied ist aber das IO-Handling.>Bei den ARM hat sich allgemein das Set-/Clear-Register Schema>durchgesetzt. Um einen Pin zu löschen, muß man ein 1-Bit an die Stelle>im Clearregister schreiben.>Ein gleichzeitiges Setzen und Löschen einzelner Pins ist also nicht>möglich.
Direkt beschreibbare Out-Reg sind eigentlich Std. (bei jedem uC).
Set-/Clear-Register bieten (sofern vorhanden) zusätzliche Möglichkeiten.
Eumel schrieb:> Stephan R schrieb:>> Heißt das, es gibt keinen C- Code, der nur von einem 32Bit, nicht aber>> von einem 8-Bit- µC ausgeführt werden kann?>> So ist es. Solange beide genügend Speicher haben.
Hallo!
Hier muss ich mal gewaltig widersprechen. Mir fallen aus dem Stand 5
Beispiele ein, die auf 32Bit anders sind als auf 8Bit:
- Integer-Größe: Lest bitte mal nach, wie breit ein "int" bei
AVR/8051/... ist. Auf 32 Bit ARM ist das 32 Bit.
- Endianness: Ist die Architektur Little- oder Big Endian? Bei 32 Bit
ist es meist festgelegt, bei 8 Bit Systemen macht das jeder Compiler
anders (GCC macht bspw little endian)
- Alignment von Variablen; packed structures, usw., bspw:
1
{
2
uint8_t bla;
3
uint32_t foo;
4
uint8_t bar;
5
}
Der ARM GCC fügt defaultmäßig nach dem ersten uint8_t drei Padding-Bytes
ein! Der AVR GCC macht das nicht.
- ist ein "char" signed oder unsigned?
- Die Größe eines "Byte":
In C ist ja ein "char" definiert als "1 Byte". Bei TMS320F2808 bspw. ist
ein Byte aber 16 Bit breit.
---
Dazu kommen noch die ganzen Compilererweiterungen wie Interrupts, Pragma
usw.
Dazu kommen noch schrottige Compiler wie der 8051 Keil, die nicht
richtig mit dem Stack umgehen und stattdessen Overlays machen, mit
Funktionspointern nicht gut klar kommen usw usf.
Von einem "über alles erhabenen" C-Standard kann also keine Rede sein.
Man muss genau wissen was man tut, und lieber ein Paar Stunden/Tage mehr
in eine Portierung stecken als zu wenig.
Phantomix Ximotnahp schrieb:> Hier muss ich mal gewaltig widersprechen.
Ja, ich dir auch:
> - Integer-Größe:
Du weißt ganz genau, daß ein int garantiert 16 Bit haben muß und man
garantiert nicht erwarten darf, daß es mehr als 16 Bit hat (obwohl es
das bei einigen µC haben kann - aber eben nicht muss).
Wer nicht doof herumprogrammiert, der wird von einem int also niemals
mehr als 16 Bit erwarten und bei größerem Bedarf eben long wählen.
> - Endianness:
Das hat mit der Prozessorbitbreite nur wenig zu tun, bei 8 Bit Systemen
wird dies eher von der Breite der Zeigerregister (PC, SP, usw.)
abhängen.
Ansonsten geb ich dir voll Recht: Eumel liegt schlichtweg falsch mit
seiner Ansicht und der Glaube, daß gerade im µC-Bereich irgendwelcher
C-Code lustig portierbar sei, ist ein Fehlglaube. Das Einzige, was
wirklich portierbar ist, sind Funktionsprinzipien, also wie man als
Programmierer eine Aufgabe angeht und löst - und das ist sogar über
relativ viele verschiedene Programmiersprachen portierbar.
W.S.
Phantomix Ximotnahp schrieb:> Dazu kommen noch schrottige Compiler wie der 8051 Keil, die nicht> richtig mit dem Stack umgehen und stattdessen Overlays machen, mit> Funktionspointern nicht gut klar kommen usw usf.
Was ist daran schrottig, wenn der Compiler effizienten Code erzeugt,
anstatt mit Push/Pop-Orgien Flash und CPU-Zeit zu verschleudern.
Der 8051 läuft typisch nicht mit 1GHz und hat auch keine 1MB Flash.
Daher muß man schon etwas auf Effizienz achten.
Rekursive Funktionen braucht man eh kaum, und falls doch, dann sagt man
es einfach dem Compiler, aber dann nur für diese Funktion.
Ich hatte mit Funktionspointern noch nie Probleme, welche C51-Version
meinst Du denn?
Selbst mit Funktionspointern macht er den Calling-Tree für das Overlay
korrekt.
Phantomix Ximotnahp schrieb:> Eumel schrieb:>> Stephan R schrieb:>>> Heißt das, es gibt keinen C- Code, der nur von einem 32Bit, nicht aber>>> von einem 8-Bit- µC ausgeführt werden kann?>>>> So ist es. Solange beide genügend Speicher haben.>>>> Hallo!>> Hier muss ich mal gewaltig widersprechen. Mir fallen aus dem Stand 5> Beispiele ein, die auf 32Bit anders sind als auf 8Bit:
Die irrelevant sind. Alle bekannten Controller sind turing-vollständig
d.h. könnten alles berechnen was auch eine universelle Turing-Maschine
berechnen könnte. Gleiches gilt für die gängigen Programmiersprachen.
Anders formuliert heißt das nichts anderes als die sich alle gegenseitig
emulieren könnten.
Arc Net schrieb:> Anders formuliert heißt das nichts anderes als die sich alle gegenseitig> emulieren könnten.
Die berechnen aber meines Wissens in der Realit"at nicht mathematische
Funktionen. Emulier mal mit 'nem 8-bitter den atomaren Zugriff auf den
Speicher bei 'nem 32-Bitter und Interrupts, hehe!
Embedded Linux erfordert zuerst mal eines: Sich in die Treiber
Schreiberei einzuarbeiten, wenn das auf deinem Board nicht schon vorher
geschehen ist.
Am besten macht man das, indem man sich vorhandene Treiber anschaut und
für seine Zwecke umstrickt. Programme im Userspace dürfen genauso wie
bei Windows erstmal nicht an irgendwelcher Hardware rumfummeln, ohne das
das geordnete Wege geht über /dev , /proc oder über seine neueren
Nachfahren wie /udev.
Die Programmierung von Userspace Programmen unterscheidet sich dann
nicht gross von jedem anderen Betriebssystem.
Und warum sollte ein millionenfach auf Routern, Set-Top Boxen usw.
eingesetztes BS wie Linux nicht für ein Wasserfahrzeug gehen?
