Connect with us

Microcontroller Project

Discussion in 'Electronic Design' started by [email protected], Mar 19, 2006.

Scroll to continue with content
  1. Guest


    I am going to do a project using 8051. I plan to work on the Hangman
    game. I intend on interfacing an LED,LCD and a keypad with the

    This is my first course on microcontrollers and I have to submit this
    project in 10 days time. Could you tell me whether it is possible to
    implement this project in such a short span of time?

    Thank you.
  2. Yes, but only someone who knows what they are doing. You almost
    certainly don't have a chance.
    If you switch to a simpler micro and language like a PIC-AXE with BASIC
    you might have a chance.

    Dave :)
  3. Rich Webb

    Rich Webb Guest

    Yes, it is.
  4. Guest

    David L Jones and Rich Webb,

    Thanks for the prompt answers. I had also thought about doing something
    basic like this:

    Use a heat sensor to switch on a fan(maybe a dc motor) when the
    temperature crosses a point. And switch on a light and the fan when a
    "door" opens. Would this be possible to implement in 10 days, by some
    like me? :)
  5. Rich Webb

    Rich Webb Guest

    Whether it's possible in general is answerable. Whether it's possible by
    you is unknown, of course.

    It depends on (a) whether you have some familiarity with the
    microcontroller model of controlling the "embedded peripherals" by
    banging on the registers, (b) have some familiarity with the particular
    layout of the 8051-family, and (c) have some familiarity with the
    assembler and/or C toolchain, such as which header files to use for the
    particular "8051" you actually have, creating the loadable image, and
    getting the run-time image into the execution space of the processor.

    Then comes the issue of dealing with the world outside of the 8051. For
    example switching inductive loads, like DC motors, opens up a whole new
    problem domain. LEDs, keypads, and LCD displays (particularly character-
    based displays) present fewer such issues since they're more or less in
    the digital domain. Keys bounce, though.

    Recommended first step: Just blink an LED, at a visible rate, in an
    endless loop. To get to that point you'll have understood the processor
    instruction set, have gotten the right code in the right place to
    actually run something, have the toolchain up and running, and have
    figured out how to create and then load the executable.

    Recommended second step: Blink the LED but use one of the timers to
    control the blink rate. That covers how to instantiate, use, and return
    from a peripheral interrupt.

    If you can do both steps then the rest is just logic (as long as you
    stay in the digital domain). might have some useful information.
  6. Once again, using an 8051 and with someone as inexperienced as you, the
    answer is no.
    You could do this very easily *without* a microcontroller and built it
    within a matter of hours.

    Do you *have* to use an 8051? or are you free to use any micro?
    Also, what language(s) can you use? Assembler?, C?, BASIC?

    Dave :)
  7. Guest

    Sorry for the late reply.

    Yes, I have to do the project in 8051. I have studied the theory of
    8051, but have very little practical experience.

    As far as languages are concerned, there is no restriction. I am
    planning on using C.

    I decided to try and implement the Hangman game itself. I have a rough
    idea as to what I must do, though I am confused as to how to go about
    it. Could you tell some good resources for 8051 programming in C on the

  8. Keith

    Keith Guest

    Theory? Have you actually programmed a "bit"? If you've done any trivial
    progem and had it work (even flashing an LED), this should be too much of
    a problem.
    I wouldn't. I'd stick with assembler. It's a fairly trivial problem and
    AFAIC a compiler will only get in the way. Again, I haven't seen a good
    problem statement.
    I thought you know about the theory of the 8051. I can give you a big
    hint though; the first instruction is a jump. Setting up the beast is
    a bit strange if you want to use all the features but it's not that tough.
    I have a template I use to do the startup garbage.
  9. In that case a good C compiler will take care of most of the low level
    8051 stuff for you.
    If you are programming in C then your actual program will have little
    to do with the 8051.
    You could write the C program on a PC first, and then port to your
    8051. Instead of writing to the screen you would turn on a LED on a
    port of the 8051, so only a small part of your program should change
    between a PC version and an 8051 version.

    The advantage of using a high level language like C is that you
    shouldn't have to care what micro platform it is used on.

    If you need help with the C code then the 8051 is the least of your

    On the other hand, if your subject is the 8051 micro and it's
    architecture then you won't learn much by doing your program in C. I am
    surprised your teacher is not forcing you to use assembler language.

    Dave :)
  10. Keith

    Keith Guest

    I disagree! A C compiler will just mask the nonsense underneath. It
    *will* come back to bite you (think "stack").
    Again, I disagree. Normally one would assume this, but the 8051 is a
    "special" (as in; designed by a "short-bus" architect) case.
    ....and watch the stack explode. Good idea!
    A naieve statement. "shouldn't?" There's a comforting statement. Very
    few people can write truely platform independant C. ...I'm certainly not
    one, and my bet is that given your statements here that you aren't either.
    Granted, but workign C isn't likely to help him either.
    It's not clear what the issue is here. Perhaps it's to show them what
    they *don't* know? ;-)
  11. Ok, I'm not an 8051 guy, so I'll take your word there is a potential
    issue here.

    Is assembler any different? (especially for a beginner?)

    All things considered a high level language will get a beginner up and
    running much quicker than assembler. Take a look at the popularity of
    the PIC-AXE, there is a good reason why it's popular.
    So what are you saying? That C compilers for the 8051 are no good?
    I find this very hard to believe.
    Many people have said that C on a low end PIC (another so-called
    "crippled" architechture) is useless, but excellent ANSI C compilers
    are available for them, and the low end ones too.
    Once again, what are you saying exactly? Are you saying that no C
    compiler for the 8051 can anticipate a stack overflow and give you a
    Ok, I should have said "shouldn't have to care too much" especially for
    the OP's case of a simple hangman game.
    No C program is ever truely platform independant, but you can go a long
    way to making it so. In many cases only minimal changes are required to
    the code that accesses the hardware, and depending on the program and
    application that can be a tiny percentage of the whole code indeed.

    You'd loose your bet BTW :->

    It ain't that hard if you try, really.
    Maybe not, he'd probably have oodles of problems with the programmer
    settings alone :->
    A smart lecturer indeed then!

    Dave :)
  12. Yes. This is exactly the same type of problem, that appears very
    frequently microcontrollers. In a sense, the compiler can make some things
    vastly easier (lbraries for I/O, maths etc.), but when dealing with a
    microcontroller, you need to have enough awareness of the device hardware
    limitations, to know what to steer clear of, or at least keep a good eye
    on, when writing the code. The ability of a 'high level' language to hide
    the hardware from you, may well be 'great', but it is not infinite...

    Best Wishes
  13. Ken Smith

    Ken Smith Guest

    Next is:
    MOV SP,#StackArea
    I usually put it in subroutines with obvious names. It adds 3 bytes to
    the length of the code but makes it easier to understand.

    If you do much with an 8051, I predict that by the end of the first year,
    you will have a large library of routines you can reuse in the next
  14. Keith

    Keith Guest

    I looked into various compilers when I did a major (~25kloc) 8051
    project a decade ago. The only one that didn't mask the
    limitations (and even advantages) of of the 8051 was PL/M51.
    Yes, because of the need to be keenly aware of the processor
    hardware limitations. The 8051 isn't an ordinary processor. It
    only has 128 bytes of RAM (the variant I used had 256) and the
    stack's gotta fit in there too. When the stack overwrites the
    registers (memory mapped) all sorts of fun things happen.
    An interpreter is a little different case. Were that the choice
    here, I wouldn't have any issue. Assembler is a PITA, but the 8051
    has all that in spades. You really have to understand the memory
    map (IIRC, seven different maps some interrelated) to use it at
    all. A compiler will try to hide much of this.
    I wouldn't advise a novice to use C on an 8051, no. If you're
    *really* good at C it can be done but given the strange
    architecture I don't see what it'll gain over assembler. I don't
    see any real code being portable so why bother?
    All sorts of things exist, many for no good reason. No, I don't
    see any advantage to C on an 8051. I can't speak to the PIC, but
    my guess is it's much the same story.
    No, because stack overflows are run-time events. How is a compiler
    going to anticipate what the program is going to do at run-time.
    They can be made so, or at least C programmers on the comp. groups
    think they do it. ;-) ...but it's usually not worth the bother.
    Again, the 8051 is a strange beast. Much of its utility comes from
    this strangeness (memory mapped registers, bit addressable memory,
    strange and wonderful hardware, etc.). Hiding it isn't a good idea
    and may invite disaster (e.g. stacks creaming registers).
    You just said it can't be done a few lines up; "No C program is
    ever truly platform independant"
    Which is it? ;-)
    There's that too. I wonder what he's going to use as a development
    system. ...edit->compile/link->program eprom->plug->repeat is
    going to be a bitch.
  15. linnix

    linnix Guest

    Yes for paper project. No for real project. You need 10 days of
    design, 10 days of layouts, 10 days of debugging and 10 days of waiting
    for parts. No all of them can be concurrent.

    For example, for our 10 day project (AVR w/ LCD), we decided to change
    parts on day 5 and restarted all other timers. Sometimes, we do that
    more than once as well. By the way, that's not including ordering the
    custom LCD panel, which would take a lot more than 10 days.
  16. I'd then suggst you take a look at some more modern compilers perhaps.
    Countless people use C on the 8051, I'm sure it's not that bad.
    If the stack overflow thing is your only gripe then that's not much of
    a problem.
    You'll get dynamic stack allocation errors on most micros, it's not
    that hard to avoid unless your program is doing something very strange.
    There are great many applications were the stack useage is very
    predictive and guaranteed. Typical rule of thumb is to ensure your
    stack space is twice as big as the largest you'll anticipate using and
    find durign testing. If you use static allocation for everything (and
    you should be on a micro really) then you'll usually know exactly how
    much RAM you have left.
    You can get stack overflow errors on the PIC too, and I've written
    plenty of C programs on that in less RAM than 128bytes.
    There are a lot of 8051 C compilers around and I'm sure a lot of people
    use them without issue.
    So you've been bitten on the stack overflow issue, but I would not use
    that an excuse to stay clear of C.
    Well I can speak for the PIC, it has a notoriously horrible
    architecture that is very "C unfriendly" yet the modern C compilers
    like the HiTech C do a fantastic job.
    I am sure that thousands happily use C on the 8051 without problem.
    There is no real reason to avoid C on any micro when good compilers
    It's called static allocation and knowing what your program does. In
    most programs it's not hard to know the maximum number of stack calls
    you can expect, and good C compilers can detect this and warn you. For
    instance, if you have 10 nested function calls and your stack can only
    support say 8 (after the static variable allocation), the compiler will
    warn you.
    If you are using dynamic allocation for stuff then you are asking for
    trouble on any micro.
    Check out the PIC some day, some said it was impossible to write an
    ANSI C compiler for it, yet many have done it now.
    He'll be playing with that for weeks!

    Dave :)
  17. Keith

    Keith Guest

    The point is that one is *necessarily* doing bit-banging on the
    hardware (the whole point of a uC). C doesn't give much advantage
    and a _lot_ of headaches.
    When the stack overflows you don't see any allocation errors. You
    simply get hosed special purpose memory, or perhaps registers get
    overwritten. This sort of thing is *not* easy to track down and
    for an amateur with no tools it might be a show-stopper. Clearly
    you don't understand the 8051 memory model(s). It is very strongly
    Harvard with very little directly addressable memory, which is
    mapped into several different resources.
    You do realize that the 8051 only has 128 BYTES of memory and the
    stack has to fit in about half of that. Thumbs are harder to hit
    when you can throw mega-giga bytes at the problem. The 8051 ain't
    an x86!
    Now, think about someone who's never used a uC with no tools
    debugging this mess. Assembler is far easier, IMO; the less
    abstraction the better.

    I see no advantage in using C. Portability isn't an issue since
    hardware is the name of the game with uCs. Any abstraction will
    lead to resource conflicts. No, actually, I haven't been bitten by
    stack issues because I've used assembler. I don't let the compiler
    assign *anything*; not even what byte the bits go in.
    I disagree. C has no advantage over a half-decent macro assembler
    and a MAKE utility. Abstraction has a *lot* of disadvantages when
    you're severely hardware constrained. Sure, people use C on 8051s,
    but I suspect for many C is the only tool in their shed.
    You never use conditionals? Your code must be really boring. ;-)
    I guess PCs don't work. The point is that you *CANNOT* do dynamic
    allocation on an 8051. Once you've blown the stack you've eaten
    data with no one to tell you that your foot is gone.
    I would like to work on a PIC, but I've gone up the food chain
    quite a number of steps. ;-)

    I don't envy him, unless he has an ICE of some sort, or at *least*
    a card with a decent monitor (perhaps on-board with an external
    EPROM, which again limits the 8051).
  18. Ok, it looks like this one could never end.
    You are pro-assmebler, I'm pro-C.
    I used to do all my work in assembler unless I started using C and then
    never looked back. I still do some inline assembler where it's called
    for, but that's it.

    There are *massive* advanatges to using C (or another high level
    language) on a micro - speed of development, platform portability
    (which is a BIG requirement for some people), ease of peer review, ease
    of maintenance, easier code-reuse, easier model migration, better code
    visibility to name a few. This is why C compilers are immensely popular
    these days.

    Yes, there are advantages to assembler as well (and disadvantages to
    C), that's why I like many others use the best of both worlds. Making a
    blanket statement like there are *no* advantages to using C is just
    plain rubbish.

    Dave :)
  19. Keith

    Keith Guest

    Why do you snip anything you've said? Are you trying to be cute, or win
    an argument without posting your thoughts?
    For microcontrollers, you bet! C is a waste of resuorces, kinda like
    It *is* called for with these tinker-toys. If you're embedding a real
    processor, I might have a different opinion.
    Ok, you say there are "*massive* advantages", I don't buy it. I've told
    you why I don't buy C for an 8051 for anyone other than a one-trick-pony.
    Pony up!
    You've not offered one, other than some assinine statement
    about "portability". Please! Even you don't believe this.
  20. Keith

    Keith Guest

    I/O libraries only matter if your system has rather standard I/O. This
    isn't normally the case with 8051 sorts of systems. Math isn't something
    any sane person would want to do on an 8051. When it's been required,
    I've found that fixed-point isn't all that tough to do at any precision.
    I learned how to do arithmetic (in arbitrary bases, even) over forty years
    ago. If floats are needed in an 8051 project, some PHB needs to stop
    Agreed. It's just not smart to give up precious resources to a compiler.
    Every *bit* is a precious resource when programming an 8051 (or PIC, I
    presume). OTOH, PC's have *loads* of memory and always have, even when
    "640K was enough for anyone".
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