Hacker News Reader

Comment by gregfjohnson | Hacker News Reader

On the topic of Microchip and secrecy: I downloaded and installed their IDE, MPLAB X IDE v6.20. It is for a pic3mx chip. The compiler looks like a completely generic gcc, built to cross-compile on a Windows host. However, they want a $1000.00 “licensing fee” in order to enable any optimization level above -O0. This seems wrong. Wouldn’t this be a violation of the copyleft license covering gcc? I’m guessing there’s some loophole, since otherwise EFF and folks would be going after them. Or perhaps they don’t know about this situation? Should I alert EFF to this situation

View on HN

The GPL in no way forbids that. However, if they are obeying GPL you can ask them for the source code and then remove that limit yourself. If you ask for the source and they don't give it to you, then alert GNU.

In some jurisdictions you may even be able to sue them for the source code without bothering GNU.

Of course that depends if the optimization was compiled into the version they have. One can imagine two binaries with the optimizations just missing from the free one.

If they distribute the one with optimisations, then they need to make the source available.

... but only to the ones they distribute it to. They can then choose to redistribute it if they want to.

... a.k.a. the RHEL model (with contract termination on sharing source).

How much does it look like gcc? Can you run it on its own with a --version argument, or run it through strings to get the text out of it.

If it's actually gcc, a copy of the GPL should have come with the software. A bunch of other compilers mimic a lot of its interface for compatibility’s sake.

Ran into this at Google. Qualcomm compiler for their DSP was an expensive branch of GCC. I asked my manager if we could just ask them for source instead of paying per-seat license. He said that “ our contract with Qualcomm specifically prohibits us from asking them for the source of this compiler”. They found the workaround tor GPL I guess.

I have heard that this is how it is done before. I wonder how that works with a third party? If they happened to come across the binaries some how they could demand the source. I also wonder if that clause is enforceable.

AIUI the entity distributing it has to provide the source. So if Google were to (try to) (re-)distribute that compiler, they'd be legally fucked because they'd have to provide the source… which they don't have and can't get.

(But presumably that agreement also restricts Google from redistributing the binaries anyway.)

The GPL doesn't say you can't charge money for things. Do they provide patches for their changes to the source?

I think that the issue here is the following:

    - you can charge money for things
    - anything that's not built with the "official compiler" is not "supported"

I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and told me "Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE.

They used ARM chips, so not even anything strange...

The real issue would come if they did not provide the source code for the gcc build they sell you, though.

Offloading the liability for a compiler sounds like common sense to me. How many heads did this company pay? 100, 1000?

Related, compiler bugs aren’t uncommon in the arm-none-eabi family. Especially the cortex m0 seems to have a few that recur every few years.

I have not used anything but arm-none-eabi-gcc for STM32s from day one. Never even installed CubeMX or any other ST software.

> Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE

This is critical if you want any support from the vendor.

If you come to them with a bug in their hardware but you’re not using their toolchain and BSP, it’s the end of the road. You have to recreate a minimal reproduction of the bug in their ecosystem before they’ll look at it.

When you’re working at company scale, paying $1000 for a compiler is a trivial expense.

I avoid vendor toolchains and BSPs just because of how buggy they are.

From my perspective, it's much better to reproduce a bug with a 20-line C or assembler file that compiles with upstream gcc, completely ruling all of their custom stuff out as the root cause.

Just tell me what the silicon does when I poke this register and I'll work around it.

> not using their toolchain and BSP, it’s the end of the road.

Mhm. I'd say, you're forced to reproduce it on their toolchain and BSP, which may or may not be the end of the road depending on how complex the problem and your use case are.

IME you're usually on your own anyway. I've rarely found it worth slogging through their crappy BSP for the chance of maybe receiving some useful support.

(I am aware that there's a certain kind of mindset that likes to lean on support from vendors to do basically anything, and I think if you're in a position where you actually get good support, that might work, but in most of the instances where I've seen such a mentality it tends to produce expensive results that still don't actually work, and sometimes even when AFAICT the vendor's pretty switched on, they just don't actually have all the context)

It's been this way forever... They do distribute source (but last time I checked it is with incomplete build info). I think there is also some BS fine print about the licensing fee being for the provided header files.

Yeah I’m really not a fan - we had some designs with PICs on them and ended up switching to NXP micros (MCX-A and i.MX-RT) instead, partly because of MPLAB and also because the Microchip ones had some annoying quirks. NXP’s documentation I find a lot better too. I literally try to avoid Microchip where I can from the experience…

Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns.

I liked working with Microchip uC, but this was back when the whole IC (PIC24) was described in a single ~1000 page document. I found it very readable and instructive in general.

If I had to pick something today it would be with RP2040/2350. The docs look awesome and there's a huge community that is not locked down in some corporate moderated forum but spread organically, with actually useful GitHub projects. It is the only embedded product where it felt like the open source community is along for the ride and not just picking up the scraps. I hope they continue this line of products.

Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.

It felt very different and not pleasant.

The PIC24 was actually my first large project. I learned awful lot from reading its docs, for example setting the DMA to read 32 samples from ADC and let CPU know when done. Putting it together felt like playing with LEGO blocks. There were many annoyances with the toolchain and the clumsy memory addressing but I enjoyed it overall.

The NXP was downright unpleasant compared to it. I don't think a junior could be handed a NXP dev board and all the docs to hone their craft. It requires significant patience and expertise to pick out the relevant details in the vastness of their documentation. Of course the NXP product line is huge and I can only comment on few uC models I had contact with. The sensors and other less complex ICs were vastly better and docs were quite digestable.

When you add up all the various PDFs documenting the NXP MCXN947 it comes to around ~7,000 pages.

They have the source code on their website: https://www.microchip.com/en-us/tools-resources/archives/mpl...

That's such a weird thing to do. MPLab used to be completely free to encourage people to use their chips.

Reply on news.ycombinator.com