Forum: Ausbildung, Studium & Beruf Welche Tools muss man heute eim Embedded-Sektor beherrschen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hans-Hermann (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin seit einigen Jahren raus aus der Embedded-Entwicklung und möchte 
nun wieder einsteigen.
Welche Tools sollte man da in einem professionellen Umfeld heute 
beherrschen? Was ist da alles gefordert?

Gruß,
Hans-Hermann

:
von Haha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Slack, Jira, Confluence, E-Mail, Docker, Git, ...dafür geht dann schon 
30% der Arbeitszeit drauf.

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
Der "Embedded Sektor" ist groß, so groß daß er schon wieder 2 Dutzend 
Untersektoren hat. Dementsprechend gibt es unterschiedliche Tools für 
unterschiedliche Zwecke wie Sand am Meer.

Präzisiere also Dein Anliegen.

von dadida (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ada... Sparc...

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und 
vim, das ist das absolute Minimum das in allen Bereichen zwingend ist, 
quasi die Beherrschung der Grund-Infrastruktur. Dazu kommen dann noch 
diverse speziellere Tools und auch IDEs für bestimmte Zwecke.

von Haha (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Desweiteren Opsgenie, MS Office, MS Azure, Bedienung von Telefonen 
(Telefonkonferenzen sind ganz wichtig), Wikipedia (zusätzlich zu 
Confluence, am besten schreibt man alles redundant auch ein drittes Mal 
in ein Word Dokument).

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
Gute bis sehr gute Englischkenntnisse in Wort und Schrift.

von Bernd K. (prof7bit)


Bewertung
2 lesenswert
nicht lesenswert
Chinesisch ist noch optional aber zunehmend nützlich.

von Haha (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Gute bis sehr gute Englischkenntnisse in Wort und Schrift.

Gute Deutschkenntnisse sind natürlich auch nicht vrkehrt!

von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
Simulink, TargetLink, LabView ...

von Haha (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
HAL (SETM32, vor allem im professionellen Umfeld), AVR Studio 4, WINAVR, 
Assembler, RS232 (Debugging), I=U/R kennen und anwenden

von konfusius (Gast)


Bewertung
8 lesenswert
nicht lesenswert
Bei solchen Threads postet doch jeder nur was er selbst halbwegs kann,
und das wird dann zum absoluten Standard und Minimum erklärt.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man Embedded Android macht: find und grep.

von Olaf D. (Firma: O.D.I.S.) (dreyero)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde alles lernen was dieses Kommando ausgibt:
ls /bin /sbin /usr/bin

(Duck und weck)

von Haha (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Evtl. auch noch eine Fortbildung im Fliesenlegen!

von Andreas B. (bitverdreher)


Bewertung
0 lesenswert
nicht lesenswert
Dass hier noch keiner Arduino genannt hat....

von Haha (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Dass hier noch keiner Arduino genannt hat....

Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung) 
gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da 
eine Projektanfrage.

Beitrag #6141108 wurde von einem Moderator gelöscht.
von Programmierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Haha schrieb:
> Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung)
> gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da
> eine Projektanfrage.

Wenn es darum geht, z.B. ein Shield und zugehörige Libraries, oder einen 
ganz eigenen Arduino zu entwickeln als Evaluations-Plattform für eigene 
Produkte, ist das doch nicht verkehrt, wie z.B. der Linduino.

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Haha schrieb:
> Evtl. auch noch eine Fortbildung im Fliesenlegen!

Irrtum!

Was heutzutage gebräuchlich ist, ist mit LEGO umgehen zu können.

Also nix Fliesen, sondern Plastich dreidimensional!

W.S.

ps.: seit wann ist der Freitag auf den Mittwoch verlegt worden?

von Haha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Was heutzutage gebräuchlich ist, ist mit LEGO umgehen zu können.
>
> Also nix Fliesen, sondern Plastich dreidimensional!

Ich drucke meine Fliesen auch im 3D Drucker.

von Hinweisgeber (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Haha schrieb:
> Slack, Jira, Confluence, E-Mail, Docker, Git, ...dafür geht dann
> schon 30% der Arbeitszeit drauf.

Git und generell Linux reicht. Rest ist unnützer Mist

von Hinweisgeber (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Walter T. schrieb:
> Simulink, TargetLink, LabView ...

Teure Spielerei...

von Haha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ISO9001 sollte man auch im Schlaf beherrschen.

von IM Drahtwickel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Hans-Hermann schrieb:
> Welche Tools sollte man da in einem professionellen Umfeld heute
> beherrschen? Was ist da alles gefordert?

Multimeter, Oszilloscope, Crimpzange, Schraubendreher, 
funktionsgenerator,

daran scheitern 50% der Hochschulabsoventen, in bestimmten 
Fachrichtungen 100%. (die, die unter Tools was ganz anderes verstehen).

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
IM Drahtwickel schrieb:
> Multimeter, Oszilloscope, Crimpzange, Schraubendreher,
> funktionsgenerator,

Ich hab mir an der Hochschule mal einen Funktionsgenerator geliehen. Ein 
Jahr später brauchte ich ihn noch einmal, und er stand noch auf exakt 
den gleichen Einstellungen...

von Haha (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Programmierer schrieb:
> Ich hab mir an der Hochschule mal einen Funktionsgenerator geliehen. Ein
> Jahr später brauchte ich ihn noch einmal, und er stand noch auf exakt
> den gleichen Einstellungen...

Sowas macht man heute auch mit einem Arduino!

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Haha schrieb:
> Sowas macht man heute auch mit einem Arduino!

Geht auch, mit Funktionsgenerator war's etwas einfacher. Arduino wäre 
aber handlicher gewesen...

von vn nn (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Programmierer schrieb:
> Haha schrieb:
>> Ich wurde schonmal (im Umfeld der professionellem Embedded Entwicklung)
>> gefragt: Du Max Mustermann, kennst du dich mit Arduino aus? Wir haben da
>> eine Projektanfrage.
>
> Wenn es darum geht, z.B. ein Shield und zugehörige Libraries, oder einen
> ganz eigenen Arduino zu entwickeln als Evaluations-Plattform für eigene
> Produkte, ist das doch nicht verkehrt, wie z.B. der Linduino.

Wenn der Hardwareentwickler irgendwas braucht, wo er einfach seinen 
Sensor dran flanschen kann um schnell mal die Analogwerte per UART 
auszugeben, auch nicht.

von T-Rex (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Nur die Werkzeuge die notwendig sind;-)

Je nach Target am Besten die Hersteller Tools zum FLASHEN bzw. Debugging
Compiler und Editoren sind Geschmackssache. Wer sich es leisten kann 
professionelle Tools zu verwenden fährt nicht unbedingt schlecht. Wer 
nicht die Geduld und das Wissen hat Spezial Tools zu konfigurieren ist 
mit konfektionierten IDEs/Tools besser dran. Bei Makefile Projekten tut 
man sich mit Linux meist besser. Mit IDEs ist Windows gut genug. Als 
Nicht-Spezialist fährt man (manchmal) mit kommerziellen Tools vielleicht 
besser. In der Firma verwenden wir für die aktuellen Projekte allerdings 
nur kommerzielle Werkzeuge.

Auch wenn man mich mich jetzt teert und federt, bin ich der Meinung, daß 
man mit vernünftig programmierten C oder C++ immer noch am besten fährt. 
Wenn auch für viele Newcomer Sprachen oft mächtig getrommelt wird, kommt 
man mit C/C++ doch immer noch zuverlässig zum Ziel. Aber das muss jeder 
selbst entscheiden. Wer da abenteuerlich veranlagt ist, wird sich mit 
der Vielfalt der neuen Werkzeuge sicherlich austoben können sofern man 
mit der Lernkurve und Evolution der Werkzeuge zurecht kommt.

Für einfachere Sachen im Hobbybereich kann man übrigens auch mit dem 
verschrieenen Arduino IDE + GCC gut zurecht kommen. Auch wenn der Editor 
einfach gehalten ist, ist so ziemlich alles wirklich Notwendige 
vorhanden. Auch dort kann man "Bare Metal" programmieren. Man ist nicht 
unbedingt auf externe Bibliotheken angewiesen und man kann ziemlich frei 
gestalten.

Wer Debuggen wichtig findet, wird mit JTAG GDB gut zurecht kommen. 
Debugger ist je nach Projekt wichtig oder man braucht ihn kaum. In 
meiner Praxis komme ich fast ohne Debugger aus. Nur wenn man selber 
einen blöden (Schlampigkeits) Fehler macht, dann hilft der Debugger es 
schneller zu finden. 90% der Zeit befindet sich der Fehler meist vor dem 
PC. Manche 8-bit Debugger Infrastrukturen funktionieren nicht so gut. 
Was Debuggen betrifft, machte ich mit ARM7/Cortex uC JTAG und GDB gute 
Erfahrungen. Mit AVR und PIC war es immer ein frustrierendes Erlebnis.

von Haha (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
Wer seine Software debuggen muss, ist ein Anfänger und kein Profi.

Die Diskussion hatt wir hier im Forum jetzt schon häufig genug.

von Programmierer (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Haha schrieb:
> Wer seine Software debuggen muss, ist ein Anfänger und kein Profi.

So ein Quatsch. Diese Arroganz, zu denken, man könne keine Fehler 
machen, hat schon Raketen und Flugzeuge abstürzen lassen. Leute, die 
behaupten, nicht debuggen zu müssen, sind meistens die, die zu faul 
sind, den Umgang mit dem Debugger zulernen.

Beitrag #6142005 wurde von einem Moderator gelöscht.
von Ingo Less (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Haha schrieb:
> HAL (SETM32, vor allem im professionellen Umfeld)
Naja, die SPL bzw. LL-Driver sind auch ok

>AVR Studio 4
Veratlet, Atmel Studio 7 ist um längen komfortabler

>WINAVR
Veraltet, einen aktuellen GCC sollte man schon mal verwenden

>Assembler, RS232 (Debugging), I=U/R kennen und anwenden
Check!

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Haha schrieb:
> Wer seine Software debuggen muss

Wirst Du diesen Schwachsinn jetzt in jedem Thread posten der auch nur 
entfernt was mit Mikrocontrollern oder Programmierung zu tun hat?

Beitrag #6142122 wurde von einem Moderator gelöscht.
von Programmierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Batman schrieb im Beitrag #6142122:
> Hatte letztens einen Bewerber (Snowflake) der sich mit seinem Rasperry
> Kenntnissen gebrüstet hat.

Wenn der sich mit den Details der CPU und z.B. des Grafikprozessors, des 
Kernels und der zugehörigen Treiber für den R-PI auskennt - Respekt! Das 
ist dann ein hochqualifizierter Experte mit seltenen Kenntnissen, den 
man für anspruchsvolle Embedded-Linux-Entwicklung einsetzen kann. Könnte 
man durchaus als goldene Schneeflocke bezeichnen...

Beitrag #6142152 wurde von einem Moderator gelöscht.
Beitrag #6142182 wurde von einem Moderator gelöscht.
Beitrag #6142192 wurde von einem Moderator gelöscht.
von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Batman schrieb im Beitrag #6142192:
> Nein, der kann höchstens ein Image aus dem Internet herunterladen und
> auf einem Raspi installieren.

Nagut. In jedem Fachgebiet gibt es Deppen.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Embedded ist ein riesiger Bereich - da kann man kaum sagen, was man 
benötigt und was nicht. Wichtig ist eigentlich nur eine Sache: sich 
schnell in neue Anforderungen/Software einarbeiten zu können (eben weil 
es so eine große Vielfalt gibt).

Oft gehört auch dazu, dass man sich in die Thematik des Umfelds der 
späteren Elektronik einarbeitet, weil der Kunde selbst noch nicht genau 
weiss, was er überhaupt benötigt.

Walter T. schrieb:
> Simulink, TargetLink, LabView ...

Noch nie benutzt :-)

konfusius schrieb:
> Bei solchen Threads postet doch jeder nur was er selbst halbwegs kann,
> und das wird dann zum absoluten Standard und Minimum erklärt.

Natürlich!

Daher gehören fundierte Kenntnisse über Fluidphysik, Metallurgie, 
Zerspanung, CNC-Kenntnisse und Bearbeitung optischer Flächen zwingend 
dazu - vorher braucht man nicht einmal an irgendwelche Elektronik zu 
denken ;-)

: Bearbeitet durch Moderator
von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Noch nie benutzt :-)

Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-)

von konfusius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder 
eine andere PCB Design Software genannt hat.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Chris D. schrieb:
>> Noch nie benutzt :-)
>
> Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-)

Na Gott sei Dank! :-)
Ernsthaft: ich bin sehr froh, für diesen Bereich nicht entwickeln zu 
müssen.

von Haha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
konfusius schrieb:
> Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder
> eine andere PCB Design Software genannt hat.

Ok: Eagle oder KiCad, aber bitte nur jeweils den Layouteditor. Wer 
braucht schon Schaltpläne?

von Hinweisgeber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Walter T. schrieb:
> Chris D. schrieb:
> Noch nie benutzt :-)
>
> Dann kannst Du Dir ASIL-D und ISO 26262 aber abschmieren! :-)

Unsinn

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
konfusius schrieb:
> Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle oder
> eine andere PCB Design Software genannt hat.

Wir haben alle in Anbetracht der Leser- und Schreiberschaft hier aufs 
peinlichste genau darauf geachtet keine kontroversen und stark 
polarisierenden Themen anzuschneiden oder überhaupt auch nur beim Namen 
zu nennen, bzw. überhaupt auch nur daran zu denken!

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
konfusius schrieb:
> Was mich jedoch wirklich wundert ist, dass bis jetzt niemand Eagle
> oder
> eine andere PCB Design Software genannt hat.

Die Hardware kaufen wir billig in China, wir brauchen nur einen Doofen 
der die mitgelieferte Software repariert.

von Industriegereifter alter Sack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:
> Haha schrieb:
>> Wer seine Software debuggen muss, ist ein Anfänger und kein Profi.
>
> So ein Quatsch. Diese Arroganz, zu denken, man könne keine Fehler
> machen, hat schon Raketen und Flugzeuge abstürzen lassen. Leute, die
> behaupten, nicht debuggen zu müssen, sind meistens die, die zu faul
> sind, den Umgang mit dem Debugger zulernen.

Debuggen != Testen

Da werden 2 unterschiedliche Sachen vermischwechselt.
Wenn (auch embedded-)SW wirklich gut gemacht ist, dann kann sie bei 
einem Test gerne auch mal abkacheln. Jedoch bei der Informationsspur 
welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und 
auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne 
Debugging.

Ich duerfte von so arbeitenden Senior-Kollegen lernen und weiss somit 
dass es auch ohne (klassisches/stereotypes) Debugging geht, sehr weit 
geht.
(Branchen: Flugsicherheit, Sprachkommunikation, Telekom i.A., SCADA)

Sobald jedoch bei der Konzeptionsphase von Produkte "schnell-schnell" 
was gemacht wird (sprich: zu frueh und unbedacht Quellcode gerotzt 
wird); tja dann... ja genau dann wird Debugging noetig und auch haarig.
Dann ist aber der Zug schon abgefahren.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Industriegereifter alter Sack schrieb:
> Wenn (auch embedded-)SW wirklich gut gemacht ist, dann kann sie bei
> einem Test gerne auch mal abkacheln.

Wieso Testen? Wer keine Fehler macht, braucht doch nicht testen!

Industriegereifter alter Sack schrieb:
> Jedoch bei der Informationsspur
> welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und
> auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne
> Debugging.

Das Verfolgen der "Informationsspur" ist debuggen. Fehler Suchen eben.

von Industriegereifter alter Sack (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:
> Wieso Testen?
> Wer keine Fehler macht, braucht doch nicht testen!
DAS ist Deine Behauptung! Lebe DU lange und gut damit...

> Industriegereifter alter Sack schrieb:
>> Jedoch bei der Informationsspur
>> welche sie dabei hinterlaesst wissen deren Macher sofort warum/wieso und
>> auch wo weiter daran zu arbeiten ist - und jetzt kommt's - ganz ohne
>> Debugging.
>
> Das Verfolgen der "Informationsspur" ist debuggen.

Oh Mist.. er hat es gemerkt (ausser dass es ohne Debugger geschieht 
:-> )
So gewinnst Du eine Reise nach Amerika.
Wenn Du nun auch aufhoerst zu trollen (s.o.), gewinnst Du auch die 
Heimreise dazu.


> Fehler Suchen eben.
Du meinst, Etwas nicht gemachtes (s.o.) zu suchen?

Bin raus, tschuess.

von Random .. (thorstendb) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Um auf das Ursprungsthema zurückzukommen:
Ich selbst bevorzuge für meine Projekte verständlicherweise MDK-ARM mit 
ULINK pro oder plus, sowie die zugehörige Middleware (bin ja vorbelastet 
:-) ).
Andere (Bekannte) verwenden im professionellen Umfeld z.B. IAR oder 
andere kommerzielle IDEs.
Vorteil an diesen ist, sie unterstützen den Entwickler mit integrierten 
Werkzeugen, wie (im ARM Cortex Fall) z.B. einem ITM Terminal, grafischen 
Analysetools für Variablen und RTOS, oder gar Instruction Trace.
Somit braucht man keinen UART (= ITM printf), oder einen PortPin mit dem 
Oszi ausmessen (= Data Watch, Zeitmessung im Fenster).

Ich für meinen Geschmack greife eher selten bis gar nicht auf HALs 
zurück (z.B. STM). Man sollte sich aber für ARM Cortex die CMSIS 
Standardisierungen ansehen (CMSIS Headerfiles, Treiber, ...). Je nach 
Projekt und Portierbarkeit macht es doch Sinn, sich auch mit den HALs 
auszukennen.

Im privaten Bereich greift man lieber auf kostenlose Lösungen aus den 
gnu Paketen zurück. Verständlich, eine Vollversion der kostenpflichtigen 
ist meisst nicht ganz billig. Zum Glück schmeissen ST und Konsorten seit 
einiger Zeit mit Boards um sich, wo gleich ein kleiner Debugger mit 
drauf ist :-) Ansonsten bietet z.B. Segger (als Konsequenz der China 
Clone?) eine recht günstige EDU Version des JLink an.

Zurück zu dem, was man können sollte:
- mind. eine IDE / Toolchain bedienen können
- C/C++ bevorzugt, da man näher am Core ist (ASM Jünger, steinigt mich 
:-) )
- Software-Architektur, den Code zumindest halbwegs sinnvoll auf Module 
aufteilen
- die Zielarchitektur verstehen oder verstehen lernen!
- das Manual der MCU lesen & verstehen
- Peripherals auch durch Lesen des Manuals programmieren können
- sich Standards anschauen (z.B. CMSIS)
- Code Debuggen, Fehler auf verschiedenste Weise eingrenzen können
- Grundverständnis in Elektronik, Schaltpläne lesen können
- Assembly und Register (Debugger) lesen können, um Code zu optimieren
- Architektur Besonderheiten (Intrinsics)
- und vielleicht muss man ab und an auch mal wissen, wo das heisse Ende 
vom Lötkolben ist :-)
- ggf. PC Programmierung (z.B. Visual Studio) für Test Tools oder 
Datenauswertung

