Embedded Systems:Frisch vom Studium - was sollte man können

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.

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.