yes, *microchip* may have compilers for their chips, but if I cross into another company, then I have to use different compilers, linkers, debuggers, etc?
getting back to the arduino vs microchip comparison, the arduino chip 'family' makes use of tools that are already installed or very easily installed on our systems.
I agree. Using one IDE and one toolchain makes life a lot easier when dealing with multiple targets/platforms.
yes, *microchip* may have compilers for their chips, but if I cross into another company, then I have to use different compilers, linkers, debuggers, etc?
getting back to the arduino vs microchip comparison, the arduino chip 'family' makes use of tools that are already installed or very easily installed on our systems.
I agree. Using one IDE and one toolchain makes life a lot easier when dealing with multiple targets/platforms.
Well, there are lot of resources of using the compilers under eclipse if that is the goal.
Well, there are lot of resources of using the compilers under eclipse if that is the goal.
I think he (they? since "he" thinks he speaks for others too) was asking for "literally" one tool chain (compiler/linker/debugger) for all chips. Solutions under an IDE like Eclipse is one IDE but (potentially) multiple toolchains (CCS would be a good example for that).
What he (they?) was asking is to have open source tools in closed source systems. A little bit of an oxymoron if you ask me: if you really want to work on an open source system, obviously a closed source system should be in your sight.
I've had enough of your shenanigans, danny. welcome to my blocklist. when you can't carry on a conversation without making it personal, I'm done with you. shame, too, since you do have some good insights. but with your constant wanting to make this into something personal, I have no choice but to ignore you from now on. not that you'll care, but if you post anything directed to me, you'll understand why I won't be replying to your posts anymore.
the thread has been generally informative and useful, but clearly you have run out of ideas and now resort to childish attacks. I want none of that, danny. please grow up.
I would like to not care, at some point, what family of chip I use. I'd really like all my tools to be gcc-based so that I don't have to keep relearning stuff needlessly. or at the very least, similar enough and without any 'funny stuff' going on. if that ever happens, I'll start to consider other vendors and their chips in my designs and builds. (again, all DIY based and targeted, not meant for high count production runs).
Another, but commercial option is IAR Embedded Workbench. Quite expensive though so not for hobbyist. But they make C-compilers for many different MCU families, like ARM, AVR, AVR32, MAXQ, CR16C, SAM8, STM8, MSP430, 8051 and a number of families from Freescale and Renesas:
http://www.iar.com/Products/IAR-Embedded-Workbench/Actually IAR was consulted when initially designing the AVR architecture to help make it a more C-friendly architecture than C-unfriendly architectures like 8051 and PIC16. And because of this collaboration IAR made the first C-compiler for AVR. For a long time Atmel's AVR code examples were compiled in IAR. Now they have integrated the free GCC in their own tool-chain though.
I've read MSP430 and ARM are even more C-friendly.
Like GCC there's no IAR compiler for PICs though.
Like GCC there's no IAR compiler for PICs though.
They did support some PICs for a while.
they make C-compilers for many different MCU families
That is one of the reasons that I use IAR, aside from their utilitarian UI.
However, that's not going to solve his (their?) issue: he/they want to have a free open source compiler / toolchain for all mcus. Even IAR has different compilers for different chips and it is as far from free and open source as it is possible.
free open source compiler / toolchain for all mcus
Bad idea, we can give up talking about optimizations for the various mcu's then.
I don't see the problem in various toolchains for each mcu, it's good if the toolchain is standalone so you can use it with you ide/editor of choice, but that is just an small part of setting things up I would guess, and one could still use common tools for the build process, so one have same project-file/makefile format if that is a point, but one compiler to rule them all?, nah..
free open source compiler / toolchain for all mcus
Bad idea, we can give up talking about optimizations for the various mcu's then.
I don't see the problem in various toolchains for each mcu, it's good if the toolchain is standalone so you can use it with you ide/editor of choice, but that is just an small part of setting things up I would guess, and one could still use common tools for the build process, so one have same project-file/makefile format if that is a point, but one compiler to rule them all?, nah..
What you want is a common toolchain so you can use the same options, linker descriptions files, etc for every platform. GCC (actually GCC + binutils + GDB) does that. You can use the same code on Linux, Windows, OSx and many microcontrollers without needing to change IDE or compiler. Using 'one compiler' doesn't mean you need to give up on optimisations. The back end of GCC (the part which generates the machine code) is tailor made for each target.
Just downloaded XC8 1.31 as an upgrade to 1.12. On the only pic16 source I have to hand ram usage increases by 2 bytes but flash usage is down by 332 words (about 10%). Not bad.
In related news, Microchip have some sort of deal on XC32++, no real info as to what is offered, apart from the C++ extensions and Dinkumware. Whatever, the offer had the word 'Free' in the title so it must be good
XC32++ licenses have AFAIK always been free, but it's just a license key for XC32 that enables compilation of C++.
According to this only the XC 8 compiler for PIC 10/12/16/18 MCUs is Hi-Tech PICC based while both the XC 16 compiler for PIC 24 MCUs and dsPIC DSCs + XC 32 for PIC 32 MCUs are GCC based:
http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/#comment-4216mlp on February 24, 2014 at 9:49 pm said:
XC8 is a merging of HI-TECH’s PICC and PICC-18 products. The HI-TECH compilers for Microchip’s 16-bit and 32-bit MCUs, just like the HI-TECH compilers for all other architectures, had no connection to GCC and were retired after the acquisition.
XC16 and XC32 are GCC-based with no HI-TECH connection.
while both the XC 16 compiler for PIC 24 MCUs and dsPIC DSCs + XC 32 for PIC 32 MCUs are GCC based:
XC16 = C30;
XC32 = C32.
I wonder why they would retire it again?
Their PIC offerings never caught on - I suspect that the free C18 was too enticing for PIC users, and PIC24 came on too late.
Microchip doesn't give a shit about hobbyists. And neither does any other semiconductor company.
Microchip's strengths are long product life, dedicated replacements for obsolete products and good support for volume costomers. Weaknesses are lack of low-cost/free IDE (not a problem for business customers), buggyness of silicon (again, can be mitigated when you are a big company) and kind of obsolete architecture.
Microchip doesn't give a shit about hobbyists. And neither does any other semiconductor company.
True. But that has proven to be fairly difficult for some people to understand and accept.
Microchip doesn't give a shit about hobbyists. And neither does any other semiconductor company.
True. But that has proven to be fairly difficult for some people to understand and accept.
But Microchip have a long track record of supporting lower volume users.
They pioneered OTP when everyone was using maskrom, parts have always been easy to get in low volumes, datasheets are very good, they have way more DIP options than anyone else, rarely if ever make parts obsolete, have low cost programmers and emulators, and a very low cost programing service.
I can't think of any other maker that comes close across all these aspects.
Microchip doesn't give a shit about hobbyists. And neither does any other semiconductor company.
Microchip's strengths are long product life, dedicated replacements for obsolete products and good support for volume costomers. Weaknesses are lack of low-cost/free IDE (not a problem for business customers), buggyness of silicon (again, can be mitigated when you are a big company) and kind of obsolete architecture.
Utter rubbish.
Why do things like the pickits exist? Why is the ICD3 such a good price (take one apart if you don't believe me)? MPLAB IDE is free and as far as I can remember always has been, I only write in assembler so can't comment on the C compliers though.
I've only ever hit one undocumented bug on the silicon - the errata is excellent.
Obsolete architecture - I don't think so... Have you looked at the PIC24 or the dsPIC33? The only misstep I can think of is the PIC32 (and it's probably fine for what it does - I never bothered learning MIPS4K assembler).
When I did a small assembler project in MPLAB a few years ago I remember it wasn't that nice to use as an IDE; but since then I'm really happy with just using Codeblocks and setting up my own build tools to the various compilers; if anything I've learnt so much more doing that way that I must thank MPLAB for being awkward for me to use :-)
I'm really happy with just using Codeblocks
Big fan of CB myself. Great tool, and a big reason I use EmBlocks on PIC24 chips. A life saver.
They might be fine with assembler. Nevertheless there is no solid and free compiler for Microchip devices. Not that I care - For small stuff I use ATTiny's and for bigger Cortex M0/M3/M4. One recent exception is replacing 3 PWM generators with PIC10F200 due to space limitations.
Rdg debuggers:
As for Atmel - IIRC their AVR Dragon is not that expensive - 50€ or thereabouts. IDE is free and very usable (IMO). Other than that you can get USBASP clone on ebay for $2 or so shipped. And those clones generally work.
Microchip - I have never used ICD3. A friend of mine had it and it just died. Pickit's fine. It works very stable on any OS I have tried. Value for money is really high on that one
STM32 -> buy a 12€ eval board and you're set for all STM32 devices. Win!
I'm really happy with just using Codeblocks
Big fan of CB myself. Great tool, and a big reason I use EmBlocks on PIC24 chips. A life saver.
I just installed EmBlocks and had a play - thanks for the tip!
I do my best to avoid Mplab/Mplab X - because of that, I don't use 18F parts.
EmBlocks has been a life saver for me as I love the 24F parts.
They might be fine with assembler. Nevertheless there is no solid and free compiler for Microchip devices. Not that I care - For small stuff I use ATTiny's and for bigger Cortex M0/M3/M4. One recent exception is replacing 3 PWM generators with PIC10F200 due to space limitations.
If you prefer to use AVR over PIC, Atmel has started making 6-pin tinyAVRs [ATtiny4, 5, 9 & 10] to compete with the 6-pin PIC10 series from Microchip.
Nevertheless there is no solid and free compiler for Microchip devices.
Yes there are - XC16 and XC32.
Though the free version of XC8 isn't very efficient, it is perfectly "Solid" IME
Nevertheless there is no solid and free compiler for Microchip devices.
Yes there are - XC16 and XC32.
Though the free version of XC8 isn't very efficient, it is perfectly "Solid" IME
SDCC is also free and very usable for PICs.
Microchip doesn't give a shit about hobbyists. And neither does any other semiconductor company.
Microchip's strengths are long product life, dedicated replacements for obsolete products and good support for volume costomers. Weaknesses are lack of low-cost/free IDE (not a problem for business customers), buggyness of silicon (again, can be mitigated when you are a big company) and kind of obsolete architecture.
Of course they are going for volume, the devices cost so little that in order to make any reasonable profit they have to sell lots.
That being said, as I mentioned earlier most of my microchip devices have come through their samples program - as in they gave them to me for free in small quantities.
Im not sure what you mean exactly by an IDE, what microchips always offered for free has been enough for me and is what I would consider a fitting IDE for it's intended purposes.
And obsolete architecture? how can something that is still in widespread use be obsolete?