mikrocontroller.net

Forum: Ausbildung, Studium & Beruf Fortbildung vs "Ausbildung" in embedded


Autor: Alexander (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi,
ich habe nachm Sommer mein halbjährliches Mitarbeitergespräch, in dem 
wir unter anderem das Thema Fortbildung ansprechen werden.

Zu meiner Person:
Studium (Master) Elektrotechnik mit Schwerpunkt Leistungselektronik, 
anschließend Promotion und Postdoc im Bereich Leistungselektronik. Ich 
würde behaupten, dass ich ein sehr ausgeprägtes Interesse und Kenntnisse 
an Leistungselektronik, Topologien, Regelung, Filter Design etc habe.

Seit ca zwei Jahren bin ich nun in der Industrie als 
Entwicklungsingenieur im Bereich Hardware tätig und entwickle 
Leistungselektronik für Luftfahrt.

Mit dem Job komme ich recht gut zurecht. Alles rund um reine Hardware 
Leistungselektronik (Topologien, magnetische Bauelemente, analoge 
Regelung etc) ist für mich aufgrund meines Werdegangs recht zugänglich.

Bei vielen praktischen Angelegenheiten, die für ein eigentliches Produkt 
wichtig sind (z.B. coating, worst case analysis, FMEA etc) sind für mich 
neu und ich lerne Einiges - on the job. Aber auch das ist aufgrund der 
netten und hilfsbereiten Kollegen gut machbar.

Jetzt stelle ich mir die Frage, in welchem Bereich eine Fortbildung Sinn 
ergeben könnte.

Sinnvoll für das Unternehmen:
1 EMV (kaum praktische Erfahrung vorhanden, könnte interessant sein, 
Testen unsere Produkte in-house)
2 Schaltnetzteile und DCDC Konverter (gibt diesbezüglich mehrere Kurse, 
finde ich aber nicht so lehrreich, da vieles auf recht niedrigem Niveau 
ist und ich vieles davon bereits kenne)
3 magnetisches Design (gleiches wie in Punkt 2.)

Persönliches Interesse:
4 Embedded Hardware (bis auf ein wenig grundlegende hands-on Erfahrung 
in digitalen Regelungen mittels TI DSPs keine nennenswerte Kenntnisse im 
Bereich uC Programmierung vorhanden. Verwenden aber embedded hardware in 
unseren Systemen, daher grundsätzlich mit der Firma im Einklang)
5 Weiterführende Regelungstechnik (optimale Regelung, nichtlineare 
Regelung, Kalman Filter etc. fände ich spannend im Bereich 
Leistungselektronik, hat aber wenig Relevanz für das Unternehmen)
6 Multi objective optimization im Bereich Leistungselektronik 
(interessantes Forschungsgebiet,  potentiell interessant für ein 
Unternehmen, hat aber wenig Relevanz für unser Unternehmen, da viele 
Basics fehlen.)
7 Eine bestimmte Anzahl an Stunden pro Woche zum "Forschen" verwenden 
und anschließend ein Paper zu veröffentlichen (wird die Firma sicherlich 
nicht einlassen wollen, da es für die Firma keinen wirklichen Mehrwert 
bringt).

Meine Frage an euch (Hardware Entwickler):
Welche Weiterbildungen habt ihr bekommen bzw findet ihr empfehlenswert, 
die mit der Firma im Einklang sind?

Unsere Firma ist prinzipiell sehr engagiert, dass die Mitarbeiter 
(sofern daran selbst interessiert) sich fortbilden. Eine gesunde Balance 
zwischen Interesse des Unternehmens und Interesse des Mitarbeiters kann 
dabei ausgehandelt werden - ein wenig Verhandlungsspielraum ist also 
vorhanden.

Danke und Gruß,
Alexander

Autor: Jürgen W. (Firma: MED-EL GmbH) (wissenwasserj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einigen Messen sind Konferenzen angehängt, die meistens recht gute 
Vorträge bieten. Ich war selbst schon mehrfach dort:

* Embedded World
* Electronica
* SMT Hybrid Packaging / SMTconnect
* Diverse Angebote von "Bayern Innovativ"
* Der TÜV Süd hat im Bereich Funk/EMV/Medizintechnik manchmal Seminare.

Weiters:
* AT&S Technologieforum (also vom PCB-Hersteller AT&S, idR jährlich)
* AVNET Silica: Der Distributor hat zumindest in Ö in der Vergangenheit 
gemeinsam mit Analog Devices ganz brauchbare (halbtägige) 
Seminarveranstaltungen gemacht - siehe deren Homepage.
* Wenns um Simulationen geht: COMSOL Multiphysics bietet viele 
kostenlose Einsteigerseminare.
* Speziell TI und Analog Devices (für meine Anwendungen) haben eine 
unerschöpfliche Quelle von Tutorials.
* Würth Elektronik bietet immer wieder Webinare an - siehe auch auch 
Youtube.

: Bearbeitet durch User
Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen W. schrieb:
> Bei einigen Messen sind Konferenzen angehängt, die meistens recht
> gute Vorträge bieten. Ich war selbst schon mehrfach dort:
>
> * Embedded World
> * Electronica
> * SMT Hybrid Packaging / SMTconnect
> * Diverse Angebote von "Bayern Innovativ"
> * Der TÜV Süd hat im Bereich Funk/EMV/Medizintechnik manchmal Seminare.
>
> Weiters:
> * AT&S Technologieforum (also vom PCB-Hersteller AT&S, idR jährlich)
> * AVNET Silica: Der Distributor hat zumindest in Ö in der Vergangenheit
> gemeinsam mit Analog Devices ganz brauchbare (halbtägige)
> Seminarveranstaltungen gemacht - siehe deren Homepage.
> * Wenns um Simulationen geht: COMSOL Multiphysics bietet viele
> kostenlose Einsteigerseminare.
> * Speziell TI und Analog Devices (für meine Anwendungen) haben eine
> unerschöpfliche Quelle von Tutorials.
> * Würth Elektronik bietet immer wieder Webinare an - siehe auch auch
> Youtube.

Hi Jürgen,
vielen Dank für deinen Beitrag und entschuldige, dass ich jetzt erst 
antworte.
Viele von deinen Vorschlägen kenne ich bereits (bzw fallen mit in meine 
Auflistung von oben mit rein).

Ich habe noch mal meinen Beitrag reflektiert und muss gestehen, dass 
dort vieles theoretisches Wissen ist und oftmals autodidaktisch aus 
Büchern erlernt werden kann.

Nach Reflektion meines Beitrages würde ich eine Fortbildung 
(Aktivitäten) wohl auf drei Kerngebiete herunterbrechen können, in denen 
ich Lernbedarf / Interesse habe:
1. EMV (dort gibt es zahlreiche Seminare mit "best practices"
2. Embedded Hardware / Software (embedded programming)
3. Eine bestimmte Anzahl XY Stunden pro Woche zum Forschen.

Zum Thema embedded programming:
Kennt ihr diesbezüglich empfehlenswerte Kurse / Fortbildungen?

Danke und Gruß,
Alexander

Autor: Jürgen W. (Firma: MED-EL GmbH) (wissenwasserj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alexander!

Bzgl. Embedded Programming kann ich nur empfehlen sich auf Youtube 
umzusehen oder bei µC-Herstellern. Es gibt auch eine ganze Palette von 
Büchern, aber ich weiß leider keinen einzigen "echten" Kurs, der eine 
definitive Antwort gibt in der Form "So macht man das" - hängt wohl auch 
davon ab, ob man mit einem OS arbeiten will oder ob es eine 
stromsparende Lösung wird (also ASM und individueller Code), ob man 
fertige Bibliotheken nutzt oder eigene schreibt (aus QA-Gründen bzw. 
bzgl. der Wartung), etc.

Für fehlerminimierten und gut dokumentierten Code möchte ich aber auf 
die diversen C-Coding Style Guidelines verweisen (von Google, MISRA, 
NASA). Saubere in-code-Dokumentation (auch für automatische 
Dokumentationserstellung via Doxygen) ist v.a. für Code-Wartung wichtig 
- ich schreibe z.B. meinen eigenen (viel Assembler) Code so, daß man mit 
Doxygen die Dokumentation erstellen könnte. Das zwingt einen außerdem 
automatisch zu einem gewissen Format, das man dann auch einhält und die 
weitere Lesbarkeit wesentlich erleichtert.

Für EMV gilt meiner Meinung nach vor allem:
* Verständnis von Wellenausbreitung (d.h. daß Strom "ungern Umwege 
macht") und Induktionsgesetz
* Bauteile kennenlernen (Frequenzverhalten realer Dioden, 
Induktivitäten, Kondensatoren, etc.)

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jürgen (und natürlich auch andere potentielle Helfer :-))

vielen Dank schon mal für dein Feedback.

Der Grund, weshalb ich nach "embedded software" frage, ist folgender:
Ich habe meine Wurzeln in der Hardwareentwicklung (Speziell 
Leistungselektronik), was mir grundsätzlich sehr viel Spaß bereitet. 
Allerdings sind die Unternehmen in und um meine Stadt herum sehr mau, 
was Hardwareentwicklung und speziell Leistungselektronik angeht.

Dem gegenüber sehe ich verhältnismäßig viele offene Stellenanzeigen für 
Embedded Software Entwicklung, weshalb ich nun mit dem Gedanken spiele, 
mich in diesem Bereich einzuarbeiten / weiter zu entwickeln.
Längerfristig könnte ich mir also vorstellen, als supplement zur 
Leistungselektronik auch sehr gute Kenntnisse in embedded software zu 
erlangen.

Speziell geht es in diesen offenen Stellenangeboten um DSP 
Programmierung und Implementierung von Algorithmen, Entwicklung der 
Firmware, in manchen Stellen sogar FPGA Programmierung.
Die Unternehmen sind dabei meist im medizinischen Bereich angesiedelt 
(Entwicklung von Hörgeräten).

Beim Durchstöbern des Internets bin ich nun über folgenden Kurs 
gestoßen, der nach einer guten Einleitung zum Thema embedded zu sein 
scheint.
https://www.coursera.org/learn/introduction-embedded-systems

Was hältst du (haltet ihr) von diesem Kurs? Bzw habt ihr eine andere 
Idee, wie man im Bereich embedded software Fuß fassen kann?

Gruß,
Alexander

Autor: Joe J. (j_955)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was meinst Du genau mit Entwicklung von Embedded-Systemen? Ein uC ist 
auch nur ein weiterer Baustein.

Dann hol Dir doch einfach einen Spezi, der das für Dich macht. Im 
Embedded Bereich werden ja sowieso nur die Leute gut bezahlt, welche die 
Systeme zusammenflicken aus verschiedenen Komponenten und sich in 
bestimmten Normen/bereichen auskennen und Verantwortung übernehmen 
wollen. Heisst also spezifizieren, spezifizieren, spezifizieren...



Wenn Du keine praktische Erfahrung im Prog. von uC-Systemen hast, dann 
kannst Du das nicht einfach so erwerben. Du kannst Dich eine ganze Weile 
erstmal damit auseinander setzen(X Jahre), bis Du mal einen groben 
Übersicht hast über die Entwicklungstools, Verfahren, Systemwissen(z.B. 
Emb. Linux) o.ä.

Algorithmen entwickeln, das sieht natürlich anders aus. Warum solltest 
Du das nicht können? Bewirb Dich doch einfach mal und guck wie die 
Resonanz ist. Simulieren/Rechnen kannst Du ja nun schon hoffentlich.

Der Lernprozess sollte ja i-wann mal abgeschlossen sein;-)

: Bearbeitet durch User
Autor: Alexander (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Joe,
sorry hatte deinen Beitrag nicht gesehen.
Joe J. schrieb:
> Was meinst Du genau mit Entwicklung von
> Embedded-Systemen? Ein uC ist
> auch nur ein weiterer Baustein.
Das stimmt. Grundwissen ist vorhanden. Wenn ich allerdings viele der 
Threads hier hinsichtlich uC lese, bzw sehe, was unsere Software 
Kollegen so tun, da sehe ich schnell meine Grenzen.
Als Beispiel sei Hilti nahe München genannt, die einen Software 
Entwickler suchen. Die Stellenausschreibung ist im Anhang. Dort geht es 
hauptsächlich um Firmware Entwicklung.

Ein C Buch durcharbeiten ist eine Sache. Von dort dann aber zB bei Hilti 
genannten Aufgaben lösen wäre eine komplett neue Herausforderung.

Ich frage mich, ob und inwiefern man in diesem Gebiet ersten Fuß fassen 
kann (als Weiterbildung - auch gerne in Eigenregie).

Joe J. schrieb:
> Der Lernprozess sollte ja i-wann mal abgeschlossen sein;-)

Sollte er? :-)

Autor: Klugscheisser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zum Thema embedded programming würde ich erstmal versuchen, mich in die 
Programmiersprache C (ist einfach DER Standard) einzuarbeiten.

Das Programmieren eines µControllers ist dann wieder mit der 
entsprechenden Toolchain, Datenblatt lesen etc verbunden.

Aber C ist dabei fast immer die Grundlage.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Die Stellenausschreibung ist im Anhang.
"Softwarellösungen" und Bullshit-Bingo  :-)

Alexander schrieb:
> in manchen Stellen sogar FPGA Programmierung
Das hat aber ganz grundlegend nichts mit Software zu tun. FPGA-Design 
ist Hardwareentwicklung.

> https://www.coursera.org/learn/introduction-embedded-systems
> Was hältst du (haltet ihr) von diesem Kurs?
Der ist schon wieder viel zu abstrakt. Dort lernst du im Prinzip nur, 
wie du ein Toolset auf dem PC aufsetzt, auf dem Zielsystem ein OS zum 
laufen bekommst und ein Programm dafür schreibst. Das ist keine 
hardwarenahe Embedded-Entwicklung, die dir im "echten Leben" etwas 
bringt.
Eine der Bewertungen sagt das dann auch klar&deutlich:
It has "Embedded Systems" in the title but the closest you
will get to an embedded system here is cross-compiling a program
to run on the ARM architecture.

> Längerfristig könnte ich mir also vorstellen, als supplement zur
> Leistungselektronik auch sehr gute Kenntnisse in embedded software zu
> erlangen.
Und was würde dir das bringen? Um deine Arbeitszeit so gut wie möglich 
an den Mann zu bringen, musst du das können, was gesucht wird.
Hast du schon mal eine Stellenanzeige gesehen, in der ein 
Leistungselektronik-Enwickler mit sehr guten Softwarekenntnissen gesucht 
wird?
Oder ein sehr guter Software-Programmierer, der auch gute 
Leistungselektronik entwickelt?

An deiner Stelle würde ich dann eher die FPGA-Schiene fahren. Damit 
findest du dann vermutlich auch nicht in Rufweite um deinen Wohnsitz 
sofort etwas, aber das "Gesamtkonzept" ist stimmig und du kannst auch 
dort Begehrlichkeiten wecken, wo diese Kombination noch nicht 
eingesetzt, aber denkbar ist.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, Klugscheißer :-)

