Logo Elektrobit

Elektrobit

Established Company
Show all Videos

Michael Wegner, Senior Software Developer bei Elektrobit

Description

Michael Wegner von Elektrobit erzählt im Interview über seine Tätigkeit als Developer für Automotive Software, welche Challenges es hier gibt und gibt Tipps für Neueinsteiger.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In “Michael Wegner, Senior Software Developer bei Elektrobit,” Speaker Michael Wegner explains his role developing Ethernet drivers for automotive microcontrollers, enabling high-volume data—such as camera streams—between multiple controllers. He works very close to the hardware—setting bits, using hardware debuggers and oscilloscopes, and doing bitbanging—and says embedded development is what he loves. His advice: use internet tutorials and real problems to get started, embrace detours as learning, and in embedded prioritize formal fundamentals like stack, heap, and interrupts, which he relies on daily.

Ethernet at the Edge: How Michael Wegner (Elektrobit) Builds Drivers, Bits, and Daily Fundamentals for In‑Car Systems

Who’s speaking—and what makes his work distinct

In this DevJobs.at devstory, “Michael Wegner, Senior Software Developer bei Elektrobit” opens a clear window into real-world embedded development in modern cars. The “Speaker: Michael Wegner” works on the components that make connected vehicles actually communicate: he develops Ethernet drivers for microcontrollers. The description sounds straightforward, but in practice it’s relentlessly close to the hardware and full of decisions that shape a system’s behavior bit by bit.

His summary leaves no doubt: Cars host multiple microcontrollers, and they have to talk to each other—reliably and with bandwidth. Cameras on the vehicle generate large volumes of data that need to be routed to a central point or several points. For that, the choice is Ethernet. It’s proven, it’s everywhere, and it can handle the load. The bridge between the physical reality on the board and the data paths that move those camera streams is the driver layer that Michael writes.

He captures his day-to-day with precision: working right next to the hardware; setting individual bits in controllers so they do exactly what they should; debugging with hardware debuggers; using oscilloscopes; and doing bitbanging. That is embedded development—and it’s exactly what he likes to do.

Why Ethernet in the car: Data that truly needs to move

What we heard is simple and compelling: multiple microcontrollers are the norm in modern vehicles. They are distributed, take on responsibilities, and must communicate. With cameras in the loop, significant data needs to reach a central or multiple points. Here the keyword is capacity that’s robust in practice. Ethernet “has proven itself,” it’s “everywhere,” and “it can do that.” Those short assessments paint a clear picture: when data volume grows and many microcontrollers need to interconnect, a well-established, high-capacity communication substrate wins the day.

For engineers, this also reframes a general lesson: not every problem calls for a novel or exotic technology. Sometimes the best choice is the robust, known, widely supported path. In Michael’s account, Ethernet is not a trend—it’s a consequence of requirements and experience.

Driver development in practice: Set bits, measure, understand

The reality Michael sketches is tactile and exacting. He talks about “setting individual bits in the controllers” to ensure the component does “exactly what it is supposed to do.” That phrasing highlights how concrete embedded work is: it’s not about abstract patterns—it’s about direct effect. Every low-level setting shows up in the device’s behavior.

He names hardware debuggers, oscilloscopes, and bitbanging. Together they form a familiar image of embedded practice:

  • Hardware debuggers: When software touches microcontroller peripherals and physical interfaces, debuggers aren’t nice-to-haves—they are central to finding causes. You observe, halt, step, compare—at the level where every instruction matters.
  • Oscilloscope: Signals are not merely assumed; they are measured. Made visible. In a world where bit sequences, timing, and electrical states draw the line between “works” and “doesn’t,” measurement is understanding.
  • Bitbanging: A willingness to generate signals deliberately in software by toggling bits at well-controlled points in time. It sits naturally in his list—a sign of being ready to control behavior at the lowest level.

This is the full picture of what he calls embedded development. It’s unvarnished and real: close to registers, close to pins, with a focus on deterministic effect. And it’s clearly the kind of work he enjoys.

What this closeness to hardware demands

The description makes something else clear: this proximity demands focus and a solid base. It’s not enough to discover the right API. The task is to make a microcontroller “do exactly what it is supposed to do.” The goal is clarity in cause and effect. When you set bits, you expect a physical, observable response on the board and on the bus. Debugging is something you can measure, reproduce, and trace.

That’s also where the appeal lies. Each improvement, fix, and insight becomes visible in the device’s behavior. The path to understanding runs through debuggers and oscilloscopes, not guesswork. It’s a discipline that foregrounds care, a systematic approach, and a willingness to look at signals not just logically but physically.

Learning today: Internet tutorials and problem orientation

Asked how to get started today, Michael is unequivocal: the Internet. Internet tutorials. If you’re interested in something, the critical ingredient is the idea or problem you want to solve. It doesn’t matter whether it’s home automation, an app you wish existed, or a mod for a game you like—he underscores that in the Internet there’s “a starting point for every topic,” enough to get going.

The emphasis on a starting point is important. The goal isn’t to understand everything at once; it’s to begin. Michael advises not to get discouraged if you don’t reach the intended destination initially. Maybe the problem “is far too complicated […] for a beginner.” But you learn on the way. He notes that he has “often ended up somewhere else than where [he] wanted to go.” Those detours are still interesting—and “in any case” you learn something.

The mindset is worth internalizing:

  • Start with a problem you truly care about.
  • Grab the first thread—tutorials, posts, examples.
  • Expect detours and accept them as part of the process.
  • Measure progress not only by goal completion but by the concepts you absorb along the way.

