Microchip jumped into open source last spring with the chipKIT Arduino-compatible development boards and open compiler/IDE. They wanted to tap the existing tutorials, enthusiasm, and customer base of Arduino community, and they were going to play nice with open source. A review of the chipKIT situation today is disappointing. The compiler still replies on closed source, and there won’t be open drivers for key advertisedfeatures like Ethernet and USB.

Microchip parts are used in most of our projects. We think they make great chips, and PIC debugging tools are cheap and plentiful. We use Microchip stuff in open source, but Microchip isn’t always open source friendly.

When Microchip dropped the chipKIT we were optimistic. Microchip invested in the Arduino IDE and released an open source compiler for PIC32. Ethernet and USB shields were in discussion at the time (now available), and we speculated that there would be an open source USB and TCPIP stack.

Four months after the fanfare of the chipKIT launch, things aren’t quite as rosy.

Compiler issues

Microchip’s compilers are based on the open source GCC compiler, but they keep some special sauce locked up. Replacing the closed parts isn’t trivial, there aren’t any alternative open source compilers for most PIC chips. Microchip gets the benefit of a community-developed free compiler, but they keep key parts closed that prevent open alternatives. Not all manufacturers do this. Atmel played nice with open source compilers and were rewarded with the Arduino community.

We were assured there was no funny business with the chipKIT compiler, but as of today there are still parts of the chipKIT toolchain that are not open. The standard C runtime library is not available as source. This is not part of the compiler specifically, but it’s needed to build the libc.a file used by the compiler. Microchip cannot make the current version open source due to license agreements with other companies. Without this code, the chipKIT compiler is incomplete. You cannot take the github source and end up with the working package they distribute.

There are solutions to the compiler issue. The open source Newlib standard C runtime library is an alternative. Porting isn’t a pipe dream either, the Pinguino project has already done it.

Closed source drivers

This week saw the launch of Digilent’s network shield. It supports the Ethernet and USB features of the chipKIT MEGA. Some drivers are needed to do anything useful with it, the most basic are a TCPIP stack and a USB stack.

We were optimistic that Microchip wanted to play fair with the Arduino community. They would release open source drivers to support these heavily advertised features. Unfortunately, it’s not going to happen. Only Microchip’s closed-source drivers are available to support Ethernet and USB on the chipKIT network shield.

Microchip has fantastic USB drivers, and TCPIP drivers with web server demos and other good stuff. They are available under a free-as-in-beer but not free-as-in-speech license. You can get the code from their website if you agree to the Microchip Application License, appropriately abbreviated ‘MAL’. It prohibits distribution, use with non-Microchip products, and gives them:

the right to reasonably inspect Licensee’s premises and to audit Licensee’s records and inventory of Licensee Products in order to ensure Licensee’s adherence to the terms of this Agreement.

Heavy stuff, not open source friendly. We use the Microchip USB and TCPIP drivers in several open source projects. Since we can’t redistribute their code, we only include our own files in the source, you have to get the USB driver from Microchip on your own. This isn’t a huge deal, but it’s a definite barrier to a curious newbie who wants to learn more about Microchip’s products.

We don’t understand the advantage of these restrictions. Would a competitor like Atmel risk the appearance of weakness by relying on code from PICs? There are abundant free and open USB options for most other platforms (AVR, ARM), so lock-in doesn’t stop people from using a competitor’s chip. Clearly Microchip is aware of the advantages of open source because they rely on the GCC compiler and want to be in the Arduino ecosystem.

Digilent is the designer, manufacturer, and distributor of the chipKIT hardware. We applaud Digilent for releasing all the files for their chipKIT designs under an open source license.

Gene from Digilent stopped by the comments last week and gave us some background on the TCPIP and USB support for the new shield. The chipKIT team pushed hard for open drivers, but lost. Digilent may write drivers, but that’s a huge project that couldn’t possibly be a good investment for a development board maker. We urged Digilent to adopt the open source JTR-Honken USB stack and help us build a top-notch community driver without restrictions.

Why it matters

It’s great that Microchip invested in the Arduino open source IDE intends to release an open source toolchain*. Unfortunately the contributions seem to stop with support for their product. Parts of chipKIT toolchain are still closed-source, and Microchip isn’t contributing open source drivers for the highly-advertised USB and Ethernet features of the chipKIT Mega.

*Rick Anderson clarifies below that Microchip did not invest in the multiplatform IDE. They are responsible for their toolchain only. We regret the error.

We buttressed this editorial by saying we’re huge fans of Microchip stuff. It’s their time-honored right to deal in closed source software – most companies do! With the chipKIT, however, Microchip wants to tap the Arduino buzz. They want promote products using the work of an open source community, but they’re not participating in the spirit of that community. It’s not illegal, it’s being a bad neighbor.

We urge Microchip to give something significant back to the community they’re tapping. Open source drivers for the chipKIT shield would be a great first step.

This entry was posted
on Tuesday, August 30th, 2011 at 3:59 pm and is filed under open source, PIC.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

For years I used Microchip over Atmel, TI and ST but I’m now removing PIC from my workspace completely. Have not purchased PIC for many months already and do not plan to purchase one any more (still have plenty lying around in drawers so will use those for some projects – but not purchasing any ever again). The major benefit of the Microchip over Atmel was pickit2 vs all other cheap atmel programmers (usbasp and similar). PK2 was just way faster, super simple, very cheap and made in circuit debugging possible. Now things change, AVR DRAGON cost as much as PK3 and allows me to program atmels as fast as pickit does, and allows me to in circuit debug them. So in that field they are now same. Now PK3 is required for most of pic’s I now use and compared to pk2, pk3 is piece of crap; it’s slow, it halts etc etc … very unreliable piece of hardware with very limited software support (remember all the stuff pk2 can do)… still no gui for pk3 after so many years ?! Anyhow, as tool wise they are now similar (both dragon and pk3 are not ideal but..) in all other fields that matter Atmel win’s by much. All tools are free, C compiler for all products, open source compiler, open source libraries, open source drivers … If you’r making proprietary products they are fairly similar microchip and atmel, but for open source products atmel wins by sooooo much…

it really makes me wonder why DP chose microchip as basic mcu type in the first place ..

