Developing/compiling software
in [Embedded]
|
From: Chris H on 23 Sep 2009 13:12 In message <OLWdnTbPU7jp2SfXnZ2dnUVZ_hKdnZ2d(a)giganews.com>, Vladimir Vassilevsky <nospam(a)nowhere.com> writes > > >Chris H wrote: > > >> Who funds these open source programmers? They have to eat. > >There is a big difference in the philosophy of the self-employed and >the employees: An employee hates his job and tries to do something >beautiful on his own for the sake of it. Then you are very sad. It is most certainly not true of all employees by a long way > Self-employed tries to make money of everything. Again completely false. Though it might be true for you? Arn't you self employed? >> The problem is the main users of the open source tools are not the ones >> who are producing them... > >One of the main problems of any tools is that the one who makes them is >not the one who uses them. The more sophisticated the tools are, the >bigger is the problem. Very true. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
From: ChrisQ on 23 Sep 2009 12:56 Grant Edwards wrote: > > In my experience the producers of open-source tools _do_ use > them. It's just that not all of the users are producers. > The best example must be gcc, where each new generation will be compiled by the previous one. > > IMO, the problem is even worse for commericial tools where it's > quite obvious that in many cases the producers do not (nor have > they ever attempted to) use the tools. > None of the commercial tools i've used have been really bad. They all compile code and seem to have few bugs. Even the older stuff (>10yrs) more or less did what it said on the tin, but by the time you get all the costs, lack of trust, dongles and flexlm hassles onboard, they can turn into a real can of worms totally unrelated to tool quality. It's not the tools that are the problem, but sometimes the attitude of the vendors, imho. Anyway, the open source stuff, where available, is often as good or better for all practical purposes. There's no real reason not to use it and the open source model of cooperative development is arguably more suited to the mindset of many users. You just have to do some of the legwork yourself... Regards, Chris
From: Grant Edwards on 23 Sep 2009 13:59 On 2009-09-23, ChrisQ <meru(a)devnull.com> wrote: > Grant Edwards wrote: > >> IMO, the problem is even worse for commericial tools where >> it's quite obvious that in many cases the producers do not >> (nor have they ever attempted to) use the tools. > > None of the commercial tools i've used have been really bad. > They all compile code and seem to have few bugs. Even the > older stuff (>10yrs) more or less did what it said on the tin, > but by the time you get all the costs, lack of trust, dongles > and flexlm hassles onboard, they can turn into a real can of > worms totally unrelated to tool quality. Don't get me started on dongles and flexlm... In my view, that stuff is all part of the quality of the tools. If the products' developers had to fight with those, things would probably change for the better. Having to cough up a bucket of cash just because you upgraded your workstation is a swindle. > It's not the tools that are the problem, but sometimes the > attitude of the vendors, imho. I remember one running battle with a cross-compiler vendor that lasted for months and months. They had lost some of their customer records in a computer crash and were completely incapable of dealing with the situation. They were relentless in trying to force people to buy new licenses instead of giving out the updates to which the customers were entitled. > Anyway, the open source stuff, where available, is often as > good or better for all practical purposes. There's no real > reason not to use it and the open source model of cooperative > development is arguably more suited to the mindset of many > users. You just have to do some of the legwork yourself... I've used gcc for embedded projects on a half-dozen different architectures, and have always been quite happy with it. I'm told there are decent commercial tools from reputable firms, but I've had consistently bad luck with commercial tools as far as both support and quality are concerned. -- Grant Edwards grante Yow! I'm changing the at CHANNEL ... But all I get visi.com is commercials for "RONCO MIRACLE BAMBOO STEAMERS"!
From: Jon Kirwan on 23 Sep 2009 15:30 On Wed, 23 Sep 2009 10:00:17 +0200, "Lodewicus Maas" <wicus.maas(a)gmail.com> wrote: >OK. So Keil is NOT an option anymore >. >The Demo/Eval version can only compile up to a max of 2K - which I reached >already. Last I checked (April, this year) Keil limits itself to 0x800 bytes (2k) without registration and to 0x1000 bytes (4k) after that. So you _may_ be able to boost this to 4k if you register with them. (I don't know their policies about registration in your country, though. So you will just have to find out about it, I suppose.) But if you feel that you will also exceed 4k, then... well, perhaps Keil is now off the table for you. >I then requested a quote from the local suppliers of Keil software, >and the quote is ... >. >. >I hope you're sitting ... >. >. >. >R 39,335.81 ( this is equal to 5,326.93 USD) - for a single user license That's more than I would have expected. I'm very sorry the situation is like that, for you. I mean that very sincerely. >My whole outlook on life is "value for money", and I don't invest in >anything if this requirement is not met, but unfortunately there is no way >in which I can justify this as a hobbiest >. >I'm now busy looking at ImageCraft >. >The "doors" keep on closing, but eventually I'll get there. I still don't know what code size you expect in your project. And you still have a few commercial vendors to check out (like IAR.) I don't believe IAR offers more than Keil for a trial version, though I really don't know about it. But if it your project is likely to be larger than 4k, it's possible that the price of the few serious commercial alternatives may very well leave you with SDCC as the only viable choice. However, take a look at Dunfield: http://www.dunfield.com/products/dks.htm They are a commercial vendor for low cost c compilers. They apparently offer one for the 8031/2 core. So that may be another option for you to consider that is already known to be 'cheap.' You may look up some reviews that compare it with SDCC before deciding. Keep finding out about other commercial options, of course, and ask just as you have with Keil. But if your project will become much larger and you feel unable to afford the kinds of prices you find with those commercial vendors, it's probably better to just invest your time in SDCC before getting in too deep with the trial versions of compilers you can ill afford. So far, SDCC has just worked exactly as intended without difficulty for the modest tasks I've thrown its way. So I have no complaints, yet. Keil accepts 16-bit descriptions for SFRs that happen to actually be 16 bits wide. To do the same with SDCC, I have to write two statements in c, one for each byte. The generated code in each is different, but equally fast and occupying the same space. Just by way of example how your source code might differ a little. Although I haven't heard specific details about IAR's pricing for the 8051, I have heard some numbers for IAR's offering for other microcontrollers where Imagecraft, for example, also plays in the commercial marketplace. And there, IAR is not a low-cost compiler tool, either. Not by any stretch. So although you may see a difference by a factor of 2 (less?), or so, I wouldn't expect a whole lot better than that. It's still worth a moment for you to find out an exact number from IAR and see where it falls relative to your own willingness to spend for this. Give them a shot. Luckily, SDCC seems not a bad choice so far as I'm aware right now. Don't be scared about SDCC just because Chris H works so energetically to make it seem terrible. He has always been quick to reply with scare tactics regarding anything that he sees as 'threatening' to high priced commercial products. Last April, he and I talked a bit about all this and he is very good at making highly veiled, while almost seemingly definite claims about SDCC. In the end, though, he refuses to be literal and specific and I've taken the view that all of his knowledge about SDCC is a decade old or more, if it has any value to it at all. For example, here is a snippet of our conversation: >>But I'm not interested in hearing your opinion a second time, without >>supporting facts. Which is why I asked for you to provide specifics. >>I see you still aren't doing that. > >Just try both and you will see the results. I don't have the time. In this thread, he once again made a semi-specific comment which seems on its face to be accurate. I took the time to look up what few words he used that I might use in a search and found that there was indeed something about it... but it is old news, back in 2000/2001, and apparently long since gone as an issue. And here in this thread, he continues to avoid providing a recent reference or source or to elaborate at all. Which seems very true to form. There may be good reasons. Free and low cost c compilers that can do a credible job threaten to topple high prices. And with lower prices, there is less money within those commercial business entities to fund internal research/development of improved techniques. So he may have a holy grail he's pursuing. I just can't say. It's just that he remains a reliable apologist for expensive commercial compilers and dongles and a consistent attacker of anything that even 'looks' somewhat different from the usual commercial business model operation. My main point here isn't to attack Chris H, but to point out that you shouldn't be frightened by him regarding alternatives like SDCC. You are definitely able to do serious projects with SDCC. If you have any question, google a few projects that have used it in the past with good success. For example, here is one I quickly found, just now: http://www.arrickrobotics.com/robomenu/adam.html You can get the SDCC manual here: http://sdcc.sourceforge.net/doc/sdccman.pdf Also, the author of the SDCC 8051 component was John Hartman and he has a mildly interesting 8051 web site here: http://www.noicedebugger.com/help/8051.htm Besides some minor differences in the way the SDCC c compiler handles some things in the source code from the way that Keil does, there are substantial differences in the way the compilers may be invoked through their option switches. See this appnote for some thoughts: https://www.silabs.com/Support%20Documents/TechnicalDocs/an198.pdf On a final note, you may still want to revisit the idea of using an 8031/2 core, at all. Though I seem to recall that you've already written a lot of code on the basis of having selected this part which has better availability for you, and perhaps you've grown quite familiar with its details by now, so perhaps that's not really much of an option. Best of luck. Jon
From: Mark Borgerson on 23 Sep 2009 17:47
In article <Hatum.359333$RV1.69792(a)newsfe26.ams2>, meru(a)devnull.com says... > Grant Edwards wrote: > > > > > In my experience the producers of open-source tools _do_ use > > them. It's just that not all of the users are producers. > > > > The best example must be gcc, where each new generation will be compiled > by the previous one. That's not necessarily true for the GCC cross compilers. Most of the cross compilers are compiled on an X86 system. The people who build an ARM compiler may never actually use it to compile code to run on an ARM system. > > > > > IMO, the problem is even worse for commericial tools where it's > > quite obvious that in many cases the producers do not (nor have > > they ever attempted to) use the tools. > > > > None of the commercial tools i've used have been really bad. They all > compile code and seem to have few bugs. Even the older stuff (>10yrs) > more or less did what it said on the tin, but by the time you get all > the costs, lack of trust, dongles and flexlm hassles onboard, they can > turn into a real can of worms totally unrelated to tool quality. It's > not the tools that are the problem, but sometimes the attitude of the > vendors, imho. > > Anyway, the open source stuff, where available, is often as good or > better for all practical purposes. There's no real reason not to use it > and the open source model of cooperative development is arguably more > suited to the mindset of many users. You just have to do some of the > legwork yourself... > Mark Borgerson |