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
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.
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.
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
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
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. ;)
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.
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
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.
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.
@ 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.
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
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.
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)
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
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
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.
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
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
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 ;-)
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
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
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
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
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
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
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. ...
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.
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.
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
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!"
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
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
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.
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
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.
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
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.
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.
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.
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.
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
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?"
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
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.
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.
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
... 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)
F. Fo schrieb:> Kann ich nur unterstützen.> Hebt mal die Hand, wer sich zu Anfang nicht mal ausgesperrt hat! :-)>>
\cccc
(|||)
(|||)
\ /
| |
| |
| |
______/ /
/
______/
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;-)
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
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
> 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.
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
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. :-)
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.
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!
:-)
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...
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
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.
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.
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! :-)
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
Wolfgang Schmidt schrieb:> Die bei Atmel schwer zu findende Dokumentation.
Danke, werde ich mir reinziehen, wenn ich die ganzen Posts beantwortet
habe.
Jürgen
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
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
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...
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
@ 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
@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.
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
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.
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.
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.
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
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
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
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
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
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
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.
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
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
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
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!
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).
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
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.
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!
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.
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.
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.
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
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 ;)
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.
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
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 ;-)
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
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
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
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
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.
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
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
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
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
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
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.
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! :-)
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.
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.
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.
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.
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
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
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
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.
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
C ist, was sein Altern in Jahren angeht, schon ein wenig angestaubt und an den Universitäten lernt
2
man, wenn überhaupt noch C, natürlich C++, denn die angehenden Informatiker und Techniker
3
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é
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
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.
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
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.
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.
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
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.
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?
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!?!
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
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!
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.
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...
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. 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?
@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.
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?
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
@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
jdhenning schrieb:> Das würde ja> bedeuten, vor Proleten den Schwanz einzukneifen. Sollte man nicht tun!
/signed
Jürgen mach weiter :-)
/regards
Andreas
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
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.
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!
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.
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
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
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
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
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
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
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
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
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
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
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
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)
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.
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
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
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
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
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.
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
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.
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...
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.
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 !
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.
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.
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
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.
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
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 :-)
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,
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.
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!
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
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.
Hi!
Da ich die Idee grundsätzlich gut finde habe ich mal durch dein
Manuskript gescrollt.
Was mir sofort auffällt ist, dass jegliche Beispiele fehlen. Ein
Lehrbuch ohne Beispiele ist wertlos - gerade wenn du als Zielgruppe
Hobbyisten ohne Vorkenntnisse im Kopf hast.
Weiterhin gibt es bereits das freie AVR ASM Manuskript (Link gerade
nicht zur Hand, aber ihr wisst sicher welches ich meine) sowie das gar
nicht so schlechte Buch Make AVR Programming. Ist halt englisch, aber
das sollte doch heutzutage kein Problem mehr sein. Btw, wenn O'Reilly
Interesse angemeldet hat, warum denn dann nicht für die Übersetzung des
o.g. Buches? Das wäre IMHO der besser Weg.
jdhenning schrieb:> 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.
tl;dr
Ich finde es dagegen sehr stark, wie du dir in deinem Buch /immer
wieder/ anmaßt, zu beurteilen, was technisch sauber oder unsauber ist.
An einigen Stellen sogar grundlos, weil du selbst etwas nicht verstanden
hast. Zum Beispiel die Erklärung mit den Pullups in deiner Anmerkung,
die im Zusammenhang mit deiner eigenen Erklärung vorher keinen Sinn
ergibt.
Nerds sind auch keine kompletten Fachidioten, wie du auf Seite 134
schreibst. Dagegen ist das enthaldende Kapitel komplett idiotisch, denn
außer wunderbaren Suchfunktionen in Editoren gibt es auch schon
wunderbare Werkzeuge wie doxygen zur Dokumentation. Und die erwähnst du
garnicht.
Insgesamt hat cyblord vielleicht spitz geschrieben, aber die Sache
eigentlich ganz gut getroffen. Als Nachschlagewerk taugt das Buch kaum
mehr als das Datenblatt. Aber das war sicherlich auch nicht dein
Anspruch, klar.
Aber auch als Lesestoff geht mir das nach zehn Seiten fürchterlich auf
die Nerven, dass du ständig persönliche Wertungen einbaust. Die
interessieren mich als Leser nicht! Schlimmer noch, solche Wertungen
stehen oft an Stellen, wo ich (jetzt als vermutlich etwas 'erfahrener'
Programmierer) quasi genau weiß, warum sie da stehen...
Insgesamt ist das Buch, ehrlich gesagt, inhaltlich ziemlich dünn und
nach ein paar Seiten fragt man sich als neutraler Leser: Warum soll ich
hier weiterlesen? Selbst der Autor schreibt ja andauernt, wie blöde das
alles ist.
Harald: Du meinst sicherlich dieses: http://www.avr-asm-tutorial.net/
Damit habe ich auch angefangen. Und ich finde es exzellent.
Es ist vorallem fachlich ziemlich korrekt. Es geht auch etwas direkter
zur Sache, aber ohne einen dabei abzuhängen.
Das wäre auch so ein Manko an Jürgens Buch: Man liest Kiloweise Papier
und es passiert eigentlich garnichts. Es kommt jede Menge Blahfusel
aus dem Datenblatt, aber irgendwie kriegt man als Leser trotzdem kein
lauffähiges Beispiel zusammen.
habe mir dein Buch auch mal durchgelesen und liefere die etwas
konstruktive Kritik.
1. Da du ja an hohen Verkaufszahlen interessiert sein wirst. Solltest du
nicht unnötigerweise die Zielgruppe verkleinern, deswegen würde ich
nicht den kleinsten ATMega nehmen, da diesem einige Hardwarebausteine
fehlen ich würde mich hier garnicht festlegen, sondern versuchen alle
Hardwarebausteine zu beschreiben.
2. Um für gleiche Bedingungen so sorgen würde ich den Aufbau eines
stabilisierten Netzteils einfügen
Trafo->Gleichrichter->Glättung->Entstörung->Stabilisierung inkl. der
empfohlenen Kerkos und Hintergrund... dazu ein kleiner Schaltplan oder
schematisches Bild.
Nicht jeder Schaltregler den dein Publikum dranhängt wird den µC zum
leben erwecken.
3. Die richtige Beschaltung des µC, hier gibt es auch viele Infos und
Empfehlungen von Atmel selbst, die auch öfter mal abweichen und wo man
drauf eingehen kann wieso das so ist. Siehe Appnotes AVR040 und AVR042
4. Dann vermisse ich Bilder viele Bilder, die man evtl. auch nach
Nachfrage von Atmel usw. verwenden kann. z.B. um die Wirkung der Kerkos
an den Versorgungspins darzustellen. In den oben genannten Appnotes gibt
es schon Bildchen die die Stromimpulse zeigen. Auch andere Fehler würde
ich mit einem kleinem Oszibild untermauern z.B. einen schwingenden
Linearregler, was der Anfänger mit seinem Multimeter schwer zu Gesicht
bekommt.
5. Ein paar Anfängerhürden würde ich schon besprechen. Ein kleines
Tastenzählprogramm inkl. Bild des Tastenprellens auf den Oszi oder zur
Not von Logic-analyzer. Hier sieht der Anfänger auch gleich wie
Hilfreich solches Werkzeug sein kann.
6. In einem AVR Buch würde ich nicht umbedingt dynamische RAM Bausteine
beschreiben oder kennt hier jemand der soetwas mit einem 8bit-µC
betreibt?
7. Zur Lebensdauer beim EEPROM würde ich mich etwas bedeckter halten.
Man kann vielleicht jede Zelle 100.000 mal neu Beschreiben aber es gibt
im KFZ Bereich schon Fahrzeuge aus den 80er und 90er Jahren die
EEPROM-Inhalte im Motorsteuergerät verlieren. Da war wohl die Simulation
doch nicht so gut.
8. Der Programmierhardware würde ich auch ein Kapitel widmen. z.B.
Kurschlussicherer Herstellertools wie AVRISP, nicht ganz so gut
geschütze Hardware wie der Dragon, Drittanbieter...
9. Den Erdkundeunterricht auf Seite 27 finde ich etwas überheblich.
10. Bezugsquelle China ist etwas ungenau, entweder direkt ein paar
Shops, Verkaufsplattformen wie Aliexpress.com nennen oder ganz
weglassen.
11. Den Stack würde ich mit einem Bild visualisieren, z.B. das
Memory-View Data in AVR-Studio hier sieht man ganz gut wie sich der
Stack von der einen Seite her Aufbaut und die Reservierten RAM Bereich
von der anderen Seite
12. Pullup Pulldown Widerstände mit Bild darstellen. Vorteile von
externen Widerständen
13. Ein paar Verknüfpungen würde ich schon mit Ergebniss darstellen
nicht einfach von einer UND oder ODER Verknüpfung sprechen sondern es
mit Ergebniss darstellen auch sieht es besser aus wenn du das ganze
einrahmst siehe
http://et-tutorials.de/wp-content/uploads/2010/07/AND.jpg und umbedingt
praktische Beispiele
and temp1, temp2
0b00001001
0b00001000
----------
0b00001000
14. Funktion und Limits der integrierten Dioden + ein paar
Enstörmaßnahmen. Siehe Mikrocontroller-Kochbuch
15. Dann beschreibst du die Vorteile der differentiellen Übertragung und
wie sich die Störeinstrahlung dort verhält das würde ich auch grafisch
darstellen.
16. Abschnitt Taktversorgung hier fehlt ein Quarzoszillator, zwar etwas
teurer als die anderen Taktquellen aber das Bauteil mit den geringsten
Abweichungen und ohne Probleme beim Anschwingverhalten.
17. Ansteuerung von externen Bauteilen wie Relais und Probleme die hier
entstehen können und Maßnahmen dagegen z.B. Freilaufdioden, Snubber...
18. Was mir überhaupt nicht gefällt ist die komische
Groß/Klein-Schreibweise wie z.B.
INT0 externer INTerrupt 0
TOSC1 Timer OSCillator; Anschluss 1
External ClocK
SCK (Spi ClocK)
19. Die ganzen Debugging Möglichkeiten gehen für den Anfänger etwas weit
das würde schon etwas nach hinten schieben im Buch.
20. Im Buch wird eine Schleife beschrieben dazu würde ich doch ein
klines Programm bringen. Assembler und C und evtl. noch in Basic da das
doch etwas Verbreitung geniest.
@ Thomas O. (kosmos)
Es gibt doch diese sehr gut verfügbaren ATmega328P Boards von eBay aus
China, von denen ich drei verlinkt habe.
1.) ATmega328P - Arduino Mini (kompatibel)
http://www.ebay.de/itm/351237508524
Preis: 1,82 Euro
2.) ATmega328P - Arduino Micro + USB (kompatibel)
http://www.ebay.de/itm/301292188973
Preis: 2,92 Euro
3.) ATmega328P - Arduino Duemilanove + USB (kompatibel)
http://www.ebay.de/itm/301149659327
Preis: 4,05 Euro
Die Version 1 ist für mini-Projekte gut wo man nur eine minimale Platine
benötigt.
Die Version 2 und 3 kann man direkt über USB versorgen und ist für
Anfänger ideal.
Er muss gar kein universales Buch schreiben, das ist für Anfänger auch
nicht günstig.
Wenn man erst mal geordnet erklärt bekommt was man mit dem einen Chip
alles machen kann und das dann mit der Zeit versteht, dann kann man sich
später auch anderen Chips widmen und das Studium der dazugehörigen
Datenblätter (sei es ein ATmega644P oder ein ATXmega128A4U) fällt dann
viel leichter.
Also ein Buch welches eine Wissensbasis aufbaut.
Wenn ich es dann wirklich verstanden habe und nicht mittendrin
abgesprungen bin weil ich es nicht durchsehe und denke "das ist viel zu
schwer", dann kaufe ich mir einen dicken Wälzer in dem alle möglichen
Funktionen aller möglichen AVR-8Bit-Controller drin steht.
Aber der Start kann ruhig durch einen einzelnen Chip initiiert werden.
Der ATmega8A wird ja wie ein ganz neuer Controller von Atmel unterstützt
und wird jetzt auch lange verfügbar sein.
Den Schwenk auf den ATmega328P würde ich aber trotzdem bevorzugen, so
kann man jemanden sagen: "Hier ist das Buch und hier im Internet kannst
du sehr billig alle Teile die du dafür brauchst kaufen."
Hier ist das Hauptboard (Arduino Micro + USB): 2,92 Euro/4,05 Euro
(siehe oben)
(auch wenn schon ein Bootlader auf dem Arduino drauf ist)
Ein USBasp-Programmer: 1,69 Euro
http://www.ebay.de/itm/291325525791
Hier ist ein Steckboard zum ausprobieren: 1,63 Euro
http://www.ebay.de/itm/290935235761
Hier sind 40 Verbindungskabel: 1,42 Euro
http://www.ebay.de/itm/300895459196
Summe: 5,97 Euro oder 7,10 Euro
Dazu dann noch ein paar LEDs, Widerstände, Taster und wer Lust hat kann
sich irgend welche von den Erweiterungsplatinen kaufen die alle nur um
die 1 - 2 Euro kosten.
Das ist ein richtig billiger und einfacher Start in die Welt der
Mikrocontroller.
Wenn man schnell ein paar funktionierende Teile (aus China) bekommt und
dann noch ein Buch hat welches die Funktionen in deutsch und mit einem
klaren Verlauf erklärt, so dass man sich immer an einem roten Faden
entlang hangeln kann, wird einem der Einstieg sehr leicht gemacht.
Als erstes Programm würde ich KEIN ASM-Programm , sondern eine normales
C-Programm nutzen.
ASM schreckt zu sehr ab und ist auch nicht sinnvoll für einen Anfänger.
Man könnte nach dem C-Programm oder zum Schluss noch ein kleines
LED-Blink-Programm in ASM schreiben damit man es mal gezeigt hat, aber
sowas würde ich dann lieber in einem Buch für fortgeschrittene sehen.
Atmega8 Atmega8 schrieb:> dann noch ein Buch hat welches die Funktionen in deutsch und mit einem> klaren Verlauf erklärt, so dass man sich immer an einem roten Faden> entlang hangeln kann, wird einem der Einstieg sehr leicht gemacht.
Dann kann man /dieses AVR-Buch/ aber grad neu schreiben. Ernsthaft.
> Als erstes Programm würde ich KEIN ASM-Programm , sondern eine normales> C-Programm nutzen.
Würde ich nicht, einfach weil auf dem Weg zum lauffähigen C-Programm
10000 Dinge schiefgehen können. Nicht mal unbedingt, weil es C ist,
sondern weil die Toolchain so lang ist.
Bei einem einfachen Assembler geht ASM rein und es kommt HEX raus,
fertig. Bei C muss die Toolchain korrekt funktionieren, dann
compilieren, linken, Sektionen extrahieren und HEX bauen. Vermutlich
noch mit einem Makefile. Viel zu viel Unbekanntes, das der Anfänger
nicht reparieren kann, wenns ins Stocken kommt. Möglicherweise total
kryptische Fehlermeldungen beim Compilieren, weil ein Semikolon fehlt
usw.
Es gibt wunderbare kleine Assembler, die sogar verständliche
Fehlermeldungen produzieren.
> ASM schreckt zu sehr ab und ist auch nicht sinnvoll für einen Anfänger.
Eine intuitivere Plattform als 8-Bit-AVR wirst du für Assembler nicht
finden.
Thomas O. schrieb:> 18. Was mir überhaupt nicht gefällt ist die komische> Groß/Klein-Schreibweise wie z.B.> INT0 externer INTerrupt 0> TOSC1 Timer OSCillator; Anschluss 1> External ClocK> SCK (Spi ClocK)
Aber mir. Es macht nämlich deutlich, WAS die Abkürzungen bedeuten, bzw.
wie sie entstanden sind.
MfG Paul
jdhenning schrieb:> 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.
Aber das ist doch genau ein Kritikpunkt an Deinem Buch, der hier schon
von mehreren Leuten (offensichtlich auch Pädagogen) fast schon
flehentlich an Dich herangetragen wird. Ein Auszubildender wird den
Einstieg in das Thema Mikrocontroller mit Deinem Buch kaum schaffen.
Bitte folge mal dem von Harald Nagy genannten Link. Hier wird das
geboten, was man als Auszubildender braucht, der mit dem Datenblatt
alleine nicht klar kommt:
Harald Nagy schrieb:> Jetzt musste ich doch nachsehen. Ich meinte dieses> http://www.weigu.lu/a/jdhenning schrieb:> 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.
Das erklärt natürlich einiges. Dein Buch ist wohl weniger als Leitfaden
gedacht, sondern eher als Ergänzung zu den Basics, die man sich über
Tutorials aneignen kann. Das hättest Du vielleicht mal früher verlauten
lassen sollen. Was das angeht, bist Du mit Deinem Buch auf einem guten
Weg.
Da sind wir gerade bei einem guten Thema!!
Gerade dieser C Mißt geht einem als Afgänger mal voll auf den.... bevor
man das alles mal ans laufen hat!
Außer man verwendet das neue Atmel Studio, damit geht es vermutlich
einfacher, aber gerade weil man an dem Buch sowieso nicht viel verdient,
würde ich überlegen mit Mikroe zusammen zu arbeiten und im Buch somit
auf den mikroe Kompiler aufzusetzen! So hat der Anfänger auch gleich die
Ausfahl von Basic, Pascal und C
Und Du bekommt von mikroe pro verkauften Buch nochmal einen Betrag X.
Für die ersten Versuche reicht die kostenlose Version von mikro e somit
alles gut.
Soll mehr gemacht werden kann der Anfänger entscheiden ob er Lust auf
dieses freie C gefrickel hat oder eine Vollversion von mikroe erwirbt
z.B.
So ist es eine WIn Win Situation für alle Du bekommt was von Mikro e
mikroe bekommt neue kunden und der Anfänger hat einen bezahlbaren
Compiler mit vernünftiger Oberflächer und einen super Einstieg um später
auf beliebe Controller zu wechseln und kann immer bequem alles protieren
@Conny Phi (conny_phi)
ich denke das Buch sollte erstmal nicht überhand nehmen, einm Buch
wächst mit der Zeit, also wäre das in zei Jahren dann in einem anderen
Band möglich bis es ein richtig dicker Wälzer wird von A-Z.
Und da ist dann auch der neue AtXmega oder so auf dem Cover :-)
Hallo ATmega8,
danke für deinen langen Post. Einige Leute sind hier ja der Meinung,
dass so ein Buchprojekt sowieso völlig sinnfrei sei, weil nur noch ü50
Bücher lesen und alle anderen sich ihre Informationen aus dem Internet
holen. Diese Ansicht ist ja auch nicht völlig falsch, denn ein Großteil
meiner Informationen habe ich ja auch aus dem Internte (zum Beispiel die
Datenblätter). Die große Schwierigkeit hierbei ist das Auffinden von gut
aufbereiteter Information (sogar hier, in einem Fachforum, hat der
Glossar nur 106 Einträge, von denen allerdings nur ca. 50 für MCUs
relevant sind).
Auf jeden Fall kann man voraussetzen, dass der potentielle Leser einen
Rechner mit Internetzugang hat (sonst könnte er sich nicht das Atmel
Studio besorgen). Das heißt einerseits, dass er sich zusätzliche
Informationen besorgen kann (etwa, weil ich irgendwas nicht gut
beschrieben habe oder nicht ausreichend) und er findet problemlos
Beispielprogramme (da sei alleine schon auf die Sammlung hier im Forum
verwiesen). Aus der Hüfte geschossen würde ich vermuten, dass es
mindestens 50 mal mehr Beispielprogramme gibt denn auch nur halbwegs
brauchbare Erklärungen.
Also dachte ich mir, dass man vielleicht beide Welten ein wenig
zusammenführt; eine (hoffentlich) gute Beschreibung auf Papier und
Beispielprogramme aus dem Internet (die kann man dann auch gleich per
Copy and Paste übernehmen). Und es schont den Waldbestand.
Für in reines Papierprojekt sind deine Vorschläge gut (und bitte vergiss
nicht, dass ich ein fauler Mensch bin; wenn andere schon wunderschöne
Beispielprograme geschrieben haben, warum sollte ich das dann auch noch
machen?).
Zusätzlich muss man auch unterscheiden, welches die Zielgruppe ist. Ein
15-jähriger wird noch am ersten Nachmittag ein Erfolgserlebnis haben
wollen, sonst findet er das Thema langweilig. Meine Zielgruppe sollen
Leute sein, die sich aus einer Projektidee heraus mit MCUs beschäftigen
wollen. Die brauchen keinen schnellen Erfolg, sondern die wollen wissen,
was man alles mit MCUs machen kann und ob sich ihre Projektidee mit so
einem Teil umsetzen lässt und falls ja, wie. Wenn man alleine den ganzen
Bereich des Modellbaus betrachtet, dann weiß man, dass diese Leute eine
Engelsgeduld haben.
Danke für deine Zeit und Mühe
Jürgen
Hallo Harald.
Harald Nagy schrieb:> sowie das gar nicht so schlechte Buch Make AVR Programming. Ist halt> englisch, aber das sollte doch heutzutage kein Problem mehr sein.
Wenn du in diesem Thread mal auf Bearbeiten->suchen gehst und 'Elliot'
eingibst, dann findest du einen Eintrag von mir, dass ich das Buch
gelesen habe und es mir nicht so gefiel. Dann gibt es einen Eintrag von
Elliot selbst, in dem er mich fragt, was mir denn nicht so gefallen
hatte und meine Antwort darauf. Sein Buch ist für bastelwütige Teenies
und entspricht vom Stil und der inhaltlichen Tiefe genau dieser
Zielgruppe. Es ist also kein schlechtes Buch, sondern spricht eine
Zielgruppe an, die ich nicht ansprechen will (und übersetzen würde ich
das Buch nur für viel, viel Geld).
Ich weiß, dass es einige Assembler-Puristen gibt. In der Richtung denke
ich pragmatisch; es gibt einige ganz wenige Fälle, in denen man
tatsächlich auf Assembler zurück greifen muss, aber im allgemeinen
verzehnfacht man nur den Zeitbedarf, bis ein Programm fehlerfrei läuft.
Jürgen
Das meinst du jetzt nicht ernst oder? Warum also sollte man dein Buch
kaufen? Die Infos finde ich im Datenblatt, Beispiele soll ich mir in
Netz zusammen suchen, Erklärungen soll ich mir vlt auch noch selber
zusammenreimen? Also brauch ich dann dein Buch eh nicht!?
Und denkst du nicht, dass auch jemand, der ein Projekt umsetzen will,
ohne garantierte Erfolgserlebnisse (und die gelingen nur mit gut
konstruierten Beispielen) sehr schnell frustriert aufgibt?
btw ich stimme zu, dass das Wörtchen ICH sowie Wertungen und persönliche
Meinungen in einem derartigen Buch nichts zu suchen haben. Aufgabe eines
solchen Buches ist es doch den Leser die Befähigung zu vermitteln sich
seine eigene Meinung zu bilden.
Nase schrieb:> Nerds sind auch keine kompletten Fachidioten, wie du auf Seite 134> schreibst. Dagegen ist das enthaldende Kapitel komplett idiotisch, denn> außer wunderbaren Suchfunktionen in Editoren gibt es auch schon> wunderbare Werkzeuge wie doxygen zur Dokumentation. Und die erwähnst du> garnicht.
doxygen als Suchhilfe im Internet? ICh hatte gar keine Ahnung, dass das
geht. Wenn du darüber ein Tutorial schreibst nehme ich den Link gerne in
das Buch auf, denn damit würde man jede Menge Leute glücklich machen.
Jürgen
jdhenning schrieb:> doxygen als Suchhilfe im Internet?
Du sprachst in besagtem Kapitel ja nicht von einer Suchfunktion im
Internet, sondern von der Suchfunktion im Editor. Mit der du dich durch
den Quelltext hangelst, weil du die Dokumentation jeweils vor die
Funktionen schreibst.
jdhenning schrieb:> (und bitte vergiss> nicht, dass ich ein fauler Mensch bin; wenn andere schon wunderschöne> Beispielprograme geschrieben haben, warum sollte ich das dann auch noch> machen?)
(Und warum schreibst du dann so krampfhaft an deinem Buch? Andere haben
auch schon wunderschöne Bücher drüber geschrieben...)
Hallo Thomas,
auf jeden Fall schon mal vielen Dank für die viele Zeit, die du dir
genommen hast.
Thomas O. schrieb:> 1. Da du ja an hohen Verkaufszahlen interessiert sein wirst. Solltest du> nicht unnötigerweise die Zielgruppe verkleinern,...
Wurde hier schon diskutiert und ich bin aktuell dabei, den ATmega328
durch zu arbeiten. Wenn das auch nur halbwegs passt (und danach sieht es
aktuell aus) dann kommt der mit dazu. Lieber ein zwei Sachen richtig,
als zu viele Themen anzureißen.
> 2. Um für gleiche Bedingungen so sorgen würde ich den Aufbau eines> stabilisierten Netzteils einfügen.
Ich dachte mir, für die allerersten Gehversuche reicht auch die
Versorgung vom USB. Es wurd hier schon (zu recht) angemahnt, ich solle
Entstörkondensatoren und auch eine Induktivität zwischen VCC und AVCC
einfügen. Das kommt.
> 4. Dann vermisse ich Bilder viele Bilder, die man evtl. auch nach> Nachfrage von Atmel usw. verwenden kann. z.B. um die Wirkung der Kerkos> an den Versorgungspins darzustellen. In den oben genannten Appnotes gibt> es schon Bildchen die die Stromimpulse zeigen.
Ich habe da einen schönen Artikel gefunden über die pulsartigen
Belastungen des Netzteils im Rhytmus des Systemtaktes. Kommt.
> 5. Ein paar Anfängerhürden würde ich schon besprechen. Ein kleines> Tastenzählprogramm inkl. Bild des Tastenprellens auf den Oszi oder zur> Not von Logic-analyzer. Hier sieht der Anfänger auch gleich wie> Hilfreich solches Werkzeug sein kann.
Die Idee ist gut.
> 6. In einem AVR Buch würde ich nicht umbedingt dynamische RAM Bausteine> beschreiben oder kennt hier jemand der soetwas mit einem 8bit-µC> betreibt?
Die beiden Absätze zum DRAM sind nur der Vollständigkeit halber drin und
weil auch jemand auf die Idee kommen könnte externes RAM benutzen zu
wollen, das nicht über TWI oder ähnlich angesteuert wird.
> 7. Zur Lebensdauer beim EEPROM würde ich mich etwas bedeckter halten.> Man kann vielleicht jede Zelle 100.000 mal neu Beschreiben aber ...
Das sind offizielle Herstellerdaten, da brauche ich mich nicht zu
bedecken.
> 8. Der Programmierhardware würde ich auch ein Kapitel widmen. z.B.> Kurschlussicherer Herstellertools wie AVRISP, nicht ganz so gut> geschütze Hardware wie der Dragon, Drittanbieter...
Seite 23 bis 26.
> 9. Den Erdkundeunterricht auf Seite 27 finde ich etwas überheblich.
Was ist daran überheblich?
> 10. Bezugsquelle China ist etwas ungenau, entweder direkt ein paar> Shops, Verkaufsplattformen wie Aliexpress.com nennen oder ganz> weglassen.
Ich habe mittlerweile das Kapitel mit den (hoffentlich) hilfreichen
Links um einige einschlägige Bezugsquellen (z.B. ebay, pollin, Reichelt)
erweitert plus eine Erklärung, was man zolltechnisch beachten muss, wenn
man im Ausland bestellt.
> 11. Den Stack würde ich mit einem Bild visualisieren, z.B. das> Memory-View Data in AVR-Studio hier sieht man ganz gut wie sich der> Stack von der einen Seite her Aufbaut und die Reservierten RAM Bereich> von der anderen Seite
Kommt, da schon geplant.
> 12. Pullup Pulldown Widerstände mit Bild darstellen. Vorteile von> externen Widerständen
Welchen Vorteil siehst du bei externen Widerständen?
> 13. Ein paar Verknüfpungen würde ich schon mit Ergebniss darstellen> nicht einfach von einer UND oder ODER Verknüpfung sprechen
Seite 37 bis 42
> auch sieht es besser aus wenn du das ganze einrahmst
Es ist noch ein Rohmanuskript, weshalb man auch noch Schusterjungen und
Hurenkinder findet.
> 14. Funktion und Limits der integrierten Dioden + ein paar> Enstörmaßnahmen. Siehe Mikrocontroller-Kochbuch
siehe 2.
> 15. Dann beschreibst du die Vorteile der differentiellen Übertragung und> wie sich die Störeinstrahlung dort verhält das würde ich auch grafisch> darstellen.
Kommt voraussichtlich nicht.
> 16. Abschnitt Taktversorgung hier fehlt ein Quarzoszillator, zwar etwas> teurer als die anderen Taktquellen aber das Bauteil mit den geringsten> Abweichungen und ohne Probleme beim Anschwingverhalten.
Seite 116. Für erste Gehversuche reicht der interne RC-Kreis völlig aus
und man muss den Anfänger auch nicht gleich auf die Fuses loslassen (er
wird da irgendwann dran gehn, aber je später desto besser).
> 17. Ansteuerung von externen Bauteilen wie Relais und Probleme die hier> entstehen können und Maßnahmen dagegen z.B. Freilaufdioden, Snubber...
Das hebe ich mir für später auf.
> 18. Was mir überhaupt nicht gefällt ist die komische> Groß/Klein-Schreibweise wie z.B.> INT0 externer INTerrupt 0> TOSC1 Timer OSCillator; Anschluss 1> External ClocK> SCK (Spi ClocK)
Die gefällt mir auch nicht, aber wie soll man sonst aufzeigen, wie Atmel
auf die Abkürzungen gekommen ist.
> 19. Die ganzen Debugging Möglichkeiten gehen für den Anfänger etwas weit> das würde schon etwas nach hinten schieben im Buch.
Aus beruflicher Erfahrung weiß ich, dass 40 bis 80% (je nachdem, wie
viel Administratives man zu erledigen hat) der Zeit beim Programmieren
mit Fehlersuche verbracht wird. Das Kapitel gehört eigentlich weiter
nach vorne.
> 20. Im Buch wird eine Schleife beschrieben dazu würde ich doch ein> klines Programm bringen. Assembler und C und evtl. noch in Basic da das> doch etwas Verbreitung geniest.
Ich setze C-Kenntnisse beim Leser voraus.
Danke für die viele Arbeit und ein frohes neues Jahr
Jürgen
Hallo ATmega8,
Atmega8 Atmega8 schrieb:> Als erstes Programm würde ich KEIN ASM-Programm , sondern eine normales> C-Programm nutzen.> ASM schreckt zu sehr ab und ist auch nicht sinnvoll für einen Anfänger.
Dass ASM für Anfänger nicht so geeignet ist und sogar abschreckend
wirken kann, sehe ich genauso. Aber das Progrämmchen ist so kurz und gut
dokumentiert, dass ich da keine Gefahr sehe.
Danke für die Links (ich habe anscheinend zu teuer eingekauft), aber
genau die Teile meine ich. Es ist nur schade, dass Links auf ebay-Seiten
so vergänglich sind, sonst hätte ich sie glatt übernommen.
Auch wenn man 20 Euro ausgeben muss, das teuerste am Einstieg wird ein
gutes Buch sein oder man bezahlt mit seiner Zeit.
Gruß
Jürgen
Conny Phi schrieb:> jdhenning schrieb:>> 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.>> Das erklärt natürlich einiges. Dein Buch ist wohl weniger als Leitfaden> gedacht, sondern eher als Ergänzung zu den Basics, die man sich über> Tutorials aneignen kann. Das hättest Du vielleicht mal früher verlauten> lassen sollen. Was das angeht, bist Du mit Deinem Buch auf einem guten> Weg.
Tschuldigung (ich hätte es gleich im einleitenden Post schreiben sollen)
Gruß Jürgen
Tom schrieb:> Da sind wir gerade bei einem guten Thema!!> Gerade dieser C Mißt geht einem als Afgänger mal voll auf den.... bevor> man das alles mal ans laufen hat!> Außer man verwendet das neue Atmel Studio, damit geht es vermutlich> einfacher, aber gerade weil man an dem Buch sowieso nicht viel verdient,> würde ich überlegen mit Mikroe zusammen zu arbeiten und im Buch somit> auf den mikroe Kompiler aufzusetzen!
Anfangs hatte ich vor, ein längeres Kapitel über die GNU-Toolchain zu
schreiben, kam dann aber zu dem Ergebnis, dass die pure Toolchain viel
zu anspruchsvoll ist, als dass man sie einem Anfänger zumuten dürfte. So
gesehen hat sich natürlich das Atmel-Studion angeboten, denn das gibt es
nicht nur für Windows sondern auch für Linux, sogar den Mac und ist
kostenfrei.
Das Problem mit Mikroe ist, dass ich es nicht kenne und folglich will
ich da auch keine Wertung machen.
Gruß
Jürgen
Harald Nagy schrieb:> Warum also sollte man dein Buch> kaufen? Die Infos finde ich im Datenblatt
Wenn die Info im Datenblatt so aufbereitet wäre, dass man sie auch ohne
einen zweiwöchigen Einführungskurs verstehen könnte, dann wäre das Buch
in der Tat sehr entbehrlich. Aber dann hätte ich mir auch nicht so viel
Arbeit gemacht.
Nase schrieb:> Du sprachst in besagtem Kapitel ja nicht von einer Suchfunktion im> Internet, sondern von der Suchfunktion im Editor. Mit der du dich durch> den Quelltext hangelst, weil du die Dokumentation jeweils vor die> Funktionen schreibst.
Ich habe noch mal mit der Suchfunktion im Text nach dem Wort
Suchfunktion gesucht und es kommt lediglich in zwei Zusammenhängen vor.
Einmal die Suchfunktion vom Betriebssystem nach dem Speicherort in
Dateien und zum anderen die Suchfunktion in verketteten Listen im
Zusammenhang mit Call-Back-Funktionen. Ich habe also keine Ahnung, was
du meinst da gelesen zu haben.
> (Und warum schreibst du dann so krampfhaft an deinem Buch? Andere haben> auch schon wunderschöne Bücher drüber geschrieben...)
Dann gib mal 'ne Liste (aber wiederhole bitte keine Nennungen aus diesem
Thread).
jdhenning schrieb:> Atmel-Studion angeboten, denn das gibt es> nicht nur für Windows sondern auch für Linux,
Ähhh... bist du sicher? Soweit ich weiss basiert das Atmel-Studio auf
Visual Studio (urgs) und deshalb kein linux?
Oder verwechsle ich da grad was?
Michael Reinelt schrieb:> jdhenning schrieb:>> Atmel-Studion angeboten, denn das gibt es>> nicht nur für Windows sondern auch für Linux,>> Ähhh... bist du sicher? Soweit ich weiss basiert das Atmel-Studio auf> Visual Studio (urgs) und deshalb kein linux?>> Oder verwechsle ich da grad was?
Exakt.
Harald Nagy schrieb:> Das Studio gibt es nur für Windows. Allein die Toolchain gibt es quasi> für alle Systeme auf die der gcc portiert wurde...
Der Profiautor Jürgen verwechselt halt gerne mal IDE und Toolchain. Oder
er hat zumindest Probleme die Unterschiede sprachlich exakt
darzustellen. Fatal, gerade wenn man Anfängern was beibringen will. Das
geht nicht, wenn man selbst keinen Überblick über das Thema hat. Daher
auch meine Aussage mit "Kraut und Rüben". Das geht im Buch ja auch
dauernd so. Alles wird mit allem gemixt und verquirlt. Evt. erst mal die
eigenen Gedanken ordnen, dann andere Belehren.
jdhenning schrieb:> Ich habe also keine Ahnung, was> du meinst da gelesen zu haben.
Ich meine das, was ich meinem Ursprungsbeitrag sogar mit Seitenangabe
bezeichnet habe:
Nase schrieb:> Nerds sind auch keine kompletten Fachidioten, wie du auf Seite 134> schreibst. Dagegen ist das enthaldende Kapitel komplett idiotisch, denn> außer wunderbaren Suchfunktionen in Editoren gibt es auch schon> wunderbare Werkzeuge wie doxygen zur Dokumentation. Und die erwähnst du> garnicht.
Und ich möchte nochmal mit Nachdruck sagen: Nimm die ganzen wertenden
Passagen aus deinem Buch! Einerseits gehört sowas nicht in ein Fachbuch.
Wenn überhaupt gehören da Erklärungen hinein, wie es zu vermeintlich
'komischen' Dingen komt.
Und Andererseits bist du offenkundig nun wirklich nicht in der richtigen
Ausgangsposition, um solcherlei Wertungen von dir zu geben.
Michael Reinelt schrieb:> Hast du das ausprobiert?>> Soweit ich weiss ist das nur die Toolchain (command line), kein Studio
Du hast recht! Es ist nur die Toolchain.
Nase schrieb:> Und ich möchte nochmal mit Nachdruck sagen: Nimm die ganzen wertenden> Passagen aus deinem Buch! Einerseits gehört sowas nicht in ein Fachbuch.> Wenn überhaupt gehören da Erklärungen hinein, wie es zu vermeintlich> 'komischen' Dingen komt.
Wie z.B. der Kommentar zum 'URSEL'-Bit und der doppelten
Adressenbelegung. Das hat schon seinen Sinn und ist keine Schikane der
bösen Atmel-Ingenieure, um den User zu ärgern.
Der Sinn ist zwar nicht auf den ersten Blick erkennbar, aber von
jemandem, der ein Buch über diesen Controller schreibt, erwarte ich
schon, dass er das weiss und dem geneigten Leser dies auch mitteilt.
mfg.
6. auch wenn jemand eines externes RAM ansteuern will das nicht per SPI
sondern parallel dranhängt so wird das sicherlich kein dynamisches RAM
sein das man auffrischen muss, sondern ein statisches RAM. Da also kaum
jemand so ein DRAM mit einen 8bit AVR ansteuern wird ist es die
Erwähnung nicht wert.
8. Wenn du da von Debugging spricht sollte JTAG oder DebugWire
auftauchen du spricht nur das es nicht alle ISP können.
9. Siehst so aus als ob du zeigen wolltest was du alles weist.
12. The simplest method to ensure a defined level of an unused pin, is
to enable the internal pullup. In this case, the pullup will be disabled
during reset.
16. Wollte nur sagen, wenn du schon andere Taktquellen nennst, würde ich
auch den Quarzoszillator nennen und seine Vorteile gegenüber dem Quarz
mit den Kondensatoren wo es öfter mal zu Problemen beim Anschwingen
kommt. Aber gerade wenns um die serielle Übertragung geht fällt der
Interne RC Takt schnell flach.
18. Finde ich nicht wichtig weil man eh keinen Einfluss drauf hat. Zudem
du die Abkürzungen auch unterschiedlich auslegst
SCK (Spi ClocK)
SCK Serial Clock
19. Dann debugge am praktischen Beispiel.
20. Ein Anfänger wird selten C-Kenntnisse mitbringen
Nase schrieb:> Nase schrieb:>> Nerds sind auch keine kompletten Fachidioten, wie du auf Seite 134>> schreibst. Dagegen ist das enthaldende Kapitel komplett idiotisch, denn>> außer wunderbaren Suchfunktionen in Editoren gibt es auch schon>> wunderbare Werkzeuge wie doxygen zur Dokumentation. Und die erwähnst du>> garnicht.
Wikipedia sagt: Nerd [nɜːd] (engl. für Fachidiot, Computerfreak,
Sonderling, Streber / Geek, Außenseiter).
Du hast recht, da steht nichts von komplett; wird aber, insbesondere im
amerikanischen Englisch, exakt so benutzt.
Ich schreibe auch nichts über 'git'. Könnte Gründe haben. Einer davon
ist, dass ein MCU-Anfänger wohl kaum ein Projekt anfangen wird, bei dem
er derartige Werkzeuge überhaupt sinnvoll einsetzen könnte. Deshalb habe
ich auch nichts über Netzpläne geschrieben.
Wenn der Verlag sagt, dass solche Wertungen nicht in das Buch hinein
gehören, dann werden die wohl verschwinden (schließlich machen die Satz
und Layout). Ich nehme sie nicht raus.
P.S. Dass ich die 'Suchfunktionen' nicht mit der Suchfunktion gefunden
hatte, lag an einem Copy & Paste, bei dem hinter 'Suchfunktion' sich
noch ein (unsichtbares) Leerzeichen versteckt hatte. Soll nicht wieder
vorkommen.
Hallo Thomas.
Thomas O. schrieb:> 6. auch wenn jemand ein externes RAM ansteuern will das nicht per SPI> sondern parallel dranhängt so wird das sicherlich kein dynamisches RAM> sein das man auffrischen muss, sondern ein statisches RAM. Da also kaum> jemand so ein DRAM mit einen 8bit AVR ansteuern wird ist es die> Erwähnung nicht wert.
Das ist genau der Punkt. Jemand, der das weiß, wird es sicherlich nicht
machen.
> 8. Wenn du da von Debugging spricht sollte JTAG oder DebugWire> auftauchen du spricht nur das es nicht alle ISP können.
Genau, denn mit dem Text habe ich mich auf den ATmega8 (und jetzt
zusätzlich den ATmega328) beschränkt, folglich ist die Erwähnung, dass
es sowas wie JTAG auch noch gibt, völlig hinreichend. debugWIRE wird
jetzt rein kommen, aber ich fürchte, da werde ich keine lobenden Worte
für finden können.
> 9. Siehst so aus als ob du zeigen wolltest was du alles weist.
Du meinst, man kann mit dem Wissen, dass man über eBay auch Bauteile aus
China bestellen protzen? 1. unwahrscheinlich und 2. bin ich aus dem
Alter raus.
> 12. The simplest method to ensure a defined level of an unused pin, is> to enable the internal pullup. In this case, the pullup will be disabled> during reset.
Und das ist ein Vorteil von externen Widerständen?
> 18. Finde ich nicht wichtig weil man eh keinen Einfluss drauf hat. Zudem> du die Abkürzungen auch unterschiedlich auslegst> SCK (Spi ClocK)> SCK Serial Clock
Datenblatt ATmega8:
S. 58 SCK (SPI Bus Master clock Input)
S. 59 SCK: Master Clock output, Slave Clock input
S. 230 Tab. 96 SCK Serial clock
S. 230 Serial Clock (SCK)
S. 232 SERIAL CLOCK INPUT (SCK)
Du meinst, ich sollte päpstlicher sein als Atmel?
> 20. Ein Anfänger wird selten C-Kenntnisse mitbringen
Da magst du recht haben, aber ein C-Tutorial gehört meiner Meinung nach
eindeutig nicht hier rein (1. weil es da etliche sehr gute Bücher und
Tutorials gibt; 2. weil das mindestens 100-150 Seiten mehr wären). Die
Kapitel 'Bitmanipulationen' und 'Das Betriebssystem des kleinen Mannes'
mussten rein, weil auch Leute, die seit Jahren in C programmieren, sowas
sehr wahrscheinlich zuvor nie (zumindest nicht in der Form) gemacht
haben und man das bei der Programmierung von MCUs wissen muss bzw.
wissen sollte.
Vielen Dank für die Zeit, die du dir nimmst. Gruß
Jürgen
Thomas Eckmann schrieb:> Wie z.B. der Kommentar zum 'URSEL'-Bit und der doppelten> Adressenbelegung. Das hat schon seinen Sinn und ist keine Schikane der> bösen Atmel-Ingenieure, um den User zu ärgern.>> Der Sinn ist zwar nicht auf den ersten Blick erkennbar, aber von> jemandem, der ein Buch über diesen Controller schreibt, erwarte ich> schon, dass er das weiss und dem geneigten Leser dies auch mitteilt.
Das ist mir schon klar, dass die keine Registeradresse mehr übrig hatten
und die Information irgendwie und irgendwo mit reinquetschen mussten.
Trotzdem ist das unsauberes Design und daher letztlich eine Zumutung für
die Nutzer. Das Recht, auf so etwas hinzuweisen, lasse ich mir nicht
nehmen.
Du schraubst deine Erwartungen an andere zu hoch. Wenn das Buch für
einen Neueinsteiger deutlich besser verstehbar ist als das Datenblatt,
dann habe ich einen hervorragenden Job gemacht. Höher liegen meine
Ansprüche nicht!
jdhenning schrieb:> Das ist mir schon klar, dass die keine Registeradresse mehr übrig hatten> und die Information irgendwie und irgendwo mit reinquetschen mussten.> Trotzdem ist das unsauberes Design und daher letztlich eine Zumutung für> die Nutzer. Das Recht, auf so etwas hinzuweisen, lasse ich mir nicht> nehmen.
Die Erklärung ist zu billig. Da steckt eine Kleinigkeit mehr dahinter,
die dieses "unsaubere Design" durchaus rechtfertigt.
mfg.
In dem Buch Mikrocomputertechnik mit Controllern der Atmel AVR-RISC
Familie von Günter Schmitt liest sich das völlig wertfrei.
"...... Da es auf der gleichen Adresse wie das Steuer-und Statusregister
UCSRC liegt, muss beim Zugriff auf das Baudratenregister das Umschaltbit
URSEL=0 sein."
Das Wort Interrupte ist ein Unding. Nenne das Interrupt(s).
Auch das Wort Sklave(n) ist schlecht. Nenne das Slave(s) wie in allen
anderen Büchern.
6. vergiss das mit dem DRAM es handelt sich ja um einen Abschnitte der
ein paar Begriffe erklärt. Bin das etwas schnell überflogen.
9. Hört sich das nicht etwas komisch an wenn ich irgendwo schreibe
Berlin(in Deutschland). Wenn ich nicht weiß nach was ich suchen muss
bringt mir die Ortsangabe in eBay herzlich wenig.
12. nein, der Vorteil ist, dass der Pin immer definiert liegt und sich
z.B. beim Programmieren nicht ändert. Angenommen man hat etwas
zeitkritisches wie eine Zündanlage programmiert und während der
Übertragung des Programms ins den µC löst man ungewollt Zündungen aus
oder die Zündspule wird länger als ein paar mSek angesteuert dann wirds
etwas heiß für die Schalttransistoren.
18. Dann verzichte doch zumindestens auf die Großschreibung mitten oder
am Ende des Wortes, macht Atmel ja auch nicht sieht einfach komisch aus.
Man erkennt das auch ohne die Großschreibung woraus die Abkürzung
gebildet wird.
jdhenning schrieb:> Wikipedia sagt: Nerd [nɜːd] (engl. für Fachidiot, Computerfreak,> Sonderling, Streber / Geek, Außenseiter).> Du hast recht, da steht nichts von komplett; wird aber, insbesondere im> amerikanischen Englisch, exakt so benutzt.
Das ist egal, du schreibst für den deutschen Sprachraum. Du hast in
Wikipedia bestimmt auch weitergelesen:
> Während der Begriff ursprünglich negativ [...] besetzt war, hat er sich> [...] zu einer selbstironischen Eigenbezeichnung gewandelt.
Und in en:
> Though originally derogatory, "Nerd" is a stereotypical term, but as> with other pejoratives, it has been reclaimed and redefined by some as> a term of pride and group identity.
Der Terminus Nerd ist heute nicht mehr unbedingt negativ belegt.
Außerdem solltest du bedenken, dass es hauptsächlich die Fachidioten
und Freaks sind, von denen du hier erwartest, dass sie dein Buch
kritisieren.
jdhenning schrieb:> Trotzdem ist das unsauberes Design und daher letztlich eine Zumutung für> die Nutzer.
Ich glaube nach wie vor nicht, dass DU in der Position bist, soetwas
bewerten zu können.
jdhenning schrieb:> Wenn der Verlag sagt, dass solche Wertungen nicht in das Buch hinein> gehören, dann werden die wohl verschwinden (schließlich machen die Satz> und Layout). Ich nehme sie nicht raus.
Warum noch gleich..? Ach genau, weil du ja gerade so viel Fachwissen
mitbringst, dass du es dir erlauben kannst, zu bewerten. SCNR.
Sorry, ich bin raus. Der Autor ist unwillig, selbst simpelste Dinge
umzusetzen. Daher vergeudete Zeit.
Guten Morgen,
hier hat sich ja irre was getan. Gesern habe ich mir die Mühe gemacht
und das ganze Buch gelesen (und nicht nur überflogen).
Anfänglich habe ich mir noch parallel Notizen gemacht es dann aber sein
lassen.
Jürgen hat genau DAS eine Problem, dass die Thematik in sich (auch wenn
viele der Experten - nicht ironisch gemeint - es anderst sehen) relativ
schwierig ist.
Für jemanden, der sich auskennt ist es immer einfach zu sagen: Dieses
oder jenes wäre wichtig.
Die Kunst (und ich selbst behersche sie absolut NICHT) besteht also
darin, vieles eigentlich wichtige weg zu lassen. Bei vielen Dingen ist
es so, dass heutige Gegebenheiten aus der Historie erwachsen sind, hier
ist beispielsweise die Frage, wieviel Geschichte bringt man und was läßt
man weg.
Jürgen hat genau dieses Problem, was ist weg zu lassen und was nicht.
Witzig (und FÜR MICH am interessantesten) war die Abhandlung über
Projektmanagment bei der ich mich bis jetzt wirklich frage ob die
notwendig ist oder nicht (ich meine das wirklich noch als
"unentschieden" gefragt).
Tatsächlich habe ich eine solche Abhandlung noch nirgendwo im
Zusammenhang mit Microcontrollerentwicklung gelesen (und sorry, Jürgen,
hier stellt man eindeutig fest, was du arbeitest oder gearbeitet hast).
Wenn du dieses Kapitel zwingend erhalten magst, solltest du hier
allerdings nicht "springen", sondern Projektmanagment an den
"abstrakten" (ich finde kein passenderes Wort für die Beschreibungen für
die Entwicklungsarbeiten der Wirtschaft) Beispielen zu Ende bringen um
dann an einem konkreten Beispiel am Mikrocontroller zu zeigen.
An alle die "ich weiß etwas besser" Fraktion: Ihr habt sicherlich recht
wenn ihr etwas besser wisst (das ist nicht negativ gemeint), aaaaaaaaber
es wird immer jemanden geben, der auf einem Gebiet eines Themas etwas
besser weiß und ich glaube dass Jürgen genau aus diesem Grund sein
Manuscript deshalb hier eingestellt hat, damit wir quasi als Lektore
darüber lesen (und das ist absolut legitim).
Ich wünsche dir viel Glück mit deinem Buch und eine gewissen
"Schmerzfreiheit" wenn du nach langem überlegen dich dann doch von
Inhalten trennst, von denen du "weißt" dass sie aber wichtig sind.
Es ist einfach, ein gutes Buch als solches zu erkennen wenn man es
liest, aber es ist überaus schwierig ein solches zu schreiben.
Möchte man ein "perfektes" Buch schreiben, wird man nie fertig (smile,
warum kommt mir das bekannt vor).
(By the way: um meinen Auszubildenden die bestimmte Vorgänge zu erklären
bauen die nach wie vor wenn sie gut sind - und das auf einem Steckbrett
- erst ein Z80 Minimalsystem bestehend aus Taktgenerator, RAM, ROM auf,
ein 74573 Latch und ein 74245 Bustreiber fungieren als I/O Baustein. Für
das ROM steht ein EPROM Simulator zur Verfügung. Bisher waren fast alle
der Auszubildenden erst der Meinung, das wäre Technik der vergangenen
Tage - und eigentlich haben sie Recht - aber anschließend auch alle der
Meinung, dass es zum Lernen was da eigentlich vor sich geht gut
geeignet. )
In diesem Sinne,
Ralph
Thomas Eckmann schrieb:> Nase schrieb:>> Und ich möchte nochmal mit Nachdruck sagen: Nimm die ganzen wertenden>> Passagen aus deinem Buch! Einerseits gehört sowas nicht in ein Fachbuch.>> Wenn überhaupt gehören da Erklärungen hinein, wie es zu vermeintlich>> 'komischen' Dingen komt.
Dem möchte ich mich anschließen. Mit solchen Aussagen sollte man schon
im Alltag und erst recht im Beruf vorsichtig sein, in einem Lehrbuch hat
es Garnichts verloren.
Dieses generell abwertende Verhalten zu Datenblättern finde ich auch
unpassend. Wenn jemand schon mit den sehr übersichtlichen AVR
Datenblättern Schwierigkeiten hat, wird mit anderen uCs garnicht
klarkommen. Datenblätter sollen nicht schwafeln sondern kurz und
prägnant das Produkt so beschreiben, dass es für einen Entwickler
nutzbar ist.
Bei komplexeren Chips wird man sich noch durch Unmengen anderer
Dokumente wühlen müssen, da kann man bei den AVRs wirklich nicht
meckern.
Jürgen Henning schrieb:> Der „Request For Comments“ ist hiermit eröffnet!
Es ist bei technischen Büchern nicht verboten und im Gegenteil sogar
sehr vorteilhaft, wenn man für gleiche Sachen die gleichen Worte
verwendet. Das geht schon beim ersten Satz schief:
1
[Rückseite Cover]
2
Es hätte durchaus schönere Motive für das Cover gegeben, aber ich habe
3
aus gutem Grund das *Pinlayout* des ATmega8 in seiner Ausführung als DIP
4
genommen (der Atmega328 hat exakt das gleiche *Pin-Layout*
Zudem wäre es für den Anfänger wichtig, wenn hier genau der Begriff
verwendet würde, der sich später auch im Datenblatt findet: Pinout
Es sind viel zu wenige Bilder und Skizzen im Buch. Gerade Anfänger
brauchen einfache klare Skizzen zum Verstehen der Schaltungen und der
internen Vorgänge.
Im Kapitel 8.1 kommen z.B. ein paar Bilder mit dreieckigen und
rechtwinkligen Kurven, die ein Anfänger ohne weitere Erläuterungen
gerantiert nicht versteht.
Auf der Seite 26 fehlt mir für einen blutigen Anfänger auf jeden Fall
ein detailiertes Foto von einem Aufbau auf einem Steckbrett. Oder es
sollte ein skizziertes Steckbrett mit bunten Linien dargestellt sein.
Denn das, was da skizziert ist, ist 1. unvollständig (Blockkondensator)
und 2. können Anfänger nicht von schwarzen Linien auf reale Hardware
extrapolieren.
In dem Listing auf der Seite 110 (EEPROM_write) wäre es auch sinnvoll,
nur deutsche Kommentare zu verwenden. Zudem sind solche "Kommentare"
redundant und nichtssagend:
1
sbi EECR,EEMWR; set bit Master Write Enable im EECR
2
sbi EECR,EEWE; set bit Write Enable im EECR
Sinnvoller wäre es, den Vorgang zu beschreiben:
1
; EEPROM schreiben
2
sbi EECR,EEMWR; zuerst muss das Master Write Enable...
3
sbi EECR,EEWE; ...und dann gleich das Write Enable gesetzt werden
Und das hier auf Seite 116 ist sogar sachlich unrichtig:
1
Wenn man mit Quarzen oder Resonatoren arbeitet, dann braucht man
2
für die Zwischenspeicherung der Energie zwei Kondensatoren
Mich würde als Anfänger brennend interessieren, wozu der Takt nötig ist,
und was es für Auswirkungen hat, wenn er nich passt, und warum die
Programmierung des Controllers vom Takt abhängt...
Und das hier ist für mich der Aufruf zum "Verwendet das GOTO in C! Ohne
geht es nicht!". Und: "Blödmänner" gehören nicht in ein technisches
Buch. Zudem könnten es auch "Blödfrauen" sein...
1
Der Ausweg ist die Goto-Anweisung (nur Blödmänner schreiben Spagetticode;
2
allen anderen, die wissen, was sie da machen, deshalb die 'goto-Anweisung'
3
zu verbieten ist derbe Prinzipienreiterei!).
Zur Seite 119 auch noch ein Wort:
1
Programme, die (mehr oder weniger) linear durchlaufen werden, sind
2
meistens recht einfach zu kontrollieren. Anders sieht es aus, wenn man
3
etwa eine kompliziertere Steuerung programmieren will.
Sollte das bedeuten, dass ich bisher nur simple Steuerungen programmiert
habe, weil ich kein GOTO brauche? Ich bewerte das so:
1
Programme, die (mehr oder weniger) linear durchlaufen werden, sind
2
meistens recht einfach zu kontrollieren. Deshalb muss es das Ziel sein,
3
solche Programmstukturen zu erstellen.
4
Wenn man sein Programm aber schon so vermurkst hat, dass ein wilder
5
Programmsprung nötig ist, dann gibt es die Notnägel setjmp und longjmp.
jdhenning schrieb:> Weil so ein kleines Betriebssystem wahnsinnig praktisch ist...> wollte ich es gerne mit drin haben.
M.E. ist ein Multitasking-OS für einen so kleinen uC wie wenn ich einen
400PS Motor (=OS) auf ein 2CV-Fahrwerk (=uC mit 8k) montieren würde.
> Weil so ein kleines Betriebssystem wahnsinnig praktisch ist
Es wäre sinnvoller, wenn man eine vernünftige Programmstruktur mit
Hauptschleife und die Handhabung von Zustandsautomaten lehren würde.
Dazu kurze ISR und die Verwendung eines fortlaufenden Zählers für die
Systemzeit.
Damit habe ich Schülern auf einem Arduino erst eine Kreuzungsampel mit
Fußgängervorrang, danach ein langsam auslaufendes Glücksrad machen
lassen. Und zum Schluss haben wir uns überlegt, wie das "gleichzeitig"
auf einem uC laufen könnte. Und dieses "Multitasking"-System dann ganz
problemlos aufgebaut, indem die beiden Zustandsautomaten
(Ampel+Glücksrad) einfach hintereinander in der Hauptschleife aufgerufen
wurden...
Was mir dann noch aufgefallen ist:
Lothar Miller schrieb:> Was mir dann noch aufgefallen ist:jdhenningATjdhenningDOT de> 'AT' durch '@' ersetzen und 'DOT' durch '.'> In einem Buch? Ist das dein Ernst?
Was MIR aufgefallen ist: Das ist im Moment ein MANUSKRIPT, was man
herunterladen kann. Da würde ich meine Adresse auch nicht im Klartext
eintragen...
MfG Paul
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. Ich habe> bisher das Datenbuch zum ATmega328 nur überflogen und nur bis zur Seite> 80 durchgearbeitet.
Wie arbeitet man sowas denn durch?! Ich gehe einfach in das notwendige
Kapitel, wenn ich eine Peripherie benutzen will oder benutze die
Suchfunktion um bestimmte Daten zu suchen.
Das ist doch kein Roman...
> 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.
Wofür gibt es denn Atmels Migration Appnotes? Da sind ALLE Änderungen
zwischen den Chips drin. Und wie man sieht, sind das nicht viele.
http://www.atmel.com/images/doc2553.pdf> 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.
Ganz einfach zusammenfassend: Die ATmega88/168/328 Serie ist offiziell
(d.h. laut Atmel) der Nachfolger des ATmega8 und dazu in vielen
elektrischen Parametern besser. Das heißt, dass es irgendwann in naher
Zukunft dazu führen kann, dass der ATmega8 abgekündigt wird, weil es
einen (fast vollständig kompatiblen, besseren, Ersatztypen gibt). Und
dann wird der ATmega8 teuer und das Buch will niemand mehr.
Lothar Miller schrieb:> Es wäre sinnvoller, wenn man eine vernünftige Programmstruktur mit> Hauptschleife und die Handhabung von Zustandsautomaten lehren würde.> Dazu kurze ISR und die Verwendung eines fortlaufenden Zählers für die> Systemzeit.>> Damit habe ich Schülern auf einem Arduino erst eine Kreuzungsampel mit> Fußgängervorrang, danach ein langsam auslaufendes Glücksrad machen> lassen. Und zum Schluss haben wir uns überlegt, wie das "gleichzeitig"> auf einem uC laufen könnte. Und dieses "Multitasking"-System dann ganz> problemlos aufgebaut, indem die beiden Zustandsautomaten> (Ampel+Glücksrad) einfach hintereinander in der Hauptschleife aufgerufen> wurden...
SOWAS hätte ich mir damals mal gewünscht. Denn genau DAS ist es, was
heutzutage den Profi von dem Laien unterscheidet: Programmstruktur.
Hi Jürgen
Ich schreib es dir noch einmal, weil die Diskussion hier nie enden wird
und du dich immer tiefer in die Kritik bringst. Meine Empfehlung, leg
das Buch mindestens ein halbes Jahr beiseite, dann lies es. Wenn du als
Leser und nicht als Autor ein Buch liest, wirst du viele Kritikpunkte
unterstützen. Ich fang jetzt nicht auch noch damit an, auf dir
rumzuhacken, weil ich der Meinung bin, das der Ansatz gar nicht mal so
schlecht ist. Dir fehlt es an Übung, mit Schriften umzugehen, wobei ich
nicht Rechtschreibung und Stil meine. Ein Fachbuch darf nicht zur
Biografie oder zum Erlebnisroman abdriften. Aber einige Passagen sind da
nicht weit weg von und ehrlich gesagt, als neugieriger Technikfreak, der
sich ein Buch kauft, wäre ich bald gelangweilt. Schlimmer noch, schon
beim Lesen der ersten paar Zeilen, (und das tut man in Büchereien, wenn
die Coveroffen sind) würd ich es wieder weglegen. Du musst lenen, den
Blick des Lesers zu bekommen, dann verstehst du auch die viele Kritik.
Damit meine ich nicht: "Ein weiteres Buch über Mikrocontroller braucht
die Welt nicht" sondern :"mir ist zuviel Eigendarstellung enthalten".
Glaub mir, ich weiß, wovon ich rede. Als ich den Beitrag "keine Angst
vor Assembler" im Forum von AVR-Praxis aufgeschrieben habe, musste ich
zwischen durch auch immer wieder goße Zeiträume mit "Nichtstun"
einbruingen, um so einigermaßen auch für andere verständlich zu werden.
Also, Abstand zum Text, durchlesen und neu verfassen. So betrachtet,
werde ich da wohl drei- bis fünfmal neu angesetzt haben....
Und Schreibfehler.... na ja, die gehören auch dazu.
Gruß oldmax
Simon K. schrieb:> Wofür gibt es denn Atmels Migration Appnotes? Da sind ALLE Änderungen> zwischen den Chips drin. Und wie man sieht, sind das nicht viele.
Unsinn.
Da sind nicht alle Änderungen drin. In der Migration Note ist
beschrieben, welche Änderungen durchzuführen sind, um den Atmeg8 durch
den Atmega88 zu ersetzen. Der Funktionsumfang der Atmega48..328 ist
weitaus höher.
mfg.
Simon K. schrieb:> dass der ATmega8 abgekündigt wird, weil es> einen (fast vollständig kompatiblen, besseren, Ersatztypen gibt)
Genaugenommen wurde der ATmega8 schon längst NRND. Der Nachfolger heißt
ATmega8A. Aussage ATMEL Support, Stand 2012.
Jürgen Henning schrieb:> 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?
Soll ich überhaupt noch etwas dazu schreiben?
Ich bin jetzt mal dran gegangen wie ein Newbie. Ich habe eine
Projektidee und angenommen ich habe noch zwei Probleme: Serielle
Anbindung und AD-Wandlung.
Also suche ich zuerst nach RS232. Jetzt muss ich erst mal 7 Seiten Prosa
lesen und dann kommen noch die Registerbeschreibungen. Okay, wenn ich
jetzt geduldig alles gelesen habe, dann darf ich meine eigenen Versuche
starten. Wenn es nicht klappt, dann gilt der Satz von Kaptel 1.6.1:
(Zitat):"Wenn das soweit geklappt hat, dann sind die Hürden, an denen
viele Anfänger scheitern oder wochenlang verzweifeln, überwunden.
Ansonsten fröhliches Suchen & Fluchen."
Und das Wichtigste aus Kapitel 1.1: (Zitat)"Falls irgend etwas nicht so
funktioniert, wie es entsprechend meiner Erklärung sein sollte, dann
gilt:
Glauben sie mir nichts, RTFM!"
Und jetzt frage ich mich:"Weshalb habe ich denn das Buch gekauft? Im
Datenblatt steht das Selbe drin, funktionierenden Beispielcode muss ich
mir aus dem INet besorgen.
Also weiter zu ADC.
Was ich hier finde ist zwar weniger Prosa, aber auch wieder kein Hinweis
wie es geht sondern ebenfalls ein ins Deutsche übersetztes Datenblatt.
Also doch kein Buch für Newbies. Ausser der Newbie kann kein Englisch.
Doch meine Erfahrung mit jungen Leuten in der Ausbildung sagt mir, dass
in der heutigen Zeit praktisch jeder an der Elektronik interssierte auch
genügend gut Englisch versteht. Gut genug für ein Datenblatt auf jeden
Fall.
Wir leben nicht mehr vor 30 Jahren, der Autor anscheinend schon. Oder
wie soll ich den ständigen Hinweis auf ein Elektronikstudium vor 30
Jahren verstehen?
Okay, nachdem ich das Buch jetzt ja doch (fiktiv) gekauft habe schau ich
mal weiter im Inhaltsverzeichnis.
Kapitel 17: Einführung in die AVR-libc - das hört sich doch hilfreich
an!
Nur leider wird nur stichwortartig erklärt wofür die Libs da sind.
Manche einzelne Libs bzw. Inhalte werden etwas ausführlicher erklärt,
wohl diejenige welche der Autor mal benutzt hat. Was soll ich damit?
Weiter beim Kapitel 18: Projektmanagement (kurze Einführung)
Hallo, meine serielle Schnittstelle und mein ADC funktionieren noch
nicht und ich soll mein Mega8-Projekt mit mehreren anderen Programmierer
tagelang managen?
Achso, nein, darum geht es ja garnicht. Es geht darum dass der Autor
sein Wissen verbreiten möchte. Es hat zwar nichts mit dem auf dem Cover
abgebildeten Mega8 zu tun, aber wo soll er es sonst hinschreiben?
Kapitel 19: Debugging:
Juhu! Endlich kann ich meine RS232-Schnitstelle in Betrieb nehmen!
Kapitel 20: Mops
Seitenlange Prosa, welche kein Mensch braucht.
Der Autor weist ja glücklicherweise darauf hin, dass es jetzt zäh wird:
(Zitat): "Es dauert nur ein paar Seiten, dann können sie selbst
feststellen, ob Aufwand (und Speicherbelegung) den Aufwand wert sind
..... muss ich sie noch mit ein bisschen Theorie langweilen ... Bitte
machen sie sich keine Sorgen, wenn sie bei den Erklärungen zwischendurch
etwas verwirrt oder orientierungslos sind ..."
Nach vielen Seiten Prosa kommt dann die Begründung: (Zitat):"schließlich
will ich ja ein rudimentäres Multitasking-Betriebssystem vorführen und
sie
nicht langweilen" ... tja, schon zu spät.
Spätestens bei Kapitel 20.3 weiss ich nicht mehr worum es eigentlich
geht. Aber das ist kein Problem, denn einige Seiten vorher hat der Autor
ja schon gewarnt: (Zitat):"Bitte
machen sie sich keine Sorgen, wenn sie bei den Erklärungen zwischendurch
etwas verwirrt oder orientierungslos sind: Ich hatte bei der Entwicklung
der Routinen auch länger anhaltende Gedankenknoten"
Na da bin ich aber froh! Es ist also normal dass das Folgende kein
Mensch versteht. Irritiert bin ich trotzdem.
Na dann such ich doch lieber weiter weshalb mein ADC nicht funktioniert.
Da war doch irgendwo eine Liste der Register. So finde ich doch bestimmt
am einfachsten das Register für den ADC. Uuups. Im Kapitel 2 würde ich
es sofort finden, ja wenn ich die Adresse des Registers wüsste.
Hallo, klappts eigentlich? Die Adresse interssiert mich doch einen
Scheiss! Schon mal was von symbolischer Programmierung gehört? Achso,
die gab es vor 30 Jahren noch nicht. Na dann ....
Meine persöhnliche Meinung:
Für Beginner absolut unbrauchbar! Das Beste ist m.M. nach der Satz:
(Zitat)"Ansonsten fröhliches Suchen & Fluchen" Das nenne ich mal eine
richtig tolle Motivation! So wurden vielleicht die Lehrlinge vor 30
Jahren motiviert (wie komm ich nur darauf?).
Für Fortgeschrittene auch absolut unbrauchbar. Ein Fortgeschrittener
benötigt so ein Buch nur als Nachschlagewerk. Und dazu ist das
Verhältnis "Prosa/persöhnlicher Meinung : Information" zu beschissen.
Jeder der dieses Buch gekauft hat wird bald anfangen zu fluchen und dann
dem Tipp des Autors folgen: (Zitat):"eventuell selber ausprobieren; wenn
es nicht funktioniert, in der Bucht wieder verkaufen).
Es gäbe noch viel zu schreiben. Doch es ist sinnlos ....
mfG
Ulli B.
Paul Baumann schrieb:> Das ist im Moment ein MANUSKRIPT, was man herunterladen kann.
Wohlgemerkt in einem Manuskript, auf das der Zugriff mit einem Password
geschützt ist.
> Da würde ich meine Adresse auch nicht im Klartext eintragen...
So sollte ein Mensch, der ein Buch unter seinem eigenen Namenveröffentlichen will, aber nicht denken. Man kann ja z.B. einen
eigenen Mailaccount für dieses Buch einrichten...
Thomas Eckmann schrieb:> Simon K. schrieb:>> Wofür gibt es denn Atmels Migration Appnotes? Da sind ALLE Änderungen>> zwischen den Chips drin. Und wie man sieht, sind das nicht viele.>> Unsinn.> Da sind nicht alle Änderungen drin. In der Migration Note ist> beschrieben, welche Änderungen durchzuführen sind, um den Atmeg8 durch> den Atmega88 zu ersetzen.
Na gut, es sind eben alle Änderungen drin, die zwischen dem ATmega8 und
der ATmega88 Familie stehen, ohne die Sachen, die dort hinzugefügt
worden sind.
Was ich ausdrücken wollte ist, dass die Unterschiede zwischen den beiden
Chips gut dokumentiert sind und es eigentlich kein Problem ist, auf
diesen Umzusatteln. Die zusätzlichen Features in dem ATmega88 muss man
ja nicht nutzen. Von daher schränkt dies meinen Hinweis auf die
Migration Note keineswegs ein.
Siehe:
Simon K. schrieb:>> 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.> Wofür gibt es denn Atmels Migration Appnotes? Da sind ALLE Änderungen> zwischen den Chips drin. Und wie man sieht, sind das nicht viele.> http://www.atmel.com/images/doc2553.pdf
Buch ist so nicht besonders angenehm zu lesen ("Ich tue dies..", "Ich
bin der Meinung...", "Ich sehe dass so und so..",...) und hat mehr Text
als notwendig.
Für Anfänger sind imho die Tutorials auf dieser Seite + Datenblatt mehr
als ausreichend zum Einstieg. Wer damit klar kommt ist dann auch in der
Lage selbstständig weiter zu machen.
Paul Baumann schrieb:> Wenn Du Geld für Mumpitz ausgeben willst, ist dieses Buch das Richtige:> http://www.amazon.de/gp/product/3895760633?*Version*=1&*entries*=0
Das kann ich jetzt nicht beurteilen.
Aber in einer Rezension ist zu lesen:
"Schade: Nachdem vielversprechenden Titel war ich etwas enttäuscht! Im
Prinzip ist dieses Buch nichts anderes als die Übersetzung der
Datenblätter und des Befehlssatzes aus dem Englischen. Wer
Beispielschaltungen und Software für die AVR Controller sucht wird hier
kaum fündig!"
mfg.
Thomas Eckmann schrieb:> Da steckt eine Kleinigkeit mehr dahinter,> die dieses "unsaubere Design" durchaus rechtfertigt.
Da magst du (im Sinne des Produzenten) durchaus Recht haben, aber es ist
trotzdem eine Zumutung für den Nutzer.
Helmut S. schrieb:> Das Wort Interrupte ist ein Unding. Nenne das Interrupt(s).
Ist schon vor vier Tagen im ganzen Text berichtigt worden (auch im
Download).
> Auch das Wort Sklave(n) ist schlecht. Nenne das Slave(s) wie in allen> anderen Büchern.
Hatte ich vorab auch drüber nachgedacht und mich entschieden, ein wenig
deutsches Lokalkolorit in den Text zu bringen (was jetzt bitte nicht
nationalistisch aufgefasst werden sollte). Wenn das Leute lesen, die an
Slave gewöhnt sind, kommt ein kurzes Grinsen und der Text ist (trotz
aller meiner Faxen) sowieso schon dröge genug. Daher: Abgelehnt!
Trotzdem vielen Dank für deine Hinweise.
Jürgen
Thomas O. schrieb:> 12. nein, der Vorteil ist, dass der Pin immer definiert liegt und sich> z.B. beim Programmieren nicht ändert. Angenommen man hat etwas> zeitkritisches wie eine Zündanlage programmiert und während der> Übertragung des Programms ins den µC löst man ungewollt Zündungen aus> oder die Zündspule wird länger als ein paar mSek angesteuert dann wirds> etwas heiß für die Schalttransistoren.
Seite 55: Wenn die angeschlossene Hardware schon sofort nach dem
Einschalten einen bestimmten Spannungspegel benötigt, dann muss man
diesen durch einen externen Pull-up-Widerstand oder einen
Pull-Down-Widerstand erzwingen (Widerstände so hochohmig wie möglich,
damit später der Stromverbrauch klein bleibt).
Vielen Dank für deine Hilfe
Jürgen
Nase schrieb:> Sorry, ich bin raus. Der Autor ist unwillig, selbst simpelste Dinge> umzusetzen.
Nase wird es ja wohl nicht mehr lesen (wollen), aber ich habe hier schon
mehrfach geschrieben: "Ja, da hast du Recht!" oder "Gute Idee; vielen
Dank, das setze ich um!" oder "Uuups, eine echte Fehlleistung von mir!
Wird repariert!". Da habe ich überhaupt kein Problem mit, denn wer
arbeitet macht Fehler und ich bin keine Ausnahme!
Wenn Nase meint, man müsse das alles anders schreiben, dann muss ER das
anders schreiben und anschließend sehen, ob jemand das lesen will.
Manche nennen es 'Marktwirtschft' und andere 'Survival of the fittest'
und mir ist beides völlig egal: Ich fand das Datenblatt zum Verständniss
des ATmega8 echt Scheiße und ich hatte keine Bücher finden können, die
da deutlich besser waren. Also habe ich versucht, was besseres zu machen
(und mir aufgrund der Meinungen hier auch noch den ATmega328 aufgeladen;
könnte natürlich sinnvoll sein).
In diesem Sinne: Tschüs Nase
Jürgen
jdhenning schrieb:> Da magst du (im Sinne des Produzenten) durchaus Recht haben, aber es ist> trotzdem eine Zumutung für den Nutzer.
Nein. Das ist sehr wohl im Sinne des Nutzers. Insbesondere im Sinne des
ASM-Programmierers.
mfg.
Ralph S. schrieb:> Gestern habe ich mir die Mühe gemacht und das ganze Buch gelesen (und> nicht nur überflogen).
Ohne jeden Schleim: Das empfinde ich als Ehrung! Danke.
> Die Kunst (und ich selbst behersche sie absolut NICHT) besteht also> darin, vieles eigentlich wichtige weg zu lassen. Bei vielen Dingen ist> es so, dass heutige Gegebenheiten aus der Historie erwachsen sind, hier> ist beispielsweise die Frage, wieviel Geschichte bringt man und was läßt> man weg.
Meine Intention war: Wenn ich es (für einen Techniker) interessant
darstellen kann (ganz persönlich muss ich sagen, dass ich den
Geschichtsunterricht früher als ziemlich sinnfrei empfunden; nichts, was
Alexander der Große jemals gemacht hat, hat mir in meinem Leben auch nur
ein bisschen geholfen). Also Reduktion auf das, was wahrscheinlich noch
als interessant empfunden werden wird (wenn die Augenlider auf halb-acht
gehen, dann hat man übertrieben).
> Jürgen hat genau dieses Problem, was ist weg zu lassen und was nicht.> Witzig (und FÜR MICH am interessantesten) war die Abhandlung über> Projektmanagment bei der ich mich bis jetzt wirklich frage ob die> notwendig ist oder nicht (ich meine das wirklich noch als> "unentschieden" gefragt).
Letztlich gibt es exakt zwei Zielgruppen: Diejenigen, die sich mit MCUs
beschäftigen SOLLEN und die, die sich mit MCUs beschäftigen WOLLEN. Für
die erste Zielgruppe ist Projektmanagement absolut bedeutungslos, für
die zweite Zielgruppe könnte das Thema extrem interessant sein
(insbesondere, wenn auf 10 Seiten eingekürzt; ich habe -glaube ich-
mindestens 2.000 Seiten zu dem Thema gelesen; wahrscheinlich deutlich
mehr).
> Tatsächlich habe ich eine solche Abhandlung noch nirgendwo im> Zusammenhang mit Microcontrollerentwicklung gelesen (und sorry, Jürgen,> hier stellt man eindeutig fest, was du arbeitest oder gearbeitet hast).
Wieso Sorry?
> allerdings nicht "springen", sondern Projektmanagment an den> "abstrakten" (ich finde kein passenderes Wort für die Beschreibungen für> die Entwicklungsarbeiten der Wirtschaft) Beispielen zu Ende bringen um> dann an einem konkreten Beispiel am Mikrocontroller zu zeigen.
Geht nicht. Wenn jemand die Idee hat, mit MCUs ein Projekt zu starten,
dann ist alles offen (Robot, Flugmodell, Energieoptimierung im Haushalt
etc.etc.) Ich kann also nur die Idee geben, wie man das Projekt
strukturiert. Die Wahrscheinlichkeit, dass ein Beispiel am Bedarf vorbei
geht, liegt ungefähr bei 100%.
> ich glaube dass Jürgen genau aus diesem Grund sein> Manuscript deshalb hier eingestellt hat, damit wir quasi als Lektore> darüber lesen (und das ist absolut legitim).
Alles freiwillig und für den höheren Zweck. Dass ich damit nicht reich
werde, habe ich schon mehrfach dargelegt. Und ich danke allen, die in
diesem Sinne mitmachen/mitgemacht haben:
> Ich wünsche dir viel Glück mit deinem Buch und eine gewissen> "Schmerzfreiheit" wenn du nach langem überlegen dich dann doch von> Inhalten trennst, von denen du "weißt" dass sie aber wichtig sind.
Die Kapitel, die ich geschrieben habe, habe ich (aus meiner Sicht der
Dinge) aus gutem Grund geschrieben. Auf der anderen Seite ist das
Manuskript nicht mein "ach so liebes Kind". Ich hielt es für notwendig,
jetzt ist es da und natürlich versuche ich, ihm eine gute Zukunft zu
geben. Aber wenn das nicht klappt, dann zerbreche ich auch nicht daran
(erinnert mich an den Song von Jonny Cash: "A Boy Namend Sue"; 'dich so
zu nennen war das Einzige, was ich für dich tun konnte, damit du stark
genug wirst, um dich durchzusetzen).
> Möchte man ein "perfektes" Buch schreiben, wird man nie fertig (smile,> warum kommt mir das bekannt vor).
Danke für deinen langen Komentar. Es gibt Bücher, die das enthalten, was
man angeblich wissen muss. Es gibt viele Bücher, die das enthalten, was
an angeblich wissen sollte. Es gibt sehr wenige Bücher darüber, was zu
wissen wirklich sinnvoll ist! Hau rein!
Wenn man schreibt, dann muss man sich irgendwo in dieser Bandbreite
positionieren und dann sein Herz dran hängen, sonst klappt das nicht.
Vielen Dank für deine Zeit
Jürgen
TB schrieb:> Dieses generell abwertende Verhalten zu Datenblättern finde ich auch> unpassend.
Das hast du falsch mitbekommen. Ich habe keine generell abwertende
Haltung gegenüber Datenblättern (ohne es gezählt zu haben, habe ich
wahrscheinlich zwischen 5.000 und 10.000 Seiten Datenblätter in meinem
Leben gelesen (vielleicht sind es sogar 20.000 Seiten oder weit mehr,
aber wen interessiert das). Datenblätter sind das A&O jeder
Systementwicklung! Ohne die geht es gar nichts!
> Wenn jemand schon mit den sehr übersichtlichen AVR Datenblättern> Schwierigkeiten hat, wird mit anderen uCs garnicht klarkommen.
Das genau ist meine Kritik: Sie sind nicht übersichtlich. Sie sind für
ein Selbststudium nahezu ungeeignet. Ich (bilde ich mir nicht nur ein)
habe ein ziemlich profundes Wissen über Rechnertechnik und ich hatte
erhebliche Schwierigkeiten, mir darüber klar zu werden, welches Bit in
den vielen Registern letztlich welche Wirkung hat. Und es blieben auch
nach dem zweiten oder dritten Durchlesen des Datenblattes Fragen offen,
die dort nicht wirklich beantwortet werden.
Bitte verstehe mich jetzt nicht falsch, ich beziehe mich nicht das
teilweise Verständnis von Funktionen, sondern auf die vollständige
Durchdringung des Chips (alle Register und alle Bits mit sämtlichen
Auswirkungen). Das liefert das Datenblatt nicht (zumindest nicht für
mich verständlich)!
Mit einem 10 bis 80-fachen Aufwand (im Verhältnis zu dem, was wirklich
nötig gewesen wäre), hab ich mir das erarbeitet. Den Aufwand möchte ich
anderen ersparen.
Gruß
Jürgen
an Jürgen Henning:
TOP, vor allem für solche, die wenig oder gar kein Englisch können oder
auch nicht können wollen. War für mich damals als Jugendlicher die
Haupthürde beim Einstieg in uCs.
Verbesserungsvorschläge:
- Blocksatz verwenden
- Jegliche "Ich"-Formen, Persönliches etc. vermeiden
- Jegliche KLAMMERN [({ sind Gift für einen angenehmen Textfluss
- Geschichtliches würde ich im persönlich besonders hervorheben wie z.B.
Kursivstil verwenden, damit können die Nichtinteressierten Sprünge
machen zum eigentlich Inhalt. Es würde auch professioneller aussehen.
Beste Grüße und frohes neues Jahr
Alex
Thomas Eckmann schrieb:> Nein. Das ist sehr wohl im Sinne des Nutzers. Insbesondere im Sinne des> ASM-Programmierers.
ICH kann immer noch keinen Vorteil für den Benutzer erkennen (weder in C
noch in Assembler)! Ich würde vorschlagen, dass du entweder die
Begründung lieferst oder schweigst. Mit Typen, die sagen "Ich weiß was,
aber das erzähle ich hier doch nicht!", kann man die Bildschirme
pflastern. Sortier dich ein, wo du hin gehören möchtest und mach dein
Ding (aber nerv nicht).
jdhenning schrieb:> Das hast du falsch mitbekommen. Ich habe keine generell abwertende> Haltung gegenüber Datenblättern (ohne es gezählt zu haben, habe ich> wahrscheinlich zwischen 5.000 und 10.000 Seiten Datenblätter in meinem> Leben gelesen (vielleicht sind es sogar 20.000 Seiten oder weit mehr,> aber wen interessiert das). Datenblätter sind das A&O jeder> Systementwicklung! Ohne die geht es gar nichts!
Zumindest das Atmega8 Datenblatt kommt bei dir nicht gut weg und das
völlig grundlos. Ein Datenblatt ist nun einmal nicht für komplette
Neulinge in der Programmierung von Mikrokontrollern gedacht, sondern für
erfahrene Entwickler die schnell an Informationen rankommen müssen. Und
die Erfahrung muss gar nicht im Bereich von AVR liegen. Jemand der
vorher zB nur mit ARM Controllern (Hersteller egal) gearbeitet hat, wird
sich problemlos im AVR Datenblatt zurechtfinden. Wie Simon K. auch schon
erwähnt hat, arbeitet man ein Datenblatt auch nicht komplett durch
sondern sucht zielgerichtet nach der Funktionsbeschreibung der
benötigten Blöcke. Und da kann man gegen die AVR Datenblätter kaum etwas
Negatives sagen. Aber das lernt man wie immer erst zu schätzen wenn man
einen etwas größeren Überblick über andere Controllerfamilien hat.
Hi
Jürgen, du machst es dir nur unnötig schwer. Warum läßt du nicht ma die
Zeit für dich arbeiten und gewinnst Abstand zu deinem Buch. Es steht mir
und auch keinem anderen an, dir vorzuschreiben, wie du das Buch
gestalten sollst. Die Käufer werden sehr schnell wissen, ob der Inhalt
sinnig ist. Und genau da ist dein Problem. Du beißt dich als Autor an
Deiner Version fest, ohne mal mit Abstand den Text zu lesen. Hundert mal
lesen hilft nicht! Du mußt es lesen, wie einer, der den Inhalt nicht
kennt. Es erfordert mehr, als den Vorsatz "ich schreib ein Buch". Dabei
ist es völlig egal, ob Roman, Krimi, Biografie oder Fachbuch. Nicht
grundlos nehmen sich Personen wie Kohl einen Ghostwriter.
Und noch was. Ein Controller ist ein fertig Teil. Punkt. Da gibt es
nicht "ich finde es eine Zumutung". Alles ist da so drin und deine
Empfindungen werden niemals das Produkt verändern. Klar, wenn der Kunde
sagt, "nehm ich nicht" wird der Hersteller prüfen, warum sein Produkt
auf Ablehnung stößt und erst dann eine Korrektur durchführen oder eine
neue Entwicklung anstoßen. Betrachte den Controller als "Fertig". Alles
andere sind Emotionen, die in der Digitaltechnik nix zu suchen haben.
Der Controller soll einen Job machen. Der Anwendung ist es auch völlig
egal, ob das Ding lila ist. Ein Praktiker sieht nur den IC und sein
einziges Problem wird die Anzahl der IO sein, die für sein Vorhaben
ausreichen müssen. Hier hilft nicht "Ich hätte auch Danz gern ein paar
Anschlüsse obendrauf". Da sind keine! Als, Emotionen weg, Abstand zum
eigenen Werk, dann nochmal mit den Ansprüchen der Zielgruppe lesen und
dann stellst du ganz allein deine Mängel im Text fest. Aufgrund deiner
Vergangenheit bist du vermutlich (fast) Rentner. Klar, da drängt es,
weil die Zeit möglicherweise schon begrenzt ist. Aber so hart wie es
klingen mag, auch ich würde bei deinem Schreibstil vermutlich nicht
kaufen.
Und noch ein Wort zu dan anderen Kritikern. Macht dieses Buch nicht
runter. Ich bin auch der Meinng ein deutsches Buch mit einer Anleitung
für den Einsatz der µC ist nicht überflüssig. Denkt immer dran, ihr habt
es vermutlich studiert und seid mit eurem Job gewachsen. Auch ich komme
als gelernter Elektroinstallateur ohne Studium mit diesen Dingen klar.
Aber, das ist nicht der Verdienst von Experten. Deren Kauderwelsch hab
ich nur selten verstanden. Es war das Interesse an elektronischen
Spielereien, die mit Röhrentechnik begonnen und über die ICs und PCs
letztlich zu µCs führte. Geholfen haben deutsche Beschreibungen. Und ja,
auch ich habe monatelang Fehler gesucht, weil dieser im Buch eingebaut
war. Ärgerlich, aber so ist es eben. Nix ist perfekt.
In diesem Sinne, ein erfolgreiches, gesundes neues Jahr
Gruß oldmax
jdhenning schrieb:>> Wenn jemand schon mit den sehr übersichtlichen AVR Datenblättern>> Schwierigkeiten hat, wird mit anderen uCs garnicht klarkommen.> Das genau ist meine Kritik: Sie sind nicht übersichtlich. Sie sind für> ein Selbststudium nahezu ungeeignet.
Doch, sie sind übersichtlich. Im Umfeld der MCU-Datenblätter zählen sie
(und das sehen viele andere Leute ähnlich) zu den besten Datenblättern
überhaupt. Das mag sich vielleicht deinem engen Horizont entziehen, so
wie sich hier vieles an Kritik deiner Vorstellung entzieht.
jdhenning schrieb:> Das liefert das Datenblatt nicht (zumindest nicht für> mich verständlich)!
Doch, genau das soll es liefern. Und im Falle der AVRs tut es das auch
ziemlich ergründend (dann solltest du daran arbeiten, wenn das für dich
nicht verständlich ist).
jdhenning schrieb:> aber ich habe hier schon mehrfach geschrieben: [...]
Du nimmst Kritik immer genau dann an, wenn es dir gerade in den Kram
passt und bequem ist.
. Es heißt Slave und nicht Sklave. Und das sogar international und
schon seit mindestens 40 Jahren. Sogar in Deutschland.
. Es heißt Reentrancy. Wenn du schon Wert auf Deutsch legst, dann
heißt es Eintrittsinvarianz und nicht Reentrantfähigkeit.
. Unbegründete Wertungen gehören nicht in ein Fachbuch.
. Persönliche Meinungen gehören nicht in ein Fachbuch.
. Ein Fachbuch dient nicht der Theoriefindung. Wenn tausend Leute es
seit zwanzig Jahren auf die Art und Weise X machen, dann nennt man das
etabliert. Und du es doof findest, dann solltest du herausfinden,
wieso man es auf die Art und Weise X macht. Und dann solltest du das
auch akzeptieren oder einfach die Klappe halten. Denn dein Fachbuch soll
dem Einsteiger nicht deine tollen Theorien und Meinungen vermitteln,
denn die interessieren weder den Einsteiger noch den Rest der Welt.
Vielmehr soll dein Fachbuch den Einsteiger z.B. darauf vorbereiten, dass
er auf die etablierte Art und Weise stößt, früher oder später, wenn er
sich mit anderen Leuten austauscht. Und das Fachbuch soll dafür sorgen,
dass der Einsteiger dann versteht, wovon die anderen Leute reden. Wenn
du jedes Mal mit eigenen Theorien ankommst und missionierst, kriegst du
sonst jedes Mal wieder die Klatsche, genau wie hier. In einer Notiz
kannst du dann immer noch eine Alternative anbieten, aber die Etablierte
muss vorkommen.
. Dein Betriebssystem gehört nicht in dieses Buch. Es ist nichts, was
einen Einsteiger interessiert und es ist ziemlich unanschaulich
beschrieben, sodass auch kein Lerneffekt davon ausgeht. Die Verkettete
Liste hätte man dagegen z.B. als einfaches C-Beispiel nehmen können.
Außerdem ist dein Betriebssystem praxisunrelevant, da es 100 andere,
besser getestete, einfacher einzusetzende gibt.
. (S.174) Man hat PCINT15 nicht weggelassen, um den Nutzer zu verwirren.
Du hast einfach nicht verstanden, dass je 8 PCINT einen Port abdecken
und dass PC7 fehlt. PCINT15 wäre nämlich genau für PC7 da, und das ist
bei den größeren Bausteinen auch so, da gibt es PCINT15 für PC7.
. (ebd.) Der Multiplizierer ist nicht neu im ATmega328. Den gibts im
ATmega8 exakt genauso, hast du scheinbar noch garnicht bemerkt.
. Wechselstrom heißt auch nicht 'Alternate Current'. Du findest sicher
selbst heraus, wie der tatsächlich heißt. Grundlagen!
. Im Glossar ganz hinten steht soooooooo viel Kram drin, der völlig
unerheblich ist für dein Buch.
. (S.117) Wenn das 0-Byte den String abschließt, welche 255 anderen
Werte gibts dann noch?
. (ebd.) Im Manual sind die Funktionen alphabetisch nach Include-Datei
sortiert. Du schreibst, das sei extrem unpratisch und machst es dann
genauso. Toll, Hauptsache wieder abwertend.
Ansonsten würde ich auch mit Ullis Beitrag weitermachen:
Beitrag "Re: ATmega8: Das Buch"
Ja, der ist unbequem, darum hast du ihn vermutlich auch schweigend
übergangen.
Reicht das fürs erste?
Martin Vogel schrieb:> Denkt immer dran, ihr habt> es vermutlich studiert und seid mit eurem Job gewachsen. Auch ich komme> als gelernter Elektroinstallateur ohne Studium mit diesen Dingen klar.> Aber, das ist nicht der Verdienst von Experten. Deren Kauderwelsch hab> ich nur selten verstanden.
Das Problem dabe ist, ja, viele der Kritiker hier haben vermutlich
studiert, ich auch.
Aber auch darum wissen sie ziemlich gut, wie viel schwerer es ist,
einen Stoff zu verstehen, den man zuvor mal verquirlt beigebracht
bekommen hat.
Eine fachlich und/oder didaktisch untaugliche Lehre ist nicht selten
sehr viel schlimmer als garkeine...
Mein letzter Kommentar hier...
Ich habe nicht ET oder etwas in der Richtung studiert sondern Biochemie.
Elektronik und Programmierung ist für mich ein Hobby. Ich habe keine
berufliche Beziehung zu dem Thema.
Trotzdem stimme ich den Kritiken hier voll und ganz zu. Siehe auch meine
Kommentare.
Ich würde dein Buch jedenfalls nicht kaufen... vlt solltest du mal bei
elektor nachfragen. Die verkaufen ja ganz gerne derart nutzlose Bücher
und das auch noch überteuert.
Trotz allem, viel Glück mit deinem Vorhaben!
jdhenning schrieb:> ICH kann immer noch keinen Vorteil für den Benutzer erkennen (weder in C> noch in Assembler)! Ich würde vorschlagen, dass du entweder die> Begründung lieferst oder schweigst. Mit Typen, die sagen "Ich weiß was,> aber das erzähle ich hier doch nicht!", kann man die Bildschirme> pflastern. Sortier dich ein, wo du hin gehören möchtest und mach dein> Ding (aber nerv nicht).
Ich nerve soviel ich will. Das ist hier nicht dein privates, sondern ein
öffentliches Forum. Und deinen Vorschlag werde ich weder in der einen
noch in der anderen Form annehmen. Du bist derjenige, der ein Buch
schreiben will und erkennst nicht einmal solch profane Zusammenhänge.
Es ist dein Problem, wenn du keine Ahnung von den Controllern hast, über
die du schreibst.
mfg.
Habt Ihr Euch schon mal gefragt, warum der Buchvorschlag und dieser
damit verbundene Thread eine gewisse Anziehungskraft ausübt? Da gibt es
sogar "Nase"n, die verabschieden sich für immer, um einige Tage später
mit Kommentaren, die einfach raus müssen, zurückzukommen.
Für mich ist der Thread so spannend, weil das Buch und viele Kommentare
des Autors einen ungeheuren Nervfaktor haben. Das habe ich bei einem
technischen Text in dieser Form noch nie erlebt. Ganz ehrlich, beim
Lesen in dem Buch bekomme ich einen erhöhten Puls, weil es Emotionen in
mir weckt. Und ist es dann nicht schön, wenn man bei einem derartigen
literarischen Werk sogleich ein Forum mitgeliefert bekommt, in dem man
sich Luft verschaffen kann. Außerdem findet man viele Gleichgesinnte.
Das tut gut.
In diesem Sinne, danke jdhenning und den anderen "Atmega8: Das
Buch"-Fans für die aufregende Lektüre.
Conny Phi schrieb:> Da gibt es> sogar "Nase"n, die verabschieden sich für immer, um einige Tage später> mit Kommentaren, die einfach raus müssen, zurückzukommen.
Wobei ich mir ehrlich gesagt mehr Sorgen mache um potentielle
Einsteiger, denen die Lust am Einsteigen aufgrund solch mieser Lektüre
gleich wieder vergeht.
Um das Buch ist mir das irgendwie egal, das ist im derzeitigen Zustand
de-facto ein Flop, fachlich wie didaktisch.
Aber zugegebenermaßen ist es auch ein wenig amüsant, ja. Prinzipiell bin
ich gegen Trollerei, aber in solchen Fällen, na ja. Der OT hat hier eine
Schar potentiell sehr fachkundiger Menschen versammelt und fragt sie
nach ihrer Meinung zu seinem Geschreibsel. Aber im Gegenzug nimmt er
keinerlei Kritik auf, die man (anfänglich sicher) wohlwollend an ihn
heranträgt.
Wenn er doch ins Messer laufen will, na lass ihn halt. Und das sehen 9
von 10 Teilnehmern dieser Diskussion gewiss ähnlich :-)
TB schrieb:> Zumindest das Atmega8 Datenblatt kommt bei dir nicht gut weg und das> völlig grundlos.....Aber das lernt man wie immer erst zu schätzen wenn man> einen etwas größeren Überblick über andere Controllerfamilien hat.
Es ist anders herum. Ich habe in meinem gesamten Technikerdasein nur
erschreckend wenig gut gemachte Datenblätter gesehen.
Ich weiß ja, wie es in der Industrie läuft. Wer schreibt das Handbuch
oder die Bedienungsanleitung oder das Datenblatt? Derjenige, auf den man
im nächsten Projekt am leichtesten verzichten kann. Das Ergebnis wird
dann noch einmal sprachlich von jemand anderem überarbeitet (der aber
meist nur rudimentäre Ahnung vom Gegenstand hat) und abschließend geht
es noch mal in die Fachabteilung, damit grobe inhaltliche Fehler und
Auslassungen beseitigt werden.
Parallelports gibt es, seit es Computer gibt. USART seit 1963; I²C, also
TWI, seit 1983. Ich finde es beschämend, wenn eine Firma nicht in der
Lage ist, Technologien, die ein halbes Jahrhundert alt sind, so
umzusetzen, dass die Umsetzung und ihre Beschreibung verständlich sind.
Natürlich gewöhnt man sich als Techniker daran, mit schlecht gemachten
Datenblättern zu leben (es bleibt einem ja auch nichts anderes übrig!).
Was ist also schlimm daran, wenn ich sage, dass sich dieses Datenblatt
noch einmal deutlich von der grottenschlechten Umgebung abhebt? Hierbei
geht es mir ja nicht darum, Atmel schlecht zu machen, sondern
Neueinsteigern verständlich zu machen, dass ihre Verständnisprobleme
nicht darauf beruhen, dass sie zu doof sind.
Wie du selber schreibst, wenn man sich lange mit der Thematik
beschäftigt hat, dann hat man diese Probleme nicht mehr. Damit hast du
recht, aber was nützt das einem Neueinsteiger?
jdhenning schrieb:> TB schrieb:>> Zumindest das Atmega8 Datenblatt kommt bei dir nicht gut weg und das>> völlig grundlos.....Aber das lernt man wie immer erst zu schätzen wenn man>> einen etwas größeren Überblick über andere Controllerfamilien hat.> Es ist anders herum. Ich habe in meinem gesamten Technikerdasein nur> erschreckend wenig gut gemachte Datenblätter gesehen.
Ein Geisterfahrer? Hunderte!
Vielleicht hast DU ein Problem mit Datenblättern.
> Wie du selber schreibst, wenn man sich lange mit der Thematik> beschäftigt hat, dann hat man diese Probleme nicht mehr. Damit hast du> recht, aber was nützt das einem Neueinsteiger?
Du widersprichst dir? Entweder die Datenblätter sind schlecht, dann sind
sie schlecht. Oder es liegt am unerfahrenen Neueinsteiger. Dann liegt es
NICHT an den Datenblättern. Was nun?
Ich finde es schon auch amüsant dass du deine persönliche Defizite im
Verständnis der Datenblätter und der AVR Peripherie als absolut
darstellst und dich dann noch getraust in einem Buch darüber
herzuziehen. Wirklich jetzt?
Und dabei bist du noch dermaßen von dir überzeugt dass du jede Kritik
dummfrech abschmetterst. Unglaublich.
jdhenning schrieb:> Was ist also schlimm daran, wenn ich sage, dass sich dieses Datenblatt> noch einmal deutlich von der grottenschlechten Umgebung abhebt?
So eine Aussage steht dir in dieser Form und im Rahmen (d)eines
Fachbuches einfach nicht zu [...].
(1) Eine solche Bewertung gehört nicht in ein Fachbuch,
(2) denn sie ist subjektiv und suggeriert,
(3) dass du selbst nicht mit anderen Datenblättern klarkommst;
(4) zumal die Bewertung selbst in einem Buch steht, welches sich zur
Zeit noch nicht vom grottenschlechten Rest abhebt.
(5) Motivierend ist das außerdem ganz und garnicht. Denn sie suggeriert
dem Leser, dass er selbst für dieses Datenblatt noch zu blöd ist, obwohl
es schon eines der besten ist. Und dass er mit anderen Datenblättern
lieber garnicht erst anfangen soll, denn die wird er schon garnicht
verstehen.
Das waren jetzt fünf leicht nachvollziehbare Gründe, solche Passagen aus
dem Manuskript zu tilgen:
(1) Bewertungen sollte man in Fachbüchern, wenn überhaupt, stilistisch
neutral formulieren. "Fucking momsers" ist nicht stilistisch neutral.
(2) Persönliche Meinungen sollte man sich verkneifen oder begründen.
Persönliche Dummheit ist keine Begründung.
(3) Als Autor sollst du dem Einsteiger Sicherheit vermitteln und mit
ihm Denken. Und nicht jammern, dass du vieles selbst nicht verstehst
oder dass alles Mist und du der Heiland bist.
(4) Ja.
(5) "Alles ist scheiße und ich verstehs selbst kaum" ist nicht
motivierend für den Leser.
Jetzt bin ich gespannt auf die Schelte, mit der du diese fünf Gründe
wieder an die Wand haust, weil du alles besser kannst.
Hallo Martin.
Martin Vogel schrieb:> Also, Emotionen weg, Abstand zum eigenen Werk, dann nochmal mit den> Ansprüchen der Zielgruppe lesen und dann stellst du ganz allein> deine Mängel im Text fest.
Danke für die Hinweise. Die Eile mit dem Buch habe ich nicht aufgrund
meines Alters, sondern weil ich mit MCUs noch ein paar Projekte machen
wollte. Das Buch ist nicht 'mein Baby', sondern gut zur Hälfe das
Abfallprodukt meiner Bemühungen, den ATmega8 wirklich zu verstehen. Mein
Schreibstil ergibt sich aus der Überlegung, dass ich so schreiben will,
wie ich meinem besten Kumpel das alles erklären würde (falls er es denn
wirklich wissen wollte). Da wären ganz sicher noch deutlich mehr
Wertungen dabei, als jetzt im Text.
Oder anders ausgedrückt: Es ist nicht so, dass ich wissenschaftlichen
Stil nicht könnte. Ich will ihn nicht, denn er würde noch mehr Leser
abschrecken, als eine Handvoll flapsiger Bemerkungen. Als Stephen
Hawking sein Buch "Eine kurze Geschichte der Zeit" schrieb, wurde ihm
vom Verleger aufgetragen: "Jede Formel halbiert die Anzahl der Käufer!".
Aber auf die Formel E=mc² wollte er nicht verzichten.
Wie es in der Informatik so schön heißt: "It's no fault, it's a
feature!"
jdhenning schrieb:> Was ist also schlimm daran, wenn ich sage, dass sich dieses Datenblatt> noch einmal deutlich von der grottenschlechten Umgebung abhebt?
Weil das nur deine subjektive Meinung ist, die sich noch dazu aus recht
bescheidener Erfahrung in dem Umfeld bezieht.
Das AVR Datenblatt hebt sich tatsächlich von anderen ab, aber im
positiven Sinne. Ich verwende zwar selbst aufgrund günstiger ARM
Alternativen keine mehr, aber am Datenblatt hatte ich nie etwas
auszusetzen.
Natürlich sind Datenblätter immer eine lästige Angelegenheit für Firmen
und deshalb grundsätzlich keine Gute-Nacht-Lektüre. Ist bei meinem
Arbeitgeber auch nicht anders. Die Funktionsbeschreibung der Hardware
machen die Entwickler selber, wobei wir aufpassen müssen, dass man
möglichst wenig von der internen Architektur preisgibt. Der Chip muss
für den Kunden konfigurierbar aber nicht verständlich sein. Weiters ist
das Produkt meist schon Monate fertig, bevor das Datenblatt halbwegs
stabil ist und man das Produkt endlich Releasen kann. Wirklich wichtig
ist den Herstellern nur das hervorheben wettbewerbsrelevanter Parameter
(sofern sie besser als die der Konkurrenz sind). Für alles weitere wird
der Aufwand minimiert.
Also insofern hast du schon recht, dass Datenblätter selten eine
wirklich gute Architekturbeschreibung liefern. Das sollen sie aber auch
nicht. Solange der Kunde damit arbeiten kann, ist der Zweck erfüllt. Und
gerade bei Atmel kann man sich überhaupt nicht über mangelnde
Beschreibung im Datenblatt aufregen. Die Information ist sogar so
ausführlich, dass man ohne weiteres den Chip (ausgenommen dem Debug
Interface) selbst nachbauen kann (selber schon gemacht für einen Atmega
128 mitsamt Peripherie).
Nase schrieb:> (S.117) Wenn das 0-Byte den String abschließt, welche 255 anderen> Werte gibts dann noch?
Du meinst, ich sollte da eine komplette Liste einstellen? Dann schau mal
auf Seite 216, da ist sie. Allerdings haben andere schon geschrieben,
dass die völlig überflüssig sei.
> Toll, Hauptsache wieder abwertend.
Du wertest nicht nur die ganze Zeit, nein, du versuchst einem auch noch
Vorschriften zu machen, was man in so ein Buch hinein schreiben soll.
"Die Kritiker der Elche sind meist selber welche!"
> Reicht das fürs erste?
Nee, bitte nicht aufhören. Es ist doch gut, wenn sich zumindest einer
über die Peanut-Fehler aufregt und sie auflistet.
Gruß
Jürgen
jdhenning schrieb:> du versuchst einem auch noch> Vorschriften zu machen, was man in so ein Buch hinein schreiben soll.
Du willst es ja einfach nicht verstehen.
Du hast in deinem Leben vermutlich noch kein einziges Datenblatt
verfasst und machst den Autoren der AVR-Datenblätter ständig Vorwürfe,
wie schlecht die Datenblätter sind und wie blöd die Bezeichnungen sind
und so weiter.
jdhenning schrieb:> "Die Kritiker der Elche sind meist selber welche!"
Exakt. Und du kritisierst ziemlich viel am Datenblatt und am AVR herum.
Naja, eigentlich kritisierst du ja nicht, dazu müsstest du ja etwas
Fundiertes dazu schreiben. Nein, du prügelst einfach drauf herum, weil
du selbst nicht verstehst.
Cyblord ---- schrieb:> Und dabei bist du noch dermaßen von dir überzeugt dass du jede Kritik> dummfrech abschmetterst.
Das siehst du irgendwie falsch. Ich schmettere nur dummfreche Kritik ab!
Und exakt wegen der anderen Kritik habe ich das Buch hier eingestellt
und die habe ich (in sehr weiten Teilen) nicht nur aufgenommen, sondern
auch schon umgesetzt.
Und wozu die künstliche Aufregung? Wenn das Geschreibsel so mies ist,
dann wird es entweder keinen Verleger oder später keine Käufer finden.
Wo also ist das Problem?
Nase schrieb:> So eine Aussage steht dir in dieser Form und im Rahmen (d)eines> Fachbuches einfach nicht zu [...].
Sagt wer? Steht wo geschrieben? So etwas schreiben und mir
Selbstüberschätzung unterstellen. Tss, tss!
> (1) Eine solche Bewertung gehört nicht in ein Fachbuch,
Deine persönliche Meinung und die ist für mich nicht ausschlaggebend.
> (2) denn sie ist subjektiv und suggeriert,
Jede Bewertung ist subjektiv. Sogar Messungen sind des öfteren
subjektiv.
> (3) dass du selbst nicht mit anderen Datenblättern klarkommst;
Wie kommst du denn auf die Idee? Hallolzinationen? Ich habe lediglich
geschrieben, dass das Datenblatt es einem Einsteiger nicht gerade leicht
macht.
> (4) zumal die Bewertung selbst in einem Buch steht, welches sich zur> Zeit noch nicht vom grottenschlechten Rest abhebt.
Endlich gibst du zu, dass es an guter Literatur fehlt und dass das
Datenblatt da auch keine Abhilfe schafft. Danke!
TB schrieb:> Der Chip muss> für den Kunden konfigurierbar aber nicht verständlich sein. Weiters ist> das Produkt meist schon Monate fertig, bevor das Datenblatt halbwegs> stabil ist und man das Produkt endlich Releasen kann. Wirklich wichtig> ist den Herstellern nur das hervorheben wettbewerbsrelevanter Parameter> (sofern sie besser als die der Konkurrenz sind). Für alles weitere wird> der Aufwand minimiert.
(sic!)
jdhenning schrieb:> Wie kommst du denn auf die Idee? Hallolzinationen? Ich habe lediglich> geschrieben, dass das Datenblatt es einem Einsteiger nicht gerade leicht> macht.
Nicht nur Einsteigern nicht und es kommt sogar (jetzt mal nicht an µC's
denken) vor, dass ein Datenblatt eines Herstellers auch dem einen oder
anderen "alten Hasen" an bestimmten Stellen schwer fällt.
Es hat bei mir fast zwei Jahre gedauert, bis ich so einigermaßen
verstanden habe worum es bei vielen Sachen im Datenblatt geht.
Es würde sich allein schon lohnen ein Buch zum lesen lernen von
Datenblättern zu schreiben.
Nase schrieb:> Naja, eigentlich kritisierst du ja nicht, dazu müsstest du ja etwas> Fundiertes dazu schreiben. Nein, du prügelst einfach drauf herum, weil> du selbst nicht verstehst.
Wenn du das 'prügeln' nennst, dann bist du aber extrem dünnhäutig.
Nur wegen der Logik: Wenn ich es nicht verstehen würde, dann könnte ich
es nicht kritisieren, denn ich wüßte ja nicht, was exakt da der Kritik
würdig wäre. Ich kritisiere, weil ich es verstanden habe und ich die
Umsetzung/Beschreibung für deutlich suboptimal halte (meine Meinung und
wer Meinungen verbieten will, ist ein mieser Diktator [oder
Möchtegern-Diktator]).
Am besten gefällt mir das "Wirtschafts-Und".Gemocht habe ich nicht die
Ausflüge in die Vergangenheit, sei es persönlicher Art oder in die
Geschichte der Technik. Dazu gibt es sicher außerhalb des Buches
genügend Informationen und lenkt hier nur ab.
Für mich gehört eine Einführung in C, sei es auch eine Minieinführung,
nicht in ein Buch mit Titel "AVR-Mikrokontroller, Eine Einführung am
Beispiel des ATmega8". Lieber mehr gut kommentierte Beispielprogramme
auch sprachenneutral in Assembler. Lieber einen Teil 2 :) der sich nur
Programmierung und den Werkzeugen dazu beschäftigt (aber da bitte keine
Techniken, außer du kennst dich da WIRKLICH aus)
Irgendwie fehlt mir auch eine Einführung, in der man erkennen kann, für
wen das Buch gedacht ist und welche Voraussetzungen man mitbringen
sollte.
Wenigstens ein ganz einfaches funktionierendes Beispiel von HW bis SW
komplett nachbaubar beschrieben gehört für einen "Newbie" in dieses
Buch.
Ich habe nicht die Muße, wie viele hier, auf mehr Details einzugehen und
stimme meinen Vorrednern außer jdhenning zu. Hätte ich mir das Buch
gekauft, wäre ich total enttäuscht gewesen und hätte nicht versucht es
über ebay loszuwerden, sondern hätte versucht es an den Verlag/Author
zurückzugeben.
F. Fo schrieb:> Es würde sich allein schon lohnen ein Buch zum lesen lernen von> Datenblättern zu schreiben.
Das Thema habe ich vor Jahren mal mit einem Kumpel ausgiebig diskutiert
und wir kamen damals zu dem Schluß, dass das nicht geht.
Der Hauptgrund ist, dass aus Sicht des ursprünglichen Schreibers alles
vollkommen klar ist und er alles so geschrieben hat, dass sogar ein
Halbdepp es problemlos versteht. Ein paar Posts weiter hoch hat ja 'TB'
geschrieben, dass diese Version dann oftmals auch noch kastriert wird,
damit man nicht zu viel verrät. Zudem verdienen Firmen über die
Datenblätter höchstens mittelbar, weshalb man sie oft zum freien
Download zur Verfügung stellt.
Es ist mir ja klar, dass Datenblätter nur so gut sind, wie sie unbedingt
müssen. Aber ich lasse mir nicht vorschreiben, dass ich das gut zu
finden habe.
Gruß
Jürgen
jdhenning schrieb:> Nase schrieb:>> So eine Aussage steht dir in dieser Form und im Rahmen (d)eines>> Fachbuches einfach nicht zu [...].> Sagt wer? Steht wo geschrieben? So etwas schreiben und mir> Selbstüberschätzung unterstellen. Tss, tss!
Sage ich dir jetzt und wird dir dein zukünftiger Verlag dann auch sagen.
Es gibt verschiedene Textgattungen, und für Fachbücher gehört sich diese
Stichelei nicht. Kannst du in deine Memoiren oder in einen Roman packen,
aber nicht in ein Fachbuch.
>> (1) Eine solche Bewertung gehört nicht in ein Fachbuch,> Deine persönliche Meinung und die ist für mich nicht ausschlaggebend.
Die Meinung von etlichen Leuten hier im Thread und auch da draußen. Die
sollte für dich relevant sein, wenn du dein Buch irgendwann mal
verkaufen möchtest.
>> (2) denn sie ist subjektiv und suggeriert,> Jede Bewertung ist subjektiv. Sogar Messungen sind des öfteren> subjektiv.
Nö.
>> (3) dass du selbst nicht mit anderen Datenblättern klarkommst;> Wie kommst du denn auf die Idee? Hallolzinationen? Ich habe lediglich> geschrieben, dass das Datenblatt es einem Einsteiger nicht gerade leicht> macht.
Das brauchst du nicht explizit zu schreiben. Das liest man als
erfahrener(er) Leser sehr leicht aus deinen Ausführungen heraus.
Wenigstens, dass du mit dem AVR-Datenblatt nicht klarkommst. Und wenns
da bei dir schon hapert, haperts woanders ganz bestimmt - das
schreibst du sogar selbst.
jdhenning schrieb:> Ich kritisiere, weil ich es verstanden habe
An etlichen Stellen kritisierst du etwas, weil du es nicht verstanden
hast. Zum Beispiel die Sache (auf die du ja wieder nicht eingegangen
bist) mit dem vermeintlich fehlenden PCINT.
> und ich die> Umsetzung/Beschreibung für deutlich suboptimal halte
Das kannst du halten, ja, deine Meinung.
Aber du kritisierst ja nicht, denn du beschreibst ja keine Alternative
oder überhaupt mal warum etwas suboptimal ist. Du beschimpfst einfach
nur und das wars. Hat man dir jetzt aber auch schon oft genug erklärt,
auch das willst du ja nicht kapieren.
> (meine Meinung und> wer Meinungen verbieten will, ist ein mieser Diktator [oder> Möchtegern-Diktator])
Oder der Verlag, der ein Fachbuch veröffentlichen möchte. Und der will
dir deine Meinung gewiss nicht verbieten. Er will nur ein Fachbuch
draus machen, und da interessiert sich niemand für deine Meinung. Das
weiß der Verlag nämlich, weil der macht das öfter.
Wenn dir deine Meinung so wichtig ist, dann verfass doch noch einen
Roman über den AVR, da kannst du dich dann austoben. Nur den wird halt
auch keiner lesen wollen, weil sich dahingehend niemand für deine
Meinung interessiert. Darum wird dir auch kein Verlag solch einen Roman
abkaufen.
Und wenn du das nicht auf die Kette kriegst, wird auch kein Verlag dein
Buch verlegen wollen. Es gibt Leute, die können es sich leisten, mit
Konventionen zu brechen. Stephen Hawking vielleicht. So wie das
Fachbuch eine Konvention ist, bei der konventionell keine
persönlichen Meinungen dieser Art hineingehören. Aber mit so einem
Popelthema wie AVR kannst du es dir sicher nicht leisten, aus der Reihe
zu tanzen.
So wird dein Buch bestenfalls in der Sofaritze verlegt.
Hallo jdhenning!
Ich verfolge den Thread schon seit einigen Tagen und ich bin fasziniert
davon. Erstmal möchte ich mich bei dir bedanken, dass du uns an deinem
neuen Buch teilhaben lässt.
Einerseits bewundere ich es, wenn du deine Meinung vor allen vertrittst,
andererseits haben die anderen Forumsteilmehmer in vielen Punkten recht.
Persönliche Wertungen: Dieser Punkt wurde hier schon häufig
angesprochen, aber ich möchte auch etwas dazu sagen. Ich selbst
beschäftige mich gerne mit neuen technischen Dingen. Dabei habe ich die
Angewohnheit, meine neuen Erkenntnisse in Form von kurzen Dokus zu
Papier zu bringen, um später schnell wieder in die Materie zu finden.
Früher habe ich ebenfalls Wertungen in meine Dokus einfließen lassen.
Nach einiger Zeit las ich die Dokus wieder, um bei manchen Wertungen
fast peinlich berührt zu sein. Das war deshalb so, weil sich meine
Erkenntnisse erweitert hatten und ich das entsprechende Thema aus einer
ganz anderen Perspektive betrachtete. Derartige Wertungen lesen sich
unprofessionell und naiv.
Datenblätter: Dass Atmel die übersichtlichsten Datenblätter schreibt,
haben schon einige erwähnt. Dies kann ich nur bestätigen. Der Sinn des
Datenblatt ist es, dem Entwickler schnell und kurz Infos zukommen zu
lassen. Hier muss deutlich unterschieden werden zwischen
Datenblatt-Infos und Grundwissen. Das Datenblatt enthält kein
Grundwissen, weil es den Rahmen sprengen würde und der Entwickler dann
sehr lange suchen müsste, um an die wichtigen Infos zu kommen, die er
benötigt. Deshalb eignet sich ein Datenblatt nur begrenzt zur
Einarbeitung für einen Neuling. Zur Unterstützung benötigt der Anfänger
Bücher und Homepages. Erst mit deren Hilfe lässt sich nach und nach das
Datenblatt verständlich entschlüsseln.
Motivation: Es sieht so aus, als bestünde deine Motivation, ein Buch zu
schreiben, darin, dem Anfänger etwa in die Hand zu geben, weil die
Datenblätter von Atmel scheinbar so schlecht sind und weil man überall
im Internet so viel suchen muss, um überhaupt etwas Brauchbares zu
finden. Das macht keinen Spaß, sondern ist anstrengend und das liest man
auch raus.
Deine Motivation sollte aber darin bestehen, zu zeigen, welche Freude es
bereitet, sich mit dieser faszinierenden Welt der Mikrocontroller
auseinanderzusetzen. Dabei solltest du den Anfängern das Handwerkszeug
vermitteln, um ihnen ein schnelles Einarbeiten in die Datenblätter zu
ermöglichen. Wenn du deinen Lesern diese spannende Welt, bei welcher es
ständig etwas Neues zu entdecken gibt, auf diese motivierende Weise
näher bringst, werden die Leute gerne dein Buch lesen.
In diesem Sinne wünsche ich euch allen noch ein Gutes Neues Jahr.
Schöne Grüße
Martin
jdhenning schrieb:> Es ist nicht so, dass ich wissenschaftlichen> Stil nicht könnte. Ich will ihn nicht, denn er würde noch mehr Leser> abschrecken, als eine Handvoll flapsiger Bemerkungen. Als Stephen> Hawking sein Buch "Eine kurze Geschichte der Zeit" schrieb, wurde ihm> vom Verleger aufgetragen: "Jede Formel halbiert die Anzahl der Käufer!".> Aber auf die Formel E=mc² wollte er nicht verzichten.
Naja, "Einee kurze Geschichte der Zeit" ist auch kein Fachbuch, auch
kein Buch um Anfänger in die Moderne Physik einzuführen, sondern
schlicht und ergreifend Populärwissenschaft. Ein Buch das den Anspruch
an ein Fachbuch hat (auch wenn es für Anfänger ist) muss die notwendigen
Formeln enthalten und auch sauber erklären. Ebenso ist ein
wissenschaftlicher Stil angebracht, der aber durchaus locker sein darf.
Persönliche Meinungen, wie schon häufiger angesprochen, gehören aber
nicht hinein. Wenn du deine Meinung und ein bisschen Prosa verbreiten
möchtest, mach ein Videoblog...oder ändere den Titel in "Eine kurze
Geschichte des AVRs - Aus dem Leben eines Ingenieurs."
Wenn ich heute noch einmal mit µCs anfangen würde, dann fände ich ein
Buch nach dem Moto "Vom Arduino zum ersten eigen Mikrocontrollerboard -
Ein Einstieg in die Welt der Mikrocontroller" echt super. Angefangen mit
erprobter und einfacher Hard- und Software, zu einem eigenen Projekt.
Mit Erkärungen wie man Datenblätter liest, anständige Software schreibt
(auch fernab der Arduinolibs) und sich passendes Wissen beschafft. Das
wäre meiner Meinung nach ein echtes modernes Anfängerbuch.
Bitte, bitte, nehme dir die Kritik von uns allen zu Herzen und denke gut
darüber nach. Du bist motiviert und hast eine tolle Idee, nun mach auch
noch den Schuh voll daraus, auch wenn es noch ein ordentlicher Batzen
Arbeit ist. Viel Erfolg damit und ein Frohes Neues.
Nase schrieb:> . Ein Fachbuch dient nicht der Theoriefindung. Wenn tausend Leute es> seit zwanzig Jahren auf die Art und Weise X machen, dann nennt man das> etabliert.
Äh nein. Das heißt weder das es der einzige weg, noch das es der beste
Weg war oder ist. Sondern nur das es die Leute bis jetzt so gemacht
haben.
Einmal andere Wege gehen oder anders Denken war schon immer eine gute
Idee, egal in welchem Bereich.
mfg
Lord of Lightning schrieb:> Wenn ich heute noch einmal mit µCs anfangen würde, dann fände ich ein> Buch nach dem Moto "Vom Arduino zum ersten eigen Mikrocontrollerboard -> Ein Einstieg in die Welt der Mikrocontroller" echt super.
Die Idee ist wirklich gut. Am Anfang hat man erstmal funktionierende
Hardware ohne viele notwendige Erklärungen (und Fehlerquellen). Und kann
davon ausgehend beliebig ins Detail gehen. Dazu vielleicht noch eine
einfache aber vernünftige Entwicklungsumgebung auf DVD wie Ralph S. es
plant.
Ausgehend von dieser festen Basis, kann man dem Leser wirklich zumuten
sich fehlende E-Technik Kenntnisse woanders zu holen, solange es einige
gut erklärte Beispiele mit grundlegenden Erklärungen gibt.
Die Anzahl der potentiellen Leser sollte auf jedem Fall deutlich größer
sein, als die bisherige anvisierten: >50 Jahre alte E-Techniker, die
zuletzt vor 20 Jahren was mit MCU gemacht haben und sich jetzt beim
Wiedereinstieg mit englisch-sprachigen Datenblätter schwertun.
Nase schrieb:> An etlichen Stellen kritisierst du etwas, weil du es nicht verstanden> hast. Zum Beispiel die Sache (auf die du ja wieder nicht eingegangen> bist) mit dem vermeintlich fehlenden PCINT.
Ich weiß, warum die Lücke da ist und ich hätte da auch kein Problem mit,
wenn sie erklärt werden würde. Noch besser hätte ich jedoch eine andere
Benennung gefunden, etwa EXIB0, EXIB1 usw. (EXterner Interrupt über port
B, Eingang 0) oder irgendetwas ähnliches. Dann würde es solche
Irritationen überhaupt nicht geben können und mir keine flapsige
Bemerkung ermöglichen.
Auch der Umstand, dass INT0 und PCINT18 sowie INT1 und PCINT19 sich
überlagern, kann man verstehen, wenn einem der dahinter stehende
Mechanismus klar ist; da das bei einem Newbie eher nicht der Fall sein
wird, hat der dann einige Fragezeichen über dem Kopf schweben. In einem
Datenblatt mit 650 Seiten sollte bei solchen Sachen ja wohl Platz nicht
der Grund sein, dass man das nicht kurz erklärt (das Datenblatt wird ja
eh nicht gedruckt).
Es gibt den schönen Spruch: "Der größte Feind des Guten ist nicht das
Böse, sondern das Bessere!" Es geht mir nicht darum, das Datenblatt von
Atmel nieder zu machen (es ist ja sowieso unverzichtbar).
Wie ich am Anfang des Textes geschrieben habe, sind etwa die
Einleitungen zu den einzelnen Kapiteln im Datenblatt für einen Newbie
nicht verstehbar, weil sie die Kenntnis des Inahlts des Kapitels
voraussetzen (für einen alten Hasen sind sie verstehbar, aber absolut
unnötig). Bei 340 oder 650 seitigen Datenblättern gibt Atmel ja eine
Menge Geld aus, um die Datenblätter schreiben zu lassen. Bei dem Aufwand
könnten die Datenblätter supergut sein, wenn die technische Entwicklung
von einem Fachjournalisten oder Fachlehrer begleitet werden würde (der
vielleicht auch die eine oder andere Ungereimtheit in den Benennungen
aufdecken darf), der das vorläufige Datenblatt dann schreibt. Nach der
späteren Diskussion mit den Fachidioten (Nerds!), wird anschließend das
Datenblatt draus.
Das würde nicht nur den Newbies enorm helfen, sondern auch den alten
Hasen, wenn sie sich bei einem Teilgebiet nicht (mehr) ganz sicher sind.
Jürgen
Tom schrieb:> Äh nein. Das heißt weder das es der einzige weg, noch das es der beste> Weg war oder ist. Sondern nur das es die Leute bis jetzt so gemacht> haben.
Äh doch, genau das heißt etabliert nämlich.
Es heißt weder, dass es der einzige Weg ist, noch dass es der beste ist.
Aber es heißt, dass der Weg aus irgendwelchen Gründen /allgemein
akzeptiert/ oder üblich ist.
> Einmal andere Wege gehen oder anders Denken war schon immer eine gute> Idee, egal in welchem Bereich.
Ja natürlich, aber nicht in einem Fachbuch für potentiell unbedarfte
Einsteiger.
Dort nämlich führt es dazu, dass besagte Anfänger sich schon nach kurzem
anderer Quellen bedienen und feststellen, dass ihre Ansicht irgendwie
anders ist, als die aller anderen. Das wiederum kann durchaus sinnvoll
sein, wenn man ein Buch über Theologie schreibt oder eine Dissertation,
die sich kritisch mit den etablierten Denkweisen auseinandersetzt.
Wenn man aber ein Fachbuch für Einsteiger schreibt, dann führt es
bestenfalls dazu, dass der Anfänger sich nach einer Weile wundert, was
er denn für einen Quatsch gelesen hat, der nicht zum Rest der Welt
passt.
Wenn ich dem Anfänger andauernd etwas über Sklaven erkläre und er sich
später mit anderen Fachkundigen unterhält, dann gibts höchstens ziemlich
fragende bis blöde Blicke. Und der Anfänger wird bald erkennen, dass
das, was er denn da meint, eigentlich bei allen anderen als Slave
geläufig ist. Und dann wird er das höchstwahrscheinlich auch akzeptieren
und ebenfalls Slave sagen und sich ärgern darüber, dass er in seinem
Fachbuch so einen Quatsch gelesen hat.
jdhenning schrieb:> Ich weiß, warum die Lücke da ist und ich hätte da auch kein Problem mit,> wenn sie erklärt werden würde.
Und warum lästerst du dann so hinterfotzig und schreibst nicht einfach
deine Erklärung hin?!
> Noch besser hätte ich jedoch eine andere> Benennung gefunden, etwa EXIB0, EXIB1 usw. (EXterner Interrupt über port> B, Eingang 0) oder irgendetwas ähnliches. Dann würde es solche> Irritationen überhaupt nicht geben können und mir keine flapsige> Bemerkung ermöglichen.
Der Begriff externer Interrupt ist aber für etwas anderes schon
eindeutig geprägt, es wäre also total unsinnig, den hier nochmal in
anderem Zusammenhang zu verwenden. Denn PCINT sind nunmal etwas Anderes,
als externe INT0/.. beim AVR. Das hat man vermieden, weil es u.a. zu
Verwirrung mit den alten Devices käme.
Eine Numerierung wie PCB0, PCB1, ... usw. fände ich allerdings auch
passender. Ich weiß aber nicht, ob das wieder Konflikte mit großen
Devices gibt, die nicht an jedem Port ein PCINT haben.
jdhenning schrieb:> Auch der Umstand, dass INT0 und PCINT18 sowie INT1 und PCINT19 sich> überlagern, kann man verstehen, wenn einem der dahinter stehende> Mechanismus klar ist; [...]
Was überlagert sich da? INT0 und PCINT18 sind völlig verschiedene
Interruptquellen und Hardwareressourcen!
Es überlagern sich ja auch RXD/TXD vom UART mit irgendeinem Pin und so
weiter.
> dass man das nicht kurz erklärt
Und warum erklärst du das dann nicht einfach?
jdhenning schrieb:> sind etwa die> Einleitungen zu den einzelnen Kapiteln im Datenblatt für einen Newbie> nicht verstehbar, [...]
Wenn man die Kapitel aber so gestaltet, wie dir es vorschwebt, dann sind
sie für Profis unpraktisch. Profis brauchen kurz, knapp und
übersichtlich, ohne viel Prosa.
Und Newbies sind nunmal nicht die Zielgruppe von Atmel, sondern Profis.
Und der Anfänger wird ja auch bald zum Fortgeschrittenen, und dann nervt
die Prosa auch da schon.
Hallo Martin, vielen Dank schon mal für den langen Post.
Martin schrieb:> Einerseits bewundere ich es, wenn du deine Meinung vor allen vertrittst,> andererseits haben die anderen Forumsteilmehmer in vielen Punkten recht.
Haben sie auch, aber wenn sie es in einem Ton vortragen, der
Unterwerfung verlangt, dann wird irgendwo in meinem Hinterkopf
Widerstand zur Pflicht.
> Derartige Wertungen lesen sich unprofessionell und naiv.
Das Problem sind die unterschiedlichen Blickwinkel. Bei einem
Uni-Lehrbuch wären solche Wertungen absolut tabu! Auch wenn das Buch für
Schulen und Berufsschulen gedacht wäre, wären solche Bemerkungen ein
absolutes "No go!" Ich habe jetzt das Rohmanuskript einem Haufen Nerds
vor die Füße geworfen, die beleidigt sind, weil ich sie als komplette
Fachidioten bezeichnet habe (man könnte auch von kalkulierter
Provokation sprechen, aber das ist jetzt nicht das Thema). Bisher bin
ich absolut zufrieden, denn es wurden noch keine schwerwiegenden
sachlichen Fehler gefunden (da muss mal wieder ein bisschen Öl ins
Feuer!).
> Datenblätter: Dass Atmel die übersichtlichsten Datenblätter schreibt,> haben schon einige erwähnt......
Das Datenblatt wäre überhaupt kein Problem, wenn es eine gute Einführung
geben würde (es wurden bisher, glaube ich, 4 alternative Bücher hier
genannt); nur eines davon könnte (meiner Meinung nach!) gut geeignet
sein; ich habe es aber nicht gelesen und enthalte mich daher der Meinung
(allerdings hatte mich die Werbung für das Buch davon abgehalten,
überhaupt einen Blick ins Innere werfen zu wollen).
> Motivation: Es sieht so aus, als bestünde deine Motivation, ein Buch zu> schreiben, darin, dem Anfänger etwa in die Hand zu geben, weil die> Datenblätter von Atmel scheinbar so schlecht sind und weil man überall> im Internet so viel suchen muss, um überhaupt etwas Brauchbares zu> finden. Das macht keinen Spaß, sondern ist anstrengend und das liest man> auch raus.
[Ironie]Das hast du gut erkannt![/Ironie]
> Deine Motivation sollte aber darin bestehen, zu zeigen, welche Freude es> bereitet, sich mit dieser faszinierenden Welt der Mikrocontroller> auseinanderzusetzen. Dabei solltest du den Anfängern das Handwerkszeug> vermitteln, um ihnen ein schnelles Einarbeiten in die Datenblätter zu> ermöglichen. Wenn du deinen Lesern diese spannende Welt, bei welcher es> ständig etwas Neues zu entdecken gibt, auf diese motivierende Weise> näher bringst, werden die Leute gerne dein Buch lesen.
Das funktioniert rein psychologisch nicht. Wenn ich jemanden begeistern
kann und ihm dann das Datenblatt gebe, dann sehe ich am Abend tiefe
Furchen auf der Stirn und am zweiten Tag schwarze Wolken überm Kopf.
Danach sehe ich ihn nie wieder. Der Weg muss also anders herum gehen.
Jemand hat eine Projektidee und glaubt, dass MCUs hilfreich sein
könnten; alleine schon wegen der Menge an Information, die er
verarbeiten soll/muss, wappnet er sich mit einem großen Päckchen an
Geduld. DEN will ich dahin bringen, dass er von MCUs begeistert ist.
Gruß
Jürgen
jdhenning schrieb:> Bei einem> Uni-Lehrbuch wären solche Wertungen absolut tabu!
Die sind auch in deinem Buch absolut tabu.
Aber auch aus einem anderen Blickwinkel: Sie machen das Buch weder
interessanter oder informativer, noch lustiger oder lockerer Auch stören
sie den Lesefluss andauernd und lenken vom Thema ab.
Effektiv haben sie also auf dein Buch keinerlei positiven, ja
irgendwie verwertbaren Einfluss. Sie bringen garnichts, es gibt keinen
vernünftigen Grund, diese Passagen zu behalten.
Sie dienen einzig und alleine dir, vielleicht Frust loszuwerden oder
dein Ego zu bestärken -- weiß ich nicht. Aber das Buch soll dem Leser
dienen.
jdhenning schrieb:> [...] DEN will ich dahin bringen, dass er von MCUs begeistert ist.
Aber nicht, indem du auf jeder zweiten Seite schreibst, wie blöd
irgendeine Bezeichnung ist. Oder wie unsauber etwas gelöst ist. Oder
oder oder.
Das ist psychologisch Schwachsinn.
Psychologisch sinnvoll wäre, dem Leser einen Gedankengang zu
präsentieren, mit dem er sich zum Bleistift das vermeintlich fehlende
PCINT-Bit merken kann, sodass er versteht, dass es nicht willkürlich
ist. Ob dir persönlich das nun gefällt, ist völlig unerheblich. Das
würde dem Leser auch vermitteln, dass die Materie konsistend
verständlich ist und nicht aus einem Haufen zusammengewürfelter
Ausnahmen besteht. Das ist psychologisch sinnvoll, denn der Leser
ergründet Systematik, die er begreifen kann.
Momentan ist dein Buch etwa so:
Lieber Leser, das ist jetzt ein bisschen blöd, da müssen Sie jetzt noch
durch. Gleich kommt wieder eine etwsa zähere Passage. Das folgende Bit
ist dann so und so (vermutlich um den Benutzer zu verwirren). Hier ist
noch eines (das hätte man meiner Meinung nach auch anders nennen
können).
Ne!
Lord of Lightning schrieb:> Naja, "Eine kurze Geschichte der Zeit" ist auch kein Fachbuch, auch> kein Buch, um Anfänger in die Moderne Physik einzuführen, sondern> schlicht und ergreifend Populärwissenschaft.
Ich hatte mir dieses Buch vor langer Zeit mal vor einer Bahnfahrt
gekauft und auf 'leichte' Unterhaltung gehofft. Es sieht
populärwissenschaftlich aus, der Stil des Textes passt auch zu der
Vermutung, aber wenn man anfängt wirklich über den Inhalt nachzudenken,
steckt man plötzlich mitten in der theoretischen Physik. Genial und
gemein.
> Wenn ich heute noch einmal mit µCs anfangen würde, dann fände ich ein> Buch nach dem Moto "Vom Arduino zum ersten eigen Mikrocontrollerboard -> Ein Einstieg in die Welt der Mikrocontroller" echt super.
Kann ich nachvollziehen. Genau so ein Buch hätte ich auch gerne gekauft
(obwohl ich vor 1 1/2 Jahren noch nicht wusste, wer oder was Arduino
ist).
> Mit Erkärungen wie man Datenblätter liest,.....
Wenn du da eine Quelle hast, kannst du die bitte veröffentlichen. Ich
kenne keine und bin sogar der Meinung, dass es keine geben kann. Die
einzige Anweisung, die ich kenne, lautet "langsam und gründlich!".
Tschüs und Danke für den Post
Jürgen
Hallo Jürgen,
zunächst einmal meinen ausdrücklichen Respekt! Ein Buchprojekt, welcher
Art auch immer, erfordert Mut und Ausdauer.
Einige Anmerkungen zu Deinem Manuskript. Dabei gehe ich ausdrücklich
NICHT auf den Inhalt ein. Hier gehe ich davon aus, dass er korrekt ist.
Das Buch liest sich sehr schlecht. Das hat aus meiner Sicht mehrere
Ursachen.
1. Du wechselst ständig zuwischen einer sehr sachlich nüchternen
Schreibweise und einer sehr persönlich emotionalen Schreibweise. Ein
Fachbuch sollte möglichst überhaupt keine persönlichen Befindlichkeiten
beinhalten.
2. Du wechselst ständig zwischen den Zeitformen. Ers gibt sogar im Satz
Sprünge zwischen Vergangenheit und Zukunft. Ein Fachbuch sollte
möglichst in einer Zeitform (Gegenwart) geschrieben sein.
3. Deine Syntax geht bunt durcheinander. Du verwendest mal Klammern, mal
Hochkomma, mal Gänsefüßchen, mal kursiv...
4. Die Orthografie und Zeichensetzung ist mangelhaft.
5. Der Ausdruck ist oft sehr naiv.
6. Bilder und Tabellen würden Deinen Text an vielen Stellen
verständlicher gestalten.
7. Es gibt viele „Schusterjungen“ und „Hurenkinder“.
8. Du verwendest den falschen Trennstrich.
All diese Dinge führen zu einer sehr schlechten Lesbarkeit und Ermüdung
beim Lesen. Wenn Du magst, sende ich Dir ein professionelles
Layoutschema zu.
Moin Tom.
Tom schrieb:> Einmal andere Wege gehen oder anders Denken war schon immer eine gute> Idee, egal in welchem Bereich.
Ich will jetzt nicht schulmeistern, aber ganz knapp daneben: "Nicht
auszuschließen, auch einmal andere Wege zu gehen, war schon immer eine
gute Idee!"
Eine Variante ist: "Wer Spuren hinterlassen will, sollte nicht dort lang
gehen, wo alle anderen schon waren!"
Danke für den Post & Tschüs
Jürgen
Klaus I. schrieb:> Die Anzahl der potentiellen Leser sollte auf jedem Fall deutlich größer> sein, als die bisherige anvisierten: >50 Jahre alte E-Techniker, die> zuletzt vor 20 Jahren was mit MCU gemacht haben und sich jetzt beim> Wiedereinstieg mit englisch-sprachigen Datenblätter schwertun.
Ich habe es zwar schon ein paar mal gepostet, aber für dich mache ich es
noch einmal: Zielgruppe sind diejenigen, die irgendein Projekt vorhaben
und vermuten, dass MCUs ihnen bei der Realisierung helfen könnten.
Und deine Vermutung (Behauptung?) über meine Englischkenntnisse geht
voll daneben. Du müsstest englischer Muttersprachler sein, um heraus zu
hören, dass ich es nicht bin (hast du auch das Buch "Der kleine
Hobbypsychologe" geschenkt bekommen?).
Gruß
Jürgen
jdhenning schrieb:> Und wozu die künstliche Aufregung? Wenn das Geschreibsel so mies ist,> dann wird es entweder keinen Verleger oder später keine Käufer finden.> Wo also ist das Problem?
So ist es.
Niemand muß ein Buch schreiben, niemand muß es verlegen, niemand muß es
kaufen, und niemand muß es lesen. Nichts muß, alles kann.
Bisher ist noch nichts davon geschehen, und damit nichts passiert. Den
Rest wird die Zeit zeigen.
Oliver
Der jdhenning wird sich dem jetzt annehmen und das beste aus den
Kommentaren mitnehmen um sein Buch fertig zu bekommen.
Ich würde es wahrscheinlich noch mal neu machen, man kann dann eine
passendere Struktur erzeugen und dann die Teile aus dem alten Buch an
die passende Position des neuen Buchs kopieren.
Jetzt muss er erst mal sein Buch weiter schreiben, Dinge verändern,
entfernen und hinzufügen.
Jeder der das eBuch hat kann mit ihm in Kontakt treten und er kann in
ein paar Monaten noch mal sein Buch oder nur einen Teil davon vorstellen
wenn er mag.
Oder er informiert per PN einfach die angemeldeten Nutzer die sich in
seinem Thread sinnvoll geäußert haben dass er auf seiner Webseite eine
neue Version des Buches hochgeladen hat und wie das neue Passwort heißt.
jdhenning schrieb:> Du müsstest englischer Muttersprachler sein, um heraus zu hören, dass> ich es nicht bin
Dass du was nicht bist?
Nochmal mein Tipp: es fehlen in diesem Buch mindestens 100 Bilder,
Skizzen, Abbildungen und Diagramme.
Meine HP (Thema VHDL) ist z.B. auch ein "Abfallprodukt" meiner Arbeit
Mut FPGAs (ich habe dazu noch gut 500 weitere Designs auf dem Rechner).
Und für diese HP bekomme ich einiges an Lob, weil es sowas zumindest in
Deutschland offenbar nicht gibt. Und dort verwerte ich keine einzige
Zeile aus einem Datenblatt, sondern nehme mir alltägliche Probleme mit
vielen Bildern zur Brust...
Grüße Allerseits,
komme erst jetzt wieder dazu hier nachzuschauen.
Hallo Jürgen,
In Bezug auf Fachausdrücke möchte ich auch vorschlagen, daß Du Dich
STRIKT an die Konvention und Sprache der Hersteller Literatur
(Datenbücher, Application Notes, Beispielprogramme, e.t.z.) hältst. Also
sollten nur englische Fachausdrücke allgemein gebraucht werden. Als
Hilfe für den Leser erstelle aber eine Wortliste mit den wichtigsten
Fachausdrücken für die es etablierte Deutsche Ausdrücke gibt. Obwohl das
am Anfang für den Leser bestimmt etwas umständlich ist, lernt er dann
viel mehr. Wahlweise könntest Du auch ggf. Fußnoten machen. Wenn er dann
endlich die Ausdrücke kennt tut er sich beim Studieren des Datenblattes
viel leichter.
Dieser Vorschlag hat den Vorteil daß es beim Suchen in der offiziellen
Hersteller Literatur keine Zweifel an der Trefflichkeit des Ausdruckes
gibt. So sollten z.B. alle PIN-Namen, Registernamensabkürzungen und
IC-Referenzen, genau wie im Datenblatt gefunden, sich im Buch
wiederfinden.
Ich bin der Ansicht, daß man in der Technik nicht um die englische
Sprache herum kommt und sich da einfach durchbeißen muß. Mir ging es
einmal in der Firma in D genauso wo es bis auf ein paar Ausnahmen
praktisch nur englische Datenbücher(oder noch schlimmer: Franz/Ital.)
gab (1970er). Es war damals (trotz Englischunterricht in der Schule)
eine richtige Qual für mich. Literatur ist eben doch nicht mit
Fachenglisch vergleichbar. Und das Internet wie wir es heute kennen gab
es auch nicht. Ich weiß, ich kann jetzt leicht Sprüche machen, da ich
schon fast 40 Jahre in einem Englischsprechenden Land lebe.
Ich mußte mal in der Firma eine Deutschsprachige EN Vorschrift ins
Englische übersetzen. Das war gar nicht leicht weil ich wiederum viele
Deutsche Technikausdrücke nicht kannte und mußte beträchtlich
recherchieren um zu verstehen was gemeint war.
Ist nur meine Meinung, also nichts für ungut.
Schönen Abend noch,
Gerhard
P.S. Wie üblich, jetzt bitte keine Steine werfen - Das tut so weh...;-)
Nabend Nase.
Nase schrieb:>> Ich weiß, warum die Lücke da ist und ich hätte da auch kein Problem mit,>> wenn sie erklärt werden würde.> Und warum lästerst du dann so hinterfotzig und schreibst nicht einfach> deine Erklärung hin?!
Ich lästere da überhaupt nicht hinterfozig. Wenn ich hinterfozig läster,
dann merkst du das daran, dass dir die Haare nach hinten wehen!
> Der Begriff externer Interrupt ist aber für etwas anderes schon> eindeutig geprägt, es wäre also total unsinnig, den hier nochmal in> anderem Zusammenhang zu verwenden.
Wenn du jetzt behauptest, dass die PCINTs interne Inerrupts sind, dann
diskutier ich nicht mehr mit dir!
>> Auch der Umstand, dass INT0 und PCINT18 sowie INT1 und PCINT19 sich>> überlagern, kann man verstehen, wenn einem der dahinter stehende>> Mechanismus klar ist; [...]> Was überlagert sich da? INT0 und PCINT18 sind völlig verschiedene> Interruptquellen und Hardwareressourcen!
Hier überlagern sich aber zwei externe Interrupts und ich fände es schon
sinnvoll zu erklären, warum man INT0 und INT1 dann beibehält.
> Und warum erklärst du das dann nicht einfach?
Ganz einfach: NOT MY JOB!
>> Einleitungen zu den einzelnen Kapiteln im Datenblatt für einen Newbie>> nicht verstehbar, [...]> Wenn man die Kapitel aber so gestaltet, wie dir es vorschwebt, dann sind> sie für Profis unpraktisch.
Wie kommst du auf die Idee, dass sich gute Erklärungen gegenseitig
ausschließen müssen?
> Profis brauchen kurz, knapp und übersichtlich, ohne viel Prosa.
Wie kommst du auf die Idee, dass das bei einem Newbie anders ist? Der
Unterschied ist, dass dem Newbie das Hintergrundwissen fehlt, das der
Vollprofi seit langem hat. Wenn man sich ein bisschen Mühe gibt, dann
lässt sich das doch problemlos entzerren. Teil 1 eines Kapitels:
Möglichst einfache Erklärung des Sachverhaltes ohne Nennung von
Detail-Fakten; Teil 2: Die harten Fakten, die der Profi will und die der
Newbie später auch braucht; ich sehe noch nicht einmal ansatzweise,
warum sich das gegenseitig behindern sollte/könnte.
> Und Newbies sind nunmal nicht die Zielgruppe von Atmel, sondern Profis.
Und warum, glaubst du, dass Atmel das Atmel-Studio heraus gebracht hat?
Weil Profis das benutzen? Und Abgesang!
Tschüs
Jürgen
Auch wenn dieses Buch es möglicherweise niemals in die Regale von
Hudendooble und sonstigen, die bisher noch gut von der Buchpreisbindung
leben können, schafft, finde ich es trotzdem gut, dass sich jemand
hinsetzt und ein kompaktes Werk über einen µController verfasst, der dem
Neueinsteiger bis zum 14. Januar quasi kostenlos zur Verfügung gestellt
wird. Tatsächlich interessierte Nerds können sich anhand diesem "Online
Lektorat" zusätzliche Kenntnisse aneignen.
Thumbs up!
Lothar Miller schrieb:> Und für diese HP bekomme ich einiges an Lob,
Du wist zugeben müssen, dass du mit deiner Homepage nicht die gleichen
Reaktionen erreichen kannst, wie sie der TO hier problemlos erreicht.
Dafür stehen dir einfach zuviele Hindernisse im Weg: tiefgehendes
Verständnis des Themas, Blick für das Wesentliche, Erfahrung, ... Zudem
hege ich den Verdacht, dass du schon Leute ausgebildet hast und dadurch
vorbelastet bist.
@jdhenning
Dir habe ich dahingehend nichts vorzuwerfen.
jdhenning schrieb:> Ich lästere da überhaupt nicht hinterfozig. Wenn ich hinterfozig läster,> dann merkst du das daran, dass dir die Haare nach hinten wehen!
Ja, das war jetzt genauso provokant, wie Nerds als Fachidioten zu
bezeichnen. Oder "Fucking momsers" auf Seite 95.
Also, warum erklärst du es nicht sondern schreibst
> (und den PCINT15 hat man wahrscheinlich ausgelassen, um die Nutzer> etwas zu verwirren; oder jemand bei Atmel kann nicht zählen).
?
jdhenning schrieb:> Wenn du jetzt behauptest, dass die PCINTs interne Inerrupts sind, dann> diskutier ich nicht mehr mit dir!
Nein, schreib ich nicht.
Aber als die ersten AVR rauskomen, war mit 'Externer Interrupt' nur
INT0/INT1 usw. gemeint. Die ungruppierten Interrupts halt. Deren
Hardware-Aufbau (und Funktion) unterscheidet sich aber fundamental von
den PCINT. Darum hat man dafür den Begriff "Pin Change Interrupt"
geprägt. Das sollte der Verwirrung vorbeugen.
jdhenning schrieb:> Hier überlagern sich aber zwei externe Interrupts und ich fände es schon> sinnvoll zu erklären, warum man INT0 und INT1 dann beibehält.
Und warum erklärst du es dann nicht?
Man behält INT0 und INT1 bei, weil die anders funktionieren, wie die
PCINT. Und weil man kompatibel zu der Vorserie sein will.
Es überlagern sich überall Dinge. Auch Timer-Aus- und Eingänge. Die
Pins für den Systemquarz und den externen T2-Quarz. Bei den großen
Bausteinen gibts sogar getrennte SPI-Ports für ISP und normales SPI.
jdhenning schrieb:> Ganz einfach: NOT MY JOB!
Achso, ich dachte, gerade DU störst dich an der Undurchsichtigkeit der
Datenblätter und hast dir auf die Fahne geschrieben, den Einsteiger an
die Hand zu nehmen?!
Ins Datenblatt gehörts jedenfalls nicht noch ausführlicher, denn da ist
es jetzt schon eindeutig und nachvollziehbar.
Ja, nicht für Einsteiger. Das ist aber nach wie vor nicht die Zielgruppe
des Datenblatts, sondern deine.
jdhenning schrieb:> Wie kommst du auf die Idee, dass sich gute Erklärungen gegenseitig> ausschließen müssen?
Müssen sie nicht.
jdhenning schrieb:> Wie kommst du auf die Idee, dass das bei einem Newbie anders ist? [...]
Tut es ja auch nicht. Und wenn ich dir jetzt sage, dass z.B. die
AVR-Datenblätter schon sehr vernünftig sind, dann siehst du das ja doch
wieder anders. Die Datenblätter sind nicht für Newbies geschrieben.
Sie setzen Wissen voraus, und zwar ziemlich viel. Und das ist völlig
normal.
. Wenn du C programmieren möchtest, solltest du C können. Sonst lies
einschlägige C-Literatur. Nicht die Aufgabe eines Datenblatts.
. Wie man einen AVR in eine Schaltung eindesignt, ist in etlichen
Appnotes beschrieben. Schaltungstechnik solltest du beherrschen. Sonst
lies oder studier. Nicht die Aufgabe eines Datenblatts.
. Wie man die Toolchain bedient, steht in deren Dokumentation, und die
ist ausführlich genug. Nicht die Aufgabe eines Datenblatts.
. Wenn du einen UART brauchst, solltest du wissen, wie ein UART
funktioniert. Dazu gibt es offizielle Standards in DIN und ISO, an die
du dich halten kannst. Oder an etliche Bücher zu Computerschnittstellen
(Schnittstellenhandbuch von Elsing/Wienck z.B., gabs schon 1986. Wenn du
das dann weißt, kannst du dir angucken, wie genau man die
UART-Schnittstelle des AVR parametriert. Es ist nicht Aufgabe des
Datenblattes, dir eine serielle Schnittstelle zu erklären. Du sollst
wissen, wie so eine funktioniert und wirst dann wiederfinden, was es zu
konfigurieren gibt.
. Wenn du I2C brauchst, gibt es einen Standard dazu. Und viel Literatur
von Philips. Da kannst du nachlesen, wie I2C funktioniert. Es ist nicht
Aufgabe des Datenblatts, dir das zu erklären. Danach kannst du im
Datenblatt nachschauen, wie es mit der spezifischen I2C-Hardware im AVR
geht.
Das ist total ernüchternd, weiß ich. Aber in der Handbuch deines Autos
stehen auch keine Verkehrsregeln drin, oder?
Wenn du Verkehrsregeln lernen willst, geh in eine Fahrschule. Im
Handbuch deines Autos steht dann drin, wie du die Dinge, die du in der
Fahrschule gelernt hast, konkret in deinem Auto umsetzen kannst.
Genauso ist ein Datenblatt gedacht.
Nimm mal größere Controller wie c168 oder gleich FPGAs. Wie willst du
denn mit solchen Datenblättern umgehen?!
Bei XILINX besteht das Datenblatt zu einem durchschnittlichen FPGA aus
fünf einzelnen Dokumenten à geschätzten 100 Seiten. Das Datenblatt! Und
damit designst du ganz sicher nicht eine Schaltung im/mit FPGA. Dazu
kommen dann nochmal ein paar tausend Seiten Doku zu der Toolchain und so
weiter!
Oder beim c168, da hast du ein Datenblatt ähnlich des AVR und dann kommt
dazu ein etwa dreimal so dickes Rationale. Und selbst da steht noch
keine Einführung in die serielle Schnittstelle drin.
>> Und Newbies sind nunmal nicht die Zielgruppe von Atmel, sondern Profis.> Und warum, glaubst du, dass Atmel das Atmel-Studio heraus gebracht hat?> Weil Profis das benutzen? Und Abgesang!
Ja. Warum sonst? Und weils günstig war, sich aufs Visual Studio
aufzusetzen und praktisch eine vollwertige IDE geschenkt zu kriegen. Der
Materialaufwand hält sich echt in Grenzen. Die IDE kommt von Microsoft
und die Toolchain ist Open Source. Ok, Atmel steuert viele Patches bei.
Guten Abend Joe,
schon gleich mal vielen Dank für den langen Post.
Joe G. schrieb:> Das Buch liest sich sehr schlecht. Das hat aus meiner Sicht mehrere> Ursachen.> 1. Du wechselst ständig zuwischen einer sehr sachlich nüchternen> Schreibweise und einer sehr persönlich emotionalen Schreibweise. Ein> Fachbuch sollte möglichst überhaupt keine persönlichen Befindlichkeiten> beinhalten.
Ich weiß nicht (im Gegensatz zu vielen anderen hier) ob mein
Stilexperiment Erfolg habe wird. Ich habe versucht so zu schreiben, wie
ich es meinem besten Kumpel erklären würde (und da wären, wie schon
früher angemerkt, sehr viel mehr Kommentare bei). Ich versuche also
nicht, ein Fachbuch oder Lehrbuch zu schreiben (obwohl es letztlich
beides ist), sondern ein Lernbuch.
> 2. Du wechselst ständig zwischen den Zeitformen. Es gibt sogar im Satz> Sprünge zwischen Vergangenheit und Zukunft. Ein Fachbuch sollte> möglichst in einer Zeitform (Gegenwart) geschrieben sein.
Danke für den Hinweis. Das 'ständig' möchte ich bezweifeln, ich gehe
aber noch einmal durch den Text.
> 3. Deine Syntax geht bunt durcheinander. Du verwendest mal Klammern, mal> Hochkomma, mal Gänsefüßchen, mal kursiv...
Das ist relativ unwichtig, denn es wird keine spezielle
Bedeutungs-Definition damit verbunden.
> 4. Die Orthografie und Zeichensetzung ist mangelhaft.
An erstem hat demnach Open-Office Schuld (falls du die Interrupe meinst,
die wurden schon geändert) und Kommas waren noch nie meine Stärke.
Deshalb will ich ja auch über einen Verlag gehen. Aber mal ganz ehrlich:
Wer stört sich denn in einem Sach/Lern-buch an Kommasetzung? Da hat man
normalerweise ganz andere Sorgen.
> 5. Der Ausdruck ist oft sehr naiv.
Kannst du ein paar Beispiele geben? Ich verstehe nicht, was du meinst.
> 6. Bilder und Tabellen würden Deinen Text an vielen Stellen> verständlicher gestalten.
Wurde schon mehrfach (und berechtigterweise) eingefordert. War und ist
auch geplant und wird kommen (ich wollte nur erstmal einen Verriß
riskieren, bevor ich noch mehr Arbeit in das Manuskript reinstecke).
> 7. Es gibt viele „Schusterjungen“ und „Hurenkinder“.
Stimmt, denn es ist ein Rohmanuskript (habe ich aber auch geschrieben!);
das gilt auch für Tabellen, die letzlich unnötigerweise über
Seitengrenzen gehen.
> 8. Du verwendest den falschen Trennstrich.
Das wird der Verlag sicherlich richten.
> All diese Dinge führen zu einer sehr schlechten Lesbarkeit und Ermüdung> beim Lesen. Wenn Du magst, sende ich Dir ein professionelles> Layoutschema zu.
Danke für das Angebot [Ironie] Falls ein Layoutschema für deutlich
besseres inhaltliches Verständnis sorgen könnte, wäre das natürlich
super![/Ironie]. Da, wie gesagt, der Weg über einen Verlag führen soll,
wird dies nicht nötig sein.
Und die "sehr schlechte Lesbarkeit" zweifel ich mal pauschal an, bis du
Beispiele für diese Aussage bringen kannst (hättest du geschrieben
"nicht optimal" hätte ich das mit internem Maulen hinnehmen müssen; das
"sehr schlecht" bingt dich jetzt aber in die Bringeschuld und mit
mindestens 8 Beispielen solltest du nicht überfordert sein; oder war das
mal wieder ein Dumpfnudelkommentar?).
Viel Spaß beim Suchen nach aussagekräftigen Passagen.
Jürgen
Danke für deine Zeit & Tschüs
Jürgen
Wolfgang Schmidt schrieb:> Jetzt lasst den Jürgen doch schreiben, wie er möchte.> Es wird einen Lektor im Verlag geben, der ihm dann weiterhelfen wird.
(sic!)
Und wenn dem Lektor mein Stil nicht passt, dann wird er es mir auch sehr
deutlich kommunizieren (oder einfach ändern, ohne mich zu fragen).
"Sic" ?
Ich dachte Latein ist eine tote Sprache. Ist anscheinend doch nicht ganz
kapputt zu kriegen :-)
Sah einen hübschen Spruch:
Die Politik ist ein Versuch der Politiker, zusammen mit dem Volk mit den
Problemen fertig zu werden, die das Volk ohne die Politiker niemals
gehabt hätte. (Dieter Hildebrandt)
Atmega8 Atmega8 schrieb:> Der jdhenning wird sich dem jetzt annehmen und das Beste aus den> Kommentaren mitnehmen, um sein Buch fertig zu bekommen.
Yepp!
In dem Film 'Breaveheart' mit Mel Gibson ist eine der Schlüsselszenen,
dass er (unaufgefordert/unerwünscht) zur Versammlung der Truppenführer
reiten will. Ein Kumpan fragt ihn: "Warum willst du das machen?" und er
antwortet: "Ich suche Streit!"
Ich habe hier im Forum bisher einiges an Verbesserungsvorschlägen
bekommen (ganz vielen Dank dafür), und auch einiges an Pöbelei (trotzdem
Danke).
In diesem Sinne die Frage: "Falls ihr ein vernünftiges Buch über die
AVR-Reihe für sinnvoll haltet: Habt ihr echt nicht mehr drauf als das
bisschen kindliches Gepöbel?" Nur keine Scheu, ICH kann das ab (ob
jemand die Antwort abkann, sollte er sich überlegen, bevor er sich
äußert [no captives!])!
Schönen Tag noch!
Jürgen
Wahnsinn !
Ich schreibe auch gerade kein Buch aber so was ähnliches ;-)
Mir fehlt leider etwas Feedback, obwohl ich eigentlich genug
Versuchskaninchen haben müsste, da ich als Laboringenieur an einer
Hochschule arbeite und auch uC Labore betreue.
Egal, Jürgens Beispiel hat mich ermutigt meine eigenen Ergüsse die in
vielen Teilbereichen noch recht lückenhaft sind einem breiteren Puplikum
vorzustellen.
Es ist kein Konkurrenzprodukt, da es PIC Controler behandelt.
Ich werde mal einen *Das PIC18 Buch* Thread starten ...
Du bist ja nicht bereit, simpelste Dinge anzunehmen.
Hier im Thread haben dir nun 50 Leute gesagt, dass der emotionale,
wertende Stil unpassend ist. Und dennoch.
Jetzt wirst du entweder meinen Post ignorieren oder bemängeln, dass es
nur 49 Leute waren. Aber auf den Kritikpunkt gehst du nicht ein, weil er
unbequem ist.
Ich hab jetzt auch oft genug auf verschiedentliche Weise versucht,
solche Dinge an dich heranzutragen, aber du schmetterst nach wie vor
alles ab. Viele Leute haben Dinge an dich herangetragen. Und du
schmetterst alles ab.
Nach dem Beitrag
Beitrag "Re: ATmega8: Das Buch"
aber hast du dich in meinen Augen gänzlich disqualifiziert.
Ich habe mich hinsichtlich des Satzes noch zurückgehalten, weil ich
davon ausging, dass du ein Manuskript verfasst, und den Satz dem Verlag
überlässt. Darum nahm ich auch an, dass dir bewusst ist, wie
scheußlich das Manuskript "formatiert" ist. Einfach, weil es zum
jetztigen Zeitpunkt noch egal ist.
Aber selbst bei der Kommasetzung nimmst du keine Kritik an und fragst
sogar noch, warum die Kommasetzung in einem Sachbuch wichtig sei.
Sorry, da fehlt mir jegliches Verständnis.
Bin raus, endgültig. Ist ja doch vergebene Liebesmüh.
Moin Gerhard.
Gerhard O. schrieb:> Die Politik ist ein Versuch der Politiker, zusammen mit dem Volk mit den> Problemen fertig zu werden, die das Volk ohne die Politiker niemals> gehabt hätte. (Dieter Hildebrandt)
'sic' mit eckigen oder auch runden Klammern -jeweils leicht
unterschiedliche Bedeutungen- ist gängige Verwendung in
wissenschaftlichen Publikationen (gehöre ich eigentlich nicht dazu, aber
man wird ja noch mal ein bisschen angeben dürfen).
Dieses Zitat von Dieter Hildebrandt kannte ich noch nicht, aber es ist
meiner Meinung nach nicht ganz treffend. Richtig wäre: "Politik ist der
Versuch der Politiker, OHNE das Volk mit den Problemen fertig zu werden,
die das Volk ohne die Politiker niemals gehabt hätte."
Kann man anders sehen (wollen), aber ich habe halt einen starken Trend
zum Sarkasmus.
Gruß
Jürgen
jdhenning schrieb:> Dieses Zitat von Dieter Hildebrandt kannte ich noch nicht, aber es ist> meiner Meinung nach nicht ganz treffend. Richtig wäre: "Politik ist der> Versuch der Politiker, OHNE das Volk mit den Problemen fertig zu werden,> die das Volk ohne die Politiker niemals gehabt hätte."
Hallo Jürgen,
Deine abgewandelte Version von dem Spruch finde ich auch recht gut:-)
Ich habe mich inzwischen im Wikipedia über den geschichtlichen
Hintergrund von "[sic]" informiert.
Gruß,
Gerhard
Volker SchK schrieb:> Wahnsinn !>> Ich schreibe auch gerade kein Buch aber so was ähnliches ;-)> Mir fehlt leider etwas Feedback, obwohl ich eigentlich genug> Versuchskaninchen haben müsste, da ich als Laboringenieur an einer> Hochschule arbeite und auch uC Labore betreue.
Hau rein! Was willst du denn noch? Schau nach (Amazon etc) ob es echte
(also ernst zu nehmende) Konkurrenzprodukte gibt. Falls nicht, dann
solltest du es zumindest versuchen (Verlag etc.). Wenn es nicht klappt,
dann hast du auf jeden Fall ein supergutes Skript erstellt! Ist ja auch
nicht schlecht!
Gruß
Jürgen
Hi
Ich schreib auch grad ein Buch... Es wird den Namen tragen: "Von einem
der auszog und berühmt wurde"
Es braucht dazu eigentlich nur alles kopiert zu werden, vielleicht noch
mit ein paar eigenen Bemerkungen dazu und dann ab zum Druck. Am schluß
ist ein Autor berühmt geworden, weil er in einem Forum zu seinen
niedergeschriebenen Gedanken Kritik verlangt. In einem Forum, in dem so
ziemlich alles vertreten ist, vom blutigen Anfänger bis zum ergrauten
Vollprofi. Na ja, und natürlich auch ein paar, die gern mal etwas Öl ins
Feuer werfen. Gut gemischt und aufbereitet schätze ich gute 400 Seiten
Literatur zum Schmunzeln und Nachdenken.
Schade, die gelöschten Beiträge fehlen mir zur endgültigen Würze...
OK, also wir werden jdhenning nicht beistehen können, solange er nicht
bereit ist, selbst sein Werk kritisch zu betrachten und jede berechtigte
Kritik zur Schreibweise verteidigt mit den Worten: "Ich will es so".
Vielleicht nicht wortwörtlich, doch in vielen seiner Antworten kommt es
so rüber. Dann mach es so.
Gruß oldmax
jdhenning schrieb:>> Mit Erkärungen wie man Datenblätter liest,.....> Wenn du da eine Quelle hast, kannst du die bitte veröffentlichen. Ich> kenne keine und bin sogar der Meinung, dass es keine geben kann. Die> einzige Anweisung, die ich kenne, lautet "langsam und gründlich!".
Für mich hat sich die top-down Methode bewährt: Vom groben Überblick zum
Detail, wenn notwendig. Man ließt sich das Kapitel der Features durch
(meist sogar auf einer Seite marketingtechnisch zusammengefasst). Dann
weiß man was der Käfer alles kann. Nun schaut man sich das
Blockschaltbild an und verschafft sich eine Überblick, wo die einzelnen
Module und Peripherieblöcke sind. Nun kann man sich ggf. (z.B. bei CPUs)
noch die Taktverteilung anschauen. Anschließend schaut man sich das
Blockschaltbild der gewünschten Peripherie an und überlegt sich, woher
sie den Takt und die Energie bekommt (beim AVR nicht nötig) und welche
Controllregister es gibt. Frühestens jetzt schaut man sich erst die
eigentlichen Register an, besser wäre es an dieser stelle nach einem
Beispielprogramm oder besser einer passenden App-Note zu suchen und sich
dort die Grundfunktionen anzuschauen.
Dann schreibt man sich ein kleines Testprogramm mit minimaler
Konfiguration und vielen Kommentaren. Das Testprogramm kann man sich
dann in ggf. seine private Codeschnippselsammlung übernehmen. Nun fängt
man an das Minimalprogramm sukzessive an seine Bedürfnisse anzupassen
und trennt dabei immer einzelne Funktionen ab und erstellt dafür eigene
C-Funktionen.
Am Ende hat man eine kleine Teilbibliothek für den Peripheriebaustein
(oder des LCD oder Sensors oder oder), die man in seine Sammlung
(subversion,git o.Ä.) aufnimmt und bei bedarf erweitert.
Funktioniert bei mir schon seit Jahren wunderbar und man wird in
zukünftigen Projekten recht schnell, da man versteht was die libs machen
und man sie auch so schnell an neues anpassen kann. Nebenbei versteht
man so auch recht schnell die Hardware auf/mit der man arbeitet.
Lord of Lightning schrieb:> Für mich hat sich die top-down Methode bewährt ...
Deine Ausführungen machen Sinn !
Meiner Erfahrung nach sträuben sich Anfänger leider dagegen sich zuerst
einen Überblick zu verschaffen.
Ein Meisterwerk.
Nur das hier -
>Nach der dritten kompletten Überarbeitung des Gesamtprogrammes werden sie sich>eindringlich fragen, ob das Basteln an Koptern wirklich so interessant ist.
- das habe ich wirklich nicht verstanden. Wieso werde ich mich das
eindringlich fragen?
Und das mit den "fucking momsers" ist mir auch unklar geblieben.
jdhenning schrieb:> Danke für das Angebot [Ironie] Falls ein Layoutschema für deutlich> besseres inhaltliches Verständnis sorgen könnte, wäre das natürlich> super![/Ironie]. Da, wie gesagt, der Weg über einen Verlag führen soll,> wird dies nicht nötig sein.
Hallo Jürgen,
sende mir einfach eine PM und ich schicke Dir einige Vorlagen für
Fachbücher.
Wie Du mit (meiner) Kritik umgehst, ist letztlich Deine Sache. Ich
wollte Dir einfach aus Autorensicht (mehrerer Fachbücher) einige
Hinweise geben.
Die Zusammenarbeit mit einem Verlag und dem zugeordneten Lektor sieht
etwas anders aus, als Du Dir vorstellst und als hier beschrieben. Als
„neuer“ Autor wirst Du, wenn überhaupt, die Layoutarbeit vollständig
selbst übernehmen müssen. Lediglich Satz und Druck übernimmt der Verlag.
In Deinem Manuskript stecken noch geschätzte 12 Monate Eigenarbeit. Wenn
Du tatsächlich an einer Buchveröffentlichung interessiert bist, würde
ich Dir wärmstens dieses [1] Buch empfehlen.
[1] Klaus Reinhardt: "Vom Wissen zum Buch: Fach- und Sachbücher
schreiben"
Martin Vogel schrieb:> Schade, die gelöschten Beiträge fehlen mir zur endgültigen Würze...
Diese Beiträge könntest du bestenfalls im Anhang verarbeiten im
Abschnitt "Bekannt durch Funk und Fernsehen". Sie tun jedenfalls
überhaupt nichts zur Sache.
Hasso, Platz! schrieb:> Und das mit den "fucking momsers" ist mir auch unklar geblieben.
Nur der Vollständigkeit halber:
Ein "momser" ist ein uneheliches Kind, manchmal auch Bastard genannt
(obwohl nicht korrekt).
Es ist zwar ein auch im englischen Sprachraum (sehr selten) genutztes
Wort, kommt aber ursprünglich aus dem Hebräischen/Jiidischen. Auf jeden
Fall ist es kein Wort, welches man sich merken müsste.
Es wird jedoch auch (fälschlicherweise) in manch anderem Zusammenhang
benutzt, jedoch praktisch immer in negativer Bedeutung. Eigentlich immer
dann, wenn derjenige "total cool rüberkommen" möchte, jedoch in
Wirklichkeit eben nicht total cool ist.
Und damit haben wir auch schon die Verbindung zum Autor des
Manuskriptes.
Wer es solches Wort in einem (möchtegern-)Fachbuch verwendet, der hat
doch massive Probleme, welche er dringend aufarbeiten sollte.
Ich kann nur noch mit dem Kopf schütteln .....
Ulli B.
OHje, das ist ..... bemerkenswert. Thnx für die Erklärung. Mir hat die
Lektüre auch öfter die Frage abgenötigt, ob der Zweck dieser
dilettantischen Buchstabenansammlung nicht eher darin besteht, gewisse
persönliche Konflikte des Autors zu lösen.
@jdhenning: Professionell geht anders.
Nase schrieb:> . Dein Betriebssystem gehört nicht in dieses Buch. Es ist nichts, was> einen Einsteiger interessiert und es ist ziemlich unanschaulich> beschrieben, sodass auch kein Lerneffekt davon ausgeht. Die Verkettete> Liste hätte man dagegen z.B. als einfaches C-Beispiel nehmen können.> Außerdem ist dein Betriebssystem praxisunrelevant, da es 100 andere,> besser getestete, einfacher einzusetzende gibt.
Und diejenigen, die die Systeme 11 bis 99 heraus gebracht haben, waren
also alles Idioten? Und du weißt jetzt schon, dass das, was ich bringen
will, schlechter ist, bevor ich es überhaupt beschrieben habe?
Nase schrieb:> Eine fachlich und/oder didaktisch untaugliche Lehre ist nicht selten> sehr viel schlimmer als garkeine...
Die ersten Worte von Dir, die ich unterschreiben würde.
Conny Phi schrieb:> In diesem Sinne, danke jdhenning und den anderen "Atmega8: Das> Buch"-Fans für die aufregende Lektüre.
Es ist mir eine Ehre, etwas für deinen Blutdruck tuen zu können.Falls
das, was dich da irgendwie besonders nervt etwas anderes ist, als was
hier schon angesprochen wurde, dann würde ich das gerne erfahren
(vielleicht kann ich ja noch schlimmer werden).
Grüße
Jürgen
Skeptik schrieb:> Ich habe nicht die Muße, wie viele hier, auf mehr Details einzugehen und> stimme meinen Vorrednern außer jdhenning zu. Hätte ich mir das Buch> gekauft, wäre ich total enttäuscht gewesen und hätte nicht versucht es> über ebay loszuwerden, sondern hätte versucht es an den Verlag/Author> zurückzugeben.
Das ist schade. Es wurde hier zwar mehrfach angedeutet, dass ich
beratungsresistent sei und unter Altersstarrsinn leide. Stört mich nicht
weiter. Das hindert mich aber nicht daran, die Kommentare intensiv zu
untersuchen, ob sie sinnvolle Kritik enthalten (von der Sorte kam hier
schon einiges, aber prozentual gesehen war es überraschen wenig).
Sei doch so nett und teile mir mit, weshalb du diese Enttäuschung
empfunden haben würdest; wenn du es nicht machst, dann kann ich da auch
problemlos mit leben, aber dann hättest du dir auch die zehn Minuten
schenken können, um deinen Post zu schreiben.
Gruß
Jürgen
Hallo Wolfgang.
Wolfgang Schmidt schrieb:> Es wird einen Lektor im Verlag geben, der ihm dann weiterhelfen wird.
Das hatte ich schon irgendwann früher geschrieben, dass ich mich von so
einem Lektor wohl überstimmen lassen müsste.
Danke für die aufmunternden Worte & Tschüs
Jürgen
Hallo Oliver.
Oliver S. schrieb:> So ist es.>> Niemand muß ein Buch schreiben, niemand muß es verlegen, niemand muß es> kaufen, und niemand muß es lesen. Nichts muß, alles kann.>> Bisher ist noch nichts davon geschehen, und damit nichts passiert. Den> Rest wird die Zeit zeigen.
(sic!)
Moin Lothar.
Lothar Miller schrieb:>> Du müsstest englischer Muttersprachler sein, um heraus zu hören, dass>> ich es nicht bin> Dass du was nicht bist?
Was ist daran unklar?
> Nochmal mein Tipp: es fehlen in diesem Buch mindestens 100 Bilder,> Skizzen, Abbildungen und Diagramme.
Gefühlt zum 33. mal: Was ich da ingestellt habe, ist ein Rohmanuskript
und es sollen noch zwei, drei Dutzend Fotos und Diagramme folgen
(hundert werden es ziemlich sicher nicht).
Gruß
Jürgen
Hallo Gerhard.
Gerhard O. schrieb:> In Bezug auf Fachausdrücke möchte ich auch vorschlagen, daß Du Dich> STRIKT an die Konvention und Sprache der Hersteller Literatur> (Datenbücher, Application Notes, Beispielprogramme, e.t.z.) hältst.
Ich bin da zwiegespalten. Wenn ich mich hier an deinen Rat halte, mache
ich zumindest nach außen hin nichts falsch. Aber mache ich es richtig?
Das Problem ist, dass ich fast keine technischen Texte kenne, die nicht
schnarchlangweilig sind. "Aus den Formeln (3.13) sowie (4.02) und (4.16)
ergibt sich nach einigen trivialen Umformungen....blablabla.., dös weg!"
Wenn jemand den Inhalt lernen will, weil er ihn für sich nutzen will,
dann ist es völlig unerheblich, ob ich das Wort 'Sklave' oder 'Slave'
benutze, denn es ist selbsterklärend. Zudem glaube ich, dass hier von
etlichen Leuten das Humorpotential von Technikern deutlich unterschätzt
wird. Wenn ein Techniker in Bezug auf eine MCU-Verschaltung hört "Wenn
der Gutsherr zum Sklaven sagt, gib mir...", dann wird er vielleicht
grinsen, hat da aber keine Probleme mit (wenn ein Techniker diese
Ausdrucksweise in ein Datenblatt schreiben würde, dann sähe die Sache
allerdings völlig anders aus).
Da ich für Newbies schreibe, die wohl nie ein Datenblatt verfasssen
werden (und wenn sie so weit kommen, dann kennen sie sowieso die ganzen
Fachtermini), handelt sich das ganze hier also um eine Geschichte aus
Don Quichote. Ich kämpfe gegen die Windmühlenflügel derjenigen, die
meinen, sie dürften festlegen, was man wie zu schreiben hat.
Da ich das Buch "Der kleine Hobby-Psychologe" erfunden habe, darf ich es
natürlich auch mal anwenden. Ich glaube viele der abwertenden Kommentare
hier kommen daher, dass die Leute denken "Ich hatte es schwer, mir
dieses Wissen anzueignen! Folglich sehe ich nicht ein, dass andere das
einfacher haben sollen!". Aufrecht stehen bleiben und sich nicht ducken!
Gruß
Jürgen
D. V. schrieb:> Thumbs up!
Muchos Garcías
(Verballhornung des spanischen 'muchas grácias' also vielen Dank;
Garcías ist in Spanien ein Sammelbegriff wie Müller, Meier, Schultze;
ich sagte diesen Spruch mal in einer spanischen Kneipe zum Wirt, als mir
das Bier hingestellt wurde. Mein spanischer Tresennachbar zuckte kurz
zusammen und sagte dann "Das ist wahr. Er ist einer, der da drüben auch,
die beiden da am Tisch gleichfalls!")
Konrad S. schrieb:> @jdhenning> Dir habe ich dahingehend nichts vorzuwerfen.
@ Konrad S. & @ATmega8
Obwohl ich ein ziemlich dickes Fell habe, sind aufmunternde Worte
zwischendurch immer wieder angenehm. Besten Dank dafür
Jürgen
Nase schrieb:> . Wenn du C programmieren möchtest, solltest du C können. Sonst lies> einschlägige C-Literatur. Nicht die Aufgabe eines Datenblatts.
Ersten habe ich ungefähr 20 Jahre Erfahrung mit C und ich habe nie
behautet, dass eine Einführung in C in ein Datenblatt gehört. Bitte
Zitat, sonst muss ich annehmen, dass dur zu tief ins Glas geschaut hast
(was mir auch egal wäre, denn du hast dich doch schon aus diesem Thread
abgemeldet).
> . Wie man einen AVR in eine Schaltung eindesignt, ist in etlichen> Appnotes beschrieben. Schaltungstechnik solltest du beherrschen. Sonst> lies oder studier. Nicht die Aufgabe eines Datenblatts.
Da irrst du grundsätzlich, denn genau das ist die primäre Aufgabe von
einem Datenblatt. App-Notes sind nur Ergänzungen.
> . Wie man die Toolchain bedient, steht in deren Dokumentation, und die> ist ausführlich genug. Nicht die Aufgabe eines Datenblatts.
Wo hast du denn das schon wieder gelesen? Also ich habe das nicht
geschrieben. Wieder Lalluzinationen?
> . Wenn du einen UART brauchst, solltest du wissen, wie ein UART> funktioniert. Dazu gibt es offizielle Standards in DIN und ISO, an die> du dich halten kannst. Oder an etliche Bücher zu Computerschnittstellen> (Schnittstellenhandbuch von Elsing/Wienck z.B., gabs schon 1986. Wenn du> das dann weißt, kannst du dir angucken, wie genau man die> UART-Schnittstelle des AVR parametriert. Es ist nicht Aufgabe des> Datenblattes, dir eine serielle Schnittstelle zu erklären. Du sollst> wissen, wie so eine funktioniert und wirst dann wiederfinden, was es zu> konfigurieren gibt.
Vor etwa 35 Jahren habe ich das erste mal einen USART programmiert. Und
wenn in irgendeinem Chip ein USART mit drin ist, dann gehört das
selbstverständlich in das Datenblatt, über welche Register welche
Funktionen bewirkt werden und dies auch mit den notwendigen
Zusammenhängen. Und ich halte es immer noch für ein schwaches Bild, wenn
zwar Parityfehler angezeigt werden, die aktuelle Parity aber nicht!
> . Wenn du I2C brauchst, gibt es einen Standard dazu. Und viel Literatur> von Philips. Da kannst du nachlesen, wie I2C funktioniert. Es ist nicht> Aufgabe des Datenblatts, dir das zu erklären. Danach kannst du im> Datenblatt nachschauen, wie es mit der spezifischen I2C-Hardware im AVR> geht.
Wenn du dir ein ganz klein wenig Mühe gegeben hättest, dann hättest du
auf der Seite "Hoffentlich hilfreiche Links" einen Link auf genau diese
Information gefunden.
Weiteren Kommentar erspare ich mir.
Jürgen
Walter schrieb:> <Ironie>> ich habe hier auch ICs in DIC-Form (Dual Inline Ceramic)> </Ironie>
Mist, Mist, Mist! Und schon wieder erwischt! Da hast du natürlich
absolut recht.
Jürgen
Moin Martin.
Martin Vogel schrieb:> Schade, die gelöschten Beiträge fehlen mir zur endgültigen Würze...> OK, also wir werden jdhenning nicht beistehen können, solange er nicht> bereit ist, selbst sein Werk kritisch zu betrachten und jede berechtigte> Kritik zur Schreibweise verteidigt mit den Worten: "Ich will es so".
Du machst schon mal zwei prinzipielle Fehler. Erstens wird man mit so
einem Buch nicht berühmt und zweitens wird man mit so einem Buch (auch
dann nicht, wenn es begeistert aufgenommen werden sollte) nicht reich
und mit an Sicherheit grenzender Wahrscheinlichkeit nicht einmal
wohlhabend.
Also wo ist das Problem? Dass ich kein armes Hascherl bin, das vor der
wilden Meute beschützt werden muss? Wegen erhoffter berechtigter Kritik
habe ich das Munskript ja hier zum Download und zur Diskussion
eingestellt. Ich habe das jetzt nicht wissenschaftlich ausgewertet, aber
gefühlsmäßig waren 20% der Beiträge mit berechtigter Kritik (Danke
dafür), weitere 20% waren nett/aufmunternd/sinnlos, und die restlichen
60% waren reines Gemotze.
Machst du mir zum Vorwurf, dass ich wusste, auf was ich mich hier
einlasse? Ich persönlich halte es da lieber mit dem Spruch "Wenn der
Klügere immer nachgeben würde, dann würde die Erde von Schwachsinnigen
regiert werden!"
Ich habe keine Ahnung, wo du die Idee her hast, dass ich
beratungsresisten sei. Ich lese alle Beiträge mit der notwendigen
Aufmerksamkeit. Was ich nicht zulasse ist, dass irgendwelche
Skriptkiddies meinen, sie hätten das Recht, mir Vorschriften zu machen!
Gruß
Jürgen
Lord of Lightning schrieb:> Für mich hat sich die top-down Methode bewährt:
Ähh, sorry, willst du mich und die anderen hier im Forum verarschen? Ich
habe über 30 Jahre Erfahrung in der Softwareentwicklung, wo auch einige
Jahre mit Hardware-Auswahl und/oder Hardware-Entwicklung dabei waren.
Du versuchst hier, bei den großen Jungs mitzuspielen (absolut erlaubt,
aber erwarte keine übertriebene Rücksichtnahme).
Freundliche Grüße
Jürgen
jdhenning schrieb:> Da ich für Newbies schreibe, die wohl nie ein Datenblatt verfasssen> werden (und wenn sie so weit kommen, dann kennen sie sowieso die ganzen> Fachtermini), handelt sich das ganze hier also um eine Geschichte aus> Don Quichote. Ich kämpfe gegen die Windmühlenflügel derjenigen, die> meinen, sie dürften festlegen, was man wie zu schreiben hat.
Mit dem Kampf gegen Windmühlen hast du ja Erfahrung.
jdhenning schrieb:> Ähh, sorry, willst du mich und die anderen hier im Forum verarschen? Ich> habe über 30 Jahre Erfahrung in der Softwareentwicklung, wo auch einige> Jahre mit Hardware-Auswahl und/oder Hardware-Entwicklung dabei waren.
Dein Lebenslauf liest sich aber anders:
"Jürgen Henning: Auf ein abgeschlossenes Studium der Elektrotechnik
(Schwerpunkt: Mess-, Regel- und Datentechnik) folgten etliche Jahre in
der Industrie. Vor 20 Jahren brach ich mit meinem Motorrad zu einer
Weltumrundung auf (das war das Beste, was ich mir in meinem Leben
angetan habe). Dem schlossen sich zehn Jahre in Spanien an. Vor etwas
über einem Jahr begann ein intensiver E-Mail-Austausch mit einem Freund
in Spanien, der eine kleine PV-Insel betreibt. Da er Schriftsteller ist,
überredete ich ihn, ein Buch über Photovoltaik zu schreiben und ich
unterstützte ihn mit Recherchearbeit. Dann wuchs ihm das Projekt über
den Kopf und ich übernahm die Arbeit am Buch. Das Zusammenfließen von
zwei völlig verschiedenen Schreibstilen hat sehr zur Lesbarkeit des
Buches beigetragen. "
http://www.amazon.de/Photovoltaik-f%C3%BCr-technisch-unbegabte-Akademiker/dp/3735739636/ref=sr_1_9?ie=UTF8&qid=1420504162&sr=8-9&keywords=photovoltaik
Du bist über 20 Jahre raus aus dem Job. Du bist ein Blender, der eine
große Schnauze hat.
Fortgeschrittener schrieb im Beitrag #3950827:
> Naja, das gibt eben ein typisch deutsches "Fach"buch: Irgendjemand mit> Halbwissen dokumentiert sein Unverständnis mehr schlecht als recht. Arme> Ahnungslose geben dafür Geld aus.>> Spontan muss ich an Verlage wie "Data Becker", "Markt & Technik",> "Galileo Press" und seit einigen Jahren auch "O’Reilly" denken...
In gewisser Weise kann ich deine Kritik nachempfinden, aber du
beschwerst dich darüber, dass die Welt so ist, wie sie ist (und wegen
dir wird sie sich nicht ändern!).
Verlage sind, wie jedes andere Wirtschaftunternehmen (und auch alle
Arbeitnehmer) darauf ausgerichtet, Einkommen zu generieren (Wenn dir das
nicht passt, dann geh doch nach drüben! Ach, geht ja nicht mehr, weil
abgeschafft).
Vor drei Tagen ging ich noch mal durch den ganzen Thread durch und
musste zu meiner Verblüffung feststellen, dass es fast keinen Abschnitt
im Manuskript gab, der von einigen für gut befunden wurde und von
anderen für völlig überflüssig oder sogar schlicht als Scheiße bewertet
wurde. Das nennt sich Meinungsvielfalt!
Ich habe kein Problem damit, wenn mich jemand nicht mag (auch dann
nicht, wenn er mich noch nicht einmal kennt; ich ihn ja auch nicht).
Wenn du also irgendein Interesse daran hast, dass 'spätere Generationen'
einen besseren Einstieg in das Thema MCUs haben, dann schreibe ein
besseres Buch oder gib mir wenigstens Hinweise, wo du meinst, dass da
meinerseits nur Halbwissen vorhanden ist, damit ich es besser machen
kann.
Ich vermute, dass du weder noch kannst, ist aber letztlich auch egal.
Gruß
Jürgen
Volker SchK schrieb:> Meiner Erfahrung nach sträuben sich Anfänger leider dagegen sich zuerst> einen Überblick zu verschaffen.
Da täuscht dich deine Erfahrung komplett! Das ist ja exakt das, was der
Anfänger gerne haben möchte, ihm aber verwehrt wirt von 'Spezialisten',
die meinen, das wäre doch alles völlig einfach, wenn man sich nur ein
halbes Jahr (Vollzeit) Mühe geben würde.
Diese Lüge ist der einzige Grund, weshalb ich mich überhaupt hingesetzt
habe, um dieses Buch zu schreiben. Ich habe ein recht umfangreiches
Hintergrundwissen über Rechnertechnik und ich hatte trotzdem ziemliche
Schwierigkeiten, mich in das Thema MUCs einzuarbeiten. Grund: Kein
Schwein (zumindest keines, das ich trotz intensiver Suche gefunden
hätte), vermittelt diesen Überblick! Und du sagst, das ist der Fehler
der Anfänger?
Fucking momser!
Jürgen
Joe G. schrieb:> [1] Klaus Reinhardt: "Vom Wissen zum Buch: Fach- und Sachbücher> schreiben"
Danke. Ich habe gerade einen "Blick ins Buch" gemacht und finde
zumindest schon mal den Stil erfrischend. Kaufwahrscheinlichkeit:99%.
Tschüs
Jürgen
Ulli B. schrieb:> Es wird jedoch auch (fälschlicherweise) in manch anderem Zusammenhang> benutzt, jedoch praktisch immer in negativer Bedeutung. Eigentlich immer> dann, wenn derjenige "total cool rüberkommen" möchte, jedoch in> Wirklichkeit eben nicht total cool ist.>> Und damit haben wir auch schon die Verbindung zum Autor des> Manuskriptes.> Wer es solches Wort in einem (möchtegern-)Fachbuch verwendet, der hat> doch massive Probleme, welche er dringend aufarbeiten sollte.
Noch jemand, der das Buch "Der kleine Hobbypsychologe" geschenkt
bekommen hat?
Komm, dann liste doch mal auf, welche massiven Probleme ich aufarbeiten
müsste! Und du vergisst eines (hatte ich auch schon mehrfach
geschrieben): Aus dem Alter, dass ich 'cool' 'rüber kommen möchte, bin
ich schon lange raus. Nur so als Tipp: VErsuche es doch mal mit Denken!
Könnte hilfreich sein.
Hasso, Platz! schrieb:> ob der Zweck dieser> dilettantischen Buchstabenansammlung nicht eher darin besteht, gewisse> persönliche Konflikte des Autors zu lösen.
Danke für den hilfreichen Hinweis, um den Inhalt des Buches zu
verbessern!
Butter bei die Fische schrieb:> Du bist über 20 Jahre raus aus dem Job. Du bist ein Blender, der eine> große Schnauze hat.
Gute Recherche (Danke für die Werbung!) aber völlig falsche
Schlussfolgerungen (kann ja mal passieren, wenn man nicht so gut logisch
denken kann).
Alles das, was an Technologie im ATmega8 oder auch im ATmega328 drin
ist, ist absolute Computersteinzeit (Funktion, nicht
schaltungstechnische Umsetzung). Da könnte ich sogar 30 Jahre aus dem
Job raus sein und mein Wissen wäre immer noch top aktuell!
Ich habe das Manuskript geschrieben, um Neueinsteigern das Leben zu
erleichtern. Falls du die Art, wie ich das mache, nicht gut findest,
dann wäre ich an Erläuterungen interessiert, was da den Erkenntnisgewinn
behindern könnte. Falls dir nur mein Stil nicht passt, dann .....!
Zum Abschluß: Das, was ich behaupte zu können, das kann ich auch (und
das schon ziemlich lange). Ein Blender bin ich also ganz sicherlich
nicht (womit ich denn doch die Frage eröffnen möchte, mit welcher
Qualifikation du mich denn hier angreifst). Polemik im Selbststudium?
Hi
Eigentlich wollte ich dich dazu bringen, hier einen Cut zu machen um
etwas Abstand zu gewinnen. Aber du hast mich völlig falsch verstanden
> Schade, die gelöschten Beiträge fehlen mir zur endgültigen Würze...> OK, also wir werden jdhenning nicht beistehen können, solange er nicht> bereit ist, selbst sein Werk kritisch zu betrachten und jede berechtigte> Kritik zur Schreibweise verteidigt mit den Worten: "Ich will es so".
Da steht nix von Beratungsresistent. Wenn du das daraus interpretierst
ist das schon ein zeichen, das es dich langsam nervt, das sehr viele
negative Beiträge geschrieben sind. Mittlerweile hast du dich in eine
Ecke drücken lassen, in der du dich kaum noch verteidigen kannst. Lass
die Diskussion und Rechtfertigung. Ich weiß, was es heißt, ein Fachbuch
zu schreiben. Es dann in einem Forum zur Diskussion zu bringen ist auch
sehr mutig, denn ganz klar, es gibt immer welche, die vieles besser
machen würden. Ja eben nur würden, nicht wirklich besser machen. Manch
einer braucht auch so ein Buch gar nicht, weil das Internet voll von
kostenlosen Informationen ist. Es ist halt die Zeit, wo nicht mehr alles
gekauft werden muss.
Ach ja, sicherlich reich und berühmt wirst du mit dem Buch nicht.
Bestenfalls ist ein kleines Zubrot drin. Aber dann muss es auch von
Seiten des Verlags marktfähig sein. Also, nicht nur ein paar Exponate,
sondern schon ein paar tausend. Aber das wolltest du ja gar nicht zur
Diskussion bringen, sondern den Inhalt und dazu hast du viel Kritik
eingesteckt. Und noch einmal, ein letztes Mal den rat von mir: Brich
hier ab, lege alles beiseite, mindestens ein halbes Jahr. Mach in dieser
Zeit Urlauib oder bastel irgend was zurecht, aber fass das Buch nicht an
und diskutier auch nicht über irgendwelche Inhalte. Dann, wenn du
ausreichend Abstand zum eigenen Werk hast schau noch einmal drüber und
du erkennst selbst unschöne und unsinnige Inhalte. Und noch was: die
Diskussion, ob ein Controller veraltet ist, ist doch für den Inhalt
eines Buches gar nicht relevant. Wenn du beginnst, über irgendeinen
Controller zu schreiben, ist dieser mit Sicherheit bei Fertigstellung
veraltet. Daher ist wichtig, das Kopfkino anzuregen und Controller
allgemein an einem Beispiel zu erklären. Und da kommt dann der ATmega8
durchaus in Frage. Wenn die Thematik Controller verstanden ist, wird es
kein Problem sein, auf einen anderen umzusteigen. Das geschrei: "Nimm
einen modernen" ist völliger Blödsinn. Soll denn jeder Controller sein
eigenes Buch bekommen, damit niemand mehr über Eigeninitiative erlerntes
Wissen auf andere Typen adaptieren muss?
@Lothar Miller
Das mit dem Buch und den glöschten Beiträgen war nicht ernst gemeint. Es
wäre auch eher eine Anekdote in der Thematik "Menschen und das Niveau
ihrer Kommunikation" . Ergänzt hätte ich es dann natürlich mit
Kommentaren, die weit abseits jedweder Fachbeziehung wäre und der Leser
hätte damit auch nicht das geeringste über Controller oder Elektronig
lernen können. Vielleicht aber den Schluss gezogen, das [Ironie ein]
viele Experten doch ganz schön "einen an der Waffel" haben. [Ironie
wieder aus]
In diesem Sinne
Oldmax
jdhenning schrieb:> Volker SchK schrieb:>> Meiner Erfahrung nach sträuben sich Anfänger leider dagegen sich zuerst>> einen Überblick zu verschaffen.>> Da täuscht dich deine Erfahrung komplett! Das ist ja exakt das, was der> Anfänger gerne haben möchte, ihm aber verwehrt wirt von 'Spezialisten',> die meinen, das wäre doch alles völlig einfach, wenn man sich nur ein> halbes Jahr (Vollzeit) Mühe geben würde.
Deine Anfänger sind andere als meine !
Deine sind die paar Hansel , die sich zufällig dafür interessieren und
sich das Alles selbst beibringen. Meine sind die, die das lernen sollen
weil es zu ihrer Ausbildung gehört und wir einen Haufen Leute brauchen,
die das können.
Leider sind meine in einem Alter in dem vieles andere auch noch
wichtig ist und hätten es am liebsten, wenn ihnen das alles so nebenher
beigebracht werden würde. In der Ausbildung hat man dann ja auch noch
jede Menge anderer Dinge zu lernen ...
Ü50 lässt das dann mach, da kann man dann sogar auf so Zeugs kommen wie
Bücher screiben ;-)
jdhenning schrieb:> Noch jemand, der das Buch "Der kleine Hobbypsychologe" geschenkt> bekommen hat?
Leider muss ich dich nochmal (zum letzen Mal) enttäuschen.
Nicht ich habe das Buch geschenkt bekommen, sondern meine Frau hat es
sich gekauft. Und der Name des Buches lautet auch nicht "Der kleine
Hobbypsychologe" sondern
"Neurologie und Psychiatrie" von Haupt & Jochheim & Gouzoulis-Mayfrank.
Verlag Thieme.
Bei den Prüfungsvorbereitungen meiner Frau habe ich das Buch auch
mindestens einmal durchgearbeitet.
Allerdings braucht es nicht der Unterstützung von diesem Buch bzw.
dessen Inhalts um dein Problem zu erkennen.
Dein Verhalten ist sehr typisch.
Mir ist das jetzt auch alles zu blöde hier. Falls du wirklich einen
Verlag findest, welcher so ein Buch druckt, dann gibt es eben eins mehr
von der Sorte. Gibt es eigentlich Data Becker noch?
Machs gut ...
Hallo,
also ich habe das Buch nur kurz überflogen und muss sagen, dass mir
inhaltlich hauptsächlich aufgefallen ist, dass wie viele vor mir schon
erwähnt haben auf die Fuses etwas eindringlicher eingegangen werden
sollte und auch schon früher. Zu viel mehr bin ich nicht gekommen, denn
mehr als überfliegen wollte ich.
Was mich aber definitiv vom Lesen abgehalten hat und später auf von
einem Kauf abhalten würde ist der Textsatz.
Tut mir leid aber es sieht ein bisschen so aus wie eine schlechte
pdf-gedruckte Internetseite. Es fällt einem schwer einen Überblick zu
bekommen in dem man Seiten einfach nur überfliegt und längeres Lesen ist
nicht gerade angenehm. Ich müsste mich immer wieder dazu zwingen und
würde das Buch sehr schnell in einer Ecke verschwinden lassen weil es so
einfach keinen Spaß macht.
Aus meiner Sicht viel zu schade um die viele Arbeit, die du dir im
Inhalt gemacht hast.
Meine Empfehlung wäre natürlich Latex. Aber auch in Word, LibreOffice &
Co bekommt man mit etwas Mühe einen ordentlichen Textsatz zustande.
Meine Tipps dazu wären in jedem Fall
-Blocksatz
-größerer Zeilenabstand
-Bilder in ausreichender Größe, bei 100% erkennt man bei dir häufig
nicht viel und das bei A4 ein Buch wird später sicher in A5 oder
ähnlichem gedruckt.
-Bilder nicht neben die Schrift. 5-10 Wörter Zeilen sind bei langem
lesen sehr anstrengend. Außerdem wirkt es gequetscht und du machst
dadurch die Bilder noch kleiner. Wenn du ein Bild als notwendiges Übel
klein neben dran klatschst ohne das man was erkennen kann, kannst du es
auch weg lassen.
-Tabellen sollten einheitlicher aufgebaut sein, dann findet man sich
schneller zurecht und bei einigen musst du aufpassen, dass er Text
sauber dargestellt wird.
- Codehighlighting ist in Word wahrscheinlich Wunschdenken. Aber gerade
wenn du Leute adressierst, die schon Programmiererfahrung haben
erleichterst du damit das Leben sicherlich.
-Code immer in derselben Schrittgröße, lieber ein Zeilenumbruch aber auf
keinen Fall kleiner werden weil nicht alles in eine Zeile passt
-Wenn du dein Buch wirklich verkaufen willst solltest du über saubere
Quellenangaben nachdenken. Du hast nicht eine in deinem Buch und das
kann ich mir kaum vorstellen. Selbst wenn du nicht direkt zitierst, hast
du sicher nicht alle Informationen ausschließlich aus deinem Kopf.
- Auch beim Einrücken und Fettmarkieren bist du nicht konsequent. Das
ist zum einen anstrengend zum anderen kann es auch zu
Verständnisproblemen führen.
Auch wenn dir das vielleicht etwas penibel erscheint in einem Stadium in
dem du inhaltlich noch nicht ganz fertig bist, du solltest jetzt schon
viel mehr Arbeit in das Aussehen stecken oder später jemanden engagieren
und bezahlen der dir das macht.
eigentlich wollte ich ja noch was zu dem Thema Bootlader schreiben.
Dazu hab ich aber keine Lust mehr, ein Bootlader "bringt ja keinerlei
Vorteile".
Viel Erfolg..........
Ich habe mir mal die Mühe gemacht, eine Stunde in dem "Buch"
rumzulesen....
Jetzt ist mir nicht ganz klar, was du eigentlich schreiben wolltest?
* ein Fachbuch --> dafür ist es schlichtweg zu dürftig, unvollständig
und strotzt von zuviel eigenen sunjektiven Meinungen/Vorlieben
* einen Roman --> Ansatz nicht schlecht, dann stören aber die vielen
Tabellen und Bilder ;-)
Ich erwarte von einem Fachbuch (auch die für Anfänger) keine Prosa über
das Leben oder halbgewalkte Meinungen zu Gott und der Welt, sondern
klare Fakten, fachspezifische Informationen und (für Anfänger)
eindeutige Handlungsanweisungen.
Du solltest wirklich, wie hier schon von einigen angemerkt, das Ganze
mal sacken lassen, Abstand gewinnen und (später) aus einer objektiveren
Sichtweise überarbeiten. Im jetzigen Zustand des Werkes bezweifele ich,
dass irgendein (Fach)-Verlag es in Erwägung zieht, dieses Buch zu
drucken!
@ Martin Vogel (oldmax)
Selbst wenn du ein Buch 20 bis 50 Kommilitonen gibst werden die es
zerrupfen, denn jeder hat erst mal seine eigene Meinung wie solch ein
Buch sein sollte und Dinge die irgendwie ungünstig sind werden sofort
angegriffen.
Das ist ja eigentlich auch gut so, denn man will ja nicht dass das Buch
nach dem Druck von der Zielgruppe zerpflückt wird.
Da die Anforderungen hier noch etwas höher sind sehr ich gute Chancen
dass daraus ein gutes Buch wird.
Ich würde aber alle emotionalen Worte rauslassen.
In der Danksagung kann man das aber machen.
In einer Danksagung am Anfang hat der Autor gesagt dass er das Buch
initial eigentlich für ein Mädel (er hat nicht gesagt ob Tochter oder
einer Freundin) geschrieben hat und es dann professionell gestaltet hat.
Hallo Martin, da habe ich dich dann wohl wirklich falsch verstanden.
Sorry.
Martin Vogel schrieb:> Da steht nix von Beratungsresistent. Wenn du das daraus interpretierst> ist das schon ein zeichen, das es dich langsam nervt, das sehr viele> negative Beiträge geschrieben sind. Mittlerweile hast du dich in eine> Ecke drücken lassen, in der du dich kaum noch verteidigen kannst.
Nee, noch lange nicht genervt (man wird ja mal so tun dürfen) und in
irgendeiner Ecke bin ich auch noch lange nicht; wenn man mal in der
Industrie verantwortlich in Projekten gearbeitet hat (Paketgröße
siebenstellig), dann weiß man, mit welchen Mitteln dort gefighted wird
(üble Nachrede, Sabotage, Spionage und einiges mehr). Ich gebe zu, dass
mir das damals schon manchmal an die Nieren ging; im Vergleich dazu geht
das doch hier alles sehr harmlos zu.
Irgendwann in den nächsten Tagen werde ich mal wieder mit dem Verlag
telefonieren und dann sehen wir weiter. Nichts desto trotzig: Danke für
deinen Tipp.
Jürgen
Ein kleiner Tip:
In deinem Code sind die defines falsch.
Bei dir steht:
#define FOO = 4
richtig ist
#define FOO 4
Es ist daher generell empfehlenswert, wenn du schaust, dass der Code,
den du in deinem Buch schreibst, auch funktioniert. Das sollte durch
rigorose Tests geschehen. Gerade für Anfänger ist das sonst extrem
frustrierend, die können nämlich nicht einmal völlig offensichtliche
Fehler erkennen (wie denn auch?), selbst wenn diese versehentlich ihren
Weg ins Buch gefunden haben.
Moin vloki
vloki schrieb:> Leider sind meine in einem Alter in dem vieles andere auch noch> wichtig ist und hätten es am liebsten, wenn ihnen das alles so nebenher> beigebracht werden würde. In der Ausbildung hat man dann ja auch noch> jede Menge anderer Dinge zu lernen ...> Ü50 lässt das dann mach, da kann man dann sogar auf so Zeugs kommen wie> Bücher screiben ;-)
Das ist der Grund, weshalb ich mir frühzeitig die Idee aus dem Kopf
geschlagen habe, Lehre zu werden: Was, wenn ich Schüler bekomme
(rächendes Karma!), die so sind, wie ich damals war?
Nur so als Nebenthema: Was hier manche nicht verstehen wollen oder
können ist, dass das Begreifen so lange dauert. Wie hängt was womit und
warum zusammen und wie ist die Wirkbeziehung. Ich glaube, ich trage da
gerade Eulen nach Athen! Auch stimme ich deiner Einschätzung zu, dass
man als ü50 stärker daran interessiert ist, möglichst sinnvolle Sachen
zu machen (schließlich hatte man ja das Glück, dass man die völlig
unsinnigen Sachen überlebt hat).
Danke & Gruß
Jürgen
jdhenning schrieb:> Hallo Gerhard.>> Gerhard O. schrieb:>> In Bezug auf Fachausdrücke möchte ich auch vorschlagen, daß Du Dich>> STRIKT an die Konvention und Sprache der Hersteller Literatur>> (Datenbücher, Application Notes, Beispielprogramme, e.t.z.) hältst.>> Ich bin da zwiegespalten. Wenn ich mich hier an deinen Rat halte, mache> ich zumindest nach außen hin nichts falsch. Aber mache ich es richtig?> Das Problem ist, dass ich fast keine technischen Texte kenne, die nicht> schnarchlangweilig sind. "Aus den Formeln (3.13) sowie (4.02) und (4.16)> ergibt sich nach
Hallo Jürgen,
Ich muß Dir leider immer noch widersprechen. Der Grund warum ich es so
wichtig finde sich an die Herstellerkonventionen zu halten ist, dass man
früher oder später eng mit den Herstellerdokumenten bei der Fehlersuche
und Recherchen arbeiten muß. Daran kommt man nicht herum. auch das beste
Buch kann nicht ohne Hersteller Resourcen auskommen. Dann ist es extrem
irritierend wenn es Unklarheiten in der Identität des Subjekts gibt.
Ich kann leider nur von mir sprechen, denke mir aber es könnte vielen
Leuten ähnlich gehen wie mir.
Klarheit und Genauigkeit sind die Grundpfeiler in der Technik und sollte
Allen ein hohes Ziel sein. Man erspart sich zumindest viele Frusts. Um
ehrlich zu sein, ich sollte ab und zu meine eigenen Worte auf mich
anwenden. Manchmal ertappe ich mich selber auch dabei nicht Konsistent
zu sein. Nobody is perfect:-)
Bei uns gibt es aber ein treffendes Sprichwort: "Do as I say and not as
I do!"
Wie schon vorgeschlagen, mach mal eine Pause und laß Dir mal alles durch
den Kopf gehen. Man sollte sicherlich regelmäßig Abstand schaffen um
eine gesunde Perspektive zu gewährleisten.
Ohne Dich vor den Kopf stoßen zu wollen, muß ich zugeben, dass das Buch
von Barnett "Embedded C Programming and the Atmel AVR" mir persönlich
sehr nützlich bei meinem Einstieg in AVRs war, obwohl einige von Euch es
vor Jahren etwas kritisiert hatten als ich es hier irgendwo erwähnt
hatte. Ich konnte mich damals sofort in die Eigenschaften der AVRs gut
einarbeiten wenn ich zuvor noch nie mit ihnen gearbeitet hatte.
Allerdings half es die selbe Toolchain wie im Buch verwenden zu können.
Dieses Buch behandelt so ziemlich alles was ein technisch versierter
Einsteiger wissen muss um als Startpunkt für eigene Designs zu dienen.
Seh es Dir mal an. Die Abgrenzung der Kapitel finde ich sehr gut
gelungen. Auch wird die Hardware genügend detailliert behandelt. Es wird
auch ein komplettes drahtloses Wetterstationsprojekt beschrieben. Alle
Codebeispiele funktionieren einwandfrei. Ich habe auch vieles nützliche
von diesem Buch in die Welt der PICs und andere Mikros portiert.
Auch finde ich den Typ des MCUs ziemlich unwichtig. Wenn man einen AVR
kennt, kann man sich leicht in andere Familienmitglieder einarbeiten.
Auch Projektplanung und Pflichtenhefterstellung wird empfohlen und
behandelt.
Sorry für die Reklame des Buches! Ich weiß es ist hier unpassend. Aber
es ist aus Sicht eines anderen der mit einem Buch arbeiten mußte
vielleicht illustriv.
In diesem Sinne Viele Grüße,
Gerhard
Ulli B. schrieb:> "Neurologie und Psychiatrie" von Haupt & Jochheim & Gouzoulis-Mayfrank.> Verlag Thieme.>> Bei den Prüfungsvorbereitungen meiner Frau habe ich das Buch auch> mindestens einmal durchgearbeitet.
Jeder Psychologe oder Psychiater würde eine Aussage über den
Geisteszustand einer Person nur nach einer sehr eingehenden Anamnese
machen. Und du hast ein Buch (mindestens einmal!) über das Thema gelesen
und glaubst sogar Ferndiagnosen machen zu können? Die Schublade, in die
du dich gerade einsortiert hast, trägt den Titel Quacksalber!
Hallo KurzÜberflogen, schon mal vielen Dank für den langen Post.
KurzÜberflogen schrieb:> also ich habe das Buch nur kurz überflogen und muss sagen, dass mir> inhaltlich hauptsächlich aufgefallen ist, dass wie viele vor mir schon> erwähnt haben auf die Fuses etwas eindringlicher eingegangen werden> sollte und auch schon früher.
Es hatte einen guten Grund, weshalb ich die Fuses so weit nach hinten
gepackt habe, denn bei den ersten Schritten braucht man die nicht
wirklich. Außer man hat ein kommerzielles Produkt entwickelt (ist nicht
meine Zielleserschaft), dann braucht man sie bestenfalls, um die MCU
schneller zu machen. Bis man soweit ist, dass man das wirklich braucht,
sind mindestens etliche Wochen vergangen. Vorher wird man schon genügend
Probleme haben.
> Was mich aber definitiv vom Lesen abgehalten hat und später auf von> einem Kauf abhalten würde ist der Textsatz.
Ich nehme an, die ist beim kurz überfliegen entgangen, dass ich mehrfach
darauf hingewiesen habe, dass dies ein Rohmanuskript ist. Das gilt für
Textsatz als auch Bilder und Diagramme.
> Meine Empfehlung wäre natürlich Latex. Aber auch in Word, LibreOffice &> Co bekommt man mit etwas Mühe einen ordentlichen Textsatz zustande.
Ich werde versuchen, das dem Verlag zu überlassen (ich vermute, dass die
das wesentlich besser (und professioneller) können, als ich.
> -Wenn du dein Buch wirklich verkaufen willst solltest du über saubere> Quellenangaben nachdenken. Du hast nicht eine in deinem Buch und das> kann ich mir kaum vorstellen.
Es ist keine wissenschaftliche Arbeit und erhebt auch nicht diesen
Anspruch. Viele, aber nicht alle Quellen, finden sich im Kapitel: Hier
werden sie geholfen. Der einzige Vorwurf, den man mir machen könnte ist,
dass einige einzelne Sätze aus dem Datenblatt direkt übersetzt sein
könnten (habe ich, falls überhaupt, nicht vorsätzlich gemacht; zumindest
nicht, um das geistige Eigentum von Atmel zu nutzen). Kann also
entfallen!
> - Auch beim Einrücken und Fettmarkieren bist du nicht konsequent. Das> ist zum einen anstrengend zum anderen kann es auch zu> Verständnisproblemen führen.
Wenn ich konsequent wäre, dann hätte ich in meinem Leben schon einige
Leute fertig machen müssen. Ich habe mich fast immer lieber dafür
entschieden, nicht konsequent zu sein.
> Auch wenn dir das vielleicht etwas penibel erscheint in einem Stadium in> dem du inhaltlich noch nicht ganz fertig bist, du solltest jetzt schon> viel mehr Arbeit in das Aussehen stecken oder später jemanden engagieren> und bezahlen der dir das macht.
Ich träume noch davon, dass sich der Verlag darum kümmert und hoffe
inständig, dass ich recht habe.
Gruß
Jürgen
jdhenning schrieb:> Hallo KurzÜberflogen, schon mal vielen Dank für den langen Post.>> KurzÜberflogen schrieb:>> also ich habe das Buch nur kurz überflogen und muss sagen, dass mir>> inhaltlich hauptsächlich aufgefallen ist, dass wie viele vor mir schon>> erwähnt haben auf die Fuses etwas eindringlicher eingegangen werden>> sollte und auch schon früher.> Es hatte einen guten Grund, weshalb ich die Fuses so weit nach hinten> gepackt habe, denn bei den ersten Schritten braucht man die nicht> wirklich. Außer man hat ein kommerzielles Produkt entwickelt (ist nicht> meine Zielleserschaft), dann braucht man sie bestenfalls, um die MCU> schneller zu machen. Bis man soweit ist, dass man das wirklich braucht,> sind mindestens etliche Wochen vergangen. Vorher wird man schon genügend> Probleme haben.>> Gruß> Jürgen
also sorry Jürgen, mit der Aussage lehnst Du Dich aber sehr weit aus dem
Fenster und das hat mit kommerziell schonmal garnichts zu tun, da bist
Du völlig auf dem Holzweg! Das sind Basics die jeder Anfänger wissen
MUSS.
Bemühe mal die Suchfunktion mit dem Stichwort: verfust, dann wirst Du
erkennen das dieses Thema ein große Fallgrube für viele Anfänger ist.
Wichtiger in einem Anfängerbuch für Atmega8 sind sicher 9 Seiten über
Projektmanagement....
Aber was rede ich, haben ja viele andere auch schon getan.....
Christian
Lord of Lightning schrieb im Beitrag #3954014:
>> Lord of Lightning schrieb:>>> Für mich hat sich die top-down Methode bewährt:>>>> Ähh, sorry, willst du mich und die anderen hier im Forum verarschen? Ich>> habe über 30 Jahre Erfahrung in der Softwareentwicklung, wo auch einige>> Jahre mit Hardware-Auswahl und/oder Hardware-Entwicklung dabei waren.
Sorry, falls ich dir da zu sehr auf die Zehenspitzen getreten bin.
"Top-Down" ist eine von vielen möglichen Methoden (meiner Meinung nach
nicht unbedingt die beste) und dein Beitrag las sich für mich so, als ob
ein Skript-Kiddie jemandem erklären will, wie Softwareentwicklung zu
erfolgen hat (schau noch mal auf den Beitrag, den kann man wirklich so
verstehen). Daher meine gereizte Reaktion.
Fish? You were welcome! Aber es regieren ja sowieso die Mäuse; kann man
nichts dran machen!
Christian Brandtner schrieb:> eigentlich wollte ich ja noch was zu dem Thema Bootlader schreiben.> Dazu hab ich aber keine Lust mehr, ein Bootlader "bringt ja keinerlei> Vorteile".>> Viel Erfolg..........
Wenn ich eine MCU direkt über den USB-Port programmieren kann, dann sehe
ich in der Tat keinerlei Sinn darin, einen Bootloader zu verwenden. Er
ist schlicht komplett überflüssig und nur noch drin, damit die
Backwards-Kompatibilität erhalten bleibt. Falls du da bessere
Erkenntnisse hast und sie mir nicht sagen willst, dann habe ich da
überhaupt kein Problem mit. Warum möchtest du die gesamte Menschheit in
Unwissenheit gefangen halten?
Atmega8 Atmega8 schrieb:> Das ist ja eigentlich auch gut so, denn man will ja nicht dass das Buch> nach dem Druck von der Zielgruppe zerpflückt wird.>> Da die Anforderungen hier noch etwas höher sind sehr ich gute Chancen> dass daraus ein gutes Buch wird.
Es ist ja nicht so, dass ich nicht einige Fähigkeitslücken bei mir sehe
(Layout, Design, Konsistenz etc). Deine positive Kritik ist zwar fast
genauso unbegründet, wie die negative Kritik in etlichen Beiträgen, ich
empfinde aber eine starke Tendenz, sie wohlwollend annehmen zu wollen
;-)
Und jetzt mal wieder gute Nacht, ich muss mit meinen Wuffis raus.
Jürgen
jdhenning schrieb:> Christian Brandtner schrieb:>> eigentlich wollte ich ja noch was zu dem Thema Bootlader schreiben.>> Dazu hab ich aber keine Lust mehr, ein Bootlader "bringt ja keinerlei>> Vorteile".>>>> Viel Erfolg..........>> Wenn ich eine MCU direkt über den USB-Port programmieren kann, dann sehe> ich in der Tat keinerlei Sinn darin, einen Bootloader zu verwenden. Er> ist schlicht komplett überflüssig und nur noch drin, damit die> Backwards-Kompatibilität erhalten bleibt. Falls du da bessere> Erkenntnisse hast und sie mir nicht sagen willst, dann habe ich da> überhaupt kein Problem mit. Warum möchtest du die gesamte Menschheit in> Unwissenheit gefangen halten?
1. weil ich das Geraffel des Programmierers nicht ständig brauche
2. weil es schneller funktioniert über Rx/Tx
3. weil ich den ISP-Progger nicht ständig an/abstecken muss, die Pins
brauche ich ja für meine Anwendung.
4. Rx/Tx brauche ich sowieso für einfache Debugmöglichkeiten.
Ich möchte die Menschheit nicht in Unwissenheit gefangen halten, ich
schreibe aber auch kein Buch mit dem ich Wissen vermitteln möchte.
Wenn Du Wissen vermitteln möchtest gehört da mehr zu als Deine
persönliche Meinung zu einer technischen Möglichkeit. Nur weil Du es
nicht verwendet hast heißt das noch lange nicht das es "keinerlei
Vorteile bringt".
Christian
Da fällt mir gerade ein Lied vom Reinhard Mey ein(Bunter Hund) wo
vorkommt:
"... Ich belle wie ein Hund der nicht beisst, aber ich tue nur so..."
Gute Nacht,
Gerhard
someone schrieb:> Es ist daher generell empfehlenswert, wenn du schaust, dass der Code,> den du in deinem Buch schreibst, auch funktioniert. Das sollte durch> rigorose Tests geschehen. Gerade für Anfänger ist das sonst extrem> frustrierend, die können nämlich nicht einmal völlig offensichtliche> Fehler erkennen (wie denn auch?), selbst wenn diese versehentlich ihren> Weg ins Buch gefunden haben.
Danke und absolut berechtigte die Kritik!
Vor zehn Jahren war ich, nach längerer Pause, mal wieder zu Linux und C
zurück gekehrt und kaufte mir zur (Wieder-)Einarbeitung "Linux
Programmierung" von Richard Stones und Neil Matthew (3. aktualisierte
Auflage). Um den Steup zu testen schrieb ich folgendes Programm aus dem
Buch ab:
include <stdio.h>
int main
{
printf("hello World\n");
exit(0);
}
Ich weiß noch, wie frustriert ich war, als ich nach etwa 2 Stunden (die
Erinnerung kam wieder), die Include-Anweisung um ein einleitendes '#'
ergänzte und alles funktionierte.
Nochmals Danke
Jürgen
Moin Gerhard.
Gerhard O. schrieb:> Ohne Dich vor den Kopf stoßen zu wollen, muß ich zugeben, dass das Buch> von Barnett "Embedded C Programming and the Atmel AVR" mir persönlich> sehr nützlich bei meinem Einstieg in AVRs war, obwohl einige von Euch es> vor Jahren etwas kritisiert hatten als ich es hier irgendwo erwähnt> hatte.
Du stößt mich nicht vor den Kopf, denn ich gehöre (streng genommen) noch
nicht einmal zu dieser Community!
Ich bin mal auf den Link gegangen, nur leider bekommt man nicht einmal
das Inhaltsverzeichnis, geschweige denn einen Blick ins Buch.
> Dieses Buch behandelt so ziemlich alles was ein technisch versierter> Einsteiger wissen muss um als Startpunkt für eigene Designs zu dienen.> Seh es Dir mal an.
Hundert Mark, ohne zumindest vorher hinein sehen zu können, ist zu viel!
> Auch finde ich den Typ des MCUs ziemlich unwichtig. Wenn man einen AVR> kennt, kann man sich leicht in andere Familienmitglieder einarbeiten.
Sehe ich, weitgehend, genauso!
> Auch Projektplanung und Pflichtenhefterstellung wird empfohlen und> behandelt.
Viele hier meinen, diese zehn Seiten hätte ich geschrieben, um Seiten zu
schinden. Aus eigener Erfahrung weiß ich, wie wichtig diese Sachen in
jedem Projekt sind (nicht der Formalismus, den kann man bedenkenlos in
die Tonne treten); wenn die Übersicht in einem Projekt da ist (wodurch
auch immer), dann ist alles super; wenn die Übersicht nicht da ist, dann
macht man irgendetwas grottenfalsch (aber verständlicherweise will das
aber niemand höhren).
> Sorry für die Reklame des Buches! Ich weiß es ist hier unpassend.
Nee, ist es überhaupt nicht! Wenn ich etwas gegen diese Reklame hätte,
dann wäre das unpassend! Ich hatte mich im Internet und auf dem
Buchmarkt umgesehen und aus Frust, weil ich nichts vernünftiges finden
konnte, angefangen, ein eigenes Buch zu schreiben. Wenn es da draußen
etwas gibt, was genauso gut oder auch besser ist, als mein Konzept, dann
ist es alleine meine Schuld, dass ich nicht gut genug gesucht hatte (du
kannst mir glauben: sowohl Arbeit als auch Zeit hätte ich mir sehr gerne
gespart!).
Einige hier im Forum unterstellen mir ja Geltungsdrang und andere
unnette Charaktereigenschaften. Ich erinnere mich gerade an Fritz
Teufel, der vor Gericht aufgefordert wurde sich (wegen der Würde des
Gerichtes) zu erheben, und sagte: "Wenn es denn der Wahrheitsfindung
dient!". Wenn es denn einem guten Buch dient, dann mache ich problemlos
auch noch sehr viel mehr durch!
Gruß
Jürgen
Hallo Christian.
Christian Brandtner schrieb:> Bemühe mal die Suchfunktion mit dem Stichwort: verfust, dann wirst Du> erkennen das dieses Thema ein große Fallgrube für viele Anfänger ist.
Das ist nur deshalb eine Fallgrube für Anfänger, weil ihnen niemand
sagt, dass sie die Finger davon lassen sollten. Nenne mir doch bitte
einen einzigen Grund, warum ein Newbie irgendeine Fuse ändern sollte! Es
gibt schlicht keinen!
Wenn man ihm sagt, lass die Finger davon und er programmiert die Fuses
trotzdem um, dann 'bezahlt' er für diese Erfahrung und das halte ich
absolut für berechtigt (ich kenne auch ansonsten keinen Bereich, in dem
man für Ignoranz und Dummheit belohnt wird; warum sollte es hier anders
sein?).
Gruß
Jürgen
jdhenning schrieb:
(ich kenne auch ansonsten keinen Bereich, in dem
> man für Ignoranz und Dummheit belohnt wird; warum sollte es hier anders> sein?).>> Gruß> Jürgen
da hast Du Recht!
Ich werde keine weiteren Beiträge zu Deinem Wissen hinzufügen.
Erfolg für Dein Buch? die Hoffnung stirbt zuletzt.
Christian
jdhenning schrieb:> Einige hier im Forum unterstellen mir ja Geltungsdrang und andere> unnette Charaktereigenschaften.>
...nicht unbedingt! Man versucht dir nur begreiflich zu machen, dass
deine subjektiven Meinungen und langweiliges Geschwafel nicht in ein
Fachbuch gehören!
> Ich erinnere mich gerade an Fritz> Teufel, der vor Gericht aufgefordert wurde sich (wegen der Würde des> Gerichtes) zu erheben, und sagte: "Wenn es denn der Wahrheitsfindung> dient!". Wenn es denn einem guten Buch dient, dann mache ich problemlos> auch noch sehr viel mehr durch!>
...aber im nächsten Satz deiner Anmerkung verfällst du wieder in deinen
"heroischen" Stil, der einem nach einiger Zeit Kopfsausen bereitet.
Man bleibe endlich mal sachlich (hier und in dem Buch)! Sonst befürchte
ich ganz deutlich, dass das Buch nie gedruckt, geschweige gekauft wird!
Oder du münzt das Ding in einen netten Geschichtenband mit ein paar
Anekdoten aus deinem Leben um, damit die Zeit nicht ganz vergeudet
war...
Christian Brandtner schrieb:> jdhenning schrieb:> (ich kenne auch ansonsten keinen Bereich, in dem>> man für Ignoranz und Dummheit belohnt wird; warum sollte es hier anders>> sein?).>>>> Gruß>> Jürgen>> da hast Du Recht!>> Ich werde keine weiteren Beiträge zu Deinem Wissen hinzufügen.> Erfolg für Dein Buch? die Hoffnung stirbt zuletzt.>>> Christian
noch was vergessen dazu:
Ich hatte ja geglaubt das Du dank Deiner langjährigen (Projekt)Erfahrung
wissen müsstest das nicht alles so funktioniert wie man es sich
vorstellt/ geplant hat und man somit die sogenannte "Ignoranz und
Dummheit" nicht ausschließen kann.
Aber Du scheinst ja anzunehmen das die Leser(Anfänger) Deines Buches
Dich als den Atmega Gott ansehen und nichts anderes machen als das was
Du ihnen sagst.
Na dann.....ich kanns einfach nicht glauben und hoffe das O'Reilly hier
mitliest.
jdhenning schrieb:> und sagte: "Wenn es denn der Wahrheitsfindung> dient!". Wenn es denn einem guten Buch dient, dann mache ich problemlos> auch noch sehr viel mehr durch!
Hallo Jürgen,
Ja, ich kaufe auch nicht gerne die Katze im Sack. Das o.g. Buch wurde
mir von jemand wärmstens empfohlen und so bestellte ich es mir vor 11
Jahren und es war mir am Anfang recht nützlich.
Um die Projektplanung sollte man sich sicherlich nicht drücken und in
dem Buch wird es ja auch vorgeschlagen. In praktisch jeden guten MCU
Buch ist es ähnlich.
Freut mich daß ich Dir bis jetzt nicht zu sehr auf die Zehen getreten
bin:-)
Trotzdem schlage ich Dir vor einen kurzen Urlaub vom Buchprojekt zu
machen und dann mit neuer Energie und Perspektive weiter zu machen.
Vieles was hier gesagt wurde hat schon Hand und Fuß.
Ich finde übrigens das Buch "C and the 8051 Programming for
Multitasking" von Thomas W. Schultz ist eine recht gute Buchvorlage. Es
hat so ziemlich alles drin. Es setzt allerdings schon einige
Programmiererfahrungen voraus.
Leider sind alle diese Bücher in englischer Sprache und ich habe
deswegen vielleicht einen kleinen Vorteil.
In Bezug auf den Wert oder Unwert von Bootloadern bin ich der Ansicht:
"It really depends..."
Meine Firmenprojekte benötigen meist alle einen B.L. für zukünftige
Kunden Upgrades. In der Entwicklungsphase bevorzuge ich wegen dem
bequemeren Debugging direkten Anschluß des JTAG Programmiergeräts. Im
Source Code habe ich dann nur einen Define der dann die nötigen Offset
Änderungen vornimmt. So ist das Umschalten zwischen Release- und
Entwicklungsmode recht einfach. Ich habe meistens eine Board mit dem
B.L. Drin und eine andere ohne. Dann geht das Testen zwischen beiden
Versionen ruck-zuck.
Grüsse,
Gerhard
Moin Christian.
Christian Brandtner schrieb:> 1. weil ich das Geraffel des Programmierers nicht ständig brauche
Ähh, sorry, aber ich verstehe nicht, was du damit meinen könntest. Falls
du die Ausgaben von USBasp auf den Bildschirm meinst, dann kann ich dir
versichern, dass sich da jemand einige Gedanken gemacht hat, weshalb die
ausgegeben werden. Auch wenn es dich nervt, für einen Newbie könnte es
wissenswert sein.
> 2. weil es schneller funktioniert über Rx/Tx
Wenn ich mir ansehe, wie viel Zeit für die Datenübertragung benötigt
wird und wie viel Zeit für die Programmierung der Flash-Seiten, dann ist
das lediglich ein marginaler Effekt. Zumindest für einen Newbie völlig
irrelevant!
> 3. weil ich den ISP-Progger nicht ständig an/abstecken muss, die Pins> brauche ich ja für meine Anwendung.
Da könnte bessere Planung sehr hilfreich sein (nur falls es dir
entgangen sein sollte, hatte ich in meinem Manuskript auch geschrieben,
dass dies einer der wenigen Gründe sein könnte [keine anderen Pins
frei], warum man auf diese Methode zurückgreift). Also für einen Newbie
auch völlig irrelevant!
> 4. Rx/Tx brauche ich sowieso für einfache Debugmöglichkeiten.
Und in wiefern behindert sich das? Ich habe seitenweise darüber
geschrieben, dass Rx/Tx eine ziemlich gute Möglichkeit darstellen, eine
relativ gute Debug-Möglichkeit zu realisieren. Wo siehst du hier einen
Konflikt mit einem USB-Programmer im Gegensatz zu einem Bootloader? Wie
viele Newbies werden hier in einen Zielkonflikt kommen können? Ungefähr
0,0018 in den nächsten 15 Jahren?
Da ich nicht ständiges Mitglied dieser Community bin weiß ich natürlich
auch nicht, welcher Qualitätsstandard normalerweise hier an Posts
angelegt wird. Dein Level als Messlatte scheint mir aber deutlich zu
niedrig zu sein, um sinnvolle Diskussionen zu ermöglichen.
Gruß
Jürgen
Christian Brandtner schrieb:> Aber Du scheinst ja anzunehmen das die Leser(Anfänger) Deines Buches> Dich als den Atmega Gott ansehen und nichts anderes machen als das was> Du ihnen sagst.
Nöh, mach ich nicht und will ich auch gar nicht! Was hat dich auf diese
abwegige Idee gebracht? Liest du hier Texte, die niemand geschrieben
hat? Es kann da Hilfe geben!
jdhenning schrieb:> Moin Christian.>> Da ich nicht ständiges Mitglied dieser Community bin weiß ich natürlich> auch nicht, welcher Qualitätsstandard normalerweise hier an Posts> angelegt wird. Dein Level als Messlatte scheint mir aber deutlich zu> niedrig zu sein, um sinnvolle Diskussionen zu ermöglichen.>> Gruß> Jürgen
ja Jürgen, Du bist scheinbar auch ein Hobbypsychologe.
Um den Level zu nivellieren kannst Du Dir das ja mal anschauen:
http://wiki.mikrokopter.de/Portables%20Mikrokoptertool
Dazu hat 1974 ein gefädelter 8080 Mikroprozzesor auf Eurokarte, ab 2011
ein Atmega mit C, die Datenblätter, das Forum und Internet gereicht.
Und nun bin ich raus, mach was Du willst...
Hallo Gerhard.
Gerhard O. schrieb:> Freut mich daß ich Dir bis jetzt nicht zu sehr auf die Zehen getreten> bin:-)
Erstens nein und zweitens habe ich sowieso Plattfüße. Würde keinen
Unterschied machen.
> Vieles was hier gesagt wurde hat schon Hand und Fuß.
Weiß ich, aber das muss ich ja nun nicht auch noch offiziell zugeben,
oder?
> Ich finde übrigens das Buch "C and the 8051 Programming for> Multitasking" von Thomas W. Schultz ist eine recht gute Buchvorlage.
Ich kenne das Buch nicht und die Info auf Amazon ist auch sehr spärlich.
Aufgrund der minimalen Info vermute ich, dass ich etwas ziemlich
ähnliches versuche (obwohl 20 Jahre später); wurde mir aber schon in
einem anderen Post gesagt, dass ich mit diese Vorhaben bestenfalls die
Nummer 100 bin; hat mich aber trotzdem nicht beeindruckt).
> Leider sind alle diese Bücher in englischer Sprache und ich habe> deswegen vielleicht einen kleinen Vorteil.
Nachdem in diesem Thread jemand behauptet hatte, ich würde das ja alles
wegen fehlender Sprachkenntnis nicht verstehen könnte; don't worry, I
can! Better than most native speakers!
> In Bezug auf den Wert oder Unwert von Bootloadern bin ich der Ansicht:> "It really depends..."
Yepp. Früher waren sie gut und sinnvoll und sie sind es jetzt noch,
allerdings nur in sehr gut begründeten Ausnahmen. Bei anderer Meinung
wäre ich dankbar für eine gute Begründung.
> Meine Firmenprojekte benötigen meist alle einen B.L. für zukünftige> Kunden Upgrades. In der Entwicklungsphase bevorzuge ich wegen dem> bequemeren Debugging direkten Anschluß des JTAG Programmiergeräts. Im> Source Code habe ich dann nur einen Define der dann die nötigen Offset> Änderungen vornimmt. So ist das Umschalten zwischen Release- und> Entwicklungsmode recht einfach. Ich habe meistens eine Board mit dem> B.L. Drin und eine andere ohne. Dann geht das Testen zwischen beiden> Versionen ruck-zuck.
Äähh, wenn die Pins für ISP frei sind, wo liegt da der Vorteil eines BL?
Ich bin, zugegebenermaßen, extrem hartnäckig (nicht unbelehrbar, wie
hier einige behaupten), aber irgendeinen Vorteil für einen Bootloader
sehe ich hier absolut nicht. Wäre dankbar für eine Erleuchtung!
Grüße
Jürgen
Hallo Jürgen,
jdhenning schrieb:> Hallo Gerhard.>> Gerhard O. schrieb:>> Freut mich daß ich Dir bis jetzt nicht zu sehr auf die Zehen getreten>> bin:-)> Erstens nein und zweitens habe ich sowieso Plattfüße. Würde keinen> Unterschied machen.
Dann ist es ja gut:-)
>>> Vieles was hier gesagt wurde hat schon Hand und Fuß.> Weiß ich, aber das muss ich ja nun nicht auch noch offiziell zugeben,> oder?>>> Ich finde übrigens das Buch "C and the 8051 Programming for>> Multitasking" von Thomas W. Schultz ist eine recht gute Buchvorlage.> Ich kenne das Buch nicht und die Info auf Amazon ist auch sehr spärlich.
Das Buch ist wie Du Dir denken kannst schon sehr alt.
> Aufgrund der minimalen Info vermute ich, dass ich etwas ziemlich> ähnliches versuche (obwohl 20 Jahre später); wurde mir aber schon in> einem anderen Post gesagt, dass ich mit diese Vorhaben bestenfalls die> Nummer 100 bin; hat mich aber trotzdem nicht beeindruckt).>>> Leider sind alle diese Bücher in englischer Sprache und ich habe>> deswegen vielleicht einen kleinen Vorteil.> Nachdem in diesem Thread jemand behauptet hatte, ich würde das ja alles> wegen fehlender Sprachkenntnis nicht verstehen könnte; don't worry, I> can! Better than most native speakers!
Das glaube ich Dir. Deutschsprachige Bücher scheinen aber doch mehr
gefragt zu sein.
>>> In Bezug auf den Wert oder Unwert von Bootloadern bin ich der Ansicht:>> "It really depends..."> Yepp. Früher waren sie gut und sinnvoll und sie sind es jetzt noch,> allerdings nur in sehr gut begründeten Ausnahmen. Bei anderer Meinung> wäre ich dankbar für eine gute Begründung.>>> Meine Firmenprojekte benötigen meist alle einen B.L. für zukünftige>> Kunden Upgrades. In der Entwicklungsphase bevorzuge ich wegen dem>> bequemeren Debugging direkten Anschluß des JTAG Programmiergeräts. Im>> Source Code habe ich dann nur einen Define der dann die nötigen Offset>> Änderungen vornimmt. So ist das Umschalten zwischen Release- und>> Entwicklungsmode recht einfach. Ich habe meistens eine Board mit dem>> B.L. Drin und eine andere ohne. Dann geht das Testen zwischen beiden>> Versionen ruck-zuck.> Äähh, wenn die Pins für ISP frei sind, wo liegt da der Vorteil eines BL?
Da war ich etwas hinterlistig. Meine Bemerkung bezog sich auf STM32s wo
die JTAG Pins bis auf ein, zwei Ausnahmen auf Reserviert sind. Beim AVR
lege ich meine SPI Beschaltung so aus, dass sie ohne weiters coexistent
mit dem Programmiergerät ist. Das ist meistens kein Problem. Mit ein
paar Widerständen ist das meist kein wirkliches Problem.
> Ich bin, zugegebenermaßen, extrem hartnäckig (nicht unbelehrbar, wie> hier einige behaupten), aber irgendeinen Vorteil für einen Bootloader> sehe ich hier absolut nicht. Wäre dankbar für eine Erleuchtung!>
Wie schon gesagt bin ich der Ansicht "It depends"
Bei kommerziellen Produkten ist heutzutage ein B.L. Teil des
Pflichtenhefts und deshalb nicht mehr wegzudenken für komplizierte
Entwicklungen. Deshalb heisst es ja auch oft "Banana Policy" - Let the
product ripe with the customer.
Spass beiseite. Ist halt eine Frage der Bequemlichkeit. Im Prinzip kommt
man mit beiden Methoden klar und in Spezialfällen ist es sowieso
offensichtlich wie man es machen sollte. Ich würde halt im Buch ein
Beispiel geben wie man es prinzipiell macht und vielleicht auf Internet
Resourcen verweisen. Da man beim B.L. meist mit einem dedikierten
Steuerprogramm arbeiten will braucht man ja ein Programm für die andere
Seite. Ich habe allerdings schon B.L. Sachen mit einem Terminalprogramm
gemacht und gute Erfolge gehabt. In der Firma musste ich mal für einen
DSPIC vor ein paar Jahren einen AES geschützten B.L. Schreiben. Das war
trotz AES Beispielscode eine interessante Sache. Funktionierte am Ende
ganz gut, nur schaffte ich nicht mehr als 30kB/s. Also,
Geschwindigkeitsrecorde komnte man damit nicht aufstellen. Aber darauf
kommt es ja nicht wirklich an.
Ich weiß nicht wie ich Deine Frage wirklich beantworten soll. Es kommt
halt auf die jeweiligen Projektumstände an. z.B. Ein B.L. hat bestimmt
Sinn, wenn man irgend etwas baut woran man nicht leicht physisch ran
kommt und ab und zu die Firmware ersetzen muß. Meine selbstgebaute
Wetterstation mit einigen MCUs die über RS485 kommunizieren. Da wäre ein
B.L. recht praktisch wenn ich Änderungen an der FW. Machen wollte. Habe
ich aber leider nicht so gemacht weil mir das jetzt zu viel Arbeit wäre.
Oder ein komplexeres System mit mehreren Satelliten-MCUs wo der
Haupt-MCU die kleineren Brüder updaten muß. und, und, und... Mir fällt
im Augenblick nicht mehr viel dazu ein.
Grüße,
Gerhard
> Grüße> Jürgen
jdhenning schrieb:>> Meine Firmenprojekte benötigen meist alle einen B.L. für zukünftige>> Kunden Upgrades. In der Entwicklungsphase bevorzuge ich wegen dem>> bequemeren Debugging direkten Anschluß des JTAG Programmiergeräts. Im>> Source Code habe ich dann nur einen Define der dann die nötigen Offset>> Änderungen vornimmt. So ist das Umschalten zwischen Release- und>> Entwicklungsmode recht einfach. Ich habe meistens eine Board mit dem>> B.L. Drin und eine andere ohne. Dann geht das Testen zwischen beiden>> Versionen ruck-zuck.> Äähh, wenn die Pins für ISP frei sind, wo liegt da der Vorteil eines BL?> Ich bin, zugegebenermaßen, extrem hartnäckig (nicht unbelehrbar, wie> hier einige behaupten), aber irgendeinen Vorteil für einen Bootloader> sehe ich hier absolut nicht. Wäre dankbar für eine Erleuchtung!
Die Kunden haben kein Programmiergerät ?
(Das ist für mich der eigentliche Sinn eines BL)
Volker SchK schrieb:> Äähh, wenn die Pins für ISP frei sind, wo liegt da der Vorteil eines BL?> Ich bin, zugegebenermaßen, extrem hartnäckig (nicht unbelehrbar, wie> hier einige behaupten), aber irgendeinen Vorteil für einen Bootloader> sehe ich hier absolut nicht. Wäre dankbar für eine Erleuchtung!> Die Kunden haben kein Programmiergerät ?> (Das ist für mich der eigentliche Sinn eines BL)
Kurz und prägnant, so beantwortet jemand mit ERFAHRUNG so eine Frage
ohne um den heißen Brei zu reden.
Es ist schon erstaunlich mit welcher Vehemenz und Arroganz du hier deine
Unwissenheit zur Schau stellst.
Und dabei aber nicht Müde wirst zu erwähnen dass du 30 Jahre Erfahrung
hast, und "zu den Großen" (sic) gehörst und dir deshalb nichts, aber
auch gar nichts sagen lässt.
Dann aber im nächsten Post erzählst du dass dich ein fehlendes
Rautezeichen vor einem Include in einem Beispielcode Stunden der
Fehlersuche gekostet hat.
Warum ist es so schwer zu verstehen und/oder zu akzeptieren dass ein
grundlegendes Verständnis von RA (wie auch immer geartet) plus die
Lektüre eines Datenblattes NICHT dazu befähigt ein Fachbuch für Anfänger
zu einem konkreten MCU zu schreiben? Für einen normal denkenden Menschen
sollte das auf der Hand liegen und dein Buch zeigt doch dass dir zu
wichtigen Themen das Wissen und die Erfahrung schlicht fehlt.
>Die Kunden haben kein Programmiergerät ?>(Das ist für mich der eigentliche Sinn eines BL)
Und genau so wichtig, die Kunden sollen das Gerät nicht aufschrauben
müssen. Da bestünde immer die Gefahr, dass dabei das Gerät, Boards oder
Bauteile beschädigt werden.
Helmut S. schrieb:>>Die Kunden haben kein Programmiergerät ?>>(Das ist für mich der eigentliche Sinn eines BL)>> Und genau so wichtig, die Kunden sollen das Gerät nicht aufschrauben> müssen. Da bestünde immer die Gefahr, dass dabei das Gerät, Boards oder> Bauteile beschädigt werden.
Oder man möchte den unverschlüsselten Binärcode nicht rausgeben.
Oder man möchte den Weg des SW-Updates einfach komplett selbst
bestimmen.
Es gibt genug gute Gründe für einen BL.
Zu dem Bootloader:
Es gibt sogar die Möglichkeit manche Geräte über Funk mit der neuesten
Firmware auszustatten.
Der Grund ist recht einfach, entweder man kommt nicht ran an das Gerät
oder es wurde komplett eingegossen da es unter widrigen Bedingungen
arbeiten muss.
Das Laden des ebenfalls eingegossenen Akkus macht man ebenfalls über
eine kleine Spule am Boden.
Es ist eigentlich sehr schön wenn ein Chip einen USB-Anschluss hat (wie
der ATXmega128A4U) und man über diese Schnittstelle Daten austauschen
kann und auch eine neue Firmware auf den Chip schreiben kann.
Ich habe hier auch zwei PDI-Programmer, aber es ist praktisch den
vorhandenen USB-Anschluss am Chip zu nutzen da man das Board nicht jedes
mal abstecken muss.
Bei dem kleinen und billigen Arduino-Platinen kann man das auch machen
wenn man will ... man muss aber nicht.
Oft hat man auch keine Bootloader drauf weil man den Platz nicht
verschwenden will oder einfach keinen Anschluss zur Kommunikation für
einen Bootlader zur Verfügung hat.
Moin Gerhard.
Gerhard O. schrieb:> Ich weiß nicht wie ich Deine Frage wirklich beantworten soll. Es kommt> halt auf die jeweiligen Projektumstände an. z.B. Ein B.L. hat bestimmt> Sinn, wenn man irgend etwas baut woran man nicht leicht physisch ran> kommt und ab und zu die Firmware ersetzen muß. Meine selbstgebaute> Wetterstation mit einigen MCUs die über RS485 kommunizieren. Da wäre ein> B.L. recht praktisch wenn ich Änderungen an der FW. Machen wollte. Habe> ich aber leider nicht so gemacht weil mir das jetzt zu viel Arbeit wäre.> Oder ein komplexeres System mit mehreren Satelliten-MCUs wo der> Haupt-MCU die kleineren Brüder updaten muß. und, und, und... Mir fällt> im Augenblick nicht mehr viel dazu ein.
Danke, die Begründung kann ich nachvollziehen, aber solche Projekte sind
wohl eher die absolute Ausnahme. Ich habe gerade ein Bierchen lang
darüber nachgedacht, wie ich das einem Newbie sinnvoll vermitteln
könnte. Ich glaube, ich werde es bei einem Hinweis belassen, dass es
Situationen gibt, in denen ein Bootloader sinnvoll sein könnte.
Danke für den langen Post
Jürgen
Volker SchK schrieb:> Die Kunden haben kein Programmiergerät ?> (Das ist für mich der eigentliche Sinn eines BL)
Ich bin anscheinend zu pragmatisch eingestellt. So ein Programmiergerät,
das man an einen USB-Port hängt und über USBasp programmiert, kostet
keine 10 Euro. Ich würde dem Kunden so ein Teil ganz einfach schenken!
Gruß
Jürgen
jdhenning schrieb:> Ich würde dem Kunden so ein Teil ganz einfach schenken!
Ich glaub irgendwie nicht, dass er eines haben will.
Das muss er nur wieder irgendwo aufheben ...
Cyblord ---- schrieb:> Oder man möchte den unverschlüsselten Binärcode nicht rausgeben.
Sollte man im professionellen Umfeld bestimmt nicht unterschätzen !
Zum Entwickeln finde ich einen Bootloader allerdings auch das Letzte.
Das muss man sich echt nicht mehr antun ;-)
Cyblord ---- schrieb:> ... und dir deshalb nichts, aber auch gar nichts sagen lässt.
Wie kommst du denn auf diese verschrobene Idee? Wenn mir hier jemand
schreibt, dieses oder jenes wäre nicht korrekt oder es wäre nicht
sinnvoll, es in der Form darzulegen (und das auch belegt oder sinnvoll
begründet), dann habe ich da überhaupt keine Probleme mit; ich bin sogar
eher dankbar.
> Dann aber im nächsten Post erzählst du dass dich ein fehlendes> Rautezeichen vor einem Include in einem Beispielcode Stunden der> Fehlersuche gekostet hat.
Ich bin halt im Gegensatz zu dir nicht unfehlbar. Wenn ich eine
Programmiersprache 12 Jahre nicht mehr benutzt habe, dann sind meine
Kenntnisse eingerostet und ich habe dann Probleme, die ich zehn Jahre
früher nicht gehabt hätte. Wo siehst du da ein Problem?
Zudem scheinst du Schwierigkeiten mit formaler Logik zu haben.
Einerseits behauptest du, dass die Datenblätter von Atmel über jeden
Zweifel erhaben sind und da alles richtig und vernünftig drin steht (was
ich gewagte habe in Zweifel zu ziehen). Und dann behauptest du, dass es
auf keinen Fall genügen kann, das Datenblatt durchzuarbeiten. Ja was
denn nun?
Helmut S. schrieb:> Und genau so wichtig, die Kunden sollen das Gerät nicht aufschrauben> müssen. Da bestünde immer die Gefahr, dass dabei das Gerät, Boards oder> Bauteile beschädigt werden.
Und da ist ein prinzipieller Unterschied zwischen normaler ISP und
Update über einen Bootloader? Zeig den doch bitte mal auf.
Cyblord ---- schrieb:> Oder man möchte den unverschlüsselten Binärcode nicht rausgeben.>> Oder man möchte den Weg des SW-Updates einfach komplett selbst> bestimmen.
Das soll man einem Newbie vor die Füße werfen, der nur lernen möchte,
was eine MCU ist, wie sie funktioniert und wie man sie programmieren
kann? Und mir dann mangelnde didaktische Fähigkeiten vorwerfen!
Wenn das Gerät schon einen USB Anschluss hat dann bräuchte der Kunde nur
einenen PC mit USB Schnittstelle. In manchen Fällen genügt ein einfaches
Terminalprogramm zur Überspielung. Bei einem PIC Projekt machte ich das
so. Es gibt ja auch freie PC bootloader Host Programme. Beim STM32 hat
sich übrigens das freie Programm MicroBLT bei mir sehr bewährt. Geht
auch über USB.
Grüsse,
Gerhard
jdhenning schrieb:> Cyblord ---- schrieb:>> Oder man möchte den unverschlüsselten Binärcode nicht rausgeben.>>>> Oder man möchte den Weg des SW-Updates einfach komplett selbst>> bestimmen.>> Das soll man einem Newbie vor die Füße werfen, der nur lernen möchte,> was eine MCU ist, wie sie funktioniert und wie man sie programmieren> kann? Und mir dann mangelnde didaktische Fähigkeiten vorwerfen!
Da hast du doch dann schon eine Situation die du konkret erwähnen
könntest.
Ich glaube die vertehen das schon.
jdhenning schrieb:> Ich glaube, ich werde es bei einem Hinweis belassen, dass es> Situationen gibt, in denen ein Bootloader sinnvoll sein könnte.
Ich glaub sogar meine Waschmaschine hat einen Bootloader der vermutlich
nie gebraucht werden wird. Was solls, den entwickelt man nur einmal und
klascht ihn einfach in jedes Gerät bei dem es sich lohnen könnte mit
rein.
jdhenning schrieb:> Cyblord ---- schrieb:>> Oder man möchte den unverschlüsselten Binärcode nicht rausgeben.>>>> Oder man möchte den Weg des SW-Updates einfach komplett selbst>> bestimmen.>> Das soll man einem Newbie vor die Füße werfen, der nur lernen möchte,> was eine MCU ist, wie sie funktioniert und wie man sie programmieren> kann? Und mir dann mangelnde didaktische Fähigkeiten vorwerfen!
NEIN du sollst nur nicht behaupten dass man Bootloader grundsätzlich
nicht brauchen würde. Denn das ist Humbug.
Meiner Meinung nach solltest du überhaupt nichts in dein Buch schreiben
und ganz allgemein davon Abstand nehmen, anderen etwas beibringen zu
wollen.
Und ich habe kein Problem mit Logik sondern DU.
Die Qualität der Datenblätter hat NICHTS mit der Tatsache zu tun, dass
ein kurzes Studium derselben, einen nicht dazu befähigt ein Anfängerbuch
zu schreiben. Dazu benötigt man Erfahrung mit der Materie, sonst macht
man genau deine Fehler. Man verdammt Dingen die man nicht versteht. Und
das ist peinlich peinlich peinlich für einen Fachbuchautor. Und wir
reden hier nicht über Raketenwissenschaft sondern über recht triviale
Dinge die du halt nicht verstanden hast.
Nochmal werd ich dir das aber sicher nicht erklären. Wenn du
intellektuell nicht in der Lage bist meine Posts zu verstehen, so komme
ich damit gut klar.
jdhenning schrieb:> Ich bin anscheinend zu pragmatisch eingestellt. So ein Programmiergerät,> das man an einen USB-Port hängt und über USBasp programmiert, kostet> keine 10 Euro. Ich würde dem Kunden so ein Teil ganz einfach schenken!>
mal abgesehen von dem restlichen Blödsinn, Halbwissen etc., den/das du
hier und in deinem komischen Buch (...ja, ich habe es mir mal 1h zu
Gemüte geführt, da diese Diskussion schon recht amüsant ist...) von dir
gibst, zeugt obige Aussage mal wieder von deinem Un-/Halbwissen, deiner
fachlichen Ungenauigkeit, Selbstüberschätzung etc.!
Das "Programmiergerät" heisst usbasp. Die Software, mit der man mit
diesem Ding MCUs programmieren könnte z.B. avrdude (und Konsorten) sein.
Mal abgesehen, dass du den Sinn eine Bootloaders nicht verstehst oder
nicht verstehen möchtest (was ich als Ignoranz ansehe) --> dein Anspruch
ist es ein umfassendes Buch über einen ATmega8 zu schreiben? Dann gehört
dies (wie auch die oben viel diskutierten Fuses und zahlreiche weitere
Themen) in ein solches Werk hinein! Alles andere ist wieder irgend ein
WischWaschi-Buch, welche es schon gibt (z.B. Franzis; "Lernpakete
irgendwas xxx42...")!
Wie beratungsresistent und von sich überzeugt, muss man eigentlich sein,
um sich hier wie ein kleines Kind aufzuführen? Die Zeit, die du hier für
deine Rechtfertigungen und komisches Nachdenken über andere Meinungen
verwendest, solltest du für die Umarbeitung deines "Buches" benutzen!
Ich an deiner Stelle würde mit den hier geschriebenen Worten/Meinungen
mal in mich gehen und das Beste daraus machen! Hier laufen/lesen Typen
rum, die alle mal mit der Materie angefangen haben und sehr genau
wissen, was ihnen das Leben damals leichter gemacht hätte.... Und genau
das wollen sie dier hier sagen, nur das du das nicht zu verstehen
scheinst, eigentlich schade!
Grüße Uwe
PS.: ...und falls du jetzt mit deinen gefühlten 100 Jahren
Berufserfahrung kommen solltest und mir gegenüber den bekannten
"Lehrmeister" raushängen möchtest: ich bin mindestens genau so alt wie
du, kenne mich auch mit der Lochkarten/Fortran/Cobol-Ära aus und
habe..., ach was solls, vergesse es!
jdhenning schrieb:> Und da ist ein prinzipieller Unterschied zwischen normaler ISP und> Update über einen Bootloader? Zeig den doch bitte mal auf.>
z.B. die Schrauben und der Aufbewahrungsort für das Programmiergerät.
Hast du schon mal "draussen im Feld" gearbeitet? Scheinbar nicht, sonst
hättest du eine ungefähre Ahnung, was dir hier seit Tagen irgendwelche
Leute sagen möchten!
Grüße Uwe
Atmega8 Atmega8 schrieb:> Es ist eigentlich sehr schön wenn ein Chip einen USB-Anschluss hat (wie> der ATXmega128A4U) und man über diese Schnittstelle Daten austauschen> kann und auch eine neue Firmware auf den Chip schreiben kann.
Man kann es auch so machen: http://matrixstorm.com/avr/tinyusbboard/
Da ist der USB-Treiber im Bootloader-Sektor drin. Für die allerersten
Schritte noch einfacher.
Moin Uwe.
Uwe Berger schrieb:> Das "Programmiergerät" heisst usbasp. Die Software, mit der man mit> diesem Ding MCUs programmieren könnte z.B. avrdude (und Konsorten) sein.
Mit dieser Aussage hast du recht. Da hatte ich zu schnell getippt.
Wenn du etwas länger als eine Stunde in dem Manuskript geblättert
hättest, hättest du auf den Seiten 27 bis 30 gesehen, dass ich es dort
korrekt erkläre und auf der Seite 176 habe ich auch die Links auf die
jeweiligen Homepages. Du versuchst also eine Mücke zum Elephanten
aufzublasen (das scheint hier im Forum ein beliebtes Hobby zu sein).
jdhenning schrieb:> Ähh, sorry, willst du mich und die anderen hier im Forum verarschen? Ich> habe über 30 Jahre Erfahrung in der Softwareentwicklung, wo auch einige> Jahre mit Hardware-Auswahl und/oder Hardware-Entwicklung dabei waren.Butter bei die Fische schrieb:> Du bist über 20 Jahre raus aus dem Job. Du bist ein Blender, der eine> große Schnauze hat.jdhenning schrieb:> Alles das, was an Technologie im ATmega8 oder auch im ATmega328 drin> ist, ist absolute Computersteinzeit (Funktion, nicht> schaltungstechnische Umsetzung). Da könnte ich sogar 30 Jahre aus dem> Job raus sein und mein Wissen wäre immer noch top aktuell!Cyblord ---- schrieb:> Es ist schon erstaunlich mit welcher Vehemenz und Arroganz du hier deine> Unwissenheit zur Schau stellst.> Und dabei aber nicht Müde wirst zu erwähnen dass du 30 Jahre Erfahrung> hast, und "zu den Großen" (sic) gehörst und dir deshalb nichts, aber> auch gar nichts sagen lässt.> Dann aber im nächsten Post erzählst du dass dich ein fehlendes> Rautezeichen vor einem Include in einem Beispielcode Stunden der> Fehlersuche gekostet hat.jdhenning schrieb:> Ich bin halt im Gegensatz zu dir nicht unfehlbar. Wenn ich eine> Programmiersprache 12 Jahre nicht mehr benutzt habe, dann sind meine> Kenntnisse eingerostet und ich habe dann Probleme, die ich zehn Jahre> früher nicht gehabt hätte. Wo siehst du da ein Problem?
Ohne Kommentar
Uwe Berger schrieb:> Hast du schon mal "draussen im Feld" gearbeitet? Scheinbar nicht, sonst> hättest du eine ungefähre Ahnung, was dir hier seit Tagen irgendwelche> Leute sagen möchten!
Ja, habe ich. Vielleicht ist das der Grund, warum ich hier einige Leute
nicht verstehen kann.
Thomas Eckmann schrieb:> Ohne Kommentar
Das ist schade, denn ich weiß nicht, wass du bezweckst. Willst du damit
nachweisen, dass hier etliche Leute absolut unqualifiziert rumpöbeln und
ich nicht? Danke für die Arbeit, wäre aber nicht nötig gewesen, denn
jeder Leser braucht nur wenige Minuten, um das selbst heraus zu finden.
Und Tschüs
Jürgen
Merkt ihr was?
Sobald in einem Post viele "du" und "ich" auftauchen, geht es nicht mehr
um die Sache, sondern nur noch um "dich" und "mich".
Zur Sache:
Ich plädiere immer noch für viele Abbildungen und Skizzen. Die heutige
Jugend lernt nicht mehr aus textorientierten Büchern, sondern extrem
visuell orientiert aus Filmchen. Da ist eine ganze Seite ohne Bild schon
arg anstrengend...
Guten Abend,
Erstmal Lob, zum Buch-Umfang, das war sicher eine Menge Arbeit!
Ich habe jetzt auch mal ein wenig quer gelesen, etwas fiel relativ
schnell auf (Seite 36):
der Tip mit den Kommentaren und dem "// /*" ist zwar in der Praxis sehr
praktisch, ich denke aber, dass er an dieser Stelle nicht hin passt,
weil da gerade etwas über logische Verknüpfungen erklärt werden soll und
nicht über Kommentare!
Ich würde als Autor über das Buch nochmal drüber-lesen und schauen, dass
ich die Texte restrukturiere in dem Sinne, wie die Themen in anderen
Büchern (in diesem Fall über C) geordnet wurden.
In diesem Fall den Tip zu den Kommentaren an die Stelle setzen, in dem
die Kommentare erläutert werden.
Ich musste bei Programmier-Anfängern immer wieder feststellen, dass ich
gerne gut gemeinte Tips als "Randnotiz" mit auf den Weg geben wollte,
dies aber letztlich meist nur für mehr Verwirrung als "Aha"-Erlebnisse
gesorgt hat.
Weiterhin frohes Schaffen!
VG Alex
Am Ende von 1.4.1 ist der Absatz vom Thema unpassend, der gehört weiter
nach oben:
"Die Programmierung des Flash-Speichers erfolgt immer seitenweise und
eine Seite hat 64 Byte. Da
die MCU 8kByte Flash hat, gibt es demzufolge 128 Seiten. Doch zunächst
im Überblick die
prinzipiellen Möglichkeiten, Daten (also letztlich Programme) in diesen
Flash-Speicher zu
bekommen."
Paul schrieb im Beitrag #3956612:
> Zu diesem Forum:Jedes andere wäre besser gewesen, um nach Meinungen zu> fragen. Dieses hier ist
eins der wenigen, in dem sich Leute tummeln, die zumindest noch wissen,
was ein Buch überhaupt ist...
Oliver
Sanchez schrieb im Beitrag #3957710:
> Aber wirklich krass ist dieses Forum! Kannte ich vorher noch nicht. Mag> am Thema vorbeigehen und würde sicher einen eigenen Thread lohnen, aber> ich möchte es genau hier loswerden. Ich habe noch nirgendwo eine solche> Dichte von Meckerern und Miesmachern erlebt! Steht in den Forenregeln> vielleicht was von einem Zwang zu Engstirnigkeit und Negativismus? Die> hilfreichen Beiträge werden von dummen und unsachlichen Angriffen> verdeckt. Ich frage mich, was das für Typen sind, die ohne jede> Höflichkeit die Arbeit anderer heruntermachen. Kritik ist hilfreich und> ok., aber diese Flut von kleinkarierten persönlichen Angriffen spricht> von Leuten, die besser eine Psychotherapie machen sollten.
Tja in diesem Forum wird Bullshit als solcher benannt. Wenn du bisher in
einer wohlbehütete rosa Kuschelwolke aufgewachsen bist kennst du so was
vermutlich nicht.
Die Kritik an Jürgen und seinem Buch ist absolut gerechtfertigt. Sein
Fachwissen ist Mau, seine Schreibe ist grausam, seine arrogante Art
nimmt bereits krankhafte Züge an.
Jemandem so etwas zu sagen, mag vielleicht unhöflich sein, notwendig ist
es aber in jedem Fall.
Lothar Miller schrieb:> Zur Sache:> Ich plädiere immer noch für viele Abbildungen und Skizzen. Die heutige> Jugend lernt nicht mehr aus textorientierten Büchern, sondern extrem> visuell orientiert aus Filmchen. Da ist eine ganze Seite ohne Bild schon> arg anstrengend...
Das ist (leider?) wahr. Schon seit Jahrtausenden beklagen sich die
Lehrer (in Ost und West) darüber, dass die Schüler von Jahr zu Jahr
dümmer und fauler werden. Ich bin kein Mediendesigner und vermute, dass
die Wissensvermittlung per Videoclip nur recht beschränkt möglich ist
(obwohl viele das möchten).
Viele (zusätzliche) Bilder und Skizzen sind vorgesehen und sicherlich
auch nötig. Auf der anderen Seite (entsprechend der Meinung einiger
hier) ist ein Programmierbeispiel, wie man mit Timer 1 eine LED blinken
lassen kann, völlig überflüssig; wenn jemand die Register von Timer 1
verstanden hat, dann hat er mit so einer Aufgabe keine Schwierigkeiten.
Und dieses Verständnis wird ihm kein Video-Clip vermitteln können (das
wäre ja wie ein Jurastudium über Facebook).
Gruß
Jürgen
Evtl. interessieren ein paar Beispiele zum Thema Bootloader im
"täglichen" Leben (zumindest in meinem Haushalt): Ravensburger Tiptoi
Stift, Speedport Router, Polar Fitnessarmband.
Hallo Paul.
Paul schrieb im Beitrag #3956612:
> Zu diesem Forum:Jedes andere wäre besser gewesen, um nach Meinungen zu> fragen. Dieses hier ist bekannt für Arroganz, Selbstbeweihräucherung und> Besserwisserei.
Vielen Dank für die aufmunternden Worte, aber sieh es einfach mal anders
herum: Wenn ich es in diesem Forum schaffe (bisher hat man mir ja nur
ein paar Pillepallefehler nachweisen können), mein Buchvorhaben zu
verteidigen, dann hätte ich es überall sonst auf jeden Fall geschafft.
So habe ich aber ein viel besseres Gefühl, dass ich da was sinnvolles
mache (das war jetzt gerade im übertragenen Sinne die heranwinkende
Geste von Bruce Lee an die Kritiker: "You want some? Come here and get
some!")
Es kamen einige berechtigte Kritiken (hatte ich zwar schon mehrfach
geschrieben, aber trotzdem noch mal ganz herzlichen Dank dafür) und bei
der Mehrzahl der anderen Beiträge handelte es sich um Polemik und viel
heiße Luft. Davor fürchte ich mich nicht!
Gruß
Jürgen
Hallo Alex.
Alex schrieb:> der Tip mit den Kommentaren und dem "// /*" ist zwar in der Praxis sehr> praktisch, ich denke aber, dass er an dieser Stelle nicht hin passt,> weil da gerade etwas über logische Verknüpfungen erklärt werden soll und> nicht über Kommentare!
In vielen älteren Büchern und Artikeln über C wird immer der
Komentarstil /* und */ benutzt. Da ich in den folgenden Beispielen aber
die Kommentierung mit '//' benutze, musste ich auf jeden Fall eine
Erklärung dafür abgeben. Den Tipp mit '//*' und '*/' hatte ich rein
gebracht, weil er einem ganz schön viel Arbeit/Navigation ersparen kann.
Da ich ansonsten nicht auf C eingehe (zwar Beispiele, aber keine
Belehrungen), war dies der einzige Ort, wo es halbwegs passt (und
verschweigen wollte ich den Trick auch nicht).
Danke für den Hinweis (obwohl ich ihn sehr wahrscheinlich nicht
einarbeiten werde).
Gruß
Jürgen
(Mist, es geht schon wieder auf Mitternacht zu).
Bernd S. schrieb:> Am Ende von 1.4.1 ist der Absatz vom Thema unpassend, der gehört weiter> nach oben
Hallo Bernd! Danke für den Hinweis, ich habe den Absatz jetzt als
zweiten eingefügt. Da passt er wirklich besser (aber richtig schlecht
war der alte Platz auch nicht, mecker, mecker, grr).
Tschüs und Danke
Jürgen
MoinMoin,
jdhenning schrieb:> Wenn ich es in diesem Forum schaffe (bisher hat man mir ja nur> ein paar Pillepallefehler nachweisen können), mein Buchvorhaben zu> verteidigen, dann hätte ich es überall sonst auf jeden Fall geschafft.> So habe ich aber ein viel besseres Gefühl, dass ich da was sinnvolles> mache...>
hmm, möchtest (du) wirklich jeden Satz deines Buch, in dem sich mehr
persönliche Befindlichkeiten und Ansichten zu einer fachlichen Tatsache
befinden, zitiert bekommen? Reicht es nicht, wenn gesagt wird, dass das
vorliegende Manuskript, aus mehrfach geäusserten Gründen, nicht zu einem
Fachbuch taugt? Wie wirst (du) gegenüber dem Verlags-Lektor dazu
argumentieren? Schade, dass (du) das hier nicht veröffentlichen wirst,
wäre sicherlich lesenswert!
jdhenning schrieb:> und bei> der Mehrzahl der anderen Beiträge handelte es sich um Polemik und viel> heiße Luft.>
bestimmt nicht. Ich würde nachdenklich werden, wenn mir Leute soetwas
schreiben würden!
jdhenning schrieb:> Davor fürchte ich mich nicht!>
...das nehme ich dir sogar ungeprüft ab, aber das liegt wohl an dem Ton,
den (du) hier anschlägst...
Wo ist eigentlich die überarbeitete Version des Manuskriptes einsehbar,
oder hattest (du), wg. den hiesigen munteren Wortgefechten, gar keine
Zeit für eine Überarbeitung?
Grüße Uwe
jdhenning schrieb:> In vielen älteren Büchern und Artikeln über C wird immer der> Komentarstil /* und */ benutzt.>
aus gutem Grund, wie dir bestimmt bekannt ist, oder? Wenn du schon //
als C-Kommentarzeichen verwendest und dieser Methode einen "Tipp"
widmest, solltest du auch darauf eingehen! Ahnungslosigkeit in dieser
Hinsicht, könnte ähnliche Effekte bei Anfängern hervorrufen, wie bei dir
mit dem fehlenden # vor einem include... Ich spreche da, nebenbei, aus
eigener Erfahrung!
Meint Uwe
Hallo Sanchez (spanische Wurzeln?).
Sanchez schrieb im Beitrag #3957710:
> Dazu muss ich> sagen, dass der Teil am Anfang, der erklärt, was eine CPU ist und was> sie macht, mir nicht wirklich hilft. Mit Flags und Pointer etc. kann ich> zu wenig anfangen. Wahrscheinlich bräuchte ich ein "Voranfängerniveau".
Deshalb hatte ich auch ziemlich am Anfang des Manuskripts geschrieben,
dass es ein rasanter Vorbeiflug an einigen Themen wird und dass man
Verständnisprobleme ausräumen sollte, bevor man weiter liest. Und dein
Eindruck, dass es hier einen Haufen Ignoranten gibt, die meinen, so
etwas müsse man schon wissen, bevor man sich überhaupt mit der Thematik
beschäftigt, ist absolut korrekt (sonst könnten sie sich ja nicht
einbilden, etwas besseres zu sein). Was diese Ignoranten auslassen ist,
dass man als Neueinsteiger überhaupt nicht wissen kann, an welchen Ecken
es an Wissen fehlt. Am Anfang des Manuskripts findet sich meine
Mail-Adresse; falls du meinst, ich könnte dir vielleicht weiter helfen,
lass es mich wissen.
Gruß
Jürgen
Cyblord ---- schrieb:> Die Kritik an Jürgen und seinem Buch ist absolut gerechtfertigt. Sein> Fachwissen ist Mau, seine Schreibe ist grausam, seine arrogante Art> nimmt bereits krankhafte Züge an.
Komm' doch mal aus deiner Polemikblase heraus und bringe Fakten! Vor
Schaumschlägern, die mit Wattebäuschchen werfen, knicke ich nicht ein!
Also gib dir gefälligst mehr Mühe, sonst wird das hier für alle Leser
nur langweilig!
Lothar Miller schrieb:> Leute, lasst die vielen 'du' aus den Posts raus!> Es geht hier um die Sache, nicht um persönliche Befindlichkeiten.
Ich persönlich finde es noch nicht so schlimm, dass ein Eingreifen durch
dich (war das jetzt 'ne Du-Form?) nötig wäre. Ich gebe zu, dass ich hier
(teilweise vorsätzlich) auch provoziere; wenn Leute darauf hin
(sozusagen mit Schaum vorm Mund) polemisch reagieren, dann machen sie
sich doch nur selbst nieder. Der nächste Schritt ist die Lächerlichkeit.
Warum sollte man sie daran hindern?
Sanchez schrieb im Beitrag #3958147:
> Oder ob man es so formuliert:"Ich bin nicht sicher, dass Du das richtig> darstellst, damit würde der Wert Deiner Arbeit leiden und Du solltest> Dich nicht aus Begeisterung selber darüber hinwegtäuschen.">
...ok, könnte ein Zitat von mir sein, und jetzt? ...wird er darauf
eingehen, ich bin gespannt!
Grüße Uwe
Uwe Berger schrieb:> Wie wirst (du) gegenüber dem Verlags-Lektor dazu> argumentieren? Schade, dass (du) das hier nicht veröffentlichen wirst,> wäre sicherlich lesenswert!
Hätte ich überhaupt kein Problem mit, aber ich bezweifel mal, dass der
Lektor eines Verlages mich als alterstarrsinnig, unfähig, uneinsichtig
und was noch alles bezeichen wird.
Von daher die Zusage: Das stell ich hier ein!
Uwe Berger schrieb:> Wenn du schon // als C-Kommentarzeichen verwendest und dieser Methode einen
"Tipp" widmest, solltest du auch darauf eingehen!
Die Methode '//' für Komentare zu verwenden habe ich nicht als Tipp
verwendet. Wenn du noch mal in mein Manuskript gehst, verstehst du ja
vielleicht doch noch, was ich als Tipp gegeben habe. Große Hoffnung habe
ich nicht.
Sanchez schrieb im Beitrag #3958157:
> Ich würde z.B. gerne wissen, was "SDA" oder "SCL" wirklich ist,> und nicht nur, dass da der Anschluss rein muss. Mal sehen.
Seite 90.
Viva la raza!
Jürgen
jdhenning schrieb:> Die Methode '//' für Komentare zu verwenden habe ich nicht als Tipp> verwendet. Wenn du noch mal in mein Manuskript gehst, verstehst du ja> vielleicht doch noch, was ich als Tipp gegeben habe.>
...upps, du hast den Tenor meiner Anmerkung nicht verstanden?! Du hast
hier geschrieben: "In vielen älteren Büchern und Artikeln über C wird
immer der
Komentarstil /* und */ benutzt.". Scheinst aber nicht zu wissen warum,
oder?
In deinem Manuskript mischst du beide Kommentarmöglichkeiten fröhlich
miteinander, weist aber nicht auf die möglichen Fallstricke hin, über
die ein Anfänger dabei stolpern könnte. Ich würde ein solches delikates
Thema entweder, mit allen Feinheiten, vernünftig erklären oder einfach
ganz rauslassen. Entweder ein fundiertes, auf Tatsachen basiertes
Fachbuch, oder halt nicht! Genau das heisst es wissenschaftlich arbeiten
oder halt nur eine Ansammlung von Anekdoten zu verfassen.
Du darfst mich jetzt gern "Korinthenkacker" nennen...
> Große Hoffnung habe ich nicht.
...:-), sorry, ausgerechnet diesen Abschnitt habe ich mit einem
Schmunzeln lesen müssen, weil ich mir bildlich vorstellen konnte, wie
ein C-Anfänger bei diesen Thema jämmerlich scheitern kann!
Grüße Uwe
jdhenning schrieb:> Die Methode '//' für Komentare zu verwenden habe ich nicht als Tipp> verwendet. Wenn du noch mal in mein Manuskript gehst, verstehst du ja> vielleicht doch noch, was ich als Tipp gegeben habe.
Leider ist deine Darstellung des "Tipps" falsch, da fehlt noch etwas.
Probier's doch einfach mal aus.
Der "Tipp" funktioniert auch nicht, wenn im damit umschlossenen Bereich
schon Kommentare mit "/*" und "*/" vorhanden sind. Zum Deaktivieren von
Code-Bereichen nimmt man besser die Präprozessor-Methode, denn die hat
kein Problem mit Verschachtelung.
Lothar Miller schrieb:> Leute, lasst die vielen 'du' aus den Posts raus!> Es geht hier um die Sache, nicht um persönliche Befindlichkeiten.
Völlig falsch. Es geht sowohl in dem Manuskript (ist ja noch weit weg
von einem Buch) als auch in diesem Thread NUR um persönliche
Befindlichkeiten. Die Sachebene war nach den ersten drei Beiträgen (von
den 200 Seiten die 100 Seiten mit persönlichen Befindlichkeits-Anekdoten
rausschmeißen, die anderen 100 Seiten gründlich überarbeiten) erledigt.
Der Thread lebt nur noch von der extrem lustig zu lesenden
Beratungsresistenz eines an Selbstüberschätzung und deutlicher
Ahnungslosigkeit leidenden Autors. Letztes Beispiel die Diskussion zum
Thema Kommentarzeichen in C.
Oliver
Hi
Jürgen, so langsam muss es mal bei mir raus. Ich bin 64 und "bitte
lieber Gott, lass mich im Alter nicht so starrköpfig und begriffsstutzig
werden."
Warum versuchst du die Kritik "gutzudiskutieren". Nicht gerade ein
tolles Wort, aber deutlicher möchte ich nicht werden. Klar, Aussagen:
"Bücher brauchts in der heutigen Zeit nicht. Datenblatt und Internet und
gut" teile ich auch nicht und wenn du dir mal die Mühe gemacht hättest,
meinen Beitrag im AVR-Praxis-Forum "keine Angst vor Assembler" unter der
Rubrik FAQ durchzulesen, würdest du vielleicht verstehen, wie ein
Anfänger oder Einsteiger zu betrachten ist. Dein Thema ist schon etwas
höher angesiedelt, also nicht mehr da, wo die Grundlage "Bit","Byte"
usw. und Stromkreis noch gar nicht bewusst ist. Aber, und nun bin ich
der Meinung von vielen, bei deiner Zielgruppe ist die Ebene "Comic",
wenn ich es mal so salopp ausdrücken darf schon verlassen und der Leser
möchte schon qualifizierte Aussagen. Es gibt genug Stellen, die ich
jetzt nicht zitieren möchte, wo du selbst durchblicken läßt, das du das
Thema noch nicht ganz verstanden hast. Geh mal davon aus, das, wenn du
dieses Thema in dieser Form in einer Schulklasse, sagen wir Gymnasium 9.
oder 10. Klasse, vortragen würdest, die volle Begeisterung ausgelöst
wird. Nämlich dann, wenn der Gong das Ende der Stunde verkündet. Vergiss
deine berufliche Vergangenheit. Die gehört bestenfalls in ein Vorwort
oder auf den Buchrücken, aber nicht in den Text. Nicht unbedingt falsch
dagegen ist, wenn in einem Beispiel auf eigene Erfahrung hingewiesen
wird. Aber nicht ständig und schon gar nicht mit den gesamten
Lebenslauf. Ich weiß, bevor du mich darauf aufmerksam machst, ich
übertreibe da etwas, aber es gibt Stellen, da bist du von einer
Biografie nicht weit entfernt... Und genau das wird kritisiert. Themen,
die du nicht beherrscht, gehören nicht in das Buch. Solche Passagen
dequalifizieren deine Arbeit. Mir ist es noch nicht ganz klar, wie dein
Lektor damit zurechtkommt. Aber es ist nicht in meiner Verantwortung,
darüber zu urteilen. Ich hab versucht, dir schonend zu sagen, das man
sich in das eigene Werk verlieben kann und dann jede Kritik als Angriff
persönlich nimmt. Lerne endlich, dein Werk mit den Augen deiner
Zielgruppe zu lesen!
Gruß oldmax
Oliver S. schrieb:> Der Thread lebt nur noch von der extrem lustig zu lesenden> Beratungsresistenz eines an Selbstüberschätzung und deutlicher> Ahnungslosigkeit leidenden Autors. Letztes Beispiel die Diskussion zum> Thema Kommentarzeichen in C.
Genau so ist es. Wie schon vor ein paar Tagen weiter oben bemerkt wurde:
"Geisterfahrer. Einer? Hunderte!"
Einer der besten Chips-und-Cola-Threads seit langem. Sehr unterhaltsam.
Mehr aber auch nicht.
mfg.
jdhenning schrieb:> Komm' doch mal aus deiner Polemikblase heraus und bringe Fakten! Vor> Schaumschlägern, die mit Wattebäuschchen werfen, knicke ich nicht ein!> Also gib dir gefälligst mehr Mühe, sonst wird das hier für alle Leser> nur langweilig!
@JHenning
Also hör mal, es gab jetzt ja wohl genug Fakten.
Da ich keine Lust habe das Alles nochmal durch zu lesen um Zitate heraus
zu fischen, bekommst du etwas aktuelles:
Das "Problem" mit deinem fragwürdigen Tip "/*, */, //, //*".
Es ist ja schön und gut, dass du damit zurecht kommst.
Doch wie Konrad S. schon schrieb, ist das nicht ganz Problemlos.
Und so wie Uwe Berger vermutet, hast du wohl auch wirklich sowohl die
Problematik als auch das "Warum" nicht verstanden. Und das ist nur EIN
Beispiel.
Unabhängig von dem Allem erwarte ich von einem Fachbuch, dass solche
Dinge darin fachlich richtig gezeigt werden. Und fachlich richtig ist
nun mal die Verwendung des Präprozessors bzw. seine Möglichkeiten. Denn
genau dafür ist er da!
Egal jetzt ob du das schon seit 30 oder 40 Jahren so machst, Pfusch ist
es trotzdem.
Ich habe vor einigen Tagen sowohl das Manuskript überflogen als auch den
Thread mal durchgelesen. Ich würde jetzt nicht unbedingt sagen, dass das
Manuskript fehlerhaft ist. Doch hilfreich ist es weder für den
Einsteiger noch für den Fortgeschrittenen.
Dazu ist es einfach zu chaotisch, unprofessionell und selbstverliebt.
Eine Zusammenfassung von irgendwelchen Notizen und Kopien, gespickt mit
Geschichten und themenfremden Aufsätzen.
Hör doch endlich auf diesen Mist zu verteidigen.
Schreib das Buch wie du möchtest und such dir einen Verleger.
Sobald das Buch im Handel erscheint darfst du dich als Held fühlen.
Vorher aber nicht.
...
Fakten schrieb:> Schreib das Buch wie du möchtest und such dir einen Verleger.> Sobald das Buch im Handel erscheint darfst du dich als Held fühlen.> Vorher aber nicht.
Selbstverlag und Internetvertrieb/BoD reichen zum Held werden allerdings
nicht aus ...
Oliver
Fakten schrieb:> Sobald das Buch im Handel erscheint darfst du dich als Held fühlen.> Vorher aber nicht.
Als wenn keine schlechten Bücher verlegt werden würden. DAS ist kein
Maßstab.
Trotzdem glaube ich auch nicht dass er einen "großen" Verleger dafür
findet.
Aber vielleicht könnte er es als krude Satire auf AVR-Bücher verkaufen.
So ähnlich wie der "Kryptochef" damals. Die Tatsache dass der Autor es
hier aber Ernst meint, macht das Ganze noch lustiger.
Cyblord ---- schrieb:> Fakten schrieb:>>> Sobald das Buch im Handel erscheint darfst du dich als Held fühlen.>> Vorher aber nicht.>> Als wenn keine schlechten Bücher verlegt werden würden. DAS ist kein> Maßstab.> Trotzdem glaube ich auch nicht dass er einen "großen" Verleger dafür> findet.
Ach, sag das nicht. Ich fühle mich bei diesem Thread unangenehm an ein
Buch aus meinem beruflichen Bereich erinnert. Immerhin 4 Sterne bei
Amazon ;o)
http://www.amazon.de/HPLC-Schrauber-Werner-Röpke/dp/3527318178/ref=sr_1_1?ie=UTF8&qid=1420809249
Hm, wie kommt man an das Buch denn überhaupt heran? Ich werde immer nach
einem Usernamen und Passwort gefragt.
Ich wollte auch mal ein Buch von einem, der
- nicht weiß, wie man Links postet,
- mit #define FOO = 1 keine Probleme hat,
- der seine eigenen Beispielprogramme selbst offenbar nicht
compiliert,
- der ein Buch über einen µC-Dinosaurier schreiben will,
- der meint, die Unterschiede vom ATmega8 zum Atmega88 seien minimal,
- der sämtliche Aufzählungen zu Verbesserungen eines ATmega88
geflissentlich ignoriert,
- der keine Ahnung hat, wozu ein Bootloader eigentlich gut ist,
- der sich wundern wird, warum kein Verlag sein Buch drucken will,
zumindest mal querlesen.
Wer kann mir den hilfreichen Tipp geben, um mir das "Buch" anzuschauen?
Frank M. schrieb:> Hm, wie kommt man an das Buch denn überhaupt heran? Ich werde immer nach> einem Usernamen und Passwort gefragt.
Das hat Jürgen doch beschrieben:
Jürgen Henning schrieb:> 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.
Habe es gerade mal überflogen....
Auf Seite 123 hat es mir dann die Schuhe ausgezogen:
> size_t strlen(const char * src, size_t len)>> Diese Funktion sucht in 'src' nach einem Null-Byte, untersucht aber> nicht mehr als 'len' Zeichen."
Das ist jetzt nicht wahr, oder? Seit wann kennt strlen() denn zwei
Argumente?
Und weiter lese ich:
> Wenn die Funktion 'len' zurück gibt, dann wurde kein Null-Byte> gefunden.
Welche Phantasien hat jdhenning sonst?!? Die Funktion strlen() kann
tatsächlich 'len' (was ist das? Ein multidimensionaler String oder
irgend etwas aus einer fremden Galaxie?) zurückgeben?!? Ich dachte, ein
size_t wäre numerisch...
Und schnell noch den letzten Satz lesen, bevor ich mich irgendwo - nach
Luft schnappend - festhalten muss:
> Wenn man halbwegs sauber programmiert, dann braucht> man so eine Funkzion nicht!
Unglaublich. Wer noch nichtmals den Sinn und Zweck solch einer
elementaren Funktion wie strlen() kennt, darf wirklich kein Buch über
Mikrocontroller schreiben.
Auch lustig:
> char * strncpy(char * dest, const char * src, size_t len)>> [...] Diese Funktion ist Schrott, [...] Lieber selber etwas> Vernünftiges programmieren.
Der Autor hat tatsächlich keine Ahnung, wann und warum eine C-Funktion,
die es seit Anfang an (also ~1970) gibt, durchaus in der Anwendung
sinnvoll ist.
Fazit:
Das Buch ist noch nichtmals als Ersatz für schlechte Witze geeignet.
Schade um das Papier, wenn es tatsächlich gedruckt werden sollte. Aber
kein Verlag kann so idiotisch sein.
Im Kapitel Statusregister steht:
>(also 5 + 6 = 11 => half carry gesetzt).
Gerade getestet im Studio-Simulator:
ldi ZL, 5
ldi ZH, 6
add ZL, ZH
Das H-Flag war nach dem <add> aber nicht gesetzt. Ist meine MCU kaputt?
Carrywurst schrieb:> Ist meine MCU kaputt?
Auf jeden Fall. Dein Simulator übrigens auch. Die Ingenieure von Atmel
sind Deppen und im Datenblatt steht Unsinn. Und die Amerikaner sind auch
nicht auf dem Mond gelandet.
mfg.
Jungs, lasst den Autor seine Fehler selber suchen. Der will mit dem Buch
Geld verdienen, da soll er seine Hausaufgaben gefälligst selber machen.
Falls das solch mal frei verfügbar im Internet in einem Tutorial oder
Wiki veröffentlicht wird, kann ja ja weiterhelfen.
Oliver
mikcrocontroller.net ist nicht unbedingt das freundlichste Forum auf
diesem Planeten. Auch wenn es manchmal sehr nützlich und hilfreich ist -
aber hier werden gern mal Leute mit guter Absicht ans Kreuz geschlagen
und so richtig schlecht geredet, egal ob sie es verdient haben oder
nicht.
Ich persönlich finde das Ansinnen von Jürgen Henning sehr verständlich -
auch wenn Atmels inzwischen nicht mehr an der Speerspitze der neuesten
Technologie stehen, werden sie im Hobbybereich aufgrund von Arduino &
Co. noch sehr lange present sein. Und diese Atmels sind nach wie vor
wunderbar für Bastler ein Einstieg in die Wunderwelt der digitalen
Elektronik.
Das Buch/bzw. die Leseprobe hab ich mir heruntergeladen und angefangen
probezulesen. Ich kenn die Atmels ja seit ca. 3 Jahren ganz gut, hab
mehrere eigene Projekte damit komplettiert und kann mich inzwischen auch
ganz gut durch Datenblätter hangeln bzw stell dann hier im Forum ab und
zu dumme Fragen ;-)
Für mich persönlich war die Initialzündung damals das Buch vom Franzis
Verlag: Dr. Günter Spanner: "AVR Microcontroller in C programmieren"
Ich denk jeder Anfänger baucht so eine Initialzündung - also genug
Informationen um eigene erste Schritte zu gehen. Wenn ich das hier
vorgestellte Manuskript mit dem Buch von Spanner vergleiche bin ich
derzeit eher skeptisch - ich denk das Franzis Buch war für mich, der
damals vom Stand Null einsteigen wollte, die bessere Wahl. Aber das ist
ein vorläufiges Urteil, ich werd mal noch etwas weiter lesen...
Aus gegebenem Anlass wieder mal ein Hinweis auf die Nutzungsbedingungen:
die Beteiligung an einer Diskussion unter verschiedenen Namen ist nicht
erlaubt, und führt zur Löschung der Beiträge des Autors.
Nun, ob dass nun bewirken muß, daß man den Thread nur noch als
eingeloggter Besucher lesen kann, halte ich für gelinde gesagt
ungeschickt!
Ich persönlich finde soetwas unschön.
Viele Grüße
Uwe
Uwe Nase schrieb:> Nun, ob dass nun bewirken muß, daß man den Thread nur noch als> eingeloggter Besucher lesen kann, halte ich für gelinde gesagt> ungeschickt!
Lesen? Lesen kannst Du ihn auch als Gast.
> Ich persönlich finde soetwas unschön.
Es geht um das Posten unter verschiedenen Namen.
Konrad S. schrieb:> Der "Tipp" funktioniert auch nicht, wenn im damit umschlossenen Bereich> schon Kommentare mit "/*" und "*/" vorhanden sind. Zum Deaktivieren von> Code-Bereichen nimmt man besser die Präprozessor-Methode, denn die hat> kein Problem mit Verschachtelung.
Wer macht denn verschachtelte Kommentare?
Ok, ich habe auch schon oft "//" Kommentare in "/*" - "*/" - Kommentaren
eingeschlossen, aber verschachtelte Kommentare zeugen doch wohl eher von
unsauberer Programmierung (meine Meinung, die nicht richtig sein muss).
Moin Martin!
Martin Vogel schrieb:> Ich hab versucht, dir schonend zu sagen, das man> sich in das eigene Werk verlieben kann und dann jede Kritik als Angriff> persönlich nimmt. Lerne endlich, dein Werk mit den Augen deiner> Zielgruppe zu lesen!
Deine Worte sind auch schon früher bei mir angekommen (ist ja nicht so,
dass ich die Beiträge hier nicht lesen würde). Der Unterschied ist nur,
dass das Manuskript letztlich ein Abfallprodukt ist und nicht mein
geliebtes Baby. Und persönlich nehmen kann die pöbeligen Beiträge hier
letztlich auch nicht, denn die Schreiber kennen weder mich, noch kenne
ich sie. Letztlich ist also überhaupt keine Grundlage vorhanden, um
irgendetwas persönlich nehmen zu können.
Dass mich hier einige Schreiber reizen wollen ist mir absolut klar. Es
gibt da allerdings einen gravierenden Unterschied: Mir ist klar, dass es
in Deutschland die Meinungsfreiheit gibt und etliche Kritiker hier
scheinen der Meinung zu sein, sie dürften anderen vorschreiben, was sie
zu sagen, zu denken oder zu schreiben hätten. Und es ist nicht
Altersstarrsinn, wenn ich solchen 'Vorgaben' nicht folge, sondern
demokratisches Grundverständnis (musste ich einfach mal gesagt haben).
Wenn Leute (damit meine ich jetzt nicht dich) Ironie oder Sarkasmus
nicht wahrnehmen/verstehen können, dann ist das ihr Problem. Folglich
ist auch völlig offen, wie viele meiner Posts meine Meinung tatsächliche
wieder geben.
Gruß und Danke für deine Zeit
Jürgen
Thomas Eckmann schrieb:> Einer der besten Chips-und-Cola-Threads seit langem. Sehr unterhaltsam.
Das ist doch endlich mal ein Lob von dir. So schlecht kann mein
Geschreibsel ja denn doch nicht sein, wenn man so lang und breit drüber
diskutiert, ohne wirklich in die Fakten zu gehen.
Fakten schrieb:> Ich habe vor einigen Tagen sowohl das Manuskript überflogen als auch den> Thread mal durchgelesen. Ich würde jetzt nicht unbedingt sagen, dass das> Manuskript fehlerhaft ist. Doch hilfreich ist es weder für den> Einsteiger noch für den Fortgeschrittenen.
Ich habe mehrfach geschrieben, dass Fortgeschrittene nicht die
Zielgruppe sind; Einsteiger hingegen schon, allerdings diejenigen, denen
klar ist, dass sie sich eine harte Scheibe Brot ausgesucht haben.
> Schreib das Buch wie du möchtest und such dir einen Verleger.> Sobald das Buch im Handel erscheint darfst du dich als Held fühlen.> Vorher aber nicht.
Ich glaube nicht, dass ich mich als Held fühlen werde, wenn das Buch
tatsächlich einen Verleger findet. Ich schließe auch nicht aus, dass das
ganze Manuskript noch einmal komlett überarbeitet wird (ich halte es
eher für wahrscheinlich).
Gruß
Jürgen
Moin Frank.
Frank M. schrieb:> Ich wollte auch mal ein Buch von einem, der>> - nicht weiß, wie man Links postet,
Da all die anderen hier kein Problem hatten, das Manuskript herunter zu
laden würde ich mal vermuten, dass das Problem bei dir liegt.
Gruß
Jürgen
Hallo Frank!
Frank M. schrieb:>> size_t strlen(const char * src, size_t len)>>>> Diese Funktion sucht in 'src' nach einem Null-Byte, untersucht aber>> nicht mehr als 'len' Zeichen.">> Das ist jetzt nicht wahr, oder? Seit wann kennt strlen() denn zwei> Argumente?
!!!! JUBEL !!!! Du hast einen Tippfehler gefunden!
Wenn du im Manuskript auf Seite 122 gehst, findest du die normale
Definition:
size_t strlen(const char * src)
Auf Seite 123 stand in der Tat :
size_t strlen(const char * src, size_t len)
Korrekt wäre gewesen:
size_t strnlen(const char * src, size_t len)
Vielen Dank, dass du das fehlende 'n' aufgespürt hast.
Wie du allerdings dazu kommst, aus einem simplen Tippfehler auf die
anderen Behauptungen zu schließen, das solltest du hier doch noch einmal
deutlich machen!
Hallo Frank, wenn du schon zitierst, dann solttest du das auch
vollständig machen.
Frank M. schrieb:>> char * strncpy(char * dest, const char * src, size_t len)>>>> [...] Diese Funktion ist Schrott, [...] Lieber selber etwas>> Vernünftiges programmieren.>> Der Autor hat tatsächlich keine Ahnung, wann und warum eine C-Funktion,> die es seit Anfang an (also ~1970) gibt, durchaus in der Anwendung> sinnvoll ist.
"Diese Funktion ist Schrott, denn sie gibt einem nicht zurück, wie viele
Zeichen übertragen wurden bzw. ob das Kopieren aufgrund eines kopierten
Null-Bytes beendet wurde." Es handelt sich also um eine Funktion, die
VIELLEICHT das gemacht hat, was man von ihr erwartete. Prüfen kann man
es nicht. Und das nenne ich Schrott, auch wenn es aus 1970 stammt!
Ich würde mal sagen, dass du keine Ahnung hast, wenn du unter diesen
Umständen behauptest, diese Funktion sei besonders sinnvoll. Schon mit
nur grundlegenden C-Kenntnissen kann man in weniger als 5 Minuten etwas
besseres programmieren und austesten.
Micha schrieb:> Ich denk jeder Anfänger baucht so eine Initialzündung - also genug> Informationen um eigene erste Schritte zu gehen. Wenn ich das hier> vorgestellte Manuskript mit dem Buch von Spanner vergleiche bin ich> derzeit eher skeptisch - ich denk das Franzis Buch war für mich, der> damals vom Stand Null einsteigen wollte, die bessere Wahl. Aber das ist> ein vorläufiges Urteil, ich werd mal noch etwas weiter lesen...
Ich bin auf jeden Fall an deiner Meinung interessiert. Vielen Dank für
deinen Einsatz und deine Zeit. Einige meinen ja, dass ich sie ausnutze,
um Geld zu verdienen. Einerseits glaube ich nicht, dass mit so einem
Buch viel Geld zu verdienen ist und andererseits habe ich es in meinem
Anfangspost absolut klar gesagt, dass ich mit dem Buch über einen Verlag
gehen will (sozusagen eine eingebaute Qualitätssicherung). Es wird noch
nicht einmal jemand gezwungen, überhaupt seine Meinung zu äußern. Also
verstehe ich die Aufregung nicht.
Gruß
Jürgen
spess53 schrieb:> Nein. Such dir richtige Bücher.>> MfG Spess
Dann sage ihm doch wenigstens, welche das sein sollen. Das Datenblatt
ist es schon mal nicht.
In diesem mittlerweile ganz schön langen Thread wurden wenige
Alternativen aufgeführt und eine davon (obwohl nicht selber gelesen)
halte ich für (wahrscheinlich) geeignet.
Los komm! Butter bei die Fische! Rumseiern kann jeder!
Jürgen Henning schrieb:> Konrad S. schrieb:>> Der "Tipp" funktioniert auch nicht, wenn im damit umschlossenen Bereich>> schon Kommentare mit "/*" und "*/" vorhanden sind. Zum Deaktivieren von>> Code-Bereichen nimmt man besser die Präprozessor-Methode, denn die hat>> kein Problem mit Verschachtelung.> Wer macht denn verschachtelte Kommentare?
Du, wenn du den "Tipp" auf einen Bereich anwendest, der schon einen
Kommentar mit "/*" und "*/" enthält. Verstehst du es jetzt?
Jürgen Henning schrieb:> !!!! JUBEL !!!! Du hast einen Tippfehler gefunden!>> Wenn du im Manuskript auf Seite 122 gehst, findest du die normale> Definition:> size_t strlen(const char * src)>> Auf Seite 123 stand in der Tat :> size_t strlen(const char * src, size_t len)> Korrekt wäre gewesen:> size_t strnlen(const char * src, size_t len)
Auch dann ist Deine Beschreibung der Funktion nicht gerade sehr
verständlich.
Da lobe ich mir doch ein X-beliebiges Unix-Manual:
"The strnlen() function returns the number of bytes in the string
pointed to by s, excluding the terminating null bye ('\0'), but at most
maxlen. In doing this, strnlen() looks only at the first maxlen bytes at
s and never beyond s+maxlen."
Das ist kurz und knackig. Und eindeutig. Da steht auch nichts von einem
Return-Wert 'len'. In Hochkommata schon gar nicht, denn so gibt man
einzelne Zeichen an, z.B. 'x'.
Überhaupt sind Deine Erklärungen zu der avr-libc nicht formal genug.
Damit meine ich, dass Du dem Leser sehr viel Raum zur Interpretation
gibst. Ich verstehe auch nicht, warum Du zum Beispiel mit keinem Wort
auf die Rückgabewerte von strcmp() bzw. strncmp() eingehst. Diese sind
nämlich pfiffig gewählt, zum Beispiel, wenn man sortieren will. Du
behandelst sie aber in der Beschreibung wie void-Funktionen.
Jürgen Henning schrieb:> "Diese Funktion ist Schrott, denn sie gibt einem nicht zurück, wie viele> Zeichen übertragen wurden bzw. ob das Kopieren aufgrund eines kopierten> Null-Bytes beendet wurde." Es handelt sich also um eine Funktion, die> VIELLEICHT das gemacht hat, was man von ihr erwartete. Prüfen kann man> es nicht. Und das nenne ich Schrott, auch wenn es aus 1970 stammt!
Diese Funktion ist genial. Wenn Du zum Beispiel DB-Daten aus Feldern
kopieren willst und dabei kürzen musst, weil die Ziel-Länge kleiner ist,
macht die Funktion strncpy() genau das. Dasselbe gilt für das Kopieren
von sehr langen Strings in kürzere String-Arrays. strncpy() schützt
dabei effektiv gegen Buffer-Overflows, was man von strcpy() eben NICHT
behaupten kann.
Schon so mancher Hacker hat Webseiten oder andere netzwerkbasierte
Programme zum Crash gebracht oder gar als Exploit genutzt, indem er
einfach in Eingabefelder bzw. Kommando-Strings ultralangen Unsinn
eingegeben hat bzw. automatisch generiert hat. Genau davor schützt
strncpy().
Ausserdem hat Deine persönliche Meinung nichts - aber auch gar nichts -
in einem Reference-Manual-artigen Kapitel zu suchen.
> Ich würde mal sagen, dass du keine Ahnung hast, wenn du unter diesen> Umständen behauptest, diese Funktion sei besonders sinnvoll. Schon mit> nur grundlegenden C-Kenntnissen kann man in weniger als 5 Minuten etwas> besseres programmieren und austesten.
Siehe oben. Diese Funktion hat durchaus seinen Sinn und Zweck.
Und als letztes zu meiner "Ahnung". Klicke einfach mal auf meine
Benutzerseite rechts neben dem Nick. Da findest Du genügend Stoff für
Google-Suchbegriffe, um Dich ein paar Tage mit mir zu beschäftigen.
Hauptveruflich bin ich Unix/Linux-C-Systemprogrammierer und kenne C und
dessen Stärken als auch Schwächen bis ins kleinste Detail. Das ist mein
täglich Brot. Außerdem habe ich durch meine eigenen publizierten Bücher
einige Kontakte zu Fachbuch- und Fachzeitschriftverlagen. Im Moment bin
ich überhaupt nicht geneigt, Dein "Buch" irgendeinem dieser Verlage zu
empfehlen - ganz im Gegenteil.
Man sollte sich über Personen, mit denen man kommuniziert, immer erst
informieren, bevor man das Maul zu weit aufreisst. Das kommt besser.
> Ich würde mal sagen, dass du keine Ahnung hast, wenn du unter diesen> Umständen behauptest, diese Funktion sei besonders sinnvoll. Schon mit> nur grundlegenden C-Kenntnissen kann man in weniger als 5 Minuten etwas> besseres programmieren und austesten.
Wie vermessen kann dieser Mensch bitte noch sein? Ich bin jedes mal
schockiert über so viel Arroganz gepaart mit so viel Unwissen.
Cyblord ---- schrieb:> Ich bin jedes mal> schockiert über so viel Arroganz gepaart mit so viel Unwissen.
Wieso denn eigentlich? Kommt doch wesentlich öfter vor als Arroganz
gepaart mit Wissen.
Konrad S. schrieb:> Cyblord ---- schrieb:>> Ich bin jedes mal>> schockiert über so viel Arroganz gepaart mit so viel Unwissen.>> Wieso denn eigentlich? Kommt doch wesentlich öfter vor als Arroganz> gepaart mit Wissen.
Das stimmt, aber diesem Ausmaß finde ich es doch sehr befremdlich. Ich
halte es da lieber mit Sokrates:
"Ich weiß dass ich nicht weiß".
Moin & Tschüs an alle, die hier mitgewirkt haben.
Ich hatte gestern ein längeres Telefonat mit Herrn Bombien (Senior
Editor O'Reilly); er hatte weite Teile der Diskussion hier mitgelesen,
was ihn aber allem Anschein nach nicht davon abhält, dieses Buchprojekt
weiter zu verfolgen (wenn ich starrsinnig bin dann muss er ja... ähh,
das gehört jetzt hier nicht her!).
Es ist noch nicht entschieden, ob die fertige Version hier noch einmal
zur Diskussion frei gegeben wird (aus Marketinggründen zumindest nicht
für eine allgemeine Diskussion).
Ich möchte mich noch mal ganz herzlich bei ALLEN Teilnehmern bedanken
(auch bei denen, die weitgehend nur rumgemault haben, ich wäre ein
starrsinniger, seniler Tattergreis und so ein Schreibstil stände mir
nicht zu), denn es hat jeden etwas seiner Lebenszeit gekostet seine(n)
Post(s) zu schreiben. Noch herzlicher ist natürlich mein Dank an
diejenigen, die mir den Starrsinn ausreden wollten (war leider zwecklos,
denn ich bin ja auch senil).
Natürlich möchte ich mich auch bei den Moderatoren dafür bedanken, dass
sie die Diskussion in halbwegs zivilisierten Bahnen gehalten haben (ein
paar Löschaktionen deuten ja darauf, dass dies nötig war).
Worin ich auf jeden Fall bestärkt wurde ist die Überzeugung, dass es
kein Überangebot an guten deutschsprachigen Büchern zu der Thematik
gibt.
Jürgen D. Henning
P.S. Falls jemand glaubt, meine Beiträge hätten meine innere Einstellung
und Überzeugung wieder gegeben, der möge mich doch bitte per E-Mail
kontaktieren, denn ich habe da noch einen älteren Gebrauchtwagen (ohne
TÜV aber absolut top in Schuß!), den ich noch loswerden möchte.
Jürgen Henning schrieb:> Natürlich möchte ich mich auch bei den Moderatoren dafür bedanken, dass> sie die Diskussion in halbwegs zivilisierten Bahnen gehalten haben (ein> paar Löschaktionen deuten ja darauf, dass dies nötig war).
Macht nichts, die gelöschten Posts waren ja begeistert von deinem Buch.
> Worin ich auf jeden Fall bestärkt wurde ist die Überzeugung, dass es> kein Überangebot an guten deutschsprachigen Büchern zu der Thematik> gibt.
In der Tat gibt es zuwenig gute Bücher über dieses Thema.
> P.S. Falls jemand glaubt, meine Beiträge hätten meine innere Einstellung> und Überzeugung wieder gegeben,
Jaja, geschenkt...
In den letzten Posts hat man ja allmählich ein Umdenken erahnen können.
Geh halt nochmal kritisch über dein Manuskript rüber oder halt nicht.
Bezahl das nächste Mal einen ordentlichen Lektor und erhoffe nicht, das
andere hier gratis sich diese Arbeit aufbürden. Oder hoffe weiterhin auf
ein Lektorat vom Verlag, bzw lebe dann mit dem Buch was herauskommt.
Grüsse
Klaus
P.S.: Es wird mich sicher freuen, wenn Du ein gutes Buch herausbringt.
Wir werden ja sehen, oder?
Hallo Klaus.
Klaus I. schrieb:> P.S.: Es wird mich sicher freuen, wenn Du ein gutes Buch herausbringt.> Wir werden ja sehen, oder?
Frei nach Dinner for One: "I'll do my very best, hick. Cheers!"
Gruß
Jürgen
...da ich gerade darüber gestolpert bin und mich an diese amüsante
Diskussion erinnern konnte...
Hat jemand das Ding schon gelesen: https://www.amazon.de/dp/3895763225/
Über den Autor und weitere Mitwirkende
Auf ein abgeschlossenes Studium der Elektrotechnik (Schwerpunkt: Mess-,
Regel- und Datentechnik) folgten etliche Jahre in der Industrie. Vor 20
Jahren brach er mit seinem Motorrad zu einer Weltumrundung auf (das war
das Beste, was er sich in seinem Leben angetan hat).
Dem letzten Satz 1:1 in die die 3. Person umzuformulieren hört sich
ziemlich komisch an...
Bitte kaufen und berichten!
Laut Beschreibung ist das Buch jetzt für Arduino-Erfahrene und nicht
mehr "von Jürgen für Jürgen" ;o)
Wenn das Material gut überarbeitet worden ist, wäre so ein Buch
natürlich klasse.
Zum reinen Probelesen ist es mir aber zu teuer, Preisgestaltung passt
aber zu ähnlichen Büchern vom Elektor Verlag und reich wird Jürgen damit
sicherlich nicht.
Moin! Es hatte doch noch eine Weile gedauert, aber im Dezember letzten
Jahres war es dann so weit: Der Elektor-Verlag veröffentlichte das Buch.
Bei der Frage, ob sich die Anschaffung lohnt, verweise ich mal auf die
C´t 2017, Heft 4, wo jemand aus der Redaktion eine 1/2-seitige Rezession
unter dem Titel "ATmega-Kraftnahrung" auf Seite 182 plazierte. Da die
Redaktion der C´t es als höchstes Lob ansieht, wenn man sie als
Erbsenzähler bezeichnet, dann kann man meine Zufriedenheit mit der
Rezession verstehen: "... Zahlreiche Diagramme, Schaltungen und
Übersichtstabellen sowie ein umfangreiches Glossar und alphabetische
Stichwortverzeichnisse zu den Registern, Fuses und Lockbits machen das
Werk nicht nur zu einem Lehrbuch, sondern auch zu einem geeigneten
Nachschlagewerk. .... Für Bastler und Entwickler eigener
Mikrokontroller-Projekte ist das Buch jedenfalls eine nützliche Hilfe."
Ich hätte mir eigentlich einen VK-Preis von unter 30 Euro gewünscht,
aber da verfügt der Verlag über exklusive Rechte. Ich nehme an, dass man
den Vollkosten-Stundenlohn eines Entwicklers als Kalkulationsgrundlage
genommen hat; wenn mehr als eine halbe Stunde eingespart wird, dann hat
sich das Buch für eine Firma schon mal gelohnt.
Somit ist es jetzt an der Zeit für mich, mich bei allen zu bedanken, die
sich vor zwei Jahren mit dem Rohmanuskript auseinander gesetzt haben.
Ich glaube, ich habe (fast) alles an konstruktiver Kritik in das Buch
einbringen können. Da mich das Buch weder reich noch wohlhabend machen
wird, kann ich meinen Dank nur dadurch ausdrücken, dass ich ein Bier auf
euer Wohl erhebe und es dann genüsslich selber trinke. Dies sei hiermit
geschehen: Skol!
Jürgen H. schrieb:> ... eine 1/2-seitige Rezession ...Jürgen H. schrieb:> ... mit der Rezession ...
Rezession: Rückgang der Konjunktur
Rezension: kritische Besprechung eines Buches
Ich nehme an Du meinst letzteres.
Jürgen H. schrieb:> Skol!
Prost! Jürgen und herzliche Glückwünsche zu Deinem Buch.
Eigentlich würde mich ja interessieren wieviel Zeit Du da letztendlich
reingesteckt hast, gibt es einen Schätzwert dazu?
Jürgen H. schrieb:> Bei der Frage, ob sich die Anschaffung lohnt, verweise ich mal auf die> C´t 2017, Heft 4, wo jemand aus der Redaktion eine 1/2-seitige Rezession> unter dem Titel "ATmega-Kraftnahrung" auf Seite 182 plazierte.>https://www.heise.de/select/ct/2017/4/1486924132628048
Hallo und danke dafür, das du ein Autor bist, der sich in dem besten mir
bekannten deutschsprachigen Forum zum Thema Mikrocontroller meldet.
Habe leider diesen Thread aus den Augen verloren, da ich in diesen
Jahren andere Probleme hatte. Nun muss ich mit dem Ergebnis leben und
weiß leider doch nicht, was mich erwarten würde.
Wenn ich aus den ganzen Informationen aus diesem Thread bezüglich der
Programmiersprache alles richtig interpretiere, sollten / müssen
C-Kenntnisse vorhanden sein.
Schade.
Hätte mir gewünscht, das wie im Buch von Günter Schmitt jeweils ein
Assemblerprogramm und ein C-Programm abgebildet wird. Schade finde ich
ebenfalls, das sämtliche Elektorbücher für die ich mich interessiert
habe bei Amazon kein " Blick ins Buch " erlauben. Ein Inhaltverzeichnis
ist schon mal nicht schlecht, aber wichtiger finde ich den " Erklärstil
" des Autors an Hand seiner Beispiele zu erkennen.
Ok, hab doch entdeckt, das Elektor selber einen " Blick ins Buch "
erlaubt, der über das Inhaltsverzeichnis hinausgeht. Etwas weiter unten
bei Online blättern zu finden. Ist zwar umständlich, wegen dem Scrollen
zum vergrößern und verschieben, aber besser als gar nichts.
https://www.elektor.de/avr-programmierung-fuer-quereinsteiger#preview
Von Programmbeipielen ist aus erklärten Gründen hier schon mal keins zu
sehen. Um so besser für mich. Ich denke ich komm mit dem Stil des Autors
zurecht und finde ganz gut, das die Spezial Funktionsregister mit
Kapitelangaben zum besseren Verständnis angegefügt sind. In diesem
Sinne:
" Danke für das Buch ".
https://www.amazon.de/AVR-Programmierung-f%C3%BCr-Quereinsteiger-ATmega8-ATmega328/dp/3895763225
Ein Datenblattlegastheniker ;-)
Bernd_Stein
Moin @Alexander
> Rezension: kritische Besprechung eines Buches> Ich nehme an Du meinst letzteres.
Da hatte ich wohl schon zu oft Skol gesagt (obwohl, einen leichten Hang
zur Legastenie habe ich auch und bin glücklich über die
Korrekturfunktionen heutzutage).
Moin @Klaus,
wenn du von einem Jahr ohne Wochenende und täglich 5-6 Stunden ausgehst,
dann liegst du ungefähr richtig. Ich kenne die aktuellen Verkaufszahlen
nicht, gehe aber davon aus, dass es sehr viele Jahre dauert, bis ich auf
den gesetzlichen Mindestlohn komme.
Moin @Bernd,
auf Wunsch des Verlages wurde ein Kapitel über C eingefügt; man wollte
es auf 20 Seiten begrenzen, ich habe sie dann auf 30 Seiten
hochgehandelt und schließlich 50 Seiten geliefert. Wenn man irgendeine
prozedurale Programmiersprache (halbwegs) beherrscht, dann sollte der
Übergang eigentlich keine Schwierigkeiten bereiten.
Jürgen H. schrieb:> Moin @Bernd,> auf Wunsch des Verlages wurde ein Kapitel über C eingefügt; man wollte> es auf 20 Seiten begrenzen, ich habe sie dann auf 30 Seiten> hochgehandelt und schließlich 50 Seiten geliefert. Wenn man irgendeine> prozedurale Programmiersprache (halbwegs) beherrscht, dann sollte der> Übergang eigentlich keine Schwierigkeiten bereiten.>
Ich habs als Datenblattlegastheniker ;-) trotzdem vorhin bestellt, da
du mir ja in Gewisserweise große Teile des Datenblattübersetzens darin
abnimmst.
Suche noch ein gutes Buch, das ausschließlich und sehr detailiert auf
die AVR-Assemblerprogrammierung eingeht. Die Buchserie von Manfred
Schwabl-Schmidt verkauft sich ja nicht gut, ist ziemlich teuer und man
hat keinen " Blick ins Buch ".
Bernd_Stein
Bernd S. schrieb:> Die Buchserie von Manfred> Schwabl-Schmidt verkauft sich ja nicht gut, ist ziemlich teuer und man> hat keinen " Blick ins Buch ".>
Habe mir die Bände 2,3 und 4 zugelegt. Ist leider nichts für mich.
Einfach nur fürchterlich. Die DCF77-Abhandlung in Band 2 ist evtl.
interessant, aber leider auch viel zu hoch für mich. Ich denke für diese
Buchreihe muss man schon ein wenig autistisch veranlagt sein, um in
diese Welt eintauchen zu können.
Da lobe ich mir doch so ein relativ einfach gestricktes Buch, wie das
hier besprochene. Dem kann ich wenigstens folgen und es liest sich eher
wie von Normal-Mensch zu Normal-Mensch ;-).
Trotzdem würde ich gern auch mal in Band 1 ( AVR-Programmierung 1 )
hineinschnuppern, wenn es irgedwo günstig zu bekommen ist um zu sehen,
ob der Typ immer nur so hochgestochen schreibt.
Bernd_Stein
Bernd S. schrieb:> Ich denke für diese> Buchreihe muss man schon ein wenig autistisch veranlagt sein, um in> diese Welt eintauchen zu können.
Jau! Ganz fürchterlich zu lesen.
F. F. schrieb:> Jau! Ganz fürchterlich zu lesen.>
Habe gerade das Buch " AVR-Programmierung für Quereinsteiger " mit
teilweise Kapitelübersprügen durch. Und hier kann ich nur sagen, *sehr
gut zu lesen*.
Ein weiteres Highlight, war für mich Kapitel 18 Simulatoren und ( In
Circuit ) Debugging.
Wenn ich da an "AVR-Mikrocontroller-Praxis" von 1999 zurückdenke, war
der Kauf des oben genannten Buches - sinnvoll. Dieses Buch von 1999 habe
ich, so glaube ich, noch nicht einmal über eine eBay Versteigerung bei 1
Euro beginnend verkauft bekommen und somit fachgerecht, dieses Fachbuch
entsorgt.
Ich glaube es wurde auch von zwei Superstudierten geschrieben ( aber
nicht im entferntesten so fürchterlich wie die Buchreihe
AVR-Programmierung ).
Fazit:
Ich kann das Buch " AVR-Programmierung für Quereinsteiger ", für Leute
die mit dem orginalen Datenbuch zu den genannten Mikrocontrollern (
ATmega8 & ATmega328 und dessen Familie ) auf Kriegsfuss stehen nur
empfehlen. Auch wenn man nur in AVR-Assembler programmiert.
Danke für das Buch.
Mal sehen, wie weit mir die Buchempfehlung für Hobbyprojekte
weiterhilft, auch wenn ich kein Motorrad warten möchte ;-).
Bernd_Stein
Das Buch gibt es ja mittlerweile zu kaufen, Bewertungen auf Amazon gibt
es allerdings keine. Gibt es jemanden hier der sich das Buch gekauft hat
und sagen kann an wen sich das Buch Inhaltlich richtet?
Val H. schrieb:> Das Buch gibt es ja mittlerweile zu kaufen, Bewertungen auf Amazon gibt> es allerdings keine. Gibt es jemanden hier der sich das Buch gekauft hat> und sagen kann an wen sich das Buch Inhaltlich richtet?
Es gibt eine Bewertung bei Elektor selbst. Qualität und Wert jeweils 5
Sterne und beim Preis sind es nur 4 (was ich nachvollziehen kann).
Prinzipiell werden keine Vorkenntnisse erwartet (sind aber deutlich von
Vorteil).
Jürgen H. schrieb:> Es gibt eine Bewertung bei Elektor selbst.>
Ich würde eher lesen was hier zu dem Buch steht. Amazon z.B. hat so
seine Richtlinien und verbietet z.B. eine Verlinkung hierher. Und da die
Betreiber dieser Homepages nun mal bestimmen können, was an Bewertungen
angenommen wird und was nicht, kann sich natürlich jeder halbwegs
vernünftig denkende Mensch vorstellen, wie das Verhältnis von Pro und
Kontra auf Seiten ist, die diese Dinge verkaufen. Erst recht, wenn sie
noch aktuell sind. Ein indiz, das Leute zu viel erwartet haben, ist das
Angebot an Gebrauchtware. Dies ist aber nur in Relation zur Neuware
vernünftig zu betrachten und das bekommt man nicht geboten, da dies
immer wieder verändert wird oder glaubt hier jemand das Amazon nur 50
Bücher neu geordert hat. Andrerseits spielt natürlich der zu erwartende
Gebrauchtpreis eine Rolle, wo man sich natürlich doch überlegt das Buch
nicht "verschenken" zu wollen.
Val H. schrieb:> Ich hätte auch noch Interesse an dem Buch, auch wenn die Zeit abgelaufen> ist, gibt es noch die Möglichkeit das Buch zu bekommen?>Val H. schrieb:> Das Buch gibt es ja mittlerweile zu kaufen, Bewertungen auf Amazon gibt> es allerdings keine. Gibt es jemanden hier der sich das Buch gekauft hat> und sagen kann an wen sich das Buch Inhaltlich richtet?>
Hm, - welches Buch meint er denn jetzt eigentlich oder etwa beide ?
Auch dieses ?
AVR-Programmierung 1: Grundlagen und der Aufbau von Programmstrukturen
https://www.amazon.de/AVR-Programmierung-Grundlagen-Aufbau-von-Programmstrukturen/dp/3895762296/ref=sr_1_3?ie=UTF8&qid=1496932269&sr=8-3&keywords=avr+programmierung
Bernd_Stein
Bei der I²C bzw. TWI-Berarbeitung in dem Buch, ist dem Jürgen ja
aufgefallen, das die TWI-Statuscodes eine kontinuierliche Zahlenfolge
ergeben, wenn diese 3x nach rechts "geshiftet" werden ( Lese die Seiten
95&96 im Script, das hier zum Download zur Verfügung stand oder im Buch
die Seiten 162&163 ).
Dazu schreibt er dann: " Die Interrupt-Routine für den TWI wird also
extrem simpel. "
Das empfinde ich jedoch nicht so.
Als Beispiel die *Typische TWI-Datenübertragung:*
START # SLA_W # DATA # STOP
Die Rückgemeldeten Statuscodes wären, wenn alles sauber läuft :
1($08>>3) # 3($18>>3) # 5($28>>3)
Was nützt mir dann die Erkenntnis der kontinurlichen Zahlenfolge, wenn
die Rückmeldungen des TWSR ( TWI-Status Register ) dies nicht mehr sind
( 1,3,5 )?
Wenn man dann noch z.B. nach dem Senden von SLA_W, ein NACK
zurückbekommt 4 ($20>>3) sieht die Reihenfolge wieder anders aus (
1,4,5 ).
Ich schreib jetzt auch mal den Jürgen über seinen µC.net Zugang an, wie
z.B. das "simple" AVR8ASM-Programm, also das simple-Assemblerprgramm auf
dem ATmega8 aussieht, das die oben gezeigte *Typische
TWI-Datenübertragung* umsetzt und dabei auf die entstehenden
TWI-Statuscodes reagiert.
Bernd_Stein
Bernd S. schrieb:> Dazu schreibt er dann: " Die Interrupt-Routine für den TWI wird also> extrem simpel. ">> Das empfinde ich jedoch nicht so.> Als Beispiel die *Typische TWI-Datenübertragung:*>> START # SLA_W # DATA # STOP>> Die Rückgemeldeten Statuscodes wären, wenn alles sauber läuft :>> 1($08>>3) # 3($18>>3) # 5($28>>3)>> Was nützt mir dann die Erkenntnis der kontinurlichen Zahlenfolge, wenn> die Rückmeldungen des TWSR ( TWI-Status Register ) dies nicht mehr sind> ( 1,3,5 )?>
Ich weiß, diese Erkenntnis ist für die Meisten neu, aber man braucht
das Buch eigentlich nicht, sondern das hier oben sollte reichen, wenn
man sich mit der TWI des ATmega8 auskennt.
Das Hauptproblem dürfte wohl sein, das ich gerne ein AVR8ASM Beispiel
hätte, wenn jemand verstanden hat, was der Autor mit "simpel" meint und
dies auch noch in Assembler umsetzen kann.
Bernd_Stein
Bernd S. schrieb:> Ich weiß, diese Erkenntnis ist für die Meisten neu, aber man braucht> das Buch eigentlich nicht, sondern das hier oben sollte reichen, wenn> man sich mit der TWI des ATmega8 auskennt.
LOL.
Ein Lexikon oder Wikipedia braucht man eigentlich nicht, wenn man schon
alles weiss, was da drinsteht. :-)
Thread beobachten
Seitenaufteilung abschalten