Developing/compiling software
in [Embedded]
|
From: Chris H on 19 Sep 2009 04:43 In message <l6o7b5d4so1t4vdtf13het6k6n56okl6qk(a)4ax.com>, Jon Kirwan <jonk(a)infinitefactors.org> writes >On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas" ><wicus.maas(a)gmail.com> wrote: > >>I've looked at Keil uVIsion (Trial Version) as well as Asem51v1.3 (old >>stuff). >> >>Any suggestions of the compiler software you're using to write/compile your >>code and create hex files to upload to the ATMEL microcontrollers. I would >>rather review a few other options, than to invest in the Keil software, only >>to discover afterwards that there are maybe better tools for the job >> >>(Apologies for my tenses/grammar - English is my second language) >> >>Kind Regards > >If budget is not a concern; this is a large, professional application; >and you intend on using the c language for it, then the main question >I'd have regarding using Keil's c compiler would be the quality of >their after-sale support for you and their product documentation. (I >already believe they have a good quality compiler.) How important >those are will depend some on your own skills, of course. Their after sales service is as good or better than most. See comment at end. >some rather detailed technical questions, beforehand. Ask for some >names they can offer you, unaffiliated with them otherwise, whom you >can talk with a little about their experiences. Just go on the Keil forum. As 80% of the professional world use Keil that is a recommendation in itself. Besides I doubt if other customers will talk to you. >And do some research >on your own to get a sense. This may be worth a little prodding and >research at the price point they are charging. Get a manual and look >it over, too. Get the eval version of the compiler. >I haven't used Keil for 20 years. So my early experiences will be of >almost no use Correct yet still you ranted about it a few months back. You were going to show us all the results of your SDCC -Keil comparison tests. > -- they have changed hands probably more than once since >then and, Wrong. Keil was bought by ARM. However that was just a change of ownership. For the 8051 (and 166) nothing else changed. As they were bought by ARM the changes were to the ARM tool chain. Keil can still support all their 8051 compilers going back 20 years. As those of you here will know, at christmas 2008 they even sorted out a dongle problem for a version (rebadged as Franklin) that was 18 years old... -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: Jon Kirwan on 19 Sep 2009 06:01 On Sat, 19 Sep 2009 09:43:22 +0100, Chris H <chris(a)phaedsys.org> wrote: >In message <l6o7b5d4so1t4vdtf13het6k6n56okl6qk(a)4ax.com>, Jon Kirwan ><jonk(a)infinitefactors.org> writes >>On Wed, 16 Sep 2009 10:53:35 +0200, "Lodewicus Maas" >><wicus.maas(a)gmail.com> wrote: >> >>>I've looked at Keil uVIsion (Trial Version) as well as Asem51v1.3 (old >>>stuff). >>> >>>Any suggestions of the compiler software you're using to write/compile your >>>code and create hex files to upload to the ATMEL microcontrollers. I would >>>rather review a few other options, than to invest in the Keil software, only >>>to discover afterwards that there are maybe better tools for the job >>> >>>(Apologies for my tenses/grammar - English is my second language) >>> >>>Kind Regards >> >>If budget is not a concern; this is a large, professional application; >>and you intend on using the c language for it, then the main question >>I'd have regarding using Keil's c compiler would be the quality of >>their after-sale support for you and their product documentation. (I >>already believe they have a good quality compiler.) How important >>those are will depend some on your own skills, of course. > >Their after sales service is as good or better than most. See comment >at end. The OP needs to comment. And being "as good or better than most" doesn't necessarily say that one shouldn't see how it applies to their specific circumstances. In some cases, the norm is pretty bad. It's worth some investigation, unless it's already known at the outset that it doesn't matter. Which was my point. >>some rather detailed technical questions, beforehand. Ask for some >>names they can offer you, unaffiliated with them otherwise, whom you >>can talk with a little about their experiences. > >Just go on the Keil forum. As 80% of the professional world use Keil >that is a recommendation in itself. The OP still needs to comment here. But the Keil forum is an obvious place to check out, I agree. Band wagon propaganda isn't meaningful, though. Just because 80% of the professional world uses Microsoft compilers for Windows development doesn't mean it's always the more appropriate choice, either. Nor should it be the case that competition isn't supported. Few markets are served as well by single suppliers than if there are several viable ones. Competition is good. >Besides I doubt if other customers will talk to you. Now that's just you being sour and grumpy. >>And do some research >>on your own to get a sense. This may be worth a little prodding and >>research at the price point they are charging. Get a manual and look >>it over, too. > >Get the eval version of the compiler. That, too. >>I haven't used Keil for 20 years. So my early experiences will be of >>almost no use > >Correct yet still you ranted about it a few months back. You were going >to show us all the results of your SDCC -Keil comparison tests. Yes, when I am ready. Turns out, I have become more fully engaged in work than I'd imagined and although I have plenty of raw data, it will take some time (and thought) to pull it together for a post. >> -- they have changed hands probably more than once since >>then and, > >Wrong. Keil was bought by ARM. However that was just a change of >ownership. Which matters, as experience has done little but to inform me about. It can be good or bad, but rarely indifferent. Of course, I have no idea about what the changes have and have not meant. So I'll leave this for you to rant about. My point was to admit my ignorance. If you want to roll around in that mud, have at it. >For the 8051 (and 166) nothing else changed. As they were >bought by ARM the changes were to the ARM tool chain. People matter. Especially those near the top, whose attitudes and goals impact everyone all the way down to those on the phone lines. >Keil can still support all their 8051 compilers going back 20 years. As >those of you here will know, at christmas 2008 they even sorted out a >dongle problem for a version (rebadged as Franklin) that was 18 years >old... Oh, cripes. A segue back into the dongle or not-to-dongle argument. You and I will never agree on this point, either. You are simply wrong there, too. Oh, well. Someday, we should meet and have lunch. If we still couldn't find common ground or common worldviews, I'd at least be able to enjoy watching you simmer over old grievances still remembered too well. Jon
From: Jon Kirwan on 19 Sep 2009 06:05 On Sat, 19 Sep 2009 09:35:50 +0100, Chris H <chris(a)phaedsys.org> wrote: >In message <jun7b51ca0mmlh513qmraeco91cr3rscon(a)4ax.com>, Jon Kirwan ><jonk(a)infinitefactors.org> writes >>On Fri, 18 Sep 2009 18:22:14 +0100, Chris H <chris(a)phaedsys.org> >>wrote: >> >>><snip> >>>SDCC is not even in the frame It can not handle the Dallas >>>memory map. There are several ways of doing it and I recall it took a >>>lot of doing to getting working well. >> >>Is this the issue that SDCC mentions back in 2000 and 2001 and seems >>to have been resolved then? (Those issues they mention as related to >>the Dallas DS 390?) Or something you know to be otherwise and later? >> >>Jon > >Hi Jon, > >Last time we discussed SDCC and Keil you made all sorts or personal >attacks on me and made many claims. You were going to prove you were >right by doing a comparison test between SDCC and Keil > >As that was many months ago you can either show your results or >apologise and go away. I will prepare publishable results when I'm able to. I've a schedule to keep on a commercial project that arrived a month ago, right now. No, I don't trust anything you say without checking it very carefully, if I care about it at all. You've earned that on your own. But when it also serves you well, you can offer some truly useful advice. So sometimes I find gems. I just have to verify everything, that's all. My question stands. You said that SDCC "is not even in the frame" and then used the solitary specific about a Dallas memory map problem to back that broad statement up. I went over to see what I could find reported about such a problem and what I did uncover seemed to be about 2000/2001 and the DS 390. Supposedly, that's been taken care of around that time. But it might not be what you were talking about. So I'm curious if this is what you were using or not. I'm sincerely interested and believe it's possible you may have more recent information than I've been able to find. If so, your provision of some researchable specifics might help others, if not me. If you really don't have anything to add, beyond what I already discovered, then that's fine, too. It just undermines your prior comment, is all. Jon
From: David Brown on 19 Sep 2009 11:20 Chris H wrote: > In message <4ab336aa$0$26305$8404b019(a)news.wineasy.se>, David Brown > <david(a)westcontrol.removethisbit.com> writes >> FreeRTOS info wrote: >>>> I agree about the ARM having lots of tools, but I thought the choice >>>> of >>>> practical tools for 8051 was fairly limited - either SDCC (for those >>>> who value the benefits of free and open source tools, or for those on >>>> a low budget) or Keil (for those with plenty of money looking for top >>>> quality commercial tools). Are there other alternatives? >>> IAR, Resonance, Tasking, to name but 3. >>> >> Thanks. Keil and SDCC are the only ones I regularly read about in this >> group. > > Keil IAR and Tasking are professional tools Of the three the Keil is > the best for 8051. > > >> For example in this thread, the OP asked for tools for the 8051, and >> until now no one has mentioned anything other than Keil and SDCC. Are >> they so dominant that few people use other tools for the 8051? > > About 80$% of the professional market is Keil. The rest use IAR or > Tasking with only a few using anything else > >> And if so, is it for technical reasons, > > Mainly technical. Also the silicon companies work with Keil and IAR > before the chip is launched... often up to two years before launch. > > In this case Keil would be the best technical choice. Follwoed by IAR > and tasking. SDCC is not even in the frame It can not handle the Dallas > memory map. There are several ways of doing it and I recall it took a > lot of doing to getting working well. > >> economic reasons, > > Economic is another reason in this particular case. The silicon > companies work with *some* compiler companies and they have the examples > and set up projects also their generated coded is usually a LOT more > compact and faster. Thus less memory is needed and less power is needed > and therefore lower costs in production that far out weigh any cost of > the tools > I don't want to go into the pros and cons of SDCC in this thread (unless the OP goes there) - I don't know the specifics of the tools, so it would end up in yet another generic argument about the advantages and disadvantages of expensive commercial tools against FOSS tools. I'm happy not to talk about SDCC here if you are. You say Keil has about 80% of the market. I regularly read that "Keil is good, but horribly expensive" - a comment that equally applies to IAR in many cases. And as far as I know, IAR works very closely with manufacturers (I know of several cases of both commercial and FOSS tool developers having trouble because manufacturers wouldn't talk to them - as far as the manufacturer was concerned, IAR was the only relevant tool vendor and since IAR made a compiler for their micro, why should they bother talking to any other tool vendor?). So is there something else that makes Keil so dominant over IAR in the 8051 market? How do they compare in price and code quality? I know very little about Tasking - are they comparable in price and quality with Keil and IAR? And why is there (apparently) no "ImageCraft" for 8051? In the AVR and MSP430 market, ImageCraft is an example of a "cheap and cheerful" vendor. They are much cheaper than (for example) IAR, and have much lower code generation quality (both IAR and gcc generally make smaller and faster code, and have far more features). But the tools are easy to use and you get excellent support. These sorts of tools are very popular among smaller developers. Is there nothing equivalent in the 8051 market?
From: Chris H on 20 Sep 2009 11:11
In message <-tednXyshY6FainXnZ2dnUVZ8sudnZ2d(a)lyse.net>, David Brown <david.brown(a)hesbynett.removethisbit.no> writes >Chris H wrote: >I don't want to go into the pros and cons of SDCC in this thread >(unless the OP goes there) - I don't know the specifics of the tools, >so it would end up in yet another generic argument about the advantages >and disadvantages of expensive commercial tools against FOSS tools. >I'm happy not to talk about SDCC here if you are. > >You say Keil has about 80% of the market. I regularly read that "Keil >is good, but horribly expensive" - a comment that equally applies to >IAR in many cases. Neither are expensive in reality. The initial purchase price is higher than SDCC but total cost for a project can easily make the Keil the least expensive choice. > And as far as I know, IAR works very closely with manufacturers Yes both IAR and Keil work closely with the 8051 silicon and core makers. NOTE like ARM many 8051's are VHDL and Verilog cores as well as in MCU chips. >(I know of several cases of both commercial and FOSS tool developers >having trouble because manufacturers wouldn't talk to them This is not uncommon. It is a business arrangement. The silicon companies work with, usually, several of the leading compiler companies. This is often several years before the release of the silicon. I was involved in this myself with one of the new parts for an 8051. However... they want these new MCU's to be confidential until the release (at least until the release to the lead customers) which would not be possible with Open Source compilers. > - as far as the manufacturer was concerned, IAR was the only relevant >tool vendor and since IAR made a compiler for their micro, why should >they bother talking to any other tool vendor?). Some silicon companies work exclusively with IAR or Keil for the initial compiler for their new part. After release other compilers are usually able to gain information and also offer support. > So is there something else that makes Keil so dominant over IAR in the >8051 market? How do they compare in price and code quality? It is the design of the compiler. It has some features not found in any other 8051 compiler. Do remember that Keil specialised in the 8051 and only the 8051 for a long time. The code quality from a Keil compiler for 8051 can not be beaten (some can equal it) the other point is the Keil 8051 compiler will handle all the 600 odd variations of the 40+ different 8051 family cores. The standard Intel 8051/52 core is AFAIK no longer used. There internal architectures for the memory and the extensions to the SFR's mean a standard 8051 12 cycle compiler will not work with most of the 8051 family.... or at least only with a subset of the SRF's and memory. >I know very little about Tasking - are they comparable in price and >quality with Keil and IAR? I too know less about Tasking than IAR and Keil. They were bought by Altium a while back and compilers do not seem to be their core business. At Embedded World in Nuremberg this year the Tasking compilers were not on the Altium stand bar a couple of flyers they managed to find under the counter. >And why is there (apparently) no "ImageCraft" for 8051? In the AVR and >MSP430 market, ImageCraft is an example of a "cheap and cheerful" >vendor. They are much cheaper than (for example) IAR, and have much >lower code generation quality (both IAR and gcc generally make smaller >and faster code, and have far more features). But the tools are easy >to use and you get excellent support. These sorts of tools are very >popular among smaller developers. Is there nothing equivalent in the >8051 market? Not any more. The Keil (and IAR) compiler have the 8051 market sewn up. The 8051 compiler has to handle many variations in the 8051 cores. There are many memory layouts and SFR's . The 8051 market is not expanding. The number of potential customers divided by effort to produce will determine cost. So any 8051 compiler to compete with Keil will be expensive to produce. Besides you will have to convince the MCU makers to work with you as well. The problem is that due to the free and very cheap tools is that those who don't care about high quality tools will use the free or *very* cheap ones. Those who need the quality tools will get them as they are very cost effective for their work. That leaves the middle ground. Cost more than the cheap tools but they not have performance that is that much better than the low end tools and the are no where near as good as the expensive tools... This is why the mid-range tools have disappeared in so many areas. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |