Diskussion:AVR-GCC-Tutorial

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Benutzerfreundlichkeit erhöhen

Das Tutorial ist momentan ein prima Nachschlagewerk für erfahrene Benutzer, leider hat seine Qualität als Tutorial etwas nachgelassen. Auch ich habe mit ihm meinen Einstieg in die Welt der µC gefunden, aber ich glaube ich würde dies nicht mehr schaffen. Werde in den nächsten Wochen das Tutorial ein wenig verbessern, an den Mega16 anpassen und erweitern. Zusätzlich werde ich ein Tutorial für Digital-Elektronik schreiben.

FeeJai 20:26, 27. Nov 2006 (CET)

Dazu:

  • "...momentan ein prima Nachschlagewerk für erfahrene Benutzer...": Sorry, aber "erfahrene Benutzer" finden dem Tutorial wenig bis garnichts neues. Die Dokumentation der avr-libc ist eher ein gutes Nachschlagewerk. Das Tutorial nicht, vieles wird nicht detailliert erläutert und einiges nicht mal angesprochen. Was genau macht das Tutorial zu einem Nachschlagewerk?
  • "Qualität als Tutorial etwas nachgelassen": Da ich wohl die meisten Erweiterungen und Aktualisierungen geschrieben habe, seit der Artikel ins Wiki aufgenommen wurde, nehme ich das mal zum Anlass zu fragen, was mit "Qualität nachlassen" gemeint ist. Hier "Qualität nachlassen" ohne ein wenig Begründung hinzuschreiben ist mir zu platt. Wenn richtig erinnert, habe zumindest ich nichts aus einen "qualitativ" hochwertigeren alten Zustand gelöscht (bis auf Links zu Quellcode, die nicht mehr gültig waren und nur neuen Text dazu geschrieben bzw. veraltete Informationen aktualisiert.
  • "...nicht mehr schaffen...": Warum nicht? Was war vorher einfacher "zu schaffen"? Nur weil der Makefile-Exkurs etwas ausgeufert ist? Falls das der einzige Grund war: habe nun versucht, es etwas aufzuspalten. Etwas konkreter dürfte das "nicht mehr schaffen" schon sein. Bisher habe ich diese Meinung genau einmal gelesen (hier), aber vielleicht auch woanders nicht wahrgenommen. Wenn die Verbesserung darin bestand, die Erläuterungen zum Makefiles in den Anhang zu verschieben und dann im Text zu schreiben: "Sollte man noch nie mit Makefiles gearbeitet haben ist es nun an der Zeit sich den Exkurs: makefiles im Anhang A durchzulesen." ist das bestenfalls unglücklich. Der Großteil der Anfänger, die das Tutorial zum Einstieg lesen, wird vorher kaum ein makefile selbst editiert haben. Viele von den, die C mit Borland, MS oder welcher IDE auch immer gelernt haben, werden nicht mal wissen, was ein makefile ist - da hilft auch der Hinweis auf MFile erstmal wenig. Den ganzen Abschnitt nach ganz unten zu verschieben (und dabei Links und Gliederung zu zerschießen) und dann unmittelbar an der ursprünglichen Stelle den wahrscheinlich typischen Anfänger (die eigentliche Zielgruppe) dahin zu verweisen, war für mich keine nachvollziehbare Verbesserung der "Benutzerfreundlichkeit".
  • "...in den nächsten Wochen...": Dann aber zumindest den Artikel nach jeder Änderung so hinterlassen, dass die Gliederungsebenen und internen Verlinkungen noch passen - nicht so wie zum Stand 20061128_1900.
  • "...an den Mega16...": die Aktualisierung der Tabellen mit Registerbeschreibungen ist eine gute Idee. Aber wenn man sich schon die Mühe macht, dann wäre eine Anpassung an aktuelle AVR (ATmega644, ATmega48/88/168,...) sinnvoller, da die Registernamen bei den neueren von Herstellerseite noch etwas einheitlicher sind und sich wahrscheinlich in Zukunft auch selten jemand die Mühe macht die Beschreibungen zu überarbeiten. ATmega16 ist auch schon etwas betagt. Aber nicht aufhalten lassen, für ATmega16 ist auf jeden Fall schon besser als für abgekündigte AT90S.
  • In der neuen Makefile-Seite (Stand 20061128_1900) blind die Vorlage zusammen mit dem Eintrag für CPPSRC ("CPPSRC = main.cpp") reinzukopieren und dann in der "Einführung" darauf zu verweisen, hatte die Benutzerfreundlichkeit eher umkehren.
  • Die Ergänzung um eine Schritt-für-Schritt Einführung ist ein gute Idee. War aber meiner Meinung zu knapp, z.B. Begriffe, die ein Microcontroller-Anfänger eher nicht kennt, Erklärungen nicht ganz richtig (aber das sind meine Ergänzungen/Änderungen wahrscheinlich auch nicht alle). Die inkompatible Binärschreibweise (0b00..) war nicht gut (braucht gepatchten gcc - nicht alle nutzen WinAVR). Syntaxfehler (fehlendes ;).

Also: behutsamer Erweitern, mindestens einmal prüfen - im Zweifel den Compiler anwerfen und testen (makefile, Syntaxfehler), größere Änderungen auf dieser Seite zur Diskussion stellen. Gliederung und Verlinkung beachten.

Nun denn, habe ein wenig an dem Tutorial herumgebastelt, einiges übernommen, einiges ergänzt aber an einigen Stellen Änderungen auch rückgängig gemacht. Das soll aber kein Anlass sein, nun keine Änderungen oder Erweiterungen mehr einzubringen. Das Wiki "lebt" davon, dass viele Leute das beitragen, was sie für richtig halten und das Ganze sich auf Dauer durch Ergänzungen und Änderungen stetig verbessert.

Martin Thomas


Hallo! Mich freut es, dass sich jemand für meine Änderungen interessiert und diese auch verbessert. Inzwischen wurden ja noch ein paar kleine Änderungen vorgenommen. Was ich besonders wichtig finde, ist dass der Benutzer ein schnelles Erfolgserlebnis hat und damit nicht mehr so leicht frustriert aufgibt. Deswegen habe ich den Exkurs Makefiles in den Anhang verschoben. Ich fand dass er ansonsten zu abschreckend ist und potentielle Anfänger geradezu erschlägt. Bei meinem Start habe ich ihn übersprungen und das compilieren schlug natürlich fehl. Allerdings hatte ich die LCD samples von U. Radig auf meinem PC und habe sein Makefile beutzt. Daher das sample für Anfänger. ==> Ich wäre dafür den sehr ausführlichen "Exkurs" in den Anhang zu verschieben, Anfänger mit einem bereitgestellten Beispiel beginnen zu lassen und das Makefile-Konzept anhand praktischer Beispiele nach und nach zu erklären. So sind auch die meisten sehr erfolgreichen Computerbücher (z.B. von Michael Kofler) aufgebaut. Die Sache mit dem Nachschlagewerk für erfahrene Benutzer, hätte ich vielleicht anderst formulieren sollen. Zutreffender ist: Amateure, jedenfalls nutze ich es gerne als Nachschlagewerk. Das mit Qualität als Tutorial nachgelassen war so von mir nicht richtig. Ich finde es in seiner bestehenden Anordnung und Detailliertheit gerade am Anfang zu umfangreich. Man kann selbst mit Vorkentnissen nicht alles verstehen, geschweige denn behalten. Den M16 habe ich genommen denn er besitzt nahezu alle in AVRs vorkommenden Funktionen, ist erschwinglich, beliebt, wird mit ziemlicher Sicherheit demnächst nicht abgekündigt und vorallem kenne ich mich gut mit ihm aus. Die Sache mit der Gliederung tut mir sehr leid, ich werde mich bemühen, dass etwas derartiges nicht mehr vorkommt. Leider habe ich mit derart großen Texten in wikis auch noch nie gearbeitet. Grüße,

FeeJai 21:38, 29. Nov 2006 (CET)


Dann bietet es sich doch an, die einzelnen Abschnitte im Tutorial mehr nach Erfahrungslevel (Einsteiger, Kenner, Könner ;-) zu gliedern und auch zu kennzeichnen.

Stefan 00:24, 30. Nov 2006 (CET)


Prinzipiell nichts dagegen. Möchte noch Antowrt von mt abwarten. So ähnlich habe ich es ja auch vor. Da ich glaube dass es oben etwas unverständlich war was ich gerne machen würde, möchte ich es hier nochmals erläutern:

  • Konzept: Mir ist das Tutorial bisher zu theoretisch. Ich möchte den Leser nach dem Einführungsbeispiel anhand praktischer Beispiele, die Zeile für Zeile erklärt werden und langsam anspruchsvoller werden die Welt der µC näher bringen. So etwas nennt man schrittweise Hinführung.
  • Mit den Makefiles würde ich es gerne ähnlich handhaben: Da man sie immer zum compilieren benötigt, am Anfang ein funktionierendes Makefile bereitstellen, dieses muss der Leser noch nicht verstehen! Wenn die Projekte dann anspruchsvoller werden das Makefile entsprechend erweitern und somit erklären. Eine zusammenfassende alles abdeckende Erklärung ist im Anhang gut aufgehoben, überfordert aber IMHO Anfänger.
  • Der Konjunktiv: sehr höflich, wenn man absoluten Anfängern etwas beibringen will aber eher Kontraproduktiv. Beispiel Programmers Notepad. Jemand der noch nie mit µC gearbeitet hat freut sich über eine klare(!) Anweisung, wie zu Verfahren ist und die auch funktioniert. Die Loslösung von den klares Strukturen wenn man bspw. PonyProg nicht verweden will kommt mit dem zunehmenden Verständnis wie von selbst.

Grüße,

FeeJai 16:19, 30. Nov 2006 (CET)


Dazu - und zu den jüngsten Änderungen

Vielleicht habe ich mich nicht klar ausgedrückt: wenn man "irgendwann" mal vorhat des Tutorial "Anfängerfreundlicher" zu machen, fängt man nicht damit an vorhandene Erklärungen durch die Gegend zu schieben und fehlerhafte/unvollständige Informationen einzubauen. Meine Meinung abwarten war wohl eher als Witz gemeint. Ich habe den Exkurs "Makefiles" aus dem Anhang teilweise wieder hochgezogen - und das mit Absicht. Jetzt wird er wieder runtergeschoben - soll das irgendwie zur Belustigung beitragen? Mich motiviert sowas nicht - aber auch gar nicht. Wie wäre es damit, in den Unterabschnitten ein paar weiter Erläuterungen zur "Hinführung" zu ergänzen und als neuer Mitarbeiter an dem Wiki die Sache mal langsam angehen zu lassen? Wie wäre es mit den angekündigten Anpassungen der Registerbeschreibungen an ATMega16 - die stehen in weiten Teilen soweit ich das gesehen habe noch aus.

Ausser den nützlichen Anpassungen der Registerbeschreibungen an einer Tabelle wurde bisher nur hin- und hergeschoben ohne entsprechende Umsicht, ein "Anfängerbeispiel" mit Syntaxfehler eingetragen, eine ohne Änderung nicht brauchbare Makefilevorlage reinkopiert, im Beispiel speziellen Compilererweiterungen genutzt, die es nicht fuer jeden avr-gcc gibt und Erklärungen zum Beispiel gegeben, die mehr als knapp sind - teilweise sogar falsch (z.B. ist eine header-Datei keine Bibliothek/Library wie geschrieben stand). Wenn das "Hinführung" sein sollte, dann nur weiter so, keine Ahnung wen das wo hinführen soll. Ich finde so etwas "kontraproduktiv". Ich habe versucht, das etwas auszubügeln, da ich froh bin, wenn jemand etwas zu dem Tutorial beiträgt und die Idee eine kleinen Intros gut finde (ob das nun mit meinen Änderungen besser ist als vorher, muss jemand anderes beurteilen).

Hier zu erklären was man "schrittweise Hinführung" nennt und was "der Anfänger" will oder was "Kontrakproduktiv" ist, ist grosspurig. Erstmal zeigen, dass man selbst kann, bevor man hier belehrend über das urteilt, was andere gemacht haben. (Bisher war der gezeigte Einsteig in die Mitarbeit am Text alles andere als Überzeugend - aber auch das ist natürlich nur eine (meine) Einzelmeinung).

Zum speziellen: Ponyprog ist der Anfang vielen Übels, ich weiss nicht wie viele Fusebits wegen Pronyprog falsch eingestellt wurden (ja, ich habe auch seinerzeit mit PonyProg angefangen, ja ich habe auch einen ATmega16 damit zerfust und war erstmal aufgeschmissen denn zu der Zeit kannte ich das Forum noch nicht und auch keinen der helfen konnte). AVRdude ist im Beispiel-Makefile vorgekaut (aber ja - man will auf Makefiles ja erst im Laufe des Tutorials "Schritt fuer Schritt" eingehen). Nicht jeder, der sich mit avr und gcc beschäftigt nutzt MS-Windows und hat somit auch nicht Programmers-Notepad (Zeit für den Exkurs Programmers-Notepad mit Wine auf Linux...). Etwas mehr über den Tellerrand darf man schon schauen, vor allem wenn man sich anmaßt den Blick für die Bedürfnisse von Anfängern zu haben.

Soweit mt


Mir gefallen die jüngsten Änderungen nicht. Viele Schreibfehler jucken in den Augen und drängen mich zum Verbessern. Beim Verbessern sehe ich immer mehr ungenaue Formulierungen (serieller Programmablauf) und Voraussetzungen (Hello_World.hex.zip) und irgendwann bin ich so genervt, dass ich meine Korrektur verwerfe und das Bearbeiten abbreche. Abgesehen davon, dass ich bestimmte strukturelle Änderungen schlecht finde (Verschiebung der Erklärung des interruptgesteuerten Programmablaufs). Die richtige Lösung wäre gewesen, eine alternative Version vorzubereiten und darüber abstimmen zu lassen, statt die bestehende Version so grundlegend zu ändern. Bis es rum ist, lese ich in der älteren Version.

Stefan 17:16, 1. Dez 2006 (CET)

Hallo Allerseits!

Habe den ersten Beitrag offensichtlich nicht so negativ verstanden wie er gemeint war. Deswegen habe ich den Exkurs nun wieder nach oben geholt, ich dachte zuerst mt willst ihn nur solange oben haben bis im Text besser darauf eingegangen wird. Die Sache mit den Schreibfehlern stimmt natürlich, es war viel in kurzer Zeit was ich geändert habe. Ich würde mich daher auch freuen, wenn jemand hilft, diese zu korrigieren. Sollten mir selbst welche auffallen, werde ich sie selbstverständlich auch beheben. Dass du das Bearbeiten abbrichst finde ich aber wirklic schade.

Die ungenauen Formulierungen rühren leider auch von Unwissenheit meinerseits, die Formulierung serieller Programmablauf, die als Beispiel genannt wird, stammt aber so nicht von mir. Was Stefan an der Hello_World.zip nicht gut findet, kann ich so leider nicht nachvollziehen. Das Projekt habe ich, um für den Endanwender Tipparbeit einzusparen, als zip-Datei Online gestellt. In ihr befindet sich auch ein Makefile und das compilierte Projekt als .hex.

Der Artikel "I/O Grundlagen" in der Hinführung bedarf tatsächlich einer Überarbeitung. Ich werde mir mal durchlesen, wie Andreas das in seinem Tut erledigt hat. Das "Hello World" gefällt mir persönlich gut, wenn es aber in dieser Form nicht erwünscht ist werde ich es auch schlucken, falls die Hinführung gelöscht wird.

Die Probleme mit Ponyprog sind wahr, leider war es als ich damals anfing das einzige Programm welches auf meinem Rechner gut funktionierte - deswegen benutze ich es hauptsächlich. Weitere Vorteile sind IMHO: Benutzerfreundlich durch einfache Bedienbarkeit und dass die meisten Nutzer es bereits kennen, da es oft von PC Zeitschriften genutzt wird. Grüße,

FeeJai 17:57, 1. Dez 2006 (CET)

PS: Ich finde die Einführung mit deinen Änderungen wesentlich besser. Allerdings habe ich nochmal kleine Details verändert - wenn es dir nicht gefällt hau es einfach raus. Die neuen Beispiele sind alle getestet, auch ich lerne aus Fehlern. Die Sache mit dem 0b war mir so nicht bekannt und ist wahrlich wenig erfreulich.

Bitte fügt für einen Satz und ein paar Links keine neuen Abschnitte ein (aktuell: TWI)

Der Artikel ist ein Tutorial, das heißt dem Leser sollen die verschiedenen Aspekte der Programmierung mit AVR-GCC erklärt werden; ein Abschnitt über TWI mit drei großen Überschriften aber nur einem allgemeinen Satz und ein paar Links passt da nicht gut dazu. Wenn sich jemand die Mühe machen würde das Thema etwas ausführlicher und mit Beispielcode zu erklären wäre das natürlich sehr willkommen. andreas 15:15, 2. Dez 2007 (CET)


Tutorial nach Wikibooks portieren

Was haltet ihr davon das Tutorial nach Wikibooks zu portieren? Die Seite wird immer größer und unübersichtlicher. Die Einteilung in mehrere Seiten, sowie die Möglichkeit weiterführende Hinweise für fortgeschrittene Nutzer in eine Aufklappbox zu schreiben würden dem Tutorial sicher gut tun. Manuel Stahl 17:31, 14. Okt. 2008 (CEST)


Ich kann mir nicht recht vorstellen, wie das aussehen würde. Mein Vorschlag probiere es aus und stelle das Ergebnis zur Anschauung und Diskussion vor. Das Bessere ist des Guten Tod. Du kannst dafür die Version auf der Spielwiese avr-gcc Tutorial benutzen. Ich würde nach Möglichkeit die Umwandlung etc. mit Skripten o.ä. automatisieren, damit künftige Änderungen im jetzigen Text (siehe die grosse ToDo-Liste) rasch und automatisch ins Wikibook übertragen werden können. Stefan 12:57, 15. Okt. 2008 (CEST)

Hier mal ein erster Versuch: http://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC --Thymythos 19:40, 6. Nov. 2008 (CET)

Veraltete Register

Hi. Leider sind in dem Tutorial viele Register und Einstellungen auf inzwischen veraltete und viele verschiedene AVRs bezogen. Ich wäre dafür alles auf den ATMega16 anzupassen, da dieser alle Funktionen hat und trotzdem bezahlbar ist. Habe heute mit dem ADC angefangen und so viel Arbeit ist es nicht. Werde, falls es erwünscht ist nach und nach alles an den Mega16 anpassen.

FeeJai 18:13, 26. Nov 2006 (CET)

Frage zum Codebsp.

Warum hier im Codebsp. die Frequenz gesetzt wenn man im Einfache Wandlung (Single Conversion)-modus ist? 

 ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0);    // Frequenzvorteile setzen auf 8 (1)

Weil man immer den Vorteiler entsprechend der Quarzfrequenz setzen mu�? um den ADC nicht mit einem zu hohen Takt zu versorgen. --Matthias 19:58, 21. Sep 2004 (CEST)

Ich benutze folgenden code der funktioniert. Es wird kein vorteiler gesetzt!! 

   sbi(ADCSR,ADEN);   //ADC An
   sbi(ADMUX,MUX0);	//kanal wählen
   for (;;) {                           /* loop forever */
          	sbi(ADCSR,ADSC);				//wandlung starten
   	    	while(bit_is_set(ADCSR,ADSC)); 	//warten bis wandlung fertig
   		num = ADCW;

--- schnipp ---

Der Vorteiler hat nichts mit "funktionieren" oder "nicht funktionieren" zu tun. Man sollte sich eher Gedanken um die Genauigkeit und einzuhaltende Maximalfrequenzen bei der Wandlung machen. Der Abschnitt "ADC/Prescaling and Conversion Time" im Datenblatt gibt eigentlich erschoepfend Auskunft darueber. Das "sbi" in dem Beispielcode oben in einem Diskussionsbeitrag zum gcc-tutorial noch auftaucht ist mir schleierhaft, da kann ich mir die Aktualisierung auch sparen. Falls das im Artikel gezeigte Beispiel nachweislich falsch sein sollte: bitte aendern. MfG M. Thomas

Butterfly schoen und gut, aber diese beiden Hinweise in letzter Zeit mit der Preisangabe "30Eur"... Ist das irgendwo ein Lager "zu voll" und wird hier versucht "etwas Werbung" zu machen? Der Preis ist "normal" aber wenn man sich umschaut und/oder sich mit ein paar Leuten für eine Sammelbestellung zusammentut gibt es die Teile deutlich guenstiger.

Links korrigiert

Einige der Links im Kapitel 11.1.1 (Messen eines Widerstandes) funktionieren nicht. Dies wären:

--Oxygene 12:05, 12. Nov 2004 (CET)

Tabellen

Habe die Tabellen übersichtlicher gemacht, überflüssige Tabellen durch gewöhnliche Einrückungen ersetzt und recht viele Kommafehler bei Konditionalsätzen berichtigt (so um die 762 *g*). Inhaltlich ist alles gleich geblieben. --Oxygene 15:01, 12. Nov 2004 (CET)

Inhaltliches

Danke fuer die Korrekturen, einige der Fehler sind sicher "auf meinem Mist gewachsen". Die Links zu "Messen eines Widerstands" sollten ganz raus, entweder ein aktualisiertes Beispiel direkt im Text oder in einem anderen Wiki-Artikel oder ersatzlos streichen. Schlussendlich ist es ein avr-gcc Tutorial die Beispiele sollten avr-gcc-Spezifisches erläutern und den manchmal etwas "trockenen" Text auflockern. Wie man einzelne Komponenten des AVR ansteuert hat nur in seltenen Fällen mit der Impementierungssprache zu tun. Hier vor allem dann, wenn die avr-libc entsprechende "APIs" zur Verfügung stellt. Alles Andere gehört eigentlich in ein "sprachunabhängiges" AVR-Tutorial. Das avr-gcc Tutorial "schleppt" mein Meinung in dieser Hinsicht noch einige Altlasten mit. Benutzer:mthomas

Also ich habe das Tut durchgearbeitet und alle mir auffallenden Fehler korrigiert. Man hat da sofort bemerkt, von wo an die Texte von dir geschrieben wurden, da die Kommafehler schlagartig aufhörten ;) Da sind auch ein paar Formulierungen, die ich persönlich nicht so passend finde ("voll krass"), die wollte ich aber nicht ändern, da das hier eher dein Baby ist, es sei denn, du hast nichts dagegen, dass man da etwas rumbastelt. Will dir hier nicht dazwischenpfuschen und deine Pläne durcheinander bringen. --Oxygene 02:21, 15. Nov 2004 (CET)