In fast-moving technology landscapes, this resilience is a decisive advantage.

Study and embedded: When fundamentals become daily tools

Michael is clear: “A degree definitely helps. Especially in embedded.” You can self-teach a lot, he says, but a degree is about exactly that—learning fundamentals. In embedded, he argues, those fundamentals matter more than in other areas. He draws a comparison: in web development, many academic topics may never be used. In embedded, “you need many of them.” He names them explicitly: stack, heap, interrupts.

He also acknowledges that many people experience these topics as “very dry.” But his conclusion is direct: “We need that every day. I need that every day in my work.” These sentences are notable because they name the bridge between theory and practice. The concepts that can feel abstract become immediate—in his work, every day.

For students and self-taught newcomers, that’s a signpost: the slow burn of fundamentals pays off when your destination is hardware proximity. If you want to feel at home in embedded, invest in those basic concepts—and recognize their direct impact in the way microcontrollers, drivers, and data paths behave.

The essence of his stance: Interest, persistence, foundation

Three attitudes crystallize from Michael’s remarks:

  1. Interest as the engine: Whether hobby or professional duty—the starting point is a genuine reason to care. Without it, there’s no energy to push through the friction.
  2. Persistence with flexibility: Detours are expected. Even if the first goal is too big, the road toward it yields knowledge. “In any case, you learn something.”
  3. Foundation before shortcuts: In embedded, fundamentals carry the work. Stack, heap, interrupts—these are not exam trivia; they’re daily tools.

Taken together, these points offer a realistic and encouraging picture: begin, keep going, and build the base that your work stands on.

Concrete snapshots from daily work: How embedded feels

Michael doesn’t deal in lofty metaphors; he lists activities that give you a feel for the day:

  • Set and verify bits: A decision in code becomes an electrical state on a pin or a setting inside a controller.
  • Work with debuggers: Breakpoints, register views, step-by-step understanding. Nothing is left to chance.
  • Use an oscilloscope: Make the signal visible; compare what should be with what is. Move from intuition to observation.
  • Reach for bitbanging: Control down to timing, to produce exactly the behavior that’s needed.

These snapshots cut past buzzwords. They show the core: embedded is where software meets physical reality directly. Success means building that bridge diligently—observable, measurable, reproducible.

Guidance for newcomers: Clearing your own path

Michael’s comments translate into a few straightforward, reliable moves:

  • Pick a problem that genuinely interests you: something you want but don’t yet have, or something missing in your day-to-day.
  • Find the starting point: Internet tutorials will give you a first handle in nearly any topic area.
  • Accept the learning curve: Ambitious goals may be too big at the start. Move anyway; break problems down; let detours teach you.
  • Use measurement: In hardware work, behavior isn’t only reasoned about—it’s observed. Debuggers, oscilloscopes, explicit checks.
  • Invest in fundamentals: In embedded, concepts like stack, heap, and interrupts become daily practice.

These aren’t flashy steps—but they hold up. They match the calm, matter-of-fact tone in which Michael describes his work.

What we at DevJobs.at are taking away

  • In-car communication is a system concern: multiple microcontrollers, substantial data, clear pathways. Ethernet is a pragmatic choice because it has proven itself and carries the load.
  • Drivers are the bridge: they connect hardware to the flow of data. Building that bridge means working at depth—on bits, on signals, on measurable behavior.
  • Learning starts with a real reason: a problem or an idea. The Internet provides the first handle; the rest is persistence and a willingness to learn en route.
  • Fundamentals aren’t an ivory-tower concern: in embedded, they’re daily practice. Dry topics become tools.

These points underline that embedded isn’t a glamorous buzzword contest—it’s precise, sometimes tough, and deeply satisfying craftsmanship. The reward is immediate: the controller does what it should because someone set the right bits and drew the right conclusions from measurements.

Thought starters for the week ahead

  • Frame a small, real problem from your own context—one sentence is enough.
  • Find the “starting point”: a tutorial, a documentation page, a minimal example. Begin before your plan is perfect.
  • Allow detours: capture what you learn along the way, whether or not the original goal stays within reach.
  • Revisit fundamentals: pick one of the topics Michael names (stack, heap, interrupts) and link it to whatever you’re working on right now.
  • Make behavior visible: if you’re near hardware, consider how you’ll observe signals systematically—via a debugger or instrument.

These prompts align with the spirit of the session: pragmatic, concrete, no false promises—focused on what holds up in practice.

Closing: Embedded as precise craft—and as a stance

“Embedded development—and that’s exactly what I like to do.” That line from Michael Wegner sticks. It isn’t boastful; it’s calm and convincing. Embedded, in his account, is work at the core—where setting a bit, reading an oscilloscope, and patiently stepping through code aren’t peripheral tasks but the essence.

At the same time, his message is encouraging: you don’t need a perfect setup to start. A problem, a starting point on the Internet, and the willingness to learn along the way—that’s enough. And if you take embedded seriously, you’ll see how much fundamentals carry. Stack, heap, interrupts: dry in a lecture hall, used every day in the lab.

It adds up to a coherent picture of this devstory: a developer who writes Ethernet drivers for microcontrollers in cars, bringing a proven technology together with hands-on craft and a learning-first mindset. It’s an invitation to anyone who wants to work close to the metal: begin, keep going—and build the foundation that will carry you.

More Tech Talks

More Tech Lead Stories

More Dev Stories