Klugscheisser schrieb:
> zum Thema embedded programming würde ich erstmal versuchen, mich
> in die Programmiersprache C (ist einfach DER Standard) einzuarbeiten.
Definitiv. Das ist auch etwas, was ich gut in Eigenregie zu Hause mit 
einem. guten Buch machen kann.
> Das Programmieren eines µControllers ist dann wieder mit der
> entsprechenden Toolchain, Datenblatt lesen etc verbunden.
Ich glaube, dass sich meine Fragen in und um dieses Gebiet drehen - 
jedenfalls glaube ich, dass das meine Intention zu sein scheint.

Das ist sicherlich herstellerspezifisch, allerdings habe ich viel von TI 
sowie ST gehört. Mir scheint, dass ST oft eingesetzt wird (möchte hier 
allerdings keine Grundsatzdiskussion über Hersteller starten).

Gruß,

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deinen Input, Lothar

Lothar M. schrieb:
> Alexander schrieb:
>> in manchen Stellen sogar FPGA Programmierung
> Das hat aber ganz grundlegend nichts mit Software > zu tun. FPGA-Design
> ist Hardwareentwicklung.

Vielleicht missverstehe ich etwas, oder wir reden aneinander vorbei. 
Aber ein FPGA ist meinem Verständnis nach ein reiner Chip, dessen Logik 
man entsprechend programmieren kann, damit eine Aufgabe gelöst wird. Das 
würde ich unter Softwareentwicklung abbuchen. Die Hardwareentwicklung 
für FPGA wäre entsprechend alles um den FPGA herum (Versorgungsspannung, 
ADCs, PCB Layout etc).
Kann aber gut sein, daß meine Auffassung verkehrt ist.

