Welche Tools muss man heute eim Embedded-Sektor beherrschen?

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

Ada... Sparc...

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).

Bernd K. schrieb:
> Gute bis sehr gute Englischkenntnisse in Wort und Schrift.

Gute Deutschkenntnisse sind natürlich auch nicht vrkehrt!

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

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

Wenn man Embedded Android macht: find und grep.

Evtl. auch noch eine Fortbildung im Fliesenlegen!

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.

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.

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?

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.

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

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

Teure Spielerei...

ISO9001 sollte man auch im Schlaf beherrschen.

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).

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...

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!

Haha schrieb:
> Sowas macht man heute auch mit einem Arduino!

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

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.

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.

Wer seine Software debuggen muss, ist ein Anfänger und kein Profi.

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

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.

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!

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...

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.

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

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?

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

Unsinn

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.

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.

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.

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.