Developing/compiling software
in [Embedded]
|
From: Chris H on 18 Sep 2009 13:22 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 -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: Jon Kirwan on 18 Sep 2009 15:33 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
From: Jon Kirwan on 18 Sep 2009 16:17 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 I hope you aren't finding the many English answers complex enough to make further discussion hard for you. I see you haven't added anything yet, which concerns me. You mention Atmel and Asem51v1.3, so I'm assuming this is the AT89 series from Atmel? Some questions that are important to know, before discussing things: (1) Hobby or professional application? (Not clear, but I'm leaning towards believing this is for professional use.) (2) Assembly or c? (You mention asem51v1.3, but also mentioned 'compiler software', so it's not clear to me. It's possible when you talk about 'Keil software' you may only care about the debugger/JTAG capability, too. Can you clarify this?) (3) Project size/complexity? (4) Unique requirements? 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. You might be able to test this a little by seeing how they treat you with pre-sale questions -- but test things in several ways. Including 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. 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. Do the same for any supplier you consider. In the end, whatever your choice, you will spend a fair amount of your time learning to properly use the tools. Even if you have good hand-holding from the supplier, excellent documentation, or an energetic and healthy users' group, you will still have to put in a lot of your own time. It's always good to know what to expect and plan for. So, the effort won't be entirely wasted, even if the results don't materially change your final decision. I haven't used Keil for 20 years. So my early experiences will be of almost no use -- they have changed hands probably more than once since then and, besides, the entire environment around them has also changed. But I think it would help others respond to you better if you could say a little more about your situation. Jon
From: ChrisQ on 18 Sep 2009 16:29 Chris H wrote: > > 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 > > Not sure I agree with all that, but the Keil compiler seems pretty good and the ide is easy to live with. It's just so expensive. I guess not too bad if you can amortize the cost over several projects. Otoh, have been able to complete 2 small controllers with the Silabs kits well within the 4 K size limit, though neither were particularly complex. Also have an older Keil C, 5.1 iirc, that was bought for another project some years ago, but am told that there is no upgrade path and must pay the full price, yet again. Visions of bohica etc. It's a completely unlocked version as well, something we (the client in fact) paid extra for at the time. With regard to the ide, have been using Renasas 80C87 series on a client project and the "High Performance Embedded Workshop" ide looks very similar to the Keil ide, as does the ide from the Embest arm development kits. Perhaps Keil customise the ide for many. or is the look and feel being copied and becoming standardised ?... Regards, Chris
From: Chris H on 19 Sep 2009 04:35
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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ |