Chris H wrote:> > If that were the case there would be a problem but so far most of the > open source compilers are no where near as good as the top commercial > ones. >I'm sorry, but you need to be more specific in terms of *how* they are better. You're not selling soap powder to the 19th c unwashed here. If we are discussing Keil, it's not so much the compiler, but the linker, which seems to do magic in terms of it's overlay analysis and ability to make use of constrained ram and xdata space. A btter solution might have been to do more work upfront in terms of design and cpu choice to avoid the problem in the first place. Great for legacy hardware but not necessarily relevant if you're starting from scratch. So what else is there and how about other vendors and architectures. What's so inferior about the gnu toolchain, for example ?.> >> means a diminishing client base and less money for development. Unless >> they can come up with a revised business model, they seem condemned to >> niche markets and long term decline. If you want evidence, compare the >> diversity of tool vendors a decade ago with the same now. > > True... So eventually programmers will be expected to produce their own > tools and RTOS on their own time at their own expense.Some already do :-), but that's taking the argument to absurd limits. Of course, you write some tools over the years, but buy in the stuff that would be uneconomic to develop yourself. One of the great strengths of open source is that it shares the cost and time to develop complex applications among the many with the result available for all to use. It potentially brings together resources that would be not possible for individual companies.> > Who funds these open source programmers? They have to eat.Some people are still altruistic, believe it or not and do it for fun or the intellectual challenge while keeping their day job. Others want to be remembered for contributing something for the common good, rather than merely for commercial gain. Any number of reasons. Not to say that there's not serious money involved now. IBM, Hp / Compaq and many others fund development and the likes of Redhat, Code Sourcery and Kpit Cummins package up the results to sell and provide support. The truth is that the marketplace for tools has changed forever. How will traditional tool vendors like Keil and IAR survive in the long term ?.> > The problem is the main users of the open source tools are not the ones > who are producing them... >How is this a problem ?... Regards, Chris
Developing/compiling software
Started by ●September 16, 2009
Reply by ●September 23, 20092009-09-23
Reply by ●September 23, 20092009-09-23
On 2009-09-23, Lodewicus Maas <wicus.maas@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. 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 > . > . > 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.Have you thought about using an AVR or MSP430 or something less brain-dead (for which free/cheap tools are available)? -- Grant Edwards grante Yow! This PIZZA symbolizes at my COMPLETE EMOTIONAL visi.com RECOVERY!!
Reply by ●September 23, 20092009-09-23
On 2009-09-23, ChrisQ <meru@devnull.com> wrote:>> Who funds these open source programmers? They have to eat. > > Some people are still altruistic, believe it or not and do it for fun or > the intellectual challenge while keeping their day job. Others want to > be remembered for contributing something for the common good, rather > than merely for commercial gain. Any number of reasons. Not to say that > there's not serious money involved now. IBM, Hp / Compaq and many others > fund development and the likes of Redhat, Code Sourcery and Kpit Cummins > package up the results to sell and provide support.Some of the CPU vendors (Hitachi, Atmel, Altera) fund much of the initial gcc port and then provide support for the community. Unfortunately, others (like TI) appear to actively sabotage free tools. They don't succeed in hindering the tool development much, but they do manage to annoy their customers. -- Grant Edwards grante Yow! I just heard the at SEVENTIES were over!! And visi.com I was just getting in touch with my LEISURE SUIT!!
Reply by ●September 23, 20092009-09-23
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. Self-employed tries to make money of everything.> 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. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●September 23, 20092009-09-23
On 2009-09-23, Vladimir Vassilevsky <nospam@nowhere.com> wrote:> > > 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. Self-employed tries to make money of > everything. > >> The problem is the main users of the open source tools are not >> the ones who are producing them...In my experience the producers of open-source tools _do_ use them. It's just that not all of the users are producers.> 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.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. -- Grant Edwards grante Yow! HUMAN REPLICAS are at inserted into VATS of visi.com NUTRITIONAL YEAST ...
Reply by ●September 23, 20092009-09-23
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
Reply by ●September 23, 20092009-09-23
In message <OLWdnTbPU7jp2SfXnZ2dnUVZ_hKdnZ2d@giganews.com>, Vladimir Vassilevsky <nospam@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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●September 23, 20092009-09-23
On 2009-09-23, ChrisQ <meru@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"!
Reply by ●September 23, 20092009-09-23
On Wed, 23 Sep 2009 10:00:17 +0200, "Lodewicus Maas" <wicus.maas@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 licenseThat'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
Reply by ●September 23, 20092009-09-23
In article <Hatum.359333$RV1.69792@newsfe26.ams2>, meru@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