EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: dannyf on April 29, 2014, 12:54:05 pm
-
http://embeddedgurus.com/stack-overflow/2011/09/an-open-letter-to-the-developers-of-the-mplab-ide/ (http://embeddedgurus.com/stack-overflow/2011/09/an-open-letter-to-the-developers-of-the-mplab-ide/)
Nice reading, :)
I am so glade that emblocks is there.
-
I don't know if it has any meaning now. MPLAB is surpassed by MPLAB X. But we can talk about MPLAB X... >:D
-
I avoided getting into controller work for a long time. it was a field only for those who were very deep in it and hard to break in if you were just starting out.
arduino 100% changed all that. made it accessible and even fun. the tools were ALL FREE and ALL FUNCTIONAL. no 'pay extra to remove no-ops' BS.
I know that microchip has some better hardware at the chip level, in some ways, but their braindead tool chains and the fact that they still don't 'get' the free software movement has me still being an arduino guy and next to zero pic experience.
PIC: atmel is totally winning over the new generation of kids and if you don't get your act together, you'll be the 'os/2' of chips (lol) in a few short years.
-
the free software movement
I am too poor to use the "free" software.
atmel is totally winning over the new generation of kids
Dream on, :)
-
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.
-
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.
I have to agree. I have seen very few PIC projects in the last few years.
I have used the xmegas in work projects and I have to say they are extremely nice and consistent and intuitive to use. Way better than atmegas.
-
I agree that the arduino project has brought microcontroller projects to a whole new classes of people that had not and would not otherwise have entered into the field. Lots of gray beards poo pood the whole concept early on, not unlike the mainframe computer types looked upon the first microprocessors in the 70s.
And it's not that the original arduino developers were so brilliant or anything, they just had a good idea aimed at a unique audience (artist and non-techies) that needed simple tools and low cost way to enter the field.
The arduino folks just took a bunch of existing open source projects already developed and avalible and integrated them together with a very very simple controller board based on a Atmel AVR 8 bit controller chip. The use of avr-gcc compiler/linker, Processing IDE, AVRDUDE, Wiring, etc, for the idea of using abstraction for things like using pin number instead of the port/pin addressing required at the chip level. It's actually really amazing how little new code the original arduino folks had to create, they just stitched together lots of open source code together and built a simple controller board which they then released as probably the very first highly successful open source hardware project.
Soon even experienced software types found that the platform can be useful, as one is actually developing code (sketches) in C/C++ with all it's capabilities and history. So soon contributed libraries and projects quality and volumn was very impressive and has reached a critical mass that would be certainly hard for any other platform to surpase.
Certainly there are more powerful controller chips available with tons more power at the same or even less price, but if one measure of power is the size of the existing user base it will be interesting to see how long the Arduino project keeps the simple 8 bit controller actually relevant long pass it's otherwise must use by expiration date.
Indeed even the Arduino company has now released Arm based boards (Due) but it's not clear if it is being accepted and adopted in the huge numbers that the more simple 8 bit boards are. And being open source hardware one can now find simple Asian cloned E-bay sold AVR mega328P mini-boards (named Pro-mini) for like $3 each.
And a whole new generation of small specialty vendors are now actively selling components, modules, sensors, etc to this population. Firms like SparkFun, Adafruit, etc started out small with this market and grew to multi-million size very quickly.
For those of you who are as old as me it's very similar to the early growth of the microprocessor field in the mid 70s, where it was not the existing major computer and electronics companies the entered the market till later, it was very much a hobbyist driven market at first.
To be clear it's not a fan boy type of product or platform, as it is not really aimed or useful for the plug-and-play type users, one must learn some basic electronics and programming skills to actually be able
to convert an idea into a real project. But it does allow the quickest learning curve to just getting started of any other platform I had come across. It's fun and useful and cheap, what more does one need. :-+
-
I choose arduinos for my open hw/sw audio projects because of wealth of examples (that jumpstarted me) and also so much online sharing of info. it seemed like the ideal thing to get people to WANT to change the code and try new things out.
its not always the best chip for the task, but the fact that the devel tools work on all 3 platforms and are fully free (and pretty mature, too) seals to deal for me.
industry wise, its often about chip cost, chip size. but for home projects, the size is not as much of a problem and cost is also not a problem since we don't build in thousands of units. what does matter is the toolchain and community support and in that regards, nothing can touch the arduino, the raspi or the BBB. those are the 3 top boards for home DIYers and nothing else comes close (for now, at least).
when I read gerry sweeney's write-up on the non-optimizing compilers on MPLAB adding no-ops unless you PAY to have them removed, that did it for me; I have nearly no desire to do anything PIC based if I can help it. such things are hostile to users and I don't like helping any company that is this hostile to their userbase.
PIC is the microsoft and atmel/arduino is the linux, very very loosely speaking (if you catch my drift). I avoid doing any microsoft programming for many of the same reasons I avoid pic.
-
Nice reading, :)
in 2011 when it was written... I'll stick to mplabx.
-
the free software movement
I am too poor to use the "free" software.
Yeah, it is better to spend gazillion dollars on a proprietary tool, surely is better than anything free, right? Except it uses GCC for compilation and GDB for debugging under the hood. Like 99% of ARM tools, the official Atmel's, even the new Microchip's ones, to name just the most common stuff.
I am not sure why are you taking ignorant jabs at free software here when, in most likelihood, you are dependent on it too. It isn't about free as in beer.
atmel is totally winning over the new generation of kids
Dream on, :)
I haven't heard about any projects using PICs that were built by kids recently, but a boatload of Arduinos, Raspberry PIs, Beaglebones and similar. Microchip missed the boat here big time, IMO.
-
microchip REALLY missed the boat, that is so true! as I read the story, the arduino guys approached both MCP and ATMEL and MCP turned them away. they will regret that for the next 5 years, very likely. their arrogance is also part of the problem and why people hate having to learn all the gory details of each fork of the mcp architecture.
arduino, while dumbed-down a bit too much (imho) did take the right approach toward an abstraction layer and it removes the need to care about which chip is below that layer, for the most part. that was such a helpful and visionary design aspect.
...just wish the pin spacing on those 'shields' were reviewed by folks who understand that ".1 spacing is king" in the diy world. sigh.
(pet peeve: people who design for DIY and yet avoid .1 spacing should be sent to a special form of hell when they die) ;)
-
I'm not dreaming; I see no new projects that are pic based compared to the numerous ones that are arduino based.
Projecting what you say to what the market says is probably not wise.
Unless you are the market.
-
...just wish the pin spacing on those 'shields' were reviewed by folks who understand that ".1 spacing is king" in t he diy world. sigh.
Did you ever read the back story about the strange spacing between just two of the four 'shield connectors'?
It was simply an error that they didn't catch when their first boards were returned for their approval, they meant to have .1" spacing. But it was too late (and most likely too expensive) to correct by the time they did discover it. After that they were committed as there were already 3rd party suppliers shipping shield products that used the irregular spacing so it was turned into a "feature" as it makes installing shield boards backwards onto arduino controller boards impossible. 8)
-
I'm not projecting. why do you think so?
a simple count (if you want to do the work) on any open source hardware forum will show tiny numbers of PIC projects compared to atmel/arduino.
I'm not going to argue with you about this. readers know what's what no matter how you want to try to spin things.
the fact is, MCP is not nearly as DIY friendly and the # of NEW projects using their gear has fallen to near noise level since the advent and popularization of the arduino architecture.
-
a simple count (if you want to do the work) on any open source hardware forum will show tiny numbers of PIC projects compared to atmel/arduino.
Microchip (or Renesas or Freescale or ...) has zero market share on the Arduino forums, :) So they must be doomed.
I would suggest maybe a more robust way of reasoning?
-
go to hack-a-day, then. what percent of pic projects do you see vs arduino?
that forum is not locked to any one vendor, so its a fair place to start. its a popular site for controller projects.
that's my 'easy' data point. if you have one of your own that supports that pic is gaining popularity, I'm all ears.
-
go to hack-a-day, then. what percent of pic projects do you see vs arduino?
Go to any rec.center. Over a period of a year, how many kid's paintings do you see on it's walls comparing to works of professional painters?
-
microchip REALLY missed the boat, that is so true! as I read the story, the arduino guys approached both MCP and ATMEL and MCP turned them away. they will regret that for the next 5 years, very likely. their arrogance is also part of the problem and why people hate having to learn all the gory details of each fork of the mcp architecture.
I actually think it was a smart move, in a weird way.
Look at Atmel now... yes, Arduino is very popular, but it mainly uses 2-3 chips from Atmel's line and now Atmel has to continue to make those chips and support them otherwise their reputation will suffer. But how about newer, better parts? Do you think any reasonably large percent of the persons buying Arduino even bother to check what other chips Atmel does, do you think they even care to download the datasheet and work around the wrappers supplied to them by the Arduino guys? Hell, I'd bet the majority of the people buying Arduino don't even know that the microcontroller is made by Atmel.
It's almost like a chicken and egg problem - if the Arduino guys don't make a board with a newer chip and support it in the software with wrappers, for the majority of those amateur developers that chip doesn't exist...
-
go to hack-a-day
I said this earlier so let me be blunt: if you want to know how a product does in its market, go look at how it does in its market, not how it does in *****some segments***** of its market.
Hope it helps.
-
I like the Arduino, it's ideal for quick prototypes where some driver code is already available and it certainly hit a nice target market. With that said...
a simple count (if you want to do the work) on any open source hardware forum will show tiny numbers of PIC projects compared to atmel/arduino.
Microchip (or Renesas or Freescale or ...) has zero market share on the Arduino forums, :) So they must be doomed.
I would suggest maybe a more robust way of reasoning?
Indeed.
How many types and variations of mcus does ATMEL make? Would you suggest that ATMEL cease production of all but those used in the Arduino projects? After all, Arduino is so popular making all those other chips is a waste of time?
How many Arduinos are sold each year? Beside me I have a carbon monoxide alarm containing a PIC16, tens of thousands sold perhaps? My two Logitech remote controls though different models both use PICS, hundreds of thousands sold? I have an AllForOne remote around here somewhere iirc PIC based too, again hundreds of thousands sold?
These are just the devices that come immediately to mind, Microchip may have missed one boat but there are many, many more in the harbour.
-
now Atmel has to continue to make those chips
I don't think Atmel cares the least bit about it. I did this calculation awhile back: sales of chips related to Arduino wouldn't even amount to a rounding error for Atmel.
-
microchip REALLY missed the boat, that is so true! as I read the story, the arduino guys approached both MCP and ATMEL and MCP turned them away. they will regret that for the next 5 years, very likely.
Microchip shipped their 13 billionth PIC last year, and continue to ship more than 1 billion PICs a year.
Here http://www.adafruit.com/blog/2011/05/15/how-many-arduinos-are-in-the-wild-about-300000/ (http://www.adafruit.com/blog/2011/05/15/how-many-arduinos-are-in-the-wild-about-300000/) they think there are 300k Arduinos shipped.
Microchip ship more PICs every 3 hours than have been used in Arduinos total. Really missed the boat and regret? The Arduino chip market is completely trivial and the generally clueless makers using Ardunos are not the ones who are going to get Microchip design wins in volume products.
-
the arduino architecture extends much more than the 328 style chips.
in fact, its now more than atmel, as has been mentioned (arm and even MCP versions of 'arduino' that I've seen).
there was a short project called galago (I knew the 2 guys working on it, back a year or 2 ago) and that had the promise of using arm chips but in an arduino-like environment with a full hardware on-chip debugger, as well. they didn't get too far (business wise) but they did have a cool idea and it was all because of the arduino 'movement'.
-
The Arduino chip market is completely trivial
Unfortunately, facts like that are very difficult to comprehend by the all-too-important Arduino folks.
:)
-
atmel understands something mcp missed: planting seeds.
apple knows this, too (lol: apple seeds, ha!)
they (apple) give huge discounts to schools so that kids learn on apple gear. MS is also trying that.
once you get someone trained on some tech, they tend to use it over stuff they don't know.
analogy: why is cisco the undisputed king of networking gear? my answer: because their CLI is everywhere, they get companies (and schools) to value the certifications from cisco and once you know their gear, you tend to stay with it and choose it for new projects.
this is a very smart business approach. and I would also likely choose an atmel chip over a pic chip in a commercial setting since I know one over the other much better.
the commercial side of sales is not what we are talking about HERE, though; the controllers forum on THIS site is more about diy and not at all geared towards those that do this for a living. folks like that are here, but this forum is not about them, its about the learner and home diy'er. and for them, PIC nearly does not even exist on their radar.
-
atmel understands something mcp missed: planting seeds.
And maybe Microchip understands something Atmel missed: stoney ground.
-
I also think that the 'arduino' platform has not had nor ever will have an impact or caused any major changes to the micro controller industry.
Rather the point is that it has had a very big impact on many thousands of new users that would have otherwise never had any exposure or use for a micro-controller. It simply created a new very successful niche market.
I'm sure the original Arduino developers were as surprised as anyone else with the results of their initial project. Some of those new users will go on from there and enter the more traditional path to become professional EEs where they might not have ever been interested in the field.
But for most arduino users it's just a simple and inexpensive way to have lots of fun building stuff. The Arduino project should be applauded for what it has accomplished, not scorned or berated for not being professional enough way of getting started. At least they get to start by learning C/C++ rather then Basic. ;)
-
its about the learner and home diy'er.
Then maybe you should have said something like:
I see no new *****learner and home diy***** projects that are pic based compared to the numerous ones that are arduino based.
this is a very smart business approach.
Yeah. Except that that approach, if 100% successful, wouldn't amount to a rounding error for Atmel.
How many such "smart" approaches Atmel has to make to overcome its competition?
:)
-
atmel is totally winning over the new generation of kids
My initial comment wasn't really about Microchip vs. Atmel - both, in my view, have a bleak future.
This year is the 3rd year over the last 5 years that I have visited China for mcu-related seminars. PICs are practically not followed there; AVRs had some followings and many people there are switching to ST (STM8 or STM32). You would say the biggest and most enthusiastic participation at those 32-bit ARM seminars (Freescale and Renesas have their own following, also very strong). And the enthusiasm got bigger each time as time went by.
If I were Atmel, particularly Microchip, I would be very scared.
I think there will continue to be a market for 8-bit mcus, just as there is still a market for 1/4-bit mcus here now. I would be surprised if it is substantial enough to support a handful of shops: how many of you know of anyone working on MC14500?
The glory days of 8-bit mcus are probably behind us.
-
it seems that every controller based board I get from ebay/china uses the VERY ancient 8051 series chips! big ugly wide-DIP chips, not even small nice ones like atmel and pic ;)
their toolchain is at least 20 yrs behind the west. I can't understand the 8051 love over there, other than maybe its sourced by lots of makers and its cheap as, well, chips.
the western DIY market, though, shows no signs of slowing on 8bit cpus. especially the thruhole ones. I avoided the mega-arduino chips because they are not diy solder friendly and I want my users to be able to solder and repair their own boards.
as long as there is a DIP version of a controller that has full open source support, I'm happy. it does not have to be an arduino, but anyone who plays games with me by charging me to REMOVE no-ops - I will refuse to do business with such companies if I can at all help it. each time I think of them inserting slow-me-down instructions as punishment, it fills me with anger!! let them sell hardware. the HELL with trying to sell software; its not their market and they are stupid to think this has to be a profit-center.
-
it seems that every controller based board I get from ebay/china uses the VERY ancient 8051 series chips!
Does that include the "fake" Arduino boards you got from China?
I can't understand the 8051 love over there,
Maybe it has something to do with their functionality? Value? Availability? ...? Try to find a PIC or AVR with 24-bit onboard ADC; or onboard CPLD? ...
the western DIY market, though, shows no signs of slowing on 8bit cpus.
Nor did those MC14500 guys in 1982. Where are they now?
I avoided the mega-arduino chips because they are not diy solder friendly and I want my users to be able to solder and repair their own boards.
That's a valid concern if you don't have access to affordable PCB services.
the HELL with trying to sell software; its not their market and they are stupid to think this has to be a profit-center.
The beauty of a free market is that you can do whatever you feel like, including being irrational.
Me? I look at what I get vs. what I pay and make a decision on that. The vendors can make whatever they make on me, however they make that on me, as long as I get good value for my money.
-
atmel is totally winning over the new generation of kids
My initial comment wasn't really about Microchip vs. Atmel - both, in my view, have a bleak future.
This year is the 3rd year over the last 5 years that I have visited China for mcu-related seminars. PICs are practically not followed there; AVRs had some followings and many people there are switching to ST (STM8 or STM32). You would say the biggest and most enthusiastic participation at those 32-bit ARM seminars (Freescale and Renesas have their own following, also very strong). And the enthusiasm got bigger each time as time went by.
If I were Atmel, particularly Microchip, I would be very scared.
Atmel has their own ARM line too. However, I do agree that most new stuff is easier and cheaper (!) to design with something like STM32F1xx or F3/4 series than an 8bit PIC or an Atmel micro. Where the 8bit chips have advantage is the simplicity. Even STM32F103 series can be totally overwhelming for someone upgrading from a smaller micro.
The glory days of 8-bit mcus are probably behind us.
Probably not new fancy projects, but cheap, tiny and simple to program 8bit micros will have their place for a long time to come for simple things - that's why the ancient 8051 architecture (and the lack of royalties) still hangs on. This is where Microchip has a certain advantage - their chips are relatively cheap. On the other hand, ATMegas and XMegas are not at all priced competitively, IMO - I can get many times more powerful STM32 for half of the price of an ATMega328 ...
-
it seems that every controller based board I get from ebay/china uses the VERY ancient 8051 series chips!
Does that include the "fake" Arduino boards you got from China?
I can't understand the 8051 love over there,
Maybe it has something to do with their functionality? Value? Availability? ...? Try to find a PIC or AVR with 24-bit onboard ADC; or onboard CPLD? ...
I avoided the mega-arduino chips because they are not diy solder friendly and I want my users to be able to solder and repair their own boards.
That's a valid concern if you don't have access to affordable PCB services.
I don't order arduino boards from china; I have my own arduino board and I buy real chips from US suppliers. maybe you were thinking of someone else?
I have not found where the audio boards I sometimes buy from china need ANY of the things you mentioned. the answer is simple: they are cheap, the tools have long been pirated (ie 'free' now) and the chips are probably very cheap. otoh, they are huge chips and waste a lot of board space.
the boards I have bought were DACs or preamps and all they needed to do was to receive some IR, decode it and set some registers in the main chips. NOTHING that could not be done with ANY other controller. 8051 gave no magic here, sorry to disappoint you. they were chosen, like I said, because they were cheap, multiply sourced and the software is most likely pirated and they have enough people who know the 8051 well enough. I have not heard of anyone seriously using 8051's on any new projects in well over 15 yrs.
as for soldering, if you are making a DIY kit, you should assume thruhole ability only. to assume more than that is to limit your market and make things harder than they have to be on your users.
-
I have not heard of anyone seriously using 8051's on any new projects in well over 15 yrs.
Time to broaden your horizon again, :)
-
go to hack-a-day
I said this earlier so let me be blunt: if you want to know how a product does in its market, go look at how it does in its market, not how it does in *****some segments***** of its market.
Hope it helps.
I think it is massively unfair to compare a general market share versus "projects by kids". The latter is overwhelmingly dominated by Atmel at the moment, thanks to Arduino and its clones, both ATMega and ARM based.
I don't think anyone was trying to generalize this to a total market share - Atmel is a flea when compared to Microchip's dinosaur there.
However, it is not really by anything of Atmel's doing, really - they simply had a suitable product on the market for which open/free 3rdparty tools were available. If Microchip had reasonable tooling, they would have had that market segment too.
I don't see why so many people feel compelled to express their disdain and scorn for Arduino users - sure, these are rarely well engineered projects and many of these people are naive/ignorant but it is a tool that allows many more "mere mortals" to start building stuff. Give them a break ...
-
The glory days of 8-bit mcus are probably behind us.
I heard that in 1990.
Microchip responded with the PIC10 series. As of yet I haven't seen any serious ARM contenders that compete with the PIC10 price point for low end appliances/gadgets.
-
It always seemed to me that atmel are good for bringing people into the digital electronics world, and some of the things being produced are great.
Personally I do prefer microchip, they feel much more solid and yeah probably a bit more hard work but so much more satisfaction at the end of a project (that's the important thing to me regardless of what I use). The products also seem more robust, and time tested but that just my personal opinion.
I've never had to pay for using microchip products in my personal projects, their samples system allows me to get the physical devices for free and if i'm not doing anything too difficult, then stick to the PIC18 series and there's always been free software. If you want to take something to production then yeah of course youve gotta pay, your'e going to make some money so don't you think they deserve some for giving you that opportunity? It's like someone giving you a room to design a shop layout in for free but if you want to start selling things from it then you've got to pay..
Microchip also have a very large product portfolio which gives them experience...
What Atmel have is an easy to use product, and it's easy to become comfortable and famliar with that. I'm used to being challenged with a lot of different controllers so don't feel any real commitment to a single solution, plus prototyping on an atmel because it's easy for presenting a proof of concept but do they really stand up to production costs? I don't think so... (not to mention custom branding).
I don't want to be positive or negative to the whole microchip/atmel argument but it really does depend which way you look at it.
-
I have not heard of anyone seriously using 8051's on any new projects in well over 15 yrs.
Time to broaden your horizon again, :)
care to point to any current (in the last 2 yrs, say) 8051 diy projects?
I can provide literally hundreds of arduino project that are prominent in diy over the last 2 yrs. I could find a percentage of that for pic. and maybe a percent of that percent for 8051.
can you give examples as to this so-called existence of 8051 projects that I somehow have not seen or heard of? I'm pretty active in the diy world and I have not heard of a single 8051 project, but please, do let me know if I've missed any good ones.
-
I'm pretty active in the diy world...
If you still cannot get it, there is no point in getting it for you.
-
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. ;D I think that the 8-bitters will continue to hold this (low end) market for the years to come.
-
is it true that they do insert no-ops to cripple the free versions? is that only on some architectures?
it would be great if that was a false rumor. I just can't fathom using a tool that knowingly slows down your generated code.
-
they simply had a suitable product on the market for which open/free 3rdparty tools were available.
I would argue that in the 8-bit world, Atmel's products are light year ahead of Microchip's: speed, hardware multiplier, vectored interrupts, adc, etc. Basically the latecomer's advantage.
If Microchip had reasonable tooling, they would have had that market segment too.
Microchip benefited from being the first mover - specializing in the mcu market: 8051 has a considerably better architecture but was slow in developing a full set of (onboard) peripherals. This allowed Microchip to build up a huge user base with its broad product offering.
It is that very advantage that in the end will drag Microchip down. I think their strategy over the last 10 - 15 years has focused too much on milking that cow (playing defensive), rather than developing a way to allow their customers to migrate up market (playing offensive).
-
is it true that they do insert no-ops to cripple the free versions? is that only on some architectures?
it would be great if that was a false rumor. I just can't fathom using a tool that knowingly slows down your generated code.
This is/was true for the XC8 (which is actually rebranded HI-TECH C). I am using the old HI-TECH C 9.80 lite, because i'm used to it and it supports the PIC's i use more frequently.
-
This is/was true for the XC8 (which is actually rebranded HI-TECH C).
Not intentionally inserting NOP. But simply generating overly lazy code.
I am using the old HI-TECH C 9.80 lite
You may want to try pre-OCG compilers, both standard or pro versions.
The newer XC8 compilers are actually very respectable. I tried it on a PIC18 and the free XC8 is just shy of the pro PICC18 and the pro XC8 is quite a bit faster than the pro PICC18.
-
Do you really think Microchip gives a toss about OSS projects using their chips or not?
Microchip however have always been DIY friendly, way before Open Source was trendy - parts are always readily available, and who else makes a wide range of 16 and 32 bit parts in DIP?
They definitely screwed up on the free 8 bit compiler, but the free versions of their 16 and 32 bit compilers are just fine.
-
I would argue that in the 8-bit world, Atmel's products are light year ahead of Microchip's: speed, hardware multiplier, vectored interrupts, adc, etc. Basically the latecomer's advantage.
But when 16 & 32 bit parts are cheaper, who cares?
-
Microchip clearly think it's more important to cater to the needs of commercial users than some random project seen on Hackaday still on a breadboard.
Despite a few minor detours into AVR and ARM in t hepast, nowadays my first choice for any product, or 1-off design is Microchip, and many of the reasons are more applicable to commercial products than DIY, and almost none related to the architectural details so often argued over :
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.
The peripherals and devtools for the whole range form PIC10 to PIC32 are sufficiently similar that there is minimal effort to switch between them. I still use MPLAB 8.something, and I can use it for the whole range.
In general the compilers are set up by default so you don't need to do any dicking around with header files or linker configs unless you're doing oddball stuff like bootloaders. Just #include <pic.h> or <xc.h> and off you go.
I can use the same programmer across the whole range, with an identical hardware interface.
For production test jigs to give to an assembly house , I can just throw in a PicKit 3 in standalone mode for single button idiot-proof programming.
Most parts available in multiple packages, often DIP,SO,SSO and QFN are all available. (and I mean actually available, like I can get a few hundred tomorrow, or preprogrammed in less than a week)
-
its not always the best chip for the task, but the fact that the devel tools work on all 3 platforms and are fully free (and pretty mature, too) seals to deal for me.
I have on occasion used arduino code from the web to try out a new display or chip. For that I have an Uno lying about somewhere's. When I have confirmed the hardware works and am ready to start developing with that new hardware I plug it (usually a shield) into a Microchip based 'Arduino-ish' board and port the code into my preferred compiler. It's usually fairly easy to bring the code across and get it running. Once I have a basic framework running I will then lay out my custom cut-down hardware.
I tend to stay away from chip-vendor supplied tool-chains. I find third party compiler vendors do a better job of documenting the compiler. I also find they do a better job of consistently producing device drivers and libraries. So compilers I will happily spend some money on if they save me time. But now I have a couple I can't see myself going to MPLAB or any other chip vendor. Last time I checked the arduino environment didn't even have a debugger.
At the end of the day you are wanting to release a product into the wild at as low a cost as possible and with the ability to be upgraded by the user. So with a huge selection of chips (some rediculously cheap and many pin compatible upgrade paths) and a good supplier of bootloaders Microchip have the commercial market.
Any hobbyist may prefer to use the arduino to cook up something and that will probably continue, but for the reason's above that's probably the ceiling for the penetration of the platform.
-
Renesas (Hitachi, Mitsubishi & later NEC) has nothing to worry about at least not for a while.
Atmel has been growing strong and surpassed Microchip in 2010 or so.
http://www.dataweek.co.za/article.aspx?pklarticleid=7412 (http://www.dataweek.co.za/article.aspx?pklarticleid=7412)
But not because of the maker community. Microchip went from way down the list to the top on the previous decade leaving Atmel, Zilog and others in the dust.
The funny thing about that article is that you gotta see Cypress (minus smartcards and automotive) growth of %139. Love their PSoC chips. And that is for MCUs it doesn't count USB chips. Then again Automotive is huge for sales, but it shows that Cypress is climbing up big time.
Edit: forgot to attach the picture, doesn't include smartcards and automotive mcus.
(https://www.eevblog.com/forum/microcontrollers/embeddedgurus-com-'an-open-letter-to-the-developers-of-the-mplab-ide'/?action=dlattach;attach=91893;image)
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)
But 8 bit is going to always be king in price and battery life. All those cheap mp3/mp4 players have an 80C51 embedded in their multimedia chip, some PSoC chips have it too.
TI has been stale for a while but not loosing ground. Motorola?? well maybe they get royalties or something, Zilog, Toshiba, etc, might be getting royalties as well.
But even the lonely Z80 probably has shipped more chips than Arduinos and derivatives.
In any event, this was about an open letter, not about who can pee further away.
Myself I don't like the PIC branch instruction set (lack off) for anything lower than the PIC24 and they are very spartan as for the instruction set, but that implies less power consumption and longer battery life at a lower manufacturing cost.
Different strokes for different folks.
-
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).
-
That's a very strange graphic. I have no idea why you'd include smartcards, touch screen controllers and other asics in microcontroller revenue.
My impression for several years has been that Atmels actual microcontroller business isn't particularly healthy and Microchip has been doing better.
I dislike Atmels products because they seem more expensive than comparable PIC devices with little to show for it. That said, the toolchain can be better and Microchips XC8 compiler is in a sad state. It's gotten better but has remained significantly worse than the C18 compiler it replaced and much worse than the XC16 or XC32 compilers at the higher end. The 16 bit products from Microchip are quite compelling because of good cost and good peripheral support. While the 32 bit products are nice, why wouldn't I use an arm at that point?
Professionally, ARM cores have replaced everything. Why not when I can buy a M0 for less than a buck @1k?
-
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.
That said, my PIC32 project made it there a few months back. (The writeup was wrong on all the details though, about the project and about the PIC, as is normal for anything hackaday not involving an 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).
I'd be highly surprised if this was "at no extra expense", unless you're buying serious quantities or expensive parts.
-
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.
So, anything which ranks highly in search engine keyword lists. They lavish the same gushing praise on the trivial and downright dangerous as they do on genuinely novel and innovative projects. They certainly do publicise some good stuff but I find the signal to noise ratio so low I've given up visiting their site.
-
Ha, yeah, Hackaday has turned to crap postings the last few years IMHO. Is there any other news/blog site noteworthy of checking out for cool designs?
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.
I think people can share similar experiences for all IDE's. I can say I've had to recreate a MPLAB X project because otherwise the debugger couldn't figure out what line C code complies to what assembler (PIC24 project).
I've ranted more about MPLAB X in the past, and it's getting better now, but the slowness of Netbeans still bothers me. I say this on a fast machine (SSD/16GB RAM/i5 3570K CPU), and any non-Java based IDE beats it in terms of speed any day of the week. To get rid of that, ideally an IDE needs to step up with QT.
(As a side note: i'm still eager to try out Qt developer environment for ARM, including debugging. I think it should be possible, given there is a GDB server for ARM + open ARM GCC tools).
Microchip offers FREE editions of their compilers for all their families, and XC8 has become better since version 1.21.
Yep, I still can't imagine people say Microchip is not free. They provide a reasonable set of compilers that work out of the box in MPLAB X.
PICKIT 2/3 is ~50 euro's for a standalone programmer + debugger, (PK2 can also be used as a AVR programmer using avr-dude). In Atmel world this buys you an AVR dragon, but they forgot to make an enclosure for that. :-- I guess it's a close call.
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. :-DD
Also the XC8 compiler has it's limitations, and all MCP compilers speak a very strict dialect of C to much annoyance. In addition, XC8 optimizations at the FREE level are to say the least "odd".
I think this is a well known story for those who have argued with an Atmel fanboy, as they will always bring this up. And I regard it as true, but then again I try to avoid using the PIC16 & 18s a bit.
Luckily though, their XC16 & XC32 compilers are GCC (with O1 optimize which does most good stuff).
Moreover it's not hard to figure out how to run all compilers in their most optimal setting. As XC16 and XC32 are based on GCC, their source code is found online (http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html), including the part that speaks to the license manager, which means it's actually incredibly easy to figure out a replacement manager to run it in original intentions :box:
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. ;D I think that the 8-bitters will continue to hold this (low end) market for the years to come.
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.
-
hackaday has a total hard-on for arduino...
It is sad that one would pick hackaday as a yardstick for how a mcu does; It is sadder that after it was pointed out repeated why that's wrong, it still failed to be comprehended, :).
In Atmel world this buys you an AVR dragon
Or 10+ arvasp.
As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern.
Agreed.
significantly worse than the C18 compiler
Microchip did itself a huge favor by killing C18 - that compiler is truly a total crap.
the XC16 or XC32 compilers
PIC24 + C30/XC16 is a nice combination. PIC32 seems to have a crippled peripheral set vs. PiC24.
-
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've used PIC's solidly since 1991. From time to time I've looked at other vendors, but keep returning to PIC.
More recently I've wanted more horsepower in a project, but couldn't stand the learning curve with ARM (I still code in assembler) - I got round the problem with a bit of neat design and XC9572 cpld - still cheaper solution.
Microchip and Atmel are both successful because they understand their customer base, much the same as the generic 8051 clones do. They must be doing something right?
I will stick with Microchip as I haven't been let down once by availability, and I know I can buy a 16C54 to drop into a 20+ year old design... Try and get a Z8, COP8, ST7 off-the-shelf at reasonable prices or qty.
MPLAB X - I haven't tried this for a few years - it sucked when I did and I haven't gone back since.
On another note, I found myself reviewing a 16F54 the other day for a project, I forgot how simple the instruction set was and how much fun it is to code for.
-
do 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.
-
do 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.
So, what I found is all there is, thanks for the confirmation
-
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)
A lot of the "observations" will depend on how you define the market: for example, SIM/RFID typically contain a mcu. Think about how many ID cards are out there, or phone cards, :0.
I think most people would not include those figures + phones in their definition of "mcu market". Automotive is generally included in mcu market definitions.
It is generally accepted that 16-bit ship surpassed 8-bit a couple years ago. Both 16-bit and 8-bit are on a decline in terms of shares but increasing in terms of shipment. ASP on 8-bitters has been on a steady decline for more than a decade now.
I don't think 32-bit has surpassed 16-bit in terms of shipment but did so in terms of $$$.
I would say that biggies in this market are Renesas and Freescale - I would put their combined shares in the 50%+ territory. Infenion and NXP/ST are fairly large too. Fujisu/Spansion is large but only domestically.
TI was up there due to their OMAP which they exited recently.
After that, just some niche players like Silabs (mixed signal), Cypress (USB), Analog (analog/mixed signal).
-
is it true that they do insert no-ops to cripple the free versions?
Spurious 'goto's seem to be the order of the day. It's perhaps some artefact of the compilation process, but they're scattered everywhere, bulking out the code.
As Hans points out, it's no great effort to unlock the other versions.
Regards
John
-
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.
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?
If the 1st stage of the compiler simply translates source into assembly code (or something similar) and does so by using simple, one size fits all occasions template code then it is quite possible that nops and gotos are inserted at this stage. All 'for' loops have the same, general, inefficient but flexible template, all if statements have their own general template etc.
Subsequent compiler stages perform various optimisations, one of those includes removal of superfluous template code.
So, yes, the superfluous code would be put there deliberately but not out of malice, rather as a way of simplifying the compiler and giving the optimisation passes something to work with.
-
what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.
It's unlikely that anybody outside Microchip actually knows the answer to that for sure - we're unlikely to have seen any "hey, make this generate crap code so they cough up for the paid version" memos, after all! However, from reading the output on some of my projects, it doesn't really seem to have anything 'maliciously' bad; it's mainly just unoptimised and/or naïvely-generated code. Things like calculating a value, storing it in a temporary and then immediately loading it back, or a goto over some conditional code that lands right on another goto. Even a simple optimiser would take care of fixing a lot of it up, so it wouldn't have been a problem to emit code like that until they started offering a free version without one.
-
my 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.
-
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?
I worked as a field service engineer for a different minicomputer firm from the mid 70s for around five years, Varian Data Machines. We 'targeted' the scientific application market (along with small businesses) so had quite a few high performance options available at extra costs.
A few of these options (like high speed DMA memory access by peripheral controllers) only required jumper changes on some of the boards. Obviously this was implemented as a marketing policy, but I always felt a little guilty the few times I had to implement such upgrades. The majority of the time such options were factory set up when the customer's system was being configured.
Buying our machines was not unlike buying a new car at the time, the delivered price with options might be double the price of the starting list price. Option list was huge.
Probably the most profitable part of our business was the field support service, typically ran about $1,200 a month. Otherwise one paid by the hour plus parts, but had no guarantee on response time if not on the service contract.
Still all in all the minicomputers at the time allowed businesses to utilize computers at very much lower cost relative to the mainframe computer companies at the time, IBM, Univac, etc.
-
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.)
I think this is as much about differences in specific architectures than 8 vs.16/32. Most applications will be dealing with at least 16 bit data, so 8 bit MCUs will be using more cycles. 16/32 bit tends to be on newer, smaller processes at lower voltages, which will save power in some circumstances.
Even quite low-end devices tend to have smarter peripherals like FIFO'd UARTS and DMA, reducing any minor latency issues.
-
my 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.
This "Gerry" is btw this blogpost: http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/ (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.
is this true or not?
I really hope its not actually true, as stated. it seems quite hostile for a company to do this.
I guess this is not the only post about this:
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/ (http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/)
But remember that this compiler is acquired from Hi-tech, a company that had good reasons to do this.. Just read the conclusion in that post.
-
This "Gerry" is btw this blogpost: http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/ (http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/)
So?
That page is high on rants and low on facts. He didn't even attempt to provide any substantiation that Microchip deliberately inserted nops to lower the performance of the free mode, a contention of this discussion.
His opinions, and I guess others have similar after struggling with useless compilers.
I would imagine that billions of PICs coded with Microchip / Hi-Tech compilers would suggest that those compilers aren't "useless".
You certainly are on solid footing accusing them of being not free (for the non-free versions anyway), of having poor performance, of offering subpar user friendliness, etc.
You are without basis accusing them of being "useless".
Unless of course you define "useless" differently.
-
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.
But as that last blogpost mentions, it seems like microchip is removing parts of this "extracode"/fillercode..
-
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.
So your BMW is useless because my Ferrari gets to the supermarket 0.2 second faster, :)
Being able to tell the difference between "less useful" and "useless" may be useful.
-
it seems like microchip is removing parts if this "extracode"/fillercode..
Newer XC8 is actually quite respectable. I did a benchmark of dhrystone on pic18, among other mcus. The XC8 free is on par with PICC18 pro, and XC8 pro is about 20% faster than PICC18 pro. I don't recall exactly which version of XC8 I used (could be 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.
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.
Yes, that's exactly what i meant. I was not referring to a direct comparison between Microchip PIC vs. Atmel AVR, only vs. the Arduino runtime.
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. :-DD
True, i know AVR's have a more modern architecture than the PIC's, although now Microchip offers 16MIPS PIC's (PIC18F K series). But we all know what that means (Meaningless Information for Processor Speed) :D
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.
Like i said, i mostly work on small projects at the moment (easy money ;D), so 8-bit PIC's are quite decent for the job. Also, where i live there is no Digikey/Mouser, only local electronics stores, and the offer for PIC's is quite bigger than that of the AVR. Another big advantage for me is the DIP packages, because often the customer wants a prototype of the board which i must build myself (toner transfer), so i am mostly working with trough hole stuff, and the 8 bitters are still vastly available in that packages.
-
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.
My bad, I thought on the top off my head it was PK2, but apparently that doesn't work.
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.
Sure, look at dangerousprototypes. It's the complete opposite of hackaday in that sense, as it features many PIC related projects. It's mainly the blog hosts there (Ian and other designers) use PICs , so likely a small community hangs around it.
-
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.
So your BMW is useless because my Ferrari gets to the supermarket 0.2 second faster, :)
Being able to tell the difference between "less useful" and "useless" may be useful.
of course, what I mean like,is that I guess you wouldn't like if Ferrari put an lada carburettor in your Ferrari so i would go lot slower, and make you pay a lot to make it work as it should :)
-
it seems like microchip is removing parts if this "extracode"/fillercode..
Newer XC8 is actually quite respectable. I did a benchmark of dhrystone on pic18, among other mcus. The XC8 free is on par with PICC18 pro, and XC8 pro is about 20% faster than PICC18 pro. I don't recall exactly which version of XC8 I used (could be 1.21).
Good to know, i have been compiling some small stuff, and when the compiler advertises to me and tell me how much more space I would have if I had the Pro version, I get kinda sad.. but I found the cure for it, so I'm in the clear. Didn't find any tool to disassemble the compiled code yet to see how it is, but I don't get those advertisements.
But according to how microchip people answers when they are asked, I guess they aren't going to keep it like this forever.
I'm on to 1.31 of XC8..
-
you wouldn't like if Ferrari put an lada carburettor in your Ferrari
I would actually love to get a Ferrari with a Lada engine in it, as long as I pay the Lada price.
Considering how ***much*** you paid for the free version, you should be happy too, :)
-
so likely a small community hangs around it.
Absolutely true.
To that frog sitting at the bottom of a well, the universe sure looks like the size of a pizza, :)
It is perfectly OK for that frog to think that. If a human thinks like that too, s/he in big trouble.
-
Sure, look at dangerousprototypes. It's the complete opposite of hackaday in that sense, as it features many PIC related projects. It's mainly the blog hosts there (Ian and other designers) use PICs , so likely a small community hangs around it.
And all projects popping up at Tindie, lately I have been observing lot of very interresting projects using pics, more than avr, where most of the projects are around the ardiuno platform.
-
you wouldn't like if Ferrari put an lada carburettor in your Ferrari
I would actually love to get a Ferrari with a Lada engine in it, as long as I pay the Lada price.
Considering how ***much*** you paid for the free version, you should be happy too, :)
Yeah, after my recent find, I'm more than happy :)
My initial post was just linking to the article others wrote about, and an person who did do disassembly, and mentioned in his conclusion that it looks like microchip are removing some of the things from the free-version. Hi-Tech had its reasons for this, and those was ok, since they were doing business on the compilers, not the silicon.
-
since they were doing business on the compilers, not the silicon.
I would be less focused on what they didn't offer for free. Instead, I would focus on what they did offer for free.
Microchip (or any other vendor) is not in the business of offering anyone high performance compilers for free. They are in the business of making money. You should be grateful that you offered you an opportunity to use their compilers for free, albeit with reduced performance.
Demanding them to give to you a high performance product for free would be a charity demanding that you give all of your bank accounts to it, after you have donated $20.
-
This thread is devolving into an PIC vs AVR flamewar...
-
TI has been stale for a while but not loosing ground. Motorola?? well maybe they get royalties or something, Zilog, Toshiba, etc, might be getting royalties as well.
Motorola?
In 1999 they first spun off and renamed their discrete semiconductor business as ON Semiconductor.
5 years later in 2004 their remaining IC semiconductor business, mainly microcontrollers was spun off and renamed Freescale Semiconductor. Freescale is still one of the world's largest MCU manufacturers as your list shows.
-
This thread is devolving into an PIC vs AVR flamewar...
Or, who can give people good compilers to make fully use of the silicon, after all, it's the silicon that gives money til Atmel and Microchip, I doubt there is that much revenue of selling compilers..
-
I just did a check. Under XC8 free, a program I wrote recently compiled to have 8 NOP instructions - out of about 2.5KB in size. and I put those instructions there myself. So the compiler inserted no NOP instructions in free mode into that particular program.
That same code compiled to about 1.7KB in pro mode.
So maybe "gerry" was right then but certainly not right for this particular version of XC8 (1.12).
You can maybe compile a few programs to see for yourself.
-
I doubt there is that much revenue of selling compilers..
Actually, most chip vendors offer paid compilers. Vendors that offer free, full featured compilers are mostly the low-end players.
-
Yes, have done that, compiled code for 16F877A that have 8192 words programspace this is kinda significant:
PRO mode:
Memory Summary:
Program space used EF6h ( 3830) of 2000h words ( 46.8%)
Data space used 2Ah ( 42) of 170h bytes ( 11.4%)
Free mode:
Memory Summary:
Program space used 1AE7h ( 6887) of 2000h words ( 84.1%)
Data space used 2Fh ( 47) of 170h bytes ( 12.8%)
Of course, this code is not very clever, if written better it wouldn't take so much space in the first place.
And, since you obviously did not read this post: http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/ (http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/)
This codeexample:
tmpPeriod=255;
Compiles to this in Free mode:
00C3 30FF MOVLW 0xFF
00C4 00F8 MOVWF 0x78
00C5 0878 MOVF 0x78, W
00C6 00F5 MOVWF tmpPeriod
And this in Pro mode:
00B5 30FF MOVLW 0xFF
00B7 00F7 MOVWF tmpPeriod
And there are more examples there, but no, it does not insert literally NOP statements, but those extra MOVWF/MOVF, I guess we could be without those?
Now, I don't have an disassembler at hand (any recommendations?) to check if it is like this also in 1.31..
-
I doubt there is that much revenue of selling compilers..
Actually, most chip vendors offer paid compilers. Vendors that offer free, full featured compilers are mostly the low-end players.
Or others providing compilers, like Silabs, that licenses other compilers that you can use for free, but you cannot use the full codespace (I have an c8051f990 project going, luckily the free compiler matches the memory space.. :) )
But it seems like most for Arm(ST, Atmel, TI.. ), Avr and Microchip you have free, or other good alternatives (gcc), for me, it's only that hitch about compilers that says this for every compile that I don't like much: "The MPLAB XC8 PRO compiler output for this code could be 2343 words smaller." But ofcourse, it's "only" to turn it into pro-mode..
But do you think Microchip earns most by selling silicon or software? (don't know if they have licenses of those bigger software libraries, that might change it all)
-
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)
http://www.eetimes.com/document.asp?doc_id=1280803 (http://www.eetimes.com/document.asp?doc_id=1280803)
(http://m.eet.com/media/1182386/20130430pcicinsightsmcu562.jpg)
-
it does not insert literally NOP statements,
So does or doesn't the free compiler insert nop instructions? :)
Maybe instead of inserting those nop instructions literally, the free compiler inserts those nop instructions "figuratively"? :)
I don't have an disassembler at hand (any recommendations?) to check if it is like this also in 1.31..
You don't need a disassembler to see the disassembly. The compiler "literally" does that for you, :)
-
But it seems like most for Arm(ST, Atmel, TI.. ), Avr and Microchip you have free, or other good alternatives (gcc), for me,
Of those you mentioned above, only Atmel offers "free" and full featured compiler, in atmel-avr.
TI's CCS is crippled (unless you use their launchpad); ST doesn't offer its own compiler; ARM offers a pretty expensive full-featured compiler. Microchip offered a full featured compiler, which in my view they should have paid their users to use it.
ARM chips have free and full featured compilers but not offered by the vendors - you may be able to argue that ARM actually "maintains" a free compiler but I think that's a stretch.
But do you think Microchip earns most by selling silicon or software?
You probably have to ask a Microchip insider for that. I don't think compiler sales are a big source for them in terms of revenue, but together with support, it could be meaningful profit.
I also think that they have little to gain from offering free full featured compilers: people who are too unwilling / unable to pay for a full featured compiler are unlikely to buy lots of chips. Think about for all the noise and self-importance of Arduino, what profits does Atmel get?
I think a big reason (and maybe the only reason) that Atmel offers a free full featured compiler is that gcc-avr was developed by others. It is a lot easier to offer other people's stuff for free to total strangers.
-
Based on these graphs it doesn't really look like 16 bits are declining although they had a peak in 2010
It is hard to reconcile that sentence to itself, :)
-
Based on these graphs
A much more interesting graph would be ASP for those three classes of chips.
-
Yes, have done that, compiled code for 16F877A that have 8192 words programspace this is kinda significant:
PRO mode:
Memory Summary:
Program space used EF6h ( 3830) of 2000h words ( 46.8%)
Data space used 2Ah ( 42) of 170h bytes ( 11.4%)
Free mode:
Memory Summary:
Program space used 1AE7h ( 6887) of 2000h words ( 84.1%)
Data space used 2Fh ( 47) of 170h bytes ( 12.8%)
Of course, this code is not very clever, if written better it wouldn't take so much space in the first place.
And, since you obviously did not read this post: http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/ (http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/)
These numbers look about right from my experience. If you take a look at the assembly used to implement various C functions you can, perhaps reduce the difference. The trick I used in one Pic16 project was replacing all the 'for' loops with functionally equivalent code using 'while' loops, quite a saving iirc.
Should you need to use such tricks? No, but you don't have to. Buy a bigger PIC for pennies more or pay for the pro compiler. Sure it would be great to have full optimisation but even without it there are ways of getting the job done.
This codeexample:
tmpPeriod=255;
Compiles to this in Free mode:
00C3 30FF MOVLW 0xFF
00C4 00F8 MOVWF 0x78
00C5 0878 MOVF 0x78, W
00C6 00F5 MOVWF tmpPeriod
And this in Pro mode:
00B5 30FF MOVLW 0xFF
00B7 00F7 MOVWF tmpPeriod
And there are more examples there, but no, it does not insert literally NOP statements, but those extra MOVWF/MOVF, I guess we could be without those?
Now, I don't have an disassembler at hand (any recommendations?) to check if it is like this also in 1.31..
I don't have 1.31 but previously: Window->Options->Disassembly Listing ... would show you the full assembly output.
-
From the example I ran, the pro did a lot of pruning of unused code.
-
I don't have 1.31 but previously: Window->Options->Disassembly Listing ... would show you the full assembly output.
Yes, Window > Output > Dissasembly listing file
Alternatively, there's also Window > PIC Memory Views > Program Memory (and select code from the combo box) .. you can save to file and all that. But the above is more convenient as it adds the C code as comments.
-
Based on these graphs it doesn't really look like 16 bits are declining although they had a peak in 2010:
According to this article, the 16 bit ones plateau
http://eecatalog.com/8bit/2014/01/31/microcontrollers-make-waves-in-automotive-and-internet-of-things/ (http://eecatalog.com/8bit/2014/01/31/microcontrollers-make-waves-in-automotive-and-internet-of-things/)
(https://www.eevblog.com/forum/microcontrollers/embeddedgurus-com-'an-open-letter-to-the-developers-of-the-mplab-ide'/?action=dlattach;attach=92017;image)
Edit: adding Figure 2 description from the article:
Figure 2: In terms of device shipments, 4/8-bit MCUs overtook 16-bit devices in 2013 to regain their historic position as the largest unit-volume category in the market. The outlook shows 4/8-bit MCUs remaining the largest unit-volume category in microcontrollers during the next five years, but 32-bit shipments are expect to be on the verge of taking the lead in 2018.
But yeah, the money per sale of the 8bit stuff is declining according to that article.
Edit: but the F (Forecast) years is like predicting the weather, they got it wrong on your article so why should they have it right on this one? But the figures up to 2013 are good and solid.
-
I've found that the standard libraries that come with XC8 aren't as fully featured as they were in C18. I was porting a project from C18 to XC8 and some sprintf stuff didn't exist anymore. The compiler itself seems better, though it has had a lot of teething issues that they've been steadily (if not particularly quickly) fixing.
But do I really mind? Not really. I can buy a PIC24 for the same price as the PIC18 I was using with better specs. Microchip clearly has target uses for their lines and the 8 bit stuff is steadily being pushed down in that matrix.
And it can't be stated enough that if you're serious about using a processor family, buy the tools. We're mixing the hobby market (volumes of 1-5?) with the concerns of... well any other market with volumes higher than that. Who gives a toss about code space, or even code execution speed. You just buy a slightly bigger device or run the clock slightly faster in those applications. Pick a vendor, use them consistently, buy the tools and the amount of time you'll save will vastly outweigh the minor problems.
-
MikroC Pro for PIC generates pretty good code for the little tests I've made.
-
Based on these graphs it doesn't really look like 16 bits are declining although they had a peak in 2010
It is hard to reconcile that sentence to itself, :)
I mixed up the 8 and 16 bit graphs, it was 8 bit with a peak in 2010.
-
Based on these graphs it doesn't really look like 16 bits are declining although they had a peak in 2010
It is hard to reconcile that sentence to itself, :)
I mixed up the 8 and 16 bit graphs, it was 8 bit with a peak in 2010.
You could have corrected it by saying that 16 bits had a peak in 2012.
8 bit like the retro arcades still have a lot of legs left :)
-
what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.
They're an artifact of the compiler design and the crap architecture of the 8-bit PICs. The compiler generates code before having allocated addresses for variables, so it must leave space for potential bank switches. The full compiler optimizes away the unneeded instructions in a later pass.
-
so, there was never a gcc-based tool chain for PIC? seems strange to me, that it was never done.
I would like to use PIC chips and have the same options I have with avr, but not being gcc-based (or fully free based) really annoys me. I'm not a corporation and can't justify licensing fees and any of that BS. I know gcc is not the best technology around, but its old, mostly understood (lol) and covers a lot of ground. lots of people have used gcc based tools for decades and we have come to trust them for any kind of use, light or heavy.
maybe I'm old school, but I know I can work with a project that uses gcc and makefiles.
-
"he full compiler optimizes away the unneeded instructions in a later pass."
A guess like that is easy to confirm: compile a piece of code in free and count the number of nop instructions.
I am always amazed that people are a lot more willing to regergitate what they heard from total strangers on the internet than to do their own (and simple) thinking.
-
so, there was never a gcc-based tool chain for PIC? seems strange to me, that it was never done.
The 8-bit PIC architecture is a very poor fit for GCC. Although it does support some odd-ball architectures, it's really designed for register-rich, orthogonal architectures.
Every once in a while someone brings up porting GCC for 8-bit PICs, but so far it's either proven too difficult or no-one's been serious about it.
-
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 :)
-
if there is a thread for this month, this is it. the most derailed and the most successfull troll ever. (i skipped several pages but...) surprisingly nobody spotted that the original link is a retarded mental by "the so called guru but in fact a not guru from the look of his arguments" talking about the wrong troll? instead of discussing a retarded guru everybody went discussing retarded avr vs pic issue that wasted many hours of people's time. i dont know who is this Nigel Jones and whats his problem with Microchip. no split window? need make file? the funniest thing is... breakpoint where it isnt. dude! as an advice, dont sniff a pot and write something in your official page! its just too embarassing. why this type of open letter troll got "not moved to general" from mcu section is out of my head.
-
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++.
-
so, there was never a gcc-based tool chain for PIC? seems strange to me, that it was never done.
SDCC which is an open source GCC-ish compiler has some support for 8 bit PIC. The problem with PIC (and other archaic architectures like the 8051) is that they where never designed with using C as a programming language in mind. Their Harvard architecture, short stacks and banked memory make it hard to apply the flat memory model C is using. It takes a large amount of effort to make a C compiler for these kind of processors and even the commercial ones only implement a subset of the language.
GCC is never intended to support these kind of architectures. IMHO GCC is not a poor man's choice either. The GCC compiler will give most commercial compilers a run for their money. Many processor manufacturers help to improve GCC for their CPUs. Even SDCC performed better for the 8051 than a commercial compiler I bought (15 years ago). The biggest difference between a commercial compiler and GCC is the availability of optimised libraries and a slick looking IDE to get started quickly.
-
I have not looked inside gcc, but I thought it would follow a 2 (at least) phase process; parsing c code into some middle abstraction, then generating code from that, for the target cpu. are you saying that those 2 conceptual phases are not clean, in gcc's architecture? (I'm not a compiler back-end expert so I don't know how hard it would be; but I always thought that compiling a high level language would have nothing at all to do with how the processor implements it. c flat model? what do you mean by that? c is just a language and it does not force any binary generated code concepts over than pushing stuff to a stack before a call, etc etc. not sure why C is 'hard' for some cpus, but there must be some subtle details I'm not seeing, in how gcc is actually implemented.
in general, I do find it hard to understand why a high level language would, at all, be 'easier' on some cpus than other. code gen is code gen and of course, you need a code generator and optimizer for each different cpu arch. so what?
-
I have not looked inside gcc, but I thought it would follow a 2 (at least) phase process; parsing c code into some middle abstraction, then generating code from that, for the target cpu. are you saying that those 2 conceptual phases are not clean, in gcc's architecture? (I'm not a compiler back-end expert so I don't know how hard it would be; but I always thought that compiling a high level language would have nothing at all to do with how the processor implements it. c flat model? what do you mean by that? c is just a language and it does not force any binary generated code concepts over than pushing stuff to a stack before a call, etc etc. not sure why C is 'hard' for some cpus, but there must be some subtle details I'm not seeing, in how gcc is actually implemented.
in general, I do find it hard to understand why a high level language would, at all, be 'easier' on some cpus than other. code gen is code gen and of course, you need a code generator and optimizer for each different cpu arch. so what?
Let's put it this way: for 8 bit architectures like 8051 and PIC you can't use the 2 phase approach if you want to create efficient code. The compiler needs to look what kind of C construct is used and translate that into something which can be used on the PIC or 8051. One thing C compilers for 8 bit architectures do is trace which function is called from where and create a fixed memory location for all variables which are supposed to be on the stack. This is called an overlay to emulate a stack. For that the compiler has to figure out which execution paths exist (main process, IRQ processes, re-entrant functions). It gets really hairy when a function is called from both the main process and an IRQ. And that is just one of the challenges. Another problem is banked memory. The compiler has to figure out where a pointer can point to and determine it needs to add information to the pointer which kind of memory it points to or not. And produce code which can deal with such a pointer. Creating such a compiler is an art in itself.
edit: typos
-
... The compiler has to figure out where a pointer can point to and determine it needs to add information to the pointer which kind of memory it points to or not. And produce code which can deal with such a pointer. Creating such a compiler is an art in itself.
Every first class compiler is a work or art, none of them is 'trivial', and each architecture has its idiosyncrasies. Here is a sample list of gcc optimizations taken from this article http://www.linuxjournal.com/article/7269 (http://www.linuxjournal.com/article/7269)
(http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/072/7269/7269t1.jpg)
-
I actually bothered to test this theory. I have a medium size commercial project developed with the free version of C18. There are no NOPs, except where I explicitly put them. The compiler doesn't generate NOPs by itself. This is targeting a PIC18.
Does it need to be EXACT NOP statements?
C code:
tmpPeriod=255;
Compiles to this in Free mode:
00C3 30FF MOVLW 0xFF
00C4 00F8 MOVWF 0x78
00C5 0878 MOVF 0x78, W
00C6 00F5 MOVWF tmpPeriod
And this in Pro mode:
00B5 30FF MOVLW 0xFF
00B7 00F7 MOVWF tmpPeriod
Those two MOV statements:
00C4 00F8 MOVWF 0x78
00C5 0878 MOVF 0x78, W
Are those usefull?, other than wasting and cycles? Are they anything other than an NOP? (which also only exist for same purpose?)
-
Does it need to be EXACT NOP statements?
That (the use of NOP) was the accusation here. So yes.
Are those usefull?,
They are not useful in that particular case.
Can they be useful? Yeah.
an NOP? (which also only exist for same purpose?)
An NOP can exist for a lot of valid reasons.
-
I would say you are nit-picking a bit now :), NOP instruction is useful on its own (it can be for word alignement on cpu's that benefits that, can be to make correct delay loops etc).
Those mov instructions are ofcouse useful where you need them, but inserted as is now, not so. And if it was nop or those mov instructions, same-same, they just take space and cycles. Similar to the earlier Goto tricks that was used, but that is now removed.
Anyway, it gets better.. Found the disasembly function for the code in mplab, seems like lot of dead code are removed as you also found, will try to compare some code similar to those used in the article I linked, to see if it is like this on the 1.31 compiler.
-
they just take space and cycles.
As pointed out earlier, you probably want to step back and see a bigger picture. The compiler, in the initial steps of translating C to assembly, is simply putting canned pieces (template) to each sentence. It is quite feasible to understand that those canned pieces are designed to be generic, thus ****necessarily**** inefficient (so that they will work under all conditions). The inefficiency is less of a concern as it can be addressed with the optimizer later.
You are arguing that those templates are designed ****purposefully**** or even ****punitively**** inefficient. I think you have a very high hurdle to hit, particularly for the latter.
-
Just to add: the same inefficiencies can be observed in other compilers too.
-
Rather then to push it off as some kind of evil malfeasance, could it not just be the fact that the 'free version' just lacks or turns off all compiler optimization functions, and the for fee pro version allows for enabling the various optimization options.
Complaining that the free version is not as feature rich as the pro version seems a little strange to me. Now if the pro version with all optimization options turned off still generates 'better code' then the free version, then maybe there is something to complain about, but is that indeed the case?
-
Rather then to push it off as some kind of evil malfeasance, could it not just be the fact that the 'free version' just lacks or turns off all compiler optimization functions, and the for fee pro version allows for enabling the various optimization options.
It has always been clearly stated that the free version has limited optimizations, it's only crazy people that claim they're intentionally sabotaging their own compiler.
-
could it not just be the fact that the 'free version' just lacks or turns off all compiler optimization functions,
I think it is clearly communicated, but may not have been as clearly understood by some, that the free version has no optimization (either from day 1 or after a period of time).
Complaining that the free version is not as feature rich as the pro version seems a little strange to me.
I think people have migrated to suggesting (?) that NOPs or similar "waste-of-time" instructions have been intentionally added to the free version with the express / sole(?) purpose of degrading its performance.
I haven't seen much proof for such an argument, and I find it logically difficult to understand from a chip vendor's perspective.
-
it's only crazy people that claim they're intentionally sabotaging their own compiler.
Particularly when you are in the business of (also) selling chips. Slowing down your own compiler, thus your chips, makes no sense to me.
-
it's only crazy people that claim they're intentionally sabotaging their own compiler.
Particularly when you are in the business of (also) selling chips. Slowing down your own compiler, thus your chips, makes no sense to me.
Was not implying that, after all, the compiler came from someone who was selling compilers, not silicon.. but since they now are bought buy the silicon vendor, some forgets the origin, and complains about that. (me also, probably, before understanding the fact)
-
It's a while ago so I may be misremembering, but I think that before Microchip bought Hitech, Hitech's free version was code-size and/or device limited, with normal optimisations, so the de-optimising was a later change after Microchip bought it.
-
the compiler came from someone who was selling compilers, not silicon.
Google Hi-tech OCG.
and / or Hi-tech's Lite license for its compilers.
And if you are interested, get a pre-OCG compiler (9.60 std or pro or even 9.65) and compare its code generation vs. post-OCG compilers.
-
Rather then to push it off as some kind of evil malfeasance, could it not just be the fact that the 'free version' just lacks or turns off all compiler optimization functions, and the for fee pro version allows for enabling the various optimization options.
It has always been clearly stated that the free version has limited optimizations, it's only crazy people that claim they're intentionally sabotaging their own compiler.
IMHO its crazy people use controllers for which no good free compiler is available. The last time I used a commercial compiler was 20 years ago. And even that one was given away for free by the distributor selling the controllers. A free 'crippled' compiler is just a gold plated turd.
-
https://en.wikipedia.org/wiki/Microchip_Technology#HI-TECH_Software (https://en.wikipedia.org/wiki/Microchip_Technology#HI-TECH_Software)
HI-TECH Software
HI-TECH Software is an Australian-based company that provides ANSI C compilers and development tools. Founded in 1984, the company is best known for its HI-TECH C PRO compilers with whole-program compilation technology, or Omniscient Code Generation (OCG).[14][15] HI-TECH Software was bought by Microchip on 20 February 2009,[16] whereupon it refocused its development effort exclusively on supporting Microchip products.[17]
Supported manufacturers and architectures
Microchip Technology PIC10, PIC12, PIC14, PIC16, PIC18, PIC24, PIC32 and dsPIC
HI-TECH Software has also provided compilers for the following manufacturers and architectures, but none of them are advertised since the Microchip acquisition:
Cypress Semiconductor PSoC
Silicon Laboratories
8051
Z80 for CP/M [18] and Z80 cross compiler.
http://electronicdesign.com/embedded/whole-program-c-compiler-optimizes-across-modules (http://electronicdesign.com/embedded/whole-program-c-compiler-optimizes-across-modules)
Whole Program C Compiler Optimizes Across Modules
Apr 27, 2007 William Wong | Electronic Design
Splitting applications into small modules is critical to building a manageable application, but most development systems only optimize code within a module. HiTech Software's new crop of PICC-18 PRO C compilers and linkers cross this boundary and do optimization by looking at the entire program. This can be especially critical for optimizations like dead code elimination, register parameters, and inlining. It allows the system to use information in one module to optimize how another is used.
The resulting optimization when looking at the whole program can be significant. Hi-Tech's approach can often cut a program's size by 50%. Often, this is the result of leaving out unnecessary code. For example, the commonly used print function can format text for everything from characters to double-precision floating point. Significant savings are possible if the latter isn't required. Hi-Tech's approach can detect what parameters are used and eliminate the unneeded code. Pricing starts at $1195.
www.htsoft.com (http://www.htsoft.com)
Hi-Tech Omniscient Code Generation whitepaper: http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.pdf (http://www.htsoft.com/news/070309_Whitepaper-OmniscientCodeGeneration_FINAL.pdf)
Omniscient Code Generation
A whole-program compilation technology for superior code density and performance
by Clyde Stubbs
CEO and Founder, HI-TECH Software
-
its crazy people use controllers for which no good free compiler is available.
Yeah. That's why I never hire good programmers who are not free, :)
If you need an example of people going against their self-interest, you need to look no further.
-
its crazy people use controllers for which no good free compiler is available.
Yeah. That's why I never hire good programmers who are not free, :)
If you need an example of people going against their self-interest, you need to look no further.
So Microchip should make money from their compiler and not their chips? Even the FPGA vendors are giving away their development tools for free. Why is Microchip so far behind?
-
it could just be that the company is slow to change and realize what is a cost center and what is a profit center.
not every company can admit that things have changed and change themselves, internally, to support it.
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).
-
IMHO its crazy people use controllers for which no good free compiler is available. The last time I used a commercial compiler was 20 years ago. And even that one was given away for free by the distributor selling the controllers. A free 'crippled' compiler is just a gold plated turd.
This.
-
Joining a bit late, but anyway, the op article is of course severely flawed and written by someone who didn't spend more than 60 minutes with mplab back in 2011. And didn't bother to check whether his complaints were factual or not.
Anyway, MPLAB (X) today still isn't great, I think mostly due to their mistake of choosing the poor and outdated Java platform. It's a memory hog and very slow. I'm sure they can do better than that.
But all in all, it does work and it does the job once you get used to it. The PICKIT3 is still a bit wonky though, if you want to work with their older 8 bit devices etc, better make sure you still have a PICKIT2 around.
-
Even the FPGA vendors are giving away their development tools for free.
Unless it's changed recently, you still have to pay if you want to use the newest and largest devices.
Anyway, MPLAB (X) today still isn't great, I think mostly due to their mistake of choosing the poor and outdated Java platform. It's a memory hog and very slow.
That's more a problem with Netbeans than Java. There's plenty of well-performing Java software.
-
...
That's more a problem with Netbeans than Java. There's plenty of well-performing Java software.
You are probably right, but still Netbeans is primarily Java, so same thing to me :)
Sun did nice C innovations with Java but didn't win the battle.
-
So Microchip should make money from their compiler and not their chips?
Microchip should make money from whatever they like. None of my business or your business how they make money; I only care at end of the day if they offer me value for my money.
Even the FPGA vendors are giving away their development tools for free.
Not sure what "the FPGA vendors" you are referring to. But plenty of them charge plenty of money for their development tools. You would know this if you did even superficial amount of work on FPGA.
Why is Microchip so far behind?
Following the herd is the strategy one takes if one cannot think for themselves.
-
I'd really like all my tools to be gcc-based so that I don't have to keep relearning stuff needlessly.
Two ways to get you there:
1) make yourself the center of the universe;
2) if that doesn't work, write your own gcc-based compilers.
If 2) doesn't work out for you, pray that somebody else does it for you.
Insisting that others do it for you doesn't get you anywhere, unless 1) is true.
-
So Microchip should make money from their compiler and not their chips? Even the FPGA vendors are giving away their development tools for free. Why is Microchip so far behind?
The Microchip compilers used to be cheap. About $500 for a perpetual license, support, and updates.
After the Hi-Tech acquisition they got more expensive, with an obnoxious licensing and activation scheme and a 'High Priority Access' support subscription that no one knows what you get for paying it other than free major updates of where there hasn't been one so far.
This idiocy seems to have been inherited from Hi-Tech, it really feels like who ever was responsible at Hi-Tech for the Microchip acquisition (which scrapped all Hi-Tech products except the two 8 bit Microchip compilers) is in charge of the compiler department at Microchip.
-
(which scrapped all Hi-Tech products except the two 8 bit Microchip compilers)
Yeah, didn't HiTech make compiler for other platforms to?, what happened to those?
-
IMO one of Microchips strong points is that you can easily and cheaply get really old chips from them.
And of course they do have total domination on the 16 bit segment. Nothing I know of can compete with their PIC24 series in 16 bits price/performance.
-
I'd really like all my tools to be gcc-based so that I don't have to keep relearning stuff needlessly.
Two ways to get you there:
1) make yourself the center of the universe;
2) if that doesn't work, write your own gcc-based compilers.
If 2) doesn't work out for you, pray that somebody else does it for you.
Insisting that others do it for you doesn't get you anywhere, unless 1) is true.
:-DD :-DD :-DD :-DD :-DD :-DD
:clap:
-
that's bullshit.
I'm not going to waste any time WRITING a tool FOR some damned vendor. fark that! if the vendor does not want to compete, fine, I will use the other guy.
the whole compiler MESS with mcp just turns me off and since there are cleaner solutions for me, I will go with them. its just that simple, folks. make the tools work smooth for me and I'll consider your hardware products. make the tools harder and less standard (compared to what many users already are familiar with and trained on) and you get less of our business.
its one reason cisco eats everyone else's lunch. the training base is there on cisco gear (as an example) and once people are trained on a tool set, they tend to want to keep using that set.
-
The tools work smooth and the compiler is as standard as it can be, and it is free and good. You're just throwing a hissy-fit because you don't get the best/"ultimate" version of the compiler.
The IDE is free, it's good, it's based on Netbeans so it can be easily improved by third party developers.. the compiler works just fine.
At the end of the day, if you're making a product that sells in tens of thousands or several products, you're not going to care about a one-time fee of $1000, the cost of the premium version. If you make something that sells in 10k and by using the premium version you can reduce the size of your code to fit into a PIC that costs 10 pennies less in volume, then you've basically recuperated the money for the compiler.
If you're a hobbyist, you can use the free version and if you find it produces too "loose" code, you can either choose a bigger sized PIC chip (there's loads of choices) or use a third party compiler.. you have MikroC (http://www.mikroe.com/mikroc/) (about 249$), CCS (http://www.ccsinfo.com/content.php?page=compilers) (command line compilers starting from only $50!)... you don't HAVE to pay $1000 to get the absolute smallest code or most efficient one out there.
You have CHOICES.
Same as with Atmel chips (AVR) ... you have the free gcc based compiler which may or may not be the best, but you can also pay 1500$ for Crossworks for AVR (http://www.rowley.co.uk/avr/) or 200$ for MikroBasic PRO for AVR (http://www.mikroe.com/mikrobasic/avr/) or other AVR solutions... or anything in between.
-
the whole compiler MESS with mcp just turns me off
Or you just cannot handle it.
make the tools work smooth for me and I'll consider your hardware products.
A little bit too much self-importance? I don't think they care about you, or even have heard of you there.
they tend to want to keep using that set.
I guess that's why CISCO is losing market share fast, :)
-
why do you keep insisting on trying to make this about 'me' ?
clearly, there are others who feel the same way I do. we don't want to have a separate compiler for each damned product or chip. that is not sensible and if you don't -have- to deal with a different tool chain, why should you?
its just that simple, danny. and please, stop with the attempt to personalize this. its not a very good argument style and its not appreciated, ok?
-
Why do you say "we"? You're not the spokesperson of anyone here. It's just your opinion.
You don't have a separate compiler for each damned product or chip. Microchip has a compiler for all 8 bit microcontrollers, one for all their 16 bit microcontrollers and one for all of their 32 bit microcontrollers.
I don't want one compiler for everything... the old expression Jack of all trades, master of none (http://en.wikipedia.org/wiki/Jack_of_all_trades,_master_of_none) is perfectly valid here.
Microchip sells a product, and makes everything clear. If you don't like a product you don't have to purchase it. You're free to express your opinion, but that doesn't mean your opinion is correct.
-
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. for any linux user, it could not be easier (apt-get install arduino). no dumbed down versions to worry about, no upgrade troubles (apt-get will keep your apps updated), always staying at a reasonably current version and ability to install freely anywhere you want, even built from source. there is no such analog in the mcp world (is there?). and so, for an opensource hw/sw person, the gcc and apt-get way is the path of least resistance and just the obvious choice if I had to choose between this and some very custom vendor-specific set of compiler tools.
note, I'm not crediting atmel, necessarily, for any of this and I'm not necessarily blaming microchip. I'm simply saying that if I'm doing open source development, the first thing I'd choose is the standard easy toolchain that is free in every sense of the word and has quite usable performance, both as a tool and as generated output code. for open source projects, its rare that an atmel or arduino-compatible chip isn't enough to solve your controller problem. if you need more power, many will jump right up to an embedded linux board of some kind and skip all middle steps (these days, those linux boards are arm chips).
that covers the spectrum for embedded use. atmel 'open' chips for low end and linux single board small systems for stuff that goes between the lower end and full blown unix hosts.
-
So by your reasoning, if I make a revolutionary 8bit microcontroller tomorrow, I shouldn't sell it or people shouldn't use it simply because linux distributions don't have ready make packages for beginners like you, or because gcc doesn't support yet this revolutionary architecture?
The 8bit PICs are a different architecture, with various quirks and differences that makes it very difficult for someone to adapt gcc to compile binaries to this architecture. GCC simply isn't capable of compiling code for it now, just as I'm sure there's lots of other 4bit and 8bit and x bit microcontrollers that gcc doesn't support. GCC isn't the "ultimate" compiler out there.
for any linux user, it could not be easier (apt-get install arduino). no dumbed down versions to worry about, no upgrade troubles (apt-get will keep your apps updated), always staying at a reasonably current version and ability to install freely anywhere you want, even built from source. there is no such analog in the mcp world (is there?). and so, for an opensource hw/sw person, the gcc and apt-get way is the path of least resistance and just the obvious choice if I had to choose between this and some very custom vendor-specific set of compiler tools.
Yeah, let's settle on the most generic compiler out there, that makes the most generic binary, that has the most average optimizations, every microcontroller should work the same because you're too lazy to actually download some source code and compile it to a binary and install it with provided scripts. Every chip manufacturer shouldn't do something innovative that may just make their chips not compatible with the plain boring generic gcc or some other open source chain because user linux-works won't be able to say apt-get install arduino anymore.
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?
Why does this surprise you? You may have to. It all depends on the architecture of those chips, and how well those architectures are suited for what's out there, for open source compilers, linkers, debuggers.
If Microchip doesn't have the man hours to contribute to gcc to make something happen, if people all over the world don't contribute to gcc to make it happen, you have no choice. gcc doesn't make itself, people contribute code to it
Also, lots of these small lightweight microcontrollers are cheap and simple, universal/standard features like JTAG to debug and program would make the die of the chip too large and potentially make the chips commercially un-viable. See for example PIC10F200 (http://www.digikey.com/product-detail/en/PIC10F200T-I%2FOT/PIC10F200T-I%2FOTCT-ND/665887), which has only 6pin and 384 bytes of program space... you seriously expect something like this to have universal debugging or some other silliness? GCC is so big and optimized for bigger architectures with more registers and memory that it couldn't even compile something considering the restrictions of such a chip.
-
I use MPLAB X as well as Atmel Studio and find overall they are both ok. There are things that I don't like about each, but they are not show stoppers. I simply use the (free) tools and get on with the job at hand. :)
-
I like mikroC although its stupid at times:
;MyProject.c,11 :: digits[0] = digits[1] = digits [2] = '0';
0x0018 0x3030 MOVLW 48
0x0019 0x00F3 MOVWF R1+2
0x001A 0x3030 MOVLW 48 ; No need
0x001B 0x00F2 MOVWF R1+1
0x001C 0x3030 MOVLW 48 ; No need
0x001D 0x00F1 MOVWF R1
vs MPLAB X
93: digits[0] = digits[1] = digits [2] = '0';
0016 3030 MOVLW 0x30
0017 00F7 MOVWF 0x77
0018 00F6 MOVWF 0x76
0019 00F4 MOVWF 0x74 ; no need
001A 0874 MOVF 0x74, W ; no need
001B 00F5 MOVWF digits
Although MPLAB X is stupid too:
95: digits[2]++;
0020 3001 MOVLW 0x1
0021 00F4 MOVWF 0x74 ; no need
0022 0874 MOVF 0x74, W ; no need
0023 07F7 ADDWF 0x77, F
vs mikroC
;MyProject.c,13 :: digits[2]++;
0x0022 0x0AF3 INCF R1+2, 1
Seems like MPLAB X doesn't know the PIC12 can do increments so it does it the hard way and putting those extra moves :-//
but mikroC can be retarded too:
;MyProject.c,22 :: digits[0] += in_val;
0x002E 0x0842 MOVF main_in_val_L0, 0
0x002F 0x0771 ADDWF R1, 0
0x0030 0x00F0 MOVWF R0
0x0031 0x0870 MOVF R0, 0
0x0032 0x00F1 MOVWF R1
sure I'm using index 0 of the array, so why doesn't it know it's the first element instead of doing the superfluous indexing?
The thing is compilers are not that great, they waste space and cycles, nothing new there since they keep producing versions that are 10% better than the previous one, meaning they are not close to be ideal by any standard.
Best compiler out there is the Intel one, but that's for x86 systems and they are still improving it.
For big projects C++/C is a necessary evil, you couldn't cope doing it all in assembly. but for PIC12 you do have a choice, assembly is really not that hard and PIC12's branching is as hard and unintuitive as any mcu assembly can be.
-
why do you keep insisting on trying to make this about 'me' ?
Because you are participating in this conversation? Tough to have a conversation with people who aren't here.
we don't want to ...
We? Who is "we"? When did you appoint yourself the spokesperson for other people?
...have a separate compiler for each damned product or chip.
That's a great way to kill innovation - including your beloved avr.
-
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/ (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..
-
Like GCC there's no IAR compiler for PICs though.
They did support some PICs for a while.
These IAR page showed up using Google:
http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-PIC18/Product-packages/ (http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-PIC18/Product-packages/)
IAR Embedded Workbench® for PIC18 is available in standard and limited editions.
http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-dsPICPIC24/Product-packages/ (http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-dsPICPIC24/Product-packages/)
IAR Embedded Workbench® for dsPIC is available in standard and limited editions.
But this info isn't valid any more? IAR doesn't actually offer these PIC18 and dsPIC/PIC24 compilers anymore?
It's not mentioned in their list of supported manufactures/architectures in the list on the left.
I wonder why they would retire it again? Too many bugs or too few who bought it?
-
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-4216 (http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/#comment-4216)
mlp 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?
-
There is still a wide spread use of horse & carriage among the Amish....
-
LOL! but yeah, i'm pretty sure you missed the term "widespread use" hardly applies to them secluded types!
-
The Trabant had 'widespread' use. Not to bothered about the compiler but how the IDE performs ...
-
The Trabant had 'widespread' use. Not to bothered about the compiler but how the IDE performs ...
awwww! how sweet! I totally want one!!!! but yeah, think your missing the point. The architecture might be old but it's far from obsolete. There might be newer things capable of doing better but there is so much produced by that reliable old architecture that it's really worth learning.
You guys just can't stop squawking, can you.
why not, it's fun!
-
The Trabant had 'widespread' use. Not to bothered about the compiler but how the IDE performs ...
awwww! how sweet! I totally want one!!!! but yeah, think your missing the point. The architecture might be old but it's far from obsolete. There might be newer things capable of doing better but there is so much produced by that reliable old architecture that it's really worth learning.
Major :palm:
Why try to do things the hard way when there is an easy way? I really don't get why people would want to start or keep using the 8 bit PICs or 8051. Maybe some secluded types who like to play with vintage stuff... I would have given my left nut and then some for an ARM based microcontroller when I started out with microcontrollers (8051, Z80, 68HC11) over 20 years ago. The possibilities are infinite nowadays. So much cool technology to play with these days that it is almost a crime punishable by death to stick with the obsolete stuff O0
I'm starting to become a bit of an old fart and I really envy the possibilities younger people have nowadays to make really cool electronics in their attic or shed. I didn't had that when I started to tinker with electronics. I had to buy parts piece by piece from a local electronics store which didn't had a very large assortment and scrape information together from books from the library and look hard to score a datasheet book with information on interesting chips.
-
Like GCC there's no IAR compiler for PICs though.
They did support some PICs for a while.
These IAR page showed up using Google:
http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-PIC18/Product-packages/ (http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-PIC18/Product-packages/)
IAR Embedded Workbench® for PIC18 is available in standard and limited editions.
http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-dsPICPIC24/Product-packages/ (http://www.iar.com/Products/IAR-Embedded-Workbench/Microchip-dsPICPIC24/Product-packages/)
IAR Embedded Workbench® for dsPIC is available in standard and limited editions.
But this info isn't valid any more? IAR doesn't actually offer these PIC18 and dsPIC/PIC24 compilers anymore?
It's not mentioned in their list of supported manufactures/architectures in the list on the left.
I wonder why they would retire it again? Too many bugs or too few who bought it?
I think they keep it available for projects that need maintenance, but is not actively marketed.
I heard that the problem is there wasn't much interest in the product as Microchip did not support it.
-
I really don't get why people would want to start or keep using the 8 bit PICs or 8051. Maybe some secluded types who like to play with vintage stuff... I would have given my left nut and then some for an ARM based microcontroller when I started out with microcontrollers (8051, Z80, 68HC11) over 20 years ago. The possibilities are infinite nowadays. So much cool technology to play with these days that it is almost a crime punishable by death to stick with the obsolete stuff O0
I don't know of anyone who uses an actual i8051 or 80C51 or 87C51, but the modern variants (such as the Silicon Labs devices) are pretty great -- lots of flash for program store (no need for the external EPROM), lots of RAM, lots of peripherals including ADCs and DACs, and even USB.
They're certainly not the 87C51 which was the basis of my university senior design project.
Having said that, lots of ARM Cortex parts are cheaper.
-
I have some legacy products at work that use 8051 but nothing new. That's all NXP arms. However I feel like I don't actually understand the modern 8051 landscape very well. I know the core goes into a lot of very modern micros and it's still used a lot, but I don't really know who uses them and why they do, aside from the "no core royalty makes them cheap" argument. Again, what does that cost? I don't know because I'm not plugged into that at all.
Seems like most core arguments are mostly a question of familiarity and much less about what the actual differences are.
-
I don't really know who uses them and why they do, aside from the "no core royalty makes them cheap" argument.
Royalty is minimum: the arm royalties are in the pennies per chip.
Seems like most core arguments are mostly a question of familiarity and much less about what the actual differences are.
I think it is primarily a marketing and software thing: ARM is all the rage, not necessarily because it is that much faster, low consumption or more reliable, etc. It is just in, for some reasons so you observe lots of herd behaviors on that.
From a software perspective, 8051 has one of the largest installed base so lots of projects can be easily recompiled on newer / faster 8051 cores and you are ready to go.
-
I have some legacy products at work that use 8051 but nothing new. That's all NXP arms. However I feel like I don't actually understand the modern 8051 landscape very well. I know the core goes into a lot of very modern micros and it's still used a lot, but I don't really know who uses them and why they do, aside from the "no core royalty makes them cheap" argument. Again, what does that cost? I don't know because I'm not plugged into that at all.
Seems like most core arguments are mostly a question of familiarity and much less about what the actual differences are.
couple of examples out of many:
http://www.atmel.com/Images/doc4109s.pdf (http://www.atmel.com/Images/doc4109s.pdf)
http://www.cypress.com/psoc3/?source=CY-ENG-HEADER (http://www.cypress.com/psoc3/?source=CY-ENG-HEADER)
-
I have some legacy products at work that use 8051 but nothing new. That's all NXP arms. However I feel like I don't actually understand the modern 8051 landscape very well. I know the core goes into a lot of very modern micros and it's still used a lot, but I don't really know who uses them and why they do, aside from the "no core royalty makes them cheap" argument. Again, what does that cost? I don't know because I'm not plugged into that at all.
An 8051-variant vendor doesn't need to pay Intel a royalty for intellectual property. ARM is not a manufacturer; they hold the IP and license it to anyone willing to pony up for it. I'm not sure that such lack of royalty in itself makes the 8051 significantly less expensive than ARM, for example. In fact, just scan some price lists and you'll see that many well-outfitted ARMs are cheaper than some 8051s.
Seems like most core arguments are mostly a question of familiarity and much less about what the actual differences are.
That's often the case.
But look at it this way: if you've sprung for the Keil 8051 toolset and your applications are not strictly cost-sensitive (that is, you're not selling lots of product per month), why not continue to use the old familiar? It works, you have the tools and as such your development time is reduced.
In these cases, you'd consider an alternate device family if you need more horsepower or peripherals which your preferred family doesn't have.
If you're starting from tabula rasa, then I'd say look at ARMs and skip the 8051.
-
I really don't get why people would want to start or keep using the 8 bit PICs or 8051. Maybe some secluded types who like to play with vintage stuff... I would have given my left nut and then some for an ARM based microcontroller when I started out with microcontrollers (8051, Z80, 68HC11) over 20 years ago. The possibilities are infinite nowadays. So much cool technology to play with these days that it is almost a crime punishable by death to stick with the obsolete stuff O0
I don't know of anyone who uses an actual i8051 or 80C51 or 87C51, but the modern variants (such as the Silicon Labs devices) are pretty great -- lots of flash for program store (no need for the external EPROM), lots of RAM, lots of peripherals including ADCs and DACs, and even USB.
They're certainly not the 87C51 which was the basis of my university senior design project.
Having said that, lots of ARM Cortex parts are cheaper.
NXP, Infineon, et al have sold 8051 with lots of peripherals for several decades. No matter how much you beef up an 8051 an ARM always does a lot more per MHz than an 8051 especially if you need to move memory around or work with numbers which are larger than 255. Recently I got a re-design project where people tried to do some heavy signal processing with an 8 bit PIC... They choose it because they knew it and didn't look for a better fit :palm: Sticking with what you know is OK but try to get to know something which doesn't run out of steam going up the first hill OR know your limits.
-
I really don't get why people would want to start or keep using the 8 bit PICs or 8051. Maybe some secluded types who like to play with vintage stuff... I would have given my left nut and then some for an ARM based microcontroller when I started out with microcontrollers (8051, Z80, 68HC11) over 20 years ago. The possibilities are infinite nowadays. So much cool technology to play with these days that it is almost a crime punishable by death to stick with the obsolete stuff O0
For a lot of projects this is true. But imaging if you need a very small micro-controller for say a automated air fresher. You don't care about speed or ease of coding, architecture efficiency, and if it's mains plug in then the power consumption is not a concern. You just care about cost.
I think small 8-bitters are always going to be cheaper for the silicon fab to produce, with less gates the yields are better and less testing time required. Additionally zero royalty's. Every cent counts.
-
I think small 8-bitters are always going to be cheaper for the silicon fab to produce, with less gates the yields are better and less testing time required.
On the other hand, more modern micros are probably manufactured using a more modern process and with a smaller feature size, offsetting the transistor count (though most area will be RAM and flash anyway).
royalty's
Grr.
-
Are you willing to design something like a ARM core, develop all the compiler crap associated with a new architecture, then support,maintain and update the design, all that for free?
Oh, corporations are so bad, charging for the work they do, how dare they
-
If the big, bad corporation wants to sell their ARM core, they may want to consider giving away a decent set of tools to use their fancy, new ARM core. Big, bad corporations make money when people but their stuff. People tend to buy stuff that has good support; free or reasonably priced.
-
If the big, bad corporation wants to sell their ARM core, they may want to consider giving away a decent set of tools to use their fancy, new ARM core. Big, bad corporations make money when people but their stuff. People tend to buy stuff that has good support; free or reasonably priced.
I would agree. That philosophy seems to have worked very well for Microchip. Microchip has always had free or a very cheap tool chain for their micros.
:wtf: Please point me to Microchip's free C compiler for 8 bit PICs!
-
:wtf: Please point me to Microchip's free C compiler for 8 bit PICs!
Here you go: http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/#optimization-levels (http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/#optimization-levels)
-
Don't like MPLAB X? Here's some more for MPLAB 8........
http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html (http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html)
and Hi-Tech C
ftp://ftp.microchip.com/ (ftp://ftp.microchip.com/)
-
:wtf: Please point me to Microchip's free C compiler for 8 bit PICs!
Here you go: http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/#optimization-levels (http://www.microchip.com/pagehandler/en_us/devtools/mplabxc/#optimization-levels)
Free crippleware :palm: No thanks :--
-
-:wtf: Please point me to Microchip's free C compiler for 8 bit PICs-
I fail to understand your use of profanity here. If you have a point, lay it our.
the use of profanity doesn't make you any smarter or more manly, or your point stronger.
-
Profanity is his substitute for an argument. The fact you get a completely functional compiler for zero dollars doesn't jive with his personal view of Microchip.
-
That guy is always bashing Microchip.
I don't mind Microchp / Atmel / anyone bashing. But one should at least have a point.
-
Profanity is his substitute for an argument. The fact you get a completely functional compiler for zero dollars doesn't jive with his personal view of Microchip.
A compiler without optimisation is not a compiler. It is crippleware because you can't use it for any serious project. Hence there is no free C compiler for 8 bit PIC. Hence Microchip's success doesn't come from providing free tools.
-
Does profanity = butthurt these days? (butthurt is a term we use in the military that equates to waaaahhhh or any other term that describes whining or general displeasure from having thin skin)
I use profanity as a substitute for swearing.
-
A compiler without optimisation is not a compiler. It is crippleware because you can't use it for any serious project. Hence there is no free C compiler for 8 bit PIC. Hence Microchip's success doesn't come from providing free tools.
You have a funny definition for a compiler.
A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code).[1] The most common reason for wanting to transform source code is to create an executable program.
The name "compiler" is primarily used for programs that translate source code from a high-level programming language to a lower level language (e.g., assembly language or machine code). If the compiled program can run on a computer whose CPU or operating system is different from the one on which the compiler runs, the compiler is known as a cross-compiler. A program that translates from a low level language to a higher level one is a decompiler. A program that translates between high-level languages is usually called a language translator, source to source translator, or language converter. A language rewriter is usually a program that translates the form of expressions without a change of language.
A compiler is likely to perform many or all of the following operations: lexical analysis, preprocessing, parsing, semantic analysis (Syntax-directed translation), code generation, and code optimization.
http://whatis.techtarget.com/definition/compiler (http://whatis.techtarget.com/definition/compiler)
A compiler is a special program that processes statements written in a particular programming language and turns them into machine language or "code" that a computer's processor uses. Typically, a programmer writes language statements in a language such as Pascal or C one line at a time using an editor . The file that is created contains what are called the source statements . The programmer then runs the appropriate language compiler, specifying the name of the file that contains the source statements.
When executing (running), the compiler first parses (or analyzes) all of the language statements syntactically one after the other and then, in one or more successive stages or "passes", builds the output code, making sure that statements that refer to other statements are referred to correctly in the final code. Traditionally, the output of the compilation has been called object code or sometimes an object module . (Note that the term "object" here is not related to object-oriented programming .) The object code is machine code that the processor can process or "execute" one instruction at a time.
Optimization is NOT a requirement, it's just an optional feature. It's a nice to have feature, but it's just that. Just because you think it's a must, doesn't make it so.
-
especially as the 8 bit architecture is so terribly inefficient anyway.
how?
For it's use, it doesn't seem so "inefficient", you don't choose 8bit today for big tasks, and you shouldnt choose big platforms for small tasks, so for it's use, I think it is more than adequate.
-
I think he refers to the general architecture of the PIC18 and downwards devices, which fall all under the XC8 compiler.
The non-C style instruction set, limited hardware stack, banked RAM, only 1 accumulator register means it's not very efficient.
It's like a person with 1 wounded arm & no trouser pockets. Imagine how your days will become.. you'll always have to put stuff down and pick it back up and basically can't "multi task".
The Hi-Tech (XC8) compiler is reasonably good at allocating these "items" though.. it does a call tree analysis to see which variables overlap and which don't, and use as little RAM for local variables and function arguments.
But it's still wounded.
This is basically a non-issue for software stack these days, because you can just keep push-ing and pop-ing things to and from the stack and only have to worry you don't mess up the stack alignment, and that it's large enough in the most deepest/largest call made.
And I think mentioned earlier here, this architecture combined with 1 accumulator, is why the XC8 is such a specific compiler for this platform and there is no GCC port.
As an example, I think this is what he means with inefficient:
4815 ;client.c: 118: packet->packet.data[0] = 2;
4816 0303 0835 movf HandlePacket@packet,w
4817 0304 3E06 addlw 6
4818 0305 0086 movwf 6
4819 0306 3002 movlw 2
4820 0307 0187 clrf 7
4821 0308 0081 movwf 1
4822 0309 l2540: Ouch, 6 words for just a deadsimple pointer operation, even in "PRO" mode!
Where as this takes 2 instructions on a PIC24 (like any modern core that's optimized for C work) chip:
22: packet->packet.data[0] = 2;
004864 B3C024 MOV #0x2, W4
004866 984474 MOV.B W4, [W8+7]
-
The first problem you run into on an 8 bit platform is speed (been there, done that). Having the best compiler is crucial to have any chance of finishing a project in a reasonable time. IOW not getting stuck / sidetracked with endless hand optimisation or writing assembly code because that is just frustrating in the end even if it is a hobby project. Using something else is easier said than done. I've seen kludges with over 10 PICs to do a job which a faster 32 bit controller did much better.
-
A compiler without optimisation is not a compiler.
That's why it is important to have a common set of definitions before stating your positions.
To me, a compiler isn't a compiler unless it can toast my bread to my satisfaction, :).
So whatever compiler there is to your fancy, it is not a compiler.
-
The first problem you run into on an 8 bit platform is speed (been there, done that).
I thought the first problem on any platform is to find a qualified programmer who knows how to pick the right part for a given job.
-
Yet there are probably millions of products out there with 8b PIC's in them. Go figure.
Many times, I run my 8-bit chips at less than 1Mhz, because otherwise it would be too fast.
-
Looking back several decades to build it yourself you started in machine code mine was an 8b RCA cmos cpu , in those days you needed external ROM and RAM plus peripherals driver chips CRT, UART, floppy etc. and you had the chicken / egg complication of getting a boot subroutine into eeprom, after spending big bucks on Z80 and 6502 imagine the joy of finding cheap mcu’s with a host of features that just fitted the home brew hobby I am OK with MPLAB X and recently the PIC24 plus the free tools. Perhaps if the moaners had struggled to get a a single LED to light then…
Should be an attach from Elektor Magazine Aug 1978 ... "2716 UVPROM 40GBP !!!! "
-
Perhaps if the moaners had struggled to get a a single LED to light then…
Those moaners are too interesting in moaning to light up a led.
Should be an attach from Elektor Magazine Aug 1978 ... "2716 UVPROM 40GBP !!!! "
Good old days of electronics.
-
As an example, I think this is what he means with inefficient:
4815 ;client.c: 118: packet->packet.data[0] = 2;
4816 0303 0835 movf HandlePacket@packet,w
4817 0304 3E06 addlw 6
4818 0305 0086 movwf 6
4819 0306 3002 movlw 2
4820 0307 0187 clrf 7
4821 0308 0081 movwf 1
4822 0309 l2540: Ouch, 6 words for just a deadsimple pointer operation, even in "PRO" mode!
Where as this takes 2 instructions on a PIC24 (like any modern core that's optimized for C work) chip:
22: packet->packet.data[0] = 2;
004864 B3C024 MOV #0x2, W4
004866 984474 MOV.B W4, [W8+7]
Well that is sort of a misleading comparison. The code for the PIC24 assumes that the pointer is already in W8 while the code for the enhanced mid-range pic does not assume the pointer is in FSR1 and uses extra instructions to place the pointer there.
If the pointer was in FSR1 already (apples to apples comparison) then the code could be as simple as:
movlw 2
movwi 6[FSR1]
Of course, one could rightly argue that the poor register set of the enhanced mid-range pics means that it was far less likely that the pointer base would be preloaded in (only one of two) base index registers so the original comparison is right in a "typical" context. Still, if one is providing benchmarks there is a need to provide all the details required for a meaningful context.
-
From the XC8 v1.32 release notes:
New Free-mode optimization An additional optimization has been added to improve removal of redundant bank selection instructions when using Free mode. The effect of this optimization will only be observable when the assembler optimizers are enabled.
I have no idea how much this actually improves the generated code, but I guess sometimes complaining on online forums does help.
-
I don't see any significant change between 1.31 and 1.32 just comparing assembly of a project.
Program space and data space usage are exactly the same.
The only difference I notice in the assembly listings is some changes in the floating point multiplication functions xc8 includes, some optimizations for speed there and some tweaks for PIC18F mcus.
There was really a good jump from 1.30 to 1.31.. 1.30 does have a lot of useless MOVLB and CLRF counter instructions (mostly) which don't show on 1.31 anymore.
Here's the usage to compare...
Microchip MPLAB XC8 C Compiler (Free Mode) V1.30
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration
:: warning: (1273) Omniscient Code Generation not available in Free mode
Memory Summary:
Program space used CAFh ( 3247) of 4000h words ( 19.8%)
Data space used 87h ( 135) of 400h bytes ( 13.2%)
EEPROM space None available
Data stack space used 0h ( 0) of 2A7h bytes ( 0.0%)
Configuration bits used 2h ( 2) of 2h words (100.0%)
ID Location space used 0h ( 0) of 4h bytes ( 0.0%)
Running this compiler in PRO mode, with Omniscient Code Generation enabled,
produces code which is typically 40% smaller than in Free mode.
The MPLAB XC8 PRO compiler output for this code could be 1089 words smaller.
See http://microchip.com for more information.
---
Microchip MPLAB XC8 C Compiler (Free Mode) V1.32
Part Support Version: 1.32 (A)
Copyright (C) 2014 Microchip Technology Inc.
License type: Node Configuration
:: warning: (1273) Omniscient Code Generation not available in Free mode
Memory Summary:
Program space used C7Eh ( 3198) of 4000h words ( 19.5%)
Data space used 80h ( 128) of 400h bytes ( 12.5%)
EEPROM space None available
Data stack space used 0h ( 0) of 2AEh bytes ( 0.0%)
Configuration bits used 2h ( 2) of 2h words (100.0%)
ID Location space used 0h ( 0) of 4h bytes ( 0.0%)
-
I've looked at PICs a couple of times but there wasn't really anything compelling to draw me away from AVRs. Having read how much of a fiasco the compiler situation is, I'm apparently not missing much. The MCU market is pretty much a commodity at this point.
Not much new to add really, but I echo these sentiments: I can use GCC for x86. I can use it for AVR8 and Xmega. I can use it for Cortex M. I can use any IDE (or not) that I want for any of the above, and have no concerns over missing out on optimizations, or how many computers I can legally install the compiler on. In many cases, there are a lot of pre-written libraries available too. Those vendors have worked in-house, and with the OSS community, to make free, optimized tools available so I can focus my resources on the application.
Chip vendors are starting to make it as easy and inexpensive as possible to evaluate, learn, and build with their hardware. I think that's worth noting. For sure, Microchip isn't obligated to offer their premium compiler (compilers, which is just baffling) for free, but if they could instead recoup their development cost by charging a couple cents more per chip (or harness the OSS community to do it for them, in exchange for no more than open communication and well documented specs), then it could be much better in the long run than sticking to old business models.
Times have changed. It may not be fair, or logical, but if you throw the hobbyests or product architects a bone, your chip is the first they'll think of to solve some problem. The resulting product may or may not ultimately end up in high-volume production, but some will. That has the potential to be far more lucrative than a relatively small number of $1k license fee sales.
Remove barriers anywhere you can. That's what all the free compilers, free libraries, low-cost development / eval boards, low-cost programmers, low-cost debuggers, app notes, seminars, YouTube videos, vendor-sponsored forums, and tradeshow presences are all about.
-
I have no idea how much this actually improves the generated code
I have XC8 1.12 and some benchmarking I have done (against PICC9.60std and 9.65pro) suggests that the free mode is faster than the std and closer to the pro.
-
I've looked at PICs a couple of times but there wasn't really anything compelling to draw me away from AVRs.
It is very difficult to justify using a low-end PIC (12/16/18f parts) on new designs: there are simply more superior alternatives out there.
The AVRs offer a better interrupt controller, faster speed, and more consistent peripherals. But they are more expensive as well.
The STM8 is cheaper and more capable, some of them offer a better roadmap to 32-bit chips, at a lower price point. They have however an uncertain future.
The CM0/1 chips are really attractive, particularly if you already have the code base migrated. They post a considerable threat on new designs. But the learning curve can be steep.
-
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.
I have made many PIC based projects, but I have never posted on hack-a-day. Most likely I never would. I use the right processor for the task. I do not distinguish a project by the uC used. My projects are defined by what they do not by what they use.
All my DIY projects with PICs used the free compiler versions. Optimizers are not required to produce excellent code. Optimizers are just a tool to make it easier/faster. In my opinion the only people that need optimizers are corporate users where time is money or needed to even out the various skill levels.
Nobody should start a project with picking a uC. The uC supplies the required functions not the other way around. My DIY uC selection is based on package and capabilities. It really doesn't matter who makes the uC as long as they have a free tool chain. Even better if it is MacOS friendly.
I have never used PICs in school. 30 years ago PIC wasn't used in schools.
Call me a pro if you wish but I don't use Microchips expensive tools for my DIY projects. The only reason work has the optimized licences is because government is disqualified from using the free tools.
The only thing I see is there is a resurgence of Atmel users and they want to show off their projects. I don't know a single PIC user that has the desire to post their projects on what I consider a vanity site.
Sent from my iPad using Tapatalk
-
I have no idea how much this actually improves the generated code
I have XC8 1.12 and some benchmarking I have done (against PICC9.60std and 9.65pro) suggests that the free mode is faster than the std and closer to the pro.
Congratulations, now explain how that is in any way relevant to the effect of a specific change made in XC8 version 1.32.
-
The only thing I see is there is a resurgence of Atmel users and they want to show off their projects.
Think so too.
-
That's probably true, but so what? The web has always had its share of vanity. You know this if your eyes have ever been assaulted by a personal home page with an animated Under Construction GIF. Yeah, all these project sites are almost entirely fluff, but that's OK. Some of those enthusiastic engineer-larva will eventually mature to something interesting. Most will not, but such is life. I doubt that's distinct to AVR fans, although they are perhaps a bit more accessible, therefore lowering the bar a smidge.
What this has to do with the greater scheme of things is beyond me. I really hope it's not an attempt to bash a perfectly good architecture on the sole basis of its trendiness. (If so, shall we also shun the 555, TL071, LM7805, BC549, and 1N4148?)
The PIC line is too quirky for my taste, but as Danny pointed out, there is good value there. I would like to see MC step up, sort out their development hassles, make it trivial to evaluate and design with their parts, and let the hardware run at its potential best. Even in the hands of amateurs.
-
All my DIY projects with PICs used the free compiler versions. Optimizers are not required to produce excellent code. Optimizers are just a tool to make it easier/faster. In my opinion the only people that need optimizers are corporate users where time is money or needed to even out the various skill levels.
An optimizer isn't what you seem to think it is. Without a basic optimizer your code will suck and be hard to debug at assembler level. A good one really helps when using parts with small memories too, as they can often reduce code size by 50% or more. The only alternative is trying to optimize your C code to generate better assembler, which is gong to make it suck.
Nobody should start a project with picking a uC.
That's generally what we do at work. Obviously not in isolation to anything else, but we look at the requirements for the system and decide which microcontroller best fits after sketching out the rest of the system. Since our projects can get quite large it is important to get the right peripherals and features, and avoid things that are going to make the code suck.
Sent from my iPad using Tapatalk
That's no excuse.
That is a very odd thing to say to a Systems Analyst. The people who create the optimizers for compilers.
Sent from my iPad using Tapatalk
-
I did a comparison between 1.12 and 1.32, on a piece of code I have. The stats below are the total code size and execution of the main loop:
1.12 free: 2759 bytes / 5194 ticks;
1.12 pro+space: 1832 bytes / 5385 ticks;
1.12 pro+speed: 2114 bytes / 5323 ticks;
1.32 free: 2497 bytes / 7725 ticks.
-
All programmers take systems analysis and design, so we are all systems analysts, it's part of the curriculum.
So the people that make compilers are system analysts but not all system analysts make compilers. Also all system analysts write code unless you are on a big corporation and you are director of technology but even then you tend to write code as well, not as much but more critical stuff and/or mentor others. So unless you went to full management you still write code or at least review the code of your team.
As far as the computer titles go, system analyst as a title is about the lowest you can get. That was my title on my first job ever system analyst I.
-
All programmers take systems analysis and design, so we are all systems analysts, it's part of the curriculum.
So the people that make compilers are system analysts but not all system analysts make compilers. Also all system analysts write code unless you are on a big corporation and you are director of technology but even then you tend to write code as well, not as much but more critical stuff and/or mentor others. So unless you went to full management you still write code or at least review the code of your team.
As far as the computer titles go, system analyst as a title is about the lowest you can get. That was my title on my first job ever system analyst I.
Very true. Only a Programer Analyst or Entry Clerk is lower. The former works on a module and may never see how it fits onto the larger scheme. The latter may never program at all, if they do it would likely be scripting.
Sent from my iPad using Tapatalk
-
since were talking microchip compilers in here ;)
upgrading to xc32 v1.32, the good old 'return 2' xclm trick no longer works... just an FYI.
The source for v1.32 has not been released yet,
http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html (http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html)
changing the 1.31 download link to 32 works.
http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip (http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip)
-
changing the 1.31 download link to 32 works.
http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip (http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v1.32-source.zip)
Microchip complier development is managed by loons.
The trivially easy to bypass licensing scheme got slightly harder. Paying customers as well as having the hassle of activation and/or running license servers get to wait a bit longer as every compiler invocation now generates an SHA256 hash of the 900kB licensing executable.
What I found interesting in the 1.32 source archive was a document containing this
The will allow the student edition to continue to support new devices
without requiring a re-build and underscore the philosophy that improved
functionality is only made available to paying customers (and to the
student edition in greater intervals)
Regarding .info files which decouple processor specific information from the compiler executables.
Why the hell do Microchip produce compilers at all if it isn't to support sales of their processors and here we see a 'philosophy' which requires customers to pay extra (through the annual HPA maintenance crap) if they want to use new parts. Support for new parts isn't improved functionality it is a basic requirement to use those parts and the last thing Microchip should be doing (if they want to sell) is placing financial barriers between customers and those parts.
-
upgrading to xc32 v1.32, the good old 'return 2' xclm trick no longer works... just an FYI.
It seems they're now verifying the SHA256 checksum of the license manager executable. The hardcoded checksum string is present in the cc1, cc1plus and lto1 binaries.
-
yep. whats worse, every platform has a different sha256, so someone had to build xclm, sha256 it, paste it into the build and then build gcc/binutils/etc. :-DD then you see its plain ascii embedded into the files. lol. ohwell.
worse to me, all the plib stuff has been deprecated and your supposed to use harmony, which does not come with the compiler, and so far, each release totally breaks everything from the last release. aargh. so were supposed to migrate to some shit that they have not even finished OR TESTED, damn, their own forum is full of bugs and things not implemented.
I like using pic32 but damn they should get the replacement lib working fully before trying to force us over, why the hell is the harmony lib 170mb download WITHOUT HELP FILES? oh thats another 24mb..
-
the good old 'return 2' xclm trick no longer works.
It seems to me that if someone makes a product that you like, the right thing to do is to reward them, or at least not punish them.
The fact that Microchip got bad marks because they made their products less easy to hack speaks volume about some users than Microchip.
-
The thing is that with most software it is easier to use the hacked version than the version you buy from the manufacturer. I'm running hacked versions exclusively even though I have all the original disks. It is just too much hassle to deal with online activation schemes, dongles, moving node locked licenses to a new PC, entering endless sequences of keys, etc, etc.
-
so I should pay 1000$ usd to to turn on 'optimisations' that are built into gcc? microchip didnt fund those gcc optimisations, but I really should pay for them right? since its open source, they can charge whatever they want, but since it is open source, I can recompile then as I see fit. Thats power of open source.
-
the good old 'return 2' xclm trick no longer works.
It seems to me that if someone makes a product that you like, the right thing to do is to reward them, or at least not punish them.
Seems to me that if someone rewards you for your product the right thing to do is not punish them with obnoxious licensing and activation schemes and slower compile times.....
And I don't really like their product anyway, XC8 in particular has been riddled with bugs and product support is abysmal.
-
so I should pay 1000$ usd to to turn on 'optimisations' that are built into gcc? ... Thats power of open source.
yes thats the power of free dish. implemetation of a OS code in a product doesnt necesarily means the product should be free as well. you want free go for command line or find someone that can spoonfeed you well. even fun, becomes a daddy or a professional programmer.
-
so I should pay 1000$ usd to to turn on 'optimisations' that are built into gcc? ... Thats power of open source.
yes thats the power of free dish. implemetation of a OS code in a product doesnt necesarily means the product should be free as well. you want free go for command line or find someone that can spoonfeed you well. even fun, becomes a daddy or a professional programmer.
This is a compiler. A GPL licensed compiler. The product, by definition, IS free, in the RMS / "free software" / "as in speech" meaning of the word. The product can still be sold, but the license grants recipients the right to modify and redistribute, so Microchip does not hold absolute control. IANAL go consult your own
Besides, in context of this discussion, your "command line" remark doesn't make any sense. I simply don't get the "spoonfeed" remark. Even fun, even.
I wrote a patch for this new thing before I noticed someone else did. But I am curious; what is in the "Top" patch collection? Sounds more involved than it needs to be. His old xclm was less encompassing than mine. I am curious to see wtf this xclm of his that wants the old xclm is...
-
so I should pay 1000$ usd to to turn on 'optimisations' that are built into gcc?
It is up to you if you should or shouldn't do it.
But you punish people for producing things that you want, sooner or later, no one will be producing things that you want.
-
But you punish people for producing things that you want, sooner or later, no one will be producing things that you want.
There is tons of open source software which prove this statement is absolutely wrong.
-
You have it backwards, as usual. GCC was developed by the community.
If you look at the development history of GCC, the overwhelmingly largest amount of work has been commercial. It's also incorrect to say that Microchip have done "nothing". They've added extra support for their chips, extended ISR support, added features to the linker and so on. And for many, just providing precompiled binaries is a service worth paying for.
With all the hand-wringing about open source you'd expect someone would have actually done something by now.
-
Which platform specifically? Here is my reason for asking.
When I consider a new product I search their site for a question to ask. I ask this question three times ever 2 weeks for 6 weeks. For every month waiting for a reply, I am less likely to use any of their products. After a year they are never considered again, unless I hear of many great experiences.
Sent from my iPad using Tapatalk
-
You have it backwards, as usual. GCC was developed by the community.
If you look at the development history of GCC, the overwhelmingly largest amount of work has been commercial. It's also incorrect to say that Microchip have done "nothing". They've added extra support for their chips, extended ISR support, added features to the linker and so on. And for many, just providing precompiled binaries is a service worth paying for.
With all the hand-wringing about open source you'd expect someone would have actually done something by now.
I find it hard to believe Microchip added features to GCC which improved MIPS support in general. Even though MIPS is not a general purpose core (only a few big companies use MIPS) GCC's MIPS support is pretty decent. I think Microchip added features to make it easier to port existing PIC source code to PIC32.
-
But you punish people for producing things that you want, sooner or later, no one will be producing things that you want.
There is tons of open source software which prove this statement is absolutely wrong.
and there are tons of open source software which prove this statement is absolutely wrong. if you are accustomed to quality softwares, you know its not with most of this so called FOSS. one good example is the "famous and mentioned everywhere" KiCAD. time needed to improve it, is exponential of the complexity (or quality) of the software to the power of 10, aka it will take eternity to get really usable just as the paid EDA version of today. you may argue its the thing that does what "you want", but well.... after installing most FOSS around, i wish there is a paid version, if its too expensive, i wish i can do it myself. most FOSS is a "crippled" (or crawling) version of an otherwise another famous jargon "portable code" running in M$ Wind***. so... my english can be broken.
-
well to be fair, it is true some FOSS are usable and good, but some.... ehhhh.
-
But you punish people for producing things that you want, sooner or later, no one will be producing things that you want.
There is tons of open source software which prove this statement is absolutely wrong.
and there are tons of open source software which prove this statement is absolutely wrong. if you are accustomed to quality softwares, you know its not with most of this so called FOSS. one good example is the "famous and mentioned everywhere" KiCAD. time needed to improve it, is exponential of the complexity (or quality) of the software to the power of 10, aka it will take eternity to get really usable just as the paid EDA
It is always possible to name one example where something doesn't turn out well. Open source electronics software has been lagging behind in general. It just takes a party with enough interest to pick up the pace. CERN has big plans for Kicad.
Then again there are many open source software packages which work really well. Linux in general, GCC, Gimp, Apache, PHP, Firefox, Eclipse, Wireshark to name a few.
In general there is more crappy software than good software whether it is free or you pay for it.
-
I find it hard to believe Microchip added features to GCC which improved MIPS support in general. Even though MIPS is not a general purpose core (only a few big companies use MIPS) GCC's MIPS support is pretty decent. I think Microchip added features to make it easier to port existing PIC source code to PIC32.
Partly that, partly chip support, and partly chip-specific features like configuration bits. I don't know if the ISR handlers for the external interrupt controller is completely Microchip's work (their toolchain is based on CodeSourcery's/Mentor's tree), but they have definitely extended it.
-
You have it backwards, as usual. GCC was developed by the community.
If you look at the development history of GCC, the overwhelmingly largest amount of work has been commercial. It's also incorrect to say that Microchip have done "nothing". They've added extra support for their chips, extended ISR support, added features to the linker and so on. And for many, just providing precompiled binaries is a service worth paying for.
With all the hand-wringing about open source you'd expect someone would have actually done something by now.
Is the sources for xc16 and xc32 complete?, so if you compile it yourself, you get the pro compilers, is that is?
-
Not sure if complete but here is the page where to get the sources (search for "Source Archives" within this page)
http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html (http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html)
-
Is the sources for xc16 and xc32 complete?, so if you compile it yourself, you get the pro compilers, is that is?
dont know about x16, but it is for x32. the compiler is 'complete' the 'pro' is just a switch that enables existing parts of gcc. the cpp compiler is exactly that too, a switch.
-
If you have the source you can tell to use that switch regardless of what the IDE passes.
-
Then again there are many open source software packages which work really well... Eclipse
i hate to mention it since that is another famous name here. good? usable and it can do the job? yes! but usable with comfort? i dont think so. imho, if they have to, the developers should learn from MSVisualStudioExpress (i guess, since its the next thing to the MSVisual6 i'm currently using) i know one can bash on nonportable MSVS, but its not about portability or not, its about comfort and one big help file as reference without going online looking the earth. and importantly without finding another chunk of binaries to make it work.
In general there is more crappy software than good software whether it is free or you pay for it.
agreed, the problem is not whether its free or not, its the finger behind the scene. does anyone really serious, motivated or commited spending thousands of hours for a "quality" FOSS? let alone making a effort to make it work at the first install in any type of OS targetted at. frankly i havent seen one, like KiCAD it will be like, bye bye my dear (i have enough) hope someone can take care of you soon, gladly CERN took it. as for the paid version, they are commited, they are even commited pushing their product to the edge, edge of what? you define it.
-
There is very little to argue with opinion ;) Eclipse has been developed by big companies like IBM to create a very good IDE. I have been using it exclusively for all my software development for about 10 years now. It does take some getting used to in the beginning but I'm pretty productive with it especially since I can use it for C, C++, PHP and VHDL. I really don't want to go back to MSVS :scared:
-
I have been using it exclusively for all my software development for about 10 years now.
For such an "expert" on Eclipse, you seem to have more than your fair share of troubles getting CoIDE (=Eclipse) to work.
-
eclipse is great if you stay away from plugins.
Im a netbeans guy over eclipse, so I really like that Microchip picked it for MPLABX.
-
I have been using it exclusively for all my software development for about 10 years now.
For such an "expert" on Eclipse, you seem to have more than your fair share of troubles getting CoIDE (=Eclipse) to work.
I think you are mistaken me for someone else. I never tried, used or mentioned trying / using CoIDE.
-
If you look at the development history of GCC, the overwhelmingly largest amount of work has been commercial. It's also incorrect to say that Microchip have done "nothing". I find it hard to believe Microchip added features to GCC which improved MIPS support in general. Even though MIPS is not a general purpose core
And the pre-microchip MIPS support in gcc was contributed by ?? Mostly commercial entities, wasn't it (SGI, MIPS, and assorted licensees?) I guess maybe it gets "fuzzy" when architecture gurus found companies while retaining professorships, and get their grad students to implement stuff. (not that this is at all "new", or related to the OSSW "movement." BASIC came from Dartmouth, etc)
And MIPS is a fine "general purpose core." Just not a very successful one, recently. For a while, there were LOTS of MIPs CPUs in workstations, handhelds, gaming systems, routers, and so on. ARM and Intel just sorta rolled over them.
-
does anyone really serious, motivated or commited spending thousands of hours for a "quality" FOSS?
Yes. While anyone can come up with a laundry list of crappy (free or commercial) programs, let's not forget that many devices (PC and non-PC) use Linux or BSD as the kernel, run a BSD network stack, use an HTML rendering engine based on KHTML (which became WebKit, which became Chrome and Safari), use OpenSSL for transport layer encryption, and were compiled with GCC.
There are significant efforts put behind FOSS, and some of the most prolific software in use at this time is, in fact, FOSS. Or uses it to do considerable work behind the scenes. The smart hardware vendors take advantage of that fact, publish their specifications, and let the eager code monkeys take on the lion's share of development for free. Coders get a fun project and working hardware, vendors get free development, users get free tools. I really can't understand how this model leaves anything to complain about?
...let alone making a effort to make it work at the first install in any type of OS targetted at.
One of the most user-unfriendly installs I've ever had to work my way through was for Oracle's database product. Let's just say, it's not quite a free product. MySQL (also now under Oracle's care, but a FOSS product) on the other hand is much easier to install and configure. Now these two products aren't exactly equivalent, but hey if we're throwing around generalisms with regard to the polished-ness of software...
blah blah KiCAD yada yada
KiCAD is crap. On behalf of the OSS community, "We're sorry about that." Who knows, it may turn into a brilliant project some day. At least for now, forget KiCAD. There's just a lot of buzz right now because the market is aching for a decent tool that can be made ubiquitous without any financial consideration. It's a void that is collecting matter, and KiCAD was the first piece of detritus to show up. It will get better. (The situation. Not KiCAD necessarily, as it is crap. Currently.)
-
users get free tools.
but users dont get free iphone or samsung galaxy. that was my point as i saw someone moan about paying 1K for mplab whatever just to get the optimized gcc unleashed, you are paying for mplab not gcc. Al-tee-um is crazy expensive like a car, even 5K yearly just to get bug fix support, understood, its closed source delphi. mplab is part close and part open source is 1K?, yeah what we are compaining about? carry on, economy will balance itself.
-
I really can't understand how this model leaves anything to complain about?
"Invasive species" - killing off a bunch of smallish sw vendors who sold sw. I start to worry a bit about platforms that have only gcc as assembler/compiler. They're some starry-eyed dreamer's whim away from having an unsupported mess on their hands.
-
Open Source software is never unsupported. You have all the sources available so you can provide your own support or (more common) pay someone to make the changes you want.
-
I start to worry a bit about platforms that have only gcc as assembler/compiler. They're some starry-eyed dreamer's whim away from having an unsupported mess on their hands.
Mmmh, that's a valid concern yes. But I think that if it really came to that unsupported mess (because said dreamer did something whimsical) then you would no doubt have a fork in no time. Same as on the commercial side of things where "Oracle buys X", followed by "Oracle fucks up X", followed by "X development is forked".
-
Open Source software is never unsupported. You have all the sources available
Having source available so that you can "fix it yourself" or "hire someone to fix it" is certainly much better than NOT having the source available, but I still claim that it is "unsupported."
Consider, say, "WinAVR"; the package including avr-gcc and associated tools for windows cli use.
The last "release" was in 2010, based on avr-gcc 4.5 (I think.) If I were somehow dependent on that version, I would be very nervous. (Sound far-fetched? Arduino was in exactly this position - they were based on 4.3.x Crosspack/WinAVR, and very version of avr-gcc between that and 4.7.2 or so had some signficantly-disabling bug WRT Arduino. They're still agonizing over 4.8.x (there's no winavr package, but the Atmel command line tools are almost equivalent.))
If windows 8.2 stops supporting 2010-era MinGW command line utilities (which seems "possible"), then I could be quite screwed in a couple of years.
(Not that the situation with commercial compiler vendors is any better, should they make choices that conflict with my desires. But having only ONE compiler does make it worse.)
-
(there's no winavr package, but the Atmel command line tools are almost equivalent.)
Atmel hired the WinAVR maintainer to make the Atmel command-line tools.