Habe in naechster Zeit nicht vor, an dem Tut. weiterzuarbeiten. Vielleicht dann am ehesten im Abschnitt "Assembler/C mixed-language". Mach' was du fuer richtig haellst. Go ahead. Wird sich schon alles "ergeben". --mt


Aufteilung in Kapitel

Ich habe das Tutorial mal auf kleinere Unterkapitel aufgeteilt. Das ist IMHO

  • übersichtlicher
  • modemfreundlicher
  • einladender (ein Monsterartikel schreckt ab)

Einziger Nachteil: Das Inhaltsverzeichnis muss manuell auf dem neuesten Stand gehalten werden.

Vorhin im Chat wurde mir geraten, vorher zu fragen. Daran hab ich leider nicht gedacht, also hole ich das jetzt nach. ;-) --Chris (unregistriert) 17:42, 23. Apr 2005 (CEST)

Prima, das ";-)". Ist man mal einen Tag nicht in dem Chat, schon wird gefuhrwerkt. Kurz: dagegen. Lang: Es gab vorher schon ein uebersichtliches Inhaltsverzeichnis. Modemfreundlicher - na ja, ich bin von zu Hause auch ueber Modem/ISDN "drin", so gross ist der Text nun auch wieder nicht, ich habe von zu Hause gelegentlich Kleinigkeiten korrigiert ohne das mich die Geschwindigkeit gestoert hat. De facto wird "Seite speichern" auf die lokale Platte und danach offline durchlesen fuer Modemnutzer (non-flatrater) ohnehin die uebliche Vorgehensweise gewesen sein. Gelesen wird der Artikel um ein vielfaches mehr als bearbeitet. Nun heisst es, x-mal "Seite speichern" und danach durch die gespeicherten html-Seiten wurschteln. Einladend: mag sein, ist subjektiv. Es war fuer mich einfacher, ueber den ganzen Artikel drueberzuschauen, eventuell zu verweisen, zu verschieben oder eine neues Kapitel dazuzwischenzuschieben. Die abschnittweise Bearbeitung war ebenfalls zumindest fuer mich gut genug. Ein Kapitel einzufuegen heisst jetzt auch, die Verlinkung ordentlich wieder zusammenzubauen und an den angeblich "einzigen Nachteil" zu denken. Der schnelle pdf-Export fuer 'Korrekturabzuege' wird jetzt zur Qual. Nun denn, entweder wieder ein langer Artikel oder ich werde mein Engagement fuer dieses Tutorial deutlich einschraenken, bzw. einen 'Fork' weiterpflegen. Aber es gibt ja noch andere Wiki-Nutzer, die Inhalt beizusteuern. Vieleicht fuehrt ja das zerrissene Tutorial dazu, dass deren Anzahl steigt. Martin Thomas (mthomas/131.246.51.xx)