Alan, I’m using them both (and TI and ST32) but I never noticed the issues ppl mention that actually are serious if you plan to do anything more then pure hobby (availability of the chips, discontinuation of the chips etc etc). Wrt maket share being lost the last info I had was that mchip could purchase atmel with petty cache money so I’m not sure they are ever going to feel threatened by atmel (if they do – they will just purchase it). Now I might be wrong and that information might be a FUD spread by evil minds, I do not know of a way to test validity of that claim. It is obvious that open source projects are more and more leaning on atmel, and it is obvious that mchip management don’t care. Now how big that change is wrt microchip’s market share I can’t say. If atmel is moving from 1% to 1.5% for atmel it is a huge (50%) increase in market share but for microchip that’s 0.5% loss – not something worth discussing on top management meetings.. on the other hand if atmel moved from 40% to 50% than that is a crazy dangerous situation and heads in the top management need to roll.. I have no clue if that move you are talking about is closer to one or another scenario… I know many microchip fan’s that support one and many atmel fan’s that could swear that microchip has 2-3 times less market share then atmel has.. so getting information one could trust is in my case impossible. You might be in position to have sources you can trust – I am not. I’d say guy’s that designed chipkit have a way of knowing some informations not available to us mortals and they decided to design chipkit – investing their own money and time!!!! It is a very strange decision one could spend a lot of time deciphering. But I can say from few words I read that those guy’s wrote on DP forum/blog that they are good guy’s in all this and that there’s no reason to “decipher” decisions they made :D – we can just ask them directly. Question dough is if they are obligated by some NDA or some business courtesy not to disclose that info…

I have an AVR Dragon that I can use under linux using the opensource avarice and avrdude to program things like their ATtiny series up, everything written in gcc using the avr toolchain. I use the whole Arduino environment occasionally. But even the Arduino now has several things from Seeed studios including a mega with all 4 input captures brought out. This is the network effect in action. And I doubt Atmel spent a lot of time, effort, or money doing these – the community was the greater part – Providing help and guidance is the main contribution a manufacturer can make. Once the base is there and is open, the community usually runs with it, and it grows exponentially.

There is a big difference between free but fenced and open.

They will probably declare the project a failure eventually, but it won’t be the failure of the community.

And there is a danger in that. I am not as familiar with PIC chips because I don’t have the tool setups because they aren’t open. If I had a paid project I would learn, but otherwise why bother? If there are lots more engineers who know Atmel ready to go than know Microchip, they are likely to be a factor in choice of chip. There isn’t a large gap in technology, cost, or features.

Yes, they are not part of the OS community, that’s why I wonder why DP chose microchip mcu’s … I don’t see a problem for proprietary dev’s to chose microchip, I find their datasheets much better then atmels and their app notes way better then atmels (reason I mainly moved to microchip for small projects)… I don’t use arduino nor have any wish to, it’s for beginners really and the users are like a religious sect, not a kind of bunch I want to be with .. If microchip made it’s tools and libs open it could be used outside of arduino ide too and that was something to hope to, but unfortunately, microchip being microchip …

As for the knowledge, I see actually way more ppl knowing microchip then atmel, more forums with pic guy’s then with atmel guy’s .. but if you look at it from the open source perspective, way more opensource projects for atmel then for microchip – and that’s only microchip to blame :(

arhi, one MAJOR advantage of Microchip is supply. Atmel chips seem to periodically disappear from the supply chain for months on end for some models, while PICs remain in stock in large numbers. They’ve also got a very wide variety of peripherals available, which helps a lot depending on your application.

As for the Dragon, it’s a nice device for as long as it continues to work – the power supply circuit is fragile at best.

randy, donno what to say, I never had a problem sourcing atmel… but you probably have a reason for saying that so it is surely true. I basically live in a crappy country so I have to source stuff online anyhow and I’m used to waiting; pic or atmega, no way I can get it faster then 2 weeks :( anyhow…

as for the dragon, as mentioned in other blog post comment, use it from properly powered usb hub and don’t use it to power target board and there’s never a problem with it :). but yes, the psu part could use some work :)

Good on you Ian for drawing some attention to this issue – and reconfirming my avoidance of anything from Microchip.

I was actually surprised by this post – I didn’t think DP really cared about open tools and drivers that much given the extensive PIC use in your designs, and bias towards Windows based PC software and toolchains.

It always seems crazy to me to label something “open hardware” when using products from a company that doesn’t even offer a decent open tool chain or open drivers.

Sure it’s great to be able to see the circuit diagram and fiddle with a layout, but these days a lot of the important functionality is in code. If that functionality is closed entirely, or behind a toolchain paywall, or not able to be modified or distributed then I think it makes the whole “Open Hardware” movement much less interesting. “This bit over here is open, but you aren’t allowed to see or touch the interesting parts in here”.

I have personally hesitated on buying DP hardware due to PIC chips being used. Based on previous experience, I know if I ever wanted to hack on the FW I would quickly hit a closed wall, especially since my desktop environment is Linux based.

On the other hand, when I first picked up an AVR a few years ago, avr-gcc and avr-libc were already packaged by my distro and quickly installed. They worked great with plenty of examples and doco and community around them.

Similarly there are plenty of cheap ARM chips with great Linux toolchain support around.

Microchip on the other hand doesn’t seem to have attracted or fostered an open community around their products.

I’m happy to vote with my dollars, and I encourage you and DP to look into Microchip alternatives for future designs. I know there is overhead in learning a new tool chain, and the competition may not always be as good, but I think it is essential for anything labeled as open hardware.

Please don’t construe my comments as anti-PIC or anti-Microchip. I like the company and I like the products. This is just one instance where I think management acted poorly.

Like any designer or engineer, I will choose the part I think fits my project the best. That tends to be PIC for simple hobby stuff on a 2-layer PCB. Personally I first learned on AVR, then MSP430, then ARM, then some weird stuff (8051s, CPLDs, etc), and only recently PIC. I have no preference more than I prefer a hammer to a saw, they fit different needs.

I don’t put a lot of emphasis on open tools and drivers, that is true. Free is OK, as long as everyone can get it free and reproduce the results. My goal is to make open tools that help people make more and better open source. Atmel doesn’t project open drivers for most of thier peripherals (eg USB), open alternatives (eg LUFA for USB) grew out of the community over time. DP projects have facilitated the development of a ton of new open source, including replacements for manufacturer’s free-but-not-open stuff. Most open hardware shops use Cadsoft Eagle for PCB layout, it is also free but not open, but the hardware is still open source.

I don’t feel we are biased towards Windows, quite the opposite. I preference solutions that work under Linux whenever possible. All the tools and projects DP makes are operating system agnostic. We embrace open interface standards like CDC-serial to avoid FTDI-licensed drivers. Most of our small desktop utilities are written for GCC and compile on every operating system. Microchip now has a free cross-platform compiler and IDE for most PICs. Eagle is multi-platform, as is ISE webpack for our FPGA and CPLD demo boards. This site runs on a LAMP box. I am personally stuck on windows because of a few key tools (studio photography utilities, etc) I use in the biz that are Windows-only, but that’s the only Windows in the whole company.

A completely open toolchain would be great, however I don’t think this is the reality in any open hardware shop. Most use Eagle, it is not open source. For any type of simple programmable logic there is no open compiler or tool. When hardware is assembled the P&P software is going to be proprietary. If you want to be a purist in today’s environment things are going to be very limited.

I consider every option for each design. When there is a design that fits an AVR, I use it. When there is a design that fits ARM, I use it. However, when there is a design that fits a PIC, I will use it too. My goal is to make open source that helps make more and better open source. It won’t happen overnight, and for me, it’s ok to use some free-but-not-open tools on the way to that goal. If that doesn’t fit your needs I totally understand and respect that, my projects are probably not for you.

Exactly. You really should be using KiCad or gEDA if you care about the principles behind open-source (hardware or software). I really wish someone would push for this, especially since EAGLE is really not great software in the first place.

I’m glad to see you guys pushing Microchip on this issue though. When I first started fooling with uCs I thought PIC was the way to go since it seemed to be what all the hobby projects used at the time – built a programmer and started fooling around – and quickly realized that there were virtually no free tools at all. After poking around what was available, AVR seemed like it had the best open and free tool support, so I learned that instead. These days I see no reason to touch PIC for my projects. They’re a bit cheaper (at best I’m low volume, mostly one-off, so I don’t care), but other than that they’re pretty much the same, but with a weird architecture and no open tools, less community support. If I need a larger MCU, I’ve started fooling with ARM and the open tools look great, there are tons of parts available from different vendors with any capability I want.

ok but talking about Eagle as “not great software” and comparing it to KiCAD ?
Eagle maybe isn’t that good but KiCAD (sorry to say this) sucks for me. I tried couple of times but the usability is so low…

The workflow is weird, and it definitely takes some getting used to, but it’s really not bad at all once you understand how it works. Aside from moving between schematic capture and PCB layout I’d say it’s considerably more usable than EAGLE which has just a plain weird UI.

EAGLE has similar problems, it’s just more entrenched and accepted.

Anyway, the main point is that openness of the design tools is important as well. Software is one thing – it tends to be at least somewhat human readable, the specs are usually fairly open and well documented, so it tends to be pretty useful even if you can’t build it directly, say 20 years down the road. The same is not true of CAD and design files, they’re basically useless without the software they were created with. I’ve even encountered this, coming across a project I was interested in modifying that was done in an ancient DOS version of OrCad. Luckily it was well documented enough that I was able to redo the whole thing from scratch, but it really would have been nice to just modify the existing design.

Perhaps an industry standard open file format would be better, but I think that’s a harder sell for now than just getting the OSHW community using open tools.

Zizzle, I use Linux exclusively on my computers at home … have few XP’s inside virtualbox for few apps I need but everything else is on Linux. MPLAB-X works properly on linux (C18, C30, C32, ASM toolchains work properly) – IDE is Java (netbeans based) and compilers are native apps (32bit). They are not “open” but are free and available and work on Linux.

Everything else, I agree with you 100%, ATMEL is waaaaay more open source friendly

@arhi – thanks, good to know the tools are at least available on Linux now.

Back when I had to chose between AVR and PIC, there was only a busted SDCC port available on Linux, everything else was payware.

I have an old underpowered laptop that I used for firmware devel. I like to be able to leave it setup in the workshop connected to the target board and write the code on my PC inside the house. I can SSH in and “make run” to program a board.

I got the TI Launchpad when it was released and it too was relatively easy to get a GCC based toolchain running under Linux.

For the Renesas design comp I was lucky, DJ Delorie had done all the heavy lifting already, so once again and Linux based GCC toolchain was easily avilable.

Currently I’m battling the Freescale toolchain. I have Code Warrior installed and working under Linux, but I would ideally have a free GCC/Make based setup.

Having to have a PC with multiple GB of RAM to run a big bloated IDE, and having to hit buttons to compile and deploy ruins my productivity.

