Brauche eine gute Beratung bzw. Buchempfehlung ATmega8

[Stardust19322]

Hallo.

Ich brauche von euch eine gute Buchempfehlung zu einem ATmega8.
Ich muss allerdings auch dazu sagen, dass ich wahnsinnig vorsichtig geworden bin, was Bücher angeht. Hatte mich vor langer Zeit einmal im Microcontroller-Forum beraten lassen, die Bücher bestellt und konnte schlussendlich weniger als gar nichts damit anfangen.
Darum erhoffe ich mir von euch eine kompetentere Empfehlung und keine Verarsche, nur weil ich Einsteiger bin.

Was ich brauche ist ein Buch, bei dem u.A. auch die ganzen Begriffe sehr gut erklärt, besser noch mit Beispielen versehen sind. Bislang habe ich mit BASCOM programmiert, stehe hier aber an einem toten Punkt, denn für meine Zwecke wird der Programmcode zu umfassend.

Darum möchte ich den Einstieg in C wagen, die Möglichkeiten sind einfach weitaus größer, was kleine Programme mit großer Wirkung angeht.

Ich möchte daher ein Buch, wo C-Grundlagen vermittelt werden, die Bibliotheken eines AVR erläutert werden (insbesondere wozu man diese braucht) und ich auch schnell Fortschritte machen kann. Solche Bücher zur Computer-Programmerstellung brauche ich nicht, darum bitte keine "Hallo-Welt"-Empfehlungen - davon habe ich genug hier zu stehen, danke.

Wo ich hin möchte:

Ich bin Modellbauer und arbeite derzeit an einem Modellboot. Via Mikrocontroller sollen an unterschiedlichen Pins 2 PWM-Eingangssignale von der Fernsteuerung abgefragt werden. Dazu sollen mehrere Taster als Eingänge ständig abfragebereit bleiben. Weiterhin sollen über 2 weitere Pins 2 Servos angesteuert werden können. Dazu soll der Controller auch noch die Beleuchtung des Boots verarbeiten können, sowie eine Akku-Spannungsanzeige auf 2 Eingängen abfragen und auf 10 Ausgängen via Balken-Segmentdisplay visualisieren können. Insgesamt werden später ca. 20 Pins beschaltet. Ein befreundeter Programmierer und Elektro-Ingenieur meinte nun, dass dies alles ein Controller packen würde.

Bislang kam ich mit BASCOM so weit, dass ich Servos ansteuern, PWM-Signale auslesen, als auch den ADC konfigurieren konnte. Nur harmonieren diese ganzen Unterprogramme nicht miteinander. Spätestens beim Einsatz des Servo-Befehls liegt alles lahm.


Daher freue ich mich umso mehr auf eure Empfehlungen, dass ich einen guten und schnellen Einstieg in die C-Programmierung für AVR's schaffe.


LG - Star

 

[gp177]

Hallo Stardust19322,

Buchempfehlungen sind immer so eine Sache ...

Ich programmiere selbst meist in BASCOM und da hätte ich eine Empfehlung:

AVR-Mikrocontroller-Lehrbuch von Roland Walter
Homepage: www.rowalt.de

In diesem Buch geht es hauptsächlich um den Atmega8, d.h. alle Beispielprogramme beziehen sich auf den Atmega8, sind aber prinzipiell auch auf größeren Atmegas lauffähig.
Hier geht es nicht um große Projekte sondern um die einzelnen Funktionsgruppen mit entsprechenden Beispielen.
Ob du nun in BASCOM, C oder Assembler programmierst, ist mehr oder weniger Geschmacksache bzw. eine Frage der Erfahrung.
Gerade bei umfangreicheren Projekten ist es absolut wichtig, die Aufgabe in überschaubare Teilprobleme zu zerlegen und diese nacheiander zu lösen und auch komplett auszutesten.
Wenn man an einen Punkt kommt, wo es scheinbar nicht weitergeht, dann ist der Wechsel der Programmiersprache sicher nicht die Lösung. Wenn es im Speicher des Atmega8 zu eng wird, dann nimm lieber einen größeren Atmega, ggf. die SMD-Variante, wenn der Platz nicht reicht. Manchmal kann es auch sinnvoll sein, bestimmte Aufgaben auf einen kleineren Atmega / Attiny auszulagern, wie z.B. Ansteuerung von Anzeigen ...
In dem Buch geht es auch um Grundlagen wie z.B. Interrupts usw. die solltest du auf jeden Fall verstanden haben, bevor du dich an ein so umfanreches Projekt machst - egal in welcher Programmiersprache.

- gp177 -

 

[LotadaC]

Hallo Stardust, und Willkommen hier.

Ich schließe mich da mehr oder weniger an - ob irgendein C-Buch Dich weiterbringt, kann ich nicht einschätzen. Ich denke jedoch, daß das Forum selbst Dir die Hardware näherbringen kann.

Zu Deinem eigentlichen Problem (meiner Meinung nach):
Du stellst hier mehrere Aufgaben an den Controller, die eigentlich gleichzeitig abgearbeitet werden sollen. Prinzipiell ist der Controller zu echtem (!) Multitasking fähig, aber eben nur bei bestimmten Tasks. Um das mal bei Deinem Mega8 zu zeigen - der verfügt, neben der ALU mit allem was zum Ausführen eines Programmes nötig ist - ein Task sozusagen, über:

• 2 externe Eingänge, die in der Lage sind, das Programm zu unterbrechen
• einen 8bit-Timer/Counter, der allerdings keine weiteren Hardware-Units besitzt. Zumindest kann er beim Überlauf das Programm unterbrechen.
• einen 16bit Timer/Counter, der über 2 Output-Compare-Units und ein Input-Capture-Uniit verfügt. Er kann in 15 unterschiedlichen Modi betrieben werden, und zusätzlich noch die Kontrolle über die OC-Pins des Controllers übernehmen.
• einen weiteren 8bit-Timer/Counter, der ein Output-Compare-Unit besitzt, und immerhin 4 Operationsmodi besitzt. Besonderheit ist hier, daß er die Möglichkeit bietet, selbst über einen Uhrenquarz oä. getaktet zu werden. Also asynchron zum Systemtakt.
• einen Analog-Digital-Converter, der die analoge Spannung unterscheidlicher Eingänge mit einer vorgegebenen Referenz vergleicht, und digitalisiert.
• ein Zweidraht-Interface (TWI bzw IIC), welches eine byteweise Kommunikation unterstützt
• mit dem SPI eine schnelle Kommunikationsschnittstelle, die auch byteweise operiert
• eine vollwertige U(S)ART, die bsich um den ganzen protokollarischen Kram dort kümmert
• einen Analog-Comperator

Alle diese Units arbeiten grundsätzlich unabhängig voneinander (und auch unabhängig vom Hauptprogramm), gleichzeitig. Außerdem sind sie in der Lage, das Programm zu unterbrechen (Interrupt). Alternativ kann das Programm aber stattdessen auch immer mal wieder nachprüfen, ob das entsprechende Hardware-Unit irgendwas fertig hat/erwartet (Polling). Eine spezielle Form des Polling wäre das warten auf ein Ereignis, ohne was zwischndurch zu machen - also wirklich nur warten.

Entscheidend bei der ganzen Sache wird also das Zusammenspiel, die Synchronisation der einzelnen Units mit dem Hauptprogramm. Und da helfen Dir dann vorgefertigte Bibliotheken nicht immer weiter.

Unabhängig von der Sprache muß Dein Konzept in sich erstmal stimmen (welche Hardware steuert/empfängt was, was hat Priorität usw).
Dabei spielt auch die Wahl des Controllers 'ne Rolle (der Mega88 als Nachfolger des Mega8 bietet mehr Hardware, der Mega168 ist ein Mega88 mit mehr Flash,...)

Meiner Meinung nach bietet Assembler ds beste Verständnis für die Hardware, aber das hatte wir hier ja schon oft genug.

Überfliege mal das (richtige) Datenblatt des Controllers - das bringt Dich mMn auch weiter.

Drannbleiben!

 

[Cassio]

........nur weil ich Einsteiger bin.

Bislang habe ich mit BASCOM programmiert, stehe hier aber an einem toten Punkt, denn für meine Zwecke wird der Programmcode zu umfassend.

Darum möchte ich den Einstieg in C wagen......

Hallo!

Ich habe die Beiträge der anderen User jetzt gar nicht gelesen, weil......
für mich klingen deine Zeilen zur zeit eher wiedersprüchlich.


Wie meinst du das denn, dass dein Programmcode zu "umfassend" wird?
Kannst du da mal ein paar Beispiele hier einstellen, oder das mal genauer beschreiben?
Ab wann ist ein Programmcode für dich denn umfangreich?


Bedenken wir doch bitte alle....
er redet vom Mega8 (und nicht vom Mega1284)!


Gruß,
Cassio

 

[LotadaC]

Ich hatte das eher so verstanden, daß er "auslastungstechnisch" an die Grenze kommt, und nicht flashgrößentechnisch. Wobei meiner Meinung nach Die Grenzen im Algorithmus, im Code, und nicht in der Sprache liegen.

...
Bislang kam ich mit BASCOM so weit, dass ich Servos ansteuern, PWM-Signale auslesen, als auch den ADC konfigurieren konnte. Nur harmonieren diese ganzen Unterprogramme nicht miteinander. Spätestens beim Einsatz des Servo-Befehls liegt alles lahm
...

Bascom (und sicher auch andere Hochsprachen) machen es einem mit den vorhandenen Bibliotheken halt leicht, mal schnell irgendwas zusammenzustricken, was eben ganau ein Problem löst. Hat man aber mehrere Probleme gleichzeitig zu lösen, können(!) sich diese vorgefertigten Problemlösungs-Bibliotheken durchaus in die Quere kommen.

Deswegen war mein erster Vorschlag, sich mal ein generelles Bild von den Möglichkeiten der Controller zu machen (und natürlich auch von den eigenen Anforderungen) - danach kann man dann versuchen, diese Möglichkeiten zu nutzen. In welcher Sprache auch immer.
Hilfe wirst Du hier zu jeder erhalten - wenn Du Dich auch selbst bemühst.

 

[oldmax]

