Suggestions on Learning to C/ASM MCU Programming?

Discussion in 'Embedded Systems and Microcontrollers' started by blah2222, Dec 6, 2010.

  1. blah2222

    Thread Starter Well-Known Member

    May 3, 2010
    554
    33
    Hi, so as of the past month I have been looking all around for a straight to the point step-by-step guide to learning how to program mcu's in C or ASM. Sure, there are a lot of great tutorials on how to get your MCU up and running and how to set up the circuit, but I have yet to find a good tutorial on how to actually access ports/registers on the chip, play around with the internal clock, or even use interrupts. People just seem to hand out their simple code of a light blinker and hope that people can understand what is going on.

    I myself have programmed in C for a while and am comfortable with writing programs for it, but have no idea about utilizing it for the mcu realm. I don't think that it is under ANSI-C and their are so many different libraries, it seems overwhelming.

    I bought myself an Atmel ATmega168 chip and have the AVRISP2 programmer and have been messing around with it, but no really thought process of what is actually going on, just making some lights blink and using code provided by some tutorials...

    I guess my real questions are:

    is there a standard methodology of how this stuff is taught, or does this type of programming have a more "open-sourced" flavor to it, where there is no standard approach?

    Besides the physical port/register names of the mcu's, is the programming just all the same, or do they require different types of structure within C programming?

    And finally, can anyone recommend a well put-together book that goes over this stuff?


    Sorry for the essay, but it's been bugging me as of late.

    Thanks for those who read this,
    JP
     
  2. maxpower097

    Well-Known Member

    Feb 20, 2009
    795
    388
    ..................................................
     
    Last edited: Jan 16, 2011
    blah2222 likes this.
  3. thatoneguy

    AAC Fanatic!

    Feb 19, 2009
    6,357
    718
    Different C compilers have different conventions for accessing the I/O and other hardware onboard the controller.

    Even different compilers for the same family, such as C18, BoostC and MikroC for PIC. They have a lot in common, but at the same time, there is enough that isn't common to make it seem entirely different.

    Not for C itself, that is constant, usually very similar to ANSI C. The difference lies mostly in the compiler libraries and pin definitions. A GREAT example is the "Write to LCD" functions, if the compiler supports them.

    As far as programming in assembly, somebody once likened programming anything complicated in assembly for a PIC to repeatedly stabbing yourself in the face, but harder. (I've found this true on ANY uC, but the banks in the 16xxx Series PICs are a bit much, the 18xxx series don't have nearly as many issues).
     
    blah2222 likes this.
  4. blah2222

    Thread Starter Well-Known Member

    May 3, 2010
    554
    33
    Great replies, thanks! Yeah I figured how many different directions mcu's can go in programming them, bah...

    Do people normally stick to one compiler? Maybe dive into another one, only if there is a helpful library, like you mentioned?

    Also, random question, but can I use my AVRISPmk2 programmer to program PICs or non-Atmel mcu's? That'd save some dough for sure.

    Thanks again,
    JP
     
  5. thatoneguy

    AAC Fanatic!

    Feb 19, 2009
    6,357
    718
    AVR Takes a different programming interface than PICs

    I strongly suggest getting a PICKit 2 orPICKit 3 (both $50 w/demo board) for PIC work. I am strongly biased toward BoostC for code, with MikroC a close second (price kills that choice).
     
  6. maxpower097

    Well-Known Member

    Feb 20, 2009
    795
    388
    ..................................................
     
    Last edited: Jan 16, 2011
  7. wannaBinventor

    Member

    Apr 8, 2010
    179
    4
    As as been stated above, I would strongly suggest against walking down the assembly path.

    I started by learning assembly, and it's all I know. I've gotten into more complicated things and it is just a pain in the butt. It's to the point where I feel like I'd spend a couple of month at least getting back to my current level of skill in assembly, so I'd rather just "punch myself in the face" on a daily basis than go back to spending a day and a half trying to get an LED to flash.

    For instance, in assembly if I want to use an HD44780 based LCD I have to go and make a sub for every character and then program for clocking it into the LCD and what not. Then, after that I have to do something like this:

    CALL H
    CALL E
    CALL L
    CALL L
    CALL O
    CALL GAP
    CALL W
    CALL O
    CALL R
    CALL L
    CALL D

    Whearas is C, I could just do something to the effect of:
    #include <LCD.inc>

    Put (Hello World/n)
     
  8. maxpower097

    Well-Known Member

    Feb 20, 2009
    795
    388
    ..................................................
     
    Last edited: Jan 16, 2011
  9. blah2222

    Thread Starter Well-Known Member

    May 3, 2010
    554
    33
    So there is no real practicality in going through the ASM route for using mcu's?

    Thanks for the replies!
     
  10. thatoneguy

    AAC Fanatic!

    Feb 19, 2009
    6,357
    718
    That's the other part I don't really like about complete programs in microcontrollers, especially in assembly.

    The timing and functions typically aren't all in one neat place where it can be copied and pasted while ignoring the rest of the program.
     
  11. wannaBinventor

    Member

    Apr 8, 2010
    179
    4
    Max I'd love to see that!
     
  12. retched

    AAC Fanatic!

    Dec 5, 2009
    5,201
    312
    Id love to see you:

    ;)
     
  13. thatoneguy

    AAC Fanatic!

    Feb 19, 2009
    6,357
    718
    Even when using C, when working with processing intensive tasks, you will use inline assembly if you are able to do it better than a compiler (99% of the time not). To do assembly better than a compiler, you need to know the intricate makeup of the particular controllers intricacies.

    That said, nearly all C compilers will also give a .asm output of your code, complete with what the C source code instructions generated the .asm lines, sometimes you can see an improvement, but rarely.

    I think the reason AVR is more popular with hobbyists than PICs is the standard of C being the language, rather than assembly. C18 and BoostC have changed that landscape quite a bit, as well as MikroC, but if you are creating an application that will generate revenue for yourself, the licensing for BoostC is the most "generous", and includes a Real Time Operating System. RTOS exit for other C compilers, but aren't "bundled".

    Microchip tends to put most of the example code in assembly, as there are very few (< 50) instructions total to know. This leads many people to think assembly is the only way to program a PIC.

    If you are a hobbyist, it is down to two choices: AVR or PIC for uC level programming, or Arduino or PICAxe or BASICStamp for AVR or PIC "easier" workings, as Arduino, PICAxe, and the BASIC Stamps take away a lot of the hardware/circuit needs and some of the harder programming.
     
  14. maxpower097

    Well-Known Member

    Feb 20, 2009
    795
    388
    ..................................................
     
    Last edited: Jan 16, 2011
  15. maxpower097

    Well-Known Member

    Feb 20, 2009
    795
    388
    ..................................................
     
    Last edited: Jan 16, 2011
  16. rajbex

    New Member

    Nov 2, 2009
    22
    0
    JP,
    Here are some nice tutorials for PIC beginners. These tutorials use MikroC for programming the PIC microcontroller.
    http://embedded-lab.com/blog/?page_id=26

    - Raj
     
  17. blah2222

    Thread Starter Well-Known Member

    May 3, 2010
    554
    33
    Thanks for the link, but it doesn't appear to be working right now.

    EDIT nvm, works... Thanks!
     
    Last edited: Dec 11, 2010
  18. tyblu

    Member

    Nov 29, 2010
    199
    16
    It is good to be familiar with assembly in embedded design so that you understand your disassembled code, especially when debugging. Also, you have more control over the little things, including timing. More control means more responsibility and complexity as well, which is where C steps in. You may also use C++, but that is another topic.

    Make sure you have the correct datasheet. The ATmega168A and 168PA is different from the ATmega168 and 168V? ATmega168 and 168V are "not recommended for new designs" (ie: obsolete).

    These tutorials likely contain everything you need to know: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewforum&f=11 . It's worth browsing through all 5 pages and tab-opening each that looks immediately useful.

    The LCD library you're looking for is written by either "Peter Fleury", which I may have spelled incorrectly. avr-libc also has an LCD demo: http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html .
     
Loading...