Actually, it *is* a reality.  A good C programmer in embedded systems is a

lot easier to find than a competent assembly programmer.  There are projects 
that need to squeeze every last cycle out of a processor (which seems to be 
to be a bad case of under-designing your hardware), but the majority of 
projects (given my 20+ years in the field) is that this is not the case.  

	As such, find someone who needs to change a few version strings, add a 
command, etc, it's a lot easier for someone to come up to speed on a C 
project than an assembly project, especially across different processor 
platforms.

	The assembly purists can shriek all they want (and I used to be one, so I 
know what the hell I'm talking about), but the reality that we get checks 
written to us in is a bit different from the idealistic world they're
living 
in.

	--John
 
On Sunday 13 July 2003 17:55 pm, marksjames2001 wrote:
>  Howdy,
>
>  I thought I'd put my oar in the water on this subject, I'm not a
>  software guru, I'm basically a Power Electronics Consultant who
>  learned programming to do my job better.  I've only worked on small
>  to medium complexity control software for small to medium volume
>  products.  I program in Assembly, Forth and C and the highest volume
>  product that has suffered my programming attention was done in Forth
>  and has (so far) been cloned to the level of only about 60K (not
>  ready for prime time).  The biggest factor I've seen when you
>  compare C to any other language (Assembly included) is that my
>  customers demand that I use C.  No matter how annoyingly I whine,
>  they want C.  They feel that C is the easiest to support and if I
>  get hit by a meteor (or abducted by PETA for eating hamburgers) I'm
>  easily replaceable by a C programmer (I think they are cloned as
>  well).  They have been told that a C embedded application is easier
>  to port than one in Assembly, it doesn't matter the reality,
it's
>  their perception...and they have the money.  I know this is not a
>  sophisticated argument and I apologize if it doesn't elevate the
>  discussion but I tend to listen to my customers even when they start
>  sounding like Homer Simpson.
>  I'd like to add that as I've 'lurked' and listen to
this thread I
>  appreciate the interesting and informed opinions and enjoy the
>  varied and various contibutors.
>
>  Regards,
>  Mark
>
>
>
>
> 
>
>
>
>
>
>
>  .
>
>
>
>  

>> Actually, it *is* a reality.  A good C programmer in embedded
systems is a 
lot easier to find than a competent assembly programmer.  <<

Aye, and that's a sad endorsement when you consider the real paucity of
decent 
C programmers around as well! ;-) 

Joking apart, in my job,  I come across shed loads of programmers of PICs, 
HC08s, AVRs and MSPs etc. It's amazing how many of these engineers, when
they 
have the choice, still use assembly language. I've learned not to assume 
anything anymore! You seem to find that as company size gets bigger, it's 
more likely you'll find people programming in C. In small companies
I'd say 
that at least thirty percent of people use assembly language.   

One of the things that has persuaded me to use C more than I used to is that 
there are a few complier vendors around now that charge sensible prices for 
the compilers.  

	My personal belief is that the reason people use assembly on these is that

the assembly tools are usually free.  Many microcontrollers get wormed into a 
company subversively.  And to do that as at low a cost as possible.  It's 
usually not until a processor becomes "formally adopted" within the
company 
does money get spent for a real tool chain.

	It's also a general observation that the databook with the instruction set
is 
a lot closer the engineer who doesn't know C.  And a lot of the processors 
don't support C that well, particularly the PIC (I never really have 
understoon why people use PICs.  They have a despicable instruction set, 
they're not THAT cost effective.  It simply has to be marketing proganda,
and 
the availability of low cost tools).

	I know very few hardware types that are into high level languages.  I know a 
lot more programmers that do some hardware, or are more like myself, 50/50 
people.  I think the hardware types feel closer to the hardware that they 
understand with assembly.  

	The argument that assembly brings you closer to the hardware is, in my mind, 