Hi
Nun auch von mir einen kleinen Willkommensgruß. Obwohl ich mit C etwas auf dem Kriegsfuß stehe, möchte ich dich ermuntern, diese Sprache zu lernen. Leichter ist da zwar Assembler, und sicher für deine Zwecke gut geeignet, aber wenn du mit C schon ein paar Schritte gegangen bist, ist es vielleicht etwas einfacher. In Assembler aber könnt ich sicherlich ein wenig Hilfe leisten.
Gruß oldmax

 

[Cassio]

Hat man aber mehrere Probleme gleichzeitig zu lösen, können(!) sich diese vorgefertigten Problemlösungs-Bibliotheken durchaus in die Quere kommen.

Hallo!

Hast du da mal konkrete Beispiele?
Würde bestimmt nicht nur mich interessieren, welche LIBs nicht miteinander harmonieren.

Ich denke da spontan eher an ein Timingproblem bzw. einer Timerkollision.

Es hindert ihn aber nichts daran, alle Funktionen und Timings auch in BASCOM von Hand zu erstellen.
Deswegen muss man keine andere Sprache erlernen.

Meiner Vermutung nach liegt das Problem aber sowieso eher an anderer Stelle.


Grüße,
Cassio

 

[LotadaC]

Ist Library vielleicht der falsche Ausdruck gewesen?
In Bascom kennst Du Dich natürlich besser aus, aber... nehmen wir zB mal Timer0:
angenommen, Du willst irgendwelche externen Ereignisse damit zählen, und verwendest "Config Timer0=Counter, blablub"
Und jetzt willst Du meinetwegen noch ein Servo verwenden, mit "Config Servos = trallalla hastenichgesehn".
Beide Teilprogramme für sich laufen, zusammen mMn jedoch nicht. Wenn man die Hilfe genauer liest, bemerkt man, daß beide Timer0 manipulieren, und den haste nunmal nur einmal...
Ähnlich kann das auch mit Timingproblemen sein. Wenn man zB mit irgendner fertigen LCD-Ausgaberoutine 'n paar Zeilen schreiben läßt, oder mit dem einfachen print-Befehl irgendwas über den UART ausgeben läßt. Erst recht wennn der 'ne langsame Baudrate und/oder in Software läuft. (Das hatte ich eigentlich auch gemeint)
Oder, daß getadc auf die Wandlung wartet.
Das alles funktioniert einzeln natürlich, und läßt sich einfach konfigurieren - aber wenns irgendwo zeitkritisch wird, kommt man vielleicht damit nicht immer weiter. Dann hilft es, wenn man weiß, was die Bibliothek/der Config-Befehl wirklich macht, was der Controller wirklich kann.