I could probably get an ARM GCC toolchain working for the K60 – but despite being called Open Source JTAG, their download environment doesn’t seem to have any free tools :(

If it is indeed based on GCC you are correct they have to release all of the source. However I find the FSF comment very distasteful. No better than one company trying to sue the other into oblivion. Exactly why I avoid GPL like the plague, I don’t need any kinds of threats hanging over my head.

In this case, I believe they comply with the GPL. I may not agree with the practice, but the reasoning is probably sound because they are a huge company and this is a well-worn complaint about their compilers.

It’s nothing with the compiler that they’re keeping locked up. You can still program on the bare metal if you’d like (and I do with some dsPIC33 stuff). It’s the arduino-ish libc that they have kept closed. That’s fully allowed.

The easy of use that the arduino has accomplished with the Atmel will in short time I believe take over microchips dominance. There is not much difference between pic, atmel, zilog, so what is happening on the ground level with hobbyists, and students will start to change this landscape.

The arduino does not offer much in way of in curcuit debugging but, then again it’s not really designed to do that? Perhaps in the future?

@arhi the main reason I think DP uses PIC is because the on-board peripherals/options like PPS (Peripheral Pin Select) just doesn’t exist in Atmel-land which would make the Bus Pirate much less useful and much harder to implement without it.

Alan, I am not sure it is PPS that is needed. Even an MSP430 can do SPI/I2C on the same pins. USI on AVR is the same thing… One wire is slow enough you can do it in software if you wish. PPS like features also exist in other uC than PIC FWIW.

Ian’s reasons for choosing to go with PIC could indeed as mentioned elsewhere have to do with supply, the debugging environment or just personal taste.

For many projects that is the feature that makes the PIC my personal preference for a project. The Bus Pirate would not be the same tool with another processor, teh PPS features of the PIC 24F and new 18FJs are one of the primary features that make them an easy choice for our simple projects.

Since we can put peripherals where we need them, routing a PCB is WAY simpler, which is a make-or-break thing on a simple 2-layer PCB. Check out the Bus Pirate routing or Logic Sniffer routing. These are super complicated boards, and the PIC connections just go straight from the nearest pin.

But any designer or engineer will evaluate all the factors you mention: supply, price, debugging variables, existing investment in the tool chain, personal preference, etc. I do AVR, MSP430, ARM, and PIC projects regularly, but for most DP “toys” PIC has been a good choice for the unique problems of producing batches of 20-500 projects.

alan, I don’t see why is PPS necessary for bus pirate. It does make things bit easier but far from “required” …

ed, pk2 is in the same pricerange (20$ is a clone locally for e.g.) and pk3 is bit more expensive (not by much), they both work on linux without a problem. pk3 don’t work with piklab yet but .. pk2 is anyhow a better device

zizzle, they ported a compilers to linux and to osx. you do not need to use ide, I write makefiles myself and use vi to write code so it’s not required to run a bloated ide.. the important part is that compiler is there and that it is native app… now, the compiler is not open nor are the libraries and that’s where mchip is not friendly with open source… they figured out too many ppl with brain don’t use widows so they put in some effort to compile those compilers for osx and linux and that’s the first smart move I seen mchip did since publishing source for pk2 hardware and firmware.

You just go to their web site to download the scripts and then run them. Pretty easy I would say, for some “special” software, you have to go this way anyway. Easier than make/make install but a little more work than sudo apt-get install …

As a mere hobbyist I had to decide which microcontroller ecosystem to invest in back in 2008. The last time I had done any significant “electronics” I was 10 years old and using a large wooden breadboards discrete transistors and 20% tolerance carbon resistors.

Microchip and PICs won every category by a country mile. Decision made, and several years later I have not regretted it.

Having addressed the comments, and dragging it back to the topic at hand, I think it became clear shortly after the Uno32 and Max32 were launched that both Microchip and Digilent had significantly underestimated the amount of time and effort required to implement the Arduino-compatible vision. And don’t forget that Arduino, and all is achievements, were not an overnight phenomenon. It has taken 6 years of effort by a large number of individuals.

Whether the original chipKIT vision is ultimately achieved, only the time and effort of a large number of individuals — not just Microchip and Digilent — will tell.

“We urged Digilent to adopt the open source JTR-Honken USB stack and help us build a top-notch community driver without restrictions.”

Sorry guys, but using CC-BY 3.0 as license for USB stack [0] is restriction. CC licenses are not made for software [1], not GPL compatible [2] and not OSI approved [3] (and never will be). Basically, license for JTR-Honken USB stack is not “open source” by OSI definition and also nobody can include it in GPL software. Ironically, if you write GPL application (and not only GPL) for PIC, Microchip stack is better choice then JTR-Honken “open source” USB stack.

If you really need attribution, there are GPL compatible attribution licenses [2 again, read third reason].

My wild guess is that only reason for using CC-BY license for software is self-marketing, you want that everybody who uses your software links to your pages. You can’t enforce that with any OSI or FSF approved open sources licenses. Only attribution you can get is copyright notice like a “(c) 2011 Dangerous Prototypes”. Is that enough?

I agree on whole Microchip situation. However, using not FSF or OSI approved software license (CC-BY in this case) for most of the projects, call those project “open source” wrongly, and then criticize Microchip for not releasing open source drivers makes no sense at all.

In the forum we came to understand that CC-BY was GPL compatible, without adding the copy-left aspect. If that is wrong I would certainly want to update the license, except it isn’t up to me.

There is no self-marketing involved. This stack came from community members, and it is they who are attributed on the stack. Dangerous Prototypes is NEVER mentioned anywhere in the source or attributions.

If CC-BY or CC-BY-SA are not open source it is big news to me. Tell me what I need to do to be open source kosher and I’ll do it. It is my fault for being ignorant, but it is not with the intent to skirt re-distribution of my work. Basically, I just do what adafruit does, and they have traditionally used CC-BY-SA on a things I’ve seem.

And I want to be clear. I am not criticizing Microchip for not releasing OSI approved open source drivers. I think it is tacky that they are marketing themselves as open source, but continue to restrict distribution of key source code.

FSF says that CC-BY is not GPL compatible when used for software [0]. At least version 2.0. Like I said in my post above, Creative Commons says that CC licenses are not recommended for software and not GPL compatible [link 1 above].
In order for software to be “open source”, OSI approved license must be used. CC-BY is not one of those licenses.

Licence choice can be hard sometimes and depends on application. It requires research and sometimes is confusing. Embedded software makes it even harder.
In case of USB stack MIT license is maybe best choice. Your copyright stays in the code and everybody can use it, change it, port it… License is also very short and clear [1]. But, that’s only my opinion. It’s up to code authors.

You will need to use different licenses for different parts of your shared works:
For the software/firmware use : MIT/BSD/GPL/LGPL
For the Hardware you need an OSHW compliant license here’s some hints http://blog.wickeddevice.com/?p=253 (CERN/TAPR) the jury may still be out
For things like Artwork/copy and even docs etc then maybe consider CC type licenses.

You will not find a single license that covers all bases unfortunately

Isn’t the OSHW the hardware equivalent to OSI?
In which case no the hardware license will not be applicable/compliant to/with OSI
You can protect your design documents; schematics,pcb etc with a regular OSI license as these are copyrightable.

>> In order for software to be “open source”, OSI approved license must be used.

um. Bullcrap. I hope. I sorta figured this would devolve into “such and such open source license isn’t good enough.” Is the Microchip license even that bad? (OK, I’ll go back and read the whole thread more carefully.) Compare to Atmel’s license for the QTouch library, for which source is not available at all…

My main concern for open source has always been “can it be reused with only the permissions enumerated in the license”. If so, it is open to me. I like to make things and write about them, the license is just a formality. In the same sense, I don’t mind changing if there is something I could do better.

I can’t figure where the other mcu manufacturer’s are better or worse. The AVR eco-system is the most open, but that is due to the community and not Atmel. A lot of the AVR goodies that come with source code are community driven, AVR-uiP, LUFA and V-USB etc.

I know that Maxim, ST & TI also passes me through some agreements before allowing me to download software in whatever form. Microchip’s application libraries are not bug free, and in constant evolution. They allow you the source code, you can correct their bugs you find in your project. Presumably you can submit a ticket relating to the bug and fix. The idea of them controlling the distribution of the library is not bad (the utterly stupid legalise re inspecting licensee premises not withstanding), it is more inconvienient to open source distribution model.

Again, I can’t figure out is Microchip are worse than any other mcu manufacturer. Some of the other players are actually using 3rd party libraries, so I can’t credit them and feel it is unfair to discredit Microchip.

Messing around with the arduino open source movement (as per editorial) though is what tarnishes Microchip.

AVR community is driving more projects because ATMEL is “open” to “open source” hence the community is large and supportive. MCHIP is not open to open source hence where there is a community it constantly fights with it. Simple example is tear-down notice you receive from MCHIP if you host usb portion of MAL with your source. It’s one to say “we do not support, do on your own risk etc etc”, the other is to sue you for doing so..

As for other’s TI, at least for msp430 series has an open source gcc out there, but they also have a CC based on Eclipse that should have bin open but it is not. For arm there are open source tools too and at least ST provides libraries in source for their devices. We can’t discuss IAR or KEIL as they are software houses, not comparable ..

Anyhow the problem with Microchip is that “they are close” but have some management decisions that are just plain wrong IMO. They have MAL that is btw GREAT, it is less buggy then many app libraries I tried from different sources, they allow you to use MAL in your project, but they don’t allow open source project to host a piece of MAL they use. It’s managerial decision that does not make any sense.

Wrt compiler itself, I don’t necessary require all tools to be open, MPLAB.X when it is out of beta stage will be good enough for me (work on both linux and osx, there is cli version of compiler ..).. I don’t think they should limit the compilers to not have optimization options but wth maybe they make money out it .. it is stupid imho as you can’t use mchip c compiler to compile for other devices so better your tools are bigger chance you will have to sell hw.. It’s just that I really think they should support Fedora, Debian and Ubuntu packaging system so that you can yum and apt-get packages to your system without going trough long installation process. Anyhow I see serious improvements in MPLABX in past few versions so cudoes on that

I read now that MCHIP didn’t invest nothing into this chipkit project; now that’s just embarrassing imho….

Anyhow, it’s decisions like that is what makes me want to completely discard all my mchip tools and move away from it for good. Look at PK3, pk2 was open, fast and still works like a charm, pk3 is slow piece of crap that bugs 10-20 times per day… someone decided to “keep this one closed”, I’m sure that if they’d opened it they’d solve all the bugs long time ago …

>> ATMEL is “open” to “open source” hence the community is large and supportive. MCHIP is not open to open source hence where there is a community it constantly fights with it.
And yet the firmware for things like the ICD2 and picKit2 is available enough that clones abound, and microchip has published their [url=http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf]On-Chip Debugger Specification[/url] while Atmel’s debugging is still a dark mystery requiring their hardware between you and any OS debugger. Hmm.

The contributions of chip manufacturers to “Open Source” are not very transparent. Is this sort of thing tracked anywhere? Can I find out how much Atmel (or anyone) spent on OS development? How many patches they submitted? How many people they have helping? Which software they’ve published with which licenses and how much enforcement? What about the various ARM vendors? Who’s helping and who is just riding the coattails of everyone else? MIPS? (ChipKit isn’t even using the same compiler that microchip ships, is it? It’s using the “fully open source” m4k gcc support (mplabc32 (from the mplab10 beta) is gcc 3.4.4, while the chipkit’s compiler is 4.5.1)

I’m not convinced that MAL is any worse than LGPL’s requirement that non-open-source software be available in a form that allows re-linking with a newer version of the covered library. Except that Microchip seems to be enforcing their license more carefully. newlib apparently has a mix of licenses (and 36 different copyrights!); I’m sure it will make someone unhappy…

(While I’m being snarky, I should point out that the TCP stack used by the real Arduino Internet stack isn’t open, either. Or compilable, or even visible. Found a bug? Wait for new hardware!)

What makes PICs hard to work with for me is that mcirochip is pedantic about distributing the header files. This results in confusing “howtos” on the internet that explain how I have to download the microchip-compiler-for-windows extract the headers and install them somehow. However, when I tried that, both the microchip and the compiler had moved on to newer versions. Things were sufficiently different that I had to invest “brain-time” to get it to work.

I was at a friend yesterday. He didn’t have any AVR tools installed, but we were going to work on an AVR project….

Clarification, Microchip did not invest in the IDE. The mulitplatform changes were a project by Mark, and me to allow the Arduino IDE to support multiple toolchains. My test version has the hooks for several toolchains, and I’m trying to solve the delivery of toolchains, and conform to a spec that is hosted on the Arduino site. There is nothing closed sourced, about this and the plan is to incorporate into Arduino IDE when possible.

Microchip invested in an Open Source version of their toolchain, If the toolhain is not fully open there is a mistake on their part that needs to be corrected. They were looking into using newlib. They should hurry up and do that.

I do believe the goal of multiplatform Arduino is important. People should be able to learn about a chip on various platforms using Arduino libraries, and then dig deeper into it the chip when they want capabilities not available.

I could do a build that uses the Pinguino as long as the libraries compile, and if someone is willing to help fix them if their are bugs. I can help get the platforms.txt file updates, and the compiler dropped into the hardware folder and working.

We were not paid, we want Arduino to be multiplatform, and continue to be completely open.

I have put an enormous amount of personal time, and my own money into making the multiplatform changes. I spent the last weekend at Heatsync labs hacking on how to make the multiplatform version available as downloadable toolchains into the runtime version of the applicaiton. Each tool chain would be maintained by the a group willing to build and maintain the toolchain, and the Arduino core libraries. These would be packaged for download by that maintainer. If anyone is interested they can fork my platform branch at http://github.com/ricklon/arduino, and we can work on it together. There’s plenty to do.

Get rid of them. I’ve used PIC extensively in real products, and lately it’s just a big steaming pile of garbage. Bugs in the devices, compilers, IDE, documents, programming tools. Lousy slow support from people you can’t understand, no local support even after repeated phone calls.

I know every company will have some of these, but I won’t put up with all of them on the same project.

Well, I guess that puts to rest the nagging suspicion I had that this blog was secretly run by Microchip. Not that there would be anything wrong with that, but disclosure would’ve been nice had it been the case.

We developed some stuff years ago for PIC. Then we wanted a “softcore” in an FPGA. Turns out we had to use an Atmel AVR softcore. I hate having to maintain my knowledge of two different systems but alas we couldn’t find an open PIC softcore.

After we installed the AVR toolchain we immediately noticed the difference. A lot more userfriendly. Back then it wasn’t yet as easy as it is now: “apt-get install avr-gcc”, but still WAY easier and easier-to-use than the PIC development environment.

So we decided to move over to AVR, also for the “hardcores”….

Fast forward a few years. I hear GCC is available for dsPIC. I buy a dsPIC board, and when they arrive I try to install the development enviroment. Easy, right? No.

Stupid things like “howtos” that reference older versions of compilers, patches that are incompatible. etc etc. Took me hours.

I’ve given up on Microchip. I gave them a second chance, they blew it.

This is exactly why I haven’t supported the Open Hardware Initiative. It gives big companies like Microchip to manufacture and sell whatever open hardware releases they want, and even explicitly prohibits the hardware creators from requiring any compensation or contribution requirements. What were the OSI people expecting?

If I understand correctly Microchip should do the following:
Complete the upgrade of their compiler to use Newlib
Core support for the their chips like pic24, pic18 by having a a similar open Source g++ compiler
Open the USB, Ethernet portions of the MAL or make an Open Source version available
Invest in the Arduino IDE

Should other chip manufactures for like TI do the same thing?

We could send a public letter/message to them or all the chip manufactures.

All that is a great wish-list. All I personally feel they _should_ do is follow up on their own marketing hype and support their open source initiative with the bare minimum open source drivers to make it usable.

Attm the major pita with mchip is MAL and all they really need to do is change the licence, nothing else.

Wrt making the compilers open, supporting cores properly and investing in arduino ide those really depends on the investment and current return on the compiler sales they have. I do believe that any mcu manufacturer should have it’s c/c++ compiler fully open and that by doing so they will help themselves but I understand the software business and free (as it is now) is “good enough”. As Ian said, Eagle is not open but is de-facto standard in the open source community. KiCad is open source but not nearly used as much as Eagle.

So major reason mchip is unfriendly to open source is MAL licences. With that alone sorted out they’d move from being against open source to pro open source. Now, doing all other stuff (100% open c/c++ compiler etc etc) would make them even more open source friendly, but changing a single licence file would move them from one side of the fence to the other one, and that is the simplest and easiest move they could to “tomorrow”. It’s just “decision”, no real work required. (actually it would reduce work required as they would not need to scan internet for open source projects using MAL and sending them the teardown notices)

When companies like Sparkfun who seemed to tout the PIC16F88 etc for most things they made seemed to drop them for ATMega 328s’ overnight, Microchip should be worried.

I’ve been a PIC fan for many many years, but I love that I can use the tools I use everyday at work (make, gcc, gdb, etc) with the AVR, MSP and ARM toolchains. I’ve never found an easy way with PIC. I played with HiTech compiler and it mostly worked ok, but having to jump through hoops is a nightmare. Let alone the fact that I can’t use my ICD2 with Linux (which it still seems even the ICD3 isn’t fully supported yet). I don’t want to buy a PICKit2/3 when I already have an ICD.

MPLAB was great in it’s day, and MPLABX looks good too, but I use vim and a shell and I feel much more productive in *my* environment which other vendors seem to respect and support, yet Microchip however does not.

My only major gripe with Atmel is the cost of their programmers/debuggers and the lack of cool peripherals in their devices. The JTAG mkII in Australia is ridiculously expensive for what it is.

But again, they’re all just tools and they all have their flaws and strengths. Unfortunately for Microchip I no longer want to maintain a “Windows” virtual machine just so I can use their parts any more (yeah MPLABX fixes that, but I’ll believe it when I see my ICD2/3 supported fully).

I was first exposed to microchip in the late 90s. The first chip I used was the eprom based pic16c74a. Microchip has come a long way since then. I absolutely love the 16-bit PIC24/dsPIC33 architectures as well as the PIC32 chip. I think the MIPS M4K core (and in the future the M14K) is a very viable competitor to the ARM Cortex M3/M0 Processors and will have staying power. Microchip offer better datasheets and appnotes and a better customer experience overall than most MCU suppliers. Furthermore I like the Microchip model of being able to purchase silicon and low cost dev tools (PICkit3) and download free (even if they are closed) IDE and Toolchains from the same supplier. I prefer this model to the ARM Model where you have to choose a silicon supplier and a tool supplier.

I love Atmel’s ATMega and ATTiny micros but prefer the 16/32-bit products frpm Microchip over the XMEGAs and AVR32s.

Having said all that I always wondered why Microchip do not just make all of their compilers opensource, especially those that are GCC based and are meant to be open. They can’t possibly be making that much money of selling compilers. They charge a one time $900 fee for their commercial compilers and most people just use the lite editions of the compilers which have some optimizations turned of but are otherwise fully functional. This issue with the ChipKit libraries isn’t making things any better.

Pinguino32X IDE uses its own version of GCC compiler. We built the compiler from source and compiled Newlib to be used on PIC32. Pinguino 8 bits and 32 bits board are Microchip based, and we must admit we received help from Microchip every time we asked for.
At the beginning of this project in 2008, they gave us a sub license to use their Vendor ID and we received our own Product ID. Some header files were licensed to the Pinguino project by Microchip without any contribution. Even SDCC compiler for the 8 bits PIC uses Microchip header files, Microchip just asked to put the files in a non-free folder.
There is no interest between Microchip and the Pinguino project, and our goal is to make available this IDE as an Open Source tool. USB stack and TCP-IP stack are licensed by Microchip to be used only on their chips. For some instructions, Pinguino embed the libraries as object files, this is maybe a good solution to agree with the license which say that the library is ‘for use solely and exclusively on Microchip PIC Microcontroller products’.
And of course, the source are available on the Microchip website.

Hey Everyone: We’ve been reading the blogs and comments, and do agree with you. Though we are a corporation, with a lot of suits (not really, actually I think we have a policy against suits), we know the community has been and still is a large part of why Microchip is successful today. We put our best code forward, but we know it has usage limitations. Clearly this is an area where we can do better. The many points made in the blogs were taken to heart. So, we set up a meeting with our management team yesterday, and both our CEO and COO joined us because they too think this is important. Really, we weren’t just playing Frisbee golf as you might have thought. We understand why you guys are upset and this is an issue we need to address. Bottom line, we can’t release our existing stacks because we have contractual obligations to many of our customers that prevent us from making them open source.

So how about this: We offer a prize for anyone who writes these stacks for the community. To get started, the two that we want to target are the TCP/IP and USB stacks. Heck, who better to write these than the experts in the community? The goal is that the entries would be compatible with the chipKit MAX32 (PIC32MX795F512L). Digilent Inc. will help us decide which stack first meets the requirements. For our part, we will pony up the prize and provide technical support for those who want to get involved.

Thanks to everyone who posted and I’ll follow up with additional details shortly.

Now this is the reply I really didn’t expect. For the closed source stuff I completely understand why it can’t be made open; I too have bunch of code that I’d like to push to open source or even public domain but some parts of that code can’t now (nor maybe ever) be open due to different restrictions; what I don’t get is problem with opening MAL’s licence. It is already free, the source is visible, licence allows you to use it in all kind of projects – they only real limitation is that you cannot host that part of source with your open source project… (other limitations like “must be used with microchip devices” etc are really irrelevant, not that I could use most of MAL on the other mcu anyhow). MAL really looks like only a licence issue, nothing else. But I might be missing something there ..

I really do like the

For our part, we will pony up the prize and provide technical support for those who want to get involved.

. DP already have a working USB stack that is 100% open source. It’s not full stack (cdc only for now) but with some help can grow.

The chipKIT group is doing great stuff, it’s awesome to hear about this new development! The prize sounds like a great idea, Dangerous Prototypes will add a $100 cash bounty for each of Digilent’s selected stacks.

Can you please give an example, in the most general and vague sense, how Microchip gave up the right to dual license their own IP? I understand if you licensed code from elsewhere and were bound to a license, but I assume Microchip actually owns the stacks. I’m trying to think of what type of contract with a Microchip customer would motivate that.

“””Bottom line, we can’t release our existing stacks because we have contractual obligations to many of our customers that prevent us from making them open source.””” makes absolutely no sense for me either.

“””Suffice to say that there are agreements in place that have a direct bearing on these stacks and I don’t believe I could discuss the terms of those agreements here.”””

And those bearings really say that Microchip is not allowed to dual licence those stacks? Utterly weird.

Although from the outside it seems as if Microchip owns the rights to the stacks, apparently they hired an outside entity to make the stacks. This entity apparently retained the copyright, and objects to making it open source.

@Rogier – That I could understand, but it was customer licenses specifically. It doesn’t matter to me either way, but if I write or talk about this I want to give realistic and concrete examples. As many have noted here, this just sounds weird, which is why I asked for clarification. I’m not gonna push it :) “Licensing issues” it is.

I’ll throw in a from-scratch USB stack into the mix that supports host and device modes… I’ve used it to talk to USB flash drives in host mode (with a filesystem on top of an upper level SCSI driver), as well as in device mode as both HID and CDC/ACM serial port functions, so it’s a decent start with all the low-level plumbing. It needs more work to become truly general purpose, though. It is very lightweight (even allowing us to put it in bootflash on a PIC32). If there are folks who are interested in adding upper level drivers to it, check out the sources.zip at the bottom of this page: http://www.cpustick.com/downloads.htm

Marc,
Good job in getting this under the attention at Microchip. For me the most important issue is the development tools. Not the (usb/tcp) stacks.

When I want to develop under Linux, I end up having to download this, grab headers from there, install another package, compile suchandsuch.

The core reason for this is that Microchip doesn’t allow free distribution of the headers.

I understand that it’s difficult to let distribution-control out of your hands. But with Linux we have the “keep things up-to-date” reasonably sorted.

So to gain back my support what you need to get working is the following:

To start development for my pic I get the commandline tools with:

apt-get install [the compiler] [the programmer]

Now I understand that you cannot retroactively manage to get the compiler included into ubuntu-natty, as that has already been released and frozen. And it’s too late for 11.10. So to get this working on short order, I’ll have to add a PPA.

Sure mplab is a free download at microchip.com, but the hassle of doing that outside my OSes package management is too much. If it fits in the package management the dependencies are taken care of. It’ll go along with upgrades etc etc.

Certainly providing the development tools as .deb or .rpm packages would be great, but I think there are good arguments for not installing whatever happens to be included with your distro at the time.

Much better to pick a known tested vendor release for your development, rather than have a tools upgrade potentially slide in unnoticed half way through your project.

Is a common concern for AVR folks where all the tools are in the distro’s – they’re usually too old / too new / buggy / unpatched when compared to the current ‘official’ release. (In quotes because, until recently, the only official releases from Atmel were for the Windows platform. But there were equivalent packages and build scripts for other OS).

I have zero interest in microchip tools being in any default repository for distro of my choice (Fedora in my case). I would prefer to add microchip’s repository and upgrade tools using yum but only from separate “disabled by default” repository. Having this tools in the main repo would not in any way be a big plus.

As for the current installer for mplabx and compilers, I agree it’s not perfect but compared to windows only this is a huge step forward and I applaud Microchip for the move. I also love the choice they made by going with netbeans (I’m not a big fan of eclipse everyone else uses), so I’d say we are nitpicking with regards to mplabx. It is still beta and already works like a charm, there’s definete and visible improvement version trough version. Yes the yum would be nicer, yes the self upgrade would be cool, yes having pickit2/3 work with 64bit jvm would be even cooler … but cmon, it works natively on linux, fast, it looks good.. still some features missing (emulators…pk2 broken in last version somehow…) .. I put my hat down on the work there.. Yes it would be cool if C18/C30/C32/C++32 are open source but honestly, I don’t really need them to be as long as they are free and as long as they work ok and nativly on linux and kmek too.

Wrt atmel tools being in the main repo – I have 2 times already issues with that when I upgraded (naivly) my distro in the middle of some project and my atmel project would not work any more .. compiler bug .. detecting what happened took almost a week of my time ..

Thanks for the feedback. I talked with our tools guys and here is there reply.

We agree. We only recently started providing tools for Linux and Mac. They do plan to make .RPM and .DEB and certainly do not object to them being added to appropriate repositories as they become available. Apparently, we’re a few months away on that.

It turns out that not all Linux distros use these formats for package management.

For the moment, we are providing a binary installer that can work on any Linux distro (helpful for those of us who like Slackware, Arch and Gentoo;)). Of course, you are correct, to upgrade you need to download the new version and re-run the installer.

