PSoC: Field Apps Engineer for Infineon (former Cypress) here. Questions?

[PartialDischarge]

Overall this is a funny thread. Non-users of a product telling you not to use it, basically because it is too low speced for your needs and you need a Zync not a Psoc, or whatever nitpick. Comment such as "this is far cry from FPGA" are quite insightful in that it reveals that bashing a product main reason is to show-off and portray how expert the haters are. This product is too few for them and they know much better.

It reminds me of Mac vs Pc discussion in which Mac haters point that a Mac has not PCI slots and no the latest processor and bla bla bla, yet they conveniently forget that the SW makes the difference in a Mac vs Pc, which last time I checked it still pure trashcan rubbish in a Pc.

Psoc has a nice variety of ICs from small packages to large TQFPs, from 24 to 80MHz, with added analog and programmable digital glue hardware PLUS the Psoc Creator which allow for quick development of general use control solutions with very fast time to market, in which I don't even need to read a datasheet to generate a PWM with dead time, and you can all self-called experts ignore this point but this tool makes 80% of the reason why I use Psoc.

I even did program a very demanding application in terms of formulas to be evaluated in a Psoc 5 to find the position of a magnet in space with 4 3D magnetometers:

[fourtytwo42]

I looked at using PSOC several years ago in a power converter where I was having trouble with the micro-controller PWM subsystem. As an experienced fpga/pld user i was hoping the psoc would solve my problems but unfortunately not. They have buried the functionality with stupid application software and as a result do not even document the capabilities. Pity, they came up with a good useful device that filled a market niche and then let the marketing goons destroy it. Had it been any good I could have used it in many other applications too, there loss.

[Siwastaja]

Overall this is a funny thread. Non-users of a product telling you not to use it,

No one said that. You are literally the only one who's forcing your way of thinking to others and derailing the discussion into fruitless battle. Cut it and let us talk. I'm sure the OP from Cypress can take it, and we can make this a fruitful discussion if you let us. Look, even if you are, not everyone else is a fanboy. Many of us are really experienced in using whatever parts from whatever manufacturer. Technical details matter. Thank you in advance.

[dgtl]

Let me give my insight of PSoC as I have been trying it out for both professional and hobby stuff. I haven't touched PSoCs for a couple of years now, so if things have changed then correct me.

In my opinion the real strength is the UDB, otherwise it is just a microcontroller as any other. If i'd like to get full gpio multiplexing, there are cheaper microcontrollers with that (LPC15?). For the most of the designs, the modern mcu-s have plenty of peripherals and having a spare uart makes pin muxing much more simple, there is no need to go full matrix. The peripherals are just cheap and plentyful. The partially universal serial peripherals (ie UART capable doing SPI etc) or even the even more universal SAMD sercom make more sense than making serial ports in UDB. Gaining the universalness of trading uarts for timers is not worth it for me. It's 2021 and the price of a transistor on silicon die is not that expensive anymore to worry about the cost of unused peripherals. Perhaps if there would easy ways to work with the existing UDB designs, it would be more useful to hack a feature in here and there, in case I'd need some quirk for an existing peripheral. But for this to work out, the stuff should be oriented to hard-core low-level developers, unlike it now is.

The PSoC creator software has had a lot of work put into it and is probably one of the most polished vendor ide-s out there. But it does not fit me. First, none of my machines run windows, except a virtual machine used for things like that. Also, it contains too much point-and-click for my liking. Give me good documentation of register level peripherals and I can handle the rest, like with all the other Cortex-M microcontrollers. It is not special, it is just another Cortex-M. In the Cypress case, I need to know another framework pushed on me. What all the APIs look like, what they do in hardware etc. This stuff may suit for Arduino-like users and it is a very important step of getting more professional at it, but that is already behind me. There have been some hacks that revealed the built-in ROM stuff in the PSoCs, which show what Cypress has been hiding from the user with unusually high efforts and all of this makes me feel that they don't like the users to step outside of their comfy gui wizard thingy and that is just too much limitations for me.
Why not just provide a simple Makefile project to compile with gcc? The designs to put into UDBs as simple C source, that just write the config registers in uart_init() to configure the UDBs and have a very thing example on top of it? Flash and debug it via OpenOCD using whatever tools I already have?

