Embedded Microcontroler Question

C

Constant Velocity

Guest
Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

Thanks
 
Constant Velocity wrote:
Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

Thanks
C

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
The specific assembler language of each chip.
Jan-Erik.

Constant Velocity wrote:
Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

Thanks
 
On Tue, 14 Oct 2003 17:14:09 -0500, "Dave VanHorn" <dvanhorn@cedar.net>
wrote:

!@#!@$%!!@$#@# in the programmer's native tongue :)
Almost. Actually it's "Free beer!" in their native tongue... :p

--
Rich Webb Norfolk, VA
 
Jan-Erik Söderholm wrote:

Constant Velocity wrote:

Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

The specific assembler language of each chip.
Jan-Erik.
Care to support that view with any numbers?

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
Hi Kevin,

I always tend towards "C" for any embedded work I do,
even on the tiny little PIC processors. But my projects
usually have production runs that number in the tens to
hundreds of units. Programmer time is much more important
than silicon cost in these scales.

However, there are gobs and gobs of very small embedded
processors that do simple mundane tasks like: make a quartz
watch go, or run a blender, or a washing machine, or a TV
remote, or a garage door opener, or make a greeting card hum
Happy Birthday ... that MIGHT be programmed in native
assembler code. Products such as these are produced in such
high quantities that even a slight increase in die size would
cost the manufacturer millions of dollars.

I wonder if there are any accurate numbers out there? I would
certainly be interested in seeing the results of a very large
"volume of production" vs "programming language" poll.

-Chuck

As an aside, the last couple of large volume production, embedded
processor routines that I went snooping around in were definitely
written in assembly code. One was a cell phone, and the
other was a car computer. Both were mid '90s vintage.



Kevin Aylward wrote:
Jan-Erik Söderholm wrote:


Constant Velocity wrote:

Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?


The specific assembler language of each chip.
Jan-Erik.


Care to support that view with any numbers?

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
Chuck Harris wrote:
Hi Kevin,

I always tend towards "C" for any embedded work I do,
even on the tiny little PIC processors. But my projects
usually have production runs that number in the tens to
hundreds of units. Programmer time is much more important
than silicon cost in these scales.
I have done a fair bit of embedded, its was all in C.

However, there are gobs and gobs of very small embedded
processors that do simple mundane tasks like: make a quartz
watch go, or run a blender, or a washing machine, or a TV
remote, or a garage door opener, or make a greeting card hum
Happy Birthday ... that MIGHT be programmed in native
assembler code. Products such as these are produced in such
high quantities that even a slight increase in die size would
cost the manufacturer millions of dollars.
Its not that bad, imo, for most products. Time to market is probably the
most important factor. C is going to be an order of magnitude faster to
write then asm. Secondly, they are millions of C programmers out there,
so getting a programmer is pretty easy. Thirdly, unless your a *good*
asm programmer, I doubt if you will do much better in speed/memory, then
a good C programmer, of which there are loads of them.

I wonder if there are any accurate numbers out there?
I don't know what the number of asm programmers there are, but I bet its
of the order of < 1% of C programmers.

I would
certainly be interested in seeing the results of a very large
"volume of production" vs "programming language" poll.
There is a knew jerk thought of asm=embedded, i.e. memory and speed, but
realistically, most products, imo, don't have this problem today. Memory
is dirt cheap for starters.

-Chuck

As an aside, the last couple of large volume production, embedded
processor routines that I went snooping around in were definitely
written in assembly code. One was a cell phone, and the
other was a car computer. Both were mid '90s vintage.
One issue here is, did it need to be? Old habits die hard. Its hard to
get out of the mindset that speed/mem, is simply not an issue for
many/most products. Its having a product out there, first. Product cycle
times are so short nowadays, that imo, one had better be really sure
that asm is the way to go.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
"Constant Velocity" <nofalloff@knowspam.hotmail.com> wrote in message
news:7k5oovs2fnr3mc9d0dup596a9g1in43147@4ax.com...
Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

Thanks
Assembler.

Sincerely,

Mathew Orman
www.ultra-faster-than-light.com
www.radio-faster-than-light.com
 
Chuck Harris <cfharris@erols.com> writes:

I wonder if there are any accurate numbers out there? I would
certainly be interested in seeing the results of a very large
"volume of production" vs "programming language" poll.
a year or so ago, embedded systems design magazine had some numbers, which
I think they got from a readers poll. I don't remember the exact numbers,
but it was "shockingly" high-- something like 70%-- is still assembly code.