Beim Debuggen kreativ werden, vor allem bei selten auftretenden 
Problemen:
Falls jemand die NetLase LC kennt: Ich habe z.B. die Ethernet 
Kommunikation und meine internen Buffer und Timeouts sowie das 
Zusammenspiel mit den Interrupts analysiert, durch geschicktes Setzen 
von Werten verschiedener Variablen, die dann grafisch angezeigt wurden. 
In gleicher Weise konnte ich die Ausführung der Interrupts sehen. So 
wurde dann irgendwann klar, dass ein Interrupt in einem sehr seltenen 
Fall etwas zu lange dauerte. Grafisch findet man das nach ner Weile, mit 
printf geht das gar nicht, da man das Timing stört.

So gibt es verschiedene Arten, Code zu Debuggen. angefangen mit printf 
für langsame Ausgaben bis hin zu Pin Toggling oder Data Trace für 
zeitkritische Stellen.

Beruflich zerlege ich u.a. die oben genannten Datenströme unter Windows 
und sorge für die Darstellung incl. grafischem Rendering. Ich liebe 
große Datenmengen, je mehr und zeitkritischer, desto besser :-)

Und: Sicherlich gibt es in meinem Post das ein oder andere, für das ich 
gleich zerissen werde :-)

: Bearbeitet durch User
Beitrag #6142843 wurde von einem Moderator gelöscht.
Beitrag #6143225 wurde von einem Moderator gelöscht.
Beitrag #6143360 wurde von einem Moderator gelöscht.
Beitrag #6143413 wurde von einem Moderator gelöscht.
Beitrag #6143462 wurde von einem Moderator gelöscht.
Beitrag #6143465 wurde von einem Moderator gelöscht.
Beitrag #6143474 wurde von einem Moderator gelöscht.
Beitrag #6143477 wurde von einem Moderator gelöscht.
von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und
> vim, das ist das absolute Minimum das in allen Bereichen zwingend ist