Where the UDB really shines is making custom peripherals for obscure interfaces. For example if you need a 1-wire slave port. Or driving a lot of WS2812 led chains in parallel. As usual, those use cases can either be handled by throwing more cpu power on it and just bitbanging the whole thing in software (ie via timer IRQs etc). Going the route of custom peripherals needs a lot of specialized know-how. It is fun in the sense of solving a challenging technical puzzle, but usually not worth financially. When going that deep into the PSoC, you're out of the shiny gui wizard territory. The UDB is not an fpga, it is just too small to write HDL and let the tools synthesize it. It works only when using both parts of it (PLD, datapath) and this means manually designing your controller for that exact system. It is a fine puzzle - the documentation is difficult and the needed know-how is quite deep to be good at it. You really need to visualize the datapath internals at the lowest level and map your function to it. At some point, the tools start getting in the way and not letting some configurations be entered that were possible via documentation (it was some years ago, perhaps things have improved). In any case, the GUI does not seem to help much, i'd rather write some files and let a tool to compile them. Finally, I'll need to figure out the software interfacing for that component, that is another puzzle through all those APIs and miles of not-so-well documented auto-generated stuff. I did get my stuff working, but I do not feel that I'd do this for any commercial work.

I cannot figure out the usefulness of the PSoC:
* Strength: Cool hardware, that could be hacked at very low level - but the software on top of it is dumbed down
* Strength: Making custom hardware interfaces - but it is so damn hard, that bitbanging in software on much more capable mcu makes more sense
* Strength: Standard Cortex-M microcontroller - but is hard to use the same stuff that works on the rest of them
...

[PartialDischarge]

No one said that. You are literally the only one who's forcing your way of thinking to others and derailing the discussion into fruitless battle.

I'm the only one here giving useful info about Psoc and correcting your misconceptions, who knows what it is good for and what it is not for. You're all just bashing it, and still haven't even been able to praise it for a certain number of applications.

Cut it and let us talk.

Snowflake much?.  You're saying whatever you want, that you are an expert and bla bla. Keep at it, I don't mind.

[Siwastaja]

In any case, this thread already shows why the market share for PSoC is what it is and stays that way;

We have approx. 8 quite experienced professionals happy working with many different product families and tools reporting:
* They want better documentation about internals
* They want freedom from Windows-only point&click interface
* They don't see large enough difference to other microcontroller families which also offer routability and configurability