complete horse hockey.  Either you understand the hardware, or you don't. 
C 
(and Forth, and other HLLs) allow just as direct register manipulation as 
assembly does, with a few *very* rare exceptions.

	--John

On Sunday 13 July 2003 19:25 pm, Robert Wood wrote:
>  >> Actually, it *is* a reality.  A good C programmer in embedded
systems
>  >> is a
>
>  lot easier to find than a competent assembly programmer.  <<
>
>  Aye, and that's a sad endorsement when you consider the real paucity
of
> decent C programmers around as well! ;-)
>
>  Joking apart, in my job,  I come across shed loads of programmers of PICs,
>  HC08s, AVRs and MSPs etc. It's amazing how many of these engineers,
when
> they have the choice, still use assembly language. I've learned not to
> assume anything anymore! You seem to find that as company size gets bigger,
> it's more likely you'll find people programming in C. In small
companies
> I'd say that at least thirty percent of people use assembly language.
>
>  One of the things that has persuaded me to use C more than I used to is
> that there are a few complier vendors around now that charge sensible
> prices for the compilers.
>
>
>
>
>
>
>
> 
>
>
>
>
>
>
>  .
>
>
>
>  

aekalman wrote:
> --- In msp430@msp4..., Andreas Schwarz
<andreas-s@w...> wrote:
> 
>>??? Now I'm really confused. Andrew tried to explain why C was
> 
> better
> 
>>than assembler for his OS, but nobody was _comparing_ Salvo with C
> 
> or
> 
>>assembler.
> 
> 
> Basically -- I was pointing out that the much-vaunted portability of
> C was a real and considerable benefit in being able to apply the Salvo
> RTOS to a variety of different hardware platforms. In Salvo's case,
> the portability made a huge difference.
> 
> Al's point is that in his opinion, C's portability is overrrated
> because it doesn't yield benefits for the sort of applications he
> writes, with their inherent constraints on size, power and speed. I
> assume he would rate Java's portability as much higher than C's,
if
> only because Java is not (or should not be :-o ) a language for
> embedded systems, with all of the hardware-dependencies that accompany
> such systems, and therefore Java applications are free from the
> worries of interfacing with real hardware. I confess I don't know
> Java, just the hype behind it.

Posts that ask where someone can find Java for PIC's, are to me, 
troglodyte that I am, an indication of the decline in the qualoityb of 
engineers exiting universities these days. I wouldn't even consider 
interviewing anyone who listed java on embedded systems as a 'skill'.
Of 
course this may be a 'skill' that others find desirable.

> > The rest of the discussion seems to have
turned to issues of personal
> preference, and where it makes sense / is necessary to use Assembly
> over C.

The whole point of my original response to Tams post which started this 
thread was exactly that. he was knocking C and C compilers for purely 
personal reasons that had no technical merit. As is my way I threw in  a 
few personal comments. I really didn't interpret your first reply in the 
manner you describe here. Perhaps these rheumy eyes are more 
dysfunctional than I thought.


> At the very least, I hope the thread provided an
impetus to the less
> experienced programmers here to perhaps learn more Assembly if they
> have shied away from it until now ... Assembly certainly has its
> place.

As has C, as I've been at pains to point out on many occasions. I write 
a lot in C, just not for my embedded designs.

Al

marksjames2001 wrote:

> Howdy,
> 
> I thought I'd put my oar in the water on this subject, 

Ha! the elitist rowing fraternity! ;^o

> I'm not a software guru, 

SO! you deny that you are a sticky russian programmer. Gu being sticky 
stuff, and ru being the russian web addrress country code. By the way 
neither am I.

> I'm basically a Power Electronics Consultant
who 
> learned programming to do my job better.  I've only worked on small 
> to medium complexity control software for small to medium volume 
> products.  I program in Assembly, Forth and C and the highest volume 
> product that has suffered my programming attention was done in Forth 
> and has (so far) been cloned to the level of only about 60K (not 
> ready for prime time).  The biggest factor I've seen when you 
> compare C to any other language (Assembly included) is that my 
> customers demand that I use C.  No matter how annoyingly I whine, 
> they want C.  