I don’t understand why I got a “new comment” message in my mailbox just now, as everything seems to be older than 2013.

Anyway, rereading your message: You are suggesting that microchip would provide RPM and DEB packages. This is a “losing battle”: As there are many different distributions and combinations of available libraries, you’ll have to update those for different distributions all the time. This costs a lot of effort on the part of microchip.

What does work is to make things open source enough that debian, ubuntu, fedora and arch can all package a working compiler and supporting tools. Then you’ll find that soon enough, they will start carrying support for your chips. Some arch-fan will step in and package it for arch. Some ubuntu-fan will do the same for ubuntu etc etc.

Thanks for all of the positive feedback on this. I’ve been spending the day going back and forth over some of the logistics of the competition (want to keep it fair and all) but have some preliminary news for you. Prizes look like they’ll be around $1000 for each stack developed/ported and that’s in your pocket. We’ll gross up the amount to cover the taxes. I spoke with our Development Tools team and they have 10 chipKIT MAX32 boards and Network Shields that they’ll donate to the first 10 people to sign up. Once all of the T’s are crossed and I’s dotted on the rules and regs, I’ll post them on a “contest” site along with the email address to get the free boards. I’m really excited about this and anxious to see the entries!

Ian, thanks so much for offering the additional $100 that’s fantastic! wrt “Can you please give an example, in the most general and vague sense, how Microchip gave up the right to dual license their own IP? I understand if you licensed code from elsewhere and were bound to a license, but I assume Microchip actually owns the stacks. I’m trying to think of what type of contract with a Microchip customer would motivate that.”