Nicht so resignierend. Erstens steht in dem Wiki, dass jeder mitmachen kann (da steht nix von vorher nachfragen), zweitens kann man Aenderungen ja jederzeit rueckgaengig machen. Also, nicht (gleich?) entmutigen lassen :) Ich persoenlich finde die aufgeteilte Version praktischer. Ich kann mir einfach eine Adresse aufschreiben, wo ich gerade war - ohne dann ewig lang dort hin scrollen zu muessen, wo ich wirklich war. Ich denke auch, dass die armen Modem-Benutzer und/oder die, die nicht staendig die Moeglichkeit haben, online zu sein/gehen, immer weniger werden und man deshalb - so grob es klingen mag - auch weniger Ruecksicht auf sie zu nehmen braucht (kann man jetzt als Argument sowohl fuer als auch gegen die Aufteilung sehen..) --80.108.115.184 00:27, 24. Apr 2005 (CEST) sym

Ich find die zusammenhängende version auch besser. Zar kann jeder am wiki mitarbeiten, aber wenn es um so gro�?e umstellungen geht, sollte man zufor nachfragen, sonst kann die arbeit schnell umsonst gewesen sein. Ich winn für eine widerherstellung der zusammenhängenden Version. --84.57.135.238 11:51, 24. Apr 2005 (CEST) scout

Die �?nderung wurde jetzt also reverted, ohne ein Meinungsbild abzuwarten. Nagut. Dann bitte ich hiermit um eine offizielle Abstimmung, um diesen Sachverhalt zu klären, ohne es nach Willkür-Entscheidung (meinerseits oder von anderen) aussehen zu lassen. Ich schlage als Laufzeit 1 Woche vor, Stichtag wäre dann also der 1. Mai 2005 um 12:00.

Abstimmung über die Frage: Soll das Tutorial in Kapitel aufgeteilt werden? --Chris 12:45, 24. Apr 2005 (CEST)

Dafür:

  • Chris

Dagegen:

Der Hauptautor dieses Artikels (Martin Thomas) ist dagegen, das ist für mich Grund genug. Ich sehe auch keine gro�?en Vorteile an der Aufteilung, nur viel zusätzliche Arbeit durch das manuelle Anpassen des Inhaltsverzeichnisses. Die vor/zurück/hoch-Links erhöhen das Rauschen und tragen auch nicht gerade zur �?bersicht bei. -Andreas 15:24, 24. Apr 2005 (CEST)

Ohne jetzt zu Aufteilung/Nichtaufteilung Stellunge nehmen zu wollen und mthomas' Arbeit in Ehren, aber _das_ sehe ich nicht als Argument. Von mir sind auch schon Artikel entfernt/geloescht/etc. worden, ohne mich zu fragen. So lauft's in einem offenen wiki! --15:30, 24. Apr 2005 (CEST)sym

Man sollte sich von der Vorstellung freimachen, dass jedes Wiki nur weil es ein Wiki ist automatisch per Mehrheitsentscheidung verwaltet werden muss. Wenn jemand in einen Artikel so viel Arbeit reingesteckt hat wie Martin, dann hat seine Stimme nun mal mehr Gewicht. -Andreas 15:50, 24. Apr 2005 (CEST)

Von Mehrheitsentscheidung hab ich gar nicht gesprochen. Aus der Sicht als (potentieller) "Konsument" des Tutorials: Ich hab erstmals zu lesen angefangen, als es unterteilt war. Und mit der Zurueck-Umstellung auf die endlos lange Seite hab ich wieder das Interesse daran verloren. Schade - danke aber trotzdem fuer die Muehe. --80.108.115.184 21:36, 24. Apr 2005 (CEST)sym


Frage 2 zum Codebsp.

Hallo zusammen, ich nutze beruflich (ab und an) den IAR-Compiler für die AVRs. Nun steige ich privat in den AVR-GCC ein. Donglefrei halt 8-). Euer Tutorial ist eine echte Hilfe dabei! Super, wie die ganze Seite. Ich würde gerne auch mithelfen, will aber nicht einfach so rumeditieren. Daher erst einmal nachgefragt:

zu 16.2.2. (Programmspeicher) Wort lesen.

ptrToArray = (uint8_t*)(pgm_read_word(&pgmPointerToArray1));
// ptrToArray zeigt nun auf das erste Element des Byte-Arrays pgmPointerToArray1

1. Das Byte Array, auf das gezeigt werden soll, ist doch eigentlich pgmFooByteArray1[]. pgmPointerToArray1 ist ein Pointer. Könnte gerade Anfänger verwirren
2. ptrToArray ist eine Pointervariable, die im SRAM liegt und die in das SRAM zeigt. Sie zeigt damit NICHT auf pgmFooByteArray1[].

Mit ARV-GCC compiliert und in AVRStudio geladen, ergibt sich folgendes, wenn man die entsprechenden Variablen ins Watchfenster holt:

pgmFooByteArray1

Value [...]  /  Type const unsigned char[3]  /  Location 0x001A [FLASH]

[0] 18       /  Type const unsigned char     /  Location 0x001A [FLASH]
 
[0] 3        /  Type const unsigned char     /  Location 0x001B [FLASH]
 
[0] 70       /  Type const unsigned char     /  Location 0x001C [FLASH]

pgmPointerToArray1

Value 0x001A  /  Type const unsigned char * const /  Location 0x0018 [FLASH]
-> Value 18   /  Type const unsigned char         /  Location 0x001A [FLASH]

ptrToArray

Value 0x001A  /  Type unsigned char *  /  Location 0x0060 [SRAM]

-> Value 98   /  Type unsigned char    /  Location 0x001A [SRAM]

Man kann mit pgm_read_byte(ptrToArray+i) natürlich pgmFooByteArray1[] lesen, da nur der Wert von ptrToArray interessiert, da er im Macro wieder auf unit16_t umgecastet wird. Es wäre aber einfacher, wenn man das Resultat von pgm_read_word(&pgmPointerToArray1) in eine uint16_t einliest und diese dann an pgm_read_byte() übergibt.

Das Beispiel hat (zumindest mir am Anfang) suggeriert, dass es wirklich möglich ist, einen Pointer zu deklarieren, über den man direkt, also ohne Macros aus pgmspace.h, aus dem Flash lesen kann. "...ptrToArray zeigt nun auf das erste Element des Byte-Arrays... "

Vielleicht sollte man das etwas klarer machen. Zum Beispiel mit dem expliziten Hinweis, dass es einen solchen Pointer nicht gibt und immer Code bemüht werden mu�?, um das Flash zu lesen. Vielleicht kann man das Beispiel ja auch mit einer unit16_t Variablen, statt mit einer uint8_t * Variablen machen.

Falls erwünscht, schreibe ich es gerne um. --EdeC 19:39, 2. Sep 2005 (CEST)


Glaube, dieser Textabschnitt ist noch relativ unveraendert von mir, sorry, falls es zu unklar ist. Sinn des ganzen Abschnitts und er Beispiele ist es, zu verdeutlichen dass eben diese "direkten" Pointer (noch) nicht im funktionieren. Ja, Programmspeicherzugriff ist beim IAR-Compiler anders und v.a. einfacher. Aber das Grundprinzip und die Problematik ist wenn recht erinnert schon erlaeutert (explizit und mit etwas "Plappertext"). Vermute, die Verwirrung kommt eher durch die IAR-"Vorbelastung". Falls die Beispiele also tatsaechlich suggerieren, dass es diese Funktionalitaet gibt, bitte Aenderungsvorschlag einfach einbauen. Code aber bitte nur aendern, wenn die Beispiele falsch sind, ansonsten einfach /*Kommentare*/ und/oder ein paar zusaetzliche Beispiele einbauen. Ich habe absichtlich einige nicht-triviale Beispiele eingetragen, die "einfachen Sachen" stehen ja auch da und in vielen anderen Beispielen/Tutorials ebenfalls.

Martin Thomas


Ich finde, der Abschnitt erklärt sehr gut und verständlich! Lediglich bei dem Code-Beispiel waren IMHO ein paar Unsauberkeiten, die mich zuerst in die Wüste geschickt haben. Das hatte allerdings den positiven Effekt, da�? ich mich ziemlich drin verbissen und dadurch etliches dazu gelernt habe 8-) .

--EdeC 13:54, 10. Sep 2005 (CEST)

Fuse-Bits Ich hage mal gehört der atmega habe soetwas. Wovor schützt das genau? hann ich sie auch wieder löschen??

Stelle solche Fragen lieber im Forum. Hier ist es a) Zufall, wenn mal jemand über deine Frage stolpert und b) zerfretzelt es das Wiki. Also zu den AVR Fuses gibt es einen eigenen Artikel. Grundsätzlich dienen die Fuses dazu eine bestimmte Hardwarekonfiguration des AVR einzurichten. Wenn man dabei einen Fehler macht, ist der AVR u.U. Schrott. Daher gilt besonders bei Thema Fuses: Datenblatt sorgfältig lesen.

--Stefan 17:58, 28. Aug 2006 (CEST)

Baudraten Macros mit UL

Die Baudraten-Macros aus dem Tutorial scheinen recht populär zu sein, ich habe sie schon in mehreren Projekten gesehen. Leider funktionieren sie nur, wenn F_CPU als signed Long definiert ist. Sowohl Mfile, AVR Studio als auch mein AVR Eclipse Plugin definieren F_CPU aber als UL.

Wenn man die Formel minimal ändert, dann funktioniert es auch mit UL:

<c> /* UART-Init beim AT90S2313 */

  1. ifndef F_CPU

/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann 

  F_CPU im Makefile definiert werden, eine nochmalige Definition
  hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
  #ifndef/#endif 

  Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio 
  verwendet wird und dort eine andere, nicht zur Hardware passende 
  Taktrate eingestellt ist: Dann wird die folgende Definition 
  nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?) 
  von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
  noch nicht definiert: */
  1. warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
  2. define F_CPU 4000000UL // Systemtakt in Hz
  3. endif
  1. define BAUD 9600UL // Baudrate

// Berechnungen

  1. define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) // clever runden
  2. define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) // Reale Baudrate
  3. define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
  1. if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
 #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
  1. endif

</c>

Irgendwelche Einwände wenn ich das im Tutorial ändere?

Thomas

--> nur zu, M. Thomas

Änderungen in den EEPROM Beispielen

Die am 20.1.09 von 92.204.48.153 ergänzten Zeilen im Beispiel zu EEPROM read/write Block <c> /* 20.01.2009 ACHTUNG UNTER LINUX MIT EINIGEN AVR-LIB VERSIONEN SIND 

  eeprom_write_block(...) VERTAUSCHT. DORT MUSS ES DANN HEISSEN: */

// eeprom_write_block(eeFooByteArray1,myByteBuffer,sizeof(myByteBuffer)); // eeprom_write_block(eeFooWordArray1,myWordBuffer,sizeof(myWordBuffer)); </c> sind für mich aus dem Quellcode der avr-libc nicht nachvollziehbar. Gibt es weitere Belege (z.B. avr-libc bug-report, Diskussionen dazu in Foren/Mailinglisten)? Wie wurde die "eigene avr-lib" konfiguriert? Welche release-Version bzw. Datum des CVS Auszugs?

M. Thomas

Die Änderungen 15:16, 25. Mär. 2010 von 141.71.47.38 sind falsch und wurden daher rückgängig gemacht. In den betroffenen Beispielen werden Felder als Argumente übergeben, d.h. es darf heissen: feldname oder &feldname[0] aber nicht &feldname. Stefan 15:23, 25. Mär. 2010 (UTC)

FEHLER??? im CODE BSP?

Als ich mir das Codebeispiel zum Timer im ctc modus angeschaut kamen mir bis jetzt 2 Fragen auf die ich nicht klären konnte.

und zwar geht es um dise stelle 

 TCCR0A = (1<<WGM01); // CTC Modus
 TCCR0B |= (1<<CS01); // Prescaler 8
 // ((1000000/8)/1000) = 125
 OCR0A = 125-1;

Frage1) wo kommt das TCCR0A register her und wo kommt der WGM01 her weder oben in der Tabelle noch in meienm datenblatt hab ich sie gefunden und avrstudio meckert ebenfalls

Ich habe ein Bsp zur UART mit Transmit im trransfer modul und receive im interrupt modus geschrieben (inklusive eines ack im receive) wo soll ich es hochladen?

Abgerufen von „https://www.mikrocontroller.net/index.php?title=Diskussion:AVR-GCC-Tutorial&oldid=103033“