Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

AVR Microcontroller tutorial

Status
Not open for further replies.

rameshrai

Member
Hi,

I want to learn AVR microcontroller, can anybody recommend me good and easy to understand tutorials or books? I am more worried about learning programming so it would he helpful in that direction.

thanks
 
yo Mister T, I don't have to hear his opinion (although I did, as a courtesy to you) , as I have my own, based on 32+ years of programming. I have used many many many high level languages. Started with PL/M in '82... Intel's macro programming language (and the one I believe C was modeled after as they are both very very close). And because of my assembly background, I could run rings around my C instructor in school, who I could tell only programmed in high level languages, so he had no idea or concept of the hardware involved. Which, knowing the hardware and how a computer works helps you to program better in high or low level languages.

And by the way, anyone who calls someone else a dickhead for having an opinion that is contrary to their own is the real dickhead. I didn't say it was faster, just better. And to call C the 'original programming language' ??? Not only is he a dickhead, but ignorant as well.


Now, shall we tackle PIC vs AVR???
 
Now, shall we tackle PIC vs AVR???
skip to 3:20 for opinions about fanboys who stick with one family of micros.

Anyway.. there are too many PIC vs AVR, and ASM vs C debates already. Both debates are pointless
 
Last edited:
Get something (doesn't matter much what) and work with it. If, at some point, you regret your choice, switch to whatever you feel is better. Hopefully, you'll know enough to make a decision by then.

Besides simple AVRs and PICs, there are lots of MCUs that are way more powerful, for example PIC32 based on MIPS and lots of MCUs based on ARM-Cortex-M. You cannot cover all that ever changing diversity even if you wanted.

As to the C/Assembler question, start from what what you understand better.
 
Just my little take on Dave....

To some points I agree... C is a better language to program Microchip devices... Many of them now have C friendly core's... But If I were to program small memory devices, ASM would be top of my list...

As Dave points out in the video ASM will still be used in timing specific applications... Personally I can't remember the last time I have used ASM within my C code ( with embedded micro's). I used to, a lot with the 8051 stuff. But the pic18 range I use now, low level access with C is simple...

I agree with Mike that calling people for not doing it the way you would is out of order... If programming an entire application in ASM works for you.... Well done!!

My Ex boss couldn't use Hitachi's assembler ( he couldn't get his head around "S" files ) so he programed his entire collection of programs in binary!!! Painstakingly converting Mnemonics into a hex editor and programming eprom after eprom until it ran correctly... No debugger other than the hardware he made.. It was a 16 bit H8/500... That was impressive!! I had to learn this technique so I could make changes to his code.... There was no source code... Just binaries...
 
Hi,


I happened to catch that video just the other day too, even before i saw this thread, and i have to say i had to laugh. That guy makes me laugh and he has some good information so i kinda like his videos.

As far as ASM versus anything else, it's pretty simple really. You use high level language when you can get away with it, and you use ASM when you have to. And of course there are some times when you absolutely must use ASM and there's no way around it other than get someone else to write it for you.

I myself tend to like ASM, but i would never use it for say Windows programming in general, but even there there are exceptions and i have a good example. Back when i was working intensively with a somewhat offbeat language that many people liked at the time there was no way to use Microsoft's COM components in our applications, but since COM is a binary standard we were able to make some ASM routines to handle some of the basic tasks involved. In this case there just was no other way to do it.

But i think his point was more aimed at microcontrollers. He simply thinks it is silly to program in ASM when at least one high level language is available. But that kind of statement requires some qualification to either validate or invalidate it really. For example, if a guy is programming microcontrollers for two weeks he is unlikely to have many routine routines built up in his personal library, while a programmer that has been programming for 2 years is very likely to have routines built up that do just about anything, such that all he has to do is include one in his main program and it flies without too much trouble.

Another viewpoint altogether is that today time is more important than it was back when ASM was first developed. These days the fastest way to do things is the best and sometimes we dont have time to build up regular routines to do everything. It just costs too much to have to delay for too long.

One very bad downside to ASM is that it is not very portable, but subset languages may also not be too portable.

As a person out of the field for a while now i still like ASM but i also like other languages, so i use what is necessary most of the time unless i just want to have a little fun.
 
One very bad downside to ASM is that it is not very portable, but subset languages may also not be too portable.
One problem with C in embedded applications is that many hobbyist write very ugly code. Many times even without trying to understand what the code does (copy-paste). This results ugly unreadable and unportable code.. and this makes many people think that C is ugly and bad language.
 
skip to 3:20 for opinions about fanboys who stick with one family of micros.

Anyway.. there are too many PIC vs AVR, and ASM vs C debates already. Both debates are pointless
I agree with you. People are different: what is hard for some, is easier for others. But he shouldn't be calling them a dickhead.
 
i rather start with C because it would be easier. But I know it is the assembly language that is the actual core to any programming and any serious programmer would go dwell into that and I know this because I had class on intel 8051 class too. But it is because of this difference between high level language and machine language that high level language was developed in the first place. Because I saw the assembly language and I know it would take some time(at least for me) to become familiar with its language I had come here to ask about this.

I am not going too much into microcontroller, just basic. I want to but don't have that time so I am taking the shortest possible path to learning basic things and perphaps C is best choice right now.
 
Well your first stop will be AVR Studio 6..

As you have a bit of 8051 experience, you could try MCU 8051 IDE http://mcu8051ide.sourceforge.net/
It runs with SDCC as well so you can develop in C and get the feel of the language... Its free ( as is AVR studio 6)
 
i rather start with C because it would be easier.

If you think that it is easier, you will hit a wall very fast. C is more intuitive in many ways, but do not expect that you can ignore how the microcontroller works!
When you move to C, it also means that you understand your hardware and you are ready to move on to write software that is well structured and divided to well defined modules.

Good C is all about "separation of concerns". Google it.
https://en.wikipedia.org/wiki/Separation_of_concerns
 
Last edited:
Good C is all about "separation of concerns". Google it.
https://en.wikipedia.org/wiki/Separation_of_concerns

Every programmer strives to break his big program into small, preferably independent pieces, which he can address without being concerned about other pieces. But it's easier said than done. In real word, everything is interdependent and separation is difficult to achive.

C is certainly more difficult to structure than OOP languages.

At the beginning, I wouldn't be concerned about writting a "good" code. But I would suggest writing code rather than copying and pasting other people's code.
 
Every programmer strives to break his big program into small, preferably independent pieces, which he can address without being concerned about other pieces. But it's easier said than done. In real word, everything is interdependent and separation is difficult to achive.

True.. many "professional" programmers struggle with good style and separation of concerns (SoC), which should be the first goal.. after that comes Dependency injection, or Inversion of Control (IoC).
When you learn basics of C programming and then read and learn about those two ideas, then you are on the right way to becoming a good programmer.

And either of those (SoC, or IoC) are only for OOP.. same things can be applied in asm also. If you are a good programmer, and if you care.
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top