I’m the Academic Program guy so I’m not privy to such information and it wasn’t really discussed in any detail at our meeting. The focus of our meeting was on how to enable the open source community with stacks that run on Microchip products and how we can help there. Suffice to say that there are agreements in place that have a direct bearing on these stacks and I don’t believe I could discuss the terms of those agreements here.

That is amazing, it’s great to see Microchip is getting behind a solution to the problem. I’ve also had a few emails from other donors who want to contribute to a bounty. We’re checking to see if there is an online escrow service we can use to pool the private bounties. Has anyone asked Digilent to be involved?

Both projects are huge, especially the TCPIP stack. If some demos (http server, ftp, etc) and documentation are involved it’s a labor of love. If things are still in flux, please pitch this as a long term investment in the educational (and to lesser extent open hardware) markets.

A $1000 prize is a great incentive, and I won’t knock it, but it pales in comparison to marketing expenses. A quarter page ad in make is $2000, a half-page is $6K. Maker Faire entry fee is 5K-15K+ plus expenses.

This isn’t just a core part of chipKIT, but your whole product line. A share-able USB and TCPIP stack will get your products out there and in the hands of students, engineers, and hobbyists in a way that advertising can’t.

No worries about the license, I totally understand. I’ll just refer to it as “license issues”.

Thanks and understood. During normal business conditions, we could have provided more of a reward. Unfortunately, we’re in a down cycle along with most companies in this industry. Just look at TI’s announcement this week. In times like these, we pull back all advertising and marketing expenditures (our advertisers hate us right now). The reason for this is so we don’t pull resources away from manufacturing product and to avoid layoffs. This allows us to continue to provide product and support to customers during these times so we don’t have to play catch-up in up cycles.

