go to hack-a-day, then. what percent of pic projects do you see vs arduino?
I can buy preprogrammed chips from MicrochipDirect for a few pennies more. AFAIK no other MCU manufacturer does this, at least for small (<1000) qtys, or as easily. Even if all that gets preprogrammed is a bootloader, this can save a lot of time and hassle in production.
IIRC Digikey can do this for most of the atmels they have in stock, at no expense in basically any quantity (but I haven't tried it yet).
go to hack-a-day, then. what percent of pic projects do you see vs arduino?
hackaday has a total hard-on for arduino / attiny85 (even when used completely inappropriately), 3D printers, and quad/hexrotors aka "drones" - anything in the world involving one will probably end up there even if it isn't deserving of a second pair of eyes ever looking at it.
This letter was written back in 2011!!! And it is about the old (outdated) MPLAB IDE. The main IDE now is MPLAB X and because it's based on Netbeans it is supported on Linux too. And it is MUCH better than the old MPLAB IMHO. Although there are still some folks out there who claim the IDE is awful, i have to say that my experience with it is VERY positive. Lately i'm doing some work with Keil, and it crashed on me twice, without any warning! One of the crashes corrupted my project file, so i had to start over by creating a new project! Never had that experience with the MPLAB X.
Microchip offers FREE editions of their compilers for all their families, and XC8 has become better since version 1.21.
And if you want you can still use the legacy HI-TECH C compiler for the 8 bits in MPLAB X in lite mode. And PIC18 + XC8 free or HI-TECH C lite will OUTPERFORM the Arduino anyday, so it is your loss for not using the PIC.
As for the demise of the 8-bitters, it will happen, but only for more complicated projects. Currently i'm working on 2 projects that are so trivial, (simple user interfaces) even the PIC16 series is overkill. I think that the 8-bitters will continue to hold this (low end) market for the years to come.
hackaday has a total hard-on for arduino...
In Atmel world this buys you an AVR dragon
As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern.
significantly worse than the C18 compiler
the XC16 or XC32 compilers
PK2 can also be used as a AVR programmer using avr-dude
do you have any links to the info on this?
Quotedo you have any links to the info on this?
It is truly experimental, and I think the efforts stop'd maybe 5 - 7 years ago.
8bit mcus are pretty much at no growth but not loosing shares, 16 bits are declining and 32 bits are climbing (mobile stuff of course)
is it true that they do insert no-ops to cripple the free versions?
what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.
again, my only source was from gerry's write-up on MC's compiler tools and his implication, as I read it, was that the free tools had the no-ops inserted on purpose, to 'motivate' you to buy the paid-for tools.
is this true or not?
I really hope its not actually true, as stated. it seems quite hostile for a company to do this.
story: I worked at DEC many years ago and I did hear the story about how we made 2 VAX systems (I forget if it was the 750 or 780 series) and we would allow customers to upgrade from one to the other by paying the upgrade fee. it turns out that there was no actual hardware change but we'd dispatch field service (we jokingly called them 'field circus') to swap out the color of the metal skins and do a microcode upgrade. the microcode - you guessed it - had the no-ops removed and so the end effect was that the VAX ran almost twice as fast with that 'upgrade'. the metal skin color change was just 'marketing' and to let the customer think something real had been changed. this angered a lot of people and I've heard the story told by many old DEC guys, so I do believe it was true. the MCP thing makes me think of this shenanigan; and it was unacceptable back then and still is, now.
so, is this on purpose or just sloppiness?
what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.
my only source was from gerry's write-up...
what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.
again, my only source was from gerry's write-up on MC's compiler tools and his implication, as I read it, was that the free tools had the no-ops inserted on purpose, to 'motivate' you to buy the paid-for tools.
is this true or not?
I really hope its not actually true, as stated. it seems quite hostile for a company to do this.
story: I worked at DEC many years ago and I did hear the story about how we made 2 VAX systems (I forget if it was the 750 or 780 series) and we would allow customers to upgrade from one to the other by paying the upgrade fee. it turns out that there was no actual hardware change but we'd dispatch field service (we jokingly called them 'field circus') to swap out the color of the metal skins and do a microcode upgrade. the microcode - you guessed it - had the no-ops removed and so the end effect was that the VAX ran almost twice as fast with that 'upgrade'. the metal skin color change was just 'marketing' and to let the customer think something real had been changed. this angered a lot of people and I've heard the story told by many old DEC guys, so I do believe it was true. the MCP thing makes me think of this shenanigan; and it was unacceptable back then and still is, now.
so, is this on purpose or just sloppiness?
But when 16 & 32 bit parts are cheaper, who cares?
8 bit still has some important advantages. Power consumption for many tasks is lower, performance for some tasks is better (especially low latency stuff, interrupt handling etc.)
Quotemy only source was from gerry's write-up...
Simple common sense dictates that unless this "gerry" was intimately involved in the development / decision making of this compiler, what he said is inconclusive at best.
is this true or not?
I really hope its not actually true, as stated. it seems quite hostile for a company to do this.
This "Gerry" is btw this blogpost: http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/
His opinions, and I guess others have similar after struggling with useless compilers.
Useless in the way that an compiler fills the resulting code with instructions that does not belong there, just to fill up already tight memoryspace, if you pay $999 you get an option that does not add that code.
it seems like microchip is removing parts if this "extracode"/fillercode..
And if you want you can still use the legacy HI-TECH C compiler for the 8 bits in MPLAB X in lite mode. And PIC18 + XC8 free or HI-TECH C lite will OUTPERFORM the Arduino anyday, so it is your loss for not using the PIC.
It will probably outperform programs written using the Arduino runtime. That's horribly slow, where I recall a simple digitalWrite action can take up to tens of microseconds.
As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern. Only 1 accumulator register, banked memory, Fosc/4 clock speed, etc. But it works.
There is a reason it still uses HI-TECH compiler. Microchip failed themselves to make a decent one, and therefore bought out HI-TECH. They made attempts to port it to GCC or LLVM, but that failed too, as the architecture was so odd it couldn't made to fit with modern compilers.
I'm designing a digital power supply at the moment, and I'm likely to put a PIC24 or STM32 chip in it. Mostly for cost/performance (which I don't really need, though), but also so I have similar/identical code for most of my projects (saves time).
I would only use 8-bit chips if for package or power consumption.
PK2 can also be used as a AVR programmer using avr-dude
Risking a quick diversion off topic, do you have any links to the info on this? Last time I looked I came up with something in Russian with a very suspicious chain of half broken html links and some other method I didn't like the look of but cannot quite remember at the moment.
I'm not dreaming; I see no new projects that are pic based compared to the numerous ones that are arduino based.
I would not even consider using a pic in an opensource project simply due to the fact that the tools are not free and not nearly as functional as they could/should be.
the ones using pic are the ones told to use it at school or industry. I know of no one that starts out picking the pic anymore. its used by pros (who have the expensive tools) but rarely by new guys starting out.
if you have info to show otherwise, bring it. else, it seems pretty obvious if you just take a look at a place like hack-a-day (etc) and see how many pic submissions are there vs atmel. pic is rarely even mentioned anymore and that's a fact.