Mich würde interessieren, was man so können sollte, wenn man als Embedded Systems Entwickler arbeiten möchte. Ich hab' mein Studium nicht abgeschlossen, würde aber gerne jetzt arbeiten gehen und den Abschluss nebenher machen. C, C++ ist klar, haben wir alles gemacht, auch auf MCs. Ich hab' zusätzlich den Softwarezweig studiert, kenn' mich also auch mit OOP, UML,.... und den ganzen lustigen Sachen aus. Was mir irgendwie nur fehlt: was sollte man für den kompletten Entwicklungszyklus können? Wir haben embedded die Spezifikation bekommen und einfach C runterprogrammiert. Haben Elemente des SE gar nichts verloren? Teilweise habe ich Meinungen gelesen, dass doch auch für Embedded Systems mit UML gezeichnet wird? Gibt's Tools/IDEs/Simulatoren/... die besonders wichtig sind? Ich hab' hauptsächlich mit avr-gcc bzw. AVR Studio gearbeitet zum Debuggen. Naja, auf jeden Fall, vom Studium kenn ich's alles, mich würde interessieren, was mir für einen Job als Entwickler helfen würde, seien es Techniken zu lernen, Bücher,.... was auch immer. Danke schon mal!
Also ziemlich wichtig finde ich, daß Du lernst einen MC auf Assemblerebene zu programmieren. Dadurch lernst Du auch das Programmiermodell und hardwarenahes Denken. Weiterhin sollte man einen Mikrocontroller in der Hardware designen können, also sprich das Evaluationsboard selber bauen. Signalverarbeutungsalgorithmen (Filter, FFT, Wavelet-Transf., z-Transf. usw,) Eine Akkumaschine, Register-direkt-Maschine, v. Neumann-, Harvardarchitektur auseinanderhalten können. Bestimmte Seiteneffekte bei Pipeline-Architekturen kennen, einen Mnemonische vom algebraischen Assembler unterscheiden können. Hardwarenahes C beherrschen, C++ eher selten. DIe IDE's kriegt man meist im Beruf mit, je nach µC. Häufig sind Keil µVision, Eclipse, Metrowerks oder IAR. Schnittstellenstadards: SPI, I2C, CAN, RS232, RS485, evtl. Profibus DP/PA usw. Allerdings solltest Du schon einen Abschluß machen, denn das ist oftmals die formale Eintrittskarte, auch wenn Du sonst alles beherrschen solltest.
Danke für die Antwort! Ja, ASM hab' ich auch programmiert auf MCs, ich glaub', die Hardware kenn' ich schon einigermaßen von daher. Die Schnittstellen kenn' ich auch größtenteils, verwendet hauptsächlich RS232 am MC. Signalverarbeitungsalgorithmen hab' ich mal können ;) weiß zwar noch wozu und so, aber könnte ich auf Anhieb definitiv nicht. Wo genau verwendet man das bei Embedded Systems? Ich hätte gedacht, die werden ohnehin in Hardware implementiert... Naja, aber eigentlich fang' ich schon was an mit dem meisten, was du schreibst, find' ich schon mal gut ;) Mit dem Abschluss hast du sicher recht - aber war das eher auf Einstieg oder bessere Position bezogen? Ich hätte halt gern etwas Praxis und würde schon sehr gern arbeiten. Aber ohnehin keinesfalls Vollzeit, Studium wird abgeschlossen. Hab' erst begonnen, Bewerbungen zu schreiben und überrascht positive Antworten gekriegt ;) also würd' ich's gern auch ohne Abschluss mal probieren, im Fach zu arbeiten und nicht irgendwas nebenbei.
Signalverarbeitung und die Algorithmen sind eigentlich das A und O jeder CD, MP3 DVD oder sonstwas player ; eigentlich in jedem etwas gescheitem embedded system ist signalverarbeitung bzw. digitale regelung mit dringmit drin. also man sollte sich schon etwas auseinander setzen unde den unterschied zwischen FR , FTA , DFT und FFT kennen, daraus dann die IIR, FIR filter. Auto und kreuz korrelation gehört natürlich auch dazu. Joa und bei der regelungstechnik, halt z-trafo wichtig, Kompensationsregler, Dead Beat eher seltener .... Aber im grunde ist egal weches stück elektronik du dir anschaust irgendwo nen regler drin. Selbst innerhalb deiner software, wenn du informationen von einer task an die andere übergeben willst usw.... kommt natürlich auch immer auf den bereich drauf an wo du arbeiten möchtest. industrieelektronik , unterhaltungselektronik ? ... mfg
@STS Hoffe du musst niemanden einstellen... meine deine anforderungen sind schlicht überrissen... (äh unter können versteh ich mehr als nur etwas mal gehört haben, oder kurz ein beispiel im studium angeschaut haben...) Schlussendlich kann einer, der direkt vom studium kommt rein gar nix was mit dem fachlichen zu tun hat... ABER er hat gelernt das ganze schnell zu lernen, sich schnell in themen einzuarbeiten, er hat einen gewissen theoretischen background... (p.s. diese aussage ist nicht im geringsten abwertend gemeint, ist und war meiner meinung nach bei allen so...)
>Die Schnittstellen kenn' ich auch größtenteils, verwendet hauptsächlich
RS232 am MC.
Na. Da kommt schon noch was hinzu.
Bisher machten Ingenbieure mit 15 und mehr Jahren Erfahrung auf allen moeglichen Gebieten Embedded Systeme. Dies, weil man dazu auch all die anderen Disziplinen braucht. Ein Controller und seine Programmiereung war mur ein Teil. Dazu kommt seine Anbindung an eine externes System, resp ein Verbund von Systemen. Die Kommunikation dazu, die Protokolle, die Programmierung externer Systeme. Dazu kommt, dass ein Controler alleine wenig macht, er hat meist noch irgendwelche Analogik, Sensorrik, Aktuatoren. Dann steht das System irgendwo und macht irgendwas. Dh man hat eine Schnittstelle zu anderen Disziplinen. Man redet mit Chemikern, Physikern, Medizinern, und deren Sprache ist sehr verschieden zur Ingenieurssprache auch wenn sie ueber Dasselbe reden. Fuer einen Ingenieur ist eine Spezifikation etwas, was man nur zu 60% hingeht. Heisst ein Netzteil mit 1A wird nur hoechstens mit 600mA belastet. Ein Physiker hingegen betrachtet einen Spezifikation als eine statistische Aussage des Herstellers, die kann man auch mal 20% ueberschreiten. Der Unterschied zwischen diesen zwei Gesichtspunkten : Der Ingenieur moechte das Geraet die nachsten 10k Stunden laufen sehen, und nie mehr was davon hoeren. Der Physiker moechte das Experiment machen und nachher interessiert es ihn nicht mehr. Das Geraet wird mit einer gewissen Wahrscheinlichkeit im Schrank verschwinden und nach 10 Jahren entsorgt. Mediziner reden von einem zuverlaessigen Medikament, einer zuverlaesigen Behandlung wenn sie in 2 von 3 Faellen wirkt. Ein Ingenieur redet von Zuverlaessigkeit in Anzahl 10k Stunden, in Millionen von Schaltspielen. Daher ist alleine ein Embbeded System zu bauen, etwas, das ein Ingenieur gegen 40 anfaengt. Soll aber nicht demotivierend wirken.
>Daher ist alleine ein Embbeded System zu bauen, etwas, das ein Ingenieur >gegen 40 anfaengt. Da frage ich mich bloß, was ich seit 9 Jahren mache, nach Abschluß des Studiums, und ich bin noch nicht 40. @David. Ich habe lediglich geschildert, was so an Aufgaben wartet. Und er wollte das ja wissen. Vieles davon wird bereits im Studium theoretisch besprochen. Das Problem ist halt die Umsetzung ins Praktische. Bei meinem ersten Job wurde ich auch ins kalte Wasser geschmissen: Programmierung einer Rauschminderung mit anschliedßender Fourieranalyse für ein optisches System. Und rundherum nur Physiker (Optik)...
Ja, richtig, ich wollte wissen, was auf mich zukommt ;) Warum ich wegen DSP so seltsam gefragt habe: ich interessiere mich mehr für den Kommunikationsbereich, also Aufteilung auf mehrere MCs. Das heißt nicht, dass ich schreiend aus dem Fenster springe, wenn ich mal was mit einer FFT etc. zu tun bekomme. Klar, RS232 ist nicht alles. Dafür haben wir ein Kommunikationsprotokoll entworfen und implementiert, den Rest kenn' ich halt nur theoretisch. Wenn jemand von einem Uniabsolventen erwartet, mit allen Protokollen etwas Komplexes gebaut zu haben, würde ich ihm raten, aufzuwachen ;) Ja, ich war einfach neugierig, was so in der großen weiten Welt von Bedeutung ist, damit ich mich etwas drauf einstellen kann bei der Jobsuche. Denke, das ist eine berechtigte Frage. Ich seh' jetzt im Vordergrund DSP und Kommunikationsprotokolle, ist auch eine interessante Information für mich. Hätte gedacht, das eher bestimmte Entwicklungsprozesse genannt werden, die auf der doch eher theoretischen Uni untergehen.
Nicht fragen, einfach arbeiten gehen, sich reinarbeiten und machen! Wer fragt, zeigt, das er innere Ängste überwinden muss und wenig Selbstvertrauen besitzt.
>>Daher ist alleine ein Embbeded System zu bauen, etwas, das ein Ingenieur >>gegen 40 anfaengt. >Da frage ich mich bloß, was ich seit 9 Jahren mache, nach Abschluß des >Studiums, und ich bin noch nicht 40. Der Fokus der Aussage war auf "Alleine". Ohne die Physiker rund herum. Als junger Ingenieur macht man was von irgendwoher in der Firma spezifiziert wird. Da meist auch fachfremde Leute am Projekt beteiligt sind sollte man unterscheiden, was von Aussen kommt und was von Innen kommt. Auswaertige, ob Kunden, oder auch Ausfuehrende, haben immer Wuensche, aber den Lohn wird von der Firma bezahlt. Daher bestimmt auch jemand aus der Firma was implementiert wird. Irgendwann ist man dann der in der Firma, der gegenueber Fachfremden oder aeusseren Personen definiert was und wie's gemacht wird. Und da sollte man nicht zu jung sein. Ja, ich war auch mal in der Position, dieser zu sein, da die Geschaeftsleitung eh keine Ahnung hatte. Die externen Anforderungen wuchsen und wuchsen und wir waren als 5 Manfirma im Boot mit Weltfirmen mit tausenden Angestellten. Die kleinste Konkurrenz hatte 10 mal mehr Leute. Da waer's auch besser gewesen 15 Jahre aelter zu sein. Nein, nicht wegen Fachfragen. Wegen den nicht-Fachfragen. Ein Embedded system ist eines kleines Aestchen an einem Baum. Und sobald der Baum involviert ist, genuegt der Jungingenieur nicht mehr. Da muss ein Alter her. Wegen den Nicht-Fachfragen. Es sollte natuerlich genauso eine Ahnung haben. Glaubt's mir einfach. Bei einer falschen Entscheidung gehen die Hunderttausender nur so weg, und als Junger ist man sich teilweise gar nicht im klaren darueber ueberhaupt eine Entscheidung getroffen zu haben. Eine unguenstige Aussage an einer Sitzung, ohne Unterschrift, und eine Viertelmillion ist weg. Das merkt man aber erst viel spaeter, wenn ueberhaupt.
@ Gast (Gast), was auf dich zukommt... Du hast mittlerweile viel gelernt, das ist aber erst der Anfang. Die Geschwindigkeit der neuen Dinge, die es zu lernen gibt wir sogar noch exponentiell zunehmen. Man kann natuerlich immer aussteigen, durch die Einwegtuere natuerlich, in den Verkauf, und in die Schulung. Als Abgaenger ist weniger wichtig was man schon kann, als was man sich zutraut noch zu lernen. Die Auswahl was man denn machen und kann will ist natuerlich begrenzt, da das Gebiet sehr viel schneller waechst, als man lernen kann. Daher sollte man sich auch ein paar Punkte, wo Nachfrage ist pflegen. Jeder Punkt, wo man spaeter mal sagen kann, hat man auch angeschaut, ist eine zusaetzliche Jobchance. Dabei sollte man sich im Mainstream bewegen und auch nicht. Als ich Absolvent war, Anfang der 80er gingen alle Kollegen sukzessive in die Software. Das war derart neu, dass es nur uns gab. Mittlerweile gibt es Informatiker. Mit denen muss ich nich konkurrieren. Daher hab sehr schnell gefunden, das Datenbankzeugs ueberlass ich denen. Man muss schnell auf eine neue Welle aufspringen koennen, aber genauso schnell wieder drunten sein. Un dann gibt es auch noch absteigende Aeste. Sollt man sich fernhalten. ZB Wehrtechnik.
>Der Fokus der Aussage war auf "Alleine". Ohne die Physiker rund herum.
Wie geschrieben. Die kamen von der Optikschiene. Ein embedded-System
konnte von denen keiner dimensionieren, aufbauen oder programmieren. Da
ging es nach dem Motto: Wenn Du nicht, kommt der nächste. Ich bin
geblieben :)
Ja. Ja. Aber wenn die sagen was sie haben wollen, resp verkaufen koennen, ist die halbe Arbeit schon gemacht. Ohne deine Arbeit schmaelern zu wollen, Hut, ab, zu einem Produkt ist noch ein weiter Weg.
Was die haben wollten: Eine Elektronik, die einen 100 kHz gepulsten Laser ansteuert (incl. Lasertreiber mit Monitor). Phasensynchronisert die 2 Kanäle einer PSD einlesen, diese Signale innerhalb von 10 µs vom Rauschen befreien, in die Fourierbestandteile zerlegen, an einen PC ausgeben mit FIFO. Ihr Aufgabengebiet war die refl. Optik, der Laser an sich und dann ab PC. Als Einsteiger vom Studium schwitzt man da erst mal ganz schön, v. a. wenn man einen DSP auswählen soll, ohne das man weiß, ob die Ressourcen wirklich reichen. Dazu Schaltplan, Layout, Programm.
tja leute, was ihr hier beschreibt ist die klassische schule. moderne
entwicklungen erfordern zunehmend kenntnisse von entwicklungsprozessen
und werkzeugen. dass betrifft vor allem entwicklungen in der industrie,
nicht so sehr die entwicklung von prototypen und kleinserien.
ich kann dem fragesteller nur empfehlen, seine kenntnisse aus der
softwareentwicklung in richtung der SE für eingebettete systeme zu
vertiefen. es gibt einiges an literatur dazu. suche einfach mal nach
Bruce Powel Douglass ("Real Time UML" - Buch, Rhapsody - Tool). da
findest du einen guten einstieg. es gibt aber noch andere interessante
prozesse und werkzeuge.
Fragt sich bloß, ob er diese jemals in KMU's anwanden wird.
Aber sicher in den KMUs. Die sind meist in der Technologie vorne. Die grossen Laeden kannst du vergessen. Die verlieren sich in unnuetzten Sitzungen, langen Entscheidungswegen und aufgeblaehten Strukturen. Man kann kann in einem kleineren Laden keine zehn Projekte in den Sand setzen, muss eher brauchbaren Output liefern.
> Schlussendlich kann einer, der direkt vom studium kommt rein gar nix was > mit dem fachlichen zu tun hat... Hmmm...ein gewisser Teil der Studenten befasst sich durchaus auch hobbymässig mit seinem Studium, da lernt man doch so einiges. > Fragt sich bloß, ob er diese jemals in KMU's anwanden wird. Durchaus. Schau dich nur mal um, wie viele davon aus irgendwelchen Forschungsarbeiten an Universitäten hervorgegangen sind.
Was braucht man? a) Mut (zum Sprung ins kalte Wasser) b) Selbstbewusstsein (nicht zuviel, siehe auch a) c) Bereitschaft zum lernen Lernen LERNEN (es will nicht aufhören) d) Freude an der Arbeit (das ist nicht immer leicht, Normen machen zB keine Freude) Ich hab es geschafft, viele andere haben es geschafft, Du wirst es auch schaffen (siehe a-d).
Die Frage ist doch, ob die KMU's und Startup's das Geld aufbringen und dann auch inverstieren, um Designtools anzuschaffen. Meist wird doch aus "Sch...e Bonbon" gemacht. Die Notlösung ist oft auch die Raubkopie. Oder man hat einen "Kooperationsvertrag" mit einer Hochschule, d. h. die teuren Geräte oder auch Software wird nicht selbst angeschafft, sondern an Uni/FH genutzt.
Ein Designtool, das sich rechnet wird angeschafft. In einer KMU muss man rechnen was etwas bringt. Man nimmt nicht einfach ein Mentor, wenn ein Protel es auch tut. Im Konzern faehrt man eine float License vom teuten Produkt zum vergleichsweise guenstigen Preis, waehrend man als KMU nicht von hohen Stueckzahlen profitieren kann und daher falls passend das guenstigere Produkt eingesetzt wird. Im Konzern hat man ein standardisierungs buero mit einem Sesselkleber drin, der spezifiziert, wie alle Software dokumentiert werden muss. Dazu passend ist dann ein Doku-package. In der KMU malt man sich dann ev ein Diagramm auf Papier. Oder mit Corel Draw.
@STS Dieses Problem besteht zweifellos und man findet diese Design-Tools meist in größeren Firmen. Die von dir beschriebenen Notlösungen kann ich aus eigener Erfahrung bestätigen. Aber auch ohne teure Tools sind Kenntnisse zu Entwicklungsprozessen und allem was damit verbunden ist sehr hilfreich. Ich kann aus eigener Erfahrung bestätigen, dass die Entwicklung wesentlich strukturierter und sauberer erfolgt. Es gibt dabei aber leider ein weiteres Problem: Vorgesetzte begrüßen die Ergebnisse solche Entwicklungsprozesse, ich sage nur Doku oder QMS. Aber leider sind sie nicht so gern bereit für die Einarbeitung in solche Prozesse Zeit zur Verfügung zu stellen. Deshalb empfehle ich jede Gelegenheit dazu zu nutzen.
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.