Hallo
Ich habe mir gerade zwei mal das AVR-GCC-Tutorial durchgelesen.
Dabei sind mir zwei Dinge aufgefallen.
1. Es wurde sehr viel Arbeit dort hineingesteckt.
2. Es ist, meiner Meinung nach, für einen Anfänger nicht brauchbar,
weil u.a. in dem Text alle möglichen Wege gleichzeitig beschrieben
werden.
Beispiel:
Der Compiler und die Standardbibliothek avr-libc werden stetig
weiterentwickelt. Einige Unterschiede, die sich im Verlauf der
Entwicklung ergeben haben, werden im Haupttext und Anhang zwar
erläutert, Anfängern sei jedoch empfohlen, die aktuellen Versionen zu
nutzen (für MS-Windows: aktuelle Version des WinAVR-Pakets; für Linux:
siehe Artikel AVR und Linux).
Meine Vorschlag:
Es wird empfohlen den neusten Compiler und die neuste Standardbibliothek
avr-libc zu verwenden. Link Windows: WinAVR-Pakets, Link Linux: AVR und
Linux
oder
Beispiel:
Um diese riesige Seite etwas überschaubarer zu gestalten, wurden einige
Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von
avr-gcc in Verbindung stehen.
Mein Vorschlag:
Ja, einfach machen und das Ersatzlos streichen.
Beispiel:
Benötigte Werkzeuge
Um eigene Programme für AVRs mittels avr-gcc/avr-libc zu erstellen und
zu testen, wird folgende Hard- und Software benötigt:
usw.
Mein Vorschlag wäre hier einen Weg genau zu beschreiben und die
anderen Lösungen als Tabelle oder als eine Art von Baumdiagramm darunter
darzustellen.
Link: http://de.wikipedia.org/wiki/Baumdiagramm
bzw.
http://upload.wikimedia.org/wikipedia/commons/a/ab/Hierarchical_clustering_diagram.png
MfG
> 2. Es ist, meiner Meinung nach, für einen Anfänger nicht brauchbar,> weil u.a. in dem Text alle möglichen Wege gleichzeitig beschrieben> werden.
Das ist interessant, aber die Beispiele kann ich dem nicht zuordnen.
Vielleicht kannst du diesen Punkt näher erläutern?
Aus Sicht eines 'häufiger am Tutorial schreibenden' kommt IMHO zu wenig
Feedback zu den Tutorials.
Der Updateprozeß ist bei mir oft so, dass ich eine Frage im Forum lese
und daraufhin überlege, ob das ins Tutorial passt, damit der nächste die
Frage nicht stellen muss. Diese Arbeitsweise kann zu einer Zerfrettelung
führen und dazu, dass das große Bild verschwimmt. Ich versuche darauf zu
achten, dass das nicht passiert.
Mehr Feedback was hilft dem Anwender (oder nicht) wäre für mich und
wahrscheinlich auch die anderen Autoren hilfreich.
Zu den konkreten Beispielen:
*1. Beispiel* und *2. Beispiel* sind IMHO Peanuts-Änderungen. Kann man
ändern, muss man nicht. Einen Mehrwert oder Schaden sehe ich bei der
Änderung nicht.
*3. Beispiel*
So ein Diagramm wäre eine gute Idee. Ich kenne deinen Stand im Thema
nicht, aber wenn du AVR-Erfahrung hast: Mach doch mal eins und stelle es
vor.
Hallo Klaus und die Anderen
Der Text ist nur dann einfach, wenn man weiß um was es geht. Ich habe
den Text meiner Frau zum lesen gegeben. Sie ist auch Ing. nur ganz
andere Fachrichtung (wobei sie aber trotzdem profundes Wissen
über Elektrotechnik hat). Also der "ideale Anfänger". Sie meine
auch, dass man ein einfaches komplettes Beispiel durchführen sollte und
danach alles andere beschreiben sollte.
Also so etwa:
1. Software und deren Installation
2. Hardware und deren Installation (USB, Programmer und Hw mit einer LED
und dem R)
3. Einstellungen an Sw und Hw
3. Sw öffnen und Programm erstellen, dass die LED blinkt.
4. Kompilieren
5. Übertragen in Hw
6. Atmel starten.
(7. Hw für neue Programmierung vorbereiten.)
8. das AVR-GCC-Tutorial
@ Stefan B. Danke für dein Mühe
Eigentlich soll die erste Programmierung eines µC mit der AVR-GCC
Toolchain im Einführungsbeispiel gezeigt werden
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Einf.C3.BChrungsbeispiel
Dein Vorschlag ist noch ein paar Stufen ausführlicher als das
Einführungsbeispiel. Ich weiss aber nicht wie man das ohne eine Art
"standardisierte" Hard- und Software machen kann.
Der eine arbeitet mit AVR Studio, der andere mit AVR Studio + WinAVR,
der andere nur mit WinAVR, der andere auf'm Mac, der andere auf Linux.
Das nur bei der Toolchain. Bei den Boards und ISP-Adaptern und der
Software dafür geht es dann weiter in den Unterschieden.
Beim Gegenstück Assembler im AVR-Tutorial ist das etwas einfacher.
Da ist der Assembler aus dem AVR Studio quasi der Standard. Und es wird
ein Atmega8-Targetboard vorgeschlagen.
Es gibt inzwischen aber auch eine Initiative das Thema mit mehr
Praxisbeispielen an "Absolute Beginner" zu vermitteln:
Absolute Beginner-AVR Steckbrettprojekte
Ich selbst versuche auf Pollin Funk-AVR-Evaluationsboard ebenfalls
einfache Praxisbeispiele mit steigender Schwierigkeit zu zeigen. Die
Anregungen für die Themen nehme ich auch aus dem Forum. Das hat den
Vorteil einer leicht zugänglichen Hardware inkl. einem (viel
gescholtenen) ISP-Programmer. Dadurch kann ich aber genauer auf die
notwendigen Schritte und zusätzlichen Verdrahtungen eingehen ohne
jedesmal das Rad neu zu erklären.
Wenn dir der learning-by-doing Weg besser liegt, kannst du auch auf die
Arduino Hardware gehen. Da gibt es sehr viele Tutorials in der Art wie
du sie beschreibst.
Ich bin etwas skeptisch, dass sich im AVR-GCC-Tutorial da kurzfristig
etwas ändern wird. Mit einem kleinen Umschreiben hier und da kann man
das nicht so einfach einrichten. Im Prinzip wäre die gesamte Struktur
kritisch zu beäugen (Wieso Bitfelder (die im restlichen Tutorial nicht
mehr erscheinen) vor Grundsätzlichem Programmaufbau? Wieso formatierte
Ausgabe (printf und sprintf) erst in Abschnitt 21? Wieso Warteschleifen
(ein reines Softwarethema) erst in 13? Wieso LCD und UART nach ADC?
usw.)
Ich kann die Einwände von Hannes nun wirklich nicht nachvollziehen,
obwohl ich selber Anfänger bin. Ich finde das Tutorial sehr gut. Was man
noch verbessern sollte, sind einführende Beschreibungen zu Linux: welche
Software brauche ich, wie konfiguriere ich diese und wie benutze ich
diese? Die Einstiegshürde ist bei Linux eben etwas höher als bei
Windows, weil die Hardwarehersteller für Linux keine komfortable, d.h.
nahezu selbsterklärende Software anbieten. Die weiterführenden Kapitel
sind davon natürlich unberührt.
Hallo Stefan B.
Hier liegt genau das Problem, dass ich sehe:
>"Ich weiss aber nicht wie man das ohne eine Art>"standardisierte" Hard- und Software machen kann."
Man sollte einfach ein Beispiel mit einer (einfachen und preiswerten)
Hardware am Anfang durchspielen.
Nicht mehr und auch nicht wenigen.
Dann ist die Frustration, die der Sohnemann gerade aufbaut,
geringer, als wenn er z.B. nach drei Tagen erst herausbekommt, dass man
mit Ponyprog nicht über USB den Chip beschreiben kann.
Ich muss zugeben, ich habe es auch nicht sofort gesehen.
(zu meiner Entschuldigung: auch andere Fachrichtung)
MFG
Geht es um den automatischen Link auf WinAVR in den Beiträgen im Forum
oder geht es um den Artikel WinAVR und Hinweise auf WinAVR in anderen
Artikeln in der Artikelsammlung?
Die Links in Beiträgen im Forum sind IMHO nicht notwendig und könnten
IMHO gestrichen werden.
Die Links in Artikeln in der Artikelsammlung... Was stört dich daran so
sehr, dass du für andere alle Hinweise auf WinAVR streichen möchtest?
Richtig, WiNAVR wird von Eric nicht mehr weiterentwickelt. Aber es ist
doch möglich, dass andere Entwickler ein herstellerunabhängiges WinAVR
wiederbeleben.
Außerdem gibt es User, die aus verschiedenen Gründen z.B. Wartung
älterer Firmware, z.B. nicht lauffähiger AVR-Toolchain-Installer auf
ihren PCs usw. ältere WINAVR Versionen verwenden.
Das in der Artikelsammlung gesammelte Wissen zu den älteren WinAVR
Versionen ist ja nicht spontan wertlos, bloss weil die Entwicklung von
WinAVR mit dem Wechsel von Eric stagniert.
Hallo Stefan,
es geht mir um die Anfänger Tutorials. Einen Anfänger sollte man sowieso
nur AVRStudio und die Toolchain von Atmel empfehlen. Mit Eclipse ist ein
Anfänger überfordert btw. wird von den Einstellungen erschlagen und wie
schon geschrieben WinAVR wird vorerst nicht weiter entwickelt, dann eher
noch MHV AVR Tools angeben.
> Einen Anfänger sollte man sowieso> nur AVRStudio und die Toolchain von Atmel empfehlen.
Nicht jeder Anfänger hat einen Windowsrechner herumstehen. Deshalb
sollte man auch an die Linuxuser denken!
So war das auch nicht gemeint, ich persönlich arbeite unter Windows und
Linux dabei ist Eclipse mein ständiger begleiter. WinAVR ist einfach
veraltet und darauf sollte man den Benutzer aufmerksam machen.