Die Aussage ist so pauschal natürlich Quatsch.

Es gibt etliche Firmen, die weder Docker noch git benutzen. Manche 
benutzen auch kein make, sondern ein anderes Build-System. Manche 
benutzen andere Compiler als den gcc. Welchen Editor man verwendet, ist 
in der Regel komplett wumpe... und so weiter und so fort.

: Bearbeitet durch User
von Mark B. (markbrandis)


Bewertung
1 lesenswert
nicht lesenswert
Hans-Hermann schrieb:
> Welche Tools sollte man da in einem professionellen Umfeld heute
> beherrschen? Was ist da alles gefordert?

Wenn die Frage auf spezifische Tools eines bestimmten Herstellers 
abzielt, dann ist sie falsch gestellt. Tools kommen und gehen. Genau so 
wie viele Programmiersprachen auch.

Was man braucht, ist Methodenwissen. Und in aller Regel Tools aus den 
folgenden Kategorien:

Lesen von Datenblättern.
Erstellen von Anforderungen.
Erstellen von Architektur/Design Dokumenten.
Editieren von Sourcecode.
Compiler.
Linker.
Debugger.
Test Framework.
Erstellen von Testberichten.

Welche das dann im konkreten Fall sind, unterscheidet sich von Firma zu 
Firma sehr stark. Daher kann man hier keine pauschal gültige Antwort 
geben.

