Richtung Hardware oder Software?

got2b schrieb:
> Ich habe das Gefühl, jeder
> halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester
> reines Informatik studiert hat.

Pfft!

Sobald es Hardwarenahe Programmierung ist, kannst du mindestens 9 von 10 
Informatiker in der Pfeife rauchen.

=> Embedded, Steuergeräte ect.. das ist der Bereich, wo EIT zum tragen 
kommt.

Mach dir keinen Kopf!

Wenn es jedoch um reine klassische Softwareentwicklung geht, bist du im 
falschen Studiengang.

got2b schrieb:
> kann mir jemand etwas erzählen, wie es für einen
> Elektro-/Informationstechniker (B. Eng.  FH) in der SW-Entwicklung
> aussieht?

Sonnig, mal heiter bis wolkig. Scherz beiseite.
Gewöhnlich macht man die Hardware im Labor und die Software
am PC. Wobei man sich das nicht so klinisch vorstellen muss.

Entscheidend sind die Aufgaben und welche Werkzeuge
man bereitgestellt bekommt. Meist kann man da ja mit reden.

> Ich kann mir im Moment nur auf Dauer langweiliges C(++)
> programmieren darunter vorstellen.

Bei Anlagen wird das wohl auch so verwandt werden, aber bei Geräten
(embedded Systems) wird man mit C arbeiten können.

> Kann man in diesen Job auch z.B.
> Systemtheorie, Numerik mit einbeziehen?

Ich vermute mal, bei Anlagen ja, bei Embedded eher weniger.
Hängt eben von der App ab.

> Ich habe das Gefühl, jeder
> halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester
> reines Informatik studiert hat.

In Software vielleicht, aber nicht in Hardware. Kommt halt drauf an
ob du mit Hardware im Projekt konfrontiert wirst.

Der Eunuch erzählt wieder, wie man es macht..

In meiner Firma würde ich die Programmieraufgaben in drei Gebiete 
einteilen (welche jeweils von unterschiedlichen Kollen mit Abschluss 
B.Eng./M.Eng./Dipl.-Ing. bedient werden).

1) uC-Kleinkram

Analoge Schaltungsteile entwerfen, welche mithilfe von Mikrocontrollern 
eine digitale Schnittstelle erhalten. Programmierung hauptsächlich in C, 
sehr hardwarenah, Herausforderungen liegen darin unterschiedliche 
Schnittstellen möglichst resourcenarm zu implementieren, Steuerungs- und 
Reglungsaufgaben entsprechend effektiv zu gestalten und möglichst 
robusten und fehlerunanfälligen Code zu produzieren.

Beispiel: Strom- und Spannungsüberwachung von einem Netzteil mit 
Schaltfunktionen, Kurzschluss-/Überlasterkennung, Lüftersteuerung, 
seriellem Interface etc.

2) uC-Großkram

Programmierung von ARM-Controllern und/oder FPGAs in C++ resp. VHDL, je 
nach Projekt hardwarenah oder mit RTOSsen bzw. selbst(zu)entwickelten 
Betriebssystemen. Kernpunkte sind Kommunikation mit 1) und 3), ergo 
Schnittstellen, Speichermanagement und Implementierung von Reglern, 
Motorsteuerungen, etc. Dabei ist ein Großteil der Zeit Reglerentwurf und 
-verifizierung. Das Programmieren ist mehr Mittel zum Zweck.

Beipiel: Algorithmus zum Gleichgewicht halten bei einem dreibeinigen 
Roboter, welcher auf einem Gummiball steht, seine aktuelle Positionen 
von Modulen aus Kategorie 1) erhält, diese verarbeitet und wieder an 
Module aus Kategorie 1) weitergibt sowie einen Kamerastream an 3) 
weitergibt.

3) UI

Als drittes Gebiet sind die Kollegen, welche die Benutzerschnittstellen 
programmieren. Das geschieht hauptsächlich mit C++ und Perl auf 
*nix-Systemen (bei uns). Dabei steht Anwenderfreundlichkeit und 
Implementation von Protokollen, Diagnosesystemen, Datenloggern und 
Ähnliches im Vordergrund.

Beispiel: Treiber schreiben, welcher von 2) einen Videostream über z.B. 
USB von 2) erhält und diesen an einen Apache Webserver weiterreicht, 
welcher das Videosignal auf einer Website als Live-Bild verfügbar macht.

Wie du siehst wäre für Teil 1) und 2) ein (reiner) Informatiker eher 
ungeeignet, da Hardwareentwicklung und ein tiefes Verständnis von 
analoger und digitaler Schaltungstechnik extrem wichtig ist. Zudem sind 
Kenntnisse in Systemtheorie und Regelungstechnik absolut wichtig um 
funktionierende Regelschleifen implementieren zu können, Modelle zu 
erstellen und Fehler zu erkennen. Punkt 3) ist wahrscheinlich eher, was 
du dir als "Programmierer" vorstellst, was jedoch in Firmen mit 
Entwicklungs- und Forschungsarbeit nur ein kleiner Teil ist/sein kann.

