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.
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.