ATmega8: Das Buch

[Jürgen H. (jdhenning)]

Vor etwa einem Jahr wollte ich mehr über MCUs wissen (reichlich 
Vorwissen aus der Zeit vor 20-30 Jahren über die grundlegenden Techniken 
und auch die Programmierung in Assembler). Ich fand kein einziges Buch, 
was sinnvoll nutzbar war und sogar die Tutorials bei microcontroller.net 
waren nur bedingt hilfreich (dauernd Abkürzungen von Registernamen, 
Bits; technische Bezeichnungen, die nicht einmal in eurem eigenen 
Glossar erklärt werden). Beim Durcharbeiten der zur Verfügung stehenden 
Lektüre kam so viel Material zusammen, dass ich dachte, das reicht auch 
für ein sinnvolles Buch, denn wenn ich mit meinem Vorwissen schon 
Schwierigkeiten habe, mich in die Thematik einzuarbeiten, wie soll es 
dann Newbies gehen?

Am 24.9. eröffnete ich einen Thread, in dem ich eine Detailfrage über 
den TWI stellte und auch mein Vorhaben bekannt machte. Eine 
unvollständige Zusammenstellung der Reaktionen:

John Wayne sein Schwiegervater
Offenbar besteht dringend der Bedarf nach einem vernünftigen Buch in 
deutscher Sprache und der TO ist darauf bedacht, dort keinen Fehler 
einzubauen. Das ist m.E. vollkommen in Ordnung.

Karl Heinz (Moderator)
Ist es auch. Ich hoffe nur, er wird es Korrektur lesen lassen.

Oliver
Na ja, die Äußerung von Karl-Heinz dürfte auf der Beobachtung beruhen, 
daß so ziemlich alle vergleichbaren Bücher bisher das Papier nicht Wert 
sind, auf dem sie gedruckt wurden. Aber die Hoffnung stirbt zuletzt.

Skeptik
Ja, böse, ich weiß. Mich interessiert aber nicht was du nach eigenen 
Worten gemacht hast, sondern was im Buch stehen wird.

Cyblord
Ja du schreibst als unbedarfter ein Buch für Unbedarfte. Das geht halt 
nicht gut. Deine Beiträge zeigen einfach dass du keine relevante 
Erfahrung mit AVRs oder gar dem Mega8 hast. Desweiteren ist der Mega8 
einfach veraltet. HEUTE ein Buch dafür zu beginnen ist irrwitzig und 
deine Einlassungen dazu kann man nur als stur und unbelehrbar einordnen. 
Ne absolut nicht. Sowas nennt man wohl Altersstarrsinn. Völlig sinnloses 
Gewäsch.

Jörg Wunsch
Überhaupt: gerade ein Kapitel über sinnvolles Debuggen (jenseits von 
„wir fügen da immer printf()s ein“) würde den Wert eines derartigen 
Buches wohl deutlich mehr ausmachen als ein deutscher Mini-Abklatsch 
dessen, was im Datenblatt steht und schon in zahllosen Tutorien im 
Internet zu finden ist (einschließlich hier).


Es ist Zeit zu prüfen, ob ich meinen eigenen und auch euren 
Anforderungen gerecht werden kann. Das Rohmanuskript steht (bis zum 14. 
Januar) unter "www.jdhenning.de/AVR" zum freien Download bereit (auf der 
Homepage ist kein Link auf '/AVR'). Der Username ist "AvrBuch" und das 
Passwort "ATmega8" (Schreibweise beachten!). Von der dann erscheinenden 
Seite kann man das Rohmanuskript als '.pdf' Datei herunter laden.

Aktuell bin ich im Gespräch mit dem Verlag O'Reilly, der nicht 
uninterresiert ist, das Buch herauszugeben (wenn denn eine entsprechende 
Nachfrage zu erwarten ist; die haben nämlich noch nicht einmal auf 
englisch ein brauchbares Buch zu dem Thema).

Der „Request For Comments“ ist hiermit eröffnet!

Ich wünsche euch allen ein frohes Fest gehabt zu haben!

  Jürgen

[Detlef K. (adenin)]

Nagut, ich habs mal überflogen.
Hmm, Kilt???


Das Buch ist für Anfänger sicher nützlich.

[X. (Gast)]

So ein Bucvh gibts schon. Kann man direkt bei Atmel downloaden. Nennt 
sich Datenblatt. Da steht alles drin was man wissen muss. Noch dazu 
direkt vom Hersteller statt aus zweiter Hand.

[r2-Torf (Gast)]

Was soll ich sagen? Mir geht es genauso.
Daher: Dankeschön!

[Jürgen H. (jdhenning)]

X. schrieb:
> So ein Buch gibts schon. Kann man direkt bei Atmel downloaden. Nennt
> sich Datenblatt. Da steht alles drin was man wissen muss. Noch dazu
> direkt vom Hersteller statt aus zweiter Hand.

Das Buch habe ich (mehrfach) gelesen und wenn es auch nur ansatzweise 
zur Einarbeitung in das Thema geeignet wäre (bis auf wenige Ausnahmen 
ist es zumindest völlig korrekt), hätte ich mir die Arbeit sicherlich 
nicht gemacht. Aber viele Leser hier werden deinen Hinweis sicherlich 
dankbar aufgreifen.

[isidor (Gast)]

Jürgen Henning schrieb:
> Der „Request For Comments“ ist hiermit eröffnet!

Willst du Kommentare hier gepostet haben?

[Mister Jones (Gast)]

schön finde ich auch die Art wie es geschrieben ist, meist schreiben es 
Nerds und vergessen das der Käufermarkt ein nicht Nerd ist, somit sind 
viele dieser Bücher Wertlos.
Ein gutes Beispiel hierfür ist das Lazarus Buch..sicher für Nerds der 
Hammer, aber für Anfänger völlig nutzlos.

Auch sehr schön, das es gleich einen kleinen C Anfängerkurs beinhaltet 
und nicht nur ASM und man dann als Anfänger doch wieder mit zwei oder 
mehr Büchern hantieren muss und die Fortschritte schlussendlich nur 
subjektiv groß sind.

Ich denke ich werde kein Kunde da ich mich derzeit im XMega Bereich 
einarbeite bzw ARM aber bis vor kurzem wäre es eine ernsthafte 
Überlegung gewesen

[Gerhard O. (gerhard_)]

Hallo Jürgen,

Danke für den Hinweis auf Dein Buch. Liest sich schön. Ich werde es nach 
Weihnachten einem älteren Arbeitskollegen von mir geben der sich gerne 
mit MCus beschäftigen will. Ich glaube mit Deiner Art der Einführung 
sollte er ganz gut klar kommen. Das ist vielleicht gerade das Richtige 
für ihn um sich mit der Materie praktisch zu beschäftigen und erspart 
mir eine Menge Zeit;-)


Gruß,
Gerhard

[Detlef K. (adenin)]

Mister Jones schrieb im Beitrag #3938594:
> Das ist super, sowas fehlt mir noch füde einen STM32Fxxxx

Da ist eindeutig dieses Buch "The Definitive Guide to the ARM® 
Cortex-M3" das geeignetste.

Ok, es hat einen Fehler: ist in ausländisch geschrieben. ;)

[chris (Gast)]

Habs auch nur mal überflogen aber zumindest für Anfänger sollte da ne 
ganze Menge Wissen gebündelt sein welches man nutzen kann. Auf jeden ist 
doch versucht worden, es sehr einfach zuhalten z.B.: anstatt Slave wird 
Sklave genutzt. Damit kann eigentlich auch der Dümmste was anfangen und 
es ist wirklich jedes BIT mit einer deutschen Erklärung hinterlegt, was 
schonmal ne Menge Eindeutigkeit bringt, da im englischen doch manches 
konfus rüberkommt, einfach der Sprachenverständlichkeit geschuldet.

Englisch sehr eingengt im Wortschatz**
Deutsch halt dooch ein wenig vielfältiger**

**persönliche Empfindung

X. schrieb:
> So ein Bucvh gibts schon. Kann man direkt bei Atmel downloaden. Nennt
> sich Datenblatt. Da steht alles drin was man wissen muss. Noch dazu
> direkt vom Hersteller statt aus zweiter Hand.

Das ist wohl wahr aber viele Schreckt es doch ab alles auf englisch 
durchzuarbeiten und da ist doch mal das ganze in Deutsch, wenns 
vielleicht auch nicht Fehlerfrei sein kann, ne willkommene Erleichterung 
weil man sich nur auf das erlernen dieser Thematik konzentriert und 
nicht zusätzlich nen Fremdsprachenduden wälzen muss. ABER ein wenig 
Fremdsprache muss man eben doch können.

[Gerhard O. (gerhard_)]

Hallo Jürgen,

Ein kleines Haar habe ich in der Suppe gefunden:

Bei den Erklärungen zur Peripherie fehlt meiner Ansicht nach ein 
Blockschaltbild mit Referenzen zu den dazu gehörenden SFRs.

Ich finde z.B., dass man eine TIMER/CAPTURE/COMPARE Einheit viel 
leichter verstehen kann wenn man im Blockschaltbild den Signalverlauf 
genau je nach den Einstellungen und Modus der dazu gehörigen SFRs 
verfolgen kann. Für mich ist das sehr wichtig. Das fehlt bei Deinen 
Erklärungen. Nur mit Text wird das einfach zu abstrakt. Solche 
Hardwareeinheiten sind meiner Meinung nach viel zu komplex um ohne 
bildliche Darstellung richtig verstanden zu werden. Du könntest aber 
vielleicht auch darauf hinweisen, dass man die Erklärungen von Dir im 
Buch nur zusammen mit den jeweiligen Kapiteln in dem Datenblatt oder 
AppNotes studieren sollte.

Ist nur meine Meinung - Nicht für ungut,

Gerhard

[Atmega8 A. (atmega8)]

Durch die Nutzung der Arduino wird der ATmega8 oder eben äquivalente 
Typen wie der ATmega328 noch lange genutzt werden.

In dem Buch steht:
"Also stellte sich die Frage: Was benötigt man im Minimum, um einen 
ATmega8 in Betrieb zu nehmen?"

Als ich damals angefangen habe wollte ich eine kleine Übersicht sehen in 
der steht was alles gebraucht wird, am besten mit Bildern, so wie es 
dann auch zu Hause vor mir liegt.

AVRstudio zum schreiben des Programms,
AVRdude zum brennen der hex-Datei,
USBasp der Programmieradapter,
Das Steckbrett ...

Im weiteren Verlauf kann man dann ein paar einfache Schaltungen auf dem 
Steckbrett aufbauen.

Eine Zeichnung eines Steckbretts mit den Kabelführungen ist 
übersichtlicher als ein Foto von einem Originalaufbau, denn da verdecken 
die Kabel alles wichtige und es gibt unscharfe Bereiche.

Bei einer Zeichnung kann man die Kabel etwas durchsichtig machen und so 
wird es übersichtlicher.

[Mister Perfekt-Widerlich (Gast)]

Grüß Dich Jürgen!
Inzwischen hast Du Dich bestimmt daran gewöhnt, dass hier zu 99 Prozent 
Frust- Ablasser am Werke sind. Humorlose Leute, den Tieren gleich.
Ich beglückwünsche Dich zu Deinem Werk!
Ein Beitrag in diesem komischen Forum gleicht einer Zeilen- und 
Zeitverschwendung. Gegen diesen, meinen Grundsatz habe ich soeben 
verstossen.

[Atmega8 A. (atmega8)]

@ Gerhard O. (gerhard_)
Wenn du dir das Buch von seiner Seite selbst herunterlädst ist das okay, 
aber verbreite es nicht überall so dass es schon jeder als eBook hat und 
es keiner mehr kaufen muss.

Es ist allerdings schön wenn man funktionierenden Programmbeispiele oder 
wenigstens die Quelltexte auf der Webseite herunterladen kann.

Später braucht man noch einen Bereich "Korrekturen/Fehler/Ergänzungen" 
auf der Webseite und im Buch müsste die Adresse zur Webseite stehen.

[Gerhard O. (gerhard_)]

Mister Perfekt-Widerlich schrieb:
> Grüß Dich Jürgen!
> Inzwischen hast Du Dich bestimmt daran gewöhnt, dass hier zu 99 Prozent
> Frust- Ablasser am Werke sind. Humorlose Leute, den Tieren gleich.
> Ich beglückwünsche Dich zu Deinem Werk!
> Ein Beitrag in diesem komischen Forum gleicht einer Zeilen- und
> Zeitverschwendung. Gegen diesen, meinen Grundsatz habe ich soeben
> verstossen.

Ich glaube nicht, dass es ganz sooo schlimm ist.

Abgesehen davon, Hut ab wer sich so viel Mühe machte und Arbeit 
reingesteckt hat um anderen zu helfen. Und das obendrein noch für 
gratis. Ehrliche und konstruktive Kritik sollte doch ok sein?

Gruß,
Gerhard

[Gerhard O. (gerhard_)]

Atmega8 Atmega8 schrieb:
> @ Gerhard O. (gerhard_)
> Wenn du dir das Buch von seiner Seite selbst herunterlädst ist das okay,
> aber verbreite es nicht überall so dass es schon jeder als eBook hat und
> es keiner mehr kaufen muss.
>
> Es ist allerdings schön wenn man funktionierenden Programmbeispiele oder
> wenigstens die Quelltexte auf der Webseite herunterladen kann.
>
> Später braucht man noch einen Bereich "Korrekturen/Fehler/Ergänzungen"
> auf der Webseite und im Buch müsste die Adresse zur Webseite stehen.

Wollte ja nur mit meinem Arbeitskollegen damit zusammenarbeiten. Also 
keine Angst in der Hinsicht.

[Wolfgang S. (wsm)]

Die Gestaltung eines solchen Buches kann durchaus überdacht werden.

Mir stellt sich die Frage der Zielgruppe?

diese ist bereits genannt: Anfänger -  das ist ok.

Welche Probleme sehen Anfänger?

Ich suche den Überblick und Unterschied zwischen CPU und MCU. Dies ist 
zwar im Text beschrieben, es fehlt aber das Bild dazu. Eine 
Übersichtsbild MCU mit den enthaltenen Blöcken CPU; I/O, RAM, ROM, 
A-Bus, D-Bus, ...

Der Einstieg in die Software IDE ist das nächste Problem. Hier sollte 
ein einfacher Einstieg demonstriert werden.

Auch das Übertragen des Programmes sollte dem Leser an einem Beispiel 
Schritt für Schritt vollständig gezeigt werden.

IRQs wurden erklärt. Habe ich das Standard-Diagramm einer leeren Loop 
und der nebenstehenden IRQ-Routine übersehen? dabei können auch mehrere 
IRQs dargestellt werden.

Ich habe in den 15 Minuten wahrscheinlich auch den Hinweis (step by 
step) auf eine echt durchführbare Programmierung übersehen.

Weiter sollte der Schaltung auf Seite 26 auch noch ein 
Keramikkondensator spendiert werden.

Die häufigen Abbildungen des Atmega8 würde ich jeweils auf den Abschnitt 
reduzieren, der die jeweils relevanten PINs enthält.

Weitere Diagramme, die der Veranschaulichung dienen, wären bei dem Ziel, 
für Anfänger zu schreiben, sicher sehr hilfreich.
In diesem Fall sind auch einfache Programmbeispiele geeignet mit Hilfe 
eines Diagramms die Funktion des Atmega zu erklären.

Du wirst hier auch Anmerkungen erhalten, dass der Atmega8 veraltet ist. 
Natürlich sind deine Ausführungen hilfreich, aber die Aktualität des 
Kontrollers ist der Blickfang auf der Titelseite.
Daher ist es sinnvoll auf den Einstieg in die 8-Bit Kontroller am 
Beispiel eines Atmega8(8) mit Vergleichen mindestens zu einem Attiny, 
einem großen Atmega(128)und auch Xmega hinzuweisen und einen Vergleich 
der wesentlichen Parameter in das Buch einzufügen. Dies dürfen bis zu 10 
Typen werden.
Auch der Bezug zu einem kleinen, preiswert verfügbaren Modul mit einem 
entsprechenden Atmega steigert die Aktualität des Buches. Ein Lektor 
wird sich und ggf. dich fragen, ob das Buch sich in fünf Jahren noch 
verkauft oder bei http://www.buecherbillig.de/ landet.

Die Darstellung (Foto zu Seite 26) einer Steckbrettversion, einer 
Lochrasterplatine bis hin zu einer Arduino-Version (klein und groß) sind 
ein hilfreicher Überblick über verfügbare Varianten.

Timer und Counter wurden spärlich behandelt und erscheinen als 
erweiterte Übersetzung aus dem Datenblatt, wie auch andere Passagen. Das 
Auflisten der Timerregister führt nicht zum Verständnis. Hier fehlt 
zumindest ein Beispiel z.B. für das Erzeugen eines 100Hz-Signales am 
Ausgang oder eines Sekundentaktes bzw. einer einfachen funktionsfähigen 
Zeitanzeige.

Der Anschluss eines LCD wird zwar erwähnt, kann aber nach der Lektüre 
des Buches durch einen Anfänger nicht realisiert werden, obwohl ein 
solches Display eine wesentliches Ausgabeelement darstellt. Dies wird im 
Buch anders dargestellt und dann vergessen.

Ich wünsche dir viel Erfolg

W.

(Autor, Co-Autor, Lektor)

[Gerhard O. (gerhard_)]

Oft helfen mehrere Resourcen. Damals lernte ich viel aus dem Buch 
"Embedded C Programming and the Atmel AVR" von Barnett.

Ich hatte es schon mal vor ein paar Jahren hier im Forum erwähnt und es 
wurde damals eher etwas herunter gemacht. Mir hat es jedenfalls sehr 
geholfen mich mit dem AVR vertraut zu machen. Allerdings arbeite ich nur 
exklusiv mit CodeVisionAVR.

Ein schwerer Nachteil des Buches allerdings ist, dass es sich auf 
Beispiele stützt die für den Codevision Compiler zugeschnitten sind. 
Auch werden viele Seiten für den Gebrauch des IDEs ausgefüllt. Das ist 
für den Anfänger ein großes Problem weil andere Werkzeuge deutlich 
anderen Syntax und Einstellungen benötigen. Nicht jeder will/kann so 
viel Geld für den Compiler ausgeben.

Grüsse,
Gerhard

[jdhenning (Gast)]

isidor schrieb:
> Willst du Kommentare hier gepostet haben?

Natürlich doch!

[jdhenning (Gast)]

Hallo Gerhard

Gerhard O. schrieb:
> Ich finde z.B., dass man eine TIMER/CAPTURE/COMPARE Einheit viel
> leichter verstehen kann wenn man im Blockschaltbild den Signalverlauf
> genau je nach den Einstellungen und Modus der dazu gehörigen SFRs
> verfolgen kann. Für mich ist das sehr wichtig. Das fehlt bei Deinen
> Erklärungen.

Danke für den Hinweis. Ich schau mir das noch mal genauer an.

  Jürgen

[jdhenning (Gast)]

Atmega8 Atmega8 schrieb:
> Als ich damals angefangen habe wollte ich eine kleine Übersicht sehen in
> der steht was alles gebraucht wird, am besten mit Bildern, so wie es
> dann auch zu Hause vor mir liegt.

Hi, es kommen noch ein paar Fotos, war nur bisher nicht dazu gekommen.

[jdhenning (Gast)]

Mister Perfekt-Widerlich schrieb:
> Ein Beitrag in diesem komischen Forum gleicht einer Zeilen- und
> Zeitverschwendung. Gegen diesen, meinen Grundsatz habe ich soeben
> verstossen.

Moin, ich habe etwa 10 Jahre in Andalusien gelebt und der damalige 
deutsche Konsul sagte einmal (allerdings nicht offiziell), dass seiner 
Meinung nach etwa 90% aller Ausländer im arbeitsfähigen Alter eindeutig 
dem kriminellen Milleu zuzurechnen seien.Wenn ich das anderen dort 
lebenden Ausländern im entsprechenden Alter erzählte meinten die meist 
spontan "90% ? Ne' glaube ich ich nicht. Aber 60% könnte hinhauen!"

In diesem Sinne siehst du das etwas zu negativ. Hier sind nur 10 bis 20% 
Nörgler unterwegs. Danke für deinen VErstoß gegen deine Prinzipien.

  Jürgen

[jdhenning (Gast)]

Atmega8 Atmega8 schrieb:
> Später braucht man noch einen Bereich "Korrekturen/Fehler/Ergänzungen"
> auf der Webseite und im Buch müsste die Adresse zur Webseite stehen.

Kommt, wenn das Buch von O'Reilly verlegt wird. Danke für den Hinweis.
  Jürgen

[Alexander S. (alesi)]

Jürgen Henning schrieb:
> Ich fand kein einziges Buch,
> was sinnvoll nutzbar war und sogar die Tutorials bei microcontroller.net
> waren nur bedingt hilfreich

Hallo,

was ist denn z.B. an diesem Buch:
Schmitt, Günter, "Mikrocomputertechnik mit Controllern der Atmel
AVR-RISC-Familie"

http://www.degruyter.com/view/product/221318?rskey=QGQTBk&result=7

http://www.amazon.de/Mikrocomputertechnik-Controllern-Atmel-AVR-RISC-Familie-Programmierung/dp/3486589881/ref=sr_1_1?s=books&ie=UTF8&qid=1419540300&sr=1-1&keywords=Schmitt+Mikrocomputertechnik

nicht so gut? Es ist zwar scheinbar nicht für den absoluten Anfänger
geschrieben, sondern eher für Studenten, aber vom Inhalt sieht es
ganz gut aus. Ich überlege es evtl. zu kaufen.

[Andreas H. (ahz)]

Jürgen Henning schrieb:
> Der „Request For Comments“ ist hiermit eröffnet!

Hallo Jürgen

Das mit dem Buch ist eine Super Idee von Dir. Oft scheitern Anfänger ja 
nicht nur an der neuen, komplexen Materie, sondern auch noch zusätzlich 
am Englisch.

Die Anfragen hier im Forum zeigen ja auch schon, dass genau hier ein 
echter Bedarf existiert.

Ich habe es mir mal runtergeladen und (bis jetzt) nur kurz mal 
überflogen. Tolle Arbeit (insbesondere auch das Cover!). Aber natürlich 
auch noch viel, dass verbessert werden kann. Angehängt ein paar erste 
Eindrücke und Vorschläge (zur Diskussion natürlich).

Viele Grüße
Andreas



- In einem Anfängerbuch ein Kapitel über Projektmanagment ? Wäre eine 
kurze "Skizze" zum Aufbau eines Programms da nicht ausreichend ?

- "Interrupte" ? Interrupt (engl. für Unterbrechung), Mehrzahl 
Unterbrechungen (engl. interrupts), nicht Interrupte ;-)

- Texte wie: "Wenn sie jetzt keine Idee haben, wie sie die LED zum 
Blinken bringen können, dann sollten sie dieses Buch vielleicht besser 
auf dem nächsten Flohmarkt verkaufen" sind unnötig, unwitzig und evtl. 
demotivierend. Du bist Dir 101% sicher, dass man Deine vorhergehenden 
Erklärungen nicht missverstehen kann und alles bis ins letzte Detail 
fehlerfrei ist?
Besser wäre evtl. eine "Übungsaufgabe" mit entsprechenden Teilschritten, 
die den Anfänger zur Lösung führen (man glaubt ja immer nicht, an welch 
einfachen Sachen sich Anfänger aufhängen können).

- Oben wurde schon vorgeschlagen, eine Zeichnung mit einem Aufbau für 
das erste Programm zu machen. Ich würde vorschlagen, auch eine komplette 
"Stückliste" dazuzulegen. Oft scheitert es ja wirklich an Kleinkram und 
man ärgert sich, wenn man nach dem Einkauf der Bauteile dann doch etwas 
vergessen hat.
Das gleiche Problem taucht auch wieder beim Anbinden der seriellen 
Schnittstelle an den PC auf (Kap. 19.1). Wäre es nicht einfacher für den 
Leser, wenn man in der Stückliste gleich ein FTDI-Kabel (Kabel !!!) mit 
angibt, dass man an den PC anschließt und das auf der anderen Seite 
direkt 5V  RXD/TXD für den Atmel zur Verfügung stellt ?
Mit einer kleinen Anschlußskizze hat der Leser dann alles an Hardware 
für die Kommunikation fertig. Nebenbei könnte sogar ein 
Netzteil/Batterie entfallen. Die FTDI Kabel liefern auch 5V für den uP 
gleich mit ;-)

- Bei den meisten Programmen ist sind die Comments auf Englisch. ist das 
beabsichtigt ?

- Das Glossar mit (auch englischen) Begriffen ist eine tolle Sache. Man 
muss irgendwann ja doch woanders nachsehen. Und dann hat man die 
wichtigsten Begriffe gleich zusammen.
(Appropos: Tri-state ist etwas "missdeutig". TriState bedeutet, dass ein 
digitaler Ausgang DREI (engl. tri-) Werte haben kann. '0' und '1', die 
üblichen High-/Lowpegel und ausserdem den "Wert" hochohmig. Mit 
Eingängen hat das nichts zu tun. Auch bei anderen Einträgen muss man 
noch einmal rüberschauen)

- Einführung in verkettete Listen etc. in diesem Buch ? Wäre es evtl. 
zielführender, sich erst mal die CPU & Peripherie mit entsprechenden 
Beispielen vorzunehmen ? Man kann ja z.B. auch mal zwei uPs direkt 
miteinander via TWI/SPI reden lassen. Der Leser hat ja u.U. null 
Messequipment.
Meine persönliche Meinung ist hier, lieber weniger Breite (Beschränkung 
auf die elementaren Gebiete), dafür aber mehr Tiefe (Beispiele, 
Aufgaben) und nicht nur triviale Sachen. Auch das oben schon genannte 
Beispiel mit dem LCD Display bietet hier viel "Spielplatz" zum lernen. 
Und am Ende hat der Leser gleich eine weitere "Debughilfe" für das 
nächste Projekt.

Als Beispiel sei hier mal Kapitel 10 (ADC) genannt. Nach der Erkläreung 
des ADCs allgemein und seiner Register war es das. Wäre es nicht 
schöner, hier gleich ein paar Beispiele/Aufgaben zu haben, damit der 
Leser ein Gefühl für die Funktion der "vielen bunten Registerbits" 
bekommt ?
Hier kann man auch wieder auf die "Interrupte" zurück kommen und z.B. im 
Zusammenhang mit der SIO zeigen, wie zwei IRQs zusammen/gegeneinander 
arbeiten. Und das alles nur mit ein paar LEDs und viel AHA Erlebniss ;-)
Appropos: Als Bonbon kann man jetzt (!) auch gleich mal zeigen, was man 
mit den Timern machen kann. Mit einem Kondensator und einem Widerstand 
an einem Ausgang baut man sich per PWM wieder eine Analogspannung. Du 
kannst Dir sicher sofort ein schönes Experiment dafür vorstellen ;-)

[jdhenning (Gast)]

Wolfgang Schmidt schrieb:
> Daher ist es sinnvoll auf den Einstieg in die 8-Bit Kontroller am
> Beispiel eines Atmega8(8) mit Vergleichen mindestens zu einem Attiny,
> einem großen Atmega(128)und auch Xmega hinzuweisen und einen Vergleich
> der wesentlichen Parameter in das Buch einzufügen. Dies dürfen bis zu 10
> Typen werden.

Ich bin (wie schon zugegeben) kein MCU-Profi. Kannst du mir so eine 
Liste geben? Einige Fotos und Zeichnungen sind noch in Planung, aber ich 
wollte erstmal abchecken, ob überhaupt ein fundiertes Echo zurück kommt.

  Jürgen

[Andreas H. (ahz)]

Klaro schrieb im Beitrag #3938765:
> Trotz direkt kopieren von Username und Passwort in die Eingabe
> gab es keinen Zugang.

Huhu Klaro

Hat bei mir vorhin problemlos geklappt.

Ich würde Dir das PDF, Jürgens Einverständniss vorausgesetzt, auch gern 
schicken. Aber Du bist unregistered user :/

Grüße
Andreas

[jdhenning (Gast)]

Alexander S. schrieb:
> was ist denn z.B. an diesem Buch:
> Schmitt, Günter, "Mikrocomputertechnik mit Controllern der Atmel
> AVR-RISC-Familie"

Ich habe das Buch nicht gelesen, sondern bin nur mal bei Amazon das 
Inhaltsverzeichnis durchgegangen. Das Buch ist mit Sicherheit nicht 
schlecht und gibt sicherlich einen guten Überblick über die 
Mikroprozessortechnik im Allgemeinen. Mir ging es darum, Einsteigern 
etwas an die Hand zu geben, wodurch sie eine MCU (fast) komplett 
verstehen können (also ein deutlich schmalerer Blickwinkel).

  Jürgen

[wendelsberg (Gast)]

jdhenning schrieb:
> Ich bin (wie schon zugegeben) kein MCU-Profi. Kannst du mir so eine
> Liste geben?

Das nicht, aber ein ATMega32U4 sollte dabei sein, der stellt meiner 
Meinung nach den Einstieg in die ATMegas mit USB dar.

wendelsberg

[jdhenning (Gast)]

Hallo Andreas,

vielen Dank für deinen langen Post. Ich werde ihn später ganz eingehend 
durchgehen. Jetzt nur dieser Kommentar.

Andreas H. schrieb:
> - "Interrupte" ? Interrupt (engl. für Unterbrechung), Mehrzahl
> Unterbrechungen (engl. interrupts), nicht Interrupte ;-)

Ich bin Elektrotechniker und kein Deutschlehrer ;-)

Bei meinen Recherchen war mir aufgefallen, dass es sehr viele Tutorials 
/ Beiträge mit Programmbeispielen gibt, aber kaum eines diese Beispiele 
hat mir beim Verständnis der MCU geholfen. Wenn der Verlag meint, dass 
der Text ist zu kurz, kann ich auch viele Seiten mit Beispielen füllen.

  Jürgen

[jdhenning (Gast)]

Andreas H. schrieb:
> Huhu Klaro
>
> Hat bei mir vorhin problemlos geklappt.
>
> Ich würde Dir das PDF, Jürgens Einverständniss vorausgesetzt, auch gern
> schicken. Aber Du bist unregistered user :/

Das geht absolut in Ordnung! Danke für das Angebot der Mithilfe. Die 
Seite ist bei Strato gehostet und ich habe den Zugang über Firefox und 
Klein&Weich Internet Explorer ausprobiert und keine Probleme gehabt. Tut 
mir leid, wenn es da Probleme gibt.

  Jürgen

[fred (Gast)]

Du brauchst dringend einen erfahrenen Lektor. Für inhaltliche Aussagen 
braucht es mehr Zeit. Mir sind da einige Punkte bereits beim flüchtigen 
Überblättern aufgefallen. ...

[HildeK (Gast)]

Schöne Arbeit!
> Der „Request For Comments“ ist hiermit eröffnet!

An Andreas H. (ahz) bez. des Projektmanagements und dem Wunsch nach 
tieferen Beispielen kann ich mich nur anschließen - ich bin in dem 
Gebiet µC nur Anfänger und lernte bisher am Meisten an Hand von 
Beispielen. Gerade das Ineinandergreifen der verschiedenen Bitsettings 
bereitete mir die größten Schwierigkeiten. Manchmal ist sogar die 
Reihenfolge oder Gleichzeitigkeit des Setzens relevant. Darüber einen 
Hinweis oder eine kommentiertes Beispiel zu lesen, wäre gerade für deine 
Zielgruppe bestimmt sehr hilfreich.

Ich traue mich auch, ein paar Bemerkungen loszulassen, obwohl ich bisher 
nur teilweise und oberflächlich in deinem Werk gelesen habe.

- manche englischsprachigen Begriffe würde ich so lassen, Beispiel 'band 
gap' oder Interrupts. Lieber einmal erklären (und/oder Glossar) und die 
üblichen Fachbegriffe drin lassen. An anderen Stellen hast du es ja auch 
so gemacht (konsistent bleiben :-))
- Die Zeile in einem Beispiel
     PORTB = PORTB | (1 << DDB4);
Verwendet man da nicht eher PB4 anstatt DDB4? Ich weiß, beide sind mit 
der Zahl '4' hinterlegt, aber PB4 ist meines Wissens die Konvention an 
dieser Stelle.
- Wie sollte Watchdog geschrieben werden? Watch Dog, Watchdog (wie ich 
es mache und du manchmal), Watch-Dog? Ich habe alle drei Varianten 
gefunden :-). Auch hier: konsistent bleiben!
- Das Wörtchen 'ich' sollte man ev. vermeiden - außer im Vorwort oder 
deiner Vorstellung. Oft verwendet man als Ersatz 'der Autor'. Finde ich 
persönlich passender.

[F. F. (foldi)]

Jürgen Henning schrieb:
> Der „Request For Comments“ ist hiermit eröffnet!

Alle Beiträge habe ich nicht mehr gelesen, aber hier mein Kommentar:

Zunächst, ich würde so ein Buch nicht kaufen.
Nicht, weil es nicht gut ist. Ich habe nur den Anfang überflogen und 
wäre, wenn ich jetzt noch mal ganz von vorne anfangen müsste, sicher 
begeistert.
Aber es hat schlichtweg den falschen Titel!
Heute ist der ATmega328, durch die Arduinos total populär und ich würde 
immer nach einem neueren Buch suchen.
Der Aufbau und der Vergleich zwischen C und Assembler und das 
ausreichend genug, aber ohne zur Orgie zu werden, das ist sehr gut.

Der Vorspann, wie bei nahezu allen Büchern, ist zu lang geraten.
Wenn man mit Elektrik und Elektronik anfängt, dann steht in jedem Buch 
erstmal das Atom und nach dem dritten Buch ist man das leid.

"Guten Tag, jetzt geht es los!", so stelle ich mir ein gutes Buch vor.
Ich will nicht wissen wer "Neumann", "Meier" oder "Schulz" ist, darauf 
kann man mit Fußnote verweisen.

Später geht es alles sehr gut weiter.

Eine Zeit lang habe ich mal Datenbanken gemacht und ein Buch, das baute 
über das ganze Buch eine sinnvolle Datenbank auf, die man am Ende 
brauchen konnte.
So ein Projekt, angefangen von "Hello World", also die blinkende Led, 
bis zum Touchdisplay mit mini Betriebssystem, leicht abwandelbar, sollte 
das Buch begleiten.

Ich habe nun noch einige Seiten gescrollt und wirklich gute, didaktisch 
sehr taugliche Ansätze gesehen.

Abschließend kann ich nur sagen: Nimm Abstand vom Titel und schreibe 
ATmega328 drüber. Dann wird es auch gekauft werden.

Ich hoffe meine Meinung hilft dir weiter.

Kleiner Nachtrag.

Den Glossar könnte man als herausnehmbaren Teil gestallten und immer 
daneben legen, wenn man was nachschlagen muss.

[jdhenning (Gast)]

HildeK schrieb:
> (konsistent bleiben :-))
und
> - Wie sollte Watchdog geschrieben werden? Watch Dog, Watchdog (wie ich
> es mache und du manchmal), Watch-Dog? Ich habe alle drei Varianten
> gefunden :-). Auch hier: konsistent bleiben!
Danke für den Hinweis. Es ist wahnsinnig schwierig, bei einem so langen 
Text diese Konsistenz zu bewahren. Wenn man den Text teilweise schon 
fast auswendig kennt, dann 'sieht' man solche Sachen nicht mehr.

> - Die Zeile in einem Beispiel
>      PORTB = PORTB | (1 << DDB4);
> Verwendet man da nicht eher PB4 anstatt DDB4? Ich weiß, beide sind mit
> der Zahl '4' hinterlegt, aber PB4 ist meines Wissens die Konvention an
> dieser Stelle.
Hatte ich, um ehrlich zu sein, von irgendwoher kopiert und nicht drüber 
nachgedacht. Werde ich checken.

  Jürgen

[Helmut S. (helmuts)]

Diese Sätze zum Thema C sind dir besonders negativ aufgefallen. Hier 
wird der Eindruck erweckt, dass Bitmanipulationen in C Unsinn wären und 
anschließend werden die Tausend Bits der Config-Register mit Beispielen 
in C und Assembler gesetzt. Das passt nicht zusammen. Am besten diesen 
Abschnitt komplett löschen.

"Man kann in C auch einzelne Bits manipulieren, nur wer braucht so etwas 
schon in halbwegs normalen Programmen? Schlicht niemand! Wer hat das 
Problem, dass er aus seinem PC auch noch das letzte bisschen 
Geschwindigkeit hervor kitzeln muss? Schlicht niemand!"

[jdhenning (Gast)]

F. Fo schrieb:
> Abschließend kann ich nur sagen: Nimm Abstand vom Titel und schreibe
> ATmega328 drüber. Dann wird es auch gekauft werden.

Danke für den Hinweis. Ich werde mal das Datenblatt des ATmega328 
checken und werde, wenn das keine riesigen Änderungen im Manuskript nach 
sich zieht, umschwenken.

  Jürgen

[Andreas H. (ahz)]

jdhenning schrieb:
> HildeK schrieb:
>> - Die Zeile in einem Beispiel
>>      PORTB = PORTB | (1 << DDB4);
>> Verwendet man da nicht eher PB4 anstatt DDB4? Ich weiß, beide sind mit
>> der Zahl '4' hinterlegt, aber PB4 ist meines Wissens die Konvention an
>> dieser Stelle.
> Hatte ich, um ehrlich zu sein, von irgendwoher kopiert und nicht drüber
> nachgedacht. Werde ich checken.

Schau Dir vielleicht auch mal das _BV() Makro von Atmel an. Das macht 
die Bitschieberei mMn auch etwas übersichtlicher.

/regards
Andreas

[jdhenning (Gast)]

Helmut S. schrieb:
> "Man kann in C auch einzelne Bits manipulieren, nur wer braucht so etwas
> schon in halbwegs normalen Programmen? Schlicht niemand! Wer hat das
> Problem, dass er aus seinem PC auch noch das letzte bisschen
> Geschwindigkeit hervor kitzeln muss? Schlicht niemand!"

Es ging mir hier darum klar zu stellen, dass man in einem 'normalen' 
C-Programm eigentlich nie wirklich Bitmanipulationen braucht (wenn man 
unbedingt schnelleren Code als der optimierende Compiler erstellen will 
hat man eine Ausnahme). Anders ist das natürlich in einem Embedded 
System, wo man Bitmanipulationen eigentlich ständig braucht.

Danke für den Hinweis, ich werde versuchen diese Unterscheidung stärker 
hervor zu heben.

[Frank K. (fchk)]

1.5.2 SPI (Serial Programming Interface)

Der offizielle Name ist ISP (In-System Programming). Diese Bezeichnung 
solltest Du auch verwenden, denn SPI und ISP ist nicht das gleiche.
SS wird für ISP nicht verwendet - bitte aus der Tabelle entfernen!

1.5.3
"HV-Programmierung
Bei dieser Art der Programmierung wird der Reset-Pin auf plus 12 Volt 
gelegt. Was daran HV (High Voltage) sein soll, hat sich mir bisher nicht 
erschlossen, aber die Methode nennt sich nun einmal so."

12V ist eine hohe Spannung für Systeme, die sonst nur mit maximal 5V 
laufen. Weil es kein normaler Logikpegel mehr ist, nennt man es HV. Das 
ist der Grund.

Es fehlen Grundlagen über Digitalschaltungen: Logikpegel, Logikwerte H, 
L, X, Z, Open Collector/Open Drain, Logikfunktionen, warum es eine dumme 
Idee ist, Eingänge offen zu lassen, und der Sinn von Pull-Ups und 
Pull-Downs, wofür den 100n Abblockkondensatoren sind, die man braucht.

Es ist für meinen Geschmack zu wenig Beispielcode dabei.

Zeichentabelle am Ende: Codepage 850, also genau das, womit Windows eben 
gerade NICHT arbeitet (Codepage 1252 als Erweiterung von ISO8859-1). 6, 
setzen. Ich finde die entbehrlich, quasi wie Seitenfüller.

Und: Man merkt, dass das Buch mit Word (oder OO 3.3) geschrieben wurde. 
Stichwort Typografie. Die Zeilen sind viel zu lang, das Lesen strengt 
an. Faustregel: zwei Alphabete pro Zeile (also etwa 50 Zeichen), mehr 
nicht.
Ich denke, ein Verlag wird das in InDesign komplett neu setzen lassen. 
Bitmap-Grafiken gehen ja schon mal überhaupt nicht, das sieht im Druck 
voll semiprofessionell aus. Also einmal Illustrator bemühen und neu 
machen und daran denken, dass in der Druckvorstufe mit CMYK gearbeitet 
wird.

Das fällt mir jetzt so auf die Schnelle ein.

fchk

[Lord of L. (lightninglord)]

Ich habe das Buch auch nur kurz überflogen, deshalb haben vielleicht 
nicht alle meine Anmerkungen ein starkes Gewicht.

Als Anfänger hat man wenig bis gar keine Ahnung von der Materie, somit 
auch  nicht von den vielen verschiedenen Programmier- und 
Debugmöglichkeiten. Gerade das Debugen ist am Anfang sehr wichtig und 
damit meine ich nicht das USART-Debugen. Mit einem neueren IC z.B. 
ATmega328 hat man heute mit OneWireDebug (läuft sogar über die ISP 
Schnittstelle) tolle Möglichkeiten. Hierzu wäre eine detaillierte 
Einführung nicht schlecht. Dann würde ich auch nicht mehr unbedingt das 
STK500 und den AVRDragon empfehlen. Das neue ICE kostet kaum mehr und 
gibts für Schüler und Studenten sogar reduziert. Und das STK500 ist mit 
seinen COM-Ports auch nicht wirklich toll, gerade weil ei
s teilweise mit den USB-Adaptern nicht sauber läuft. Am Anfang steht man 
vor einem riesen Berg, da sollte es nicht auch noch die Hardware sein, 
die einem den Einstieg schwerer macht als nötig. Generell sollte man zu 
orginal Programmierhardware raten. Die meisten Scherereien hatte ich 
damit am Anfang, dass meine Programmierer selbst gebaut waren. (Auch 
eBay ist für Programmierhardware nicht geeigenet, ein Kollege hat einen 
ganzen Tag letzte Woche gebraucht bis er gemerkt hat, dass ein 
gefälschtes PicKit das Problem war.)

Ebenso vermisse ich eine Schritt für Schritt Anleitung vom installieren 
der IDE bis zur ersten blinkenden LED.

Ein paar Diagramme, z.B. zur Beschreibung der Architektur, helfen beim 
Verständnis immens.

Vielleicht solltest du auch an manchen Stellen über deine Formulierungen 
nachdenken. Sarkasmus ist nicht jedermanns Sache und den Leser zu necken 
vielleicht auch nicht. Ein lockerer Schreibstiel ist natürlich schön zu 
lesen, aber man muss damit vorsichtig sein. Ein guter Lektor kann dir da 
richtig gute Tipps geben, dann wird das ein gutes Einsteigerwerk.

An sonsten finde ich es spitze, wie viel Mühe du dir mit dem Buch machst 
und hoffe das du damit auch Erfolg hast.

[jdhenning (Gast)]

Frank K. schrieb:
> 1.5.2 SPI (Serial Programming Interface)
>
> Der offizielle Name ist ISP (In-System Programming). Diese Bezeichnung
> solltest Du auch verwenden, denn SPI und ISP ist nicht das gleiche.
> SS wird für ISP nicht verwendet - bitte aus der Tabelle entfernen!
Ich kann nichts dafür, dass Atmel das SPI nennt; wenn ich es anders 
nennen würde, wäre die Verwirrung nur größer, was gerade nicht mein 
Ansinnen ist.
Kannst du mir sagen, welche Tabelle auf welcher Seite du meinst?

> 1.5.3
> "HV-Programmierung
> Bei dieser Art der Programmierung wird der Reset-Pin auf plus 12 Volt
> gelegt. Was daran HV (High Voltage) sein soll, hat sich mir bisher nicht
> erschlossen, aber die Methode nennt sich nun einmal so."
>
> 12V ist eine hohe Spannung für Systeme, die sonst nur mit maximal 5V
> laufen. Weil es kein normaler Logikpegel mehr ist, nennt man es HV. Das
> ist der Grund.
Das liegt einfach daran, dass ich Elektrotechniker bin. Es gibt 
Niederspannungsnetze (230 - 400 Volt), Mittelspannungsnetze und 
Hochspannungsnetze (300 kV oder auch mehr). So gesehen fallen für mich 
12 Volt noch nicht einmal in den BEreich der Niederspannungsnetze (mit 
anderen Worten: das war Ironie!).

> Es fehlen Grundlagen über Digitalschaltungen: Logikpegel, Logikwerte H,
> L, X, Z, Open Collector/Open Drain, Logikfunktionen, warum es eine dumme
> Idee ist, Eingänge offen zu lassen, und der Sinn von Pull-Ups und
> Pull-Downs, wofür den 100n Abblockkondensatoren sind, die man braucht.
Für den Bereich gibt es jede Menge gute Bücher und Web-Sites; vielleicht 
bin ich da ja ein wenig engstirnig, aber ich würde solche Kapitel als 
Papiervergeudung ansehen.

> Es ist für meinen Geschmack zu wenig Beispielcode dabei.
Gleiches Argument wie gerade eben.

> Zeichentabelle am Ende: Codepage 850, also genau das, womit Windows eben
> gerade NICHT arbeitet (Codepage 1252 als Erweiterung von ISO8859-1). 6,
> setzen. Ich finde die entbehrlich, quasi wie Seitenfüller.
Wenn ich bei über 200 Seiten nur zwei Seiten als Seitenfüllern habe, 
dann ist das eher eine 1+ mit Sternchen. Ich arbeite an einem alten PC 
auf dem noch XP läuft und rate mal, wie ich die Zeichen in die Tabelle 
bekommen habe? Indem ich die Alt-Taste gedrückt halte und den dezimalen 
Ziffercode des Zeichens eingegeben habe. Deine Info ist also entweder 
falsch oder nicht vollständig. Vor etlichen Jahren hatte ich mir mal das 
Buch "C++ Objektorientierte Programmierung" von Alexander Niemann und 
Stefan Heitsiek gekauft. Der einzige Grund, weshalb ich dieses Buch noch 
nicht entsorgt hatte war die ASCII-Tabelle auf den Seiten 334 und 335.

Auch wenn wir uns inhaltlich nicht ganz einig sind: Vielen Dank für 
deine Kommentare.

  Jürgen

[Christian M. (chrigi001)]

Frank K. schrieb:
> 1.5.2 SPI (Serial Programming Interface)
>
> Der offizielle Name ist ISP (In-System Programming). Diese Bezeichnung
> solltest Du auch verwenden, denn SPI und ISP ist nicht das gleiche.
> SS wird für ISP nicht verwendet - bitte aus der Tabelle entfernen!

Genau

Und für ISP (nicht SPI) wird noch die Reset Leitung benötigt.

[F. F. (foldi)]

jdhenning schrieb:
> F. Fo schrieb:
>> Abschließend kann ich nur sagen: Nimm Abstand vom Titel und schreibe
>> ATmega328 drüber. Dann wird es auch gekauft werden.
>
> Danke für den Hinweis. Ich werde mal das Datenblatt des ATmega328
> checken und werde, wenn das keine riesigen Änderungen im Manuskript nach
> sich zieht, umschwenken.
>
>   Jürgen

Bei Atmel gibt es ein Datenblatt oder AppNote, da sind genau diese 
Unterschiede kurz zusammen gefasst. Leider weiß ich nicht wie das Blatt 
noch heißt.

[F. F. (foldi)]

Womit ich mit anderen hier nicht überein stimme. Die Länge ist völlig 
ausreichend. Beispiel (also das "Meer" von Beispielen) könnte der Verlag 
online stellen.
Nicht jeder sitzt den ganzen Tag zu Hause rum und hat Zeit dran zu 
bleiben. Da zählen schnelle, reproduzierbare Erfolge. Denn ohne Spaß 
hört man erst mit dem Buch und dann mit den Mikrocontrollern auf.

[F. F. (foldi)]

jdhenning schrieb:
> Ich habe das Buch nicht gelesen, sondern bin nur mal bei Amazon das
> Inhaltsverzeichnis durchgegangen.

... und ich hatte es, als Anfänger, schnell wieder weg gelegt.
Viel zu wissenschaftlich.
Für jemanden der das nebenbei machen will, sehr harter Tobak.

[Helmut S. (helmuts)]

jdhenning schrieb:
> F. Fo schrieb:
>> Abschließend kann ich nur sagen: Nimm Abstand vom Titel und schreibe
>> ATmega328 drüber. Dann wird es auch gekauft werden.
>
> Danke für den Hinweis. Ich werde mal das Datenblatt des ATmega328
> checken und werde, wenn das keine riesigen Änderungen im Manuskript nach
> sich zieht, umschwenken.
>
>   Jürgen

Das wird aber ziemlich viel Arbeit und jemand muss dann auch die 
Beispiele mit dem ATMEGA328 testen.

http://www.atmel.com/images/doc2553.pdf

[jdhenning (Gast)]

Lord of Lightning schrieb:
> Am Anfang steht man  vor einem riesen Berg, da sollte es nicht auch noch
> die Hardware sein, die einem den Einstieg schwerer macht als nötig.
> Generell sollte man zu orginal Programmierhardware raten. Die meisten
> Scherereien hatte ich damit am Anfang, dass meine Programmierer selbst
> gebaut waren.
Ich hatte mich unter anderem auf den ATmega8 beschränkt, weil es viele 
'offizielle' Programmiergeräte gibt. Dass es (technisch) nicht die 
neuesten sind, war mir auch klar; nur findet man im Internet jede Menge 
Links, die sich genau auf diese Geräte beziehen. Also musste ich 
zumindest grundlegende Informationen zu ihnen geben.

> Ebenso vermisse ich eine Schritt für Schritt Anleitung vom installieren
> der IDE bis zur ersten blinkenden LED.
Jetzt frustrierst du mich wirklich. Ich war (und bin immer noch) der 
Meinung, dass ich wirklich Schritt für Schritt beschrieben habe, wie man 
per Programm eine LED einschaltet und nach Änderung des Programmes 
wieder ausschaltet. Bitte um Mithilfe: "Wo habe ich da signifikante 
Lücken gelassen?"

[jdhenning (Gast)]

F. Fo schrieb:
> Denn ohne Spaß hört man erst mit dem Buch und dann mit den
> Mikrocontrollern auf.

Thumbs Up!
  Jürgen

[Gerhard O. (gerhard_)]

Senf vom Gerhard:

Ich möchte vorschlagen die Abkürzung SPI nur für serielle 
Datenübertragungsanwendungen zu beziehen. M.W. wird doch bei allen 
anderen Herstellern für SPI "Serial Peripheral Interface" gemeint.

Das Dumme ist, dass beim AVR das SPI HW interface im Gegensatz zum PIC 
auch als ISP-Schnittstelle mit verwendet wird. Daher kommt die ganze 
Verwirrung.

Es wäre vielleicht hilfreich im Buch darauf hinzuweisen dass beim AVR 
die SPI-Schnittstelle auch als ISP-Schnittstellen Zugang doppelt 
verwendet wird und von Anfang an richtig verstanden wird.

Dann wäre es auch noch gleich nützlich und wichtig darauf hinzuweisen 
dass die ISP/SPI Schnittstelle einen Takt benötigt und beim Falschsetzen 
der Takt Fuses der chip sich meist nicht mehr ansprechen lässt und im 
Notfall, wenn das passieren sollte, einen externen Oszillator 
anschliessen soll, damit man die Fuses wieder richtig setzen kann.

Man sollte gerade dem Anfänger aufs Herz legen mit den Fuses richtig 
umzugehen und genau dokumentieren was Setzen und Zurücksetzen bei den 
Fuses bedeutet und aufs Herz legen nicht damit wild herum zu 
experimentieren. Mit der Logik der Fuses hat Atmel wirklich ein 
Baseliskenei gelegt oder einen großen Bock geschossen. Ich kenne sonst 
keinen MCU wo man so aufpassen muß um sich nicht auszuschließen.

Grüsse,
Gerhard

[F. F. (foldi)]

Kann ich nur unterstützen.
Hebt mal die Hand, wer sich zu Anfang nicht mal ausgesperrt hat! :-)

Auch die Verwirrung mit SPI und ISP. Mal steht es so rum und dann wieder 
andersrum. Ist doch das gleiche!?

Insbesondere die Fuses sollten sehr deutlich, noch vor dem Übertragen 
des ersten Programmes stehen und zwar so, wie sie dann auch im Studio zu 
sehen sind und mit genauen Erklärungen.
Ich wusste zwar relativ schnell was ich einstellen muss, aber die 
Erklärungen habe ich erst ein Jahr später gefunden.

[Helmut S. (helmuts)]

Ich finde kein Bild mit der Belegung des 
Standard-Programmiersteckers/Kabel (6pin, 10pin). Waren da nicht sogar 
zwei verschiedene 10pin Belegungen?
http://www.elektronik-bastelkeller.de/avr_isp.html
Das hätte ich spätestens bei dem LED-Beispiel erwartet oder zumindest 
einen Verweis auf die Belegung.

Ob dein Programmieradapter aus Hongkong ist oder nicht ist unerheblich. 
Vielleicht besser ein paar gängige Adapter, auch die von Atmel, 
benennen.

[jdhenning (Gast)]

Gerhard O. schrieb:
> Das Dumme ist, dass beim AVR das SPI HW interface im Gegensatz zum PIC
> auch als ISP-Schnittstelle mit verwendet wird. Daher kommt die ganze
> Verwirrung.
Das ist leider nicht die einzige Verwirrung, die AVR produziert hat 
(aber hätten die nicht so sehr geschludert, dann gäbe es ja auch keinen 
Grund für dieses Buch)

> Es wäre vielleicht hilfreich im Buch darauf hinzuweisen dass beim AVR
> die SPI-Schnittstelle auch als ISP-Schnittstellen Zugang doppelt
> verwendet wird und von Anfang an richtig verstanden wird.
Yepp, vielen Dank für den Hinweis, wird eingearbeitet!

Und jetzt gute Nacht und Tschüs bis morgen!
  Jürgen

[F. F. (foldi)]

... und immer auf das Datenblatt verweisen. Spätestens wenn jemand den 
externen Interrupt auf den ATtiny13 übertragen will, wird es 
Schwierigkeiten geben, Wobei das Programm dann wieder auf dem ATtiny10 
laufen würde (vorausgesetzt die Pins sind gleich)

[Gerhard O. (gerhard_)]

jdhenning schrieb:
> Und jetzt gute Nacht und Tschüs bis morgen!
>   Jürgen

Gleichfalls!
Gerhard

[Gerhard O. (gerhard_)]

F. Fo schrieb:
> Kann ich nur unterstützen.
> Hebt mal die Hand, wer sich zu Anfang nicht mal ausgesperrt hat! :-)
>
>


     \cccc
     (|||)
     (|||)
      \ /
      | |
      | |
      | |
______/ /
       /
______/

[Gerhard O. (gerhard_)]

F. Fo schrieb:
> Kann ich nur unterstützen.
> Hebt mal die Hand, wer sich zu Anfang mal ausgesperrt hat! :-)

War so gemeint - hatte das " nicht " glatt übersehen;-)

[Frank K. (fchk)]

jdhenning schrieb:
> Frank K. schrieb:
>> 1.5.2 SPI (Serial Programming Interface)
>>
>> Der offizielle Name ist ISP (In-System Programming). Diese Bezeichnung
>> solltest Du auch verwenden, denn SPI und ISP ist nicht das gleiche.
>> SS wird für ISP nicht verwendet - bitte aus der Tabelle entfernen!
> Ich kann nichts dafür, dass Atmel das SPI nennt; wenn ich es anders
> nennen würde, wäre die Verwirrung nur größer, was gerade nicht mein
> Ansinnen ist.

Trotzdem ist ISP die geläufigere Bezeichnung.

> Kannst du mir sagen, welche Tabelle auf welcher Seite du meinst?
Seite 25

> Hochspannungsnetze (300 kV oder auch mehr). So gesehen fallen für mich
> 12 Volt noch nicht einmal in den BEreich der Niederspannungsnetze (mit
> anderen Worten: das war Ironie!).

Vorsicht mit Ironie und Sarkasmus. Das funktioniert in geschriebener 
Sprache oft nicht. Verzichte besser komplett auf diese Stilelemente, sie 
werden missverstanden werden.

>> Es fehlen Grundlagen über Digitalschaltungen: Logikpegel, Logikwerte H,
>> L, X, Z, Open Collector/Open Drain, Logikfunktionen, warum es eine dumme
>> Idee ist, Eingänge offen zu lassen, und der Sinn von Pull-Ups und
>> Pull-Downs, wofür den 100n Abblockkondensatoren sind, die man braucht.
> Für den Bereich gibt es jede Menge gute Bücher und Web-Sites; vielleicht
> bin ich da ja ein wenig engstirnig, aber ich würde solche Kapitel als
> Papiervergeudung ansehen.

Es gibt zu jedem Bereich gute Bücher, aber wenn Du Dein Buch als 
One-Stop-Shop siehst, muss ein Mindestmaß davon drin sein, damit der 
Leser seinen Mega 8 auf einem Steckbrett zum Laufen bekommt. Sonst gibt 
es kein Erfolgserlebnis. Und dazu gehören 100n zwischen VCC und GND und 
zwischen AVCC und AGND, dazu gehört, dass AVCC und AGND immer 
angeschlossen werden müssen, auch wenn man die Analogfunktionen nicht 
verwendet, dazu gehört die Warnung vor offenen Eingängen und den dabei 
auftretenden ohen Querströmen in der CMOS-Eingangsstufe etc pp.

> auf dem noch XP läuft und rate mal, wie ich die Zeichen in die Tabelle
> bekommen habe? Indem ich die Alt-Taste gedrückt halte und den dezimalen
> Ziffercode des Zeichens eingegeben habe.

Reingefallen. Das ist eine Kompatibilitätsfunktionalität zu DOS. Damit 
bekommst den OEM-Zeichensatz, der in der "DOS-Box" verwendet wird. Den 
ANSI-Zeichensatz bekommst Du, wenn Du den dezimalen Zeichencode mit 
führender 0 eingibst. Probiere mal <ALT> 164 und <ALT> 0241. Und der 
ANSI-Zeichensatz ist eben der, den Windows-GUI-Programme verwenden.

fchk

[Oliver S. (oliverso)]

Frank K. schrieb:
> Den
> ANSI-Zeichensatz bekommst Du, wenn Du den
einfach eine der Zillionen im Netz verfügbaren Tabellen abschreibst. Was 
dann einen Schritt weitergedacht zu der Erkenntnis führt, daß das 
Abdrucken solch einer Tabelle schlicht überflüssig ist.

Und das zeigt das grundlegende Problem dieses Buches: 
Informationsbeschaffung funktioniert heute einfach anders, gerade im 
Bereich Software.

Ich hab das Buch jetzt mal quergelesen. Das Thema der völlig 
überflüssigen Kapitels zur Projektverwaltung wurde ja schon genannt.

Mein Problem mit diesem Buch ist, daß es an den entscheidenden Stellen 
eben nicht erklärt, was wichtig ist, dafür aber seitenweise 
unwesentliche Nebekriegsschauplätze abhandelt. Die seitenlangen 
Erklärungen  von ALU, speicherarten, bringen nichts. Dafür fehlt es an 
den entscheidenden Stellen.

Was ist ein Timer? Was macht der, mir einfachen Worten erklärt? Was ist 
der Prescaler? Was ist ein Interrupt? Dann Beispiele bringen.

Ist das Buch für Assembler-Programmierer, oder soll es C-Programmieren 
näher bringen? Im ersten Fall wäre eine vollständige Beschreibung des 
Befehlssatzes erforderlich, mit Beispielen. Wenn C, dann mehr C. Mit 
Beispielen, wie man Mikrocontrollerprogramme aufbaut.

Das Kapitel über die avrlibc-Funktionen ist dagegen viel zu lang. Da 
könnte man sich auf die Funktinonen beschränken, die nicht Standard-C 
sind.

Das Buch ist so, wie es da steht, fühlbar von Generation Ü50 für 
Generation ü50. Was vielleicht nicht verkehrt ist, denn alle anderen 
kaufen keine Bücher zu solchen Themen.

Oliver

[Lord of L. (lightninglord)]

> Ebenso vermisse ich eine Schritt für Schritt Anleitung vom installieren
> der IDE bis zur ersten blinkenden LED.
Jetzt frustrierst du mich wirklich. Ich war (und bin immer noch) der
Meinung, dass ich wirklich Schritt für Schritt beschrieben habe, wie man
per Programm eine LED einschaltet und nach Änderung des Programmes
wieder ausschaltet. Bitte um Mithilfe: "Wo habe ich da signifikante
Lücken gelassen?"

Wie gesagt nur überflogen. Und spät wars ja auch. Ich hatte keine Bilder 
von der IDE gesehen, deshalb...wie gesagt Bilder Bilder Bilder ;-)

Noch einmal zum Mega8, hier sind die Debugmöglichkeiten hald deutlich 
beschränkter als beim Mega328...und die Software vom Mega8 ist meist mit 
nur kleinen Änderungen auf einem Mega88, 168, 328 compilierbar. Naja ist 
ja nur ein Vorschlag.

[Paul B. (paul_baumann)]

Oliver S. schrieb:
> Das Buch ist so, wie es da steht, fühlbar von Generation Ü50 für
> Generation ü50.

Das ist doch auch gut so. Wie viele Leute gibt es, die im Rentenalter
merken, daß es gut wäre, sich miitels Kontroller sein Problem lösen zu
können, wenn man es nur anständig und in deutscher Sprache erklärt 
bekäme.
(Ja, manch Einer ist so alt, daß es noch gar keine Engländer gab, als er
in die Schule ging)
;-)

Oliver S. schrieb:
> Was vielleicht nicht verkehrt ist, denn alle anderen
> kaufen keine Bücher Zinslockerung Themen.

Zinslockerung? Ägypten? Torsionsstabfederung?

MfG Paul

[F. F. (foldi)]

Gerhard O. schrieb:
> F. Fo schrieb:
>> Kann ich nur unterstützen.
>> Hebt mal die Hand, wer sich zu Anfang mal ausgesperrt hat! :-)
>
> War so gemeint - hatte das " nicht " glatt übersehen;-)

Aber die Hand war klasse. :-)

[Wolfgang S. (wsm)]

jdhenning schrieb:
> Wolfgang Schmidt schrieb:
>> Daher ist es sinnvoll auf den Einstieg in die 8-Bit Kontroller am
>> Beispiel eines Atmega8(8) mit Vergleichen mindestens zu einem Attiny,
>> einem großen Atmega(128)und auch Xmega hinzuweisen und einen Vergleich
>> der wesentlichen Parameter in das Buch einzufügen. Dies dürfen bis zu 10
>> Typen werden.
>
> Ich bin (wie schon zugegeben) kein MCU-Profi. Kannst du mir so eine
> Liste geben? Einige Fotos und Zeichnungen sind noch in Planung, aber ich
> wollte erstmal abchecken, ob überhaupt ein fundiertes Echo zurück kommt.
>
>   Jürgen

Hallo Jürgen,

ich möchte hier nicht aktiv werden, um die Aufgaben des Autors zu 
übernehmen. Das was du schreibst muss deine Arbeit sein.

Es sei noch angemerkt, dass jede Ironie fehl am Platz ist. Es ist auch 
unüblich, dass ein Autor sich selbst im Buch mit "ich" in den Text 
einbringt. Du schreibst ein hier Sachbuch, keinen Erlebnisbericht.

Es gibt zwischenzeitlich viele Hinweise zur Ergänzung. Konzentriere dich 
darauf, das wesentliche für Anfänger zu erklären.
So genügt z.B. genau ein PWM-Modus zu beschreiben, wobei der Leser erst 
verstehen muss, was mit PWM gemeint ist, bevor er die Diagramme aus dem 
Datenblatt nachvollziehen kann.

Es ist auch vermehrt auf die Notwendigkeit von Beispielen hingewiesen 
worden.
So erscheint es mir sinnvoll auf EVA hinzuweisen. D.h. ein Beispiel zur 
Eingabe über Ports sowie auch den AD-Wandler oder serielle 
Schnittstelle.
Die Verarbeitung am Beispiel einer einfachen Addition von Registern, 
Multiplikation, ggf. Hardwaremultiplikation, falls verfügbar sodann die 
Ausgabe als Bits über einen Port, z.B. zum Schalten eines Relais, über 
die serielle Schnittstelle zu einem Terminalprogramm auf dem PC und zum 
LCD.
Ganz klar sage ich auch, dass der Anschluss einer SD-Karte nicht in dein 
Buch gehören würde.

Viel Erfolg
W.

[dfgh (Gast)]

Habe mal kurz drübergeschaut:
Das mit der Einführung ist für mich kein Problem. Am geschicktesten 
finde ich immer noch die Variante: "Sie wollen direkt loslegen? -> Seite 
42" in einem kleinen Kästchen ganz am Anfang der Einführung.

Die zweite Einführung in "Programmierung des ATmega8" ist allerdings 
recht lang und vermischt meiner Meinung nach viele verschiedene Themen
- Wie dieses Buch zu verstehen ist
- Vorraussetzungen
- Übersicht über das Buch
- Meine Geschichte mit der µC-Programmierung
- Material (bisher für Anfänger recht unverständlich, evt. kurze 
Übersicht über die Bauteile inkl. Funktion, "Käfer" ist für Neulinge 
evt. nicht eindeutig? Jedes Teil einmal mit einem kleinen beschrifteten 
Bild versehen.
Gut wäre auch ein Hinweis, wo man die Teile bekommt! Aus "in Hong Kong 
bestellen" wird nicht jeder schlau, auch ich bin erst durch das Forum 
hier auf die Idee gekommen, per Ebay etc. im Ausland zu bestellen. Da 
gibt es ja auch diverse Regeln wegen Zoll etc. zu beachten. Vielleicht 
auch Reichelt, Conrad usw. erwähnen (als Anhang hinten im Buch).
Als Tipp vielleicht auch ein einfaches Multimeter für 10-30€ empfehlen?

"Interrupte" ist mir auch aufgefallen - hier im Forum wird 
wahrscheinlich jeder Anfänger dafür sofort gesteinigt :-) Solche 
Begriffe lieber englisch lassen und eine kleine "Erklärungsbox" an den 
Rand setzen

Dann, wie viele schon erwähnt haben, am Anfang mehr Bilder. Unbedingt 
darauf achten, dass man die wichtigen Informationen auch erkennen kann 
(es gibt da grauenhafte Fotos in manchen Büchern)

Ein kurzer Absatz mit einer kleinen Grafik darüber, wie die Steckbretter 
verdrahtet sind (immer 5 Pins zusammen) schadet auch nicht, schließlich 
sieht man das dem Steckbrett nicht an. Hier habe ich schon einige 
Verwirrte Gesichter gesehen, als man denen das Steckbrett ohne Erklärung 
vorgesetzt hat!

Zu den Links am Ende:
>>http://www.atmel.com/images/atmel-2486-8-bit-avr-microcontroller-atmega8_l_datasheet.pdf
Die Hersteller ändern ihre Serverstruktur gerne mal, dann gehen solche 
Links ins Leere. Am besten dazu einen Hinweis machen...

>>http://www.mikrocontroller.net/articles/AVR-Tutorial
>>Recht umfangreiches Tutorial. Viele Beispiele in Assembler. Ohne
>>Grundkenntnisse und einen guten Glossar (also dieses Buch hier!) ist der
>>Wissenserwerb auch hier etwas mühsam.
>>Die Forengemeinde ist extrem aktiv (und manchmal auch extrem gemein/offen
>>/ehrlich;knallharte Kerle eben).
Wunderbare und sehr liebevolle Beschreibung dieses Forums! Daumen hoch! 
:-)

[Wolfgang S. (wsm)]

Die bei Atmel schwer zu findende Dokumentation.

[Hans W. (Firma: Wilhelm.Consulting) (hans-)]

Ich habe dein Buch kurz überflogen und bin mir nicht ganz sicher ob/in 
wie weit es dem Newbie tatsächlich hilft.

Meiner Meinung nach  wiederholst die von dir aufgezeigten "Fehler der 
anderen Autoren" und gibst ein Datenblatt fast 1:1 wieder und wirfst mit 
Fachtermini/Abkürzungen nur so um dich.

Um von einer einfachen CPU bis zu einem Scheduler zu kommen sind auch 
1000 Seiten nicht ausreichend.

Schau dir beispielsweise das Arduino-Tutorial an. Der Inhalt des 1. 
Kapitels wäre für ein richtiges Einsteigerbuch möglicherweise noch Ok.

Im übrigen ist dieses Tutorial in meinen Augen auch nutzlos weil dem 
Einsteiger nicht einmal ein Hinweis gegeben wird warum beim 
Blinky-Beispiel ein 220Ohm Widerstand verwendet wird... von UART und ADC 
ganz zu schweigen...

Auf jeden Fall Hut ab für den Aufwand den du betreibst!

73

PS.: Schonmal an einen Eigenverlag gedacht? ePubli&Co könnten eine 
interessante Alternative zu einem "richtigen" Verlag sein...

[F. F. (foldi)]

Wolfgang Schmidt schrieb:
> Die bei Atmel schwer zu findende Dokumentation.

Man sollte immer unbedingt auf der Atmel Seite unter Produkte nach den 
verwendeten Controller schauen und dort dann unter Dokumente.
Einig werden sich wiederholen, aber es sind dort auch immer spezifische 
Dokumente für diesen einen Controller oder der Gruppe zu der er gehört.

Auch sehr nützlich, gerade für Anfänger die mit den kryptischen 
Bezeichnungen der Gehäuse nichts anfangen können:
http://www.atmel.com/Images/doc4064.pdf

[jdhenning (Gast)]

Frank K. schrieb:
>> Kannst du mir sagen, welche Tabelle auf welcher Seite du meinst?
> Seite 25
Danke, ich habe die Tabelle im Manuskript berichtigt.

>>> Es fehlen Grundlagen über Digitalschaltungen: Logikpegel, Logikwerte H,
>>> L, X, Z, Open Collector/Open Drain, Logikfunktionen,
Ich hatte mich mit Herrn Bombien (Senior Editor beim O'Reilly Verlag 
Deutschland)darüber unterhalten und er war eher der Meinung, dass dieses 
Thema nicht mit dazu gehört (als E-Techniker hätte ich überhaupt keine 
Schwierigkeiten etliche Seiten damit zu füllen).

> Und dazu gehören 100n zwischen VCC und GND und zwischen AVCC und AGND,
> dazu gehört, dass AVCC und AGND immer angeschlossen werden müssen,
> auch wenn man die Analogfunktionen nicht verwendet, dazu gehört die
> Warnung vor offenen Eingängen und den dabei auftretenden hohen
> Querströmen in der CMOS-Eingangsstufe etc pp.
Danke, guter Hinweis, nehme ich auf. Ich hatte irgendwo die Empfehlung 
gelesen, man solle eine 10 µH Spule zwischen VCC und AVCC setzen. 
Erscheint mir sinnvoll. Erfahrungen?

> Reingefallen. Das ist eine Kompatibilitätsfunktionalität zu DOS. Damit
> bekommst den OEM-Zeichensatz, der in der "DOS-Box" verwendet wird. Den
> ANSI-Zeichensatz bekommst Du, wenn Du den dezimalen Zeichencode mit
> führender 0 eingibst. Probiere mal <ALT> 164 und <ALT> 0241. Und der
> ANSI-Zeichensatz ist eben der, den Windows-GUI-Programme verwenden.
Jetzt arbeite ich schon seit über 30 Jahren mit PCs, aber das habe ich 
noch nicht gewusst. Danke.

[jdhenning (Gast)]

Hallo Oliver

Oliver S. schrieb:
> Mein Problem mit diesem Buch ist, daß es an den entscheidenden Stellen
> eben nicht erklärt, was wichtig ist, dafür aber seitenweise
> unwesentliche Nebenkriegsschauplätze abhandelt. Die seitenlangen
> Erklärungen  von ALU, Speicherarten, bringen nichts. Dafür fehlt es an
> den entscheidenden Stellen.
>
> Was ist ein Timer? Was macht der, mir einfachen Worten erklärt? Was ist
> der Prescaler? Was ist ein Interrupt? Dann Beispiele bringen.

Dann sei doch bitte so nett und benenne die entscheidenden Stellen (dann 
habe ich eine Chance, darüber nachzudenken, ob ich da nachbessern 
sollte).

"Dann Beispiele bringen." Ich habe bei meinen Recherchen problemlos zu 
jedem Einzelthema seitenweise Beispiele gefunden, aber nur ganz ganz 
selten gute Erklärungen. Folglich halte ich es für eine schlechte Idee, 
den Schwerpunkt in Richtung Beispiele zu verschieben, wenn jeder Depp 
diese problemlos im Internet finden kann.

Falls du mit deiner Meinung Recht hast, dass die u50 wesentlich besser 
darin sind, Informationen im Internet zu finden, als die ü50, dann 
brauchst du dich nicht weiter über das Buch aufzuregen, denn dann wird 
ja keiner der u50 jemals mit dem Buch belästigt werden.

[jdhenning (Gast)]

Lord of Lightning schrieb:
> Wie gesagt nur überflogen. Und spät wars ja auch. Ich hatte keine Bilder
> von der IDE gesehen, deshalb...wie gesagt Bilder Bilder Bilder ;-)

Kommen, kommen, kommen! :-)

[jdhenning (Gast)]

Klaro schrieb im Beitrag #3939148:
> Wenn man für das Buch erst ein Studium machen muss, wäre es eher
> nur für eine begrenzte Leserschaft geeignet, aber nicht der breiten
> Masse, wie z.B. Schüler. Bücher werden aber nur gedruckt, wenn die auch
> vermarktet werden können. Bis dahin ist noch ein weiter Weg. Als Einstig
> ist es demnoch eine beachtenswerte Lektüre.

Danke für das Blümchen. Es ist ziemlich schwierig technische Inhalte so 
aufzubereiten, dass sie ein breites Spektrum an Leserschaft anspricht. 
Ich erinnere mich auch noch gut an die Lehrbücher an der Uni, bei denen 
man immer den Eindruck hatte, sie sollten hauptsächlich klar machen, wie 
intelligent der Autor ist und wie blöde man selbst. Eine angenehme 
Ausnahme waren die Lehrbücher aus der damaligen DDR; die waren eindeutig 
geschrieben, damit man die Sache verstehen konnte; leider war es immer 
sehr auswändig, die zu beschaffen.

Was du jetzt gelesen hast ist das Rohmanuskript eines Lernbuches und 
nicht eines Lehrbuches. Eigentlich gibt es nur noch eine Großbaustelle, 
aber an vielen Ecken noch Restarbeiten (das kommt dann später, wie der 
HEimwerker sagt). Da es ein Lernbuch sein soll, sehe ich auch kein 
Problem darin (was mehrfach negativ angemerkt wurde) auch die Ich-Form 
zu benutzen. Angestrebtes Ziel ist: Wie würde ich versuchen, es meinem 
besten Freund zu erklären?

Danke für die Kommentare
  Jürgen

[jdhenning (Gast)]

Wolfgang Schmidt schrieb:
> Die bei Atmel schwer zu findende Dokumentation.

Danke, werde ich mir reinziehen, wenn ich die ganzen Posts beantwortet 
habe.

Jürgen

[jdhenning (Gast)]

Hans Wilhelm schrieb:
> Schonmal an einen Eigenverlag gedacht?

Yepp. Ich habe vor einigen Monaten ein Buch über Photovoltaik 
(Photovoltaik für technisch Unbegabte, Akademiker mit zwei linken Händen 
und alle anderen) bei BOD veröffentlicht. Man muss praktisch alle 
Arbeiten selbst machen, was bei dem Buch noch gut möglich war 
(technisch/inhaltlich nicht sooo anspruchsvoll). Bei dem ATmega-Buch 
möchte ich doch lieber auf professionelle Hilfe setzen. Hätte ich nicht 
schon darüber nachgedacht gehabt, dannhättest du mich jetzt ins Grübeln 
gebracht. Danke,

  Jürgen

[jdhenning (Gast)]

F. Fo schrieb:
> Auch sehr nützlich, gerade für Anfänger die mit den kryptischen
> Bezeichnungen der Gehäuse nichts anfangen können:
> http://www.atmel.com/Images/doc4064.pdf

Danke, über die Datei war ich noch nicht gestolpert. Ich werde den Link 
in die "Da werden sie geholfen"-Liste aufnehmen.

  Jürgen

[Gerhard O. (gerhard_)]

Jetzt möchte ich mal was ganz Ketzerisches aufbringen:

Es ist ja ein großartiges Unterfangen ein Sachbuch allein zu schreiben. 
Aber trotzdem bin ich der Ansicht dass man auf dem Gebiet als kleine 
Authorengemeinschaft letztlich doch vielleicht bessere Resultate 
erzielen könnte. Jeder von uns kennt sich in spezifischen Gebieten mehr 
oder weniger besser aus und kann Wertvolles beitragen. Dann kommt noch 
die manchmal unerbittliche, ehrliche Kritik aneinander die oft hart zu 
akzeptieren ist, aber letzlich Maximales erreichen läßt. Erschwerend 
kommt noch dazu, dass es wahrscheinlich das perfekte Buch nicht geben 
kann, weil jeder Leser einen anderen Verständnishintergrund mitbringt 
und man es nicht jeden recht machen kann. Oft wollen Leser auch nur ganz 
schnell eine Lösung zu einem ihm spezifischen Problem finden. Die Gründe 
können oft vielfältig sein.

Mir geht es jedenfalls so dass man oft etwas nur dann richtig versteht 
wenn man aus verschiedenen Quellen schöpfen kann.

Dann, gerade im Einführungsbereich zu Mikrocontroller, kommt es manchmal 
auf exakte, fehlerfreie und 100% lauffähige Beispiele an. Oft ist es 
sehr lehrreich ein gutes Programm mit Hilfe der Dokumentation des MCUs 
und Kompiler zu analysieren bis man das Warum begreift.

Ich bin der Meinung dass jeder Mensch irgendwie anders am Besten lernt. 
Was für den einen absolut logisch und verständlich ist, sind für andere 
trotz ehrlicher Anstrengung nur Böhmische Dörfer. Deshalb geht es oft 
nicht ausreichend mit nur einer Informationsquelle.

Wenn ich also eine Wunschliste aufstellen würde, dann möglicherweise 
eine Struktur wie diese:

1) Eine kleine Einführung mit Beispielen in die Welt der MCUs wo sie oft 
verwendet werden
2) Eine kurze Einführung in die C Sprache mit Schwerpunkt auf 
Mikrocontroller Anwendung und Fußangeln
3) Ausführliche Beschreibung der Innnereien eines representativen, 
popularem, leicht erhändlichen MCU-Typ wie ATMEGA32. Auch sollten genug 
Schaltungs Beispiele dabei sein wie man einen MCU minimalistisch richtig 
beschaltet.
4) Lauffähige HW+FW Beispiele für jedes (interne) Peripheral. Auf diesem 
Gebiet kommt es darauf an. (Gehört zwar nicht zum AVR Thema: Beim STM32 
hatte ich Probleme meine eigene I2C Implentation 100%ig zuverlässig zum 
Funktionieren zu bringen. Das Datenblatt ist hier nicht besonders 
hilfreich weil es nur für die Leute verständlich ist, die das Interface 
entwickelt haben. Für aussenstehende lassen sich mangels von State 
Machine Diagrammen die Hintergründe der I2C HW. nicht nachvollziehen. 
Wer schon damit gearbeitet hat, kann vielleicht auch ein Lied davon 
singen. Bis ich dann endlich auf ST Appnote 1284 gestossen bin, deren 
Implementation letztlich 100%ig funktioniert hat.)
5) Einstellung der Entwicklungsumgebung mit kompilierbarem, 100%ig 
lauffähigem Testprogram um die ganze Toolkette von PC zu MCU zu testen.
6) Sektion über den Gebrauch von wichtigen externen Peripherien wie LCD 
display Module, Io-Expander, ext. EEPROM, RTCs, e.t.z. 
(Schaltungsbeispiele für jede externe Beschaltung). Auch wären Hinweise 
zwischen Spannungswandlung nützlich. Wie man z.B. 3V Logik mit einem 5V 
MCU verbinden kann und umgekehrt.
7) Überblick in Programmierungstechniken wie State Machines, RTOS, 
Interrupts, Gebrauch des Schlafmodus.
8) Eine praktische Kurzanleitung wie man die Minimum Beschaltung richtig 
hinkriegt(Quarzbeschaltung, Abblocken, Reset Beschaltung, ISP Fußangeln, 
SPI Isolation in Bezug auf ISP Zugang. 
Spannungsversorgungsbetrachtungen.
8b) Genaue Hinweise, Erklärungen der Fuses und Anleitung zum 
Programmieren des FLASH. Kurzbeschreibung/Hinweise auf gängige 
erhältliche Programmer/Debugger.
8c) Ein Kapitel wie man an besten richtig debuggen tut.
9) Ein vollständiges, nettes und interessantes funktionierendes 
Beispielprojekt mit Teileliste.
10) Webseite WO man sich die lauffähigen Beispiele runterladen kann.
11) Richtige Projektplanung und Dokumentierung
12) Liste von wichtigen Dokumenten ohne die man nicht arbeiten sollte
13) Hinweise zur Minimalfehlersuche wenn mal überhaupt nichts geht
14) und, und, und. mehr fällt mir im Augenblick nicht ein...

Irgendwie finde ich das Thema zu groß für einen Einzelnen um in einem 
Buch wirklich erschöpfend behandelt werden zu können.

Ich will wirklich niemanden auf die Zehen treten und nur meine 
Sichtpunkte von meinen bisherigen Erfahrungen im Leben zum Thema 
kundgeben.


Grüße,
Gerhard

P.S. Bitte keine Steine werfen. Das tut so weh:-) Duck und weg...

[Frank K. (fchk)]

jdhenning schrieb:

>> Und dazu gehören 100n zwischen VCC und GND und zwischen AVCC und AGND,
>> dazu gehört, dass AVCC und AGND immer angeschlossen werden müssen,
>> auch wenn man die Analogfunktionen nicht verwendet, dazu gehört die
>> Warnung vor offenen Eingängen und den dabei auftretenden hohen
>> Querströmen in der CMOS-Eingangsstufe etc pp.
> Danke, guter Hinweis, nehme ich auf. Ich hatte irgendwo die Empfehlung
> gelesen, man solle eine 10 µH Spule zwischen VCC und AVCC setzen.
> Erscheint mir sinnvoll. Erfahrungen?

Ich verwende oft so eine kleine Ferrit-Induktivität, ähnlich wie das 
hier:

http://www.reichelt.de/Fest-Induktivitaeten-SMD/JCI-2012-10-/3//index.html?ACTION=3&GROUPID=3178&ARTICLE=9001&OFFSET=16&WKID=0&;

Gibts auch in verschiedenen Größen und Werten.

Ferrit deswegen, weil der die HF-Anteile in Wärme umsetzt. Man will hier 
eben keine besonders hohe Güte haben. Du willst ja keinen Schwingkreis 
aufbauen.

Bedrahtet sieht das so aus:

http://www.reichelt.de/Fest-Induktivitaeten-axial/L-HBCC-10-/3//index.html?ACTION=3&GROUPID=3179&ARTICLE=86460&OFFSET=500&WKID=0&;

fchk

[Noch Einer (Gast)]

Hallo

ich habe angefangen dein Buch zu lesen und kann erst mal nur sagen: 
Respekt für die Fleißarbeit und den Versuch alles verständlich zu 
erklären.

Leider scheint das erwartete Vorwissen "gut gemischt" zwischen Null und 
soliden Grundkenntnissen aus Informatik und E Technik zu liegen.
Was ist ein Bit, warum benötigt der erste Opperand 2 Byte (was ist ein 
Byte ?) der Befehl aber mindestens nur ein Byte ?(Deine Erklärung auf 
Seite 15 ff) usw.
Für die meisten hier, mich selber einschlossen, sind das keine Frage und 
"selbstverständlich" (?) bekannt - aber ganz bestimmt nicht für einen 
Interessierten aus anderen Bereichen.

Eigentlich wurde schon alles hier geschrieben, aber insbesondere die 
Hinweise von :
 Gerhard O. (gerhard_) Datum: 26.12.2014 17:31
  Autor: Hans Wilhelm (hans-) Datum: 26.12.2014 12:39

sind sehr treffend.

Aber du hast ja schon selbst erkannt :
" Es ist ziemlich schwierig technische Inhalte so aufzubereiten, dass 
sie ein breites Spektrum an Leserschaft anspricht."
Selbst ein wirklich gutes und umfassendes Anfängerbuch über den "ach so 
simpelen" Arduino hat über 1000 Seiten (immer noch knapp 800 wenn man 
die Elektrische Grundlagenvermittlung weg lassen würde)
 - Die elektronische Welt mit Arduino entdecken  von Erik Baumann-

Was du versuchen könntest ist das Buch jemanden zu lesen zu geben der 
noch keinerlei Erfahrung mit µC hat, aber gerne einen einsetzen würde um 
ein Problem  zu lösen (z.B. Modelleisenbahner, Aquarianer, Mopped/ 
Auto"tuner" usw.)
-Also solchen Leuten wie die manchmal im Forum Anfragen ob jemand für 
sie etwas entwickeln kann und dann die entsprechende Antwort erhalten 
die sich für den Unwissenden sehr gemein und arrogant anhört (weil sie 
den entsprechenden Aufwand nicht kennen können).

mfg

      Noch Einer

[jdhenning (Gast)]

@ Frank K.
Danke!

@ Gerhard O.
Keine Sorge, aus dem Alter, dass ich mit Steinen werfe bin ich raus; 
deshalb zunächst herzlichen Dank für den langen Post.

"Irgendwie finde ich das Thema zu groß für einen Einzelnen um in einem
Buch wirklich erschöpfend behandelt werden zu können."
Das ist nicht mein Vorhaben (glücklicherweise). Das erste Problem ist, 
was kann man alles weglassen, damit der Rest noch ein vollständiges Buch 
abgibt? Und das zweite Problem ist, welche Vorkenntnisse kann/darf man 
voraussetzen.

Zu einigen Kapiteln wurde hier ja kritisch angemerkt, dass ich die auch 
ruhig weglassen könnte. Den Kritikern war nur nicht klar, dass ich 
letztlich auch ein fauler Mensch bin. Wenn ich nicht gute Gründe gesehen 
hätte diese Kapitel zu schreiben, dann hätte ich das sicherlich auch 
nicht gemacht. Wenn ich Seiten schinden wollte, dann hätte ich super 
viele Beispiele jeweils zusammen mit dem kompletten Code gebracht. Damit 
wäre ich problemlos schon über der 300-Seiten-Marke.

Das Problem war also immer, wie viel muss ich erzählen, damit ein 
technisch normal begabter Leser die Zusammenhänge begreifen und sich 
somit die einzelnen Funktionen erschließen kann (also letztlich Hilfe 
zur Selbsthilfe). Auch hatten viele bemängelt (so wie auch du), dass man 
doch bitteschön eine modernere MCU hätte aussuchen sollen. TWI wird 
dadurch auch nicht einfacher und das Buch hat jetzt schon eine 
hinreichende Länge und Komplexizität. Die Auswahl beruht also nicht auf 
Altersstarrsinn (wie hier jemand vermutete) sondern ist absoluter 
Pragmatismus (ein Tiny wäre so gesehen noch besser gewesen, aber dann 
wäre das Buch zu dünn gewesen).

Bei einem Buch mit 200 A4-Seiten seufze ich und nach ein wenig 
Überwindung arbeite ich mich dann da durch. Bei einem Buch mit 300 
Seiten gehe ich in das Inhaltsverzeichnis und sehe nach, was mich denn 
interessieren könnte (das wäre didaktisch gesehen ein Misserfolg).

Also noch mal vielen Dank für die vielen Überlegungen und ich schließe 
eine Beteiligung an einem anderen Buchprojekt absolut nicht aus.

  Jürgen

[Wolfgang S. (wsm)]

@Noch Einer

Da muss ich doch mal widersprechen.
Es gibt natürlich viele Grundlagen, die man wissen sollte. Aber bei Bit 
und Byte anzufangen ist in diesem Fall nicht notwendig.
Auch Grundverknüpfungen wie UND und ODER u.s.w. sollten nicht erklärt 
werden.
Wenn man sich darauf einlässt, dann landet man irgendwann beim Aufbau 
eines Gatters, beim Transistor, beim Halbleiter und letztendlich beim 
Ohmschen Gesetz.
Dem Anfänger, für den dieses Buch gedacht, ist dürfte man schon zumuten, 
dass er die genannten Punkte kennt.

Genau so wie den Umgang mit einer Programmiersprache, ob C++, Pascal, 
BASIC (BASCOM ergibt sich daraus) oder Java. Was der Anfänger später 
benutzt oder ausschließt, sollte sich aus Beispielen in dem Buch 
ergeben.

W.

[Paul B. (paul_baumann)]

Wolfgang Schmidt schrieb:
> Da muss ich doch mal widersprechen.

Na, da muss ich doch mal widersprechen.

>Es gibt natürlich viele Grundlagen, die man wissen sollte.

Wenn es ein Buch für Anfänger werden soll, die u.U. aus völlig anderen
Berufsumfeldern kommen, dann gibt es NICHTS, was sie wissen SOLLTEN.

>Aber bei Bit
>und Byte anzufangen ist in diesem Fall nicht notwendig.
Natürlich.
>Auch Grundverknüpfungen wie UND und ODER u.s.w. sollten nicht erklärt
>werden.

Die vor allen Dingen. Gerade beim Setzen/Löschen von mehreren Bits in
einem Register, um z.B. eine gewollte Betriebsart z.B. eines Timers 
einzustellen, ist das zwingend notwendig.

@jdHenning
Du bist auf dem richtigen Weg.

MfG Paul

[Salewski, Stefan (Gast)]

Paul Baumann schrieb:
> @jdHenning
> Du bist auf dem richtigen Weg.

Sag das nicht...

Die Zielgruppe für das Buch ist mir unklar: Anfänger, die auch noch 
etwas Begriffsstutzig sind, wird das Buch doch eher noch überfordern. 
Und die anderen, auch smarte Anfänger, wird es über weite Strecken nur 
langweilen, zumal der Schwafelanteil doch noch beträchtlich ist.

Und das ganze kommerziel: 9,99 Euro pro Buch, davon vielleicht ein Euro 
für den Autor ab dem tausensten Exemplar. Und insgesammt wird man 
vielleicht ein paar Dutzend Bücher absetzen können. Ja, vor dreißig 
Jahren konnte man von so etwas noch etwas mehr verkaufen, da haben 
manche Leute sogar noch gedruckte Zeitungen gelesen. Dann doch lieber im 
Sommer mal für den Nachbarn den Rasen mähen, oder ein paar Zeitungen 
austragen, da hat man einen größeren Verdienst.

Gute Bücher, und Leute die gute Bücher schreiben können, gibt es wenige. 
Und gute Bücher erfordern viel Arbeit und eine klare Zielgruppe. Aber 
auch dann wird man sie heutzutage nur in geringer Stückzahl verkaufen 
können.

[Wolfgang S. (wsm)]

Es sollte doch die Entscheidung des Autors sein, an welcher Stelle er 
anfängt.

So geht in allen Ausbildungszweigen die ich kenne, und in einem 
Ausbildungszweig war ich fast 30 Jahre aktiv, jeder 
Mikrocontrollernutzung eine Phase der elementaren Logik voraus.

Natürlich kann man diesen Teil mit in das Buch übernehmen. Dann entfernt 
der Autor sich von seinem eigenen Thema und muss für seine geplante 
Publikation einen neuen Titel suchen. 300 Seiten möchte er ja nicht 
schreiben.

Wer entscheiden soll, welchen Mikrocontroller er verwenden will, kennt 
in der Regel die Begriffe Bit, Byte, UND, u.s.w. Falls nicht, greift man 
dazu auf Literatur zurück, die es ohne Ende und auch in Lehrbüchern 
gibt.

Aus eigener Erfahrung kann ich nur empfehlen zuvor die Zielgruppe, oder 
auch mehrere, klar zu definieren. Dann die Voraussetzungen abzugrenzen, 
die Abstraktionsfähigkeit einzuordnen und das was man darauf aufbauen 
kann.

Themen wie elementare Logik, Logik-Bausteine, Programmiertechniken oder 
Spezialanwendungen gehören in andere Bücher.

Aber, wie ich bereits erwähnt habe, sollte jede interne Einheit eines 
Atmega an einem einfachen Beispiel erklärt werden.

Bisher habe ich mich bemüht Hinweise zu geben, die dem Ziel des Autors 
und dem Thema gerecht werden.
Viele andere Beiträge haben die Grundüberlegungen aus den Augen 
verloren.

W.

[Wolfgang S. (wsm)]

Sollen wir mal die Zielgruppe(n) definieren:

1. Bastler ohne Vorkenntnisse      -      bei Ohm und Volta anfangen
2. Elektriker                      -      phys. Stromrichtung definieren
3. Schüler 8. - 10. Klasse         -      Siehe LEGO
4. Schüler Stufe 12                -      Facharbeiten z.B. Datenlogger
5. Abiturienten stud. E-Technik    -      Schau mal in die Uni-Skripte
6. Dipl (Fh) E-Technik             -      braucht nur das Datenblatt
7. Bastler mit el. Vorkenntnissen  -      sucht nur Atmega-Informationen
8. Physik-/Informatik-Lehrer       -      benötigen päd. aufgearbeitete 
Bsp

u.s.w.

Du kannst dich für max. drei zusammenliegende Zielgruppen entscheiden.

[jdhenning (Gast)]

Moin Noch Einer.

Noch Einer schrieb:
> Aber du hast ja schon selbst erkannt :
> " Es ist ziemlich schwierig technische Inhalte so aufzubereiten, dass
> sie ein breites Spektrum an Leserschaft anspricht."
> Selbst ein wirklich gutes und umfassendes Anfängerbuch über den "ach so
> simpelen" Arduino hat über 1000 Seiten (immer noch knapp 800 wenn man
> die Elektrische Grundlagenvermittlung weg lassen würde)
>  - Die elektronische Welt mit Arduino entdecken  von Erik Baumann-

Der heißt Bartmann und das Buch hat nur 700 Seiten. Aber ich will hier 
nicht meckern. Auch 700 Seiten sind mMn deutlich viel zu viel, weil das 
keiner mehr liest (und ich habe es auch nicht gelesen; und bei 1.000 
Seiten wäre das Buch noch nicht einmal tauglich um Fliegen 
totzuschlagen, weil man wegen dem Gewicht zu langsam ist; Oooops, ich 
habe gerade gesehen, dass das Buch auch von O'Reilly ist und hoffe mal, 
dass keiner von denen hier mitliest).

Allerdings hatte ich mir von O'Reilly "AVR-Programming von Eliot 
Williams" angetan (ich war nicht so begeistert; mehr will ich dazu nicht 
sagen) und "Embedded Hardware von John Catsoulis" (schon deutlich 
besser, geht aber auch nicht sehr in die Tiefe).

Mein Vorhaben war also, so kurz und knapp wie irgend möglich alle 
Funktionen des ATmega8 zu beschreiben und was man an Rüstzeug braucht, 
um sinnvoll mit ihm umgehen zu können. Wenn Leute meinen, ich hätte 
etwas anderes machen sollen (etwa angeln gehen oder Skat spielen), dann 
ist das voll in Ordnung.

Ohne mir jetzt zu sehr geistig auf die Schulter zu klopfen: Eigentlich 
ist es genau das Buch, das ich mir vor einem Jahr gerne gekauft hätte. 
Gab's aber nicht, also musste ich es schreiben. Grins!!

Das heißt aber nicht, dass ich die Kommentare nicht ernst nehme. Absolut 
nicht! Die Zielgruppe sind nicht Jugendliche, die ihr Moped tunen 
wollen, sondern Leute, die vorhaben, so zu werden wie ihr (ich bin mir 
noch nicht sicher, ob ich sie eindringlich warnen sollte).

Gruß
  Jürgen

[Wolfgang S. (wsm)]

... und schätze mal ab, wie groß deine Zielgruppe ist.

habe ich als letzten Satz vorhin vergessen.

W.

[jdhenning (Gast)]

Paul Baumann schrieb:
> @jdHenning
> Du bist auf dem richtigen Weg.

Kurzen Dank für die Blume.
  Jürgen

[jdhenning (Gast)]

Klaro schrieb im Beitrag #3939748:
> Nicht unbedingt, weil das eine Kategorie des ATMega ist, die
> auch (gewollte) Einschränkungen haben, aber es wäre sicher nicht
> verkehrt im Buch eine ATMega-Tabelle zu führen, sowie einige Typen
> da mal erwähnend raus zu picken und die wesentlichen Unterschiede
> zu erläutern.

Ich habe das aufgrund eines Vorschlags hier aus dem Forum erstmal so 
gelöst, dass ich im Kapitel "Hier werden sie geholfen" den Link
http://www.atmel.com/Images/doc4064.pdf
eingefügt habe. Das ist zugegebenermaßen die Lösung für Faule (also 
mich), hilft dem möglichen LEser aber schon mal weiter.

Jürgen

[jdhenning (Gast)]

Salewski, Stefan schrieb:
> Und die anderen, auch smarte Anfänger, wird es über weite Strecken nur
> langweilen, zumal der Schwafelanteil doch noch beträchtlich ist.

Das Problem dabei ist, welches Niveau soll man ansetzen? Wenn es um 
jemanden geht, der sich seit 20 Jahren beruflich mit MCUs beschäftigt, 
dann wird der Schwafelanteil meines Buches sehr nahe bei 100% liegen. 
Wenn es um jemanden geht, der vor ein paar Monaten angefangen hat, sich 
mit Computern (also nicht als Nutzer der klassischen Programme) zu 
beschäftigen und jetzt etwas über MCUs wissen möchte, dann liegt der 
Schwafelanteil sehr nahe bei 0% (sogar wenn es absolutes Schwafeln wäre, 
er würde es nicht bemerken können).

Wenn ich bei der technischen Literatur mal die Uni-Lehrbücher komplett 
außen vor lasse, dann ist der Schwafelanteil in meinem Buch sehr weit 
unter dem allgemeinen Durchschnitt (neben fehlender Klarheit einer der 
Gründe, weshalb ich überhaupt angefangen hatte, das Buch zu schreiben).

Falls es mit O'Reilly klappen sollte, dann befürchte ich, dass denen der 
Schwafelanteil viel zu gering ist (Hallo Herr Bombien [falls sie 
mitlesen], das war nicht als Beleidigung gemeint; ich weiß, dass da 
wirtschaftliche Überlegungen hinter stecken).

Stefan, auch wenn du mir das übel nimmst, ich werde mich da völlig 
pragmatisch den Wünschen des Verlegers unterordnen (und die gehen zu 
mehr Schwafel; ähh, was hab ich da gerade geschrieben?).

Gruß
  Jürgen

[jdhenning (Gast)]

Wolfgang Schmidt schrieb:
> Wer entscheiden soll, welchen Mikrocontroller er verwenden will, kennt
> in der Regel die Begriffe Bit, Byte, UND, u.s.w. Falls nicht, greift man
> dazu auf Literatur zurück, die es ohne Ende und auch in Lehrbüchern
> gibt.
Honig auf meine Seele! Endlich einer, der mich versteht!

Ok, das war jetzt ein Scherz. Aber ich möchte es ausdrücklich mal gesagt 
haben: Ich war seit locker über einem Jahr immer mal wieder als Gast 
hier unterwegs und ich kann mich nicht an sehr viele Threads erinnern, 
in denen es so gesittet zuging, wie in diesem. Also tiefe Verbeugung, 
Hut ab und Danke! Muß man ja mal sagen dürfen!

> Themen wie elementare Logik, Logik-Bausteine, Programmiertechniken oder
> Spezialanwendungen gehören in andere Bücher.
Sehe ich auch so.

> Aber, wie ich bereits erwähnt habe, sollte jede interne Einheit eines
> Atmega an einem einfachen Beispiel erklärt werden.
Das ist, ebenso wie der Wunsch nach viel viel mehr Bildern und 
Zeichnungen, zu mir vorgedrungen.

> Bisher habe ich mich bemüht Hinweise zu geben, die dem Ziel des Autors
> und dem Thema gerecht werden.
Was habe ich falsch gemacht, weshalb du das jetzt ändern willst?

Danke & Tschüs
  Jürgen

[Conny G. (conny_g)]

jdhenning schrieb:
> Salewski, Stefan schrieb:
>> Und die anderen, auch smarte Anfänger, wird es über weite Strecken nur
>> langweilen, zumal der Schwafelanteil doch noch beträchtlich ist.
>
> Das Problem dabei ist, welches Niveau soll man ansetzen? Wenn es um
> jemanden geht, der sich seit 20 Jahren beruflich mit MCUs beschäftigt,
> dann wird der Schwafelanteil meines Buches sehr nahe bei 100% liegen.
> Wenn es um jemanden geht, der vor ein paar Monaten angefangen hat, sich
> mit Computern (also nicht als Nutzer der klassischen Programme) zu
> beschäftigen und jetzt etwas über MCUs wissen möchte, dann liegt der
> Schwafelanteil sehr nahe bei 0% (sogar wenn es absolutes Schwafeln wäre,
> er würde es nicht bemerken können).
>
> Wenn ich bei der technischen Literatur mal die Uni-Lehrbücher komplett
> außen vor lasse, dann ist der Schwafelanteil in meinem Buch sehr weit
> unter dem allgemeinen Durchschnitt (neben fehlender Klarheit einer der
> Gründe, weshalb ich überhaupt angefangen hatte, das Buch zu schreiben).
>
> Falls es mit O'Reilly klappen sollte, dann befürchte ich, dass denen der
> Schwafelanteil viel zu gering ist (Hallo Herr Bombien [falls sie
> mitlesen], das war nicht als Beleidigung gemeint; ich weiß, dass da
> wirtschaftliche Überlegungen hinter stecken).

Da stimme ich voll zu. Offensichtlich muss ein Fachbuch, das 40 Euro 
wert sein soll ein gewisses Gewicht und Seitenzahl haben.
Fast alle Fachbücher könnten einfach halb so dick sein...
Das erste Mal, das ich diese Annahme auch mal ausgesprochen sehe.

> Stefan, auch wenn du mir das übel nimmst, ich werde mich da völlig
> pragmatisch den Wünschen des Verlegers unterordnen (und die gehen zu
> mehr Schwafel; ähh, was hab ich da gerade geschrieben?).
>
> Gruß
>   Jürgen

[jdhenning (Gast)]

Hallo Wolfgang,

deine Typisierung trifft es sehr gut (und letztlich werde ich den Verlag 
entscheiden lassen, welche drei das sein sollen; wenn das gewünschte 
Niveau so niedrig ist, dass ich das ganze Buch umschreiben muss, dann 
wird das aber nichts werden; letztlich ist das ganze Buchprojekt 
eigentlich eine Trotzreaktion: ich wollte mir durch ein mieserablig 
geschriebenes Datenblatt nicht vorschreiben lassen, was ich verstehen 
darf und was nicht!).

Wolfgang Schmidt schrieb:
> 6. Dipl (Fh) E-Technik             -      braucht nur das Datenblatt

Das war ja das Problem. Ich bin Dipl.-Ing.(TU) E-Technik und das 
Datenblatt reichte NICHT. Hätte es gereicht, hätte ich nie mit dem 
Manuskript angefangen!

Gruß
  Jürgen

[Salewski, Stefan (Gast)]

jdhenning schrieb:
> dann ist der Schwafelanteil in meinem Buch sehr weit
> unter dem allgemeinen Durchschnitt

Ja. ich muss auch zugeben, dass ich den Buchtext nur ganz kurz 
überflogen habe.

Das mit dem Schwafeln ist eben ein generelles Problem: Fast jeder hat 
wohl seine Dpiplomarbeit ganz von vorne begonnen, nachdem sie halb 
fertig war. Bei einigen waren dazu vielleicht einige Anmerkungen vom 
Kollegen erforderlich. Anfangs möchte man die Seiten füllen und zeigen 
was man alles weiß, und wenn man dann auch noch in seiner Muttersprache 
schreibt...
Ein gutes Buch wird man wohl immer mehrmals ganz von vorne schreiben 
müssen.

Zum Thema Sachbücher: Art of Elektronics von Horowitz/Hill wäre mein 
Maßstab. (An der neuen Ausgabe knappern die ja auch schon seit vielen 
Jahren.) Oder in Deutsch vielleicht die alten SuSE-Linux von Michael 
Kofler? Aber so etwas, an dem man Jahre arbeitet, kann man heute kaum 
noch produzieren, sofern man auf etwas Verdienst angewiesen ist. 
Sachbücher zu aktuellen Themen könnte man wohl in akzeptabler Zeit und 
Qualität herunterschreiben und wird dann noch einige Käufer finden 
können. Da hat dann auch keiner so hohe Erwartungen. Aber soweit ich 
weiss hat sich das in den letzten Jahren für kaum einen auch nur 
halbwegs finanziell rentiert. Also wenn da ein Stundenlohn von unter 
einem Euro bei herauskommt, dann würde ich persönlich lieber frei bei 
Wikibooks oder so schreiben. Wohl nicht mehr unbedingt mit LaTeX, eher 
diese Sachen wie Markdown oder wie sie heißen mögen, so dass man es gut 
auf Readern lesen kann. Und ATmega -- war der nicht eher vor gut 10 
Jahren aktuell? Tja, ist schwierig all das. Und im Übrigen -- Elektronik 
und uC als Hobby heutzutage? Also ich würde eh eher abraten. Gut, besser 
als Saufen und Video gucken immerhin.

[Kim S. (Gast)]

also ob Ironie oder nicht sollte dem Autor  überlassen bleiben, wenn er 
seine persönliche Note rein bringen will, warum nicht, Leute die das 
stört sind sowieso nicht die Käufer solcher Anfängerbücher!

Und NEIN, ich würde keinen kompletten C Kurs einbauen!!
In dem Buch geht es um den Controller und seiner programmierung es soll 
kein C Kurs sein.
Ich finde die c Ansätze die bisslang drin sind aber sehr gut!! und über 
daran keinerlei kritik

[Salewski, Stefan (Gast)]

Ich habe gerade noch mal nachgesehen:

http://www.buch-schreiben.de/buch-veroeffentlichen/autorenhonorar.php

In der Tat bekommt der Autor wohl nur um die 10% vom Endpreis. Selbst 
wenn man viel Glück hat und ein paar hundert Exemplare verkauft ist das 
nicht viel.

[Frank K. (fchk)]

jdhenning schrieb:
> Wolfgang Schmidt schrieb:
>> Wer entscheiden soll, welchen Mikrocontroller er verwenden will, kennt
>> in der Regel die Begriffe Bit, Byte, UND, u.s.w. Falls nicht, greift man
>> dazu auf Literatur zurück, die es ohne Ende und auch in Lehrbüchern
>> gibt.
> Honig auf meine Seele! Endlich einer, der mich versteht!

Schreibe doch ein Kapitel "An wen richtet sich dieses Buch". Da steht 
dann, was Du vom Leser erwartest:
* PC-Kenntnisse
* C-Kenntnisse
* vielleicht erste Programmierkenntnisse???
* grundlegendes Elektrik-Wissen (was ist ein Widerstand, was ein 
Kondensator, Stromkreis, Spannung, Strom)
? grundlegende Kenntnisse der binären und hexadezimalen Zahlensysteme
? grundlegende Kenntnisse der logischen Operatoren und oder nicht

und was Du ihm beibringen willst
* Mikroprozessor-/Mikrocontrollertechnik am Beispiel von ...
* ...
* ...

Das macht es nicht nur für andere einfacher, auch Du selber 
dokumentierst Deine Designentscheidungen.

fchk

[jdhenning (Gast)]

Salewski, Stefan schrieb:
> Also ich würde eh eher abraten. Gut, besser
> als Saufen und Video gucken immerhin.

Das hatte ich mir auch gedacht.

[jdhenning (Gast)]

Kim Schmidt schrieb:
> Und NEIN, ich würde keinen kompletten C Kurs einbauen!!
> In dem Buch geht es um den Controller und seiner programmierung es soll
> kein C Kurs sein.
> Ich finde die c Ansätze die bisslang drin sind aber sehr gut!! und übe
> daran keinerlei kritik

Gracias! Es gibt saugute Bücher über C und eine endlose Anzahl von 
Tutorials im Internet. Mit denen konkurrieren zu wollen wäre ziemlich 
sinnfrei. Daher auch die Beschränkung auf das, was man bei MCUs in Bezug 
auf C wissen sollte.

Gruß
  Jürgen

[jdhenning (Gast)]

Salewski, Stefan schrieb:
> In der Tat bekommt der Autor wohl nur um die 10% vom Endpreis. Selbst
> wenn man viel Glück hat und ein paar hundert Exemplare verkauft ist das
> nicht viel.

Wenn man 10% bekommt ist das schon sehr gut (bekommen normalerweise nur 
schon bekannte Sachbuchautoren!).

Da ich Überzeugungstäter bin, stört mich das aber nicht so sehr!

[jdhenning (Gast)]

Frank K. schrieb:
> Das macht es nicht nur für andere einfacher, auch Du selber
> dokumentierst Deine Designentscheidungen.

Steht im einführenden Teil, wird aber definitiv Teil vom Klappentext 
(bzw. Rückseite des Buches, denn gerade Fachbücher sind ja oft in 
Plastik eingeschweißt).

[Rolf H. (flash01)]

Hallo Leute,
ich schaffe es nicht dieses Buch zu öffnen!
Bin doch garnicht so bl..d.
Setze oben www.jdhenning.de/AVR ein und es öffnet sich eine Seite
mit den Vermerk "Ups! Dieser Link scheint nicht zu funtionieren"
Rechts daneben eine Suchlupe.
Drück ich darauf, öffnet sich Google mit "basteln-mit-avr"
Aber das ist doch nicht das Buch...oder?
Hab den Internet-Explorer neueste Version!
Grüße

Rolf

[Dennis X. (Gast)]

Rolf H. schrieb:
> Internet-Explorer

Funktioniert einwandfrei mit zwei anderen Browsern. Hatte es gestern 
Abend mal probiert.

[Marco B. (pintman)]

Rolf H. schrieb:

> Setze oben www.jdhenning.de/AVR ein und es öffnet sich eine Seite
> mit den Vermerk "Ups! Dieser Link scheint nicht zu funtionieren"

Hilft es, ein http:// davor zu setzen? http://www.jdhenning.de/AVR


Gruß,
Marco.

[Rolf H. (flash01)]

danke für Deine Antwort!
Jetzt versuche ich es mal mit einen anderen Rechner,
da ist noch ne alte Browser-Version drauf.
Nun rödelt es schon 5 Minuten "Verbindung wird hergestellt" nichts!
Den Usernamen "AvrBuch" und Passwort "Atmega8" habe ich ordnungsgemäß
eingegeben.
Die Idee von Marco werde ich anschliessend machen.

Grüße

Rolf

Die alte Browser-Version rödelt immer noch!

[Helmut S. (helmuts)]

Du musst das Atmega8 so schreiben: ATmega8

[Rolf H. (flash01)]

Hallo Helmut,
das lässt mir einfach keine Ruhe....ziemlich hartnäckisch!
Bin wieder zurück zum Notebook mit aktuellen Browser.
Wie von Marco mit https://www.jdhenning.de/AVR eingegeben und was
kommt: "Die Seite ist nicht auffindbar"
Alles sehr merkwürdig...oder?
Sollte ich das AVR klein schreiben?
werde mal den Browser-Verlauf löschen.

[Helmut S. (helmuts)]

Nimm Firefox auf einem normalen WINDOWS PC.
Genau so wie unten sollst du es machen. Hast du etwa einen Super 
Browserschutz aktiviert der dir kein PDFs erlaubt?

www.jdhenning.de/AVR
User: AvrBuch
Passwort: ATmega8

Es ist Zeit zu prüfen, ob ich meinen eigenen und auch euren
Anforderungen gerecht werden kann. Das Rohmanuskript steht (bis zum 14.
Januar) unter "www.jdhenning.de/AVR" zum freien Download bereit (auf der
Homepage ist kein Link auf '/AVR'). Der Username ist "AvrBuch" und das
Passwort "ATmega8" (Schreibweise beachten!). Von der dann erscheinenden
Seite kann man das Rohmanuskript als '.pdf' Datei herunter laden.

[Helmut S. (helmuts)]

Nimm Firefox auf einem normalen WINDOWS PC.
Genau so wie unten sollst du es machen. Hast du etwa einen Super- 
Browserschutz aktiviert der dir kein PDFs erlaubt?

www.jdhenning.de/AVR
User: AvrBuch
Passwort: ATmega8

Es ist Zeit zu prüfen, ob ich meinen eigenen und auch euren
Anforderungen gerecht werden kann. Das Rohmanuskript steht (bis zum 14.
Januar) unter "www.jdhenning.de/AVR" zum freien Download bereit (auf der
Homepage ist kein Link auf '/AVR'). Der Username ist "AvrBuch" und das
Passwort "ATmega8" (Schreibweise beachten!). Von der dann erscheinenden
Seite kann man das Rohmanuskript als '.pdf' Datei herunter laden.

[Rolf H. (flash01)]

hurra...auf dem Smartphon Galaxy S3 mit seinen Android
sind gerade 1,6 MB am Downladen.
Danke nochmals.
Alle Versuche "Browser löschen usw." führten zu nichts.

Grüße

Rolf

[Dennis X. (Gast)]

Rolf H. schrieb:
> Wie von Marco mit https://www.jdhenning.de/AVR eingegeben und was
> kommt: "Die Seite ist nicht auffindbar"

Das ruft auch mit HTTPS auf, das geht bei mir ebenfalls nicht. Einfach 
HTTP nehmen ;)

[Atmega8 A. (atmega8)]

Um sich dort einloggen zu können muss man Scripte (in NoScript) und 
Cookies (in der "Cookie Whiteslist") erlauben.
Ihr nutzt vielleicht einen anderen Cookie blocker.

[D. J. (basteldag)]

Hallo,

Win7 64bit, IE9, einfach mit http (NICHT https) eingeben es klappt

[Rolf H. (flash01)]

Nun möchte ich mich zum Schluß nochmal melden!
Es hat nach meiner großen Aktion mit dem Notebook funktioniert.
Was habe ich gemacht?

1. mit TuneUp 1-Klick-Wartung die Festplatte bearbeitet.
Es wurden ca. 30 defekte Verknüpfungen und vieles Andere repariert.

2. In Programme/Zubehör/Datenträgerbereinigung den Browser gereinigt.

3. Den Rechner runter bzw. hochgefahren.

4. Internet-Explorer geöffnet und nochmals unter Extras/ Browser
bereinigen aktiviert.
So, und jetzt neu www.jdhenning.de/AVR eingegeben.
Jetzt kam es endlich zur Eingabe von Usernamen und Kennwort
(dabei auf ATmega8 geachtet).
Es ließ mir doch keine Ruhe!

Nochmals mein Danke für alle Tips.

Grüße

Rolf

[Andreas H. (ahz)]

Oliver S. schrieb:
> Das Buch ist so, wie es da steht, fühlbar von Generation Ü50 für
> Generation ü50. Was vielleicht nicht verkehrt ist, denn alle anderen
> kaufen keine Bücher zu solchen Themen.

<LOL>
War klar, dass wieder so ein Kommentar kommt. Aber mal kurz zum 
"Zurückärgern:

Die Jungs, die den Prozessor gebaut haben sind ü50.
Die Leute, die den Compiler designed haben (also gcc allgemein) sind 
ü50.
Die Gründer von ARM sind (afaik) ü50.

u50 nehmen lieber Arduino oder noch besser RPi (falls man mal ZWEI Leds 
blinken lassen soll).
</LOL>

/regards
Andreas

P.S:

Rolf H. schrieb:
> Hallo Leute,
> ich schaffe es nicht dieses Buch zu öffnen!
??? u50 ???

(sry Rolf. Can't resist ;-)

[jdhenning (Gast)]

Hallo Helmut,
leider kam ich erst heute dazu, mich mit dem Link zu befassen und auch 
mal kurz ins Datenblatt des 328 zu schauen.

Helmut S. schrieb:
> Das wird aber ziemlich viel Arbeit und jemand muss dann auch die
> Beispiele mit dem ATMEGA328 testen.
>
> http://www.atmel.com/images/doc2553.pdf

Resümee: Eine Umarbeitung des Manuskripts ist eher unwahrscheinlich, 
denn dann würden sich da (zwangsweise) jede Menge Fehler einschleichen. 
Also bleibt nur, das Buch um einen Abschnitt zu erweitern. So ganz grob 
betrachtet sind ja nur der Multiplizierer und der debugWIRE komplett neu 
und es wurde jede Menge umgestellt (und neu/anders benannt).

Ich werde mich jetzt mal durch das 'Datenbuch' ackern und nach einem Weg 
suchen, wie die zusätzliche Information mit einem Minimum an Aufwand 
integriert werden kann. debugWIRE wäre schon nicht uninteressant.

Danke noch mal für den Link
  Jürgen

[jdhenning (Gast)]

Moin Gerhard.

Gerhard O. schrieb:
> Mit der Logik der Fuses hat Atmel wirklich ein Baseliskenei gelegt
> oder einen großen Bock geschossen.

Es gibt so etliche Abschnitte im Datenblatt, wo ich dachte, dass man das 
auch deutlich nachvollziehbarer hätte lösen können. Bei den Fuses war 
ich (auch nach mehrmaligen Lesen) auch fassunglos: Es ist schlicht eine 
Unverschämtheit vom Hersteller, wenn er vom Nutzer invertierte Logik 
verlangt.

Ich habe den warnenden Text überarbeitet und erweitert. Danke
  Jürgen

[spess53 (Gast)]

HI

>Bei den Fuses war
>ich (auch nach mehrmaligen Lesen) auch fassunglos: Es ist schlicht eine
>Unverschämtheit vom Hersteller, wenn er vom Nutzer invertierte Logik
>erlangt.

Jeder gelöschte Flash-Speicher ist mit H-Bits gefüllt und wird mit 
L-Bits beschrieben. Also eher logisch.

MfG Spess

[F. F. (foldi)]

jdhenning schrieb:
> Bei den Fuses war
> ich (auch nach mehrmaligen Lesen) auch fassunglos:

Ich habe die Fuses auch erst verstanden, nachdem ich das von einem 
netten Menschen erklärt bekommen habe.

http://www.schniko.at/index.php/de/avr-meets-me/121-erklaerung-avr-fuse-bits-sut-cksel-taktauswahl-deutsch

[jdhenning (Gast)]

Moin Spess.

spess53 schrieb:
> Jeder gelöschte Flash-Speicher ist mit H-Bits gefüllt und wird mit
> L-Bits beschrieben. Also eher logisch.

Das erste Paradigma, das mir bei der professionellen Softwareentwicklung 
über den Weg lief war: "Have pitty with the user!"

Deine Antwort ist fachlich sicherlich richtig, ist aber die eines 
Technikers, dem der Endkunde ziemlich egal ist. Was kosten 16 Inverter 
und ein wenig Ansteuerungslogik auf so einem Chip? Liege ich mit 
ungefähr 0,002 Cent pro Chip in der richtigen Größenordnung?

Wenn ich diese Ersparnis der Zeit gegenüberstelle, die Hobby- und auch 
andere User mit der Fehlersuche wegen versehentlich falsch gesetzten 
Fuses und Lockbits aufgebracht haben, dann muss ich feststellen, dass 
Atmel kein Mitleid mit seinen Kunden hat. Wenn die Kunden zu doof sind, 
das Datenblatt zu verstehen, dann können sie ja auch teure Kurse buchen, 
um ihrem Verständnis auf die Sprünge zu helfen. Wenn ihnen das zu teuer 
ist, dann haben sie halt Pech gehabt.

Kundenorientierung und Service sehen für mich anders aus (was mir mit 
dem Buchprojekt hoffentlich eine Marktlücke eröffnet).

Gruß
  Jürgen

[Conny P. (conny_phi)]

Hallo Jürgen,
Kompliment für das Werk! Da steckt eine Menge Arbeit drin.
Da ich ein Sammler von Anfängerbüchern und Tutorials bin, war ich sehr 
neugierig auf Dein Buch.

Beim Querlesen ist mir direkt Folgendes aufgefallen:

Mir ist bewusst, dass Du einen lockeren Schreibstil gewählt hast. Das 
ist Dir auch gelungen. Aber für meinen Geschmack schreibst Du zu viel 
über Dich (… da ich ein Sturkopf bin…) und über Deine Meinung. Das ganze 
ist dann häufig auch noch zu sehr wertend (…die Unsitte in technische 
Texten, bei der Beschreibung links oben anzufangen…, Ich halte es für 
eine unglückliche Lösung, die Pull-Up-Widerstande…). Das kommt dann 
nicht mehr locker rüber sondern eher schon etwas überheblich.


Ich habe viele Deiner Ausführungen gelesen. Manches habe ich bisher in 
keinem anderen Buch gefunden und fand sie wirklich sehr interessant. 
Aber wenn ich mir vorstelle, ich wäre ein Anfänger und würde Dein Buch 
als Leitfaden lesen. Ich glaube, ich wäre hoffnungslos verloren.

Beispiele:

Steht irgendwo im Buch was ein I/O-Register überhaupt ist? Oder sollte 
das ein Leser des Buches bereits wissen. Es fehlt eine einfache, aber 
für das Verständnis eines Mikrocontrollers absolut wichtige Erklärung 
wie hier im Tutorial: "Weiterhin haben alle Mikrocontroller sogenannte 
Special Function Register (SFR, spezielle Funktionsregister). Das sind 
spezielle Register, welche sämtliche Funktionen und Module des 
Mikrocontrollers steuern…" Der Leser Deines Buches wird erstmals im 
Kapitel über den Speicher  mit dem Begriff „IO-Bereich" konfrontiert und 
sogleich auf  später vertröstet. Später kommt lediglich eine Liste (um 
die Verwirrung komplett zu machen, heißt es dann nicht mehr IO-Bereich 
sondern Register).

Ähnlich ergeht es einem mit den general purpose Registern. Deren 
Speicherort im SRAM wird im Kapitel 1.4.2. ohne Erklärung der Register 
genannt, dann werden sie einige Seiten später als MCU-Register nochmal 
kurz erwähnt. Schließlich werden sie dann in einigen Assemblerbeispielen 
verwendet. Eine Erklärung, was es mit diesen Registern auf sich hat, 
habe ich vergeblich gesucht.

Angenommen ein Anfänger liest das Kapitel über den Stack. Ich fürchte, 
er wird auch danach nicht wissen, was ein Stack ist. Und das Schlimme 
daran, er wird auch nicht verstanden haben, dass er es überhaupt nicht 
wissen muss, wenn er in C programmiert. Da hilft auch nicht, dass das 
nebenbei erwähnt wird. Die Mischung aus Erklärungen über das 
Assembler-Programmieren und C ist nicht nur an dieser Stelle absolut 
verwirrend.

Ein Anfänger wird schwer verunsichert weiterlesen und landet schon bald 
beim Kapitel, "Das Betriebssystem des kleinen Mannes".  Er hat bisher 
gerade mal eine LED zum Leuchten (ohne Blinken) gebracht, er kennt noch 
keine Grundlagen, wie z.B. den Unterschied zwischen PINA und PORTA und 
bekommt ohne Vorwarnung eine Final State Machine erklärt und das ganze 
eben mal so über ein  Array mit Pointern auf Funktionen in einem 
Beispielprogramm vorgesetzt. Den Anfänger, den ich vor Augen habe, wirst 
Du mit diesem Kapitel nicht annähernd erreichen.

Und endlich auf Seite 54 wird erklärt, was es mit den PORT, PIN und 
DDR-Registern auf sich hat. In jedem Buch oder Tutorial steht das ganz 
am Anfang, wo es meiner Meinung nach auch hingehört, aber gut. Auch hier 
bietet sich dem Anfänger ganz schwere Kost. Welcher Anfänger solle z.B. 
das verstehen:
------------------------------------------------------------------------
Wenn man also an einem Port gemischt Ein- und Ausgänge hat und das 
Aktivieren oder Deaktivieren von Pull-Up-Widerständen funktional in der 
realisierten Schaltung einen Unterschied macht, dann muss man vor jeder 
Ausgabe auf das Daten-Register das Byte so bereinigen, dass man nicht 
die Pull-Up-Widerstände ungewollt ein- oder ausschaltet (man muss sich 
also irgendwo die Pull-Up-Aktivierung merken und das Ausgabebyte mit 
dieser Info verodern).
-----------------------------------------------------------------------




Insgesamt kann ich mir nicht vorstellen, dass die Zusammenstellung in 
Deinem Buch genau das ist, was ein Anfänger sucht. Mir kommt es vor, Du 
hast einfach das aufgeschrieben, was Du als Erkenntnisgewinn hattest. 
Das wird vorallem an dem Kapitel über Projektmanagement deutlich. Diese 
Information ist für einen Anfänger absolut entbehrlich und der Hinweis 
mit dem Hausfrauenzettel eher peinlich.

[spess53 (Gast)]

HI

>Deine Antwort ist fachlich sicherlich richtig, ist aber die eines
>Technikers, dem der Endkunde ziemlich egal ist.

Da sind die mehr als 10000 Kunden, die Geräte mit meiner Software 
gekauft
irgendwie anderer Meinung.

>Wenn ich diese Ersparnis der Zeit gegenüberstelle, die Hobby- und auch
>andere User mit der Fehlersuche wegen versehentlich falsch gesetzten
>Fuses und Lockbits aufgebracht haben, dann muss ich feststellen, dass
>Atmel kein Mitleid mit seinen Kunden hat.

Hobbyisten sind weder die Zielgruppe von ATMEL oder irgend einem anderen 
Halbleiterhersteller. Die sind eher ein 'Abfallprodukt'. Mit dem was die 
kaufen kann man wahrscheinlich gerade mal die Pförtner bezahlen aber 
keine Produktion oder Entwicklung.

Deine 'Endkunden' sind die, die milliardenfach Geräte mit diesen 
Bauelemente kaufen ohne sich im mindesten dafür interessieren was da 
drin ist oder gar wie unbekannte Fuses gesetzt werden. Und die 
Entwickler dieser Geräte sollten wissen was sie machen. Sonst sind sie 
ihr Geld nicht Wert.

MfG Spess

[Frank K. (fchk)]

jdhenning schrieb:

> Wenn ich diese Ersparnis der Zeit gegenüberstelle, die Hobby- und auch
> andere User mit der Fehlersuche wegen versehentlich falsch gesetzten
> Fuses und Lockbits aufgebracht haben, dann muss ich feststellen, dass
> Atmel kein Mitleid mit seinen Kunden hat. Wenn die Kunden zu doof sind,
> das Datenblatt zu verstehen, dann können sie ja auch teure Kurse buchen,
> um ihrem Verständnis auf die Sprünge zu helfen. Wenn ihnen das zu teuer
> ist, dann haben sie halt Pech gehabt.

Das Problem ist ein anderes. Warum muss man sich mit falsch gesetzten 
Fuses (blöde Bezeichnung) unbedingt aussperren? Microchip hat es doch 
auch hinbekommen. Bei den PICs kann man sich normalerweise(*) nicht 
aussperren, egal wie dumm man sich anstellt. Man kommt immer an den Chip 
heran. Wenn sie bei Atmel unbedingt einen Takt für ihre State Machine 
brauchen, hätten sie einfach den nehmen sollen, den der Programmer via 
SCK liefert. Oder immer den internen RC-Oszillator. Wie gesagt, bei 
Microchip und dem ICSP dort klappt es doch auch. Und ab PIC24 auch ganz 
ohne High Voltage(†) auf !MCLR, selbst wenn !MCLR zum Portpin gemacht 
wurde.

Fail.

fchk

(*) mit Gewalt mag es gehen, zB bei einem PIC16, der normalerweise per 
LVP programmiert wird, LVP abschalten und gleichzeitig auf !MCLR eine 
Beschaltung haben, die die HVP-Programmierspannung nicht abkann. Aber 
das ist Vorsatz und damit strafbar.

(†) min 3.5V über Vcc

[spess53 (Gast)]

Hi

>Hobbyisten von heute sind die Entwicklungsingenieure von morgen. ;-b

Hast du belastbare Zahlen? Wer nicht in der Lage sich die simpelsten 
Grundlagen selbst bei zu bringen wird kaum ein Studium überstehen.

>Das Problem ist ein anderes. Warum muss man sich mit falsch gesetzten
>Fuses (blöde Bezeichnung) unbedingt aussperren? Microchip hat es doch
>auch hinbekommen.

Das Problem wir eher dramatisiert.

MfG Spess

[oldmax (Gast)]

Hi
Nun, ich hab mir nicht die Mühe gemacht, alle Beiträge zu lesen, aber 
mir ist aufgefallen, das die Experten etwas abdriften. Was soll eine 
Diskussion über Profis und Hobbyisten? Spess, sicherlich hast du mit der 
Bemerkung
>Wer nicht in der Lage sich die simpelsten
>Grundlagen selbst bei zu bringen wird kaum ein Studium überstehen.

irgendwo recht, aber es gibt auch die Abteilung Schüler, die vom 
Wissensstand der Lehrkräfte abhängig sind und sich nunmal für das Thema 
interessieren. Wenn dann eine Projektarbeit angeboten wird, ist das doch 
nicht verwerflich. Wen interessieren zu diesem Zeitpunkt die Zahlen, 
wieviele Teilnehmer dann später nach einem Studium Entwickler werden.
Wenn dann ein Buch erhältlich ist, in welchem Lehrkräfte und Schüler 
gleichermaßen eine Basis finden, ist das doch gut. Das soll jetzt nicht 
bedeuten, das unbedingt dieses buch dafür geeignet ist, aber es ist 
immerhin einn Anfang, das Thema in Muttersprache rüber zu bringen. Dabei 
ist es völlig irrelevant, ob ein Controller veraltet oder die Sprache 
tot ist. So manchem Automechaniker täte es nicht schaden, die 
historischen Modelle der Verbrenner  von Otto oder Daimler zu kennen. 
Auch wenn die Motoren von Heute kaum noch etwas mit den klobigen 
Einzylindern zu tun haben funktionieren sie immer noch nach diesem alten 
Prinzip.
Wer sich mit der Materie µC beschäftigt, wird sich früher oder später 
auch mit anderen Controllern befassen und da ist dann der Zeitpunkt, wo 
er selbst die Datenblätter liest und sein Vorhaben umsetzt. Die ewig 
nervige Diskussion, C oder Assembler oder vieleicht doch BASCOM, was 
soll das? Wer Programme schreiben kann, tut das sowieso in seiner 
favorisierten Spraache und manchmal auch abseits, wenn das Problem mit 
den gegebenen Werkzeug einfach nicht zufriedenstellend gelöst werden 
kann. Aber einem Anfänger weiszumachen, das es nur "eine" Sprache gibt, 
ist Blödsinn. Vielleicht sollte der ein oder ander mal in mein 
bescheidenes Werk "keine Angst vor Assembler" bei AVR-Praxis 
überfliegen. Er wirds dann vielleicht verstehen.
Nun zum Autor. Das Buch braucht noch ein wenig Leben, um einen Anfänger 
zu fesseln. Und wenn es dir Erfolg bringen soll, dann warte ein halbes 
Jahr. In dieser Zeit nicht hineinlesen. Und dann lies es nochmal. Wenn 
es dich dann immer noch fesselt, dann ist es vermutlich gut. Was ich 
damit sagen will, du brauchst Abstand, um dein Werk mit einem anderen 
Blickwinkel zu sehen. Was auch möglich wäre, ein paar interessierte 
Jugendliche zu finden, die dir dann das Werk "auseinander" nehmen. Wenn 
die damit arbeiten können ( Azubis oder Schüler) und das Interesse nicht 
verlieren, hast du dein Ziel erreicht.
Gruß oldmax

[g. b. (gunb)]

Guten Morgen,

sicher ein weiteres Buch für Einsteiger, wo viele Themen bereits in 
anderen Einsteigerbüchern schon aufgegriffen wurden.

Nun gut, soll ja nich verboten sein, ein weiteres Buch zu schreiben, 
gibt sicher immer den ein oder anderen Punkt, wo ein bestimmtes Buch mit 
ein paar Details punktet, die in anderen fehlen oder zu kurz kommen.

Was mich aber stört ist, wenn Begriffe wie "Interrupts" in "Interrupte" 
eingedeutscht werden. Da sollte man das englische Original "Interrupts" 
erhalten.

Weiterhin steht bei "Betriebssystem des kleinen Mannes":

>Das liegt unter anderem daran, dass Betriebssysteme viel Speicherplatz
>brauchen und man auf eine MCU meistens sowieso viel zu wenig Speicher hat.

Das kann man heute sicher nicht mehr so stehen lassen, denn die 
32-Bitter sind eben auch Mikrocontroller und eher für den Betrieb mit OS 
entwickelt worden, besonders wenn sie eine MMU besitzen. Hier sollte man 
genauer differenzieren und i.d.Z. die 8-Bit Controller nennen.

>Wenn man (was auf einer MCU normal ist) kein Betriebssystem hat

Das ist falsch. "Normal" ist das heute nicht mehr, siehe Tablet, 
Smartphone, Handy, viele Messgeräte wie Scopes usw.
Kommt eben eher auf die verwendete MCU an, im Hobbybereich würde ich das
so sehen, aber diese Pauschalaussage ist nicht ganz korrekt.


Ansonsten zum Buch: warum nicht?! Immer gut, wenn Leute ehrenamtlich 
tätig werden und anderen helfen ;-)


Gruß
gunb

[Konrad S. (maybee)]

oldmax schrieb:
> Dabei
> ist es völlig irrelevant, ob ein Controller veraltet oder die Sprache
> tot ist.

Jürgen D. Henning schrieb in seinem ¨Buch¨ auf Seite 55/56:
> Anmerkung: Ich halte es für eine unglückliche Lösung, die
> Pull-Up-Widerstände über das Port-Register zu aktivieren
> oder zu deaktivieren; eine technisch saubere Lösung wäre
> gewesen, dass man beim Port-Register die aktuellen Pinzustände
> abfragen kann (egal ob Eingang, Ausgang oder ob dem Pin
> eine völlig andere Funktion zugeordnet wurde) und es ein
> Pull-Up-Register gäbe, mit dem man die Widerstände aktivieren,
> deaktivieren oder ihren Status auslesen könnte. Aber mich
> hat man ja mal wieder nicht gefragt!

Neuere AVR-Designs von Atmel verfügen pro Port über ein Register, mit 
dem sich die Pull-Ups steuern lassen. Es spielt also durchaus eine 
Rolle, dass ein alter/veralteter Controller beschrieben wird.

Das sehe ich aber eher als das kleinere Problem an. Übler ist, dass der 
Autor dadurch gegenüber dem AVR-beleseneren Leser seine Unwissenheit 
demonstriert, was jedoch dem AVR-unerfahrenen Leser (somit der 
Zielgruppe) verborgen bleibt. Mit diesem ¨Buch¨ will wohl einer sein 
Halbwissen als der Weisheit letzten Schluss in die Welt hinausschreien. 
Na meinetwegen! Mein Fazit: Dieses ¨Buch¨ ist wie ein Kropf: will und 
braucht man nicht, aber man stirbt auch nicht daran.

[Luftfeuchte (Gast)]

Es heißt Interrupt(s) nicht Interrupte!

[meckerziege (Gast)]

Hab mal nen Blick drauf geworfen.
Die Wahl des ATmega8 scheint für Einsteiger durchaus sinnvoll zu sein. 
Dir entgeht aber leider ein großer Teil der Funktionen der größeren 
Controller. Hierbei sei mal z.B. das externe Speicherinterface genannt.

Folgendes ist mir auch noch aufgefallen:
-------
T (biT storage?)
Über die Assemblerbefehle BST (Bit STore) kann ein einzelnes Bit an 
dieser Position
zwischengespeichert werden. Über den Befehl BLD (BitLoaD) kann es wieder 
ausgelesen
werden. Wozu man das brauchen könnte, weiß wahrscheinlich keiner.
-------
Ich heiße zwar nicht "keiner", weiß aber für was du das brauchst. Damit 
kannst du auf Bitebene Manipulationen vornehmen. Es gibt nicht nur BST 
und BLD, sondern auch BRTS, BRTC, SET und CLT.
Wenn du Beispielsweise das Bit 3 auf Bit 5 in einem Register kopieren 
willst, dann ist genau das der Anwendungszweck. Das geht mit zwei 
Befehlen BLD und BST. Du brauchst keine bedingten Sprünge und andere 
komplexere Sachen.

