Microcontroller Project

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

Yes, it is.

--
Rich Webb   Norfolk, VA

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? :)

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.

--
Rich Webb   Norfolk, VA

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

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

Thanks

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.

--
  Keith

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

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

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? ;-)

--
  Keith

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

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

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

In article , Keith wrote: [....]

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

--
--
kensmith@rahul.net   forging knowledge

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.

;-)

--
  Keith

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.

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

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

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.

8051.

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.

either.

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

--
  Keith

level

*snip*

*snip*

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

level

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

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.

--
  Keith

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

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

--
  Keith