Your whining skills are obviously deficient! I don't whine, I educate ;@}.

> They feel that C is the easiest to support and if
I 
> get hit by a meteor (or abducted by PETA for eating hamburgers) I'm 
> easily replaceable by a C programmer (I think they are cloned as 
> well).  They have been told that a C embedded application is easier 
> to port than one in Assembly, it doesn't matter the reality, it's

> their perception...and they have the money.  

But, if they had the requisite skills they wouldn't be talking to you, 
hence if you truly consider C to be the best option use another tack. 
"In C I will require this device, whose tools cost XYZ, and which will 
increase the end product cost by N%, and my fee by $100,000". They 
ALWAYS listen when their wallet protests. On the other hand if it can be 
easily done in C with no down side that will reflect on you go ahead and 
do it if you want the contract.

In most cases people are pointed in my direction by disties, or company 
FAE's, or other companies who know me after they've been through the 
usual mill, and the last 2 or 3 companies have blown the budget and 
stuffed up the job. I'm all they can afford (I'm cheap), hence if they

want me they listen. I design what they want, but I do it my way.

> I know this is not a 
> sophisticated argument and I apologize if it doesn't elevate the 
> discussion but I tend to listen to my customers even when they start 
> sounding like Homer Simpson.

You mean Homer isn't a sophisticate, BUGGER! I thought anyone who could 
attract a doll like marge had to be worth emulating.

> I'd like to add that as I've
'lurked' and listen to this thread I 
> appreciate the interesting and informed opinions and enjoy the 
> varied and various contibutors.
> 
> Regards,
> Mark

Al

J.C. Wren wrote:

> 	Actually, it *is* a reality.  A good C programmer
in embedded systems is a 
> lot easier to find than a competent assembly programmer.  There are
projects 
> that need to squeeze every last cycle out of a processor (which seems to be

> to be a bad case of under-designing your hardware), but the majority of 
> projects (given my 20+ years in the field) is that this is not the case.  

I whole heartedly agree with most everything you say, except the last 
sentence above. Sometimes there are absolutely no options available, due 
to either cost constraints or power constraints. In most cases due to 
cost constraints. The biggest single market for embedded  systems (by 
volume) is probably the white goods market, where 2 months extra work is 
nothing compared to adding another 10 cents to the product cost. If 
assembler allows you to fit the product into a $0.50 PIC with just 512 
words of program memory, leaving just a few words spare they would 
rather do that than  move up to a 1k code space processor costing a few 
cents more. Automotive is very similar, but being naturally tied to a 
relatively competent processor, which traditionally was expensive, the 
large comparative drop in the price of higher end processors has largely 
eroded this need. In my own case  I readily admit that I would rather 
use assembler, even on the few projects that don't require ANY 
assembler, simply because I have libraries for nearly everything I might 
want to do, and these are far faster than C. After all, this is, to a 
large extent, one of the main values of C. the fact that it has a 
collection of ready built functions.

Al

J.C. Wren wrote:

> 	My personal belief is that the reason people use
assembly on these is that 
> the assembly tools are usually free.  

Definitely a major consideration when considering a new device for 
inclusion. If the tools are free, or extremely cheap I will almost 
certainly buy the tools and evaluate the part, if they are expensive I 
won't. Since my evaluation typical involves building a real world system 
I've often have a decent collection of converted libraries by the time 
the evaluation is over, and have learnt the instruction set well enough 
to use the device in anger. As I said elsewhere I'm cheap. This would 
apply equally to C though. I've several DSP EVkits, they nearly all come 
with unlimited C compilers, hence $300 for the EV board, assembler, 
programmer and compiler makes it attractive, and usually C the language 
of choice.

> Many microcontrollers get wormed into a  company
subversively. 

Subversive micros, now there's an awesome concept!