Lothar M. schrieb:
> Der ist schon wieder viel zu abstrakt. Dort lernst du > im Prinzip nur,
> wie du ein Toolset auf dem PC aufsetzt, auf dem
> Zielsystem ein OS zum
> laufen bekommst und ein Programm dafür
> schreibst. Das ist keine
> hardwarenahe Embedded-Entwicklung, die dir im
> "echten Leben" etwas
> bringt.
okay, gut zu wissen. Frage an dich: Welche hardwarenahe embedded 
Entwicklung bringt etwas im "echten Leben". Magst du das ein wenig näher 
erläutern, falls möglich?

Lothar M. schrieb:
> Hast du schon mal eine Stellenanzeige gesehen, in > der ein
> Leistungselektronik-Enwickler mit sehr guten
> Softwarekenntnissen gesucht
> wird?
Nein, aber eine Stellenanzeige, in der ein embedded Software Entwickler 
gesucht wird. Es muss nicht zwangsläufig die Kombination "embedded + 
Leistungselektronik" sein. Reine embedded Entwicklung OHNE 
Leistungselektronik ist ebenfalls akzeptabel. Genau darauf zielt mein 
eigentliches Anliegen ab (kann aber gut sein, dass ich es 
schwammig/unklar formuliert habe). Wie kann ich mich von der 
Leistungselektronik lösen, um unabhängiger davon zu sein? embedded 
software war die Idee, die mir in den Sinn kam.

Gruß,

Autor: Cyblord -. (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Vielleicht missverstehe ich etwas, oder wir reden aneinander vorbei.
> Aber ein FPGA ist meinem Verständnis nach ein reiner Chip, dessen Logik
> man entsprechend programmieren kann, damit eine Aufgabe gelöst wird. Das
> würde ich unter Softwareentwicklung abbuchen. Die Hardwareentwicklung
> für FPGA wäre entsprechend alles um den FPGA herum (Versorgungsspannung,
> ADCs, PCB Layout etc).
> Kann aber gut sein, daß meine Auffassung verkehrt ist.

Total verkehrt. FPGAS werden nicht klassisch programmiert, sondern 
mittels einer Hardwarebeschreibungssprache konfiguriert.
Somit IST FPGA Entwicklung = Hardwareentwicklung.

Ein FPGA kann aber einen SoftCore enthalten und DER wird dann wieder 
klassisch programmiert.

Autor: J_955 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Alexander schrieb:
>> Der Lernprozess sollte ja i-wann mal abgeschlossen sein;-)
>
> Sollte er? :-)

Ja, sollte er. Mit dem DOC ist ja schon eine Spezialisierung erfolgt. 
Dass das sonst bei der Tätigkeit in einem technischen Umfeld nie der 
Fall ist, ist klar. Aber derart vertiefen, wie Du das vor hast, ist ein 
kompletter Wechsel der Fachricthung und imho nicht gern gesehen.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Cyblord
Cyblord -. schrieb:
> Total verkehrt. FPGAS werden nicht klassisch
> programmiert, sondern mittels einer
> Hardwarebeschreibungssprache konfiguriert.
danke für die Richtigstellung. Das war mir nicht bewusst, dass das etwas 
völlig anderes ist.

