Starting with AVR-GCC. Any suggestions for literature? - Page 1
Forum section: electronics / general

author: FenderBender
author_rank: Super Contributor
timestamp: April 26, 2012, 10:03:20 pm
content: Hi again,I've done a good bit of PC programming in vBasic and a limited amount of programming with Arduino. In general, I do pretty well with it but I don't have too much experience with micro-controller programming. Iwoulduse my Arduino more...but I feel like I would be cheating myself if that makes sense. I'm still in high school and I hope to go to school for EE. I thinkrealprogramming would be of more value to me...but I'm not sure.I'm going to try to get started. I am thinking of using the AVR Dragon programmer which is fairly cheap.Any good references? Or ways to get the programming juices flowing?Thanks.

author: fmaimon
author_rank: Unknown
timestamp: April 26, 2012, 10:13:46 pm
content: Check out the tutorial section of AVRFreaks.net . Lots of good info there.

author: TerminalJack505
author_rank: Super Contributor
timestamp: April 27, 2012, 05:28:08 am
content: Read the AVR-LibC User Manual and the appropriate datasheet. This will cover at least 80% of what you will need to know. Even more if you are using AVR/Atmel Studio since you won't need to know about makefiles and avrdude in that case.

author: McMonster
author_rank: Frequent Contributor
timestamp: April 27, 2012, 07:56:10 am
content: What was said above and WinAVR (if using Windows), Eclipse and AVR Eclipse plugin. No need to care about makefiles, easy fusebit setting, little overhead.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 27, 2012, 09:09:50 am
content: Quote from: FenderBender on April 26, 2012, 10:03:20 pmIs nice to still see people in high school getting into coding. I have to say though this (I don't want to say Arduino snobery) can lead to problems since there are times when an arduino would be perfect to work on.For example, when I was a boywe had a computer call a commodore 64. And if you wanted to hit the road with it you had to carry around a TV set. Today, you can take an ultra book, a Arduino and the usb cable and you can hack yourself crazy.Don't worry about the interface. OK worry because that Arduino IDE is just bloody terrible, but what I'm saying is work on your own coding style. Learn to identify different C coding styles and techniques and pay attention to the way people use comments. This is the most important thing. If you comment your code well you can easily port it to another platform. And understand it later.Also remember to make your code modular so you can swap in and out revisions of parts as needed. Now find an itch to scratch and hit up Google or forums if you get stuck.The best book on programming, if you insist, is this one:http://catb.org/~esr/writings/taoup/html/(The Art Of Unix Programming)Now I realize it's a UNIX book but there is some interesting pros and cons of coding choices formulated to help you decide what kind of coder you are and what to do given a paradox.Nearly all of this book can be applied to the way to program anything. Notice that the philosophy is at odds with corporate electronics design where sharing freely your code and ideas is simply horrifying. Notice also that the author gives away the book on the net for free. But you can but the much more preferred printed version like I did.

author: FenderBender
author_rank: Super Contributor
timestamp: April 27, 2012, 07:50:26 pm
content: Thanks everyone. Yeah I don't really mind Arduino, but I just don't want to have to feel particularly constrained by it. By the time I get a job, Arduino might not even be in existence and there's hardly a company that would give Arduinos do their engineers..I think.Again, I think Arduino is a good intro to programming with MCUs and I've used them. It's not awfully terrible. There are plenty of libraries and support.But somehow, just somehow, I feel like it aint right. Perhaps if I wasn't planning on making a career out of it, I wouldn't be so troubled. But yeahhh

author: FenderBender
author_rank: Super Contributor
timestamp: April 27, 2012, 07:57:22 pm
content: 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 chipCompiler: Is this a separate piece of software from the IDE?Debugger: This is also in software? I heard some MCUs have hardware debugging?Thanks.

author: IanB
author_rank: Super Contributor
timestamp: April 27, 2012, 08:22:41 pm
content: Quote from: FenderBender on April 27, 2012, 07:57:22 pmAll the above terms (except programmer) apply to programming in general and not just micros.IDE: "Integrated Development Environment" -- a code editor, compiler, debugger and everything but the kitchen sink all in one. Think Swiss Army knife. In the old days each tool was separate, until some bright spark had the idea of combining them all together.Programmer: yup, downloads your compiled program into the chip.Compiler: converts your source code into the binary form the chip can execute. (There is usually a "linker" in this process too, but don't worry about that.)Debugger: helps you step through your program line by line when it doesn't work and figure out where you made your mistakes. You can either debug the code in an emulator, or debug it in place on the chip using remote debugging support.

author: IanB
author_rank: Super Contributor
timestamp: April 27, 2012, 08:31:39 pm
content: I first learned about programming when I was 16. In the way that often happens I got the programming bug and went crazy. I spent every available hour in front of the computer writing code.However, although I wrote a lot of programs, many of which actually worked, I didn't do a good job of learning how to program. What I lacked was the ability to break the programming problem down into logical pieces, to construct good modules for each function, and make each module independent of the other modules. I tried, but at age 16 and self-taught, I was woefully lacking in the experience and skills to do it well.In a nutshell, writing good software is an engineering problem. It requires disciplined thought, good problem analysis, careful organization, logical deduction and inference, and careful attention to detail.It honestly doesn't matter what languages, tools, or hardware you use to learn with. The skills everywhere are the same and are transferable.I would recommend you avoid books like "Learning Java" or "Learning C" or "Programming Arduino", and instead consider books like this one:http://www.amazon.com/Structure-Interpretation-Computer-Programs-Engineering/dp/0262011530As a disclaimer I have not read this book (it is on my list), it is a hard book probably, it is an academic book, and you may find it a struggle.However, programming is a discipline, and above all you should try to understand the discipline and not get hung up on tools.

author: TerminalJack505
author_rank: Super Contributor
timestamp: April 27, 2012, 08:39:41 pm
content: If you are just starting to learn programming here's a little advise for you.Get a decent C/C++ programming environment (IDE) for your OS. Use this to 'prove' code that you're not sure of before putting it on a MCU. This will save you a lot of frustration since it can be much more difficult to troubleshoot code on the MCU.If you don't already have a good C/C++ Windows/Linux/OSX IDE then I recommendQt Creator. Don't get hung-up on all the wiz-bang stuff it does. All you need it for is to create command line programs that spit out your debugging statements (via stdio printf or std::cout) and stepping through the debugger.

author: Kremmen
author_rank: Super Contributor
timestamp: April 27, 2012, 09:11:20 pm
content: Quote from: FenderBender on April 27, 2012, 07:57:22 pmMy 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.

author: FenderBender
author_rank: Super Contributor
timestamp: April 27, 2012, 09:24:42 pm
content: 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.

author: TerminalJack505
author_rank: Super Contributor
timestamp: April 27, 2012, 09:41:49 pm
content: 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.ThisAtmel app note might come in handy.

author: Kremmen
author_rank: Super Contributor
timestamp: April 27, 2012, 10:06:00 pm
content: 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.

author: FenderBender
author_rank: Super Contributor
timestamp: April 27, 2012, 11:24:25 pm
content: 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.

author: IanB
author_rank: Super Contributor
timestamp: April 27, 2012, 11:50:48 pm
content: Quote from: FenderBender on April 27, 2012, 11:24:25 pmYou really don't need to worry too much about specialization at the early stages. Keep your thinking broad and it will serve you well.All branches of engineering have much in common; engineering is about understanding and designing complex systems and the rules that govern their behavior. In electrical, mechanical or chemical engineering the rules may be scientific principles like physics or thermodynamics; in software engineering the rules are about logic, abstraction, organization, representation. But real engineering covers many areas. It would be hard to find a hardware project these days that doesn't have a whole lot of software in it.Even the analog/digital divide is fuzzy. If you look close enough digital signals are analog, and sometimes the analog nature really matters. Ideal square waves only exist in textbooks. You will never see one on an oscilloscope.Remember that "big" things are always a challenge for everyone. All big problems are solved by decomposing them into smaller problems that can be worked on individually. Don't be discouraged from attempting something big, just remember to be patient and to tackle it in bite-sized pieces. Everything you learn builds on something you learned before. Every problem is solved by starting at the beginning.So never feel you have to do too much at once, and never feel what you are doing is too simple to be worthy. If it looks interesting and you have not done it before, give it a go and see what lessons you can take away from it.

author: FenderBender
author_rank: Super Contributor
timestamp: April 29, 2012, 01:41:26 am
content: Thanks for all of the advice. My brother has a degree in Civil Engineering and you would assume he would be building bridges or something, designing pavement or something, right? No. He actually works for a company that puts up windmills in the ocean. Weird...So I guess an important thing would be to be able to think like an engineer as that will get the job done.I just visited Rutgers University today which is only about an hour from where I live and I talked to some of the students. I feel like I know a good deal of what some of them are learning and they are 2nd or 3rd year students. Pssh even those grad students whofor some reasonthought I didn't know what a voltage controlled oscillator was... thought he was being so smart.So I'm pretty confident. The only problem now will be those darn Calc classes and then Multi-variable Calc. God help me. I don't hate math, but I'm not a natural born mathematician.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 30, 2012, 07:49:07 am
content: Some time ago I met a Civil Engineer who was working on a big project. His job was to oversee the construction of a new bridge.I asked him about it and he said "The builders start constructing the bridge at each end and meet in the middle.I asked him "Why are there two bridges?""We missed" he said.