Next generation products - microprocessor family

On 2006-08-08, Gian <gianmarcocverde@libero.it> wrote:
>> 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),

> Good observation. Thanks. Wich professional tool is't linked to one OS?

Off the top of my head: GCC, Rowly, Tasking. 

-- 
Grant Edwards                   grante             Yow!  I want EARS! I
                                  at               want two ROUND BLACK
                               visi.com            EARS to make me feel warm
                                                   'n secure!!

Gian wrote:
> 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
> http://www.visi.com/~grante/ladder.pdf 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.

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 ?

-jg

On Tue, 08 Aug 2006 14:54:31 -0400, Walter Banks
<walter@bytecraft.com> wrote:

>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.

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.

Jon

"Gian" <gianmarcocverde@libero.it> skrev i meddelandet 
news:jV6Cg.17394$ZJ6.14649@tornado.fastwebnet.it...
>>> I agree with u but _in my experience_, equation 'free=less professional'
>>> doesn't always works.
>>
>> But neither does your negation of it, which appears to be "free ==
>> better than anything that costs money".
>
> Do you write compilers?
> Sorry I'm just joking!!! :-)
>
> Hans, thanks for your suggestion and best regards,
> Gian.

Walter does, so no need to apologize ;-)

-- 
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 

> (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.

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.

> Jon

-- 
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 

Gian wrote:
> >> Please suggest us a family of micro that has:
> >> - good cost
> >> - integrated CAN bus
> >
> > What would be so bad about an external one?
> Not so bad... just more expensive.
>
> >> - free C compiler
> >
> > 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.
> Just two example: fujitsu series MB90xxx comes with a free compiler. Very
> affordable and professional.

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.

On Tue, 8 Aug 2006 23:59:32 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>> (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.
>
>Try building a gnu arm toolchain with software floating point, and you 
>change your mind about "mature" ;-)

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.

>Precious few combinations of gcc/binutils/glibc which will compile.

I've found the ARM tools good.

>Internal compiler errors are the last thing you want to see after compiling 
>for two hours.

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.

Jon

On 2006-08-09, Jonathan Kirwan <jkirwan@easystreet.com> wrote:

>>Precious few combinations of gcc/binutils/glibc which will
>>compile.
>
> I've found the ARM tools good.

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.

> 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.

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            

On Wed, 09 Aug 2006 02:41:08 -0000, Grant Edwards <grante@visi.com>
wrote:

>On 2006-08-09, Jonathan Kirwan <jkirwan@easystreet.com> wrote:
>
>>>Precious few combinations of gcc/binutils/glibc which will
>>>compile.
>>
>> I've found the ARM tools good.
>
>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).  

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.

>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 can believe it.  But that is probably an unusual case.

>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).

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.

>Mark Williams compiler for '286 was solid as a rock.

That is one I believe I've heard of, but I never did any Atari ST
work.

>TI's compiler for the TMS32C3x was decent.
>Lattice C for 8086 wasn't bad.

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.

>Tektronix's Pascal compilers for
>various targets were all terrific.

I haven't used these, though I worked there for a time and live
nearby.

>Everybody I talk to has
>good things to say about Rowley, and I've never heard
>complaints about IAR's compilers either.

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.

>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.

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.

>> 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.
>
>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.

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.

Jon

I need a website to make some comparison between uPs...
Do you have something to suggest?

Thanks!