This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

8051 C complier

Hello all,

I have been programming the 8051 chip using assembly for small programs and applications such as A to D converter, alarm clock, etc. In which I have learned that it is a great pain to do more complicated projects with assembly, as the number of lines of codes get larger and harder to track.

I have downloaded the uVision 4 C complier to try to replace assembly, but I'm having difficulties learning how to use it. I have had C/C++ programming before, but I must admit it has been a while since I used it.

Are there any tutorials on programming the 8051 using C?

Also, I have been trying to duplicate my counter project (counting from 0 to 99 using assembly code) with C. I have it count from 0 to 9, but I could not figure out how to do decimal adjust using C. Any idea? In assembly the code is simply DA

Thanks all,
Woozie

  • First step.

    Learn the operators.

    Then you would know that x % 10 would perform a modulo operation, and extract the least significant decimal value from a number. And you would know that x / 10 would perform (in this case) an integer divide, and throw away the least significant decimal digit - which (if your number is strictly within the 0..99 range) would extract the most significant decimal digit.

    And combining the above knowledge, you would then understand that ((x / 10) % 10) would support numbers larger than 99, and extract the second least significant digit, so if you had the number 12345 (given that x has a data type that can store this, i.e. a 16-bit or larger type and not an 8-bit type) it would first cut away the digit (5) giving 1234 and then extract that last decimal digit (4).

    And you would then also know the meaning of << and understand that (expr) << 4 would multiply that value by 16 by moving the value four steps to the left in the variable, leaving the four lowest bits zero.

    And you would also know that | is a bit-and, so it will merge the bit patterns from the expression to the left, and the expression to the right.

    So suddenly, you would see of the expression takes a numeric value x, splits out the two least significant decimal digits from it, and place them in the high and low nibble of the P1 port.

    The code would be a bit simpler if it could assume that the number is already from the start in the 0..99 range, but as written it allows values larger than 99, by throwing away higher-valued decimal digits.

    C isn't black magic. There are few operators. There are few reserved keywords. Programs are just formed by combining these few LEGO pieces into larger and larger constructs, until you get a program that performs the task at hand.

    So your goal must be to learn what LEGO pieces you have access to. And then figure out how to subdivide your task into smaller pieces until each piece is small enough that you are able to convert that little subtask into individual C statements.

  • "I really appreciated your example code,"

    andrew is absolutely right: you don't need sample code. all you need is to pick up a good C book and understand it.

    at this point, giving you sample code does more harm to you.

  • at this point, giving you sample code does more harm to you.

    I'm not sure I would go THAT far. I think most of us learned a lot of what we know about programming by examining other people's code and trying to figure out how it worked. However, I didn't learn much by asking other to tell me the answers. I worked hard to figure things out for myself.

    The example code I gave is trivial. There's nothing tricky about it. It uses typical C operators. Now it's time for the OP to break out a C book and see what it is that % and / and << do. If he has written assembly code and taken elementary to middle school math, it won't be hard.

    Jon

  • I found it more helpful to learn by looking at other people's code and comparing them to see which one is more efficient. But that's my personal learning style.. I do not wish anybody to give me the entire program to solve my problem, and I didn't ask for one either.

    The only things I wasn't sure about that line of code was the % and <<, but now I know. Thanks for the explanation.

  • "I found it more helpful to learn by looking at other people's code"

    I agree. the downside with that risk, especially by taking a random stranger's code, often out of context or without context, before you have a good understanding of the language, may lead to incorrect understandings.

    what I would suggest is a good class / book in C, and then going through well written code pieces side by side with your book / class materials.

  • "going through well written code pieces"

    The trouble there is: how does a novice know whether code is "well-written" or not?

    And the trouble with a book is that you can't interact with it: you can't ask it to explain again; it can't look at your work to see where you're going wrong; it can't adjust to your particular strengths & weaknesses.

    "what I would suggest is a good class"

    Absolutely!

  • "And the trouble with a book is that you can't interact with it"

    I guess that's why books are useful only for humans, not machines.

  • I mainly used a language reference manual (definitions, not attempts at sample code) and lots and lots of downloaded examples when learning C.

    Since it wasn't embedded programming, I looked for really large programs. If they were easy to understand, I tried to duplicate the constructs and way of writing. If they where not easy to read, I ignored the style but looked for intresting constructs.

    Reading code is a very good way to learn. But it takes lots of code, until our pattern-matching brain starts to be able to detect and categorize what is good and what isn't good.

    One bad thing with books is that lots of book authors don't seem to be good programmers. They know how to produce many pages of text, but can't present elegant code. And are so focused on describing a specific keyword or specific function call that they write "simplified" code that doesn't really do anything. All the time missing all the extras needed for use in an commercial-grade environment.

  • Per,

    I guess somewhere down your rant you let this slip... just pointing it out:

    And you would also know that | is a bit-and, so it will merge the bit patterns from the expression to the left, and the expression to the right.
    

    Oops :)

    George

  • I have this C/C++ pocket reference with definitions of syntax and examples. I could probably do this counter in just C/C++ without any problem. My biggest problem is understanding how to use C/C++ to program the micro controller to do what I wanted to do. Which I learned I needed 8051 headers, and from the way it looks, it seems like the header is a file with all the 8051 registers declared into C variables per the addresses. Hence why I tried to use ACC to do my counter calculation like I did with embedded. But since I can't use ACC directly, I wonder why it is in the header file. Something I need to do some study on.

    As for classes, they can only teach so much. I have not yet taken a class where they teaches me how to program in C to interact with micro controller. Neither are books available.. Anyone knows? Any recommendations?

  • I tried to use ACC to do my counter calculation like I did with embedded. But since I can't use ACC directly, I wonder why it is in the header file.

    For writing in-line assembly.

    Jon

  • Lol - yes, that one slipped. The expression "merge" is compatible with a bit-or, but the text before is not.

  • "Neither are books available."

    there are so many (too many?) of them out there.

    but that's 2ndary. programming a micro controller is no different from programming a regular pc/large computer in that you need to have thought out a structure to your code (aka how are you going to have the computer solve a problem?), and then program individual pieces to actually achieve that goal.

    the distinction here is that with a mcu, you are communicating with the outside world solely with their pins: you create certain patterns on those pins, across time or across multiple pins.

    it is that simple - that's why embedded programmers don't make much money.