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
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.
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
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.)
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
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;-)
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? :-)
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.
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:
1
It has "Embedded Systems" in the title but the closest you
2
will get to an embedded system here is cross-compiling a program
3
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.
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ß,
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ß,
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.
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.
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ß,
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.
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.
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ß,
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.
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...
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ß,