And then we have one hobbyist(?) fanboy who reports using PSoC for every project(!), ridicules usage of assembly language, ridicules experts calling themselves experts, and gets butthurt when others do not agree. (Really, I don't care about the brand the slightest, and am not interested in bashing any microcontroller series. My mind does not work that way.)

It must be nice to have a product nice enough to create fanboyism - it doesn't happen with all silicon manufacturers at all! But at the same time, on silicon business, it does not generate much cash flow. You are not Apple or Tesla.

This 8:1 ratio of comments also translates into the customer base. As long as the main target audience for PSoC are those who cannot afford learning to work with microcontrollers "the classic way" and need a Labview-like interface, it stays quite niche. To compare, Arduino is highly successful but they are not a silicon company, they took an existing microcontroller and "dumbed it down" at PCB module level.

And don't get me wrong, this is not to say to abandon the pointy-clicky. Apparently, according to the comments I have heard earlier too, it's very good in its own genre and directly responsible for all the successful business in that segment. If you re-do it, the risk is you lose part of the existing customers, too.

But at the same time, trusting in your successful workflow only, is a limiting factor for growth.

Another limiting factor might be the disappointing nature of the HW itself. Not saying it's bad, but marketing and fanboys make it sound even better than it actually seems to be. Sure, it's quite flexible, but many others have become better as well within the traditional product segments without any big words. The bar is set higher today for the "baseline product"! You can't afford being just "a tad" better. Traditional MCUs handle 99% of projects just fine. You need to be able to handle significant part of the remaining 1%, and for that to happen, the products need to really shine.

If you want to see how you can get free routability of IO and ease of register level use in the same package, look at the Nordic Semiconductor products. Look at the manual to see how easy it is to configure a peripheral in whatever pins and DMA it.

Make your products even more capable and give barebones documentation (doesn't need to be polished; as ataradov says, we are fine reverse-engineering a bit if the HW is good) and I'm sure you can get more market share. Especially now as it seems you can't buy STM32 in next 12 months anyway, now it's good time to compete. And I'm sure all of us "critics" wish very best for PSoC product line because really, it's always great to have options.

[SiliconWizard]

Do not waste too much time replying to "flamewar" posts...

As it is, the OP themselves clearly stated:

I don't see a lot of projects with PSoC, and that's a shame! It's a good chip. I liked using them long before I worked for them. If you want something Arduino easy, but fully functional, PSoC4/5 is your mate. (PSoC6 is for hardcore nerds only, at the moment).

So experienced people giving the OP some possible reasons (and why they themselves wouldn't consider those products) sounds like something the OP (and possibly Infineon) could benefit from.

To add to what we said, interestingly here, the OP seems to be targetting the typical "Arduino" users, which are a majority of hobbyists. So no wonder there is misunderstanding here. The vendor may have a GUI-based dev tool that might be good for hobbyists (although even that point remains to be seen: I'm not even convinced of that), but the PSoC products were never marketed for hobbyists (and this would be way too small of a market for Cypress/Infineon anyway). So how can you wonder why they have a hard time finding their market? As I said, first thing would be to really define your markets and then design products accordingly... Do not reduce my (and others') opinion to "those chips are bad", this is absolutely not what anyone said here. Just that I do think there's a market problem here. Take it or leave it.

[Siwastaja]

To widen the market (to get "more projects"), I see exactly two possibilities:

1) Widen towards the "Arduino hobbyist" direction. This isn't negligible market anymore, most companies now take this seriously. As far as I understand, the current Windows tooling is quite suitable for Arduino folks. So to reach them, you'd need to add two vital things:
* Visible guerilla marketing, coming up with stories why Arduino hobbyists need or want PSoC.
* Very affordable simple boards/modules, similar to the Arduino boards. A $10 PCB with your $5 MCU, with USB connector, regulator, and pins brought out. $15 TOPS! With good availability, consider selling direct on a web store with free shipping, or getting a partner to do it for you. Many beginners are not comfortable ordering from Digikey.

2) Widen towards the professional electronic design direction. This is larger market obviously but surprisingly, more fragmented because different sizes and types of companies work in very different ways. Depending on the company, you need to:
* Reach out to the managers and ignore engineers; and/or:
* Reach out to the engineers and ignore managers,

If you do the latter, you will find some very thankful engineers and there might be some synergy between hobbyist and professional segment (but don't count on it). This means exactly implementing the points already well explained in numerous posts in this thread, I'm not going to rephrase them.

Whatever you do, don't reinvent your point-clicky because apparently many people like it. There are only risks involved.

[ataradov]

Many companies tried to shoehorn their product into Arduino-like environment, most failed (including Atmel/Microchip with anything that is not ATmega and SAM D21 to some extent).

The primary thing I want to see here is unique things I can do with the programmable logic part, since this is the only distinguishing part of this device. If there are cool use cases, then there is something to talk about. If we are still talking about trivial stuff like quadrature decoders, then no need to bother. It has to be something that is impossible to do otherwise. If it is just something to compensate shortcomings of the device, and others have it as a native feature, then I'll just use other devices.

[SiliconWizard]

GUI-based (AKA "RAD") tools are meant to either appeal to beginners/hobbyists (and not all of them!) or *some* managers that might be sold the idea that firmware development will be so much faster and will require fewer (and, let's admit it, less qualified) engineers. But it's a rabbit hole. You end up paying the consequences of driving a project using less qualified people, and just postpone the inevitable maintenance issues down the line. Maintaining firmware developed with GUI tools can often become a nightmare, and things get even worse if said tools have evolved in between and are note quite compatible anymore. Then you'll do the dance of trying to get ahold of an older version, which might not run on currrent OS versions. Etc.

Oh and still something to consider: even though Arduino in general is not particularly made for professional use, it's still entirely programming-based. It's not without its own flaws, but is still based on C++. If Arduino had been based on point-clicky stuff, I'm not sure it would have taken off and gotten as popular as it is now. So that's another thought.

[poorchava]

My question would be: why is it so crazy expensive? I mean in lower volumes for the price of 1 PSoC5, which is something like 67/80MHz CM3, I can get TWO 480MHz STM32H7s (ok, I would be able to, if they were available at all, but PSoC5 are unavailable either).

The programmable logic aspect is nice. Dev tools are also nice, But every time I had an opportunity to use one, the cost was just prohibitive.

Is this the same stupid sales tactic / politic that Wurth Elektronik uses (aka - retail prices even in 1k quantities are 2...3x higher than actual prices u get after speaking to a sales rep?)

As for the GUI, I don't really understand the hostility against it (and against various HALs, driverlibs, etc). If you don't like it or you can't accomplish what you need, or the performance sucks nobody is preventing you from banging the registers.

We actually use code generation GUIs for various chips (mainly STM32 and TI C2000) and it just cuts NRE time/cost down. And believe me when I say it: engineers at our company are as far from 'Arduino crowd" as one can possible be.

I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes. Almost all reasonable CAD software runs under Windows. Plus all the "Linux is free if your time is worth 0" stuff. Maybe it's good for web development or something, but I really don't see how Linux is relevent to Electronic/Electric/Mechanical engineering/CAD.

1 instance when I found PSoC useful (well, actually it was a PRoC, so no programmable logic, there are PSoCs with BLE integrated into them) was making a simple and cheap gizmo that communicated over BLE. This was probably the only part family that had a simple to use toolchain where I could just add some simple logic to the radio without adding a separate MCU to blink a led and talk with RF over [insert some serial interface here].

I have to say, that analog peripherals are not that bad on PSoC5 - I mean the ADC performance is similar to STM32 and just a bit worse than C2000. Not bad if you compare it against stuff like some PIC18s that had 12-bit ADC with +/-13 LSB INL+DNL and ENOB of ~8. Opamps with 2mV ofset and RRIO and 2MHz GBP are not bad either, at least for some rough measurements (I'm in precision T&M industry, so I'm probably a bit biased...)

[ataradov]

If you don't like it or you can't accomplish what you need, or the performance sucks nobody is preventing you from banging the registers.

This is the whole point here. You can't bang anything as the logic block is not documented at all on the low level. And if you are not using this part for the logic block, why are you using it at all? There are so many parts out there that are better in pretty much all respects.

[poorchava]

If you don't like it or you can't accomplish what you need, or the performance sucks nobody is preventing you from banging the registers.

This is the whole point here. You can't bang anything as the logic block is not documented at all on the low level. And if you are not using this part for the logic block, why are you using it at all? There are so many parts out there that are better in pretty much all respects.

Well, neither are most programmable logic devices. Most FPGAs that have hard blocks use GUI to configure them. Bitstream etc is also not documented, aside from some simple iCE40, that somebody reverse engineered. Most software nowadays has GUI...

[ataradov]

Well, neither are most programmable logic devices. Most FPGAs that have hard blocks use GUI to configure them. Bitstream etc is also not documented, aside from some simple iCE40, that somebody reverse engineered. Most software nowadays has GUI...

But none of them need GUI. Vendor tools work from command line (under at least Win and Linux) and everything can be described using HDL. And documentation is sufficient to write code that would instantiate a standard IP. And nobody is thinking that it is a good idea either, hence the reverse engineering attempts.

Here we have a completely different case. There is no immediately apparent reason to use PSoC, and poor documentation does not help the case.

And comparing that 32 FF logic unit to FPGA makes no sense either. In no way this is anything like FPGA.

[nctnico]

Well, neither are most programmable logic devices. Most FPGAs that have hard blocks use GUI to configure them. Bitstream etc is also not documented, aside from some simple iCE40, that somebody reverse engineered. Most software nowadays has GUI...

But none of them need GUI. Vendor tools work from command line (under at least Win and Linux) and everything can be described using HDL. And documentation is sufficient to write code that would instantiate a standard IP. And nobody is thinking that it is a good idea either, hence the reverse engineering attempts.

Here we have a completely different case. There is no immediately apparent reason to use PSoC, and poor documentation does not help the case.

And comparing that 32 FF logic unit to FPGA makes no sense either. In no way this is anything like FPGA.

I don't think there is a standard which says how many flipflops an FPGA needs to have in order to be called an FPGA. What is more important is to have a uniform flow. The PSoC tools seem to support using VHDL and Verilog so that should allow to re-use existing code on a PSoC. I typically use VHDL for tiny CPLDs as well just because it gives me a standard workflow to use programmable logic devices. But in the case of PSoC there is no clear information in the datasheet (using standard programmable logic metrics like LUTs, product terms, registers, etc) to indicate how much resources are available for use as programmable logic.

I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes. Almost all reasonable CAD software runs under Windows. Plus all the "Linux is free if your time is worth 0" stuff. Maybe it's good for web development or something, but I really don't see how Linux is relevent to Electronic/Electric/Mechanical engineering/CAD.

Even Gowin has a Linux version of their software nowadays. If you look more carefully you'll see every major vendor of programmable logic has a Linux version available of their tools. I doubt they made that just for fun. So yes, having a Linux version available for the software is a big plus to win design-ins.

[Siwastaja]

Fact is, even though many if not most professional design houses use Windows exclusively (and that does work, I have evidenced it myself), not everyone does that, especially when the main focus of the design team is in software (possibly stack of firmware and higher level processing).

HW CAD (SolidWorks, Fusion, Altium...), sure, happens mostly in MS Windows. This doesn't always mean firmware development happens, too.

Here's the catch: the more niche your product segment, the higher the chances the development cycle doesn't use MS Windows. Sure, MS Windows might be behind 95% of firmwares, but most of them are those super generic products that just use some very basic STM32F0..STM32F4 device. Those wouldn't buy PSoC anyway.

Now if your product is totally exceptional and you can't live without, everyone can accept MS Windows. But when competition is more dire, completely artificial limitations like this is one bullet point more in the pro/con list.

So this is great example of sacrificing market share by limiting choices.

Cross-platform software development is considered standard practice today. If you have competent developers, you can support all major OS's with not much cost overhead. The wider market pays back in no time.

[PartialDischarge]

My question would be: why is it so crazy expensive?

That is the main problem with Psocs. Fortunately the products I develop are not cost sensitive so +-5€ is fine, and long ago I decided that I didn't want to have any more than necessary time spent on the SW since the HW is the difficult part.
Happy I was the day I deleted Code Composer Studio.

[poorchava]

...Fortunately the products I develop are not cost sensitive so +-5€ is fine, and long ago I decided that I didn't want to have any more than necessary time spent on the SW since the HW is the difficult part.
Happy I was the day I deleted Code Composer Studio.

Well, my job is specialist T&M gear for power industry and related fields, so cost Is also not the primary issue here. Bute as one of my friends, who is quite well-off said: "rich or not, I'm not gonna pay $100 for a cabbage". It's the same here - radio chips seem to be the only justifiable part of that portfolio, as they don't require expensive sw tools to develop code for. The other stuff is just too expensive too justify.

The only use case for those that I can imagine, is if you need to make something REALLY small, yet can't go into custom silicon. Then maybe having some logic and analog integrated into a single chip makes sense.

I recall a show at Electronica Munich, I think 2016 or 2019, where they made a line follower robot with something like 5 lines of code. Nice, but commercially irrelevant.

As for Code Composer: I use TI's C2000 DSc's... Those parts really leave others behind when it comes to digital SMPS and power quality analysis. Compiler produces very high performance code. In general for DSP-ish applications (filters, FFTs, smps/motor control) A 100MHz C2000 performs better than STM32F7 @ 216 Mhz. But the toolchain, IDE and documentation are some different dimension of garbage... They are improving now, but it's still really painful when compared to STM32 IDE, or even MPLAB

[westfw]

I'll have to admit to being relieved/happy when the PSOC4 started including "standard peripherals" like USART and SPI, instead of requiring that those be built out of the logic cells.  That made it a lot easier to start at a "general purpose part" view, and see "what else" could be done, rather than guessing what might be "left over."

[radar_macgyver]

One feature I would like to see which would come for free once the programmable analog and digital hardware are exposed to the programmer is on the fly reconfiguration of the analog subsystem. My line of work (at a small remote sensing research group) requires some hardware whose functions are not fully defined when deployed. Being able to reprogram the analog interconnect without a reflash would be a great help.

The PSOC5's programmable analog and digital blocks combined with an ARM core are a good match for many of the boards I design, and the ability to assign special functions (including analog) to any pin greatly simplifies my board layouts. However, none of this matters right now since I can't buy any devices (repeatedly quoted > 1 year lead times), so looking hard at alternatives.

While PSOC Creator is quite nice, I would love it if I could stick with my IDE of choice (vim and Makefiles). The cysch blob and xml also don't play nice with version control (though this is better than, say Xilinx ISE since user preferences are in a separate xml file that isn't version controlled). I can't really do a diff between today's cysch and yesterdays to see what changed.

[Siwastaja]

The great feature in modern general purpose MCUs like STM32 series is, their analog blocks and signal routing is controlled by memory mapped control register writes and hence accessible from C(++), ASM or whatever you are writing the application in. This also makes dynamic reconfiguration a total no-brainer, you don't even think about it being dynamic reconfiguration, it just is.

This is also why I don't use Cube-like code generation. They generate long piece of initialization code which is then in the beginning of the application. Of course you can divide it in parts, shuffle it around and so on, but then you lose the simplicity of autogeneration, need to understand that autogenerated code, maintain it, and this is more work than writing more minimalistic code yourself.

I'm surprised if PSoC analog block routing cannot be configured runtime, or if it is more difficult than it needs to be. Is this true?

Really, look at the nRF series, how they implemented full free IO matrix. You write port and pin number in a register and bang, it's connected. One obvious line of code that directly shows the pin number:

UART1->PSEL.TXD = 0<<5 | 27; // connect UART TX to pin 27 of port 0.

Seeing PSoC series really doesn't implement FPGA level of complexity, what is preventing this approach to be offered? If the internal registers are not designed as cleanly as nRF did, then simple wrapper functions could be offered, they would also work as documentation and examples.

[JPortici]

I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes. Almost all reasonable CAD software runs under Windows. Plus all the "Linux is free if your time is worth 0" stuff. Maybe it's good for web development or something, but I really don't see how Linux is relevent to Electronic/Electric/Mechanical engineering/CAD.

From time to time i have to dig out old libraries/AN from various manufacturers and they usually come in a prepackaged EXE file instead of for example a zip archive.
The exe file is more often than not difficult to open because it requires some component not available since XP or, even worse, it's a 16 bit executable.

The problem with "windows only" solutions is that they usually are closed and/or lack in documentation, which means that when the one click solution won't be mantained anymore you will be screwed.

I tend to not use radios from silabs for this very reason. Before you can start using the goddamn chip you have to load a binary blob with no documentation whatsoever, not even on what you have to do to start the chip.
More or less as with screens you have to get an autogenerated project and dig though the code and the macros

[bingo600]

Lot's of info & questions here.
The only thing i miss is that the OP would answer some of them.

Was OP just a "Catalyst" from marketing ??

/Bingo

[RoGeorge]

I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes. Almost all reasonable CAD software runs under Windows. Plus all the "Linux is free if your time is worth 0" stuff. Maybe it's good for web development or something, but I really don't see how Linux is relevent to Electronic/Electric/Mechanical engineering/CAD.

That is so not true it reminded me about Kupamanduka concept.
https://en.wikipedia.org/wiki/Kupamanduka

[Nominal Animal]

I don't really understand the "windows-only" argument. Linux is dead as far as serious engineering goes.

Unless you do serious engineering, like distributed stress FEM analysis (mechanical engineering) or fluid flow analysis (chemical/process engineering) or use custom code for finding optimal routing patterns (electrical engineering), and similar.  You either do that stuff on your desktop PC, or you use a cheap Linux cluster (with expensive Nvidia cards) to do it one or more orders of magnitude faster, leaving you with a functional desktop machine to do other useful stuff at the same time.

As far as I understand it, only the middle to low end engineering houses are Windows-only; the ones that do mostly the same jobs again and again for different customers, and not anything really new.

Among the current 500 largest computing clusters, there are 500 running Linux and 0 running Windows or anything else.  There is a reason for that, and it isn't that "Linux does not cost any money".  Microsoft has spent a lot of money subsidizing attempts to crack the 500, and the amount of hardware they needed to get comparable performance was so ridiculous even they gave up.  Even Azure runs on Linux.  (I do not have statistics on engineering houses, so I grabbed the ones I know, that cover the top 500 HPC clusters.)

Fact is, for pure computation tasks, Linux is much more efficient than Windows is, no matter how much you prefer Windows.

I've done HPC for a living, and even maintained a mixed set of Windows, Linux, and Mac OS (pre-X) desktop workstations quite successfully, so I'm not your typical "Linux fanboi".  I use whatever tool is suitable for the task.  And Tux is only my mascot, not my idol.  Whenever I build a new desktop for myself, I almost always get a free Windows license on top (simply because retailers include it when you buy a specific component set; it's difficult to avoid paying the 'Microsoft tax'), so price isn't one of the reasons why I use Linux exclusively.  I do often help others port their proprietary stuff between Linux and Windows/Macs, but mostly on the Linux side.

I compile C and C++ for avr, x86-64, various arm, aarch64 (64-bit arm), and mipsel_24kc (ramips); and these are currently best supported by GCC and LLVM/clang.  Intel C compiler collection generates better code for x86-64, but I'm just fed up with the shenanigans it used to do to explicitly hobble AMD64 code when running on AMD processors, so I don't nowadays bother with it; the hassles are not worth the gains, especially now that Intel-AMD processor battles are heating up again.