Hi J_955
J_955 schrieb:
> ist ein kompletter Wechsel der Fachricthung und
> imho nicht gern gesehen
Magst du bitte erläutern, inwiefern das NICHT gerne gesehen ist?

Würde das ggf den Anschein erwecken, dass man sein Fachgebiet aufgegeben 
hat / nicht gut ist und der Wechsel als Flucht interpretiert werden 
könnte?

Oder weshalb könnte man den Wechsel negativ verstehen?

Demgegenüber würde ich argumentieren, dass viele (Leistungselektronik) 
Hardware Produkte (inklusive unserer eigenen) über uC und FPGAs 
verfügen. Ich würde es also eher als positiv bezeichnen, wenn man auch 
auf diesem Gebiet sehr gutes Wissen mitbringt.

Mag aber auch naiv klingen - kann ich schwer beurteilen.

Gruß,

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Vielleicht missverstehe ich etwas, oder wir reden aneinander vorbei.
Ersteres.

Du bekommst ein FPGA ohne grundlegendes Hardwareverständnis nicht zum 
Laufen. Oder andersrum: du bekommst relativ schnell ein "lauffähiges" 
Design ins FPGA. Aber wenn du dann die durch die Hardware bedingten 
"Feinheiten" nicht beachtest, dann zeigt dieses Design sporadische 
Fehler, die sich u.U. bei der kleinsten Änderung im Design ändern und 
ganz woanders auftauchen. Das passiert, weil die gesamte Beschreibung 
(quasi das gesamte "Programm", naja mir sträuben sich die Nackenhaare 
bei der Verwendung dieses Wortes an dieser Stelle) parallel und 
gleichzeitig auf dem FPGA vorhanden ist. Und natürlich auch parallel und 
gleichzeitig mit jedem Takt auf die Umwelt reagiert.

