Embedded Microcontroler Question

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

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.

 

[email protected]#[email protected]$%[email protected]$#@# in the programmer's native tongue

 

Almost. Actually it's "Free beer!" in their native tongue...

 

Care to support that view with any numbers?

Kevin Aylward

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.

 

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

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

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.

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

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

 

Assembler.

Sincerely,

Mathew Orman
www.ultra-faster-than-light.com
www.radio-faster-than-light.com

 

Assembler, on five processors.
www.mobilecommand.net

 

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

 

"C"

 

a year or so ago, embedded systems design magazine had some numbers, which

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.

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

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

 

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.

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.

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.

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

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.

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.

 

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.

This is a valid point, if that is indeed the case. I am sceptical on
this actual assertion though.

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.

well, I cant really comment on how often this is the case. But, again,
I'm sceptical.

Yes real projects.

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.

Well, only goes to show that they are a lot of unqualified people
vetting CV's.

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.

Old habits die hard.

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.

Valid point, but grasping a bit I think.

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

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

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

 

It is, imo, for many tasks.

: but then you seem to know nothing

Oh. I see. And your evidence for that would be?

No idea what your talking about. I have never written a compiler. I
write applications heavily in C++/C.

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.

Oh get real dude.

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.

Ahmmm..

< Nor does a 16Kb printf function.

And you propose that degree educated CS people are all so daft to not
know this?

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.

I agree, that if one is stuck with such a problem, it may be a tad
tricky. And your point would be?

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.

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

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

 

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.