von Jens J. (jensen23523)


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Linux, Bash, Python (Matplotlib, numpy, etc), Docker, git, make, gcc und
> vim, das ist das absolute Minimum das in allen Bereichen zwingend ist,
> quasi die Beherrschung der Grund-Infrastruktur. Dazu kommen dann noch
> diverse speziellere Tools und auch IDEs für bestimmte Zwecke.

Eben. Ich bin Profi und nutze weder Bash, python, Docker, git, make und 
vim.

Ich konzentriere mich lieber auf mein Produkt, als auf eine tolle 
Toolchain. Das ist denke ich ein großer Fehler, den heutzutage vor allem 
Startups begehen. Die vergessen dann das Wesentliche, worum es 
eigentlich geht und schütten sich mi irgendwelchen Programmen zu... und 
versauen ihre Arbeitsweise.

Wenn z.B. ein Kunde auf einen STM8 programmiert haben möchte, dann nehme 
ich STVD, für STM32 STM32CudeIDE, für Atmel das Atmel Studio 7. Ich baue 
mir keine Toolchain auf und gehe sofort ans Werk. Wenn es eine fertige 
SOftware gibt, dann nutze ich die auch. Gibts die später nicht mehr, 
nutze ich halt etwas anderes.

Python ist meiner Auffassung nach etwas für kleine Programm interne 
Scripte. Ach aufm Linux programmiere ich (hardwarenah) in C/C++ und 
nicht in Python.

