[st_goliath]

> ... don't require absurdly bloated development environments.

Outside hobbies, I've been mostly away from this field for little over a decade by now. Is it still that bad? I remember back then, every single professional electronics engineer that I met had this die hard belief that this was simply how things work:

You want to use DerpSemi micro controllers? You must install DerpStudio '98! Not the later 2005 version tough, that has some major UI bugs. You want to program a HerpSoft PLC? You need EasyHerpes IDE! What, command line toolchain? Text editor? You must be completely insane!

It's been somewhat of a personal fight against windmills for me back then. That, plus suggesting that we are actually developing software and the C/Assembly/VHDL maybe shouldn't be an undocumented, tested-only-once pile of spaghetti based off a circuit diagram inside one guys head (and no, a 50 line comment block with a German transcription of the code below is not documentation).

[Ygg2]

> and no, a 50 line comment block with a German transcription of the code below is not documentation

You had it good back then. Now it's a one-line comment in Chinese. Line is 300 characters wide. /Yorkshire men skit.

[st_goliath]

Now that's funny. The irony here is that, besides German (native), I do speak some HSK4-ish Mandarin as a 3rd language. A few years ago, a single line Chinese comment next to a blob of magic hex values did help me figure out a bug in a touch controller driver :-)

[Aurornis]

It's not that the official tools are the only way to work with parts.

It's that they're the only vendor supported method of working with the parts. If you build your product with an unsupported toolset and something doesn't work, you need to be prepared to reproduce the issue in the vendor support toolchain if you want support.

People coming from desktop and mobile development roll their eyes at this because they aren't coming across bugs in their x86-64 process or M1 Silicon that haven't already been patched over by some combination of microcode, the OS, and the toolchain. Everything works as expected.

Not so in the world of embedded. On modern complex systems, vendor involvement can be a critical part of the development process. Many of the products you have in your house like your router, Wifi gear, and IoT devices were probably co-developed to some degree with the hardware vendor. Starting with the vendor-provided reference design gets you to market much faster, even though you often could forge your own path with a separate toolchain and start from scratch.

It's still this way even in MCU development. You can go out and develop something like an STM32 system completely without STMicro's tools, but it's much easier to start the project in STMicro's tools and copy over the parts you need for setting up everything from clocks to peripherals, then to maintain a skeleton project in the official tools in case your separate toolchain starts acting funny.

[mrheosuper]

>It's that they're the only vendor supported method of working with the parts

And it's because those engineers do not demand. "I Want something easy to use and has GUI, not some Terminal command line"

[ACCount37]

It's much better in microcontrollers. Almost everything can now be handled with VSCode and some open source compiler toolchains.

PLCs and FPGAs are still pretty damn bad though.

[f1shy]

> Is it still that bad?

IMHO yes, if not worse.

Working now with some advanced devices from Xilinx (using very expensive top-line SoC. If you change version of the Vivado tools, you have to basically start again from 0 your project. Is a complicated mess because of matching of the OS in the ARM controller and the FPGA part…

[robinsonb5]

One thing I will say in favour of the Gowin IDE - it does seem to be much more lightweight than the larger vendors' tools. For smaller designs it will often go from zero to bitstream in less time than Quartus or Vivado would have taken to even start synthesizing.

[dreamcompiler]

It's that bad. FPGA designers on my team would routinely start a Vivado job and come back 8 hours later (because that's how long it typically took) and discover Vivado had crashed.

Vivado is expensive, bloated, buggy garbage.

[wucke13]

I have dedicated a large chunk of my (arguably short) professional career on improving upon this, mostly in the safety critical software domain. What was your experience back then, what made you leave ultimately, and what do you do now?