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!
naja auch bei embedded Linux gibt es C, also hardwarenahe Programmierung. Die Probleme dürften also geringer sein als befürchtet.
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.
Danke für die Rückmeldungen! Frageindenraumreinwerf: Ist "mein" AAEON GENE Board hier am Ende so etwas wie ein Raspberry?
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.
Alexander F. schrieb: > 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? Es kommt auf die Echtzeitanforderungen an. https://www.osadl.org/Single-View.111+M5f6c0e654c7.0.html http://www.osadl.org/Continuous-latency-monitoring.qa-farm-monitoring.0.html (da werden u.a. aktuelle Systeme mit i3, i7 gemessen)
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?
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.