Path: Home ==> AVR-EN ==> Mikro beginner ==> Conclusions     Diese Seite in Deutsch (extern): Flag DE Logo

Conclusions from those lectures

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:
  1. 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.
  2. 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?
  3. 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.
  4. 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