Auch die anderen Erklärungen der Flags sind nicht ganz korrekt. Du musst 
genauer erklären, dass es Instruktionen gibt, welche die Flags ändern. 
Bei V schreibst du nur von Inkrementieren, bei N von vergleichen. Ein 
Blick ins Instruction Set verrät aber, dass es bei deutlich mehr 
Operationen der Fall ist.
Bei V unterschlägst du, dass der Overflow auf Bit 7 und nicht auf dem 
Carry/Bit8 stattgefunden hat! TWO'S COMPLEMENT Arithmetik beachten!!
Hier kannst du das alles noch schöner nachlesen:
http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf

Es gibt einige lange Kapitel bei dir. Diese würde ich stärker 
unterteilen. Wenn ein (Unter)kapitel über mehrere Seiten geht ist das 
deutlich zuviel.


"Die Nutzung des Stacks ist eine übliche Methode, um etwa zwei 
Registerinhalte schnell zu tauschen." Das seh ich eigentlich nie. Dafür 
nimmst du eher das temporäre Register her. Vor allem, weil jedes PUSH 
und POP zwei Taktzyklen braucht, das MOV ins temporäre Register nur 
einen Taktzyklus.


"Ein Byte wird in C entweder als 'char' deklariert oder besser als 
'unsigned char'."
Nein. Ein Char ist ein Zeichen. Ein Byte ist ein (u)int8_t.

"Es funktioniert
beides, aber bei unsigned char ist eindeutig klar, dass da kein 
Vorzeichen (also + oder -) vorhanden
ist (wenn das höchste Bit eine '1' ist, dann würde das Byte als negative 
Zahl interpretiert werden)."
Weiter unten schreibst du aber:
"Die Bits, die hinaus geschoben werden sind verloren und es wird, 
unabhängig von der Schieberichtung, immer mit Nullen aufgefüllt."
Das stimmt so NICHT! Du machst einen arithmetischen Shift, wenn du einen 
signed Typen shiftest. Es wird mit dem MSB aufgefüllt und nicht 
unbedingt mit 0. Siehe Befehl "ASR".

Funktionspointer würde ich nicht als
func[0] = function_1;
sondern als
func[0] = &function_1;
schreiben. Grund: Es wird klar, dass du wirklich einen Pointer auf die 
Funktion willst und nicht etwa vergessen hast das () für den Aufruf 
hinzuzufügen.
Die Lösung mit den Funktionspointern im Array finde ich ehrlich gesagt 
sehr schön! So etwas sehe ich sonst viel zu selten. :-)

"Interrupte" gibt es im Deutschen nicht. Bleib doch bei "Interrupts".

"Vom
aktuell laufenden Programm aus gesehen hat es die Unterbrechung 
überhaupt nicht gegeben (man
könnte nur über Zeitmessungen nachweisen, dass da irgend etwas 
Merkwürdiges passiert und
Rechenzeit klaut)."
Stimmt so nicht ganz. Das unterschlägt einige Risiken:
- Zugriff auf 16-bit Register können unterbrochen werden, dies wird zu 
großen Problemen führen. (internes temporäres Register!)
- Race conditions

"Inklude"
bitte nicht...

Allgemein zum Stil: Du schreibst sehr oft etwas in Klammern (um es 
danach noch genauer zu erklären). Diese Klammern stören den Lesefluss. 
Mach lieber normale Sätze draus.

Die Abschnitte zum Projektmanagement finde ich sehr schön, da gibts nen 
interessanten Überblick!

Beim Textsatz gibt wohl auch noch kleinere Probleme. Teils rutscht das 
letzte Wort des vorherigen Absatzes auf die nächste Seite. (siehe 
143/144)

Insgesamt wäre das ein oder andere Bild oder auch Grafik nicht falsch. 
Das würde den Text stark auflockern. Das ist an manchen Stellen SEHR 
nötig.


Viel Erfolg! :-)

[jdhenning (Gast)]

Hi Conny,

Conny Phi schrieb:
> Insgesamt kann ich mir nicht vorstellen, dass die Zusammenstellung in
> Deinem Buch genau das ist, was ein Anfänger sucht. Mir kommt es vor, Du
> hast einfach das aufgeschrieben, was Du als Erkenntnisgewinn hattest.
Ich hatte noch nicht erwähnt, welches die Zielgruppe ist: Leute, die 
wegen einem technischen Vorhaben beschlossen haben, sich ernsthaft mit 
MCUs zu beschäftigen. Wenn du die Lernerfahrung aus über 40 Jahren als 
Erkenntnisgewinn bezeichnest, dann hast du recht.

> Das wird vorallem an dem Kapitel über Projektmanagement deutlich. Diese
> Information ist für einen Anfänger absolut entbehrlich und der Hinweis
> mit dem Hausfrauenzettel eher peinlich.
Wegen der anvisierten Zielgruppe ist genau dies nicht entbehrlich. 
Einige frühere Kollegen und ich fanden den 'Hausfrauenzettel' derartig 
praktisch, dass wir da jahrelang mit gearbeitet haben. Ein praktisches 
Planungswerkzeug als peinlich zu bezeichnen kommt mir fast so vor, als 
würde man Debugger als peinlich bezeichnen, denn wer richtig 
programmieren kann, der braucht so etwas nicht.

[jdhenning (Gast)]

spess53 schrieb:
> Und die Entwickler dieser Geräte sollten wissen was sie machen.
> Sonst sind sie ihr Geld nicht Wert.
Das finde ich etwas schwach als Begründung für unsauberes Design und 
schlecht geschriebene Datenblätter und Handbücher. Und das Hobbyisten 
nur eine marginale Randgruppe für Halbleiterhersteller darstellen 
brauchen wir wohl nicht diskutieren.

[g. b. (gunb)]

jdhenning schrieb:
> Einige frühere Kollegen und ich fanden den 'Hausfrauenzettel' derartig
> praktisch, dass wir da jahrelang mit gearbeitet haben.

Naja, sicher für den Anfänger tolerabel, besser wäre gleich mit 
einfachen Pflichten-/Lastenheften zu beginnen.

[g. b. (gunb)]

spess53 schrieb:
> Hi
>
>>Hobbyisten von heute sind die Entwicklungsingenieure von morgen. ;-b
>
> Hast du belastbare Zahlen? Wer nicht in der Lage sich die simpelsten
> Grundlagen selbst bei zu bringen wird kaum ein Studium überstehen.

Sowas kann man auch mal als lockeren Spruch sehen, ohne da wieder das 
Erbsenzählen anfangen zu müssen.

[Ulli-B (Gast)]

Hallo jdhenning,

bist Du sicher dass es eine gute Idee war das Buch hier vor zu stellen?
Hier bekommst Du von 20 Leute 25 Meinungen.
Jeder hat andere Erfahrungen/Probleme.
Bei mir zB. waren die Fuses noch nie ein Problem. Andere scheitern da 
bald jedes Mal dran. Ich habe dafür andere Probleme.

Es gibt ja auch schon einige Bücher zu dem selben Thema.
Wenn hier im Forum nach Bücherempfehlungen gefragt wird, so geht es auch 
meist drunter und drüber, von :"Buch ist super" bis "Buch ist absoluter 
Mist".

Meiner Meinung nach wäre es das Beste, Du suchst Dir eine 
Schule/Berufsschule/Ausbildungsbetrieb oder so etwas. Dort bietest Du 
einem Lehrer/Ausbilder Dein Manuskript sowie etwas Hardware an.
Dann sollen Schüler damit arbeiten und gleichzeitig auf einen 
"Hausfrauenzettel" aufschreiben wo es Probleme gab und was schwer zu 
verstehen war/ist.

Gibt es denn keinen besseren Namen für den Hausfrauenzettel?
Z.B.: Notitzblock oder so?

Noch kurz zu Deinem Buch:
ATmega8 finde ich ganz schlecht.
Nimm etwas aktuelleres mit mehr Möglichkeiten (Schnittstellen, Speicher, 
usw..)

mfG
Ulli-B

[jdhenning (Gast)]

Moin oldmax

oldmax schrieb:
> Was ich
> damit sagen will, du brauchst Abstand, um dein Werk mit einem anderen
> Blickwinkel zu sehen. Was auch möglich wäre, ein paar interessierte
> Jugendliche zu finden, die dir dann das Werk "auseinander" nehmen. Wenn
> die damit arbeiten können ( Azubis oder Schüler) und das Interesse nicht
> verlieren, hast du dein Ziel erreicht.

Ich habe vor, an der FH einen Zettel auszuhängen, dass ich Testleser 
suche. Und wenn das durch ist wollte ich mal bei einem Gymnasium 
anklopfen. Danke für die Tipps.
  Jürgen

[jdhenning (Gast)]

Moin gnub

g. b. schrieb:
> Was mich aber stört ist, wenn Begriffe wie "Interrupts" in "Interrupte"
> eingedeutscht werden. Da sollte man das englische Original "Interrupts"
> erhalten.
Ist schon im gesamten Text geändert, aber noch nicht hochgeladen.

>>Das liegt unter anderem daran, dass Betriebssysteme viel Speicherplatz
>>brauchen und man auf einer MCU meistens sowieso viel zu wenig Speicher hat.
>
> Das kann man heute sicher nicht mehr so stehen lassen, denn die
> 32-Bitter sind eben auch Mikrocontroller und eher für den Betrieb mit OS
> entwickelt worden, besonders wenn sie eine MMU besitzen. Hier sollte man
> genauer differenzieren und i.d.Z. die 8-Bit Controller nennen.
Erledigt & Danke
  Jürgen

[Klaro (Gast)]

jdhenning schrieb:
> Das finde ich etwas schwach als Begründung für unsauberes Design und
> schlecht geschriebene Datenblätter und Handbücher.

Wird wohl daran liegen, dass auch da nur Menschen hinter stehen,
die nicht perfekt sind. Wenn man so was anstrebt, sollte man auf
vorhandenes Wissen aufbauen und Korrekturen/Ergänzungen vornehmen.
Sicher hat es kein Autor leicht, aber man muss es sich auch nicht
schwer machen und auf erfolgreiche Konzepte verzichten wollen.

meckerziege schrieb:
> http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf

Dieses Datenblatt fand ich recht informativ, vor allem durch die
Grafiken, obwohl hier kleine Befehle in Assembler oder/und C die
Beschreibung vervollkommnen würden, wenn man wissen will, was
bei welchem Befehl passiert. Platz scheint mir reichlich vorhanden.
Wenn das Script Mängel hat und du die kennst, wäre es doch
sinnvoll, die Inhalte 1:1 mit Grafiken in dein Buch zu übernehmen
und Fehler oder Mängel zu korrigieren. Schon allein eine
Übersetzung ins Deutsche wäre ein Gewinn.
Das dann dein Buch schnell 1000 Seiten dick würde, sehe ich nicht
als Nachteil an.
Es wäre ohnehin sinnvoll wenn es ein Atmega-Kompendium werden würde
und nicht nur ein Kochbuch.

In letzter Zeit hast du ziemlich oft versucht dich zu rechtfertigen.
Meinungsunterschiede wird es immer geben, aber wenn so ein Projekt
erfolgreich sein soll, dann wird/sollte die Lesermeinung ein höheres 
Gewicht haben, als die Autorenmeinung.

[jdhenning (Gast)]

Konrad S. schrieb:
> Mit diesem ¨Buch¨ will wohl einer sein
> Halbwissen als der Weisheit letzten Schluss in die Welt hinausschreien.

Wenn du auf das Titelblatt geblickt hättest, dann hättest du gesehen, 
dass das Buch sich nur auf den ATmega8 bezieht. Und nein, mein Vorhaben 
war und ist ein Buch zu schreiben, das einem eine Einführung in die Welt 
der MCUs gibt, denn ich hatte weder im Internet noch im Buchladen 
irgendetwas gefunden, was da wirklich tauglich ist. Hättest du die 
Einleitung gelesen, dann hättest du auch das wissen können.

Jürgen

[Rene H. (Gast)]

Zur Ich-Form:

http://www.faz.net/aktuell/feuilleton/autorschaft-das-ich-als-unverschaemtheit-11684188.html

C ist, was sein Altern in Jahren angeht, schon ein wenig angestaubt und an den Universitäten lernt
man, wenn überhaupt noch C, natürlich C++, denn die angehenden Informatiker und Techniker
sollen ja lernen strukturiert zu denken.

Das stimmt meiner Meinung nur begrenzt. C ist eine strukturierte 
Sprache, C++ ist Objektorientiert. Die angehenden Informatiker können 
bereits strukturiert denken, wenn nicht, sind sie im falschen Studium. 
Sie sollten eher objektorientiertes Denken lernen.

Grüsse,
René

[jdhenning (Gast)]

Schon mal vielen Dank für den langen Post.

meckerziege schrieb:
> Hab mal nen Blick drauf geworfen.
> Die Wahl des ATmega8 scheint für Einsteiger durchaus sinnvoll zu sein.
> Dir entgeht aber leider ein großer Teil der Funktionen der größeren
> Controller. Hierbei sei mal z.B. das externe Speicherinterface genannt.
Ich habe mich (auf vielfachen Wunsch) schon an die Arbeit gemacht und 
werde einen Abschnitt des Buches dem ATmega328 widmen.

> T (biT storage?)
> Ich heiße zwar nicht "keiner", weiß aber für was du das brauchst. Damit
> kannst du auf Bitebene Manipulationen vornehmen.
> Wenn du Beispielsweise das Bit 3 auf Bit 5 in einem Register kopieren
> willst, dann ist genau das der Anwendungszweck.
Ich habe meinen Kommentar über dieses Flag in "In Assembler kann man 
damit schnelle Bitmagie betreiben." geändert.

> Auch die anderen Erklärungen der Flags sind nicht ganz korrekt. Du musst
> genauer erklären, dass es Instruktionen gibt, welche die Flags ändern.
> http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf
Ich habe den Link in die Linksammlung eingepflegt und im Text über die 
Flags auf diesen Link hingewiesen.

> "Die Nutzung des Stacks ist eine übliche Methode, um etwa zwei
> Registerinhalte schnell zu tauschen." Das seh ich eigentlich nie. Dafür
> nimmst du eher das temporäre Register her. Vor allem, weil jedes PUSH
> und POP zwei Taktzyklen braucht, das MOV ins temporäre Register nur
> einen Taktzyklus.
Das war ein Rückfall von mir in längst vergangene Zeiten.

> "Die Bits, die hinaus geschoben werden sind verloren und es wird,
> unabhängig von der Schieberichtung, immer mit Nullen aufgefüllt."
> Das stimmt so NICHT!
Da hast du recht, bei negativen Zahlen wird beim nach rechts schieben 
links mit Einsen ergänzt.

> Funktionspointer würde ich nicht als "func[0] = function_1;"
> sondern als "func[0] = &function_1;" schreiben.
Gute Idee, habe ich übernommen.

> "Interrupte" gibt es im Deutschen nicht. Bleib doch bei "Interrupts".
War schon erledigt, nur nicht hochgeladen.

> - Zugriff auf 16-bit Register können unterbrochen werden, dies wird zu
> großen Problemen führen. (internes temporäres Register!)
> - Race conditions
Wird an anderer Stelle abgehandelt.

> "Inklude" bitte nicht...
Erledigt.

> Beim Textsatz gibt wohl auch noch kleinere Probleme. Teils rutscht das
> letzte Wort des vorherigen Absatzes auf die nächste Seite. (siehe
> 143/144)
Es ist noch Rohmanuskript und noch gar nicht fürs Buch formatiert. Das 
kommt, wenn alle Bilder und ZEichnungen da sind.

> Insgesamt wäre das ein oder andere Bild oder auch Grafik nicht falsch.
> Das würde den Text stark auflockern. Das ist an manchen Stellen SEHR
> nötig.
Ist und war mir bewusst und wird auch kommen.


Danke für die vielen und auch zureffenden Kommentare.

  Jürgen

[Klaro (Gast)]

jdhenning schrieb:
> Ich habe den Link in die Linksammlung eingepflegt

Und was macht der Leser, wenn der Link irgend wann nicht
mehr funktioniert, weil Atmel Dateien umbenennt oder
seinen Server neu ordnet? Findet man sehr häufig schon
im Wikipedia und da hätten es die Autoren vergleichsweise
Gelegenheit und leicht die Daten zu pflegen.

[jdhenning (Gast)]

Hallo Ulli.

Ulli-B schrieb:
> Noch kurz zu Deinem Buch: ATmega8 finde ich ganz schlecht.
> Nimm etwas aktuelleres mit mehr Möglichkeiten (Schnittstellen, Speicher,
> usw..)

Aus didaktischen Gründen hätte ich normalerweise eine noch kleinere MCU 
ausgewählt, um den Komplexitätsgrad so gering zu halten, dass ein 
Neueinsteiger nicht gleich in VErzweifelung ausbricht. Da die Meinung 
"zu alt", "kann zu wenig" schon recht oft kam, arbeite ich jetzt an 
einem neuen Abschnitt und da wird der ATmega328 besprochen (aber 650 
Seiten Datenblatt ist schon heftig).

Jürgen

[Conny G. (conny_g)]

jdhenning schrieb:
> Hallo Ulli.
>
> Ulli-B schrieb:
>> Noch kurz zu Deinem Buch: ATmega8 finde ich ganz schlecht.
>> Nimm etwas aktuelleres mit mehr Möglichkeiten (Schnittstellen, Speicher,
>> usw..)
>
> Aus didaktischen Gründen hätte ich normalerweise eine noch kleinere MCU
> ausgewählt, um den Komplexitätsgrad so gering zu halten, dass ein
> Neueinsteiger nicht gleich in VErzweifelung ausbricht. Da die Meinung
> "zu alt", "kann zu wenig" schon recht oft kam, arbeite ich jetzt an
> einem neuen Abschnitt und da wird der ATmega328 besprochen (aber 650
> Seiten Datenblatt ist schon heftig).
>
> Jürgen

Spring über Deinen Schatten und nimm den 328 als Grundlage fürs Buch. 
Sonst machst Du mit einem Heidenaufwand eine Gurkenlösung.
Das ist ja als würdest Du eine Anleitung für KFZ-Reparatur mithilfe 
eines Trabi schreiben. So sehen aber heute keine Autos mehr aus.

[Konrad S. (maybee)]

jdhenning schrieb:
> Konrad S. schrieb:
>> Mit diesem ¨Buch¨ will wohl einer sein
>> Halbwissen als der Weisheit letzten Schluss in die Welt hinausschreien.
>
> Wenn du auf das Titelblatt geblickt hättest, dann hättest du gesehen,
> dass das Buch sich nur auf den ATmega8 bezieht. Und nein, mein Vorhaben
> war und ist ein Buch zu schreiben, das einem eine Einführung in die Welt
> der MCUs gibt, denn ich hatte weder im Internet noch im Buchladen
> irgendetwas gefunden, was da wirklich tauglich ist. Hättest du die
> Einleitung gelesen, dann hättest du auch das wissen können.
>
> Jürgen

Nur keine Sorge, ich hatte auch das Titelblatt und die Einleitung 
gelesen. Wenn du dich daran störst, dass dein Einbaum keinen 
Außenbordmotor hat, warum nimmst du dann kein Motorboot? Es schein daran 
zu liegen, dass du davon noch nichts gehört hast. Sorry, aber das ist 
der Eindruck, den das bisher geschriebene bei mir hinterlassen hat.

[jdhenning (Gast)]

Klaro schrieb:
> Meinungsunterschiede wird es immer geben, aber wenn so ein Projekt
> erfolgreich sein soll, dann wird/sollte die Lesermeinung ein höheres
> Gewicht haben, als die Autorenmeinung.

Als ich das gerade gelesen habe musste ich an diesen Gag denken. Chef: 
"Ich bin sehr für Meinungsaustausch! Sie kommen mit ihrer Meinung bei 
mir rein und gehen mit meiner Meinung wieder raus!" Natürlich ist mir 
die Meinung der potentiellen Leser wichtig, allerdings gab es hier im 
Forum fast bei allem gegensätzliche Meinungen gab. Der einzige 
weitgehende Konsens war, dass man eine neuere und größere MCU nehmen 
sollte und dem komme ich ja schon nach, indem ich einen zusätzlichen 
Abschnitt für den ATmega328 angefangen habe.

Allerdings noch wichtiger als die Meinung des Autors oder des Lesers ist 
die Meinung des 'Senior Editors' vom Verlag. Wenn der meint, dass es 
nicht genügend Leser geben wird, ist der Rest ziemlich egal.

Jürgen

[Klaro (Gast)]

jdhenning schrieb:
> Der einzige
> weitgehende Konsens war, dass man eine neuere und größere MCU nehmen
> sollte und dem komme ich ja schon nach, indem ich einen zusätzlichen
> Abschnitt für den ATmega328 angefangen habe.

Dann scheinst du nicht alles zu lesen, denn der Wunsch nach
mehr Bebilderung ist ja auch häufiger gefallen. Allerdings
ist der Thread ja auch schon ziemlich angeschwollen.

[Conny G. (conny_g)]

jdhenning schrieb:
> Forum fast bei allem gegensätzliche Meinungen gab. Der einzige
> weitgehende Konsens war, dass man eine neuere und größere MCU nehmen
> sollte und dem komme ich ja schon nach, indem ich einen zusätzlichen
> Abschnitt für den ATmega328 angefangen habe.

Das finde ich nicht gut in 2014 ein Autoreparaturbuch für den Trabi von 
1980 zu schreiben und das Problem mit einem Kapitel für modernere Autos 
zu kompensieren. Das ist im Ansatz Murks.
Das kann man in einer zweiten Auflage machen, wenn man schnell mal das 
Buch aktualisieren will, aber keine Zeit hat. Aber bei der Erstausgabe 
gleich mit ollen Kamellen anfangen?

[Konrad S. (maybee)]

Ich hatte hier Beitrag "Re: Extra uC für Bedienteil" mal 
was zu ATmega8-Tutorials geschrieben. Jetzt willst du nochmal neu ein 
altes Tutorial schreiben!?!

[jdhenning (Gast)]

Hallo Konrad.

Konrad S. schrieb:
> Ich hatte hier Beitrag "Re: Extra uC für Bedienteil" mal
> was zu ATmega8-Tutorials geschrieben.
Netter Fred. Um in dem dort verwendeten Bild zu bleiben: Ich schreibe ja 
nicht über die Logikbausteinreihe 7400 und Geschwister, mit denen ich 
vor 40 Jahren gespielt habe. Und die gibt es auch immer noch 
(pinkompatibel aber leicht andere Innereien).

> Jetzt willst du nochmal neu ein altes Tutorial schreiben!?!
Wenn man es unbedingt so ausdrücken will. Atmel brauchte nur 11 Seiten, 
um die Änderungen vom 8'er zu 88'er zu beschreiben. Dann kann man davon 
ausgehen, dass man praktisch alles aus dem ATmega8 auch dort findet 
(Pin-kompatibel, aber nicht Software-kompatibel, weil einige Register 
neue Namen und Adressen bekommen haben).

Also wird die Liste der Dinge, die anders (aber nicht komplett neu) 
sind, recht kurz sein. Und die Dinge, die wirklich neu sind, müsste ich 
sowieso beschreiben. Ab das so geht, weiss ich erst, wenn ich mit dem 
Datenblatt durch bin und werde dann entscheiden.

Jürgen

[Mein grosses V. (vorbild)]

jdhenning schrieb:
> Atmel brauchte nur 11 Seiten,
> um die Änderungen vom 8'er zu 88'er zu beschreiben.

Nein. Darin stehen die Änderungen, die man beachten muss, wenn man vom 
8er auf den 88er wechselt.

jdhenning schrieb:
> Also wird die Liste der Dinge, die anders (aber nicht komplett neu)
> sind, recht kurz sein

Ja ne, is klar.

Schon Scheisse, wenn man ein Buch schreibt und weder den Controller, 
über den man schreibt, noch die Controllerfamilie, zu der er gehört, 
auch nur ansatzweise kennt.

Markiere den gesamten Text deines Buches und drück <Strg> + x

Nicht zu fassen!

[jdhenning (Gast)]

Mein grosses Vorbild schrieb:
> Schon Scheisse, wenn man ein Buch schreibt und weder den Controller,
> über den man schreibt, noch die Controllerfamilie, zu der er gehört,
> auch nur ansatzweise kennt.
>
> Markiere den gesamten Text deines Buches und drück <Strg> + x
>
> Nicht zu fassen!

Wenn du so superschlau bist, warum hast du dann nicht schon vor langer 
Zeit ein Buch geschrieben, das -im Gegensatz zum Datenblatt- von jedem 
Normalo verstanden werden kann? Zu faul? Keine Zeit? Kein Mitgefühl? 
Mangelnde didaktische Fähigkeiten? Maulen ist einfach, besser machen ist 
Arbeit!

Deshalb werde ich einen Teufel tun und meinen Text löschen, denn er ist 
eindeutig besser, als alles, was ich auf dem Markt (also Tutorials im 
Internet und Bücher im Buchladen) gefunden habe. Falls du das auch 
besser weißt, dann lass doch mal 'nen Link oder 'ne ISBN rüber wachsen 
und zwar für eine Komplettbeschreibung einer MCU.

[X. (Gast)]

jdhenning schrieb:
> Mein grosses Vorbild schrieb:
>> Schon Scheisse, wenn man ein Buch schreibt und weder den Controller,
>> über den man schreibt, noch die Controllerfamilie, zu der er gehört,
>> auch nur ansatzweise kennt.
>>
>> Markiere den gesamten Text deines Buches und drück <Strg> + x
>>
>> Nicht zu fassen!
>
> Wenn du so superschlau bist, warum hast du dann nicht schon vor langer
> Zeit ein Buch geschrieben, das -im Gegensatz zum Datenblatt- von jedem
> Normalo verstanden werden kann?

Das hat er deshalb nicht getan weil es einfach nicht notwendig ist.

> Deshalb werde ich einen Teufel tun und meinen Text löschen, denn er ist
> eindeutig besser, als alles, was ich auf dem Markt (also Tutorials im
> Internet und Bücher im Buchladen) gefunden habe.

Unter Selbstüberschätzung leidest du aber nicht gerade...

[Rolf H. (flash01)]

man kann das bald nicht mehr lesen, was die Vorbilder und Co
so von sich geben..jdhenninger halte durch!

[Mein grosses V. (vorbild)]

jdhenning schrieb:
> Maulen ist einfach, besser machen ist Arbeit!

Um den Mist, den du zu Papier bringen willst, als solchen zu erkennen, 
muss ich selbst kein Buch schreiben.

jdhenning schrieb:
> Deshalb werde ich einen Teufel tun und meinen Text löschen, denn er ist
> eindeutig besser, als alles, was ich auf dem Markt (also Tutorials im
> Internet und Bücher im Buchladen) gefunden habe. Falls du das auch
> besser weißt, dann lass doch mal 'nen Link oder 'ne ISBN rüber wachsen
> und zwar für eine Komplettbeschreibung einer MCU.

Da du, wie ich schon schrieb, weder den Atmega8 noch die gesamte 
AVR-Controllerfamilie kennst, kannst du das überhaupt nicht beurteilen. 
Aber das entgeht dir in deiner grenzenlosen Arroganz natürlich völlig.

[Rolf H. (flash01)]

ich werde mich aus diesen Thread abmelden..nicht mehr schön zu lesen.

[Mein grosses V. (vorbild)]

Rolf H. schrieb:
> ich werde mich aus diesen Thread abmelden..nicht mehr schön zu
> lesen.

Kannst es nicht ertragen, wenn hier einer nicht grenzenloses Lob hudelt, 
sondern klar sagt, was dieses sinnlose Buch ist?

