Enno:
Programming a microprocessor involves lots of different programs and each does a particular job.
You, the "programmer" see only the interface with more or less language-based information. You tell the rest
of the programs what you want the microprocessor to do.
That language-based program is interpreted and put together by the compiler and its associates. Remember
that the microprocessor understands only binary information; it has no idea what any other language is.
The compiler produces a binary file which is the "program" for the processor. Then it hands it off to another program.
In the case of AVR and ATmel microprocessors, the compiler which translates your language file into binary is the
gnu compiler. The compiler translates the language file to the binary file and hands it off to AVRdude. It is the responsibility
of AVRdude to get the program into the processor.
AVRdude knows that there are 3 program areas in every 8-bit ATmel chip. One is the main flash memory. Another is the
EEPROM memory. And the third is the fuse memory. It looks at the binary file and arranges it so that each area is covered
according to what the compiler has told it. It then connect to the programmer, which is the actual physical connection to the
processor, and uses a protocol to communicate. That involves using a serial clock signal for getting bits of information
into the processor and the miso and mosi signal ports to get and receive the actual binary information. It also knows something
else. It has to identify the processor.
So, the first thing that AVRdude does is to ask the processor (via scl, miso, and mosi) "Who are you?" There is a special area in every
ATmel chip which is programmed at the factory with a number. That number is the ID of the chip. AVRdude knows, because it has been told,
what to expect,i.e., what chip is out there and what the number should be. The chip responds with its ID number and then all is well.
If it doesn't, AVRdude tries up to 10 times to find out what it is. If it doesn't find out, or the answer it gets is "000000", then it gives up and tells
us that it didn't find anything or that it is not what it wanted and it can't go on. Unfortunately, the information AVRdude gives us is pretty cryptic and useless for the
average user...but at least we know something is wrong.
If all is well, AVRdude has identified what chip is out there, and then prepares the physical programmer to transfer its binary information.
It writes flash memory. Then it writes EEPROM memory if it has been instructed to do so. And then it writes to the fuses.
Almost all the information for the operation of the program is contained in the fuse bits. The most important for AVR users is perhaps what oscillator to
use. ATmel chips are capable of operating on an internal oscillator. Usually it is limited to about 8 MHz. It can also operate on an external oscillator,
which can go to 20MHz or so. It knows which to use according to the information in the fuse area.
Now suppose, the program is flashed into memory ok, but the fuse information says "Look for an external oscillator". The processor looks for that oscillator
and if it isn't there...it stops operation. Almost all AVR programs use an external oscillator. That is why one should be present
on the ad-hoc or pc programming board. All Arduinos have one, for instance..
Now as to scl, mosi, and miso, they are used only during the programming of the chip; they disappear (under the supervision of AVRdude) when programming
is finished and verified. The fuses determine which oscillator to use from that point on, and the processor must have some oscillator to operate.
Once programming is finished, the need for the physical apparatus that connects the serial or USB port to the processor is also finished. You can leave
it connected, but it is not doing anything. There is one exception. That port is used for special serial communication between the processor and
the computer. But neither the editor, the compiler, nor AVRdude is involved anymore. That is controlled by yet another program in the whole suite, the serial
communications program is the controller, and the pins Do and D1 (Tx and RX) are the serial port on the processor.
So programming a microcontroller is not exactly a simple process. But most of it is not the responsibility of the user, the programmer. He or she is responsible only
to see that the environment is ok for the other programs to do their job, and to enter the program in a human-readable form. The rest is handled internally and
pretty much invisibly to humans. We can request informational messages to chart progress. And, of course, error messages are automatically
given out to the human user. We see the result of those in all kinds of threads in this list. There is usually a lot of other things involved, but the main thing for the human user
is getting the language part right, and realizing that there are both physical and binary parts to the program. They do most of the work automatically if they are configured right.
Hope this helps.
john
AD5YE
David VK2DMH
Eddie Leighton
Wes WB7BR
Kurt Zimmerman
Jim Sheldon