Path:
Home ==>
AVR-EN ==>
Mikro beginner ==> Conclusions
Diese Seite in Deutsch (extern): 
Controller internal hardware
The AVRs offer a wide variety of built-in hardware for use. With a few configuration
bits this internal hardware can be brought to function as desired. Switching the
internal hardware on and configuring it with a few SBI, CBI, IN or OUT instructions
is simple and straight forward. Assumed that you understand the timer, its modes and
which bit in the configuration port has which consequences if set or cleared. The
whole world of the timer is at your command, not only this small part that your BASIC
compiler offers to you. You can do a lot of things with those timers as has been
demonstrated in the lectures, if you understand the basics of those timers. And those
few instructions that are necessary for that are not high-flying programming art and
intransparent like witches but rather easy to understand.
Only a few hardware features are missing in those 14 lectures. Such as assynchroneous
(UART) and synchroneous communication (e.g. I2C). Who wants to bring 50 controllers
together to control an automobile needs this feature, the homebrewer does not. Only if
he wants to construct a controller farm for his railway model. Or is a computer nerd
that is already satisfied if the controller transmits back the content of a certain
register to the laptop, only to see that it works, but nothing really practicable.
The same type of people love to use another feature of the controller that is
completely missing here: the boot mode. For those who need to change their software
in more than 500 controllers on a nearly daily basis, this feature is highly welcome.
The concept of distributing software with serious bugs has become an industry standard
now-a-days, so the boot mode offers this extensively. Those who want to solve problems
by increasing the number of their problems each time they repair one problem welcome
that. Of course you need the boot mode if you have to repair millions of controllers
that were programmed to swindle about automobile NOx emissions back to a
less-swindling version. Or, in 10 years, to a non-swindling "nothing but the
truth" version. Normal people that are used to write bug-free software do not
need this.
External hardware
This is an issue that needs, and should need, the most brain work. A design error in
the hardware can blast the whole software concept and, in the worst case, causes
compromises in functionality. Those who forgot the bouncing of switches and keys, just
because the key they had tested the software with showed no boucing, will have a hack
of work if the software does not work correct with a different switch. I know what I
am talking about, I have to click the de-alarm key of my wake-up clock at least three
times until the controller accepts that I do not like to be woken up again. This
bouncing only startet after two years, corrosion is a very slow process sometimes.
The
design of external hardware nearly always has consequences for selecting the AVR type,
and for the software as well. I encountered several cases when a small change of the
hardware caused a completely new design of the software. So putting brain into the
design process is a time-and-life-saving approach.
The other side of that, to choose an elefant design to be safe, is pure theory. Why
should one use a 96 pin AVR in an airplane model, of which only 6 pins are useful and
needed (one as pulse input, one as PWM output for motor power, and two each for
elevator and side rudders)? Many people now-a-days using AVRs were socialized by
their Arduino. Not because it is rather practical but just because it is low cost.
And those cannot imagine to design and program controllers for solving real problems.
Just using one LED to debug their software is out of their scope because they are used
to use far more mighty debugging tools. Those are not usable in a small ATtiny10 for
a rudder maschine, because their powerful but extensive libraries do not fit in there.
Program design
Especially for starters this aspect is the most dissuasive. The lengthy code listings
that started in lecture 6 can give the impression that this is all too complicated to
understand. Therefore here the following hints:
- Interrupt driven programs have all the same basic structure. First find out what
the interrupts and their associated routines do and which flags they set. This is
already half the way to fully understanding what is going on.
- The controller hardware is first initilized in the RESET vector. Which internal
hardware is involved there? In which modes run timers, ADCs and other internal
hardware?
- Try to conclude on standard processes using the documentation of the software.
A multiplication routine always looks the same, 18 to 20 instructions for that
belong together, you do not need to understand each of those if the sense of this
code package is clear.
- Try to identify and paint algorithms and to clear the conditions that cause
branching. Identify callings and their input parameters and their output provided.
The basic decision if existing software is usable to solve a task or if a new own
design might be more effective is not simple for a beginner. Very often the decision
to use existing software turns out to be the more complicated way because adjustments
to own needs are too extensive. With increasing experience in design and programming
the decision is clearer: other's horses are not the first choice if you need
reliability.
Design your own from scratch and you can be sure that all your needs are optimally
reached.
Good luck and short debug sessions.
©2017 by http://www.avr-asm-tutorial.net