[Berater (Gast)]

@jdhenning
Der Thread wird zunehmend von gefrusteten Trollen okkupiert, darum:
Streite nicht mit einem Idioten. Er zieht Dich auf sein Niveau und 
schlägt
Dich dort mit seiner Erfahrung.

Gehe Deinen Weg und laß die Kläffer im Straßengraben zurück.

[jdhenning (Gast)]

X. schrieb:
> Unter Selbstüberschätzung leidest du aber nicht gerade...

Stimmt, denn Selbstüberschätzung liegt vor, wenn man seine Fähigkeiten 
höher einschätzt, als sie sind. Ich weiß recht genau, was ich kann und 
was ich nicht kann (so habe ich etwa weder die allgemeine noch die 
spezielle Relativitättheorie von Albert Einstein wirklich vollständig 
begriffen). Ich habe auch nicht mehr das Bedürfniss, mich vor anderen zu 
beweisen (das ist Teeny-Stuff). Können wir zum Thema zurück?

[Andreas H. (ahz)]

Mein grosses Vorbild schrieb:
> Kannst es nicht ertragen, wenn hier einer nicht grenzenloses Lob hudelt,
> sondern klar sagt, was dieses sinnlose Buch ist?

Abgesehen davon, dass es kein sinnloses Buch sein muss, ist das einzig 
nervende an dem Thread die unsinnige Zankerei.

Die AtMega sind nicht schlecht und für Anfänger relativ schnell zu 
überblicken. Ob man nun Diesen oder jenen Vertreter dieser Familie 
benutzt ist doch am Anfang völlig nebensächlich. Der TO hat sich für 
Einen entschieden. Fertig.

Es gibt doch genug andere Stellen im Buch wo noch nachgearbeitet werden 
muss. Und DAS sollte man hier im Thread diskutieren. Es werden ja wohl 
schon genug andere Threads "totqeflamed" :/

/regards
Andreas

[jdhenning (Gast)]

@Rolf H.
Das ist der Vorteil, wenn man schon weiße Haare hat: Da hat man schon 
viel Schlimmeres erlebt und hält problemlos durch. In meinem Leben haben 
schon manche versucht, mich fertig zu machen, aber bisher hat es noch 
keiner geschafft und so schnell wird sich das auch nicht ändern.

@Rolf H.
Nee, falls dich das Thema noch interessiert, bitte nicht. Das würde ja 
bedeuten, vor Proleten den Schwanz einzukneifen. Sollte man nicht tun! 
Als ich gestern noch mal durch den Thread ging (um festzustellen, ob ich 
alle Hinweise auch schon registriert habe), stellte ich fest, dass schon 
zwei Posts (die ich noch nicht einmal besonders schlimm fand) von den 
Mods gelöscht wurden. Ich vermute, das könnten bald mehr werden, wenn da 
einige ihren Ton nicht ändern. Also kein Grund sich belästigt zu fühlen.

@Berater
Danke für den Tipp, ist aber unnötig. Ersten ficht es mich nicht 
wirklich an und zweitens werde ich mich nicht auf so ein Niveau herunter 
denken (können). Es gibt da ein schönes Sprichwort aus dem 
Dänischen:"Big dogs don't need to bark!" Das haben einige noch nicht 
begriffen. Grins!

Danke und Tschüs für heute
  Jürgen

[Andreas H. (ahz)]

jdhenning schrieb:
> Das würde ja
> bedeuten, vor Proleten den Schwanz einzukneifen. Sollte man nicht tun!

/signed

Jürgen mach weiter :-)

/regards
Andreas

[jdhenning (Gast)]

Hallo Andreas.

Andreas H. schrieb:
> Es gibt doch genug andere Stellen im Buch wo noch nachgearbeitet werden
> muss. Und DAS sollte man hier im Thread diskutieren.
Genau das war meine Bitte und es wurden schon einige Detailfehler 
gefunden und berichtet. Dazu sage ich schon mal vielen Dank an alle 
beteiligten!

> Es werden ja wohl schon genug andere Threads "totqeflamed" :/
Solange nicht 100 Schrott-Posts pro Tag dafür sorgen, dass man den Rest 
nicht mehr findet, besteht hierzu nicht der Hauch einer Chance. Und wenn 
das passiert, wird wohl der eine oder andere User ein Ctrl+X von einem 
Mod bekommen. Keep cool, mach ich auch!

Jürgen

[Salewski, Stefan (Gast)]

jdhenning schrieb:
> Danke und Tschüs für heute
>   Jürgen

Hallo Jürgen,

ich hoffe mal du ärgerst Dich nicht allzu sehr über einige der obigen 
Kommentare -- einiges was ich so beim durchscrollen gesehen habe war 
schon etwas dreist.

Für ein kostenloses Tutorial oder ähnliches wäre eine so unverschämte 
Kritik natürlich völlig unakzeptabel. Aber für ein kommerzielles Produkt 
wie Dein Buch -- auch wenn es nur wenige Euro kosten mag -- ist Kritik 
womöglich doch angebracht. Ich kann es zwar nicht wirklich beurteilen, 
da ich wie gesagt deinem Text nur ganz kurz überflogen hatte. Aber man 
sollte natürlich auch ein wenig an die Käufer denken: Wer mag so ein 
Büchlein kaufen? Kinder, womöglich einige Rentner? Und werden die mit 
dem Büchlein glücklich sein, wenn sie denn entdecken, dass nicht alles 
topaktuell ist oder dass man vieles auch im Internet findet? Und wenn 
sie nicht glücklich sind, dann ist das womöglich ein Grund für sie, nie 
wieder ein Buch zu kaufen. Natürchlich denken soweit nur wenige, die 
Meisten werden gerne irgendwelchen Schund veramschen, sofern man damit 
ein paar Mark machen kann, auch wenn es dann letzendlich nur Euro sind. 
Aber Du hast ja sicher einen höheren Anspruch, sonst hättest Du diesen 
Thread nicht gestartest.

Und wenn Du denn an Deinem Vorhaben festhalten magst: Dann würde ich 
zumindest Ergänzungen frei im Internet zugänglich machen, wenn es dann 
sein muss auch noch mit Zugangscode für die Buchkäufer.

[Elliot W. (hexagon5un)]

Hallo Jürgen,

zum Thema AVR Buch schreiben habe ich ein bisschen Erfahrung.  (Mit 
Deutscher Rechtschreibung komme ich nicht so ganz klar...)

A1 würde ich vorschlagen, wie viele andere Leute schon gesagt haben, der 
alte Mega8 nicht zu nutzen, sondern was modernes.  Ein M88 oder M168 
würde viel besser sein, denn die Macronamen sind mit die ganze Reihe 
moderner Micros zusammendpassend.  Der Mega8 ist fast ausgestorben.

Zweitens, es lohnt sich eine Zielgruppe fest im Kopf zu haben wann man 
schreibt.  Was bringt die das Buch?  "Ein Buch für Anfanger" ist nicht 
präzis genug. (Und die Nische hier ist übrigens sehr schmal. Reine 
Anfänger heute lernen Arduino.  Profis lernen ARM/Cortex.)

Da gibt's zu viel darüber man schreiben kann -- man musst aber sehr 
fokusiert sein. Ein guter Redakteur kann auch viel helfen. (Der bekommt 
man bei O'Reilly nur per Zufall.)

Und zum Thema O'Reilly:

Jürgen Henning schrieb:
> Aktuell bin ich im Gespräch mit dem Verlag O'Reilly, der nicht
> uninterresiert ist, das Buch herauszugeben (wenn denn eine entsprechende
> Nachfrage zu erwarten ist; die haben nämlich noch nicht einmal auf
> englisch ein brauchbares Buch zu dem Thema).

Also, O'Reilly selbst hat keins.  Das Tochterunternehmen Maker Press, 
aber...

jdhenning schrieb:
> Allerdings hatte ich mir von O'Reilly "AVR-Programming von Eliot
> Williams" angetan (ich war nicht so begeistert; mehr will ich dazu nicht
> sagen)

Warum nicht?  Ich bin genau der Elliot Williams und ich freue mich sehr 
über Kommentar, weil nämlich wir die bereinigte 2. Edition laufend 
dranarbeiten und es könnte immer verbessert werden.

("Make: AVR Programming" hat sich allerdings in Deutschland sehr gut 
verkauft.  Kommischerweise, habe ich viel mehr verdient in Deutschland 
als in England, obwohl das Buch in Englisch geschrieben ist.  Veilleicht 
liegt es an den höhen Nerdanteil (gut gemeint) hier.)

Ich habe das Buch für Leute die schon Arduino kennen, aber 
hardware-näher zu programmieren lernen wollen geschrieben.  Meine 
Zielgruppe kennt noch nicht so gut C, aber andere Bücher lesen kann. 
Die sind nicht Einsteiger, aber auch kein Profis.  Da habe ich viele 
Kompromisse gemacht -- das schreiben war "leicht", das Editieren war 
schwer.  Zwei Bücher mehr liegen ausgeschnitten auf dem boden...

Was genau hat Ihnen nicht gut gefallen?

      Elliot.

PS. Ein Buch zu schrieben ist ein Liebesdienst.  Kopf hoch!

[Konrad S. (maybee)]

Andreas H. schrieb:
> Ob man nun Diesen oder jenen Vertreter dieser Familie
> benutzt ist doch am Anfang völlig nebensächlich. Der TO hat sich für
> Einen entschieden. Fertig.

Es ist eben gerade nicht nebensächlich. Der Anfänger wird - nur um 
nichts falsch zu machen - genau den besprochenen μC kaufen, den ihm sein 
Einstiegsbuch nahelegt. Und genau damit macht er den ersten - für ihn 
nicht erkennbaren, daher unvermeidlichen - Fehler: Investition
in veraltete Technik. Nein, nicht das bisschen Geld für den μC ist 
verschwendet, sondern die viele Zeit fürs Lernen an veralteter Technik. 
Das führt dann dazu, dass später der Nicht-mehr-ganz-Anfänger ums 
Verrecken nicht mehr von dem alten Scheiß lassen will. Wie auch am TO zu 
sehen ist, denn er wurde schon im September-Thread darauf hingewiesen. 
dass der ATmega8 veraltet ist. Da aber die existierenden Tutorials nun 
mal auf dem ATmega8 aufbauen ... ein Teufelskreis. Genau deswegen halte 
ich ein Einsteigerbuch auf ATmega8-Basis für überflüssig, ein halbwegs 
ordentliches Einsteigerbuch auf Basis des ATmega328 wäre dagegen ein 
Segen.

[F. F. (foldi)]

Ich muss mich noch einmal zu Wort melden.
Es gibt schon ein sehr gutes Buch und eben für moderne AVR.
Das AVR Kochbuch.

[oldmax (Gast)]

Hi
Nochmal ein kleines Statement von meiner Seite an alle, die sinnlose 
Posts gegen das Buch schreiben. Es ist doch jedem selbst überlassen, was 
er tut und wenn er ein Buch schreibt, ist der erfolg (Gott sei dank) 
nicht von so dämlichen Antworten abhängig, sondern von der Thematik. Ob 
guter oder schlechter Schreibstil, da kann diskutiert werden, um dem 
Autor zu helfen, sein Werk lesbar zu machen. Wenn so Oberschlaue dieses 
Buch nicht benötigen, dann brauchen sie es ja nicht zu lesen und schon 
gar nicht zu kaufen. Ich selbst hab vor langer Zeit mal Hinweise auf 
Interruptbearbeitung in 286 CPU's gesucht und fast 400 DM ausgegeben, 
bevor ich einen wertvollen und brauchbaren Hinweis fand.Keines der 
Bücher war schlecht, aber oftmals lagen Schwerpunkte halt in anderen 
Bereichen. Ach ja, um zum Thema "fehlerfrei" zu kommen, es ist keine 
Kunst, Fehler anzumeckern, aber eine, keine Fehler zu machen. Sich da an 
banalen Rechtschreibfehlern hochzuziehen, sollten doch inhaltliche 
Fehler aufgezeigt werden. Die Rechtschreibfehler werden Lektoren schon 
herausplümen und wenn da auch  mal einer stehen bleibt, so what?
@ jdhenning
Ich hab dein Buch nur locker überflogen, also bilde ich mir mal nur vom 
kurzen Einblick eine Meinung. So ist bei mir auch der Eindruck 
entstanden, das trotz versuchter Lockerungsübung der Stoff zu sachlich 
und daher auch trocken rüberkommt. Aber ich kann mich irren und werde 
mir auch mal die Mühe zu machen, etwas intensiver durchzugehen. Nur nach 
meiner Erfahrung und in der Regel  ist es halt so, das ein Interessent 
vor dem Kauf nicht die Gelegenheit hat. Sicher hier eine Ausnahme duch 
die Vorstellung auf dieser Plattform, aber der erste Eindruck 
entscheidet - kaufen oder nicht - und da solltest du dein 
inhaltsverzeichnis mal mit ein wenig ansprechenden Begriffen füllen, was 
die Begehrlichkeit erhöht. Ich weiß nicht, ob hier die Chance von PN 
besteht, aber auch mein Pseudonym ist ein kleines Markenzeichen, welches 
du Bspw. in AVR-Praxis findest. Und dort weiß ich, das eine PN machbar 
ist.  Wenn du also vielleicht die ein oder andere Hilfe brauchst...
Gruß oldmax

[Paul B. (paul_baumann)]

Konrad S. schrieb:
> dass der ATmega8 veraltet ist. Da aber die existierenden Tutorials nun
> mal auf dem ATmega8 aufbauen ... ein Teufelskreis. Genau deswegen halte
> ich ein Einsteigerbuch auf ATmega8-Basis für überflüssig, ein halbwegs
> ordentliches Einsteigerbuch auf Basis des ATmega328 wäre dagegen ein
> Segen.

...und schon nächsten Monat ist der Atmega328 veraltet, weil es einen
neuen Typ gibt. Das o.g. genannte Argument ist für mich nicht 
stichhaltig.

Wem mit einem GUTEN Buch am Anfang geholfen wurde, der kann dann mit dem
erworbenen Wissen sich dann selbst weiterhelfen, wenn eine neue 
Fertigungs-
linie von Kontroller herauskommt. Es ist schließlich technisch nicht 
ALLES
völlig neu, die Grundprinzipien sind immer da.

MfG Paul

[Oliver S. (oliverso)]

oldmax schrieb:
> Ich selbst hab vor langer Zeit mal Hinweise auf
> Interruptbearbeitung in 286 CPU's gesucht und fast 400 DM ausgegeben,
> bevor ich einen wertvollen und brauchbaren Hinweis fand.

Und genau das ist der Punkt. Damals (tm) gabs sowas nur auf gedrucktem 
Papier. Heute, einen Jahrtausenwechsel später, hat sich die Welt radikal 
verändert. Brockhaus ist pleite, und Computerbücher sind genauso out.

Oliver

[Martin V. (oldmax)]

Hi
@oliver
Mal ne Frage an dich: "Wie wertvoll findest du deinen Beitrag?" Ach ja, 
ich vergaß, vermutlich bist du noch einer derjenigen, die sich der 
Arbeit anderer fleißig bedienen, ohne auch nur im geringsten 
nachzudenken, das auch in kostenlosen Informationen eine menge 
Arbeitsleistung stecken kann. Dein beitrag würdigt dies in keinster 
Weise. Im Gegenteil, du setzt  auf die Internetseiten und dort 
befindlichen kostenlosen Informationen. Warum soll sich noch jemand 
Gedanken machen, Wissen in irgendeiner Form weiterzugeben. Wenn es 
jemand tut, wird er auch noch runtergemacht. An dieser Stelle mal ein 
kleiner Hinweis: Setz mal die graue Masse in deinem Kopf etwas klüger 
ein und überlege, welche Information eben nicht so einfach im Netz 
erhältlich ist und dann schreib entweder selbst ein Buch oder hilf 
einem, der es versucht.
Gruß oldmax

[jdhenning (Gast)]

Hallo Stefan

Salewski, Stefan schrieb:
> Aber für ein kommerzielles Produkt wie Dein Buch -- auch wenn es nur
> wenige Euro kosten mag -- ist Kritik womöglich doch angebracht.

> Wer mag so ein Büchlein kaufen?
Als Zielgruppe sind diejenigen angedacht, die sich ernsthaft mit MCUs 
beschäftigen wollen. Schüler, die ein Projekt machen, gehören da weniger 
dazu. Leute, die ambitionierte Bastelideen haben, schon eher 
(Modelleisenbahner und ähnliches). Riesig wird der Markt nicht sein.

> Aber Du hast ja sicher einen höheren Anspruch, sonst hättest Du diesen
> Thread nicht gestartest.
Yepp und die erhoffte frische Brise kam ja auch.

> Und wenn Du denn an Deinem Vorhaben festhalten magst: Dann würde ich
> zumindest Ergänzungen frei im Internet zugänglich machen, wenn es dann
> sein muss auch noch mit Zugangscode für die Buchkäufer.
Gute Idee!
 Danke
  Jürgen

[Andreas H. (ahz)]

Martin Vogel schrieb:
> Ach ja,
> ich vergaß, vermutlich bist du noch einer derjenigen, die sich der
> Arbeit anderer fleißig bedienen, ohne auch nur im geringsten
> nachzudenken, das auch in kostenlosen Informationen eine menge
> Arbeitsleistung stecken kann.

Martin

You made my day :-)

Die aktuelle "alles umsonst & sofort" Mentalität treibt in der 
Zwischenzeit schon merkwürdige Blüten :/

Grüße
Andreas

[jdhenning (Gast)]

Hallo Elliot,

vielen Dank für die vielen Anmerkungen, die mir sicherlich auch weiter 
helfen werden.

Elliot Williams schrieb:
> jdhenning schrieb:
>> Allerdings hatte ich mir von O'Reilly "AVR-Programming von Eliot
>> Williams" angetan (ich war nicht so begeistert; mehr will ich dazu nicht
>> sagen)
Denn muss ich ja wohl. Es liegt an der Zielgruppe (12- bis 16-jährige, 
die basteln und ihre Kumpels beeindrucken wollen), aber für die hast du 
den richtigen Stil gehabt. Wahrscheinlich ist das sogar die größte 
Zielgruppe, die man in diesem Markt haben kann und zwangsweise wurde 
also in dem Buch alles ausgelassen, was etwas schwieriger ist. No insult 
meant; ich glaube nicht, dass sich irgendjemand hier im Forum dein Buch 
ins eigene Bücherregal stellen würde.

Zudem ist mir auch klar, dass man mit einem Fachbuch, das vom Niveau her 
etwa zwei Stufen unter Uni-Lehrbuch sein soll, nicht viel verdienen 
kann.

Vielen Dank & Tschüs
  Jürgen

[Andreas H. (ahz)]

Konrad S. schrieb:
> Es ist eben gerade nicht nebensächlich. Der Anfänger wird - nur um
> nichts falsch zu machen - genau den besprochenen μC kaufen, den ihm sein
> Einstiegsbuch nahelegt. Und genau damit macht er den ersten - für ihn
> nicht erkennbaren, daher unvermeidlichen - Fehler: Investition
> in veraltete Technik. Nein, nicht das bisschen Geld für den μC ist
> verschwendet, sondern die viele Zeit fürs Lernen an veralteter Technik.
> Das führt dann dazu, dass später der Nicht-mehr-ganz-Anfänger ums
> Verrecken nicht mehr von dem alten Scheiß lassen will. Wie auch am TO zu
> sehen ist, denn er wurde schon im September-Thread darauf hingewiesen.
> dass der ATmega8 veraltet ist.

Lieber Konrad

Versteh mich nicht falsch. Aber wieviel Embedded Entwickler sind NICHT 
in der Lage den Prozessor zu wechseln, nachdem sie es (irgendwann) auf 
IRGENEINEM Prozessor gelernt haben ?

Wenn ich Deine Argumentation weiterführe, dann wären doch Anfänger, die 
sich heute mit CORTEX3/4 beschäftigen in spätetestens 10 Jahren komplett 
outdated.
Bildest Du Dir wirklich ein, dass das auch nur für 5% der Entwickler 
zutrifft? Die sind doch nicht alle gegen die Wand gelaufen ...

Andersherum wird aber auch kein Schuh daraus. Wenn Du auf eine 
Prozessorfamilie eingearbeitet bist (egal welche), dann wirst Du solange 
wie möglich dabei bleiben. Denn dann kennst Du auch die "kleinen Macken" 
dieser Familie. Und mit so etwas kann jede Familie aufwarten.
Darum werden auch heute noch MCS52 Derivate eingesetzt. Die Anwendung 
braucht nicht mehr Rechenleistung. Warum also aufrüsten ?

Bilde Leute nach dem KISS Prinzip aus und die Leute können sich selber 
weiterentwickeln. Und DANN ist der Prozessor völlig egal.

/regards
Andreas

[jdhenning (Gast)]

F. Fo schrieb:
> Ich muss mich noch einmal zu Wort melden.
> Es gibt schon ein sehr gutes Buch und eben für moderne AVR.
> Das AVR Kochbuch.

Ich hatte das Buch irgendwo schon mal gesehen und war vom Werbetext 
verschreckt worden: "Rezept auswählen, Zutaten zusammenstellen – und 
genießen. Nach genau diesem Konzept finden Sie in diesem Buch alles,
um Ihr „Mikrocontroller-Süppchen“ zu kochen". Da hatte ich nichts 
sinnvolles erwartet. Ich habe jetzt mal in dem Teil 'geblättert', der im 
Internet einsehbar ist; wenn der Rest vom Buch genauso ist, dann ist das 
sicherlich keine schlechte Kaufentscheidung.

Hast du das Buch (gelesen) und gehen die auch auf jedes Register und 
jedes Bit darin ein?

Jürgen

[jdhenning (Gast)]

oldmax schrieb:
> Wenn du also vielleicht die ein oder andere Hilfe brauchst...
> Gruß oldmax

Im Augenblick brauche ich am meisten mehr Zeit. Danke für das Angebot, 
ich werde es im Hinterkopf behalten.

Gruß
  Jürgen

[jdhenning (Gast)]

Hallo Andreas.

Andreas H. schrieb:
> Bilde Leute nach dem KISS Prinzip aus und die Leute können sich selber
> weiterentwickeln. Und DANN ist der Prozessor völlig egal.

Ich bin gerade dabei deine Behauptung in der Praxis zu verifizieren 
(Einarbeitung in den ATmega328). Leider schaffe ich nur knapp 30 Seiten 
am Tag. Bisher habe ich nur feststellen können, dass einige Register und 
Bits andere Namen bekommen haben und manche die Position gewechselt 
haben. Du könntest also recht haben.

Gruß
  Jürgen

[Atmega8 A. (atmega8)]

Du kannst auf das Cover auch einfach in ATmega328 umbenennen.
Ein Arduino-Zusammenhang kann man im Buch aber auch herstellen, das 
macht die Erstellung des ersten Projekts einfacher.

Der Unterschied zwischen denen ist recht klein!
http://avrprogrammers.com/articles/atmega8-vs-atmega328


- Der Controller hat doch nur ein paar zusätzliche Interruptquellen und 
noch ein paar Kleinigkeiten, deshalb ist er ja so gut gegen einen 
(alten) ATmega8 ersetzbar.

Ich würde wahrscheinlich die zusätzlichen Interrutquellen hinzufügen und 
gut.


zum Atmega328P (der für den Arduino mini/micro genutzt wird):

- Eine komplette Micro-Platine ist unglaublich billig. (1,82 Euro)
Ein ATmega8 kostet ja schon 1,70 Euro bei Pollin.
http://www.ebay.de/itm/351237508524

- Die Nano-Platine (mit USB):
Sie kostet auch nur 2,91 Euro
http://www.ebay.de/itm/301292188973


Das aller schwerste bei dem AVRs war es eigentlich einen Anfang zu 
finden.
Der Einstieg in die Materie sollte klar und einfach beschrieben werden.

So ähnlich wie das "Hello-World!" C++ Programm in der Console, aber eben 
mit den zugehörigen Platinen.
Man fängt dann so an: Ich nehme eine ATmega328P-Platine, löte ein einen 
Stecker und einen Verpolschutz (Diode) ran und kann dann einen 
LiIon-Akku nutzen.
Oder eben das gleiche mit einem 12V,  5V Netzteil oder 3.3V Netzteil.

Der minimale Aufbau eines Programms, meine Arbeitsschleife und welche 
Dateien ich dann alles habe, bzw. zu welchen Dateien noch gelinkt werden 
oder erstellt werden war für mich wichtig, besonders die hex-Datei... 
ich musste ja erst mal eine einfache Ordnung im Kopf aufbauen damit ich 
das verstehe.

Dann mit AVRdude in der Konsole auf den AVR schreiben und die angelötete 
LED beobachten.

Die LED war meine erste Hilf beim debugen des Programmt, irgendwann hat 
es nicht mehr ausgereicht und man nutzte den USB-UART-Konverter um etwas 
am Bildschirm anzuzeigen.

Zuerst gab es da eine Delay-Routine, danach etwas mit dem Timer wo ich 
dann etwas versaut hatte da die LED nicht mehr im Sekundentakt geblinkt 
hat, sondern scheinbar schwach geleuchtet hat. (sie hat jetzt sehr 
schnell geblinkt da ich das falsche Register verändert hatte)

[Thomas E. (thomase)]

Atmega8 Atmega8 schrieb:
> Der Unterschied zwischen denen ist recht klein!

Atmega8 Atmega8 schrieb:
> - Der Controller hat doch nur ein paar zusätzliche Interruptquellen und
> noch ein paar Kleinigkeiten, deshalb ist er ja so gut gegen einen
> (alten) ATmega8 ersetzbar.

Eigentlich gibt es da fast überhaupt keinen Unterschied.

Abgesehen von den Pin Change Interrupts, für deren Erklärung man 
wahrscheinlich 20 Seiten braucht, damit es auch der Letzte rafft, einem 
vernünftigen Timer0, an Stelle des 8048-Revival-Timers. Dazu noch 
jeweils 2 PWM-Channels pro Timer und für jeden Timer exklusive Register. 
Nicht zu vergessen der Watchdog-Timer. Diverse Trigger-Quellen für den 
ADC und natürlich andere Referenzspannungen. Dazu noch abschaltbare 
Digitaleingänge. Ein anderes Konzept des internen Oszillators. Ein 
USART, der auch SPI kann. Ein grösserer Spannungsbereich sowie eine 
höhere maximale Taktfrequenz. Noch was vergessen? Ach ja: Debug Wire.

Und 3 kleinere Brüder. Auch die sehr einfache Portierung auf den 644er 
und Konsorten könnte man noch erwähnen, damit überhaupt ein paar 
nennenswerte Unterschiede zusammenkommen.

Und das Datenblatt ist mehr als doppelt so dick. Wahrscheinlich weil da 
so viele bunte Bilder drin sind.

mfg.

[Paul B. (paul_baumann)]

Thomas Eckmann schrieb:
> Und das Datenblatt ist mehr als doppelt so dick. Wahrscheinlich weil da
> so viele bunte Bilder drin sind.

Richtig. Wegen den bunten Bildern. Es kann aber auch sein, daß ein 
doppelt
so dickes DatenBUCH (nein, kein -blatt, bei diesem Umfang) auch doppelt
soviel Verwirrung bei einem Laien auslöst.

Skifahren lernt man auch nicht in der 1. Viertelstunde auf der Streif in
Kitzbühel.
;-)

MfG Paul

[jdhenning (Gast)]

Moin Atmega8.

Atmega8 Atmega8 schrieb:
> Ich würde wahrscheinlich die zusätzlichen Interrutquellen hinzufügen und
> gut.

