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.
:
Bearbeitet durch User
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;-)
:
Bearbeitet durch User
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ß,
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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.