Um zu wissen und zu erkennen, ob eine Hardwarebeschreibung gut ist und 
problemlos laufen wird, musst du dir einiges an Wissen aneignen. Und 
dieses Wissen hat nichts mit sequentieller Software-Programmierung zu 
tun, sondern mit FPGA-internen Laufzeiten, Timingverletzungen, Routing, 
Eigenheiten und letztlich auch Errata.

Autor: J_955 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Demgegenüber würde ich argumentieren, dass viele (Leistungselektronik)
> Hardware Produkte (inklusive unserer eigenen) über uC und FPGAs
> verfügen. Ich würde es also eher als positiv bezeichnen, wenn man auch
> auf diesem Gebiet sehr gutes Wissen mitbringt.

Die Personaler mags freuen, so legt man die Latte einfach höher. Und in 
Zukunft werden dann die Stellenausschreibungen entsprechend 
abgeändert;-)

Wie gesagt, Du kannst so argumentieren. Aber bewerben würde ich mich 
nicht auf eine Stelle als SW-Entwickler mit dem Ausbildungshintergrund.

Hier bei uns in BW würdest Du vmtl. Absagen kassieren, weil 
überqualifiziert. Oder Du schraubst Deine Erwartungen entsprechend 
runter. Für 50k kriegst Du eine Stelle bestimmt sofort - auch als 
Entwickler.

Hoffe, das war halbwegs verständlich.

SW-Entwickler->Nein, überqualifiziert/Fachgebietswechel.
PL-Leitung/Architekt etc. ->schon besser, aber auf Produktebene. 
SW-PL-Leitung benötigt spez. Fachkenntnisse

