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
Nagut, ich habs mal überflogen. Hmm, Kilt??? Das Buch ist für Anfänger sicher nützlich.
:
Bearbeitet durch User
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.
Jürgen Henning schrieb: > Der „Request For Comments“ ist hiermit eröffnet! Willst du Kommentare hier gepostet haben?
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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: > Ich fand kein einziges Buch, > was sinnvoll nutzbar war und sogar die Tutorials bei microcontroller.net > waren nur bedingt hilfreich Hallo, was ist denn z.B. an diesem Buch: Schmitt, Günter, "Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie" http://www.degruyter.com/view/product/221318?rskey=QGQTBk&result=7 http://www.amazon.de/Mikrocomputertechnik-Controllern-Atmel-AVR-RISC-Familie-Programmierung/dp/3486589881/ref=sr_1_1?s=books&ie=UTF8&qid=1419540300&sr=1-1&keywords=Schmitt+Mikrocomputertechnik nicht so gut? Es ist zwar scheinbar nicht für den absoluten Anfänger geschrieben, sondern eher für Studenten, aber vom Inhalt sieht es ganz gut aus. Ich überlege es evtl. zu kaufen.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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?"
F. Fo schrieb: > Denn ohne Spaß hört man erst mit dem Buch und dann mit den > Mikrocontrollern auf. Thumbs Up! Jürgen
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;-)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
jdhenning schrieb: >> Und dazu gehören 100n zwischen VCC und GND und zwischen AVCC und AGND, >> dazu gehört, dass AVCC und AGND immer angeschlossen werden müssen, >> auch wenn man die Analogfunktionen nicht verwendet, dazu gehört die >> Warnung vor offenen Eingängen und den dabei auftretenden hohen >> Querströmen in der CMOS-Eingangsstufe etc pp. > Danke, guter Hinweis, nehme ich auf. Ich hatte irgendwo die Empfehlung > gelesen, man solle eine 10 µH Spule zwischen VCC und AVCC setzen. > Erscheint mir sinnvoll. Erfahrungen? Ich verwende oft so eine kleine Ferrit-Induktivität, ähnlich wie das hier: http://www.reichelt.de/Fest-Induktivitaeten-SMD/JCI-2012-10-/3//index.html?ACTION=3&GROUPID=3178&ARTICLE=9001&OFFSET=16&WKID=0& Gibts auch in verschiedenen Größen und Werten. Ferrit deswegen, weil der die HF-Anteile in Wärme umsetzt. Man will hier eben keine besonders hohe Güte haben. Du willst ja keinen Schwingkreis aufbauen. Bedrahtet sieht das so aus: http://www.reichelt.de/Fest-Induktivitaeten-axial/L-HBCC-10-/3//index.html?ACTION=3&GROUPID=3179&ARTICLE=86460&OFFSET=500&WKID=0& fchk
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
:
Bearbeitet durch User
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
... und schätze mal ab, wie groß deine Zielgruppe ist. habe ich als letzten Satz vorhin vergessen. W.
Paul Baumann schrieb: > @jdHenning > Du bist auf dem richtigen Weg. Kurzen Dank für die Blume. 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
Ich habe gerade noch mal nachgesehen: http://www.buch-schreiben.de/buch-veroeffentlichen/autorenhonorar.php In der Tat bekommt der Autor wohl nur um die 10% vom Endpreis. Selbst wenn man viel Glück hat und ein paar hundert Exemplare verkauft ist das nicht viel.
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
Salewski, Stefan schrieb: > Also ich würde eh eher abraten. Gut, besser > als Saufen und Video gucken immerhin. Das hatte ich mir auch gedacht.
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: > Internet-Explorer Funktioniert einwandfrei mit zwei anderen Browsern. Hatte es gestern Abend mal probiert.
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.
:
Bearbeitet durch User
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
jdhenning schrieb: > Bei den Fuses war > ich (auch nach mehrmaligen Lesen) auch fassunglos: Ich habe die Fuses auch erst verstanden, nachdem ich das von einem netten Menschen erklärt bekommen habe. http://www.schniko.at/index.php/de/avr-meets-me/121-erklaerung-avr-fuse-bits-sut-cksel-taktauswahl-deutsch
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
:
Bearbeitet durch User
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
Zur Ich-Form: http://www.faz.net/aktuell/feuilleton/autorschaft-das-ich-als-unverschaemtheit-11684188.html
1 | 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!
:
Bearbeitet durch User
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...
man kann das bald nicht mehr lesen, was die Vorbilder und Co so von sich geben..jdhenninger halte durch!
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.
Ich muss mich noch einmal zu Wort melden. Es gibt schon ein sehr gutes Buch und eben für moderne AVR. Das AVR Kochbuch.
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.
:
Bearbeitet durch User
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
PittyJ schrieb: > Mein Fazit: Mehr Diagramme, Schaubilder und Abläufe. Kommt, ist versprochen. 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.
:
Bearbeitet durch User
Max schrieb: > Ich bin übrigens trotz einiger Beiträge, immer noch überrascht wie > gesittet es hier momentan zugeht :-) Ich auch. Guten Rutsch Jürgen
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.
Michael Reinelt schrieb: > Ähhh... bist du sicher? Yepp. http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx
jdhenning schrieb: > Michael Reinelt schrieb: >> Ähhh... bist du sicher? > > Yepp. http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx Hast du das ausprobiert? Soweit ich weiss ist das nur die Toolchain (command line), kein Studio Harald Nagy schrieb: >> Oder verwechsle ich da grad was? > > Exakt. etwas deutlicher kostet fast gleichviel :-)
:
Bearbeitet durch User
Das Studio gibt es nur für Windows. Allein die Toolchain gibt es quasi für alle Systeme auf die der gcc portiert wurde...
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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:
1 | jdhenningATjdhenningDOT de |
2 | 'AT' durch '@' ersetzen und 'DOT' durch '.' |
In einem Buch? Ist das dein Ernst?
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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 Namen veröffentlichen will, aber nicht denken. Man kann ja z.B. einen eigenen Mailaccount für dieses Buch einrichten...
:
Bearbeitet durch Moderator
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
:
Bearbeitet durch User
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.
justmy2cents schrieb: > 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. Wenn Du Geld für Mumpitz ausgeben willst, ist dieses Buch das Richtige: http://www.amazon.de/gp/product/3895760633?*Version*=1&*entries*=0 :-( MfG Paul
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
Jetzt lasst den Jürgen doch schreiben, wie er möchte. Es wird einen Lektor im Verlag geben, der ihm dann weiterhelfen wird.
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
:
Bearbeitet durch User
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...
:
Bearbeitet durch Moderator
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 Lass dich nicht von einem Troll provozieren, schau mal auf den seinen Namen, das sagt schon alles.
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.
>DIP-Form wählen (Dual Inline Plastik)
<Ironie>
ich habe hier auch ICs in DIC-Form (Dual Inline Ceramic)
</Ironie>
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)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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!
Ich habe gerade nachgeschaut und bin schockiert über den Preis des Buches. Echt extrem. Damals kostete es wenige als die Hälfte. Gerhard
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
>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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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
Hallo, spess53 schrieb im Beitrag #3956541: > Dann lieber gleich als Comic. Hat Schrödinger probiert. :-) http://www.pcwelt.de/news/Buchvorstellung-Peppiges-Programmierhandbuch-Schroedinger-programmiert-C-5867349.html LG
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.
:
Bearbeitet durch User
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
Leute, lasst die vielen 'du' aus den Posts raus! Es geht hier um die Sache, nicht um persönliche Befindlichkeiten.
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
PopCorn schrieb: > Hat Schrödinger probiert. :-) > > http://www.pcwelt.de/news/Buchvorstellung-Peppiges-Programmierhandbuch-Schroedinger-programmiert-C-5867349.html > > LG Ich hoffe, du willst mich nicht wirklich hier "PHP & MySQL für Kids-Bücher" einsortieren. Ich weiß nicht, wie tief ich sinken kann (das wusste man bei RTL vor etlichen Jahren ja auch nicht), aber ich glaube dass schaffe ich nicht, auch nicht mit viel Mühe! Gruß Jürgen
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch Moderator
Wenn so ein Thread langsam länger als das Buch wird, fragt man sich eh nach dem Sinn.
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.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Die Ingenieure von Atmel > sind Deppen und im Datenblatt steht Unsinn. Dieser Aussage stimme ich nur zu 1% zu. ;-) MfG Paul
Paul Baumann schrieb: > Dieser Aussage stimme ich nur zu 1% zu. Immerhin. Also wenn sich jetzt noch 99 Leute finden, ist das volle Zustimmung. mfg.
:
Bearbeitet durch User
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...
Danke für das Buch! Kann sein, dass es für mich genau das Richtige ist. Bin Anfänger.
Hi > Kann sein, dass es für mich genau das Richtige ist. >Bin Anfänger. Nein. Such dir richtige Bücher. MfG Spess
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.
:
Bearbeitet durch Moderator
> 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.
Hallo, auf der Elektorseite zum Buch gibt es in der Vorschau 36 Seiten zum Probelesen https://www.elektor.de/avr-programmierung-fuer-quereinsteiger
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?
Beitrag #5029212 wurde von einem Moderator gelöscht.
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
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?
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?
:
Bearbeitet durch User
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
:
Bearbeitet durch User
> 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 Ich glaube da bin ich mit dem Assembler Tutorial hier im Forum besser bedient da schnellerer Erfolg garantiert ist und dennoch ausführlich erklärt wird :-)
Beitrag #5128352 wurde von einem Moderator gelöscht.
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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. :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.