Developing/compiling software
in [Embedded]
|
From: Mark Borgerson on 23 Sep 2009 17:51 In article <h9dnlq$39a$1(a)reader1.panix.com>, invalid(a)invalid.invalid says... > 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. > > Just goes to show how varied user experiences can be. I've had consistently good luck with Codewarrior(68K systems), IAR (ARM systems), and ImageCraft (MSP430). I've also used GCC for an ARM system without major problems---except having to learn linux and support either another computer or a virtual machine. Mark Borgerson
From: Grant Edwards on 23 Sep 2009 18:03 On 2009-09-23, Mark Borgerson <mborgerson(a)comcast.net> wrote: > Just goes to show how varied user experiences can be. I've > had consistently good luck with Codewarrior(68K systems), IAR > (ARM systems), and ImageCraft (MSP430). I've also used GCC > for an ARM system without major problems---except having to > learn linux and support either another computer or a virtual > machine. You can use gcc cross-compilers under Cygwin. But to be honest, it's probably easier to run Linux on a VM. -- Grant Edwards grante Yow! My pants just went to at high school in the Carlsbad visi.com Caverns!!!
From: -jg on 23 Sep 2009 18:08 On Sep 24, 7:30 am, Jon Kirwan <j...(a)infinitefactors.org> wrote: > 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.) This HAS changed recently, with Cypress Claiming this: [" Cypress also offers fully functional, free compilers with no code size limitations for both the PSoC 3 and PSoC 5 device families."] ["Cypress already has agreements in place to offer free compilers for both the PSoC 3 and 5 families. The Keil CA51 Compiler for PSoC 3 and the GNU GCC-ARM compiler are bundled with Creator, which also includes a debugger to support on-chip debug and trace functionality"] My understanding is they now have a Full Keil, with reduced optimize choices, (and somehow Cypress Centric?) > >. > >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. This high price seems to follow the Embarcadero (ex Borland) selling model. ie Target the deep pocket corporates, but have some fringe tools, that are somewhat usable. PC comments : PC tool flows ARE quite useful for embedded work, for algorithm development Here, Embarcadero has Turbo Delphi, which is free, but is also crippled enough to not compile many web projects. Meanwhile, MicroSoft has quite usable versions of their C and Basic flows, (which DO compile most web projects...) and there are a number of other free PC tool flows. > > Luckily, SDCC seems not a bad choice so far as I'm aware right now. HiTech also had a legacy version of their compiler free, IIRC ? Not sure of the current availability, perhaps on a mirror somewhere ? > 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. My advice to a novice, would to be to worry less about the compiler - (as Silicon IS getting cheaper and larger all the time), but to focus more on the Debug tool chain. Unless you are intending to produce 10,000+ units into a price- paranoid market, then simply choosing the next-larger variant, is a better solution. You are always better to start with a more capable device and shrink to the final application, than the other way around. Atmel have an OSD in release, and the Silabs offering is mature and usable, and Silabs have very good ToolStick level development choices. The Cypress Debug flows look to extend things, as they claim a TraceBuffer I have not seen volume PSoC3 prices, but their web prices are comfortably under $10 -jg
From: David Brown on 24 Sep 2009 02:43 Grant Edwards wrote: > On 2009-09-23, ChrisQ <meru(a)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. > It will be interesting to see how that attitude will change at TI now that they have bought Luminary Micro and swallowed their Cortex M3 line. Luminary Micro supported a broad range of compilers pretty much equally (Keil, IAR, Code Red and CodeSourcery) with their evaluation kits, libraries, and example software. They also support FreeRTOS, uIP and lwIP (their ROM-based boot loader uses uIP, AFAIK). I don't know how much of that attitude will spread from the Luminary Micro group at TI to other groups (you're probably thinking mainly of the msp430). But for the Cortex M3 devices anyway, the idea is that the customer gets to choose which tools suit his needs, rather than which ones TI happens to like dealing with.
From: David Brown on 24 Sep 2009 04:09
ChrisQ wrote: > 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. > One point that is missing here is that the tools situation varies widely according to the processor architecture. In particular, there is a huge difference between C-friendly architectures (>= 16-bit, plenty of registers and pointers) and C-unfriendly architectures (8-bit, few registers). In the world of C-friendly processors, there is not a huge difference between major compilers for ordinary code generation. I've looked at tools for the PPC and the ColdFire - there are not many percentage point differences in the code size or speed for ordinary code between tools like Green Hills, CodeWarrior, and gcc. You certainly couldn't justify a purchasing decision based on the code quality. One thing that /can/ vary is the support for generating code that takes advantage of additional features such as DSP-type processor extensions. Libraries, debugger, profiler, IDE, wizards, etc. are other distinguishing features, as is language support (C and C++ standards and extensions). Much depends on how well the toolset fits the way you like to work. For these sorts of processors, gcc is very much a realistic choice for professional users seeking the best tools. CodeWarrior has compiler options to enable gcc language extensions - that's an indication of the relevance of gcc in that market. You also see smaller players building toolchains around gcc - they have gcc as the compiler, but use their own library, debugger, and other tools (possibly their own IDE, or just using Eclipse like many others). Anyone who still thinks gcc is "nowhere near as good as the top commercial compilers" for processors like ARM, PPC, ColdFire, MIPs, x86 is either many years out of date, or has his head in the sand. Argue about the benefits of commercial support, integrated solutions, certification, libraries, etc. if you want - that is where there are real distinctions in the tools. But not the compiler. For small cpus, the situation is very different. Getting the best out of a processor like the 8051 or the COP8 is far from easy. For the COP8, there are relatively few users, all of which are serious professionals. Writing a good compiler for the device is a specialised job. Whereas for larger devices, much of the compiler software can be shared across different targets, on something like the COP8 there will be a higher proportion of target-specific code. This means that writing a COP8 compiler takes a lot of time and money for a very small user base, and that really boils down to commercial tools at a professional-only price point. The 8051 is an oddity in this. It is a C-unfriendly device and the professional-only compiler (and associated tools) from 8051-specialist Keil gives the best code. On the other hand, it is very popular and there is a perfectly reasonable open source compiler. The generated code might not be as compact (especially in data usage) as with Keil's compiler, but that's not a problem for all users. One important thing to consider in this is how things will change in the future. The trend is towards 32-bit micros - they are getting smaller, cheaper and lower power, and pushing out the 8-bit devices (16-bit is now almost non-existent, except for the msp430 which is squarely in the 8-bit market). Use of 8-bit devices will become less common for new designs (except for customers looking for huge volumes, of course), especially in the case of C-unfriendly architectures, making life difficult for the more specialist tool vendors. I suspect we'll see more development tools based on gcc but with specialisation and differentiation in libraries, debuggers, other tools, and support (there are already half a dozen such tools for ARM variants). How then will the big commercial developers react? I hope they adapt and that we don't see acquisitions or bankruptcies - choice and competition is important for end users. |