Ein Kompromiss:
Mit Prozessoren und Datenblättern etc. solltest Du Dich schon auskennen. 
Was ist so aktuell, was sollten die uC mitbringen etc. Da kann es auch 
nicht schaden, mal die eine oder andere Zeile zu programmieren. Die 
SW-Tätigkeiten übernimmt dann jmd. mit einschl. BE.

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Lothar,
vielen Dank für deinen Input. Der feine Unterschied war mir so nicht 
klar.
Lothar M. schrieb:
> Um zu wissen und zu erkennen, ob eine
> Hardwarebeschreibung gut ist und
> problemlos laufen wird, musst du dir einiges an
> Wissen aneignen. Und
> dieses Wissen hat nichts mit sequentieller
> Software-Programmierung zu
> tun, sondern mit FPGA-internen Laufzeiten,
> Timingverletzungen, Routing,
> Eigenheiten und letztlich auch Errata.

Dann (m)eine Frage an dich:
Welche Strategie hältst du am sinnvollsten, sich in die FPGAs 
einzuarbeiten. Ein Evaluationsboard kaufen und dann in Eigenregie damit 
anfangen, oder ggf einen offiziellen (mehrtägigen) Kurs besuchen?

Mir ist klar, dass es auch bei FPGAs verschiedene Hersteller gibt. Es 
würde im ersten Schritt also Sinn machen, den FPGA (Hersteller) zu 
verwenden, der auch bei uns in der Firma eingesetzt wird.

Meine Frage zielt eher darauf ab, ob es einen Mehrwert / Sinn ergibt, 
wenn man einen Kurs / Workshop besucht, und ob die Kosten gerechtfertigt 
sind. Diese Frage kommt sicherlich vom Management relativ zu Beginn :-)

Gruß,

Autor: Jetzt ist G. (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was vielleicht etwas unterging... EMV.
Ist superwichtig. Nein, nicht um inhouse tests zu machen, sondern fuer 
das Design. Einen (Inhouse-)EMV Test zu machen ist relativ sinnlos wenn 
beim Design die EMV nicht bedacht wurde.
Ohne gute Ahnung von EMV sollte man eigentlich gar nicht mit einer 
Entwicklung anfangen.
Ist mit hoher Wahrscheinlichkeit fuer die Tonne.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Es würde im ersten Schritt also Sinn machen, den FPGA (Hersteller) zu
> verwenden, der auch bei uns in der Firma eingesetzt wird.
Wäre nicht ganz abwegig. Im Besonderen dann, wenn du deinen AG davon 
überzeugen kannst, dir die Schulung zu finanzieren.

Alexander schrieb:
> Welche Strategie hältst du am sinnvollsten, sich in die FPGAs
> einzuarbeiten. Ein Evaluationsboard kaufen und dann in Eigenregie damit
> anfangen
Ja. Es ist kein Hexenwerk, und falls du dann tatsächlich auf eine 
Schulung gehst, kannst du mit den Begriffen eher was anfangen. Oder es 
werden sogar Fragen beantwortet, die sich bei der Arbeit mit dem 
Baustein ergeben haben...

Autor: Alexander (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt ist G. schrieb:
> Was vielleicht etwas unterging... EMV.
> Ist superwichtig. Nein, nicht um inhouse tests zu machen, sondern fuer
> das Design. Einen (Inhouse-)EMV Test zu machen ist relativ sinnlos wenn
> beim Design die EMV nicht bedacht wurde. Ohne gute Ahnung von EMV sollte
> man eigentlich gar nicht mit einer Entwicklung anfangen. Ist mit hoher
> Wahrscheinlichkeit fuer die Tonne.

Hi Jetzt ist G.
sorry für die späte Rückmeldung. Ich stimme dir voll und ganz zu, EMV 
ist ein sehr wichtiges Thema.

Dazu gibt es zahlreiche Bücher und auch Webinars + Youtube Videos als 
erste Anlaufstelle.

Hinsichtlich Schulung:
Hast du bereits an einer solchen Schulung teilgenommen und kannst deine 
Erfahrung (egal ob positiv oder negativ) dazu schildern? Kannst du eine 
Schulung empfehlen?

@Lothar:
Auch dir vielen Dank für deinen Beitrag. Ich werde mir das Thema FPGA 
mal durch den Kopf gehen lassen, wie ich das am besten im 
Mitarbeitergespräch ansprechen kann.

Gruß,

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.