Electronics > Microcontrollers

Starting with AVR-GCC. Any suggestions for literature?

<< < (3/4) > >>


--- Quote from: FenderBender on April 27, 2012, 07:57:22 pm ---Yeah I think I plan on using AVR Studio 5 so no learning other program quirks.

There's a bunch of weird terms that even though I think I understand, sometimes I don't.

IDE: PC Software where you actually write your code.
Programmer: Piece of hardware that burns the program to the chip
Compiler: Is this a separate piece of software from the IDE?
Debugger: This is also in software? I heard some MCUs have hardware debugging?


--- End quote ---

My 2 bits.
Practically all microcontrollers have some kind of debugging support built in. The software tools then support more or less of these built in features and add the purely SW ones on top. Typical HW support comes in the form of breakpoints triggered by various events such as program counter pointing to a specific instruction or a given memory address accessed etc.

I like AVR Studio, never mind what certain diehards say. I don't feel the need to mess with makefiles in an environment where the (lack of) complexity does not warrant their use really. That said, you should learn to look under the hood i.e. the project settings for the integrated tools so that you know how to produce the kind of end result you want for each step in the development cycle. For instance while debugging an algorithm or some such you may want to turn optimizations off until the code works. With max optimization levels the code is practically undebuggable. Conversely when the code works you want to max the relevant optimization to see how fast it will be or how much memory it is going to eat. Also in time you will want to understand things like memory maps to see (and again, optimize) the way everything is put in place.

Regarding the tools embedded in a typical IDE, you have the visible front end, i.e. the editor and various views to things like files included in your project, output of builds etc etc. Then there is the compiler that turns your painfully created source code into the machine instructions. The AVR IDE embeds the AVR-gcc compiler for C and C++ that is available as an open source command line version as well. Then there is the gas assembler that handles source files written in the low level assembly code that you may need occasionally. Not as often as some say, though. The gcc is really rather clever at optimizing things and you will be hard put to turn out "better" code except for some very specific cases where human understanding gives an edge.
Finally there is the linker(/locator). This is needed to resolve symbolic references into fixed memory addresses in the various memory spaces. The linker produces the final loadable binary files (the .elf's) but also map files describing what kind of memory segments there were in the application and where those ended up in the address space of the device. LAter you may have specific requirements in that respect and then you will need the compiler and linker directives to make your wishes known to the tools.

A thing about debugging: you always need to do that. There is no piece of code trivial enough that running it through a debugger would not be worth the effort. I keep repeating to my coders that if it aint tested it wont work. Can't remember when was the last time i was wrong on that. So do learn your debugger well so that you are able to use all of its features. As was already pointed out you can debug the code completely inside the IDE without any real hardware at all. This uses the emulated processors embedded in the IDE. It works well for things like calculation algorithms or internal memorty manipulation and anything not directly connected to the real world. You can even emulate external event by manually entering data into the emulated register and I/O space of the virtual processor. What is not easy to do in the emulator is to debug actual hardware circuits. You will not know exact timings and event sequences until the system actually is debugged to completion so emulating that won't work so well. This is where you would builkd a prototype and connect it to the IDE debugger using one of the available methods and hardware tools. Other than that there is no difference in the principle of debugging, things just might happen a lot faster in the real environment of the actual prototype.

I have used the Arduino for a number of small scale projects. I think it is quite OK (except the IDE which is so-so) as far actual programming is concerned. It won't prevent you from applying sound SW development principles and the language is for all intents C++. With minimal tweaks (like 2 lines of code) you can implement the "new" and "delete" operators and then you can instantiate dynamic classes. After that you can do "real" C++ just like AVR Studio (and better in fact. At least studio 4 was hopeless for C++) .
Most of the code written for Arduino that you encounter in the web is trivial and written by tyros with no experience and little skill. That doesn't mean that you cannot do it properly, however.
Then again, i tend not to bother because i don't fancy the Arduino physical implementation. The board itself is a joke as far as any proper design is concerned so i tend to roll my own for each case where one is needed. Just include a JTAG or other Atmel style debuggable connection in the design and you will be all set.

P.S. Oh yes, i almost forgot. Books. Do read "Code Complete" 2nd edition by Steve McConnell / Microsoft Press. It is not at all about anything Microsoft, nor is it a guide to any particular programming language. What it is, is a really good walkthrough on how to properly construct a software application. It teaches sound design principles and is littered with advice on how to avoid "coding horrors" that will bite you in the leg later. Cannot recommend it enough. If you read only 1 book, make it this one. You will be better for it.

Thank you both sooo much for that detail explanation. Exactly what I was looking for. :). Kremmen, I'd have to agree that Arduino is interesting, but no way in hell that you are going to stick a $30 dev board into a normal project. It's not incredibly hard to burn the bootloader etc..but at that point...

Regarding programmer, I did some stuff in Visual Basic. I think I'm pretty good at it, but learning it was made a lot "easier" since I HAD to learn it and there was a structured curriculum. (It was a school course).

I'm busy reading the Avr-Libc User Manual..All 433 pages. Seems rather informative. Just don't know exactly where to start with the whole thing I guess is my problem.

Do you have a programmer or programmer/debugger yet?  If you do then the place to start is to throw a MCU on a breadboard and simply see if you can connect to it with the programmer.

This Atmel app note might come in handy.

Like i said, i tend to roll my own... Arduino is handy for quick trials but not so much for permanent installations.

Regarding reading, i have to say that if you are now burrowing through the libc documentation, you are really taking the bottom up approach. That is useful but i still recommend the book i mentioned in my previous.

I kind of understood that you plan a career in (sw) engineering. If that is so then let me say this: I have been a professional sw development manager in various roles close to 30 years and i have interviewed and hired innumerable more and less experienced programmers. One of the first things i look for in a candidate is an ability to understand sw creation as an exercise in problem solving and the ability to process that problem on a higher level than lines of source code. No significant software application was ever designed in front of the code editor. Many have tried but almost all have failed. Just to put things in perspective here some of those apps i have managed were things that companies like Nokia use (Nokia originally comes from Finland -so do i) , containing tens of millions of source code lines. You don't just write them and be done.
I am sure those interviewers you will encounter will look for similar understanding.

For that reason my recommendation would be not to ignore the low level stuff, but to put it in its proper place; as a means to an end. Once you do start writing the source code you need to understand enough of your tools, say avr-libc, so that you can apply them to the problem at hand. But the solution won''t come from there. The solution will come from the application of design principles (and of course experience, knowledge of the problem domain and all of that stuff). But intimate knowledge of a programming language or tool is never enough to create a proper solution. Knowing how the chess pieces move won't make you a Grand Master. Same thing.

P.S. Nevertheless it is not a bad idea to go with the hands-on approach recommended here, as well. It will keep things concrete and you do need those skills too.

Sure I do plan on buying that book. Seems like a great read.

As of now I don't really plan on being a software engineer (though you can't be certain what the future will hold). To be blatantly honest, I enjoy analog electronics more than digital. However, digital is inevitable, and I will have to be adaptive because who knows where I will land work. I also want to do some of my own projects with micros, but I've always been discouraged from doing anything too big.

For now, I just want a better understanding of programming with micro-controllers as I am sure there will various courses on MCUs in college.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version