Hi all, we're trying to solve a complicated task. We have to choose uP' family for our next generation's products. Since now we disperse a lot of energy (and money of course) in different system equipped with:
- infineon C167CRLM
- fujitsu MB90545
- various microchip
- some atmel (AVR)
- some TI (don't remember partname)
Mine product are something like PLC. To be more precise, product are Automotive PLC. Since now, we develop two family of systems with various architectures:
- visualizer
- actuators
Visualizer usually has a display (monochrome) and sometimes some limited I/O resources. Actuators, has a lot of I/O of any kind.
We spent a lot of money in development systems, employee's formation, problem solving and we're tryng to change our way of thinking. We'd like to move to just ONE architecture in order to move tecnician and programmer from a project to another one as quickly as possible.
Please suggest us a family of micro that has:
- good cost
- integrated CAN bus
- free C compiler
- web literature (forum, docs, etc...)
- flash
- good interchangeability
- low cost dev sys?
At this time, we are thinking to atmel' family but we'd like to have your precious suggestions.
Please, if you can, suggest also: _Visualization tools_ we need a tool that it's able to design in a quick way our display's content. Best could be a software that generate C code of bargraph, gauge, bitmap, variables... _Ladder tool_ tool that generate C code from a ladder diagram (since now, we found only ftp://ftp.visi.com/users/grante/stuff/led.tar.gz
formatting link
but it is working with linux only ... ) _ST tool_ tools that generate C code from a StructuredText listing
We'll appreciate all good suggestions of every kind. Best regards to all readers, Gian.
Compile all the requirements. You have most of them, but to those you need to add an estimate of the performance and memory requirements, plus your temperature requirements. I'd run the requirements by all your senior engineers, to make sure you haven't missed anything (like easy download?).
Start slogging through data sheets. Find some candidates (hopefully more than one) and winnow through them to find the best one. Try to guess at one that has upward growth potential, for when you run out of space or performance. Lean toward manufacturers that have given you good service in the past. Failing that, ask about those few candidates here, and give the most weight to answers from companies in similar positions to yours.
Make your decision. You may find that you need two different processors, or at least two strikingly different variants for your two different families of products. You'll probably either have to accept that, or accept higher per-piece price on one or both variants.
3a. You may find that the best decision you can make is one of the processors that you're already using.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
Making this a _requirement_ right off the bat is quite certainly a seriously bad idea. You're trying to save money at the wrong end. Even seemingly expensive tools are cheap, compared to the costs of project failure or loss of productivity.
Huh? Interchangeable with what? How does this make sense in a plan to become a one-architecture shop?
You already said that. Twice.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
The economics of C compilers are, "Can it save the loaded costs of 1-2 man days?". If it can the cost of the C compiler and the application development support that comes with it will make you money.
Just two example: fujitsu series MB90xxx comes with a free compiler. Very affordable and professional. There's also an integration with a very simple serial ICD. AVR has an affordable gnu compiler...
Interchangeable: i mean the possibility to use same pinout with different micros and different peripheral.
No sourcecode, and if it's downloadable at all, they've hidden that link really well.
So it's only "for free", which is not the same as free software. It gives you all of the drawbacks of a proprietary tool (linked to one OS platform which you may no longer have 10 years down the road), combined with all the drawbacks of free software (no-one to sue for a refund if it didn't live up to its promises).
... and yet, there's another company that made quite a nice business out of selling a better serial ICD at several kilodollars a pop. Guess why?
Availability of free compilers is a good thing. But it's certainly not enough of an argument to disqualify an entire platform from your selection.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
This is a very wide wish-list, and there is no magic bullet. If your task horsepower & memory footprints vary widely, so too will your processor solutions.
The software you are seeking is quite rare: ladder and ST usage is not widespread, so that may actually dictate the processor the most.
Families that have the widest interchangeability' are the 80C51 at the
8 bit end, and ARM7 at the 32 bit end. Look also at freescale, who claim to have pin-compatible 8 & 32 bit models "comming" Zilog look to have a similar multi-family common-tools emerging.
In your market area, 'works properly' and long design life, are normally more important than free/low cost wishes. or are your products open source and GPL ?
I think your point is definitely worth considering. But also keep in mind that such simplifications have almsot become a knee-jerk response to those saying they want a free compiler. The practical realities are more complex than either the OP's point or your point illustrate.
Some initial reactions of mine that I may regret writing to muddy the waters a bit...
(1) Follow the well-worn path: It might very well be a good idea to look for "processor territory" where there is a free C compiler available (GNU or otherwise, I suppose.) If only because that would tend to mean that the processor family has either been around long enough or that it has a sufficient following for that situation to have naturally evolved. Even if you don't actually wind up using the free C compiler tool, just knowing that there is one can be a comfort for those reasons and perhaps more. So I don't _always_ find such a question or requirement necessarily ill-conceived.
(2) Slow and steady wins the race: Having source code freely available for viewing by other programmers may, over enough time, allow the tool to become more robust and acquire features you care about. It's slow, as it is often volunteer effort, but over time this accumulates and builds. And there are many more eyes looking than it is possible for a commercial compiler tool to supply in looking over their own proprietary source code for their commercial compiler. This can mean that a mature product (and I'm thinking of the ARM7/THUMB and GNU compiler at this moment) will have a fairly reliable C compiler in the free version.
(3) Old, but not decrepit: If your product is planned to have a long life -- a hope for at least some embedded products -- then having control over the compiler tool set can be very important in extending the robust life of a product line. I am still to this very day supporting products using the Lattice C compiler, old Intel tools, special customized software to handle the unique OBJ formats of both, etc., all for cross-development to an 8088 processor that is in a custom configuration totally unlike a PC. The ability to archive these tools and to control their installation without support from the companies, long since dead or completely disinterested, has been an important element. A freely available compiler tool can often be archived and, if you can get the source code, even rebuilt from the actual source for new cross-development platforms (should that need arise as time changes the workstation a bit.)
(4) Pulling in two directions: The business model of a commercial software vendor (and this generally includes embedded cross-compiler tool vendors) is actually quite a lot different than the business model of an embedded developer. Dongles, computer-locked registration keys, and various other restrictions have nothing at all to do with the daily business of embedded development and, in fact, actually get in the way of it. Yet the commercial compiler vendor will feel very strongly that these steps are necessary to protect their own health and welfare. So they impose them, despite the difficulties they may pose to a developer, both in the short term and in the long term. This also feeds into (3) above where a robust and long life are desired and where the life of the embedded product _exceeds_ the life of the compiler vendor. What can you do about getting a new registration key when there is no one to call about it, anymore?
(5) Correlary to (4): Price isn't cost: Once you pay your money, you and your tool vendor are in bed with each other. And there are compromises and costs (and benefits, too) to that relationship other than the price of the tool. You buy into an entire marriage, for all the good and bad of it. With free tools, you are on your own but at least you don't have to deal with all the personalities and business needs of some partner who has real, significant, and different interests than yours.
(6) Correlary to (4): Today isn't tomorrow: Businesses go out of business, or people die, or new ownership of compiler products may change their policies including how they interpret old contracts or whether or not those old contracts are even binding on a new corporate owner, etc. And most businesses retain the right to change the business issues with evolving products without any control at all in the hands of their customers/end-users. With free tools, there is no one to jerk your chain five years from now and there never will be. You are in control. That can be good. That can be bad. But there it is.
(7) Cost doesn't necessarily correlate with quality and money doesn't buy love: There isn't some magical linear scale where more money means better quality and that therefore the implication must be true that paying zero means it is the worst tool. Paying someone more money means relatively little, actually. It all depends on the vendor and who they are and why they are in business and how well they manage the money you send them, and less upon the dollar amount you pay. One likes to imagine that the very highest fees can only be sustained if the product is superior. And there is some truth there to that misdirection. But many times one also discovers myriad difficulties with after-sale support and use with the more expensive tools, in cases where the opposite experience holds true when finally forced to take a chance with less costly competition, too.
There is no bright line here. The better choice depends and your own capabilities, the product needs, and the various options available. But one of many considerations includes thinking about various risks and keeping in mind just how much control over your own business interests you hand off to someone else. When you let someone else control your compiler tool, whether a matter of indifference or negligence or careful choice, you bring in an important partner. Their interests will probably both complicate as well as simplify some facets of your own business. There is more than just the price to consider.
I guess there is another point to make. I'm at a point in my own skills where the support I'm likely to get from a compiler vendor for application development won't be of much use. The only thing I use a tool vendor for, and rarely even for that these days, is as a "language lawyer" for their own tool enhancements. I'm not in need of "application development support" now or ever again, I don't think.
So I guess I don't think such a simplified question is the only one to ask, Walter. But it is _one_ possible 2D planar cross-cut through the
3D reality to consider.
Note: In my earlier days, there was no GNU and roughly no possibility of free compilers to be had except those you wrote on your own or got from Dr. Dobbs (or Wirth's PL/0.) But time passes and things change.
Anyway, just some quick, off the cuff comments spurred by the general question of paying for compilers.
Try building a gnu arm toolchain with software floating point, and you change your mind about "mature" ;-) Precious few combinations of gcc/binutils/glibc which will compile. Internal compiler errors are the last thing you want to see after compiling for two hours.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
The fujutsu family does come with a free toolset, which is very good, but the chips can be hard to get. It's an old family as well as being quite slow but otherwise is a good choice.
I might. I actually have written my own low-level FP libraries, in the past. And I did a small version with just a few dozen routines for the MSP-430 (faster than usually available, even from compiler vendors.)
On the other hand, I don't generally 'do' floating point except in the few cases where a wide dynamic range is essential -- and even then, it's custom because I care deeply about the numerical behavior and the usual libraries don't meet my needs, anyway. Data arrives in integer form, leaves in integer form, and is processed in some integer form in between. As a rule.
I've found the ARM tools good.
None of this addresses the real points I made, though.
Keep in mind I'm not arguing against commercial C compilers. I think they are essential, I am VERY glad they exist, I use them, and I want the vendors to do well. So perhaps you may have missed my point. My purpose in writing what I did is to point out that a blind comment _against_ using GNU or a similar approach for tools is very probably an over-simplified one.
The right choice for an application takes some thinking and it is _not_ the case that commercial compilers are _always_ the right choice for every situation. Just wanted to muddy things up a bit, you know.
I used gnu ARM tools for 5+ years (under both Linux and Cygwin) with absolutely no problems. I've also had no trouble with gnu tools for H8 (in use for 3 years) or MSP430 (only in use for a few months). Under somewhat lighter, I also had no trouble with gnu toolchains for AVR, 6812, and 68000. And of course SPARC and IA32 work fine (though I've never used them for embedded stuff).
For the Altera NIOS2 target, gcc builds fine under Linux, but I have problems under Cygwin. Altera seems fairly helpless when it comes to dealing with open-source tools. They've tried as hard as they can to absorb open-source stuff like gcc, eCos, and Linux into their borg-liked combined hardware/software IDE, and they ended up with a giant, unholy mess that's a nightmare to work with.
I've also seen plenty of good commercial compilers. Microsoft C for 8086 (pre "visual") was the best product MS ever sold (or ever will, probably). Mark Williams compiler for '286 was solid as a rock. TI's compiler for the TMS32C3x was decent. Lattice C for 8086 wasn't bad. Tektronix's Pascal compilers for various targets were all terrific. Everybody I talk to has good things to say about Rowley, and I've never heard complaints about IAR's compilers either.
I personally hate anything that's node locked, uses a dongle, or a license server. Life's too short to fight with that sort of stuff -- I don't need to give my money to people who treat me like a theif.
One of the product lines I worked on benefitted quite a bit from the fact that we used the Gnu toolchain and an open-source RTOS (eCos). For a token cost ($100, IIRC), we could provide a customer for whom the default firmware didn't quite do it with a complete set of development tools, RTOS, and sample apps.
--
Grant Edwards grante Yow! It's OKAY --- I'm an
at INTELLECTUAL, too.
visi.com
In general, that's about what I hear from others, as well. My use of GNU tools is limited to just a couple of processors, though. Mostly ARM and x86.
I can believe it. But that is probably an unusual case.
I still use MS VC++ 1.52C (their last 16-bit capable version) for applications development. I also have their prior versions going back to version 4. It's pretty good, though there are a few "internal compiler errors" that are fairly frustrating and bizarre to work around.
That is one I believe I've heard of, but I never did any Atari ST work.
I still use Lattice C, believe it or not. But it's use of registers is nothing like what became the standard in following years. So porting mixed asm/c for Lattice C to some other platform is .. a bit of trouble. Also, Lattice OBJ files may require treatment before being fed to more recent MS linkers.
I haven't used these, though I worked there for a time and live nearby.
The only complaints I've heard about IAR were regarding price and/or support. But my limited experience with IAR has been fairly good, so far. So I'm not assuming any trouble. And the product works.
That's pretty close to my attitude about it. If it were the case that I had no choice at all and was forced to pick only from vendors making my life miserable, then I'd hold my nose and do it in order to go on with life. But luckily, in this day and age, there are so many choices available and it's just not usually necessary to bend over and take it from a vendor. And that's a good thing, I think.
The short of it is that unless others I work with insist, I will select tools that avoid CPU/OS/hardware registration keys and/or dongles and the like. I've worked long enough in the business to have personally lived through the horror story of dealing with products where the vendors no longer exist, have changed their policies, won't return calls about "old products", and in general are useless or worse. I don't need anyone else to tell me about the pain, I've felt it myself, lived through it, and remember it well. So I now place a fairly high value on being in control of my tools.
That can be a consideration. One of many for an application. Which is why I emphasize that wry quips with a sidelong or askant viewpoint directed towards folks asking for a free C compiler should be muted until the fuller picture can arise. There is much to consider and it's not just about the initial price one pays.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.