Their real innovation was social. They built a community around the thing and provided documentation that wasn't addressed to EEs.
I'm so glad they didn't choose the PIC.
Their real innovation was social. They built a community around the thing and provided documentation that wasn't addressed to EEs.
I'm so glad they didn't choose the PIC.
From back when I was working on AVRs at university (2003-2004), I remember there were a ton of programming settings to choose from, different ways to program it (SPI, parallel), and you could easily screw up something if you set the wrong fuses, used the wrong oscillator frequency etc. All of this complexity was taken away by Wiring / Arduino, so you could focus on your project without digging through datasheets.
So the simplified IDE and social aspect was only part of the story.
Disclaimer: I'm a long time PIC user, going all the way back to the PIC16C84. Long before anything like Arduino came out, I always found Microchip's documentation to be much easier to crack. Of course, I admit to a certain amount of mental inertia and familiarity with the platform as well.
The PIC16 at the time at least definitely didn't have GCC support, I recall having to boot Windows to compile my code for it. Pretty sure that's still the case.
The 16- and 32-bit chips are more mainstream, and after using their proprietary compiler for a while, they switched over to GCC. Now from my standpoint, it's still "their" GCC, in that I download and use their tools. And there are some features that you still have to pay for such as optimization. I'm certainly not in love with those aspects, but it's good enough for me to wait it out until something else comes along that's compelling enough for me to switch. Folks have demonstrated building their own GCC toolchain for PIC, but I haven't bothered.
Somebody without my mental inertia and legacy projects might make a different choice.
My uses aren't critical enough to require considering the smallest, cheapest parts, so I simply avoid the 8-bit chips.