-
I doubt that has much influence. In most companies there will be seasoned engineers and the interns and the employees fresh from school will have very little say in which microcontroller to use in a project
I agree in part, however it is not the way like things happens in general. There are not rare cases in which a team of a project focused for years on maintaining and making small improvements, is allocated for the coming projects, and after a few years the staff as a whole became out of date in relation to technological innovations, and the newcomers properly selected brings accretion of knowledge to the group. -
Blame yourself for buying something cheap. If you want speed, open your wallet and buy an ICD3.
Haha, you're so funny!
The time it takes my ICD3 to even turn on I could have burned and started debugging my STM8, STM32, or PSoC project by now, and been most of the way there with AVR - It'd be waiting for Atmel's dumb update thing to go away.
Debugging - or even programming - Microchip parts with their debuggers is just painful compared to the competition. -
Quote
How big is the chance NXP will kill those chip lines in closest 5 years?
if anything, you should worry about NXP/Freescale killing the NXP parts.
Hi
Everything that is being said about the ATMEL / Microchip thing could just as easily be said about ARM and the Freescale MCU families. They pretty much killed off forward motion on all their old families when the decision to "go ARM" was made. One could debate that move as well. Net result is that today you are asking if Freescale ARM kills NXP ARM.
Why does this matter in the context of this thread?
ATMEL / Microchip could just as easily turn into a low end ARM powerhouse. They both have a following. If they can hang on to those customers while making the transition (for the most part Freescale seems to have done so) then it should work out well for them.
Bob -
Quote
They pretty much killed off forward motion on all their old families when the decision to "go ARM" was made.
Because the "core" is being commoditized - what "core" a mcu uses does not matter to the end user as much as the peripherals that core utilizes.
I have always said that the proliferation of ARM cores is more or less a marketing thing - as a shareholder of ARM, I am happy about it. But it is downright stupid for any user to make a decision based on what "core" a mcu carries.
As long as you code in a high level language like C, the "core" is fully transparent to you. My non-hardware specific code runs on 8051 as well as it does on a CM4. -
Hi
There is a lot of high speed bit bang assembler still running on cheap and dirty MCU's. That's the end of the world that Microchip and Atmel mostly played in. There the ability to toggle a bit with a single instruction at full "clock speed" (what ever that happens to mean) may be pretty important. Some of the "good old cores" were optimized for stuff like that. ARM and C ... not quite so much... Now before that starts a war, indeed some of the "good old cores" really sucked at doing this sort of thing.
Filp over to things like math performance running C and there's no contest. ARM wins. Not a lot of blink the LED and play a tune greeting cards were very math intensive ...
Bob -
Quote
Filp over to things like math performance running C and there's no contest. ARM wins.
not really, unless you count FPUs and use faster clock speed - not a fair fight then, in my view: I think I did an extensive dhrystone benchmarking of mcus, from 8051 to CM4F. No significant advantage for CMx chips over other comparable chips. PIC24 and PIC32 did reasonably well while CM0 and some CM3 did poorly.
edit:
i did some quick test, counting the instruction cycles of executing a version of the berkley random number generator - producing "long" rather than "int" output, to tilt the playing field towards 32-bit chips.
PIC24F: 60 cycles;
PIC32F: 27 - 30 cycles;
Cortex-M: 20 - 55 cycles;
ARM7TDMI: 15 cycles;
A15: 17 cycles;
So on a per Mhz basis, ARM doesn't hold much advantage over comparable chips. -
Quote
Filp over to things like math performance running C and there's no contest. ARM wins.
not really, unless you count FPUs and use faster clock speed - not a fair fight then, in my view: I think I did an extensive dhrystone benchmarking of mcus, from 8051 to CM4F. No significant advantage for CMx chips over other comparable chips. PIC24 and PIC32 did reasonably well while CM0 and some CM3 did poorly.
Hi
Not a fair fight indeed. Unfortunately that's what happens on a dollar for dollar comparison. The ARM gizmo has a faster clock. It doesn't help it on bit bang stuff, but that (and the 32 bit bus compared to 8 bit) cleans up on math.
Bob -
Quote
Filp over to things like math performance running C and there's no contest. ARM wins.
not really, unless you count FPUs and use faster clock speed - not a fair fight then, in my view: I think I did an extensive dhrystone benchmarking of mcus, from 8051 to CM4F. No significant advantage for CMx chips over other comparable chips. PIC24 and PIC32 did reasonably well while CM0 and some CM3 did poorly.
All PIC32MZ EF have single cycle FPU (single and double precision) and DSP instructions. M4F is only single precision. M7 has two optional FPUs, either single or single+double.
Before PIC32MZ is written off, in terms of hardware while I agree that the original EC version is indeed something to avoid, the more recent PIC32MZ EF is definitely worth consideration if you're at that segment of the market (M4/M4F/M7). The EC was simply not ready for release.
On another note regarding whether or not to be price conscious, while I agree for one off's and very short runs, say 20 or less, you're wasting your time trying to shave off a few cents here and there, that's not the case for larger volumes, even from 100 off. Part of the hardware design criteria has to be pricing and availability of parts in the latter case, and you have to look at it in terms of a system, not just the individual parts. For example adding a reasonable performance ADC to an MCU can be a much more expensive piece of work than finding an MCU with that ADC integrated into the chip, you may need external FIFOs and muxes too for example.
Whether ARM or not should not just depend on the core. Realistically, knowing ARM from one manufacturer isn't going to help that much when going to another. More important is the already accumulated knowledge of toolchains and a given manufacturer's devices. Learning a new device from a different manufacturer, with or without ARM, is still going to need work, and the core is a relatively small part of that.
Having said all that, if you're just starting out in the MCU world and it's only 32 bit you're interested in, and don't care about anything else like peripherals and toolchains, I'd have little hesitation in suggesting that ARM is going to be a better choice due to sheer market penetration. Your biggest problem then is understanding the ARM market and the differentiators, which between ARM and their licensees' marketing have done a crap job over the years. -
Still when using PIC you have a very limited choice of compilers or need to spend cash on a non-crippled version which in case of PIC32 is an older version of GCC. For ARM you can use the latest GCC version which has improved code density.
-
Still when using PIC you have a very limited choice of compilers or need to spend cash on a non-crippled version which in case of PIC32 is an older version of GCC. For ARM you can use the latest GCC version which has improved code density.
I'd definitely agree with that. Microchip really must take a look at their competitive offering in this respect, especially if you use their entire range where there are three compilers to fund.
ISTR reading somewhere that you can build your unrestricted PIC32 compiler if you know what you're doing an have a bit of time on your hands. There have certainly been various hacks over time for all three compilers to uncrippled them, although I don't know how many still work, particularly for the XC8 compiler which isn't GCC. Bearing in mind the flakiness of the current licensing mechanism, and the amount of time and effort you can spend getting a legitimate license to work in Pro mode, a hack can seem like a reasonable proposition! -
Quote
you can build your unrestricted PIC32 compiler if you know what you're doing
With all the eevblog "experts" who insist on rolling their own compilers / make files, it wouldn't surprise me that they have built unrestricted pic32 compilers millions of times by now.
-
Quote
you can build your unrestricted PIC32 compiler if you know what you're doing
With all the eevblog "experts" who insist on rolling their own compilers / make files, it wouldn't surprise me that they have built unrestricted pic32 compilers millions of times by now.
Despite the artificial limitations, we are quite satisfied with Microchip's GCC compiler for PIC32.
A possible explanation for why you don't find improved versions of GCC for PIC's could be that most people are ... satisfied.
-
Quote
you can build your unrestricted PIC32 compiler if you know what you're doing
With all the eevblog "experts" who insist on rolling their own compilers / make files, it wouldn't surprise me that they have built unrestricted pic32 compilers millions of times by now.
Hi
For that matter, you *can* write your own compiler from scratch / line by line. Been there / done that / don't want to do it again. Just because you *can* does not mean you *should*. Even the mainstream tools have gotcha's in them. The further you head off on your own, the more likely bugs are to creep into your tools. If indeed you can get high quality (indeed a relative term) tools for ARM for free, having to head off into the weeds to play with something else is a major problem.
Whatever comes out of this merger, they better get the tool offerings working right. That's either a "join the Borg err ARM" thing or put some real money into their own tools group. The days of grabbing some university project for your tools are long gone (yes you can dig into your Microchip history book and find that section).
Bob -
Quote
Despite the artificial limitations, we are quite satisfied with Microchip's GCC compiler for PIC32.
True. I have always been happy with C30/XC16, and C32/XC32 though my experience there is highly limited. the newer versions of XC8 are highly competitive vs. PICC std/pro.QuoteA possible explanation for why you don't find improved versions of GCC for PIC's could be that most people are ... satisfied.
Not for our "experts" who seem to be always complaining about how inadequate those tools are, how they are built on older gcc, how "crippled" they are, how much microchip charges for them, and how microchip should give away their hardwork.
I always wondered that with the source code widely available, why don't those "experts" just spend a few minutes and roll their own?
-
how much microchip charges for them, and how microchip should give away their hardwork.
Counterpoint: I don't think Microchip "should" give away their hard work, but since so many other vendors do, I'll just go to them instead.
-
how much microchip charges for them, and how microchip should give away their hardwork.
Counterpoint: I don't think Microchip "should" give away their hard work, but since so many other vendors do, I'll just go to them instead.
Hi
The logic seems to be "we are a silicon company, we do tools to sell silicon". There are often people who make "better" tools and charge for them. The bigger the audience, the more competitive that end of it gets (better bang for the buck). Unfortunately for the older Microchip / Atmel cores, that's another win for ARM.
Bob
-
I always wondered that with the source code widely available, why don't those "experts" just spend a few minutes and roll their own?
Because then they would be real experts.
Microchip's free compilers are optimized for learning and debugging. If you need more optimization for a commercial product then the cost of the compiler isn't an issue. If you're a hobbyist then just buy a more powerful chip. If you're a freeloader who doesn't want to pay for either then why should Microchip (or anybody) care about you?Quote from: uncle_bobThere are often people who make "better" tools and charge for them. The bigger the audience, the more competitive that end of it gets (better bang for the buck). Unfortunately for the older Microchip / Atmel cores, that's another win for ARM.
Which ARM-specific tools are better 'bang for the buck'?
-
For the past 25 years I have been doing this: Whenever a sales rep wants me to use a microcontroller I always tell them I must have a full compiler+tools for free. If a manufacturer is serious about their microcontrollers they should be able to provide this for their valued customers. For the past 25 years I have never paid for a microcontroller toolchain! There is enough competition between microcontrollers so use that to your advantage.I always wondered that with the source code widely available, why don't those "experts" just spend a few minutes and roll their own?
Because then they would be real experts.
Microchip's free compilers are optimized for learning and debugging. If you need more optimization for a commercial product then the cost of the compiler isn't an issue. If you're a hobbyist then just buy a more powerful chip. If you're a freeloader who doesn't want to pay for either then why should Microchip (or anybody) care about you?
edit: typo -
Which ARM-specific tools are better 'bang for the buck'?
Hi
Keil certainly seems to have a very real following in that respect. It certainly cleans up compared to the good old Microchip tools. Indeed not a fair comparison. Again, that's sort of the point. It's really tough to do up a big fancy toolset for a small audience.
Just to be very clear, no I don't use Kiel. For what I do, it's overpriced. If we needed to add horsepower to the tools, it is on my short list of things to look at.
Bob -
I don't use Kiel. For what I do, it's overpriced.
I can't see a price on Kiel's website. How much does it cost?
-
unfortunatley every single one of them requires a particular operating system build and toolchain that nobody else is interested.Quoteyou can build your unrestricted PIC32 compiler if you know what you're doing
With all the eevblog "experts" who insist on rolling their own compilers / make files, it wouldn't surprise me that they have built unrestricted pic32 compilers millions of times by now. -
Keil certainly seems to have a very real following in that respect. It certainly cleans up
Or in my case, locks up
No more Kiel for me!
-
I don't use Kiel. For what I do, it's overpriced.
I can't see a price on Kiel's website. How much does it cost?
~USD$5000 -
I don't use Kiel. For what I do, it's overpriced.
I can't see a price on Kiel's website. How much does it cost?
Hi
A lot depends on which options you add into the package. It's the options that add the horsepower. Last time I added things up with a reasonable set of this and that, it was in the > $10K range. You also get to pay a yearly fee to continue support.
While that's not prohibitive at work, it takes it out of consideration here at home. They do have student versions, I'm not a student. As another post mentioned, if the people want me to use their MCU, they better supply me with a good set of free tools. That's worked for a long time for me ... It's quite true that if I look at the "great tools" back in the 1980's and what we have today, standards have changed. To some extent it is keeping up with change that is the problem for these outfits.
Bob -
Microchip's free compilers are optimized for learning and debugging. If you need more optimization for a commercial product then the cost of the compiler isn't an issue. If you're a hobbyist then just buy a more powerful chip. If you're a freeloader who doesn't want to pay for either then why should Microchip (or anybody) care about you?
Another option for PIC compilers is Mikroelektronika. They have an IDE/compiler for 8-bit, 16-bit, and 32-bit PIC for $249-299. I've never used it, but it might be a viable option.
http://www.mikroe.com/mikroc/pic32/