Docker kannste gleich inne Tonne kloppen, das brauchen höchsten Fanboys 
aus dem Bereich Frontend/Backend.

make nutze ich auch nicht, ich lebe nicht mehr im Jahr 1995.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Lesen von Datenblättern.
> Erstellen von Anforderungen.
> Erstellen von Architektur/Design Dokumenten.
> Editieren von Sourcecode.
> Compiler.
> Linker.
> Debugger.
> Test Framework.
> Erstellen von Testberichten.

Da fehlt noch:
Repository für den Sourcecode.
Change Management Tool / Application Lifecycle Management Tool.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Bewertung
1 lesenswert
nicht lesenswert
Den richtig guten reicht Power Point völlig. Damit überzeugt man die 
Chefs das man es drauf hat und man wird auf eine Position befördert die 
wiederum  nur PowerPoint benötigt. Alles darunter sind 
"Implementierungsdetails" um die sich untergebene kümmern sollen. So 
läuft das.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Den richtig guten reicht Power Point völlig.

Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-)

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Cyblord -. schrieb:
>> Den richtig guten reicht Power Point völlig.
>
> Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-)

Abschließendes Kritierum ist die Zahl auf dem Gehaltszettel. Und wenn da 
jemand, angeblich völlig Ahnungslos, 150% von mir verdient, dann muss 
ich vielleicht meine Einschätzung korrigieren.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Mark B. schrieb:
>> Cyblord -. schrieb:
>>> Den richtig guten reicht Power Point völlig.
>>
>> Richtig gut = Kompetentes Auftreten bei völliger Ahnungslosigkeit? ;-)
>
> Abschließendes Kritierum ist die Zahl auf dem Gehaltszettel. Und wenn da
> jemand, angeblich völlig Ahnungslos, 150% von mir verdient, dann muss
> ich vielleicht meine Einschätzung korrigieren.

Es gibt tatsächlich Leute, die schlechte Arbeit leisten und trotzdem 
viel verdienen. Möglich wird das durch ein System, in dem Manager schon 
lange keine echte Verantwortung mehr tragen. Zur Not gibt es halt den 
"goldenen Handschlag" und sie werden für ihre schlechte Leistung mit ein 
paar Millionen Euro Abfindung bestraft. :-/

Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.