I write more assembly than anything else-- but I am an analog engineer
so working with the "fiddly bits" comes natural.

Steve
--
Steven D. Swift, novatech@eskimo.com, http://www.novatech-instr.com
NOVATECH INSTRUMENTS, INC. P.O. Box 55997
206.301.8986, fax 206.363.4367 Seattle, Washington 98155 USA
 
"Constant Velocity" <nofalloff@knowspam.hotmail.com> wrote in message
news:7k5oovs2fnr3mc9d0dup596a9g1in43147@4ax.com...
Sorry if this is the wrong place for this question. Does anyone know
what the most popular language for programming embedded
microcontrollers is?

Thanks


"C"
 
a year or so ago, embedded systems design magazine had some numbers, which
I think they got from a readers poll. I don't remember the exact numbers,
but it was "shockingly" high-- something like 70%-- is still assembly code.
There is a layer of hacking you can do by counting cycles. I doubt if it's
an important part of the market, but it sure is handy if you are working on
that type of problem.


I write more assembly than anything else-- but I am an analog engineer
so working with the "fiddly bits" comes natural.
Why would an analog geek have anything to do with "bits"? :)


--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
 
Hal Murray wrote:
a year or so ago, embedded systems design magazine had some numbers,
which I think they got from a readers poll. I don't remember the
exact numbers, but it was "shockingly" high-- something like 70%--
is still assembly code.

There is a layer of hacking you can do by counting cycles. I doubt
if it's an important part of the market, but it sure is handy if you
are working on that type of problem.


I write more assembly than anything else-- but I am an analog
engineer so working with the "fiddly bits" comes natural.

Why would an analog geek have anything to do with "bits"? :)
I agree. I don't see any real connection. Analogue is about
approximations and trade offs of numerous physical
properties/constraints. Software is really only about a trade off of
memory and speed.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
"Kevin Aylward" <kevindotaylwardEXTRACT@anasoft.co.uk> wrote in message
news:dCdjb.2249$HM4.1584@newsfep3-gui.server.ntli.net...
Chuck Harris wrote:
Hi Kevin,

I always tend towards "C" for any embedded work I do,
even on the tiny little PIC processors. But my projects
usually have production runs that number in the tens to
hundreds of units. Programmer time is much more important
than silicon cost in these scales.


I have done a fair bit of embedded, its was all in C.

However, there are gobs and gobs of very small embedded
processors that do simple mundane tasks like: make a quartz
watch go, or run a blender, or a washing machine, or a TV
remote, or a garage door opener, or make a greeting card hum
Happy Birthday ... that MIGHT be programmed in native
assembler code. Products such as these are produced in such
high quantities that even a slight increase in die size would
cost the manufacturer millions of dollars.