Ein anderes Beispiel wäre Timer1 (meinetwegen für'ne 2Kanal-Hardware-PWM) und die Verwendung der DCF77-Bibliothek.

Klar kannst Du das alles auch in Bascom schaffen. Ob zu Fuß, über irgendeine alternative Bibliothek, über eine selbstgeschriebene Bibliothek oder wie auch immer. Ich habe ja nicht gesagt, daß er 'ne andere Sprache nehmen soll. Er soll den Controller und dessen Arbeitsweise kennenlernen. Und sich das eigene (gestellte) Problem genauer ansehen. Dann kann man abschätzen, welche vordefinierten Befehle/Libs in dem konkreten Fall Sinn machen, und wo man eben doch selbst Hand anlegen sollte.

Letztendlich habe ich doch dasselbe wie Du gesagt:

Ich hatte das eher so verstanden, daß er "auslastungstechnisch" an die Grenze kommt, und nicht flashgrößentechnisch. Wobei meiner Meinung nach Die Grenzen im Algorithmus, im Code, und nicht in der Sprache liegen.

Irgendwo kollidieren da auch meiner Meinung nach irgendwelche Sachen. Ob das direkt irgendwelche Bibliotheken sind, die dieselbe Hardware nutzen wollen, oder das zeitliche Zusammenspiel (so wie er es umgesetzt hat) einfach nicht paßt, können wir natürlich nur mutmaßen.
Festzuhalten ist, daß die genannte Gesamtaufgabe (Fernsteuerungssignal abgreifen (2 Kanäle), Servos (2) via PWM entsprechend ansteuern, LED-Bargraph und ein paar weitere Ausgaben schalten (LEDs(?))) grundsätzlich durch einen Mega8 zu schaffen sein sollten. Bei den LED- und Schaltungsaufgaben kann dann eventuell (je nach Anzahl) 'n serielles Schieberegister/LED-Treiber-IC/oder so in Betracht gezogen werden.

Ich mach mir für sowas immer erstmal 'ne Skizze wo alle Aufgaben sinnig angeordnet werden, und versuche 'ne brauchbare Zuordnung zu verwendeter Controller Hardware zu finden. Auf Neudeutsch wäre das dann wohl 'ne "Brainstorming-Map" oder so.
Als nächstes käme dann (und davon abhängig) erstmal ein generelles Konzept des Programmablaufes (PAP).

Bis dahin sollte das noch unabhängig von der zu verwendenden Sprache sein... und hier können bereits die Ursachen für die wesentlichen Fehler liegen...

 

[Stardust19322]

Hallo an euch alle und vielen lieben Dank für eure Antworten, Hilfestellungen und Engagement.

Es kam die Frage, wo denn genau die Probleme liegen würden. Dazu Folgendes:

Ich hatte mich eine lange Zeit an die Entwicklung und Verbesserung einer vorgefertigten (Copy & Paste aus dem Netz) Servo-Steuerung mit dem Servo-Befehl gemacht. Leider schien eben genau dieser Befehl den Controller lahm zu legen, sodass in der Zeit, wo das Servo seinen Weg zog (der PWM-Zyklus also fortschritt), dank des ausgelösten Interrupts eben nichts anderes mehr funktionierte.

Mein Plan war, dass ich 2 Servos parallel vom Controller steuern wollte. Nur durch den Druck 2er Taster, also für jedes Servo einen, sollte das Servo vorfahren und in der Position stehen bleiben. Bei erneutem Tastendruck dann wieder in die Ausgangspostion zurück fahren. Allerdings wurde dies zu einer Farce: Das erste Servo fuhr vor, und während es fuhr (es sollte gaaaanz langsam fahren) konnte das 2te Servo nicht angesprochen werden. Erst dann, wenn das Servo seinen Weg beendet hatte, konnte das 2te anfahren - usw. Hinzu kam, dass beim Zuschalten der Versorgungsspannung zum ATMega gern mal die Servos "Überliefen", also in einer unmöglichen Position standen, z.B. direkt am Endanschlag, und es ging dann nichts mehr. Passierte meist dann, wenn das Programm 4KB Code erreichte.


In der Zeit, wo das Servo lief, konnte ich dank des ausgelösten Interrupts auch nichts Anderes mehr machen. Ich konnte keinen Ausgang beschalten (z.B. LED-Ausgänge) und an das Auslesen eines PWM-Signals, geschweige denn dem ADC, war gar nicht mehr zu denken.


Mit BASCOM stehe ich noch recht weit am Anfang. Ich kenne die wenigsten Befehle, muss mir sehr viel aus dem Internet heraus suchen, eben weil mir diese Deppen damals alle das "beste Buch" empfohlen haben und ich am Ende nur Schrott bekam. Entschuldigt, dass ich noch immer ein wenig verärgert darüber bin.


Erfahrungen mit C habe ich noch gar keine. In Assembler hatte ich vor Jahren mal ein wenig hinein geschnuppert. Die Erfahrungen mit BASCOM musste ich mir soweit allein beibringen.


Gibt es denn Bücher, die z.B. nur den ATMega8 betreffen? Und vielleicht sogar in (verständlichem) Deutsch? Das wäre echt super...


Ich habe daheim vorwiegend ATMega8-16PU zu Liegen und möchte diese auch gern für meine Belange verwenden. Zur Not setze ich auch 2 davon auf mein Board in das Modell ein, dass sich einer um den ADC (die Spannungsauswertung am Akku) mit der Ausgabe der entsprechenden LED-Signale, sowie das Überwachen 2er Schaltkanäle, also PWM-Auswertung auf 2 Pins parallel, kümmert, und der andere dann eben nur für die beiden Servos zur Verfügung steht.

Was denkt ihr: Mit BASCOM - einen ADC-Eingang überwachen, daraufhin Ausgänge beschalten ist kein Ding für mich (GetADC). Allerdings 2 Eingänge auf entsprechende PWM-Signale (speziell 1,7-2,0ms High-Flanke und 1,0-1,3ms Low-Flanke) zu überwachen und damit 2 Ausgänge zu beschalten... Möglich oder nicht? Beim ADC wird ja zum Glück kein Interrupt ausgelöst, aber wie schaut das bei den PWM-Eingangsüberwachungen aus?

Oder funktioniert das mit BASCOM nicht mehr...?



LG - Maik

 

[LotadaC]

Hi Maik,

das "Buch", welches nur den Mega8 betrifft, ist das Datenblatt, und eben in Englisch. Trotzdem solltest Du das mal versuchen durchzugehen.Bascom reicht für Dein Problem, logisch. Es tritt jetzt eben nur der Effekt ein, auf den ich die ganze Zeit hinzuweisen versuche.

Zum ADC: klar kann der ADC auch einen IRQ anfordern - getadc nutzt den aber nicht. Getadc startet die Messung (die dann 25 ADC-Takte braucht (mit max 200kHz)), und wartet, bis die Wandlung abgeschlossen ist. Während des wartens passiert nichts weiter - außer eventuellen anderen Interrupts. Wenn der ADC "fertig" signalisiert, liest getadc das Ergebnis aus, weist es der entsprechenden Variable zu, und setzt das Programm fort.
(Kann auch zu Problemen führen, wenn Deine Hauptprogrammschleifezwischendurch irgendwas machen soll (Multiplexing zB), das Programm jetzt aber auf den ADC wartet (wenn ich mich nicht verrechnet habe, dauert die Wandlung so immerhin 125µs. Da passen 'ne Menge Prozessortakte rein...)

Zu den Servos: Config Servos scheint Timer0 (der schwächste Timer des Mega8) zur Generation einer Zeitbasis für ein Software-PWM zu nutzen - bei jedem Überlauf des Timers fällt dann ein IRQ, in dem der PWM-Zähler inkrementiert wird, mit dem Überlaufpunkt verglichen wird (vielleicht), und mit den vorgegebenen Servowerten verglichen werden, um die Pins anzusteuern. Egal, ob sich der Vorgabewert eines Servos ändert, oder nicht.
Du könntest für 2 Servos aber auch Timer1 im Hardware-PWM verwenden (denk ich mal). Im Frequenzkorrekten PWM die 20ms einstellen, und die beiden Output-Compare-Units benutzen. Dann läuft die ganze Sache von selbst im Hintergrund. Ohne Interrupts, ohne Dein Programm zu belasten. Lediglich den jeweiligen neuen Vorgabewert mußt du da ändern.
Allerdings sind damit die beiden OC-Units des Timer gebunden, und dieser läuft halt alle 20ms über (das war doch die Periode der Servos, oder?)
Diese Überläufe kannst Du allerdings trotzdem zur Generation einer Zeitbasis verwenden.

Ob Du nun 'n Mega8 oder 'n anderen Controller nimmst, ist eigentlich erstmal egal - insbesondere in Hochsprachen. Ok, der Mega88 bietet mehr integrierte Hardware, aber die Funktionsweise der Controller ist bei allen irgendwie gleich oder zumindest ähnlich.

 

[gp177]

Hallo Maik,

du schreibst ...

Hinzu kam, dass beim Zuschalten der Versorgungsspannung zum ATMega gern mal die Servos "Überliefen", also in einer unmöglichen Position standen, z.B. direkt am Endanschlag, und es ging dann nichts mehr.

das ist sicher kein Problem der Sprache, hier hast du ein Problem in deiner Schaltung!
Nach dem Anlegen der Betriebsspannung sind die Pins vom Atmega erstmal hochohmig, d.h. dein Servo wird nicht definiert angesteuert, im einfachsten Fall hilft ein Pull-Up bzw. Pull-Down Widerstand.

weiterhin schreibst du ...

In der Zeit, wo das Servo lief, konnte ich dank des ausgelösten Interrupts auch nichts Anderes mehr machen.

Offensichtlich hast du den Sinn von Interrupts noch nicht so recht verstanden.
Interrupts sind dazu da eben nicht auf das Ende einer bestimmten Aktion warten zu müssen. Dazu darf die Interrupt-Service-Routine (ISR) aber nicht das halbe Programm enthalten. Eine ISR sollte immer so kurz wie möglich sein. Diese Problematik wird u.a. auch in dem von mir genannten Buch (siehe einer der vorherigen Antworten) behandelt.

- gp177 -

 

[dino03]

Hallo Maik,

In der Zeit, wo das Servo lief, konnte ich dank des ausgelösten Interrupts auch nichts Anderes mehr machen. Ich konnte keinen Ausgang beschalten (z.B. LED-Ausgänge) und an das Auslesen eines PWM-Signals, geschweige denn dem ADC, war gar nicht mehr zu denken.

Mit BASCOM stehe ich noch recht weit am Anfang. Ich kenne die wenigsten Befehle, muss mir sehr viel aus dem Internet heraus suchen, eben weil mir diese Deppen damals alle das "beste Buch" empfohlen haben und ich am Ende nur Schrott bekam. Entschuldigt, dass ich noch immer ein wenig verärgert darüber bin.

Erfahrungen mit C habe ich noch gar keine. In Assembler hatte ich vor Jahren mal ein wenig hinein geschnuppert. Die Erfahrungen mit BASCOM musste ich mir soweit allein beibringen.

Gibt es denn Bücher, die z.B. nur den ATMega8 betreffen? Und vielleicht sogar in (verständlichem) Deutsch? Das wäre echt super...

wenn du in Bascom bereits ein wenig Grundlage hast, dann ist das immer noch mehr wie deine nicht vorhandene Grundlage in C. Assembler läßt sich in Bascom auch wunderbar einbauen.

Ich habe zB mit Assembler angefangen. Dann habe ich bei der Hochsprache abgewägt ob ich C oder Bascom nehme. Wegen der einfacheren Einbindung von Assembler in Bascom habe ich mich dann dafür entschieden.

Dein Programm läßt sich mit Sicherheit auch in Bascom lösen. Das ist kein Problem.

Nur für Mega8 ein Buch wäre Blödsinn. Die Atmels sind vom inneren Aufbau sehr ähnlich. Wenn du also mal einen verstanden hast, dann kommst du auch mit den anderen Tinys und Megas klar (XMega ist wieder was anderes).

Ich habe mir folgende Bücher besorgt ...

Roland Walter
AVR Mikrocontroller Lehrbuch
Einführung in die Welt der AVR-RISC-Mikrocontroller am Beispieldes ATmega8
ISBN 978-3-9811894-4-5 für 39,-eur

Claus Kühnel
Programmieren der AVR RISC Mikrocontroller mit BBASCOM-AVR
3. erweiterte Auflage
ISBN 978-3-907857-14-4 für 34,95eur

Stefan Hoffmann
Einfacher Einstieg in die Elektronik mit AVR-Mikrocontroller und BASCOM
Systematische Einführung und Nachschlagewerk mit vielen Anregungen
ISBN 978-3-8391-8430-1 für 54,-eur

Das sind die drei "Standardwerke" die dir immer wieder genannt werden.
Sie sind alle auf ihre weise empfehlenswert.

Bei Roland Walter habe ich viele Infos über verborgene Fallstricke gefunden. Daher finde ich es nicht schlecht. Es ist aber auch das älteste der drei Bücher.

Das von Claus Kühnel ist vom Inhalt schon um einiges umfangreicher, etwas neuer und hat auch mehr Beispiele zu weiterer Hardware. Es geht auch sehr schön auf die Innereien der Atmels ein.

Das neueste der drei Bücher von Stefan Hoffmann ist ein sehr gutes Nachschlagewerk mit sehr vielen Beispielprogrammen. Wenn man mal Denkanstöße benötigt wie man etwas im Projekt lösen kann, dann ist das das richtige Buch. Es arbeitet auch viel mit Struktogrammen um unabhängig von der Programmiersprache das Programm zu verstehen.

Ich würde zur heutigen Zeit von meiner Seite aus das Buch von Claus Kühnel als Anfang empfehlen. Es leitet einen schon sehr weit in die Bascom-Programme und auch in die internen Abläufe des Atmels hinein. Als Nachschlagewerk und Inspirationsquelle würde ich danach das von Stefan Hoffmann besorgen. Das Buch von Roland Walter ist auch wirklich gut. Es gibt einige Infos die ich nur dort gefunden habe. Man sollte es also nicht komplett außen vor lassen. Ob man nun Claus Kühnel oder Roland Walter den Vorzug als Einsteigerwerk gibt ist auch Geschmackssache. Da ich mich damals nicht wirklich entscheiden konnte habe ich mir alle drei besorgt.

Gruß
Dino

 

[FreeVEE]

Hallo Maik,


Da ich mich damals nicht wirklich entscheiden konnte habe ich mir alle drei besorgt.

Gruß
Dino

Hallo!

Sehe ich genauso - habe auch alle drei Bücher!
Meistens verwende ich sie nur noch als Nachschlagewerk - schließlich kann man ja nicht alles wissen...

Gerade das Buch von Roland Walter finde ich sehr gut aufgebaut - ganz nach dem Motto "immer schön der Reihe nach".
Aber auch die beiden anderen Bücher sind sehr zu empfehlen.

Kleiner Tipp:
Wichtig und auch unabhängig von der Programmiersprache ist es eine Aufgabenstellung in kleinere Stücke zerlegen zu können - sprich Unterprogramme zu erkennen und umzusetzen. Durch die Kombination der verschiedensten Unterprogramme kann man sich dann oft auch bei neuen Aufgabenstellungen weiterhelfen.

Also ungefähr in der Reihenfolge:
1. Neue Aufgabenstellung => was wollen die von mir?
2. Da war doch was, das hatte ich doch schon mal ...
3. Ja dann nehme ich doch das Unterprogramm aus dem Projekt xy und modifiziere es noch etwas

MfG
FreeVee

 

[dino03]

Hi,

Kleiner Tipp:
Wichtig und auch unabhängig von der Programmiersprache ist es eine Aufgabenstellung in kleinere Stücke zerlegen zu können - sprich Unterprogramme zu erkennen und umzusetzen. Durch die Kombination der verschiedensten Unterprogramme kann man sich dann oft auch bei neuen Aufgabenstellungen weiterhelfen.

stimmt. Die meißten Leute haben Probleme damit eine Aufgabe in Teilstücke zu zerlegen. Man zerlegt zuerst in einzelne Unterprogramme und dann immer weiter bis in die "atomaren" Befehle der Sprache. Bei Basic ist das dann zB ein Print. Bei Assembler muß man selbst das Print noch weiter zerlegen bis in die Assemblerbefehle.

Bei Mikrocontrollern kommt eine weitere Schwierigkeit hinzu. Bei "normalen" Computern geht normalerweise alles schön der Reihenfolge nach. Den Rest nimmt einem das Betriebssystem ab und die Büchse läuft mit einigen Gigahertz. Bei Mikrocontrollern muß man aber auch zeitliche Abhängigkeiten der Programmteile und ihre Laufzeiten mit berücksichtigen und mit den begrenzten Resourcen rechnen. Das wird einem vor allem bei Interrupts vor die Füße fallen wenn man dort schlampt.

Gruß
Dino

 

[LotadaC]

...
Interrupts sind dazu da eben nicht auf das Ende einer bestimmten Aktion warten zu müssen. Dazu darf die Interrupt-Service-Routine (ISR) aber nicht das halbe Programm enthalten. Eine ISR sollte immer so kurz wie möglich sein.
...

Sehe ich nicht so! Von solchen Regularien halte ich nicht viel. Du schreibst das Programm, Du bestimmst was geschehen soll. Wenn Du willst, daß der Controller 'ne Stunde in der ISR verharren soll, dann läßt Du ihn das eben tun.
Das Entscheidende(!) ist, daß Du eben auch die Folgen mit berücksichtigst! Und dazu ist es eben nötig, sich mit der Hardware auseinanderzusetzen. Was macht der Controller eigentlich, wenn ich in Bascom den Befehl xy verwende...

Zum Zerlegen des Problemes:
genau das habe ich doch schon die ganze Zeit gefordert - zeichne das ganze mal sauber strukturiert auf. Welche Informationen sollen wie wo in den Controller rein? Wie sollen die verarbeitet werden? Welche Ergebnisse sollen wie wo wieder raus?
Wie häufig (Frequenz) soll das geschehen?

Welche Teilaufgaben kann man mit integrierter Hardware bereits weitgehend erschlagen (Stichwort Servos und PWM)?

Dann kann man sich um den Algorithmus kümmern, den Programmablauf.

Und wenn das alles steht, kann man anfangen, das zu implementieren - in welcher Sprache jetzt auch immer...

 

[Dirk]

Eine ISR sollte immer so kurz wie möglich sein

Sehe ich nicht so! Von solchen Regularien halte ich nicht viel

Ich finde schon, dass man eine ISR so kurz wie möglich halten soll. Man kann natürlich auch sein komplettes Programm in einer ISR abarbeiten, von mir aus in der ISR selbige sperren und Interrupts global wieder freigeben. Dann hat man eben eine Adresse mehr im Stack

Ich sehe keinen Vorteil darin, mehr als notwendig Programmteile in einer ISR abzuarbeiten. Je weniger Programmteile und je kürzer die Zeit desto besser. Man muss natürlich immer abwägen, welche Teile man in der ISR abarbeitet und welche man im Hauptprogramm abarbeitet, bzw. abarbeiten kann. Entscheindend ist hier u.a. was ist zeitkritisch, lassen sich Programmbereiche einfach genug oder überhaupt teilen, wie ist die Parameterübergabe zwischen ISR, Hauptprogramm und anderen ISRs, wird die Software zukünftig erweitert ...

Dirk

 

[dino03]

Hallo,

Eine ISR sollte immer so kurz wie möglich sein

Sehe ich nicht so! Von solchen Regularien halte ich nicht viel

Ich finde schon, dass man eine ISR so kurz wie möglich halten soll. Man kann natürlich auch sein komplettes Programm in einer ISR abarbeiten, von mir aus in der ISR selbige sperren und Interrupts global wieder freigeben. Dann hat man eben eine Adresse mehr im Stack

So lang wie nötig aber so kurz wie möglich. Es kommt immer auf den jeweiligen Anwendungsfall drauf an. Dinge die zwingend zeitlich mit der ISR zusammenhängen sollte man auch innerhalb der ISR ablaufen lassen. Dinge die aber nicht zwingend zeitlich mit der ISR zusammenhängen kann man problemlos in die Hauptroutine (oder einem Unterprogramm) auslagern um einem anderen Interrupt die Abarbeitung zu gewähren.

Ich habe zB bei mir 10 Soft-PWM Kanäle in der ISR berechnen und abarbeiten lassen. Da diese Arbeiten zeitlich sehr eng mit dem Interrupt zusammenhängen kann man die nicht ins Hauptptogramm auslagern.

Wenn man aber zB einen freilaufenden ADC hat der alle paar Millisekunden einen Interrupt auslöst um seine Daten anzubieten und gleichzeitig jede Sekunde etwas auf dem UART ausgeben möchte, dann sollte man die UART-Ausgabe nicht in der Timer-ISR lassen sondern schon in die Hauptroutine auslagern weil man sonst zu lange den ADC blockiert.

Man muß schon einen Blick auf das Ganze werfen um zu sehen was man sich erlauben kann und was man besser läßt damit die zeitlichen Abläufe im Programm noch passen.

Schwierig sind dabei zB softwaremäßige Sachen wie zB der 1Wire-Bus (DS18S20 Temperaturmesung) und gleichzeitig einen schnellen Timerinterrupt für zB Multiplexing. Da der 1Wire-Bus sein Timing einhalten muß kann man bei einem Buszugriff keine Interrupts zulassen damit der Bus überhaupt funktioniert. Wenn man nun alle Buszugriffe hintereinanderhängt und währenddessen die Interrupts abschaltet, dann hat man ne riesige Lücke in seinen Timerinterrupts für das Multiplexing. Man muß also nach jedem kurzen Buszugriff (nur 1 1Wire-Befehl) dem Timer die Möglichkeit geben das Multiplexing für das Matrixdisplay zu bearbeiten da man sonst Helligkeitsschwankungen oder Ruckler in der Anzeige hat. Hier gilt es also genau die zeitlichen Abläufe im Auge zu behalten.

Wenn man sich zB das 1Wire-Protokoll mal ansieht (Init mal außen vor) dann hat man folgendes Timing ...

;            __                  ___________              _________
; Init/Reset   |________________/           |____________/     :
;              :                :           :            :     :
;              |                |- 15-60us -|- 60-240us -|     |
;              |- >=480us ------|--------- >=480us ------------|
;              |- Master Tx ----|----------- Master Rx --------|
;
;
;           ___                             _______  <1us _______________________
; Master Tx    |___________________________/       |_____/  :        :        :
;              :        :        :        :        :        :        :        :
;              |- 15us -|- 15us -|- 30us -|        |- 15us -|- 15us -|- 30us -|
;              |----- 60-120us -----------|- >1us -|----- 60-120us -----------|
;              |     Slave-Sample^        |        |     Slave-Sample^        |
;              |- Master Write 0-Slot ----|        |- Master Write 1-Slot ----|
;
;
;           ___ >1us                        _______ >1us   ______________________
; Master Rx    |____ ________///////////////       |____ // : :               :
;              :    :   : :               :        :    :   : :               :
;              |- 15us ---|--- 45us ------|- >1us -|- 15us ---|--- 45us ------|
;              |    :   ^Master-Sample    |        |    :   ^Master-Sample    |
;              ##### vom Master generiert          ##### vom Master generiert
;

; ========== DS18S20 - Commands ==========
; 0xF0 - Search ROM		0x44 - Convert T			0x48 - Copy Scratchpad
; 0x33 - Read ROM		0x4E - Write Scratchpad		0xB8 - Recall EEPROM
; 0x55 - Match ROM		0xBE - Read Scratchpad		0xB4 - Read Power Supply
; 0xCC - Skip ROM		0xEC - Alarm Search

Ein Bit dauert also maximal 120µs plus einer minimalen Bus-Ruhephase von 1µs. Diese Zeit sollte von Interrupts frei bleiben. Jetzt muß man noch die Abarbeitungszeit der ISR für das Display-Multiplexing (sagen wir mal 500µs) dazurechnen plus ein wenig Sicherheitspuffer. Als Ergebnis bekommt man die minimale Zeit zwischen den Timerinterrupts für das Displaymultiplexing. In diesem Beispiel wären das mindestens 620µs. Eher 700µs. Man hat also eine Frequenz von maximal 1/700µs = 1,4kHz für das Displaymultiplexing.

Bei der Businitialisierung wird der Timerinterrupt wohl einmalig ein wenig warten müssen. Mit genügend Luft wird es aber nicht passieren das sich die Interrupts gegenseitig überholen Wenn einem aber einmalig ein Interrupt verschluckt wird dann fällt das bei einem Display wohl eher nicht so stark auf.

Gruß
Dino

 

[LotadaC]

Ich bestreite ja den Sinn dieser ... ähm ... Empfehlung gar nicht. Aber es ist ist eben nicht zwingend. Keine Regel, an die man sich halten muß.
Klar, man kann solche Sachen in 'ner kurzen "Regel" zusammenziehen -aber die stimmt eben nicht immer. Als ich in den Anfängen stand, wurde mir eingetrichtert:
-die IVT soll mit Retis gefüllt sein, wo IRQs nicht verwendet werden
-der Stackpointer muß initialisiert werden
usw
(irgendwo hatte ich sogar mal gelesen, daß man ein Bascom-Programm mit'nem "end" terminieren MUSS - auch das ist natürlich falsch...
Man muß halt nur sicherstellen, daß das Programm in geordneten Bahnen bleibt)

Die Regeln stimmen eben nicht - zumindest nicht so grundsätzlich. Man liest es aber an allen möglichen stellen.
Wenn man nämlich als Anfänger versucht, die Regel zu verstehen, ist man eher verwirrt (Warum MUSS ich den SP initialisieren, wenn er das laut Datenblatt vielleicht bereits ist?, Warum MUSS ich Code in der IVT meiden, und darf dort keinen (anderen als Retis) Code platzieren, wenn mein Programm dort nie ankommt?)
'Ne ISR MUSS nicht kurz sein - es macht vielleicht im allgemeinen nicht viel Sinn, oder führt zu Timing-Problemen aber zwingend ist es nicht.

Hilfreicher sollte es sein, 'nem Anfänger zu erklären, WARUM sie eher kurz sein SOLLTE, welche Folgen es hat, wenn das nicht so ist.

 

[Dirk]

Die Regeln stimmen eben nicht - zumindest nicht so grundsätzlich. Man liest es aber an allen möglichen stellen.
Wenn man nämlich als Anfänger versucht, die Regel zu verstehen, ist man eher verwirrt (Warum MUSS ich den SP initialisieren, wenn er das laut Datenblatt vielleicht bereits ist?, Warum MUSS ich Code in der IVT meiden, und darf dort keinen (anderen als Retis) Code platzieren, wenn mein Programm dort nie ankommt?)
'Ne ISR MUSS nicht kurz sein - es macht vielleicht im allgemeinen nicht viel Sinn, oder führt zu Timing-Problemen aber zwingend ist es nicht.

Regeln sind da um gebrochen zu werden Es gibt sicherlich Anwendungen, bei denen es relativ egal ist, bzw. bei denen es nichts ausmacht, wenn ich in einer ISR sogar mal eine Pause mache (hatte ich hier im Forum schon gesehen )

Ich bin der Meinung, wenn man sich an diese "Regel" hält, fährt man besser. Und das nicht nur auf eine bestimmte Programmiersprache und auf AVR 8Bit Controller bezogen!

Genauso wie die Regel, seinen Sourcecode ordentlich einzurücken, damit er leserlich ist (muss man nicht machen, das Programm läuft auch so, aber es ist schlechter verständlich und wartbar).

Hilfreicher sollte es sein, 'nem Anfänger zu erklären, WARUM sie eher kurz sein SOLLTE, welche Folgen es hat, wenn das nicht so ist.

Sie sollte deswegen zeitlich möglichst kurz sein, damit eventuell andere Interrupts nicht blockiert werden. ... habe ich sicherlich schon x-mal hier im Forum geschrieben.

Ich denke wir sind ganz schön off-topic

Dirk