Hacker News new | past | comments | ask | show | jobs | submit login

well, I work for Microchip, so I won't be writing code for other manufacturers' processors, at least not for my day job :-)



Well then go lobby for creating dsPIC support in LLVM! Selling 10M chips at a time is great and all, but designs start with a single engineer. The 16F84 was the hobbyist darling until gcc-avr ate its lunch.


PIC is not an open-source-friendly company. They literally wrapped a license manager around gcc and used it as their C compiler on several platforms, and their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc. If they did switch to LLVM, it'd probably be so they could closed-source their compilers completely.


Sheesh. I worked with their 8-bit chips in an era when using a C compiler was essentially just a nicer syntax for ASM (and you really didn't want to deal with code written by someone who thought differently). In that environment, their easily available good documentation is about as close as you can get to Free. Software complexity was of course on the rise and I figured it was only a matter of time until they "got it" with regards to a Free C compiler etc.

It's sad to hear that they've dug their heels in even further and are now one of the few examples of bad-faith attacking the GPL through contracts. Especially because recently reading their ENC28J60 documentation was a nice break after wading through STM/ARM's stuff.

If I'm ever again in a position where I'm choosing chips for a production design, I'll be verifying what you said for myself (diligence) and then steering clear to less risky alternatives.


I'm not sure I would believe the comment by the person who you are responding to.


> their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc

This is a quite serious concrete accusation. It would put Microchip in the company of Tivo and Sveasoft - not simply ignoring the GPL, but actively attacking it through bad-faith contractual restrictions.

But yes, I would definitely have to see the specific license for myself before forming any conclusions. HN is essentially just gossip, and GP could have very well interpreted a clause too broadly. But I'm not interested in sorting through what's new in the Microchip world just to preemptively answer this, especially because he could be referring to a single specific library that would be hard to find.


Microchip does have a standard license for maybe 99% of its firmware libraries, that includes this proviso, that just forbids you from using the software on microcontrollers made by other manufacturers:

  Microchip licenses to you the right to use, 
  modify, copy and distribute Software only
  when embedded on a Microchip microcontroller 
  or digital signal controller that is integrated 
  into your product or third party product
  (pursuant to the sublicense terms in the
  accompanying license agreement).
If there are any other restrictions, I'm not aware of them.


PIC is not the name of the company. It's Microchip Technology, Inc. You seem to be upset about something, since I don't think you have the facts straight about the XC series of compilers; the source code for XC16 and XC32 is posted here under "Source Archive" http://www.microchip.com/pagehandler/en-us/devtools/dev-tool...

Microchip has a number of open-source initiatives. You can use the internal guts of MPLAB X from Java via MDBcore, for example, as a scriptable debugger/simulator.


>Well then go lobby for creating dsPIC support in LLVM!

Um. Been there, done that. Well, you see, [: discussion of internal politics deleted :]




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: