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