Die Tatsache, dass sowohl Informatiker als auch Ingenieure Software 
entwickeln wird für immer und ewig Identitätskrisen auf beiden Seiten 
hervorrufen. Eine Lösung wäre es, die Lizenz zum Programmieren an ein/e 
Studium/Ausbildung mit "Informatik" im Namen zu koppeln. So wie nur ein 
Mediziner den Beruf des Arztes ausüben darf.
duckundweg

>jeder halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester
reines Informatik studiert hat.

Tatsachlich ? Allenfalls von einer Datenbank einen Drucker ansteuern. 
Eine Excel Liste ausdrucken.

Sich von C++ demotivieren zu lassen ist unnoetig. Es ist leider eine der 
Eigenschaften dieser Spreche, die Leute zu demotivieren.

Nein. Es gibt beliebig viele Moeglichkeiten. Auch ohne C++, oder nur 
wenig.
Der effektive Code ist das Kleinste am ganzen Projekt. Die Applikation, 
das System soll sicher und zuverlaessig sein. Bevor man eine Zeile Code 
geschrieben hat, hat man sich mit einer Seite an Anforderungen dazu 
auseinandergesetzt. Sehr spannend, und einer muss es ja machen.

zB Wie schaff ich es, dass mir ein Tesla nicht in einen Lastwagen 
reinfaehrt. Dabei ist der Code das absolut Kleinste. Hier ist nicht der 
der Groesste, der am meisten Zeilen schreibt.

got2b schrieb:
> Kann man in diesen Job auch z.B.
> Systemtheorie, Numerik mit einbeziehen?

Eher selten bis gar nicht, meiner Erfahrung nach. Wichtig an 
Systemtheorie ist eher die Fähigkeit, in Systemen denken zu können, 
besonders mit Rückkopplung.

> Ich habe das Gefühl, jeder
> halbwegs anständige Informatiker ist mir überlegen, da er 7 Semester
> reines Informatik studiert hat.

Der wird aber überfordert sein, wenn er mal ein Oszi rausholen soll, um 
Timings nachzumessen. Oder auch sonst immer, wenn es hardwarenah wird.

Mal ein Beispiel, man möchte predictive maintenance für ein Kraftwerk 
aufbauen. Wartung bedingt Ausfallzeiten, die kosten Geld. Man will also 
nicht mehr warten als nötig. Andererseits bewirkt zu späte Wartung 
größere Schäden als nötig, also möchte man soviel warten wie nötig.

Die Ingenieure setzt man daran, die Sensorik zu konzipieren, mit 
allerhand Kleingeräten und Microcontrollern Daten zu erfassen, 
aufzubereiten und an ein Zentralsystem zu schicken. Dann wissen sie aber 
weder, was sie mit den Unmengen an Daten tun sollen, noch, wie sie sie 
organisieren sollen.

Die Informatiker haben zwar keine Ahnung, wie sie die Daten rankriegen 
sollen, aber wenn sie sie erstmal haben, können sie sich Gedanken 
machen, wie man sie formt und was man damit nun anfangen soll.

Beide können Software machen, aber die Ingenieure eher konkret, die 
Informatiker eher abstrakt. Es sind unterschiedliche Aufgaben, die sich 
erst im Team ergänzen.

Oder wenn man ein größeres Mikrocontroller-Projekt hat. Einen 
Informatiker würde ich daran setzen, die Struktur auszuarbeiten, aber 
die Ingenieure für den Inhalt. Setzt Du nur Ingenieure ran, wird das 
Ergebnis meistens ziemlich chaotisches Spaghettizeug sein, was zwar 
funktioniert, sich aber besch..eiden warten läßt. BTDT.

Nop schrieb:
> Beide können Software machen, aber die Ingenieure eher konkret, die
> Informatiker eher abstrakt.

Das kann man durchaus am zeitlichen Verhalten von Routinen feststellen:

Bei den Ingenieuren dauert die gleiche Funktion 1 mS
bei den Informatikern 1000 mS. (gefühlt noch länger ;-)

il Conte schrieb:
> Bei den Ingenieuren dauert die gleiche Funktion 1 mS
> bei den Informatikern 1000 mS. (gefühlt noch länger ;-)

Bei einzelnen Routinen vielleicht, aber im Gesamtpaket sieht es anders 
aus. Etwa bei einem Suchbaum würden Ingenieure zwar die Hardware 
effizienter nutzen, aber die Informatiker kämen mit Ideen, wie man den 
ganzen Suchbaum beschneidet. Die Expertise für die Effizienz liegt 
einfach auf unterschiedlichenen Ebenen.

жтампф ден троль schrieb:
> zB Wie schaff ich es, dass mir ein Tesla nicht in einen Lastwagen
> reinfaehrt.

Da muss ich mal den Spieß umdrehen... Wie schafft man es dass ein LKW 
nicht in einen Tesla (oder besser gesagt PKW allgemein) reinfährt? Z.B. 
bei einem Stauende