As a fellow embedded software engineer, I made the migration from Windows to Linux some time ago. You'll see that except for old targets (or highly proprietary ones like fpga) most if not all tools used today are actually open source ones (ide based on eclipse, gcc toolchain, jtag debugger...). Once you understand how they all play together you'll see that it's actually easier to work on Linux, as those tools are in their primary element, not half bad ports to Windows !

> You'll see that except for old targets (or highly proprietary ones like fpga) [...]

Your overall point is stronger than you think: Xilinx's FPGA toolchain [1] has official Linux support, and their embedded software toolchain (based on yocto and gcc) actually depends on Linux!

[1] Xilinx is the market leader for general purpose and high-performance FPGAs. The situation is slightly different for space-grade and very low-power FPGAs, although Microsemi has been supporting Linux for many years as well.

Official Suport for Xilinx means "should work some of the time", provided you use this old and bloated daemon to communicate over USB. You will still need a separate hardware killswitch to work remotely, because the driver is flaky as hell.

"should work some of the times" is also what you get on Windows.

Source: buddy worked as sw QA for xilinx.

Linux is _by far_ the best platform for embedded development.

Vscode is available as an official snap (on Windows you need to download and update it manually), Segger tools and openocd are fully supported. GCC cross-compiler and even some flashing tools are part of the distro and just an apt-get away.

This also means that everyone get the same tools (same version, same bugs). Which makes collaboration much easier.

> This also means that everyone get the same tools (same version, same bugs).

Everywhere I've worked solved this by having the toolchain available via a network share that you would mount/copy, or checked into p4 so that everyone would be on the same version and you would know what compiler version was used to build a particular release. I suppose you could achieve the same thing by building in a Docker container..

This is kind of the idea behind the hermetic environments that Bazel enforces, and is essential if you want bit-for-bit reproducible builds.

Yeah, but everything is easier if it's native to your machine :)

We have used Docker images in past but it gets really annoying with large code trees and access permissions for programmers and debuggers...

Just a small correction:

>on Windows you need to download and update it manually

you don't need to update it manually, it will show a popup that an update is available and will update itself once approved.

It used to direct you to their website to manually download and install it. Given how often it is updated most people started ignoring those pop-ups.

Maybe that used to be the case? For at least the last few VS Code updates, it's been entirely in-app. The update is downloaded in the background, and VS Code then prompts you to restart the app to apply the update.

is there any debugger as good as the Keil IDE in Linux?

Hmmm, this is kind of the wrong way round. In my experience all the good stuff is on Linux, and windows have these bad broken ports. Depends on a lot things I'm sure...

I've done lots of embedded development on Linux, and it's mostly been a painless experience. Segger has a Linux library which works great, as well as Embedded Studio which runs on Linux. GCC-arm and several other compilers are avaible. I've been working a lot with Nordic Semiconductor's ARM-based SoCs, and I'd say Linux is a fully viable environment for the applications I've worked on.

You haven't seen it coming with Windows 8 ?