No worries. I’m enjoying the opportunity to clarify some things that I know seem strange from the outside. We try and control spending on the overall market sense of where the industry looks like it is moving in a cycle and are admittedly very conservative so we can keep our fundamentals of customer service in tact as I mentioned above….we may not always be right because we are looking forward in a crystal ball :) and do not base spending on past performance…

This ‘Earnings Call Transcript’ makes an interresting read. At least the future in Microchip’s COO Ganesh Moorthy’s crystal ball does look quite well: “We expect the 32-bit business to grow in the September quarter and achieve another record.” ;)

How about you make it the best first 10 possibilities to sign-up. Otherwise anyone and everyone who simply wants a “couple of free boards” will jump on the bandwagon and the result is no one will get much value in the long run. There is also the issue of different time zones too. You make this a first in best dressed affair you lose access to the talent who may be in the land of nod at the time.

Ok…the contest page is finally up at http://www.microchip.com/stacks/. The submission email address is ChipKit.Contest@microchip.com. If you have any difficulties whatsoever, just post here and I’ll keep an eye on the blog. As for the 10 kits we have to give away, I kind of like the idea that the first 10 submissions will each get a kit. If anyone has any objections to this we can certainly modify this requirement based on suggestions. Nothing’s set in stone for that portion of the contest. Anyhoo…good luck!!