Its not that bad, imo, for most products. Time to market is probably the
most important factor. C is going to be an order of magnitude faster to
That depends on the complexity of the project, and on the type of chip. On
small projects and small architectures, assembly can be faster to write and
debug (assuming you are familiar with the chip). For some small micros, the
C compilers available are so limited and/or buggy and/or expensive that they
are just not worth the effort (and there are some small micros for which C
compilers don't exist). There is also the consideration of the cost of the
tools - for small budget projects, that can be very relevant. There is also
the reliability and support for the compiler - assemblers tend to be very
simple and therefore reliable, while with a C compiler you may end up
fighting compiler bugs or waiting for supplier support.

For larger chips (especially 16-bit and 32-bit), it's a different matter - C
or another HLL is normally the only sensible choice.

write then asm. Secondly, they are millions of C programmers out there,
so getting a programmer is pretty easy. Thirdly, unless your a *good*
And of these millions of C programs, less than 1% have the experiance or
understanding to work well in embedded systems. When looking at the CV of a
prospective embedded programmer employee, I would not consider experiance
with C as a particular benifit unless it was specifically in embedded
systems.

asm programmer, I doubt if you will do much better in speed/memory, then
Again, that depends on the chips you are working with - I would not expect
to be able to "beat" a PowerPC compiler at code generation, but I would
expect to beat a Pic or COP8 compiler with my eyes closed.

a good C programmer, of which there are loads of them.
It is difficult to determine a good C programmer from a bad one when looking
at potential employees, but the vast majority are not going to be good
embedded C programmers. Of course, that doesn't make it easier to find good
assembly programmers...

I wonder if there are any accurate numbers out there?

I don't know what the number of asm programmers there are, but I bet its
of the order of < 1% of C programmers.
In the embedded world, there are many more assembly programmers than that
(although I have no figures to base that on). It also depends on what you
mean by an "asm programmer" and a "C programmer". I write more code in C
than assembly these days, but I would definitely say I am an experiances
assembly programmer as well as a C programmer. I would also say that the
ability to write and understand assembly programs for a chip is essential to
doing good embedded C programming on the chip.

I would
certainly be interested in seeing the results of a very large
"volume of production" vs "programming language" poll.


There is a knew jerk thought of asm=embedded, i.e. memory and speed, but
realistically, most products, imo, don't have this problem today. Memory
is dirt cheap for starters.
Memory is dirt cheap on large systems - it is not cheap on small systems.
If you are working with a microcontroller with 4k flash and 256 bytes ram,
then that's all you've got, and if some half-wit C programmer uses "printf"
instead of writing their own specialised conversion routines, you end up
needing a bigger and more expensive processor.

-Chuck

As an aside, the last couple of large volume production, embedded
processor routines that I went snooping around in were definitely
written in assembly code. One was a cell phone, and the
other was a car computer. Both were mid '90s vintage.



One issue here is, did it need to be? Old habits die hard. Its hard to
get out of the mindset that speed/mem, is simply not an issue for
many/most products. Its having a product out there, first. Product cycle
times are so short nowadays, that imo, one had better be really sure
that asm is the way to go.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
David Brown wrote:
"Kevin Aylward" <kevindotaylwardEXTRACT@anasoft.co.uk> wrote in
message news:dCdjb.2249$HM4.1584@newsfep3-gui.server.ntli.net...
Chuck Harris wrote:
Hi Kevin,

I always tend towards "C" for any embedded work I do,
even on the tiny little PIC processors. But my projects
usually have production runs that number in the tens to
hundreds of units. Programmer time is much more important
than silicon cost in these scales.


I have done a fair bit of embedded, its was all in C.

However, there are gobs and gobs of very small embedded
processors that do simple mundane tasks like: make a quartz
watch go, or run a blender, or a washing machine, or a TV
remote, or a garage door opener, or make a greeting card hum
Happy Birthday ... that MIGHT be programmed in native
assembler code. Products such as these are produced in such
high quantities that even a slight increase in die size would
cost the manufacturer millions of dollars.


Its not that bad, imo, for most products. Time to market is probably
the most important factor. C is going to be an order of magnitude
faster to

That depends on the complexity of the project, and on the type of
chip. On small projects and small architectures, assembly can be
faster to write and debug (assuming you are familiar with the chip).
Cant agree with this at all. I don't see that size makes any difference
whatsoever. C is a higher level language. Its simpler. End of story.

For some small micros, the C compilers available are so limited
and/or buggy and/or expensive that they are just not worth the effort
(and there are some small micros for which C compilers don't exist).
This is a valid point, if that is indeed the case. I am sceptical on
this actual assertion though.

There is also the consideration of the cost of the tools - for small
budget projects, that can be very relevant.
Oh, come on now. Don't agree here at all. What's a weeks engineering
salary? The cost cannot be an issue, except for schoolboys.

There is also the
reliability and support for the compiler - assemblers tend to be very
simple and therefore reliable, while with a C compiler you may end up
fighting compiler bugs or waiting for supplier support.
well, I cant really comment on how often this is the case. But, again,
I'm sceptical.

For larger chips (especially 16-bit and 32-bit), it's a different
matter - C or another HLL is normally the only sensible choice.
Yes real projects.

write then asm. Secondly, they are millions of C programmers out
there, so getting a programmer is pretty easy. Thirdly, unless your
a *good*

And of these millions of C programs, less than 1% have the experiance
or understanding to work well in embedded systems.
Crap. Smacks of elitism to me. Your view here is simple not credible. A
good programmer can transfer to embedded in about a weak. There is no
magic in embedded whatsoever. Its plain old engineering. If you were
talking about programmers becoming analogue designers, you might have a
point.

When looking at
the CV of a prospective embedded programmer employee, I would not
consider experiance with C as a particular benifit unless it was
specifically in embedded systems.
Well, only goes to show that they are a lot of unqualified people
vetting CV's.

asm programmer, I doubt if you will do much better in speed/memory,
then

Again, that depends on the chips you are working with - I would not
expect to be able to "beat" a PowerPC compiler at code generation,
but I would expect to beat a Pic or COP8 compiler with my eyes closed.

a good C programmer, of which there are loads of them.

It is difficult to determine a good C programmer from a bad one when
looking at potential employees,
Agreed.

but the vast majority are not going
to be good embedded C programmers.
In my opinion, this opinion of yours is total crap. I think your idea of
embedded is rather restricted. Essentially, its any computer in a box
controlling hardware.

Of course, that doesn't make it
easier to find good assembly programmers...


I wonder if there are any accurate numbers out there?

I don't know what the number of asm programmers there are, but I bet
its of the order of < 1% of C programmers.


In the embedded world, there are many more assembly programmers than
that (although I have no figures to base that on).
Old habits die hard.

It also depends
on what you mean by an "asm programmer" and a "C programmer". I
write more code in C than assembly these days, but I would definitely
say I am an experiances assembly programmer as well as a C
programmer. I would also say that the ability to write and
understand assembly programs for a chip is essential to doing good
embedded C programming on the chip.
I wouldn't, unless you restricted to like, 1k of memory. There's a lot
more to life than washing machines. There are 1000's of embedded
products were low level knowledge is simply not relevant. You need to
read/write to a hardware port and that's it.

I would
certainly be interested in seeing the results of a very large
"volume of production" vs "programming language" poll.


There is a knew jerk thought of asm=embedded, i.e. memory and speed,
but realistically, most products, imo, don't have this problem
today. Memory is dirt cheap for starters.

Memory is dirt cheap on large systems - it is not cheap on small
systems.
Valid point, but grasping a bit I think.

If you are working with a microcontroller with 4k flash and
256 bytes ram, then that's all you've got, and if some half-wit C
programmer uses "printf" instead of writing their own specialised
conversion routines, you end up needing a bigger and more expensive
processor.
I am not really addressing those tiny 4k embedded stuff. I'm talking
about *real* projects. Like for example, I use a hardware MIDI sound
player/file player. It comes with 8MB of flash just to save the midi
files on. It would be bloody daft to write this product in asm.

Best Regards,

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
I am not really addressing those tiny 4k embedded stuff. I'm talking
about *real* projects. Like for example, I use a hardware MIDI sound
player/file player. It comes with 8MB of flash just to save the midi
files on. It would be bloody daft to write this product in asm.
A great many embedded projects are done with the smallest controllers money
can buy.
These are usually volume applications, and an extra $0.25 on the controller
means an extra $250k in costs. Pretty easy to justify.
 
Kevin,

You have such strong opinions on assembly vs "C" programming
on embedded systems. How many embedded systems have you actually
programmed? (Earlier, you were adamant about how "C++" was
soooo much better than "C", but then you seem to know nothing
about object oriented programming, so you must be writing "C"
for your "C++" compiler, but I digress...)

I have worked with numerous programmers that thought they knew
how to write embedded code using compilers, and virtually all
were wrong. Now how can I say that? Simple, CS courses teach
people to program on large machines where code and data size
are immaterial. There is no incentive to a large systems programmer
to look under the sheets and see what the libraries had to do
to make those nice "little" standard functions work; to see what
the compiler writer had to do to make the standard statements
work. Recursion is used extensively by CS students, but has no
place in embedded systems at all. Nor does a 16Kb printf function.
Just that silly little cin>> and cout<< statement pair in "C++"
loads in more crap than a typical embedded system has rom space.
A file system? What's that?

When you are programming an embedded processor that has 25 bytes
of RAM, and 512 words of ROM, you have to look at every statement and
every function you use to see how it will affect the size and speed
of the program. "Preposterous!" you say, "Memory is cheap! Why would
anyone but an idiot use such a brain dead processor!"

Well, because it comes in an 8 pin soic package and costs under a buck
in quantity (12C508 by Microchip). I can fire up my CCI "C" compiler
and write "C" code for it, but I generally run out of RAM before
I get very far. Just to set things up so a "C" program can
run requires initializing ram, setting up a stack frame, and pointer,
setting up a data space, and then preloading the registers so the
program will start off in the right way... All in 25 bytes of RAM!

In assembler, I can easily start this processor up, and not spend
one bit of RAM/ROM space foolishly.

If you had ever programmed an embedded processor in a tiny system
you would know all this, you would be able to form an EDUCATED
opinion. Otherwise, you are just spewing forth garbage.

-Chuck, WA3UQV
 
Chuck Harris wrote:
Kevin,

You have such strong opinions on assembly vs "C" programming
on embedded systems. How many embedded systems have you actually
programmed? (Earlier, you were adamant about how "C++" was
soooo much better than "C",
It is, imo, for many tasks.

: but then you seem to know nothing
about object oriented programming,
Oh. I see. And your evidence for that would be?

so you must be writing "C"
for your "C++" compiler, but I digress...)
No idea what your talking about. I have never written a compiler. I
write applications heavily in C++/C.

I have worked with numerous programmers that thought they knew
how to write embedded code using compilers, and virtually all
were wrong.
So you claim. Now why do I find this hard to believe. Secondly, so what
if there are wrong if there haven't looked at the problem before, it
takes f'all time to brush up. Sorry, mate, as they say, this aint rocket
science.

Now how can I say that? Simple, CS courses teach
people to program on large machines where code and data size
are immaterial.
Oh get real dude.

There is no incentive to a large systems programmer
to look under the sheets and see what the libraries had to do
to make those nice "little" standard functions work; to see what
the compiler writer had to do to make the standard statements
work.
That's correct, one designs for the particular system that was in
engaged at the time. However, this by no means imply that such same
programmers will be complete and utter fools to be unable to spend a
week or so brushing up the trivial methods to save a bit of speed and
space.

Recursion is used extensively by CS students, but has no
place in embedded systems at all.
Ahmmm..

< Nor does a 16Kb printf function.
Just that silly little cin>> and cout<< statement pair in "C++"
loads in more crap than a typical embedded system has rom space.
And you propose that degree educated CS people are all so daft to not
know this?

A file system? What's that?
Ho hummm. Blatant elitism. The idea that a good programmer cannot adapt,
pretty much immediately to the constraints of a different paradigm, is
ludicrous. I simply don't accept that 1 million professional C/C++ non
embedded programmers are as stupid as you claim they are. Sure, not all
are the full shilling, but come on now. Lets talk sense. Programming is
piss easy. I know, its a hobby of mine. I've wrote 100k lines for SS
alone, and whats more, it works.

When you are programming an embedded processor that has 25 bytes
of RAM, and 512 words of ROM, you have to look at every statement and
every function you use to see how it will affect the size and speed
of the program.
I agree, that if one is stuck with such a problem, it may be a tad
tricky. And your point would be?

"Preposterous!" you say, "Memory is cheap! Why would
anyone but an idiot use such a brain dead processor!"

Well, because it comes in an 8 pin soic package and costs under a buck
in quantity (12C508 by Microchip). I can fire up my CCI "C" compiler
and write "C" code for it, but I generally run out of RAM before
I get very far. Just to set things up so a "C" program can
run requires initializing ram, setting up a stack frame, and pointer,
setting up a data space, and then preloading the registers so the
program will start off in the right way... All in 25 bytes of RAM!
Wow, aint you a clever little boy then. Yeah, so your the only one in
the universe that knows how to to a product cost analysis. Your truly
unbelievable. Sorry, sonny boy, been there, done, it, wrote the book, as
have 100,000's of other professional engineers. If only 10% of the 1M+
MS VC++ programmers are competent, that's still a huge number that could
do embedded, with a minor refresher.

In assembler, I can easily start this processor up, and not spend
one bit of RAM/ROM space foolishly.

If you had ever programmed an embedded processor in a tiny system
you would know all this, you would be able to form an EDUCATED
opinion.
Of course I know this. Its trivial, and yes, you are correct, I have
never programmed in such a restricted environment, but it has no baring
on whether or not I understand and know the issues involved. My opinion
is an educated opinion. It is one based on the realities that there are
10000s of embedded applications out there that have no such
restrictions. I gave one example, do you want a few more? For example, I
did a lot of work on a HDSL system. Multitasking, all in C but with 100k
of memory. The anticipated numbers were as one would expect from HDLS,
everyone with an internet connection numbers, cost of the memory was
insignificant.


Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.
 
In assembler, I can easily start this processor up, and not spend
one bit of RAM/ROM space foolishly.
I agree.

In a recent application, I had to overlay input buffer, output buffer, and
stack space.
This is probably not even possible with a C compiler.
Fortunately, I know that my input and output buffer size requirements only
conflict at the beginning, when I am (deliberately) using the end of the
output buffer farthest from the input buffer, and that there is no case
where they will actually collide in time.

Same thing with my stack space, I know when I need the most, and that
happens after the input buffer starts clearing out, giving me more space to
grow into.

Of course I could have used a more expensive chip with more ram, and saved a
couple hours of development time, but you only pay the programmer once.


I've also done systems that were extremely speed constrained.
Of course a faster (and more expensive) chip, with more EMI problems, would
have done the job even written in C, but again, you only pay the programmer
once.

Large systems let artless programmers get "something that runs" quickly.
Small systems weed out artless programmers. :)
 

Welcome to EDABoard.com

Sponsor

Back
Top