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?
Thanks.
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.
Home
Help
Search
Login
Register