The biggest problem with open source and the microchip stack is the same problem with microchip and the usb stack. The code works and its supported. I spent years (like 3+) trying to get lufa to do make the avr usb chips make themselves worth what they should have been and all the while (choose your epic gnashing of teeth, rending of hair tearing of flesh and clothes imagry ) failing . I found the low end usb pics and the corresponding microchip software stacks not only worked but worked cross platform. Oh and did midi as a standard part of the codebase! If you are gonna get down on microchip and mpide then do them for the fact that all of this stuff is licensed through Microchip (BARBADOS).

Happy new year to you and Cameron and everyone at Suspect Devices too! Thanks for the heads up on LUFA, many times I contemplated how jealous I am of that stack, though I have minimal experience with it. Not time to jump ship yet I guess.

What happened with microchip’s contest as there is no page http://www.microchip.com/stacks/ ?
It was a success, or it ended silently as there were no solutions?
A least, the open-source c32 compiler is there and newlib powered…
But, too bad that C18 is declared legacy after such a success on porting it to linux and osx. It can’t be replaced by that silly xc8 compiler. Anyway, it does not matter for me anymore because of two main reasons:

1. JALv2 compiler with jallib library covers all pic12f/pic16f/pic18f microcontrollers with an incredible small code size generation – much over any free C compiler and even better than some commercial solutions.

2. I’m enjoying ATmega and ATtiny microcontrollers from some time and I am amazed – this is the main effect of trying to provide a PIC18F arduino like board (freeJALduino) :( (maybe this is why it seems to me that Microchip is giving up?)

The contest wasn’t a success at all. We didn’t get any submissions. We haven’t given up by any means. We’re still working on different ways to meet the needs of this community and provide a Microchip-based Arduino solution to customers who’d like one. So we’re working with a number of Third Parties to help get some open source stacks developed and there’s been some really nice progress that will hopefully come out soon. Digilent did a ton of work to provide a completely open-source version of MPIDE by (as you mention) removing dependencies on plib (contains third party IP that couldn’t be made open source) and instead use newlib. For those interested, plib is still available as an option in MPIDE just because its a pretty nice library that some folks may want to use in the future or have used on previous sketches.

I’m more than happy to answer any questions on any of this so that we can reduce conjecture and make sure everyone has the facts. So feel free to email me with your questions, comments or suggestions if you want. If I can’t answer your question, I’ll find someone who can.

“As for the JALv2 and Jallib, I’m not familiar with the project but I did ask around and anyone I spoke to said it sounded like a cool project so definitely not a foe.”

I thought definitely Microchip is aware of this project and personally I thought it is in their interest to make some waves as it is much more over the XC8 lite (and the legacy mplab c18) and a very easy language to learn. – could do more than Wiring language.

As for Micromite project (a Maximite down to the microcontroller level) we are eager to see what Microchip have in it’s bags for us.
Thank you for the answer!

There still doesn’t appear to be an open-source USB host stack for PIC, though. And there don’t seem to be a lot of open-source options for host stacks on any microcontroller. LUFA on AVR probably comes closest, but it doesn’t support hubs.

BTW, I was very amused to read all the comments saying “I hope Microchip doesn’t buy Atmel.” :)

And I noticed that it said the software can only be distributed “when the Software is embedded on a Microchip Product that is integrated into Licensee Product.” It sounds like that would rule out firmware upgrades in the field. Is that true?