Ich habe mich heute durch die Interruptliste gearbeitet und auch 
festgestellt, dass die Unterschiede nicht riesig sind. Leider sind aber 
auch viele Kontrollbits in andere Register verschoben worden, weshalb 
mir ein wenig mehr Arbeit bevorsteht. Bisher bin ich noch der Meinung, 
dass ein Umstieg eigentlich recht einfach sein sollte. Falls ich nicht 
schneller werde, werde ich das Ende Februar wissen und natürlich hier 
bekannt machen.

Danke & Tschüs
   Jürgen

[jdhenning (Gast)]

Hallo Thomas.

Thomas Eckmann schrieb:
> Und das Datenblatt ist mehr als doppelt so dick. Wahrscheinlich weil da
> so viele bunte Bilder drin sind.

Ich nehme an, dass du da recht hast. Ich habe vorhin 4 Tabellen mit den 
Interrupten abgearbeitet und außer der Bezeichnung (die aber letztlich 
überhaupt keine Rolle spielt) sind da überhaupt keine Unterschiede 
festzustellen. Oder um es etwas drastischer auszudrücken: Das Datenblatt 
ist noch mieser als das vom ATmega8. Aber was soll man machen, man ist 
ja abhängig.

Danke & Tschüs
  Jürgen

[jdhenning (Gast)]

Moin Paul.

Paul Baumann schrieb:
> Richtig. Wegen den bunten Bildern. Es kann aber auch sein, daß ein
> doppelt so dickes DatenBUCH (nein, kein -blatt, bei diesem Umfang)
> auch doppelt soviel Verwirrung bei einem Laien auslöst.

Ich gehe der Sache gerade akribisch nach, habe aber die Befürchtung, 
dass man mit 'doppelt' nicht hinkommen wird.

Jürgen

[Thomas E. (thomase)]

jdhenning schrieb:
> Das Datenblatt ist noch mieser als das vom ATmega8.

Was hast du gegen die Datenblätter? Ich finde die hervorragend.

jdhenning schrieb:
> Ich nehme an, dass du da recht hast.

Ich nehme an, du hast es nicht so verstanden, wie ich es gemeint habe.
Aber ich weigere mich, Ironie zu kennzeichnen.

jdhenning schrieb:
> Ich habe vorhin 4 Tabellen mit den Interrupten abgearbeitet

Dann bist du auch noch ganz am Anfang.

Die komplette Beschreibung des Atmega48..328 ist mit ein bisschen
"What's New?" aus der 8er Beschreibung heraus nicht getan. Das wird ein 
zweites Buch. Aber nicht ein Kapitel mehr.

Allerdings verstehe ich das Ganze nicht. Vor gut einem Jahr hat man dir 
noch von mehreren Seiten nahegelegt, irgendwas zwischen gut zureden und 
gewaltsam ins Hirn kloppen, den 48..328er zu nehmen. Dagegen hast du 
dich noch mit Händen und Füssen gewehrt.

Scheint mir so, als wärest du jetzt zu der Erkenntnis gekommen, das mit 
dem 8er ist doch nicht so eine gute Idee. Und jetzt versuchst du es 
irgendwie zu retten. Wenn dem so ist, schreib ein neues Buch. Wenn ich 
mich irre, lass das jetzige so, wie es ist.

Die Einschätzung des Atmega8-Freundes weiter oben ist doch sehr naiv.

mfg.

[jdhenning (Gast)]

Moin Thomas,

Thomas Eckmann schrieb:
> Ich nehme an, du hast es nicht so verstanden, wie ich es gemeint habe.
> Aber ich weigere mich, Ironie zu kennzeichnen.

Wenn man ironisch sein will, dann verpufft die Wirkung, wenn man nicht 
hinreichend überspitzt.

Und es war nicht überspitzt, denn ich hätte überhaupt keine 
Schwierigkeiten gehabt den ATmega8 komplett zu begreifen, wenn ich 
damals das Buch gehabt hätte, das ich jetzt geschrieben habe. Ich habe 
bisher das Datenbuch zum ATmega328 nur überflogen und nur bis zur Seite 
80 durchgearbeitet. Bisher sehe ich nur, dass du ohne jegliche Spur von 
Ironie wahr geschrieben hast (hierbei nehme ich ausdrücklich den 
DebugWIRE aus, denn den kenne ich noch nicht).

Du meinst wirklich, dass es einen Techniker umhaut, wenn es ein paar 
neue Register gibt und wenn ein paar Bits in ein anderes Register 
verschoben wurden? Ich kann dir jetzt noch keine abschließende Antwort 
darüber geben, ob der Umstieg tatsächlich derartig einfach ist, wie ich 
es aktuell vermute. In zwei, drei Wochen kommt meine Antwort; ganz 
gewiss.

Und ich habe mich nicht mit Händen und Füßen dagegen gewehrt, vom 
ATmega8 abzurücken. Das Problem war, die ganzen Argumente waren nicht 
stichhaltig und man konnte sie eigentlich bedenkenlos in die Tonne 
drücken. Erst in diesem Thread kam eine (einzige!) Meinung, die mich zum 
Umdenken bewegt hat. "Die Leute (also mögliche Buchkäufer) kaufen nicht 
das, was für sie nützlich ist, sondern das, was sie für neu/modern 
halten." Ich versuche also nicht, irgendetwas zu retten, sondern ich 
beuge mich einem guten Argument (Danke übrigens für den Post, falls ich 
das nicht schon geschrieben hatte).

Gruß
  Jürgen

[Konrad S. (maybee)]

Andreas H. schrieb:
> Konrad S. schrieb:
>> Es ist eben gerade nicht nebensächlich. Der Anfänger wird - nur um
>> nichts falsch zu machen - genau den besprochenen μC kaufen, den ihm sein
>> Einstiegsbuch nahelegt. Und genau damit macht er den ersten - für ihn
>> nicht erkennbaren, daher unvermeidlichen - Fehler: Investition
>> in veraltete Technik. Nein, nicht das bisschen Geld für den μC ist
>> verschwendet, sondern die viele Zeit fürs Lernen an veralteter Technik.
>> Das führt dann dazu, dass später der Nicht-mehr-ganz-Anfänger ums
>> Verrecken nicht mehr von dem alten Scheiß lassen will. Wie auch am TO zu
>> sehen ist, denn er wurde schon im September-Thread darauf hingewiesen.
>> dass der ATmega8 veraltet ist.
>
> Versteh mich nicht falsch. Aber wieviel Embedded Entwickler sind NICHT
> in der Lage den Prozessor zu wechseln, nachdem sie es (irgendwann) auf
> IRGENEINEM Prozessor gelernt haben ?
...
> Bilde Leute nach dem KISS Prinzip aus und die Leute können sich selber
> weiterentwickeln. Und DANN ist der Prozessor völlig egal.

Versteh mich bitte auch nicht falsch. Ein ¨Embedded Entwickler¨, der 
sich davor scheut, sich die benötigten Informationen aus den 
englischsprachigen Datenblättern - egal welchen Umfangs - und den 
Application Notes des Hersteller zu suchen, soll sich besser umschulen 
lassen zum Fachberater für Lego-Bausteine in der Spielwarenabteilung. 
Ein (angehender) Entwickler hat doch hoffentlich in seiner Ausbildung 
soviel mitbekommen, dass er im Wesentlichen mit den 
Hersteller-Informationen zurechtkommt. Oder erwarte ich da für heutige 
Verhältnisse schon zuviel?

Die Zielgruppe des zur Debatte stehenden Buchs ist, dem Inhalt nach zu 
urteilen, eher der Bastler und evtl. noch der Quereinsteiger, nicht aber 
der professionelle Entwickler für μC-Schaltungen. Dahingehend zielt auch 
meine Argumentation.

[Ralph S. (jjflash)]

Weil ich seit nun mehr 2 Jahren auch an einem "Buch" arbeite (immer 
wieder einmal) das sich mit den  AVR Microcontrollern beschäftigen soll 
das sich an absolute Anfänger und Einsteiger richten soll (und ich schon 
über 700 Seiten geschrieben habe und bei weitem noch nicht fertig bin) 
bin ich jetzt dabei, dein Manuskript zu überfliegen. (bei meinem Buch 
soll allerdings Software – nicht nur AVR MCU-Programme enthalten sein, 
sondern vorwiegend auf Linux – Basis auch ein System, bei dem der 
Benutzer lediglich einen Stick oder – wenn er nichts speichern muss – 
nur eine CD einlegt, diese bootet und AVR-GCC Compiler, Editor und 
einiger Helpers sofort zur Verfügung stehen).

Ich bin u. a. Ausbilder für Elektroniker und stelleimmer wieder 
bestimmte Schwierigkeiten von Auszubildenden fest, bestimmte Dinge zu 
begreifen (abgesehen davon, dass die Begeisterung für diese Technik vor 
30 Jahren deutlich höher war, als dies heute ist).

Notizen, die ich beim Überfliegen deines Scriptes mache sind:

- prinzipiell hab ich absolut den Verdacht, dass du von der 8048 / 8051 
/ 8080 “Schiene” kommst

- im Einleitenden Teil schreibst du vom Verfahren, wie ein Prozessor 
Programme abarbeitet und warum es Register und Akku gibt (aber nicht, 
dass der Akku ein “Spezialregister” ist über den komplett gerechnet wird 
(und nur über diesen) hier hättest du sogar (wenn man das so will) auch 
etwas über eine ALU schreiben können, damit klar wird, dass 
Rechenoperationen über den Akku laufen müssen.

- das erste Auftauchen eines (Maschinen)Befehls ist ein BRNE und du 
schreibst etwas von Schleifen (hier muss also jemand der dein Script in 
die Hand nimmt schon einmal deutlich wissen, was Maschinensprache ist 
und er muss wissen, was Schleifen sind) …

- du führst danach das Statusregister auf in dem du schreibst, dass in 
der ALU das Statusregister den Status der CPU beinhaltet (hier taucht 
die ALU das erste mal auf).

Ich breche das hier einmal ab um es später weiter zu lesen. Meine 
Auszubildenden hätten bis hierher erst einmal “Bahnhof” verstanden und 
du solltest dir Gedanken über die Zielgruppe deines Buches machen. Zum 
einen erklärst du fast 10 Seiten lang einen Computer, versuchst 
Unterschiede RISC und CISC zu erklären und du erklärst warum es die 
Register gibt (also für extreme Neulinge) … nur um dann gleich mehrere 
Schritte zu überspringen.

(solche Dinge sind der Grund, warum ich nach über 700 Seiten nicht 
einmal im Ansatz fertig bin)

Ich werde weiterlesen...

[Klaus I. (klauspi)]

jdhenning schrieb:

> Und es war nicht überspitzt, denn ich hätte überhaupt keine
> Schwierigkeiten gehabt den ATmega8 komplett zu begreifen, wenn ich
> damals das Buch gehabt hätte, das ich jetzt geschrieben habe.

Ohne Dir zu nahe treten zu wollen, aber vielleicht ist das ein Problem. 
Ich bin selbst noch Anfänger in dem Bereich habe aber schon etwas 
Vorwissen. Mit diesem Vorwissen habe ich schon einige interessante 
Punkte in Deinem Manuskript gefunden.

Als kompletter Einsteiger würde ich mich aber sehr schwer tun. Mir ist 
nicht ganz klar, welches Vorwissen Du beim Leser erwartest.

Auf jeden Fall Respekt dafür, dass Du Dir diese Arbeit antust. 
Vermutlich wirst Du ja ab diesem Punkt nochmal das 2-3fache der 
bisherigen Arbeit reinstecken müssen, damit ein wirklich gutes Buch 
rauskommt.

[Ralph S. (jjflash)]

Jetzt habe ich einiges gelesen und einiges überflogen und komme bei 
dieser Lektüre zum Schluß, dass das zur Hälfte ein Text über die 
Möglichkeiten eines ATmega8 ist und zur anderen Hälfte (oder mehr) 
grundsätzlich ein Buch darüber ist, wie Softwareproduktion von statten 
geht (gewürzt mit einem Abriß von verketteten und doppelt verketteten 
Listen), die prinzipiell schon ein hohes Verständnis der Programmierung 
erfordern (und sich noch nicht einmal speziell an Microcontrollern 
geschweige denn am ATmega8 oder deren besseren Brüdern ATmegaxx8 
orientieren).

Die zweite Hälfte ist somit deutlich besser als die erste Hälfte des 
Textes ist aber für einen "Einsteiger" (aus meiner Sicht der Dinge) 
nicht wirklich brauchbar !

Dein Buch setzt ein grundsätzliches Verständnis (aus heutiger Sicht 
sogar ein hohes Maß des Verständnisses) im Umgang mit Computern vorraus. 
Dementsprechend wäre der erste Teil (der, bei dem es im Grunde genommen 
um Erläuterungen aus dem Datenblatt in deutscher Sprache geht) dann 
eigentlich unnötig !

[Conny P. (conny_phi)]

Ralph S. schrieb:
> Ich breche das hier einmal ab um es später weiter zu lesen. Meine
> Auszubildenden hätten bis hierher erst einmal “Bahnhof” verstanden und
> du solltest dir Gedanken über die Zielgruppe deines Buches machen. Zum

Da bin ich froh, dass auch andere zu dieser Erkenntnis kommen. In meinem 
Beitrag oben habe ich ein paar andere Stellen aufgeführt, an denen ein 
Anfänger einfach nicht verstehen wird, worum es geht.

[PittyJ (Gast)]

Ich habe das Buch auch mal überflogen.
Ich bin ein optischer Mensch. Für mich sind viel zu wenig Diagramme in 
dem Buch. Es ist meiner Meinung nach viel zu textlastig.

Ich habe mich dann an mein erstes Buch von vor 30 Jahren erinnert:
'Programming the Z80' von Rodnay Zaks
Die Diagramme der Register und Abläufe sind mir immer noch im Kopf. Und 
das hat mir damals geholfen, die Strukturen der Register zu verstehen.

Ein anderes Beispiel: da wird Polarität und Abtastzeitpunkt des 
SPI-Busses erklärt. Warum geht das nicht per Diagramm wie in Wikipedia?
http://de.wikipedia.org/wiki/Serial_Peripheral_Interface
Ok, der geneigte Leser kann selber in Wikipedia nachschlagen, aber dann 
bräuchte er überhaupt kein Buch.

Mein Fazit: Mehr Diagramme, Schaubilder und Abläufe.

[jdhenning (Gast)]

Hallo Ralph, danke für den langen Post.

Ralph S. schrieb:
> Ich breche das hier einmal ab um es später weiter zu lesen. Meine
> Auszubildenden hätten bis hierher erst einmal “Bahnhof” verstanden und
> du solltest dir Gedanken über die Zielgruppe deines Buches machen.
Es steht irgendwo am Anfang (und soll später auch auf der Rückseite vom 
Buch stehen), dass Vorkenntnisse in C erforderlich sind. Folglich kann 
und darf ich davon ausgehen, dass der Leser sogar weiß, was ein 
Compiler, ein Linker und eventuell sogar was ein Loader ist. Die 
Zielgruppe ist auch eindeutig umrissen: Alle diejenigen, die sich 
ernsthaft mit MCUs beschäftigen wollen, weil sie eine Projektidee haben 
und hoffen, mit einer MCU schneller zum Ziel zu kommen.

Betrachte die Sache doch bitte mal aus einer völlig anderen 
Blickrichtung: Wieviele deiner Auszubildenden hätten irgendeine Chance, 
sagen wir mal eine einfach Steuerung zu realisieren, wenn du ihnen nur 
das Datenblatt von Atmel gibst? Sehr wahrscheinlich keiner und genau das 
wird der Grund sein, warum du an deinem Buch arbeitest.

> (solche Dinge sind der Grund, warum ich nach über 700 Seiten nicht
> einmal im Ansatz fertig bin)
Die Gefahr sah ich auch und habe mein Vorhaben deshalb deutlich 
eingeschrumpft. Mein Buch soll eine Hilfe zur Selbsthilfe sein, damit 
man so viel Vorwissen hat, dass man erfolgreich mit dem Datenblatt 
arbeiten kann, oder im Allgemeinen auf es verzichten kann (weshalb ich 
auf jedes Register und auf jedes Bit eingehe). Für alles, was ich nicht 
beschreibe, gibt es gute Artikel und Tutorials im Internet, insbesondere 
findet man dort problemlos zumindest in die Thematik einführende 
Programmbeispiele.

Da wir also eindeutig keine Konkurrenten sind fällt es mir leicht, dir 
viel Erfolg mit deinem Buch zu wünschen. Und natürlich bin ich auch für 
jede weitere Kritik dankbar (meinem Ego gefällt das zwar nicht immer, 
aber das Buch wird dadurch ja höchstens besser).

  Jürgen

[jdhenning (Gast)]

Ralph S. schrieb:
> (gewürzt mit einem Abriß von verketteten und doppelt verketteten
> Listen)

Hallo noch mal. Die (doppelt) verketteten Listen habe ich nicht als 
Würze hinein gebracht, sondern die sind die unverzichtbare Grundlage für 
eine Datenhaltung, wie man sie in einem Betriebssystem braucht. Auf 
einer kleinen MCU kann so ein Betriebssystem nur rudimentär sein, 
erfordert also viele 'händische' Eingriffe vom Programmierer, muss also 
möglichst vollständig verstanden sein. Weil so ein kleines 
Betriebssystem wahnsinnig praktisch ist (Prozesse können sich 
beispielsweise wirklich schlafen legen und die CPU steht anderen 
Prozessen zur Verfügung; man kann verschiedene Aufgaben sauber 
voneinander trennen, was die Sache 'servicefreundlich' macht), wollte 
ich es gerne mit drin haben. Ohne die verketteten Listen würde man den 
Mops (Multitasking OPerating System) aber nicht verstehen und anpassen 
können.

Abgesehen davon habe ich bisher nur ganz wenige Programe gesehen, bei 
denen so wenig Datenhaltung drin war, dass sie überhaupt keine Probleme 
machte. Mit den fragmentierten Listen überhaupt kein Thema mehr. Daten 
rein, raus, suchen oder ändern, alles drin und geprüft.

Bitte immer im Hinterkopf behalten: Ich bin ein fauler Mensch und 
schreibe nicht, um Seiten zu füllen, sondern weil ich die Inhalte für 
wichtig halte.

[jdhenning (Gast)]

Conny Phi schrieb:
> Ralph S. schrieb:
>> Ich breche das hier einmal ab um es später weiter zu lesen. Meine
>> Auszubildenden hätten bis hierher erst einmal “Bahnhof” verstanden und
>> du solltest dir Gedanken über die Zielgruppe deines Buches machen. Zum
>
> Da bin ich froh, dass auch andere zu dieser Erkenntnis kommen. In meinem
> Beitrag oben habe ich ein paar andere Stellen aufgeführt, an denen ein
> Anfänger einfach nicht verstehen wird, worum es geht.

Das kommt auf die Definition von Anfänger an. Die meisten Informatiker, 
die ich kenne, sagen zu Hardware "Igitt, das fasse ich nicht an!"; wenn 
so einer sich dann doch den MCUs widmet, dann ist er ein Anfänger. Vor 
etwas über einem halben Jahr war ich in Bezug auf MCUs auch ein Anfänger 
(das schreibe ich ja sogar in der Einleitung; und einige meinen, ich 
wäre es immer noch).

Ich behaupte ja nicht, dass ich da 'leichte Diätküche' schreibe; 
andererseits finde ich es nicht übertrieben, wenn man von dem Leser 
eines Fachbuches verlangt, dasss er sich gefälligt auch konzentriert. 
Leichte Kost mit wenigen geistigen Kalorien findet man zuhauf im 
Internet.

Guten Rutsch
  Jürgen

[jdhenning (Gast)]

PittyJ schrieb:
> Mein Fazit: Mehr Diagramme, Schaubilder und Abläufe.

Kommt, ist versprochen.

Guten Rutsch
  Jürgen

[Max (Gast)]

Ich finde das Buch nach wie vor sehr gelungen!!

Die frage nach der Zielgruppe stellt sich nicht!!

Absolute, blutige Anfänger!1 niemand sagt das die Techniker werden 
sollen, das kann auch der Hobbybastler sein, und wird es mit höchster 
Warscheinlichkeit auch werden.

ICH hätte mir das Buch damals mit Sicherheit gekauft!! Also denke ich 
auch, das auch heute noch ein Markt daa sein wird, obwohl ein STM32 Buch 
sich sicher auch super verkaufen lässt.

Also lass Dich hier nicht beirren, hier sind halt viele Fraks/Nerds 
unterwegs und die können nun mal mit dem Buch nicht viel Anfangen sind 
aber auch nicht die Zielgruppe.


Und daran, wie wenig Bücher es gibt, sieht man das VIELE ein Buch 
schreiben wollen, aber es offenbar nicht zu ende bringen :-)


Daher lass Dich nicht verrückt machen und tue es einfach!

Tue das, was die meisten hier nicht hinbekommen, nicht nur denken 
sondern auch machen!
Davon gibt es hier leider viel zu wenige, hier sind überwiegend die 
Theoretiker.

Ich bin übrigens trotz einiger Beiträge, immer noch überrascht wie 
gesittet es hier momentan zugeht :-)

[Fpgakuechle K. (Gast)]

Thomas Beierlein, Olaf Hagenbruch "Taschenbuch Mikroprozessortechnik", 
Carl Hanser Verlag,
978-3-446-42331-2.

Wie in "Taschenbuch" üblich eine kompakte Darstellung mit der nötigen 
Prosa. Richtet sich meines Erachtens an den professionelen 
Hardwareentwickler, wenige an den Hobbybastler. Schränkt sich nicht auf 
einen µC, hat aber den
Fokus auf die kleinen (8-bit). Enthält auch Kapitel zur Baustein-auswahl 
und debugging. Auf die ATmegas wird als beispiel für I/O Port-logik, 
Timer und Taktsystem eingegangen.

Mit diesem Buch sollte man das nötige Rüstzeug für das Verständnis der 
Orginal-datenblätter haben.

http://www.hanser-fachbuch.de/buch/Taschenbuch+Mikroprozessortechnik/9783446423312

-> Inhaltsverzecihniss und Leseprobe


MfG,

[Cyblord -. (cyblord)]

jdhenning schrieb:

> Das kommt auf die Definition von Anfänger an. Die meisten Informatiker,
> die ich kenne, sagen zu Hardware "Igitt, das fasse ich nicht an!"; wenn
> so einer sich dann doch den MCUs widmet, dann ist er ein Anfänger.

Ich wäre für einen alternativen Buchtitel: "Unwissenheit und 
Vorurteile". Das passt perfekt zu dir und die Mischung ist weithin 
erprobt.

Dein Buch zeigt deutlich, dir fehlt es sowohl an Fachwissen und 
Erfahrung mit der Materie (ja das ist mehr als das Datenblatt lesen) als 
auch an pädagogischer Herangehensweise oder auch nur einer logischen 
Struktur. Kraut und Rüben sagt man wohl umgangssprachlich. Ordne mal 
deine Gedanken ein wenig.

Wie ich schon zu Anfang vermutete: 30 Jahre altes Wissen, das 
Überfliegen eines Datenblattes und übersteigertes Selbstbewusstsein 
reichen einfach nicht um ein gutes Buch zu schreiben.

[jdhenning (Gast)]

Max schrieb:
> Ich bin übrigens trotz einiger Beiträge, immer noch überrascht wie
> gesittet es hier momentan zugeht :-)

Ich auch. Guten Rutsch
  Jürgen

[jdhenning (Gast)]

Cyblord ---- schrieb:
> Ich wäre für einen alternativen Buchtitel: "Unwissenheit und
> Vorurteile". Das passt perfekt zu dir und die Mischung ist weithin
> erprobt.
>
> Dein Buch zeigt deutlich, dir fehlt es sowohl an Fachwissen und
> Erfahrung mit der Materie (ja das ist mehr als das Datenblatt lesen) als
> auch an pädagogischer Herangehensweise oder auch nur einer logischen
> Struktur. Kraut und Rüben sagt man wohl umgangssprachlich. Ordne mal
> deine Gedanken ein wenig.

Hat dir deine Mama das Buch "Der kleine Hobbypsychologe" zu Weihnachten 
geschenkt? Du bist sogar schon bis zum Kapitel "Die Ferndiagnose" 
gekommen. Fleißig, fleißig, da wird ja vielleicht doch noch mal was aus 
dir!

Aber pädagogisch hast du das noch nicht richtig drauf. Das heißt nicht 
"übersteigertes Selbstbewusstsein" sondern "realistische 
Selbsteinschätzung". Kleiner Unterschied, kann man aber schon mal 
verwechseln.

Und jetzt gehe ich feiern. Tschüs!

[jdhenning (Gast)]

Fpga Kuechle schrieb:
> Thomas Beierlein, Olaf Hagenbruch "Taschenbuch Mikroprozessortechnik",
> Carl Hanser Verlag,

Ich bin eben durch das Inhaltsverzeichnis durchgegangen und habe den 
Eindruck gewonnen, dass das Buch ganz sicher nicht schlecht ist. Was 
mich stören würde ist, dass es nur ungefähr 40 Seiten zum Thema MCUs 
gibt. Daher ist es recht wahrscheinlich nur eine minimale Hilfe beim 
Kampf mit dem Datenbuch von Atmel.

Guten Rutsch
  Jürgen

[Atmega8 A. (atmega8)]

Hey Leute, ihr sollt ihn nur ein paar sinnvolle Informationen und 
Hinweise geben durch die er es Einsteigern erleichtert in die Materie 
einzusteigen.

Wenn es ein Neuling in der Bücherei findet (passender Titel des Buches 
vorausgesetzt [nach welche Schlagworte wird der Student/Schüler in 2 
Jahren suchen?]) dann muss er auf den ersten Seiten eine gute 
Einstiegsbeschreibung finden und auf den folgenden Seiten kommen dann 
tiefer gehende Informationen mit passenden kleinen Beispielen.

Bei den Beispielen muss auch nicht alles gezeigt werden, aber es sollte 
im Text stehen wie ich z.B. eine schnelle 8 Bit PWM oder eine langsame 
16Bit PWM erzeuge und wie die Formel dafür aussieht und welche Daten ich 
für die Formel brauche.

So ein Beispiel mit Touche-Pads würde ich noch schön finden, man muss 
nur sehen können wie sich der Wert auf einem LCD verändert.
Man braucht dazu ja nur einen 1MOhm Widerstand und einen Draht den man 
zum Teil zu einer Schnecke zusammenrollt um auf ihn Tastübungen 
durchführen zu können.


Quasi wie bei uns in der Mathematik, nach jedem Satz/Definition kommt 
ein kleines Beispiel, das macht das Lernen viel einfacher.
Man sollte das auch schön abgrenzen:

1 Was brauche ich um anfangen zu können? <-- viele Bilder, klare 
Übersicht
1.1 Das Arduino-Bord
1.2 Erklärung der Grundschaltung
1.3 Nutzung von Tastern und LEDs
1.4 Wie lasse ich eine LED blinken?
1.4.1 Die Delay-Routine
1.4.2 Die Interrupt-Routine
1.5 Wie kommuniziere ich mit meinem Controller?
1.5.1 Der UART (USB-Verbindung mit USB-UART-Konverter)
1.6 ...

3 Peripherie
3.1 Definition/Beschreibung Timer
3.2 Beispiel Timer
3.3 Definition/Beschreibung SPI
3.4 Beispiel SPI

Man kann dann vom ersten Abschnitt mit den einfachen 
Einsteigerbeispielen in den 3. Abschnitt verweisen, dort steht es dann 
alles detaillierter.