> And to do that as at low a cost as possible. 
It's 
> usually not until a processor becomes "formally adopted" within
the company 
> does money get spent for a real tool chain.
> 
> 	It's also a general observation that the databook with the
instruction set is 
> a lot closer the engineer who doesn't know C.  And a lot of the
processors 
> don't support C that well, particularly the PIC (I never really have 
> understoon why people use PICs.  They have a despicable instruction set, 
> they're not THAT cost effective.  It simply has to be marketing
proganda, and 
> the availability of low cost tools).

It used to be HC11's and 8051's, why? Because there were affordable 
enough tools for uni students, or the uni to buy, and, when they entered 
the work force they used what they were familiar with. The PIC was the 
first micro that came out with such low priced tools (MPLAB is free, and 
is still far better than most commercial IDE's), that were so well 
integrated, yet were affordable to hobbyists, and even kids with a 
little spare pocket money. As they moved into the work force what else 
would they use? The STAMP also helped, it made using micros much easier 
for many who might have shied away from assembler or C, as being too 
hard. Once bitten by the bug many felt compelled to move up the chain, 
and stuck with the same micro. The PIC16F84 was probably the worst of 
the PICs, the PIC16C73, even with crash and burn, was a far better 
option, yet the F84 won out, again this gives another pointer, for the 
POIC's popularity, a dirt cheap micro that didn't need a UV eraser,
and 
was in circuit programmable.


Al

After low-cost tools I think the biggest influence driving the use of the
PIC has to be the literally scores of tutorial books on programming it
(mostly in assembly by the way).

--Bruce


> The PIC was the
> first micro that came out with such low priced tools (MPLAB is free, and
> is still far better than most commercial IDE's), that were so well
> integrated, yet were affordable to hobbyists, and even kids with a
> little spare pocket money. As they moved into the work force what else
> would they use? The STAMP also helped, it made using micros much easier
> for many who might have shied away from assembler or C, as being too
> hard. Once bitten by the bug many felt compelled to move up the chain,
> and stuck with the same micro. The PIC16F84 was probably the worst of
> the PICs, the PIC16C73, even with crash and burn, was a far better
> option, yet the F84 won out, again this gives another pointer, for the
> POIC's popularity, a dirt cheap micro that didn't need a UV
eraser, and
> was in circuit programmable.

On Mon, 14 Jul 2003 09:22:09 -0700, Bruce Cannon wrote:

>After low-cost tools I think the biggest influence
driving the use of the
>PIC has to be the literally scores of tutorial books on programming it
>(mostly in assembly by the way).

I'll mention some which *have* been important to the company I
work for, in selecting PICs in the past.  I'm going to avoid
referring to the MSP430 because this is my first project with it
and I do *not* have any track record with TI microcontrollers or
DSPs (I've programmed their DSPs on several occasions, but it
was years ago and I had no visibility on the design end of
things.)

(1)
Our company tends to produce products which are manufactured in
quantities of roughly 500-5000 per year, with most being in the
1000-1500/yr area.  In aggregate, we may combine these products
to find buying powers of some 5000 or so parts per year, but in
general, our purchases don'e make a whit of difference in the
bottom line of the micro manufacturer.  We are considered part
of the business "quantum foam."  Microchip has repeatedly
demonstrated not only a willingness to work with us, but a
factual practice of actually working pretty hard for us when
we've required support.

Unlike Atmel, for example, whose FAE employees and product line
managers are constantly asking us about how much of a difference
we might make to them, even when asking for just two samples to
test out.  I've had one sample request delayed for almost a year
because, it appears, we couldn't promise them a design win or
large quantities.  I perhaps had 5 or 6 discussions with the FAE
and the resulting delay sure seemed to be for that reason.  It's
only my impression, admittedly, from the kinds of questions
being asked and their stated willingness to accelerate things if
I could encourage them with more certainty or bigger numbers.

Microchip has *never* screwed us over for self-interest like
that.  Not once.

(2)
Microchip depends on their microcontroller business.  Atmel (and
I'd suppose, TI, as well) have other fish to fry, so to speak.
This tends to suggest that they'll care a little more about the
micro business across changing circumstances simply because they
have to.  They can't change the shell game around because they
just don't have that many shells to hide things under.  And the
past 15 years have born this predictive theory out.

As an entirely questionable story, which even if only a
half-truth still demonstrates the general point if imperfectly:

A few years ago, for example, Atmel apparently put their small
volume micro customers on hold as they used their FAB capacity
for making cell phone flash.  I read a number of customers
posting that their AT90 AVR line purchases were put on
incredibly long lead times and they simply couldn't get their
products built.  Now, I'd guess that big purchase customers
probably *did* manage to get parts.  But certainly some small
customers were suddenly having an impossible situation to
confront.

As a result, when Microchip puts out a new sampled part, I can
*always* purchase a Pro Mate II module to program it.  It's
supported, from the moment I can get parts.  It may be
expensive, but it's supported.  Further, you can expect the
Picstart+ to get support for it sometime soon afterwards.  A
cheaper path for others willing to wait a bit.

When I want technical support, I just call them.  I have a
number which is always good, gets me through to someone fairly
quickly, the staff in the past has been very well trained and
competent, listen precisely, and they try to help.  I don't have
to "go through my distributer chain" to get support -- Microchip
is there, on the spot, for themselves.  They put themselves on
the line.

(3)
They have reliable parts.  They may be buggy (just as anyone's
parts may be) at times.  But they do come up and run.  I've had
rates of up to 40% bad upon delivery (Analog Devices ADSP-2111
failed basic memory tests on start-up, when they were building
them on their first FAB -- the shift of production to a new FAB
completely fixed the problem.)  I haven't experienced that kind
of issue with Microchip.

[Personally, I think the MSP430 has a very nice advantage with
its fail-safe ring oscillator.  I'm going to be testing its
ability to keep the chip working when I stick a screwdriver
against the external crystal oscillator, someday.]

(4)
They have a wide array of part choices, though not nearly as
wide for flash (sadly) and they are competitive on price.  This
isn't so much a special position of theirs, as Atmel has a wide
array and is also competitive on price, and TI has good pricing,
as well, though not the array of parts for the MSP430, as yet.

---

By the way, low cost tools are often more readily available for
other micros.  Even more so, than the PIC.  And if you want
production quality programming of PICs, you pay a pretty penny
for their Pro Mate II.  Similarly, for their ICE 2000 system
(which *does* have a very nice, long trace buffer, though.)  In
other words, it costs good money to get into the professional
side of Microchip controllers.  But if you need the good
support, it is there for the right price.

Just some non-comprehensive thoughts from someone who has been
using them since Microchip first considered small quantity sales
of the PIC16C54..57.

Jon

That story about Atmel is not fiction. I'm not sure all of what 
parts were affected but I know for a fact that the FPGA 
configuration memories we were buying from Atmel a few years ago 
were put on "hold" because they had promised Siemens something like 
100% of their fab capacity.  Luckily we had enough on hand to get by 
but I am sure there are plenty of customers that got screwed on that 
deal.

--- In msp430@msp4..., Jonathan Kirwan <jkirwan@e...> wrote:
> On Mon, 14 Jul 2003 09:22:09 -0700, Bruce Cannon
wrote:

> 
> As an entirely questionable story, which even if only a
> half-truth still demonstrates the general point if imperfectly:
> 
> A few years ago, for example, Atmel apparently put their small
> volume micro customers on hold as they used their FAB capacity
> for making cell phone flash.  I read a number of customers
> posting that their AT90 AVR line purchases were put on
> incredibly long lead times and they simply couldn't get their
> products built.  Now, I'd guess that big purchase customers
> probably *did* manage to get parts.  But certainly some small
> customers were suddenly having an impossible situation to
> confront.
>