Connect with us

Embedded Microcontroler Question

Discussion in 'CAD' started by Constant Velocity, Oct 14, 2003.

Scroll to continue with content
  1. Sorry if this is the wrong place for this question. Does anyone know
    what the most popular language for programming embedded
    microcontrollers is?

  2. C

    Kevin Aylward
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  3. The specific assembler language of each chip.
  4. Dave VanHorn

    Dave VanHorn Guest

  5. Rich Webb

    Rich Webb Guest

  6. Care to support that view with any numbers?

    Kevin Aylward
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  7. Chuck Harris

    Chuck Harris Guest

    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.


    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.
  8. 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
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  9. Mathew Orman

    Mathew Orman Guest

  10. Dave VanHorn

    Dave VanHorn Guest

  11. Steven Swift

    Steven Swift Guest

    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.

  12. "C"
  13. Hal Murray

    Hal Murray Guest

    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"? :)
  14. 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
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  15. David Brown

    David Brown Guest

    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
    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.
  16. 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
    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
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  17. Dave VanHorn

    Dave VanHorn Guest

    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.
  18. Chuck Harris

    Chuck Harris Guest


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

    < 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

    Kevin Aylward
    SuperSpice, a very affordable Mixed-Mode
    Windows Simulator with Schematic Capture,
    Waveform Display, FFT's and Filter Design.
  20. Dave VanHorn

    Dave VanHorn Guest

    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

    Large systems let artless programmers get "something that runs" quickly.
    Small systems weed out artless programmers. :)
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day