www.mikrocontroller.net

Forum: www.mikrocontroller.net Warum ist das AVR-GCC Tutorial so bescheiden?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich habe bewusst einen recht provokanten Titel gewählt, um einerseits 
meinem Unmut kundzutun, aber gleichzeitig auch eure Aufmerksam und damit 
verbunden eure Meinung zu erhalten.

Ich bin Anfänger in Sachen uC und bin oft hier im Forum unterwegs. Dabei 
sehe ich des öfteren, dass anderen Anfängern das AVR-GCC Tutorial 
empfohlen wird. Allerdings frage ich mich:
Was findet ihr daran so gut?

Mir kommt es eher nach einem unstrukturierten Zusammenwurf von diversen 
Artikeln vor. Einen roten Pfaden, wie man ihn z.B. beim AVR-Tutorial 
findet, sehe ich hier keineswegs. Es ist ein großer, undurchsichtiger 
Dschungel in meinen Augen und ich weiß nicht, wo ich anzufangen und wie 
ich vorzugehen habe.

Jetzt habe ich es geschafft, die LEDs im AVR-GCC Tutorial zum Blinken zu 
bringen. Alles super. Beim LCD hört es dann aber auch schon wieder auf. 
Da wird anfangs auf die Pinbelegung eingegangen, was ich super finde. 
Und dann wird einfach nur noch der Code hingeklatscht und der Artikel 
ist zu ende.

Okay, denke ich mir, das LCD funktioniert einwandfrei. Ich weiß zwar 
nicht, was dort im Code passiert, aber solange es funktioniert, ist es 
schon mal was. Machst du einfach mal weiter. Aber wo? Mir fehlt im 
Tutorial nun "der nächste Schritt". Und das ist genau das, was ich mit 
roten Pfaden meine.

Ich muss sagen, dass ich persönlich das Tutorial einfach nur schlecht 
finde und nicht verstehen kann, dass es der Standardlink ist, der vielen 
Anfängern empfohlen wird.

Ich für meinen Teil wollte gerne uC in C programmieren, werde aber 
aufgrund des schlechten Tutorials auf das Assembler Tutorial umsteigen. 
Denn dort scheint wenigstens ein gewisser Lerneffekt vorhanden zu sein.

So, nachdem ich jetzt die ganze Zeit gemeckert habe, würde ich gerne 
euch um eure Meinung bitten:

Seht ihr das nicht so? Seid ihr wirklich der Meinung, dass das AVR-GCC 
Tutorial gut für Anfänger geeignet ist?

Versteht es nicht falsch. Ich bin kein Troll, der einfach nur 
rumstänkern möchte. Vielmehr interessiert mich eure Meinung und eure 
Ansicht, denn es kann gut sein, dass das Tutorial einfach nur auf meine 
Bedürfnisse nicht passt. Solltet ihr das Tutorial gut finden, so 
schreibt bitte auch was genau ihr daran gut findet. Vielleicht sind dort 
Aspekte dabei, die ich bis jetzt noch gar nicht beachtet habe.

Ich möchte aber auch Lob aussprechen, dass es diese beiden Tutorials 
überhaupt gibt. Auch wenn ich mich mit dem AVR-GCC Tutorial anfreunden 
kann, ist es meiner Meinung nach eine große Leistung, sowas überhaupt 
auf die Beine zu stellen. Und dass sowas viel Zeit in Anspruch nimmt, 
versteht sich von selbst.


Ich bedanke mich für eure Rückmeldung.

Gruß,
uCAnfänger

16.04.2012 10:35: Verschoben durch Moderator
Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich weiß nicht, wo ich anzufangen [..] habe.

Datenplatt lesen ist immer ein guter Anfang. Danach dann besagtes 
Tutorial vor Anfang bis Ende.

> Ich weiß zwar nicht, was dort im Code passiert [..]

Reinschauen (und vorzugsweise auch verstehen), dann weisst Du es.

> Machst du einfach mal weiter. Aber wo?

Mit Datenplatt lesen. Das ist unumgänglich um den Code vollständig zu 
verstehen.

> Seid ihr wirklich der Meinung, dass das AVR-GCC Tutorial gut für Anfänger
> geeignet ist?

Ja. Vorzugsweise nach dem Studium der relevanten Datenplätter, denn die 
Lösungen zu grob 99% aller (nicht-nur-Anfänger-)Probleme stehen in 
ebendiesen.

HTH und nix für ungut

Autor: Christian Kreuzer (christian_rx7) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Anfänger.

Ich kann deinen Frust irgendwie nachvollziehen, mir ging es damals nicht 
anders, egal was ich über C gelesen habe, es war unverständlich und 
kompliziert. Daher hab ich dann mit BASCOM begonnen, so jetzt werden 
hier wieder alle über mich herfallen.
Nach dem ich Bascom und C# gelernt habe, wollte ich mir wieder mal C 
ansehen und ich verstehe das Tutorium noch immer nicht wirklich, da wie 
du sagst, der rote Faden fehlt.
Schau dir mal diese Tutorium an: 
http://www.rn-wissen.de/index.php/C-Tutorial
da sind viele Grundlagen und Grundbefehle gut erklärt.

Christian

Autor: SNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas Transferwissen ist immer gefordert.
Wenn ein Link auf ein Datenblatt eines Standard-LCD da ist,wäre es in 
meinen Augen in Ordnung. Da steht dann nämlich der Ablauf der 
Initialisierungsroutine drin.

Vorher beim LED Beispiel hat man ja gelernt wie man einen Pin setzt bzw. 
löscht. Also hat man prinzipiell sämtliches Wissen was man für ein LCD 
braucht.

Wenn DU später einen IC verwendest wirst Du auch in den seltesten Fällen 
genau dass bekommen was Du brauchst.

Grüße

P.S.:Ich habe auch hier mit dem Tutorial angefangen.Man bekommt in 
meinen Augen gut die Grundlagen erklärt. Für alles andere ist 
Eigeninitiative gefragt. Und wenn das nicht klappt kann man ja im Forum 
suchen/nachfragen.

Autor: SNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so...prinzipiell spricht nichts dagegen dass Du das Tutorial ergänzt 
;-)

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo g457,
danke für deinen Beitrag. Ich glaube zu wissen, worauf du hinaus 
möchtest. Allerdings denke ich, dass wir unterschiedliche Ansichten 
vertreten.
g457 schrieb:
> Datenplatt lesen ist immer ein guter Anfang. Danach dann besagtes
> Tutorial vor Anfang bis Ende.
Ich gebe dir vollkommen recht, dass man das Datenblatt zu lesen hat. Und 
das tue ich auch so gut es geht. Dein zweiter Satz ist doch genau das, 
was ich am Tutorial kritisiere. Es gibt keinen wirklichen Anfang und 
kein wirkliches Ende. Es ist ein wilder Mix ohne roten Faden. Ja, es 
stehen viele Informationen drinnen, aber die Verarbeitung ist schwer, 
weil es ein Durcheinander ist in meinen Augen.


>> Ich weiß zwar nicht, was dort im Code passiert [..]
>
> Reinschauen (und vorzugsweise auch verstehen), dann weisst Du es.
Danke für den Tipp. Darauf wäre ich nicht gekommen. Jemand, der viel 
Erfahrung in C sammeln konnte, wird weniger Probleme haben, sich durch 
den Code durchzuhangeln. Aber hast du dir schon mal überlegt, dass es 
enorm schwer für einen Anfänger sein kann, fremden und wenig 
kommentierten Code zu verstehen? Dieses "aha, das hat sich der Autor 
dabei gedacht", ist doch kaum gegeben.
>> Machst du einfach mal weiter. Aber wo?
>
> Mit Datenplatt lesen. Das ist unumgänglich um den Code vollständig zu
> verstehen.
Welches Datenblatt denn? Der von dir zitierte Satz scheint falsch 
rübergekommen zu sein. Ich wollte damit ausdrücken:
"Nimmst mal das LCD als gegeben an. Nun machste den nächsten Schritt und 
schaust, was du mit dem uC noch so anstellen kannst".

Und deine Antwort darauf ist:
"Mit Datenblatt lesen"

:(

> Ja. Vorzugsweise nach dem Studium der relevanten Datenplätter, denn die
> Lösungen zu grob 99% aller (nicht-nur-Anfänger-)Probleme stehen in
> ebendiesen.

Du scheinst meinen Beitrag nicht wirklich gelesen zu haben. Ich 
kritisierte, dass das Tutorial ein wildes Durcheinander ist, bei dem man 
schwer den Überblick (im Sinne von Einstieg in uC, Was kann man damit 
machen, was gibt es, wie geht es) behalten kann.

Trotzdem möchte ich dir für deinen Beitrag und deine Zeit danken - auch 
wenn ich deine Ansicht nicht wirklich teile.


Gruß

Autor: Jojo S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es gibt darüber ja noch das AVR-Tutorial, da ist das LCD zB. auch 
ausführlich beschrieben. Ist zwar zum Teil Assembler, aber die LCD 
Kommandos sind ja trotzdem gleich.
Dann gibt es eben verschiedene Kapitel die nicht unbedingt etwas 
miteinander zu tun haben, wie ADC, PWM oder Servo Ansteuerung. Kommt 
halt darauf an was man letztendlich machen möchte und welche Komponenten 
man braucht.

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um sich Grundlegend mit C vertraut zu machen oder etwas nachzuschlagen, 
gibt es z.B. auch
http://de.wikibooks.org/wiki/C-Programmierung

Autor: Markus Weber (Firma: guloshop.de) (m-w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SNR schrieb:
> Ach so...prinzipiell spricht nichts dagegen dass Du das Tutorial ergänzt
> ;-)

Eben, es ist ein Wiki, und Wikis sind von allen für alle. :-)

Am leichtesten versteht man das GCC-Tutorial übrigens, wenn man vorher 
das normale AVR-Tutorial durchgearbeitet hat. Das setzt auf Assembler 
auf, damit lernt man die Hardware am besten kennen.

Und als Ersatz für einen C-Lehrgang ist das AVR-GCC-Tutorial sowieso 
nicht gedacht. Man sollte C schon wirklich können, bevor man sich an 
dieses Tutorial macht. Viele Fragen, die hier im Forum auftauchen, 
zeigen, dass es nicht am Verständnis für Mikrocontroller mangelt, 
sondern dass grundlegende C-Kenntnisse fehlen. Da betrifft insbesondre 
die Bitmanipulation, zum Beipiel
a|= 0xf0;
b&= ~0x06;
Auch Datentypen wie int8_t, uint8_t, uint16_t usw. sollten einem schon 
geläufig sein, bevor man sich in dieses Abenteuer stürzt!

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi SNR,

danke für deinen (vorigen) Beitrag. Ich gebe dir prinzipiell recht mit 
dem Transferwissen.

SNR schrieb:
> Ach so...prinzipiell spricht nichts dagegen dass Du das Tutorial ergänzt
> ;-)

Würde ich sehr gerne machen. Das setzt aber voraus, dass ich verstehe, 
was ich da eigentlich mache. Und daran scheitert es im Endeffekt. Da 
haben wir das Henne-Ei-Problem :D

Gruß

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage, die sich mir stellt ist: Wen willst du ansprechen?

Da das Tutorial eine kollaborative Angelegenheit ist und keinen 
spezifischen Autor (wie z.B. ein Buch) hat, kannst du schon mal 
niemanden direkt ansprechen.

Deine Möglichkeiten an der Stelle sind: Stelle heraus, was schlecht ist. 
Schreibe das auf, stelle das hier zur Verfügung. Erkläre, was du anders 
machen würdest. Das nennt man dann Feedback und könnte dazu führen, dass 
die Community (as in: irgendjemand) diese Verbesserungsvorschläge 
einarbeitet.

Die zweite Möglichkeit ist, dass du die Änderung selbst vornimmst.

Autor: Jojo S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:
>>> Ich weiß zwar nicht, was dort im Code passiert [..]

>> Reinschauen (und vorzugsweise auch verstehen), dann weisst Du es.
>
> Danke für den Tipp. Darauf wäre ich nicht gekommen. Jemand, der viel
> Erfahrung in C sammeln konnte, wird weniger Probleme haben, sich durch
> den Code durchzuhangeln. Aber hast du dir schon mal überlegt, dass es
> enorm schwer für einen Anfänger sein kann, fremden und wenig
> kommentierten Code zu verstehen? Dieses "aha, das hat sich der Autor

also gerade im zitierten LCD Code ist nahezu jede Zeile kommentiert, 
noch mehr Prosa darin und man findet den Code darin nicht wieder.

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Am leichtesten versteht man das GCC-Tutorial übrigens, wenn man vorher
> das normale AVR-Tutorial durchgearbeitet hat. Das setzt auf Assembler
> auf, damit lernt man die Hardware am besten kennen.
Ich glaube, dass ich das auch tun werde. Eigentlich wollte ich Assembler 
meiden, weil ich da schon eher mit C vertraut bin. Sprich, ich müsste 
mir die ganzen Assembler Befehle aneignen.

> Und als Ersatz für einen C-Lehrgang ist das AVR-GCC-Tutorial sowieso
> nicht gedacht.
Mir geht es auch nicht um die Programmiersprache C. Ich beherrsche C 
grundlegend insofern, als dass ich Bits manipulieren, Funktionen 
schreiben, if-else und for-Schleifen implementieren kann. Ich habe 
Erfahrungen im Programmieren in C# und Matlab, das Wissen übertrage ich 
auf C (ja, ich muss zwar noch einiges nachlesen). Aber trotzdem finde 
ich es extrem schwer, einen fremden Code zu verstehen, wenn er m.E. 
nicht sehr gut kommentiert ist.


Aber danke für deinen Tipp mit dem richtigen Tutorial. Ich glaube auch, 
dass ich das Tutorial mit Assembler durcharbeiten werde. Und wenn ich 
dann verstehe, wie das alles funktioniert, werde ich mir ggf. noch mal 
das Gegenstück zu C anschauen.

Danke und Gruß

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Simon,

Simon K. schrieb:
> Die Frage, die sich mir stellt ist: Wen willst du ansprechen?
euch. Dich, die anderen Leute hier, das gesamte Forum.
> Da das Tutorial eine kollaborative Angelegenheit ist und keinen
> spezifischen Autor (wie z.B. ein Buch) hat, kannst du schon mal
> niemanden direkt ansprechen.
Dessen bin ich mir bewusst.
> Deine Möglichkeiten an der Stelle sind: Stelle heraus, was schlecht ist.
> Schreibe das auf, stelle das hier zur Verfügung. Erkläre, was du anders
> machen würdest. Das nennt man dann Feedback und könnte dazu führen, dass
> die Community (as in: irgendjemand) diese Verbesserungsvorschläge
> einarbeitet.
>
> Die zweite Möglichkeit ist, dass du die Änderung selbst vornimmst.

Richtig.

Mir geht es schlichtweg um eure Meinungen zu diesem Tutorial. Ob ich der 
einzige bin, der die aufgelisteten Aspekte so sieht oder nicht. Wenn ihr 
alle sagt, dass ihr das Tutorial super findet, und dann auch noch 
Argumente nennen könnt, die das untermauern, dann entwickle ich 
vielleicht eine ganz andere Sichtweise zu diesem Tutorial. Auch das wäre 
doch ein gutes Ergebnis, meinst du nicht?


Gruß

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nach dem ich Bascom und C# gelernt habe, wollte ich mir wieder mal C
> ansehen und ich verstehe das Tutorium noch immer nicht wirklich, da wie
> du sagst, der rote Faden fehlt.

Das Problem bei diesen Sachen ist das ein gutes Produkt mit viel Arbeit 
verbunden ist und vom Schreiber auch Erfahrung braucht. Daher erwarten 
die normalerweise Geld fuer ihre Diensleistung und verkaufen sie als 
Buch. Zum lernen, gerade fuer Anfaenger, sind Internetseiten immer die 
zweite Wahl. Ausnahmen mag es geben, aber das sind dann halt auch 
Ausnahmen.

Bei C ist es aber sogar noch schlimmer. Die Sprache laesst dir jede 
Freiheit. Gerade zu Anfang braucht es da nicht nur ein Buch sondern auch 
jemand der dir auf die Finger haut wenn du Murks&Pfusch codest.

Olaf

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um Missverständnisse zu vermeiden:

Das AVR-GCC-Tutorial ist kein C-Tutorial (wie bspw. das von Christian
empfohlene http://www.rn-wissen.de/index.php/C-Tutorial), sondern ein
Tutorial zu den speziellen Eigenschaften des AVR-GCC.

Wer das Tutorial durcharbeiten möchte, sollte also schon einigermaßen
gut in C programmieren können (s. auch Kapitel "Voraussetzungen") und
eine groben Vorstellung darüber haben, was ein Mikrocotroller tut.

Zum Tutorial selbst:

Da sich die AVR- und AVR-GCC-spezifischen Eigenschaften immer nur auf
einzelne Aspekte und nicht auf den µC oder die C-Programmierung als
Ganzes beziehen, kann es keinen vom Anfang bis zum Ende durchgehenden
roten Faden geben.

Man sollte die einzelnen Kapitel eher als eine Sammlung von Application-
Notes sehen, die aber — und darin unterscheidet sie sich wesentlich von
den Appnote-Bibliotheken der µC-Hersteller — in ein einer sinnvollen
Lesereihenfolge vorsortiert sind.

Ich muss zugeben, dass ich das AVR-GCC-Tutorial nie komplett durchgele-
sen habe und deswegen zur seiner Qualität im Detail nicht viel sagen
kann. Zumindest die Gliederung halte ich aber für gut gelungen. Wenn es
innerhalb der einzelnen Kapitel zu Verständnisschwierigkeiten kommt,
deren Struktur verbesserungswürdig erscheint oder schlichtweg wichtige
Informationen fehlen, sollte das auf der Diskussionsseite besprochen
werden.

Da die Autoren des Tutorials nicht ständig auf der Diskussionsseite nach
neuen Beiträgen Ausschau halten, könnt ihr gerne eine Ankündigung der
gewünschten Diskussion mit einem Link auf die Diskussionsseite ins
GCC-Forum setzen, das von sehr viel mehr Leuten gelesen wird.

Schön wäre es, wenn gerade auch fortgeschrittene Anfänger, die für ihre
ersten Gehversuche das Tutorial zu Hilfe genommen haben, sich aktiv an
der Gestaltung und Erweiterung desselben beteiligen. Denn es sind genau
diese Leute, die aus eigener Erfahrung am besten wissen, wo noch eventu-
elle Mängel liegen.

Größere Änderungen sollten aber immer von einer Diskussion begleitet
werden, da sich sonst die Originalautoren, die viel Arbeit in die
Beiträge gesteckt haben, evtl. übergangen fühlen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:

> Was findet ihr daran so gut?

Wirklich gut finde ich es nicht.

> Mir kommt es eher nach einem unstrukturierten Zusammenwurf von
> diversen Artikeln vor.

Ursprünglich war es ein riiiiesen Bandwurm-Artikel. Einzelne 
Unterartikel wie "UART" oder "Analoge Ein- und Ausgabe", die nichts 
speziell mit avr-gcc zu tun haben, wirden bereits ausgelagert, um den 
riesen Monster-Artikel abzuspecken.

Meiner Meinung nach ist der Artikel viel zu groß und suggeriert, daß 
ungleublich viel zu lernen ist, was aber garnicht der Fall ist!

Kann man bereits C — was im Artikel vorausgesetzt wird — dann ist es 
garnicht viel, was man für avr-gcc braucht:

- Ein generelles Verständnis, wie eine GCC-Toolchain tickt.
- Nicht-Standard Erweiterungen wie ISRs
- Wie man auf SFRs zugreift. Standard-C und mit den AVR-Libc-Headern
  trivial dennoch weden tausende von Zeilen geschrieben.

Das ist schon alles. Zugriff aus den Flash ist eine reine 
Optimierungsangelegenheit! Das könnte in einem 
Fortgeschrittenen-Abschnitt stehen. Und auch hier ist das, was dasteht, 
viel zu aufgeblasen.

> Es ist ein großer, undurchsichtiger Dschungel in meinen Augen und
> ich weiß nicht, wo ich anzufangen und wie ich vorzugehen habe.

Wo es für dich weitergeht hängt auch davon ab, was dich als nächstes 
interessiert und wo noch Lernbedarf besteht.

Alles von vorne bis hinten durchzulesen ist IMO nicht so sinnvoll; eher 
einen Überblich verschaffen und dann die entsprechenden Abschnitte 
lesen.

> Ich muss sagen, dass ich persönlich das Tutorial einfach nur schlecht
> finde und nicht verstehen kann, dass es der Standardlink ist, der vielen
> Anfängern empfohlen wird. [...]

> Seht ihr das nicht so? Seid ihr wirklich der Meinung, dass das AVR-GCC
> Tutorial gut für Anfänger geeignet ist?

Teile sind einfach zu aufgeblasen oder einfach schlecht.

Direkt am Anfang zentnerweise kryptische Makefile-Schnippsel find ich 
zum beispiel extrem ungünstig und abschreckend.

Ein Problem bei dem Tutorial ist, daß jeder Autor einen anderen 
Schwerpunkt hat und oft möglichst ausführlich und breit darüber 
geschrieben wird.

Den Text zu straffen und unnötigen Kladderaddatsch rauszuwerden, 
passiert praktisch nie oder es traut sich niemand.

Autor: Krapao (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit paar Monaten habe keinen Überblick mehr über das 
AVR-GCC-Tutorial, weil es inzwischen so groß ist, dass es beim 
Aufruf in meinem Webbrowser zu Problemen kommt.

Daher arbeite ich, im Gegensatz zu früher, selten aktiv daran. 
Gelegentlich checke ich Überarbeitungen und greife bei Vandalismus ein.

Ich empfehle das Tutorial nur noch, wenn ich keinen Link direkt in der 
avr-libc Doku geben kann und von früher weiss, dass eine Frage im 
Tutorial beantwortet ist.

Das Tutorial selbst kämpft mit dem Problem, dass es an Feedback fehlt. 
Das Tutorial wurde damals(TM) von Lernenden für andere Lernende 
geschrieben.

Inzwischen sind die damaligen Lernenden vom Wissen her weiter, können 
sich schlecht in die Anfängersituation versetzen, und neue Lernende 
stellen keine Fragen. Man hat sich auseinander gelebt.

Das Tutorial ist einem Nachschlagewerk/Referenzhandbuch gewichen. Es 
steht im Prinzip alles haarklein drin, aber es taugt nicht als Lehrbuch.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Danach dann besagtes Tutorial vor Anfang bis Ende.
>
> Es gibt keinen wirklichen Anfang und kein wirkliches Ende. Es ist ein
> wilder Mix ohne roten Faden.

Ich finde das Tutorial schön linear. Alles wichtige ist auf einer Seite 
zusammengefasst, die kann man schön von oben bis unten durchlesen. Für 
einige spezielle Themen gibt es einige spezielle Seiten zur Vertiefung.

> fremden und wenig kommentierten Code zu verstehen?

Gerade den Code zur LCD-Ansteuerung finde ich hervorragend kommentiert. 
Wer den Code nicht versteht (oder besser: fragt, 'warum zum Geier macht 
der das?') sollte ∗dringend∗ ins Datenplatt kucken. Code kann (und soll) 
keine Reproduktion des Datenplatts sein. Und das Tutorial kann (und 
soll) das Datenplatt nicht ersetzten.

> Ich wollte damit ausdrücken: "Nimmst mal das LCD als gegeben an. Nun
> machste den nächsten Schritt und schaust, was du mit dem uC noch so
> anstellen kannst".

..alles was so im Datenplatt steht :-) Und wenn die Kreativität dafür 
nix hergibt, dann eben im nächsten Kapitel im Tutorial lesen was andere 
so anstellen damit :-)

Nix für ungut

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Olaf, Hi Yalu,

Olaf schrieb:
> Das Problem bei diesen Sachen ist das ein gutes Produkt mit viel Arbeit
> verbunden ist und vom Schreiber auch Erfahrung braucht. Daher erwarten
> die normalerweise Geld fuer ihre Diensleistung und verkaufen sie als
> Buch. Zum lernen, gerade fuer Anfaenger, sind Internetseiten immer die
> zweite Wahl. Ausnahmen mag es geben, aber das sind dann halt auch
> Ausnahmen.
Du hast recht, Olaf. Wer möchte sich schon für umsonst die Mühe machen. 
Und das hatte ich anfangs auch erwähnt, dass ich es grundsätzlich sehr 
zu schätzen wisse, dass sich jemand Mühe damit gemacht hat und das 
Tutorial gratis zur Verfügung stellt (okay, hier sind mehrere Köche am 
Werk. Der Dank und die Anerkennung gilt also allen gleichermaßen).

Yalu X. schrieb:
> Um Missverständnisse zu vermeiden:
>
> Das AVR-GCC-Tutorial ist kein C-Tutorial (wie bspw. das von Christian
> empfohlene http://www.rn-wissen.de/index.php/C-Tutorial), sondern ein
> Tutorial zu den speziellen Eigenschaften des AVR-GCC.
Mir geht es auch nicht um die Sprache C an sich, wie bereits erwähnt. 
Klar, ich beherrsche C nicht im Schlaf und habe dort noch einiges 
aufzuholen/neu zu lernen, aber grundlegendes Verständnis in Sachen for, 
if, while etc. sind vorhanden. Und C als Programmiersprache ist auch 
noch mal ein klein wenig anders als diese Bitschubserei, die einen sehr 
großen Teil bei uC einnimmt. Worauf ich hinaus will: C zu beherrschen 
ist sehr wichtig. Aber damit automatisch uC programmieren zu können ist 
in meinen Augen wiederum ein anderes Paar Schuhe.

> Zum Tutorial selbst:
>
> Da sich die AVR- und AVR-GCC-spezifischen Eigenschaften immer nur auf
> einzelne Aspekte und nicht auf den µC oder die C-Programmierung als
> Ganzes beziehen, kann es keinen vom Anfang bis zum Ende durchgehenden
> roten Faden geben.
Seien wir doch mal ehrlich:
Wenn man wirklich neu auf einem Gebiet ist und sich mit der Materie 
auseinander setzt, dann muss es doch irgendwo den Startpunkt geben. Bei 
uC ist es doch genau so, weshalb man mit der benötigten Hard- und 
Software anfängt.
Nun weiß der Beginner, was er vor sich aufm Tisch zu liegen hat, wie er 
den uC an den Computer anschließt. Ohne viel Theorie im Vorfeld will er 
doch erstmal die LED zum Blinken bekommen und dabei verstehen, wie das 
mit den Ports etc. funktioniert. Dann könnte man doch im nächsten 
Schritt einen Taster reinbringen, um so auf die Aspekte der Interrupts 
einzugehen. Im nächsten Schritt könnte man dann auf das Display eingehen 
(und auch hier wieder die gleiche Argumentation wie ständig: Schlichtweg 
den mehr oder weniger gut kommentierten Code zeigen und dann ist das 
Kapitel damit zu ende, das hat doch keinen Lerneffekt). Im Assembler 
Tutorial wird auch auf den Code eingegangen und erklärt, was man sich 
dabei gedacht hat. Mir geht es im Prinzip einfach nur um dieses "Was hat 
sich der Autor dabei gedacht, als er den Code so hingeschrieben hat. 
Welchen Zweck, wieso weshalb warum?" Und ein Kommentar wie
// Maske setzen
 in einer Funktion bringt mir jedenfalls nichts. Wie gesagt, das "Wieso, 
weshalb, warum" fehlt mir.
> Man sollte die einzelnen Kapitel eher als eine Sammlung von Application-
> Notes sehen, die aber — und darin unterscheidet sie sich wesentlich von
> den Appnote-Bibliotheken der µC-Hersteller — in ein einer sinnvollen
> Lesereihenfolge vorsortiert sind.
Okay, dann habe ich falsche Vorstellungen von dem Tutorial gehabt. Ich 
hatte es in der Tat wie das AVR-Tutorial als eine Art Hands-On Variante 
zum Erlernen von uC verstanden. Das ist doch schon mal eine Aussage, die 
mich zum Nachdenken anregt, meine Sichtweisen ggf. umzulenken.

Ich glaube, dass es wirklich eine gute Idee ist, wenn ich mich mit dem 
Assembler AVR Tutorial beschäftige. Das entspricht mehr meinen 
Interessen und wenn ich die jeweiligen Kapitel verinnerlicht habe, kann 
ich ja immer noch versuchen das in C umzusetzen. Hat auch den positiven 
Nebeneffekt, dass ich mich gezwungenermaßen mit Assembler beschäftigen 
muss. Wohl ein Kompromiss, mit dem ich leben kann :)

Alles in allem finde ich die Diskussion sehr gut. Sie zeigt, dass ich 
grundsätzlich nicht alleine mit meiner Meinung dastehe. Sie zeigt aber 
auch, dass es zu einfach ist "die Schuld auf andere zu schieben" und 
mehr Eigeninitiative zu entwickeln ist. Letztendlich hat die Diskussion 
dazu beigetragen, dass ich ein falsches Bild von dem Tutorial hatte. 
Tutorials, die ich sonst so kenne, bringen einem die Materie näher und 
dort ist auch ein roter Faden vorhanden. Soll heißen, man fängt irgendwo 
an und hört irgendwo auf. Dazwischen geht es Schritt für Schritt weiter. 
So wie ich dieses "AVR-GCC Tutorial" hier sehe, scheint es eher eine Art 
Kochbuch zu sein. Da sind verschiedene Themen vorhanden und je nachdem 
was man wissen möchte, sucht man sich zurecht.

Ich finde nicht, dass es dann noch einem Tutorial gerecht wird. Aber 
darüber mag sich jeder sein eigenes Urteil bilden.

Ich bedanke mich jedenfalls bei euch für eure Rückmeldungen. Wieder 
einmal habe ich etwas Neues dazugelernt :D

Gruß

Autor: cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:

> Klar, ich beherrsche C nicht im Schlaf und habe dort noch einiges
> aufzuholen/neu zu lernen, aber grundlegendes Verständnis in Sachen for,
> if, while etc. sind vorhanden. Und C als Programmiersprache ist auch
> noch mal ein klein wenig anders als diese Bitschubserei, die einen sehr
> großen Teil bei uC einnimmt.

Ein paar for oder while Konstrukte machen die Sprache nicht aus. Und 
solange Bitmanipulation, Masken, Pointer usw. ein Problem für dich 
darstellen, solange kannst du einfach kein C, da musst du mehr ran. Das 
kannst du aber auch gleich mit dem AVR-GCC lernen, das muss nicht 
getrennt sein. Aber diese Bitschubserei gehört nicht nur in die µC welt. 
Es reicht nicht, oberflächlich ein paar syntaktische Gebilde zu 
verstehen, ein echtes Verständniss für die Sprache und die 
Programmierung an sich muss sich einstellen. Das wird oft unterschätzt. 
Das beherrschen einer Programmiersprache ist nur der erste Schritt zur 
Programmierung bzw. gar der SW Entwicklung. Das dauert und braucht übung 
übung übung und du scheinst zu ungeduldig zu sein.
Du kannst zwar lesen und schreiben, aber kannst du deshalb automatisch 
Bestseller oder Gedichte schreiben? Und du bist grade mal in der 3. 
Klasse mit deinen "Schreibkünsten", also erwarte nicht dass du morgen 
Goethe überholst.

> Worauf ich hinaus will: C zu beherrschen
> ist sehr wichtig. Aber damit automatisch uC programmieren zu können ist
> in meinen Augen wiederum ein anderes Paar Schuhe.
Das ist richtig, aber wenn du C wirklich gut beherrschen würdest, würden 
sich deine µC Probleme rein auf den µC und seine Eigenheiten 
beschränken. So musst du an zwei Fronten ran.

gruß cyblord

Autor: Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich fasse mal zusammen.
Gibt es Fragen zu C im Forum wird auf das AVR-GCC-Tutorial verwiesen.
In diesem Thread wird aber gesagt, das AVR-GCC-Tutorial ist nur für 
erfahrene C-Programmierer gedacht.
Ein schönes Ringelspiel.
Haben hier eigentlich einige Leute Angst ihr Wissen weiterzugeben und 
anderen zu helfen?

Autor: Krapao (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, da musst du die Leute fragen, die das Tutorial für allgemeine C 
Fragen empfehlen.

IMHO wäre eine solche Empfehlung falsch zumal bereits im Anfang des 
Tutorials steht, dass man bereits C können sollte und das Tutorial nur 
die AVR typischen Dinge erläutern will.

> Haben hier eigentlich einige Leute Angst ihr Wissen weiterzugeben und
> anderen zu helfen?

Das ist eine Provokation oder eine Frechheit. Es gibt viele Leute hier, 
die bereitwillig und selbstlos Wissen weitergeben.

Autor: Siebzehn mal Fuenfzehn (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also. Es macht Sinn sich erst mal in den ASM einzuarbeiten, denn machher 
weiss man, wie ein controller funktioniert. C is etwas wie ein 
verbesserter Makro-Assembler. Dh man nimmt C wenn man es leid ist sich 
immer um 16bit Zugriffe von Hand kuemmern zu muessen. Oder wenn man die 
ampassungen Jump laengen selbst machen muss. Dann ist C ein kleiner 
Schritt und bringt sofort Ergebnisse.

Autor: Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Krapao:

Ich spreche von denen, Die bei Fragen zur C-Programmierung auf das 
AVR-GCC-Tutorial verweisen. Das ist keine Hilfe.
Im übrigen habe ich die Worte Provokation und  Frechheit überlesen!!

Autor: Heinz L. (ducttape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, nehmen wir mal an jemand will das Tutorial verbessern. Was soll er 
tun? Ich hätte durchaus einige Ideen wie man das Ganze "verdaulicher" 
gestalten kann (beispielsweise durch Aufteilung in Kapitel wie das auch 
beim ASM-Tut der Fall ist, welches ich persönlich exzellent fand). 
Überhaupt denke ich es wäre eine Idee das C-Tut an das ASM-Tut 
anzulehnen und die gleichen Themen in gleichen Kapiteln behandeln.

Was mir absolut und überhaupt fehlt (und zwar in beiden Tuts) ist ein 
"und wo such ich den Fehler wenn's nicht geht" Abschnitt. Grad als 
Anfänger kennt man's recht gut. Man macht's wie im Tut, also... so gut 
es eben geht (weil grad DEN Widerstand hat man nicht, oder grad DEN 
MC...)... und dann fragt man sich: Hab ich Murks gebaut? Hab ich mich 
vertippt? Geht's mit dem Widerstand/MC halt nicht? Wieviel Zeit ich 
damals versch... hab um die serielle Schnittstelle zum Laufen zu 
bringen, ein Hinweis drauf mal pins 11 und 12 am Max232 kurzzuschließen 
und zu gucken ob das Terminalprogramm mit sich selbst reden kann hätt 
geholfen eine Fehlerquelle auszuschließen. Darauf bin ich halt dann auch 
nicht gekommen. Ich glaub hier kann man vielen Neulingen viel Frust 
ersparen.

Und ja, wenn's gewünscht wird schreib ich's gern. Allerdings: Wo? Wie? 
Was darf ich... Ich bin nicht unbedingt 'n großer Wiki-Schreiber.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr redet alle um den heißen Brei.
Was ist mal mit ner konkreten Aussage? Irgend eine Liste, mit der man 
überhaupt irgendwie arbeiten kann.
Die Liste kann man ja durchaus auf der Diskussionsseite des Artikels 
zusammenstellen.

Sich einfach nur hier sammeln und den Frust von der Seele reden bringt 
niemandem Etwas.

Autor: Gert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um C zu erlernen finde ich den Videokurs gut
http://et-tutorials.de/mikrocontroller

Autor: Prüfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verstehe das mit de Tutorials jetzt so:
Ihr wollt Hauptschülern eine Anleitung zum Lösen von DLG geben, und wenn 
die den Taschenrechner nicht mal einschalten können, dann noch ein 
Troubleshooting?

Jo schrieb:
> Haben hier eigentlich einige Leute Angst ihr Wissen weiterzugeben

Die einen haben viel Zeit dafür geopfert, sich Wissen selbstständig 
anzueignen. Die anderen kommen ins Forum daher, schnippen mal eben mit 
den Fingern und wollen eine Rundum-Sorglos-Komplettlösung für ihr 
Problem. Besonders beliebt bei den jüngeren, man hat ja kein Bock selbst 
dafür was zu lernen. Diese Generation ist bald verloren...

Autor: al3ko -.- (al3ko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Prüfer,

war ein scheiß Beitrag von dir, das weißt du aber selbst...


@Heinz

Heinz L. schrieb:
> Naja, nehmen wir mal an jemand will das Tutorial verbessern. Was soll er
> tun? Ich hätte durchaus einige Ideen wie man das Ganze "verdaulicher"
> gestalten kann (beispielsweise durch Aufteilung in Kapitel wie das auch
> beim ASM-Tut der Fall ist, welches ich persönlich exzellent fand).
> Überhaupt denke ich es wäre eine Idee das C-Tut an das ASM-Tut
> anzulehnen und die gleichen Themen in gleichen Kapiteln behandeln.
Ich finde deine Idee super und auch gut, das AVR-GCC Tutorial an das 
AVR-Tutorial anzulehnen. Dann hätte man ein C-"Gegenüber" vom sehr guten 
AVR-Tutorial.
Und wie ich Krapao verstanden habe, war es auch anfangs als Lehrtutorial 
angedacht, hat sich aber als Nachschlage weiterentwickelt.

Und grundsätzlich scheint man von einer Umgestaltung/Anpassung nicht 
ganz abgeneigt zu sein.


> Und ja, wenn's gewünscht wird schreib ich's gern. Allerdings: Wo? Wie?
> Was darf ich... Ich bin nicht unbedingt 'n großer Wiki-Schreiber.

Ich glaube, dass man irgendwo hier eine Diskussion anregen kann.
http://www.mikrocontroller.net/articles/Diskussion...

Gruß

Autor: al3ko -.- (al3ko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Ihr redet alle um den heißen Brei.
> Was ist mal mit ner konkreten Aussage? Irgend eine Liste, mit der man
> überhaupt irgendwie arbeiten kann.
> Die Liste kann man ja durchaus auf der Diskussionsseite des Artikels
> zusammenstellen.

Sehe ich auch so.

Ich bin dafür, das AVR-GCC Tutorial an das AVR-Tutorial anzulehnen.

Letztendlich müsste doch "nur" der Assembler Code in C umgeschrieben 
werden. Bilder, Erklärungen etc. sind doch schon im AVR-Tutorial 
wunderbar vorhanden, so dass man diese übernehmen könnte?

Gruß

Autor: juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ uCAnfänger

Also ich empfinde es als eine bodenlose Frechheit so aufzutreten. Du 
hast in meinen Augen genau 2 Möglichkeiten. Entweder du bist mit dem 
zufrieden was dir die kostenlose Einbahnstraße liefert, bedienst dich 
daran und lernst was daraus. Oder du must auf das "kostenlos" verzichten 
und kaufst dir ein Buch. Dem Autor kannst du dann u.U. mit Recht 
vorwerfen, dass sein Buch scheiße ist. Oder besuchst eine Weiterbildung 
für die gern mal 4 stellige Beträge erwartet werden. Wenn du dann genug 
gelernt hast und willst dein Wissen öffentlich weitergeben, dann werden 
deine Antworten auf solche Beiträge wie deinen ausfallen wie meine 
Antwort.
Ich frage mich manchmal wie es möglich war Programmieren zu lernen als 
es das Internet noch nicht gab.
Eventuell solltest du auch mal über deinen geistigen Horizont 
nachdenken. Ich würde mir warscheinlich überlegen ob Friseur nicht doch 
der bessere Beruf ist, wenn ich noch nicht mal die Tutorials hier 
ansatzweise verstehe. Jedenfalls würde ich mir nicht die Blösse geben, 
dass hier auch noch öffentlich zu machen. Kannsts es ja auch mal bei 
DSDS versuchen, da werden Leute mit großer Klappe immer gern gesehen....

@die anderen
Ich kann es auch nicht verstehen, wenn hier versucht wird noch was 
konstruktives daraus zu machen. Da kommen die anderen Volltrottel nur 
noch auf die Idee, sie hätten dafür gesorgt, dass aus dem AVR-GCC 
Tutorial endlich mal was gescheites wird. So wie Malen nach Zahlen, da 
geht es doch auch.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:

> Versteht es nicht falsch. Ich bin kein Troll

Ob man ein Troll ist, entscheidet sich am Inhalt eines Postings.

Wer kein Trollposting schreibt, läuft nicht Gefahr, für einen Troll 
gehalten zu werden. Der muß dann auch nicht extra schreiben, daß er sich 
nicht für einen Troll hält.

Insofern ist ein Satz wie der obere das perfekte Erkennungszeichen für 
einen Troll. Also, falls man nach dem Lesen des Nicks und des Betreffs 
noch Zweifel hatte.

Erstaunlich finde ich deine Unverschämtheit, Leuten die in ihrer 
Freizeit ein Tutorial geschrieben haben, erst ins Gesicht zu spucken und 
dann von ihnen Hilfe zu erwarten. Geh weg!


XL

Autor: Herr Mueller (herrmueller)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh je, ich hatte schon an meiner Wahrnehmungsfähigkeit gezweifelt, als 
ich gesehen habe, dass solch ein Thread in diesem Forum so lange ohne 
Beschimpfungen auskommt. Aber nun ist alles wieder in Ordnung, ich bin 
erleichtert. Vielen Dank !

Autor: Heinz L. (ducttape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute?

Mal ehrlich und ohne Flachs, darf man nicht Kritik üben? Man KANN es 
natürlich etwas vornehmer formulieren damit man nicht auf Zehen 
rumtrampelt, das finden einige sicher nicht angenehm. Allerdings ist das 
Ziel ja hoffentlich immer noch ein Tutorial zu liefern das auch Wissen 
vermittelt. Nun ist das C-Tut, ich will's nicht verhehlen, etwas 
unstrukturiert. Gegenüber dem (meiner Meinung nach exzellenten) ASM-Tut 
ist es eher schwer verdaulich für jemanden, der weder mit MCs noch mit C 
viel bisher zu tun hatte. Ich fand den Umstieg von ASM zu C leicht, wohl 
weil ich, als ich das C-Tut durchgearbeitet habe, beides bereits 'ne 
Weile lang verwendet habe, aber objektiv gesehen ist es durchaus etwas 
besser strukturierbar.

juergen möchte ich gerne mitgeben, dass auch ich für eine Ausbildung (in 
ganz anderen Bereichen) sogar geringfügig mehr als einen 4stelligen 
Betrag hingelegt habe und auch in diesem Bereich schulend tätig bin. 
Kritik muss man da vertragen können. Ja, auch wenn man die Information 
gratis anbietet. Nicht für jeden Ratschlag den ich erteile verlang ich 5 
Hunnis die Stunde. Ich bin durchaus der Meinung, Erfahrung wird vermehrt 
indem man sie teilt. Und vor allem mit-teilt. Wobei ich sehr wohl 
unterscheide ob jemand nur "konsumieren" will oder mit der Information 
konstruktiv werden will. Und in diesem Fall gibt es meiner Meinung nach 
nur die Option, damit konstruktiv zu werden. Weil... was bringt einem 
die Info wie man MCs programmiert wenn man damit nicht irgendein Projekt 
umsetzen will?

So etwas unterstütze ich aus Prinzip gerne. Weniger erbaut bin ich wenn 
jemand von mir eine fertige Lösung will die er einfach nur "konsumieren" 
braucht, ohne dabei einen Lerneffekt auch nur erzielen zu wollen. Dafür 
nehm ich dann Geld. ;)

Wie gesagt, Kritik ist wesentlich, allerdings muss sie konstruktiv sein. 
Wenn er nun einfach nur gesagt hätte "das Tut ist Dreck und alles Käse", 
ja, dann könnte ich die Reaktion verstehen. Destruktive Kritik hilft 
nicht weiter. Im vorliegenden Fall hat der Threaderöffner allerdings 
dargestellt warum er das Gebotene nicht zufriedenstellend fand und 
welche Dinge er vermisst hat. Ich kann ihm da leider nicht 
widersprechen.

Natürlich ist es nicht angenehm oder befriedigend wenn jemand etwas, das 
man mit viel Mühe zusammengestellt hat, als ungenügend bewertet. Das 
wird allerdings immer wieder mal passieren. Damit sollte man sich 
grundsätzlich abfinden wenn man versucht, Information weiterzugeben. 
Rundheraus geradezu zu verbieten, etwas das gratis angeboten wird 
negativ zu bewerten, ist allerdings nicht zielführend. Ich würde mir 
durchaus wünschen, dass jemand mir über etwas von mir Erstelltes eine 
ehrliche Meinung zukommen lässt. Auch und vor allem weil ich das Ganze 
ja vornehmlich aus einem Grund geschrieben habe: Um Information zu 
vermitteln. Ist das Geschriebene dazu nicht in der Lage, habe ich mein 
Ziel nicht erreicht. Und das würde ich gerne wissen, weil damit meine 
Arbeit umsonst gewesen wäre, wenn ich die Kritik nicht aufnehmen, 
verarbeiten und meinen Artikel entsprechend verbessern kann um das 
gesetzte Ziel zu erreichen.

Wenn nun jeder das Ganze nur liest und den Schnabel hält weil er sich ja 
nicht aufregen "darf" weil's ja nix gekostet hat, dann bleibt etwas, das 
ich in der Hoffnung hier Wissen weiterzugeben erstellt habe, mangels 
Überarbeitung um es nutzbar zu machen unnütz.

Und das würde mich weit mehr treffen als jede negative Kritik.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Heinz L. (ducttape)

>Mal ehrlich und ohne Flachs, darf man nicht Kritik üben?

Darf man. Ist auch erwünscht.

>Ziel ja hoffentlich immer noch ein Tutorial zu liefern das auch Wissen
>vermittelt.

Logisch.

> Nun ist das C-Tut, ich will's nicht verhehlen, etwas
>unstrukturiert.

Ja.

> Gegenüber dem (meiner Meinung nach exzellenten) ASM-Tut
>ist es eher schwer verdaulich für jemanden, der weder mit MCs noch mit C
>viel bisher zu tun hatte.

Eben hier liegt der Irrtum. Es ist KEIN Einsteigertutorial, die noch nie 
was mit C oder gar allgemein mit Programmierung zu tun hatten! Es ist 
für Leute gedacht, die C gut kennen und es nun auf einen Mikrocontroller 
anwenden wollen. Es setzt viel mehr vorraus als das ASM-Tutorial!

MFG
Falk

Autor: citb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:
> den uC an den Computer anschließt. Ohne viel Theorie im Vorfeld will er
> doch erstmal die LED zum Blinken bekommen und dabei verstehen, wie das
> m

Es gibt eine erheblicha Anzahl von Leuten, die Theorie fuer wichtig 
halten, mich eingeschlossen. Dass das den typischen Anfaenger von heute 
nicht begeistert, ist auch kein Geheimnis.
Wenn also -das von Leuten, die Theorie wichtig finden geschriebene- 
Tutorial nicht passt, dann muessen die Leute, die Theorie nicht wichtig 
finden, ein neues Tutorial schreiben, was ihren Beduerfnissen Rechnung 
traegt.

Wie, das geht ohne Kenntnisse der Theorie schlecht oder gar nicht?
Warum wohl?

citb

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Eben hier liegt der Irrtum. Es ist KEIN Einsteigertutorial, die noch nie
> was mit C oder gar allgemein mit Programmierung zu tun hatten! Es ist
> für Leute gedacht, die C gut kennen und es nun auf einen Mikrocontroller
> anwenden wollen. Es setzt viel mehr vorraus als das ASM-Tutorial!

Das ist richtig, aber das alleine wäre auch nicht das Problem.

Wer kein C kann, kann es ohnehin vergessen; darüber braucht man nicht 
streiten.

Aber angenommen, man kann leidlich C (z.B. vom PC), dann ist das 
AVR-gcc-Tutorial auch noch kein richtiges Tutorial.
Es ist nicht in sich halbwegs geschlossen: daß man noch ein Datenblatt 
zum jeweiligen Controller braucht, ist klar, aber es sind dauernd 
Querverbindungen zum ASM-Tutorial nötig. Man kann sich auf den 
Standpunkt stellen, daß jemand dann halt erst ASM lernen soll, aber das 
finde ich nicht. Dann sollte man es "C für AMS-Experten" o.s.ä. nennen.

Es gibt gute Gründe für ein maschinennahes Verständnis, aber einem 
Anfänger kann man nicht alles zumuten.
Deshalb finde ich es auch deutlich verbesserungsfähig.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf jeden Fall bedarf der Artikel einer Straffung.

"Zugriff auf I/O-Ports" wiederholt zum Beispiel ein Großteil von 
"Zugriff auf Register".

Und das Tutorial sollte nicht nure klar machen, daß es kein C-Tutorial 
ist, sondern auch kein Ersatz für das Lesen der übrigens sehr guten 
Handbücher.

Den Abschnitt "Speicherzugriffe" wollte ich seit längerem schon 
überarbeitet haben, vor allem auch weil er noch keine Hinweise auf die 
Named Address Spaces enthält.

Generell kann man sagen, daß einem Artikel viele kleine Ergänzungen von 
vielen Autoren nach dem "ich weiß was"-Motto nicht unbedingt gut tun. 
Oft geht rote Faden geht verloren und unnötige Details werden übermässig 
herausgearbeitet; der Artikel verspeckt mit die Zeit...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus Wachtler (mfgkw)

>Es ist nicht in sich halbwegs geschlossen: daß man noch ein Datenblatt
>zum jeweiligen Controller braucht, ist klar, aber es sind dauernd
>Querverbindungen zum ASM-Tutorial nötig.

Stimmt.

>Deshalb finde ich es auch deutlich verbesserungsfähig.

Fängst du damit an?

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Johann L. (gjlayde) Benutzerseite

>Generell kann man sagen, daß einem Artikel viele kleine Ergänzungen von
>vielen Autoren nach dem "ich weiß was"-Motto nicht unbedingt gut tun.
>Oft geht rote Faden geht verloren und unnötige Details werden übermässig
>herausgearbeitet; der Artikel verspeckt mit die Zeit...

Wohl leider wahr.

MFG
Falk

Autor: Spackmahal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein Nachtrag zum Ursprungspost:

Och Kinder lernt doch einfach Programmieren.
Solang ihr das nicht könnt, lasst die Finger von Mikrocontrollern.

Autor: unstandardisiert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, C selbst wirkt ja auch selbst ganz schön unstrukturiert. Mit der 
heißen Nadel zusammengefrickelt, wo ham wa noch kein Sonderzeichen in 
die Sprache eingebaut? ;)

Mir kann keiner erzählen, das C-Lernen wäre (ohne Asmhintergrund) leicht 
gefallen. Ein Zeiger* ? Was soll ein Zeiger-Zeiger** sein??

Assembler dagegen ist sehr einfach, leicht zu lernen und läßt sich auch 
gut übertragen. Die Macroassembler von heute sind super, viele gute 
Ideen, aber Assembler hatte immer das Problem: Mangel an 
Standardisierbarkeit und schlechte (u.a. wegen der fehlenden Standards) 
Asmcoder (die gibt es immer noch, die haben Java erfunden). Das muß 
einen aber, sofern man nicht täglich mit 5 neuen Plattformen vom Format 
wie ARM konfrontiert wird, nicht wirklich stören.

Zum C Lernen braucht man ein gutes Buch. K+R MIT Lösungsbuch ist OK und 
auch das vom Erlenkötter ("printf kann sogar rechnen") ;)
(was macht printf("??/n") ??)

..und man braucht viel Geduld, C Lernen ist immer so komisch Top-Down, 
erst recht, wenn kein Asm-Know-How vorhanden.

Man kann unter diesem Umständen von Forenmitglierdern nicht erwarten, 
didaktische Wunderwerke zu verfassen. Wenn solche Wunderwerke in 
Buchform auftauchen, dann lehren sie in aller Regel auch nicht unbedingt 
C
http://www.amazon.de/Land-Lisp-Learn-Program-Game/...
http://www.amazon.de/Learn-You-Haskell-Great-Good/...

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spackmahal schrieb:
> Och Kinder lernt doch einfach Programmieren.
> Solang ihr das nicht könnt, lasst die Finger von Mikrocontrollern.

Themaverfehlung.


unstandardisiert schrieb:
> Mir kann keiner erzählen, das C-Lernen wäre (ohne Asmhintergrund) leicht
> gefallen. Ein Zeiger* ? Was soll ein Zeiger-Zeiger** sein??

Themaverfehlung.

Falk Brunner schrieb:
>>Deshalb finde ich es auch deutlich verbesserungsfähig.
>
> Fängst du damit an?

Wenn ich mal Zeit habe :-)

Ein kleiner Disput, wo man damit eigentlich hin will, ist aber vorher 
schon sinnvoll.
Deshalb finde ich diesen Thread eigentlich mal ganz gut (von dem 
üblichen dummern Gesabbel abgesehen).

Beitrag #2638334 wurde von einem Moderator gelöscht.
Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heinz L. schrieb:

> Leute?
> Mal ehrlich und ohne Flachs, darf man nicht Kritik üben?

Kann. Soll man sogar. Aber der Ton macht die Musik. Auch und besonders 
im Bereich der kollaborativen (Open Source) Projekte.

Aber mal ehrlich: wie ernst soll ich ein Posting nehmen, das anonym 
verfaßt wurde, mit dem Nick "uCAnfänger" und einem absichtlich 
provokanten Betreff?

Ist das nicht exakt die Definition eines Trollposts?

Was nun die geäußerte Kritik angeht:

Der "rote Pfaden" wird vermißt. Ist das schon wieder eine Provokation? 
Fipptehler? Dummheit? Na, egal. Nun in der Tat ist das GCC-Tutorial 
nicht so durchstrukturiert wie das ASM- oder allgemeine AVR-Tutorial. 
Muß es aber IMHO auch nicht. Es ist definitiv eine Ergänzung zum 
AVR-Tutorial (und referenziert dieses auch recht häufig) und geht eben 
nur auf die Besonderheiten von AVR-GCC ein. Womöglich sollte man es 
auch gar nicht "Tutorial" nennen, sondern besser "FAQ"?

Das sind alles Dinge, über die man - sachlich - sicher reden kann. 
Dafür gibt es die Diskussionsseite. Wenn man lieber in einem Forum 
diskutiert, wäre übrigens das GCC-Forum das richtige gewesen.

Persönlich sehe ich Redundanz als Hauptproblem des jetzigen 
GCC-Tutorials. Es wiederholt viel zuviel, das anderswo schon steht. Es 
ist natürlich auch Geschmackssache, wieviel Redundanz man mag. Zuviel 
Verweise auf externe Quellen zerstören den Lesefluß.

Das Problem mit dem LCD-Code kann ich überhaupt nicht nachvollziehen.


XL

Beitrag #2638406 wurde von einem Moderator gelöscht.
Beitrag #2638407 wurde von einem Moderator gelöscht.
Beitrag #2638415 wurde von einem Moderator gelöscht.
Beitrag #2638422 wurde von einem Moderator gelöscht.
Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum ist das AVR-GCC Tutorial so bescheiden?

Bescheidenheit ist eine Zier,
doch weiter kommt man ohne ihr.

Autor: Martin Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ein paar Anmerkungen von dem, der nach der Einstellung des 
ursprünglichen Texts von Chr. Schifferele in das hiesige Wiki durch 
Andreas Schwarz ziemlich viel an dem Tutorial geschrieben hat. Natürlich 
haben auch, vor allem später, viele andere beigetragen. Die Historie 
lässt sich im Wiki noch vollständig nachvollziehen.

1. Beim Durchlesen dieses Threads hat man in einigen Beiträgen den 
Eindruck, als wäre mehr Zeit zum Schreiben einiger Beträge verbracht 
worden, als zum Lesen des "Tutorials". Es gibt das wirklich ein wenig 
einleitenden Text, in dem etwas über Hintergrund und Zielgruppe das 
Tutorial steht. Ansonsten siehe Punkt 6.

2. Wie bereits oben von vielen bemerkt und in der Einleitung 
beschreiben: Verweise auf das Tutorial für C-Anfänger sind in der Tat 
wenig nützlich. Wohl aber für Leute, in C halbwegs sattelfest sind und 
nun avr-gcc verwenden wollen.

3. Ja, im Tutorial gibt es an einigen Stellen Information, die für den 
Anfänger noch nicht spannend ist. Das liegt einfach daran, das jemandem 
die Information so wichtig war, dass er/sie sich die Mühe gemacht hat, 
sie im Artikel festzuhalten, damit auch andere davon profitieren. 
Sicherlich nicht immer zu Gunsten des "roten Fadens" aber sicherlich 
besser, als wenn überhaupt nicht erwähnt. Alternative wäre, ein zweites 
Tut. für "Fortgeschrittene", um das sich auch gekümmert werden müsste 
und jedes Mal müsste man sich vor Änderungen/Erweiterungen fragen, ob 
diese "Basiswissen" oder "Fortgeschrittenenwissen" ist - das wird 
nichts...

3. Das Kapitel zu Speicherzugriffen und Adressräumen wurde seinerzeit 
von mir begonnen, weil sich in diesem Forum und auf AVRFreaks die Fragen 
zu "eeprom" und "progmem" gehäuft haben. Vielleicht ist das alles heute 
selbstverständlich und mit den Neuerungen im der gcc auch bald einfacher 
und "IAR-"-kompatibel. Vor einigen Jahres war es das nicht. Auch hier 
siehe Punkt 6.

4. Ich halte die Fortschreibung und weitere Aufteilung des Tutorials 
analog zum "Assembler"-Tutorial für wenig nützlich. Seinerzeit war meine 
Idee, den Text mit möglichst wenigen Verweisen zu externen Informationen 
zu erhalten, so dass jemand mit halbwegs brauchbaren C-Kenntnissen in 
"einem Rutsch"  durchlesen kann, was bei Anwendung des avr-gcc zu 
beachtenswert ist. Inzwischen wurden Kapitel abgespalten, die sicherlich 
etwas ausladend waren aber "klick hin" "klick her" fördert auch nicht 
unbedingt den Lesefluss. Ich war und bin gegen die Aufspaltung 
(Argumente seit Jahren auf der Diskussionsseite) aber selbst in diesem 
nicht-inhaltlichen Punkt lässt sich keine Einigung erzielen.

5. Das Tutorial ist alt, der Ursprungstext noch älter. Die Anfänge 
stammen aus der Zeit, in dem noch spezielle Funktionen zum Zugriff auf 
HW-Register erforderlich waren, von Integration in AVR-Studio nichts in 
Sicht war (daher Makefiles hervorgehoben) und erst recht neuere 
Erweiterungen im Compiler für "smart pointer" in die Adressräume nicht 
verfügbar waren (daher langes Kapitel Speicherzugriffe). Somit sind 
einige Beschreibungen möglicherweise altmodisch. Es wurde aber schon ein 
Anhang eingeführt, in den alte Informationen ausgelagert werden können. 
Das scheint aber erst dann sinnvoll, wenn der Haupttext angepasst wurde.

6. Es wurde bereits erwähnt, das der Artikel in einem Wiki steht, also 
jeder verbessern und erweitern kann. Wer sich das nicht zutraut: das 
Wiki bietet eine Diskussionsseite zum Text. Wenn man irgendwelche 
konkreten Vorschläge hat, kann man sie dort reinschreiben. Ein 
Forenthread ist zur Sammlung von Verbesserungsvorschlägen ungeeignet.

Autor: Jahat Iblis (jaib)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin gerade über diese Diskussion gestolpert nachdem man mir hier eben 
richtig toll geholfen hat. Das Forum hier ist für mich als Anfänger 
immer meine erste Anlaufstelle und langsam trau ich mich sogar was zu 
schreiben ;-)

Ehrlich gesagt bin ich auch an dem C-Tutorial hier gescheitert und 
Assembler wollte ich mir nicht antun (ich schäme ich auch dafür). Habe 
dann hier unter Links das Tutorial unter http://www.avr-cpp.de gefunden. 
Ist zwar offensichtlich noch nicht fertig aber ne ganz anderer Welt. Bin 
mit meinen JAVA Schul-Vorkenntnissen (oder besser Vor-Schulkenntnissen) 
schnell zum Zuge gekommen. Und mal sehen vielleicht trau ich mich dann 
auch noch mal an das C-FAQ-Tutorial hier ran.

Gruß Jahat

Autor: Heinz L. (ducttape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verzeihung wenn es so rüberkam als wolle ich ein "C-Lernen" Tutorial 
vorschlagen. Das will ich explizit NICHT. Es dürfte auch nicht 
sonderlich notwendig sein, was man für die ersten Schritte mit MC-C 
benötigt, dafür reicht's auch mal ein paar Zeilen in PHP oder einer 
anderen Scriptsprache geschrieben zu haben. Und ich wage die Behauptung 
man darf davon ausgehen, dass das jemand, der sich in die Welt der 
Microcontroller "hinabwagt", irgendwann mal zumindest im Vorbeigehen 
gesehen hat.

Ich danke auch für den Einwand, dass C zu lernen bedingt, Assembler zu 
können. Ich muss dem Einwand leider recht geben, ich habe C erst 
wirklich verstanden als ich den zugehörigen Assembler gelernt hatte, 
erst dann begannen so Dinge wie beispielsweise Zeiger so richtig Sinn zu 
ergeben.

Entsprechend wäre es vielleicht zielführend, wirklich einen Verweis auf 
das ASM-Tut zu machen, mit dem Hinweis sich bitte dort die Grundlagen 
der MC-Programmierung anzueignen und erst dann das C-Tut zu lesen, da 
dieses viel leichter verdaulich ist wenn man einerseits C kann, 
andererseits verstanden hat wie MCs funktionieren.

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich möchte mich auch noch mal zu Wort melden, nachdem ich noch mal eine 
Nacht darüber geschlafen und mir die Diskussion eben erneut durchgelesen 
habe.

Vorab:
Ich möchte mich für meinen harschen Ton im Eingangspost entschuldigen. 
Ihr habt recht, dass ich meine Intention und Meinung auch geeigneter 
hätte ausdrücken können und müssen. Ich entschuldige mich in aller 
Öffentlichkeit und bitte, diese Entschuldigung anzunehmen, damit die 
weitere Diskussion friedlich abläuft.

An jene, die mich als Troll bezeichnen:
Nein, ich bin keiner. Wenn ihr euer Urteil auf die zwei Argumente 
beschränkt "uCAnfänger als Name" und "Provokanter Titel", dann bitte ich 
euch, ein wenig weiterzudenken. So habe ich z.B. eine ernsthafte und 
weitaus tiefgründigere Fragestellung gegeben:
"Was findet ihr am AVR-GCC Tutorial so gut, dass ihr es so oft als 
Standardreferenz für Anfänger hier im Forum nennt".

Das war eine Kernfrage in meinem Eingangspost, auf die wenig bis gar 
nicht eingegangen worden ist. Im Gegenteil: Es gab Zustimmung, dass das 
Tutorial weniger als Lehrmaterial geeignet ist. Es war zwar so 
angedacht, hat sich aber im Laufe der Zeit zu einer Art 
Nachschlagewerk/Kochbuch entwickelt.

An juergen, falls er das hier noch lesen sollte:
Du darfst meinen Eingangspost und meine unangemessene Formulierung gerne 
kritisieren. Interessant finde ich es aber, dass du "Auge-um-Auge; 
Zahn-um-Zahn" gehandelt hast. Damit hast du ebenfalls keine Klasse 
bewiesen. Besonders schade finde ich es aber, dass du herablassend über 
andere Berufsgruppen sprichst. Das finde ich persönlich noch schlimmer 
als mein Verhalten. Ich gehe jede Wette ein, dass du alle zwei Monate 
zum Friseur gehst, um dir die Haare schneiden zu lassen.

Mir ist aufgefallen, dass ich bei einigen so rübergekommen bin:
"Tutorial ist scheiße. Leute, ändert es, macht es besser und stellt es 
wieder zur Verfügung, damit ich es verstehe. In der Zwischenzeit schaue 
ich die Simpsons auf Pro7".

Dieses Verhalten war nicht meine Intention. Im Gegenteil: Ich würde 
gerne meine Hilfe anbieten, sofern man sich zu einem neuen 
Tutorial/einer Änderung des Tutorials entschließen sollte. Zugegeben, 
mein Wissen in Sachen uC ist sehr beschränkt. Es reicht bis zum Aufbau 
auf einem Steckbrett bis hin zu drei LEDs, die in verschiedenen Rythmen 
blinken. Wie gesagt, beim LCD hörts bei mir schon auf.
Ich könnte also anbieten, eine Art Anleitung "How to set up the min. 
required circuit" zu schreiben. Dabei würde es einerseits um die 
Beschaltung des Minimalbeispiel gehen, andererseits aber auch die 
Fragestellung beantworten "Wie bekomme ich den AVRISP mkII auf das 
Steckbrett". Für jemanden, der nicht täglich am herumbasteln ist, könnte 
damit durchaus Probleme haben, weil man nicht weiß, wonach man suchen 
muss. Darauf ziele ich gezielt auf den Einkauf bei Reichelt o.ä. ab, 
wenn es darum geht, den 6 poligen Wannenstecker geeignet aufs Board zu 
bekommen. Das ist u.a. ein weiterer Kritikpunkt meinerseits bezüglich 
des Tutorials. Es wird erwähnt, dass das AVR Starterkit aus dem 
embedded-shop hervorragend geeignet sei. Deshalb habe ich es mir gekauft 
und ständig Probleme damit gehabt. Die Probleme zu finden war für mich 
als Anfänger sehr schwer geschweige denn unmöglich, weil ich nicht 
wusste, wonach ich suchen sollte. Und eine Ferndiagnose hier im Forum 
war auch nicht erfolgreich (eben weil es kein trivialer Fehler zu sein 
schien/scheint, was man mal eben über eine Ferndiagnose herausfinden 
kann).

Natürlich nur, sofern dieses erwünscht ist.

Ferner könnte ich meine Hilfe insofern anbieten, als dass ich mich als 
"blutiger Anfänger" zur Verfügung stelle, auf die das Tutorial ja u.A. 
abzielen kann/soll. Was mir im Studium bei den ganzen Lerngruppen immer 
wieder aufgefallen ist:
Wenn man sich sehr gut auf einem Fachgebiet auskennt, ist es enorm 
schwer sich in jemand anderen hineinzuversetzen und nachzuempfinden, 
dass er damit Probleme hat. Eben weil es für einen selber so trivial zu 
sein scheint. Ich habe in einem anderen Forum aktiv Nachhilfe in 
Mathematik gegeben. Dass ein wirklich ambitioniertes Mädel einfach 
keinen Zugang zur Mitternachtsformel hatte, blieb mir schleierhaft.
Genau so schleierhaft scheinen mir die Anfänge in uC zu sein, wenn ich 
das AVR-GCC Tutorial hier durchlese.


Freundliche Grüße,
uCAnfänger

Autor: uCAnfänger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir beim Lesen meines letzten Beitrages aufgefallen ist:

Die Probleme, die ich mit dem Starterkit hatte, waren, dass ich meinen 
Mikrocontroller nicht mehr ansprechen konnte. Es gab eine Fehlermeldung 
in AVRStudio und hier im Forum vermutete man, dass Fuses falsch gesetzt 
worden seien (obwohl ich die Dinger nie bewusst angefasst habe).


Gruß

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uCAnfänger schrieb:
> Was mir beim Lesen meines letzten Beitrages aufgefallen ist:
>
> Die Probleme, die ich mit dem Starterkit hatte, waren, dass ich meinen
> Mikrocontroller nicht mehr ansprechen konnte. Es gab eine Fehlermeldung
> in AVRStudio und hier im Forum vermutete man, dass Fuses falsch gesetzt
> worden seien (obwohl ich die Dinger nie bewusst angefasst habe).

Solcherlei Problemen sollte natürlich im avr-gcc-Artikel ein eigenes 
sehr langes Kapitel gewidmet werden, denn genau da passt die Anleitung 
zum Umgang mit Programmierhard- und -software und den Tücken der 
AVR-Fuses hervorragend. Damit sei auch gleich die Diskussion über die 
Unzulänglichkeiten der AVR Checkliste eröffnet - ist auch nicht so 
viel zu lesen. Ein langes Kapitel zur AVRStudio fehlt offensichtlich 
auch im avr-gcc-Tutorial, am Besten eine vollständige Übersetzung der 
Online-Hilfe der Versionen 4.x, 5.x und 6 beta, natürlich verteilt über 
mehrere Wikiseiten. Wirklich "bescheiden", dass dies alles noch fehlt.

Autor: Jahat Iblis (jaib)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nja, aber das ist für das Forum hier manchmal sehr typisch, wenn ein 
Anfänger fragt ob es empfehlenswert ist sich ein fertiges Evalboard 
zuzulegen wird er schnell mal gedisst, mir gings auch so als ich um Rat 
gefragt hatte ob ich mir ein myAVR Bausatz für 15 Teuro zulegen 
sollte... genau die gleichen Hinweise kauf ein Steckbrett und 
Einzelteile und nen Programmer aus den anhängenden shop hier ... kommt 
man dann mit sowas wie ich bekomm es nicht gebacken wird der ton schnell 
rüde und als NOOB soll man doch erst mal die Tutorials durcharbeiten 
bevor man es wagt eine Frage zu stellen...

ABER wenn man das aushält wird einem hier richtig gut geholfen :-) denn 
hier tummeln sich richtige Freaks die leider von "dummen" Fragen schnell 
genervt sind weil sie die schon tausend mal beantwortet haben... wenn 
die Jungs einfach noch lernen zu akzeptieren dass jemand es lieber etwas 
idiotensicherer als Steckbrett und Reicheltbestellliste haben möchte 
wäre es vielleicht noch schöner hier... aber eigentlich leben solche wie 
myAVR oder Franzis genau von denen die hier verschreckt werden weil die 
dann zu den wirklich teuren rundum-glücklich-Paketen greifen

Im Moment bin ich richtig zufrieden mit meinem Lernfortschritt mit C++ 
für den AVR :) genau dank der Hilfe unserer bärbeißigen Freaks und läuft 
das dann Kopf waschen lassen, nachdenken, glücklich sein: 
Beitrag "Modulo und uint32_t funktioniert nicht" ... so dass wollt ich 
einfach mal los werden

Gruß Jahat

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin Thomas schrieb:

> Solcherlei Problemen sollte natürlich im avr-gcc-Artikel ein eigenes
> sehr langes Kapitel gewidmet werden, [...]

Solche "was alles schiefgehen kann" Artikel/Einlassungen werden niemals 
nicht alle Fehler abdecken können, dafür gibt es einfach zu viele 
Fehler:

Man kann nie so dumm denken wie's kommt!

Sinnvoll wäre eher ein Diagnose-Abschnitt, wo beschrieben ist, wie man 
an Informationen herankommt: Mapfile, Assembler-Listing, Warnungen, 
Fehlermeldungen richtig lesen, Disassembly erstellen, etc. damit man in 
die Lage versetzt wird, ein Fehlerbild richtig einzuordnen.

Fehlern, die aufgrund von Faulheit und Lernresistenz auftreten und zu 
"Ein Fehler ist aufgetreten, was muss ich machen?" Threads führen, wird 
man so oder so nicht beikommen...

> Ein langes Kapitel zur AVRStudio fehlt offensichtlich
> auch im avr-gcc-Tutorial,

Nein definitiv nicht!

Es gibt einen eigenen Artikel zum AVR-Studio, wo Hinweise, Hilfe, 
Tutorial etc. dafür hingehören.

avr-gcc hat mit AVR-Studio überhauptnix zu tun. Weder braucht man es, um 
avr-gcc zu verstehen oder zu verwenden, noch muss man überhaupt wissen, 
was AVR-Studio ist oder daß es existiert ;-)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heinz L. schrieb:
> Ich danke auch für den Einwand, dass C zu lernen bedingt, Assembler zu
> können. Ich muss dem Einwand leider recht geben, ich habe C erst
> wirklich verstanden als ich den zugehörigen Assembler gelernt hatte,
> erst dann begannen so Dinge wie beispielsweise Zeiger so richtig Sinn zu
> ergeben.

Angeregt durch den obigen Beitrag und die Diskussion über die Qualität
des AVR-GCC_Tuorials habe ich ein paar Gedanken zusammengetragen zum
Thema

Was man für die C-Programmierung auf Mikrocontrollern nicht braucht
===================================================================

EDIT: | dieser Titel sollte eigentlich heißen:
      |
      | Was man zum Erlernen der C-Programmierung auf Mikrocontrollern
      | ==============================================================
      | nicht braucht
      | =============


    ———————————————————————
    Die Manager-Kurzfassung
    ———————————————————————
    1. Assembler-Kenntnisse
    2. ein Tutorial
    ———————————————————————


Das Argument, dass man Assembler-Kenntnisse haben muss, um hardwarenah C
Programmieren lernen zu können, liest man hier immer wieder. Ich sehe
das aber anders: Assembler-Kenntnisse sind zwar nützlich für den leich-
ten Einstieg in hardwarenahes C, aber keinesfalls notwendig.

Ich kenne viele Leute, die recht gut C programmieren können (auch mit
Pointern, Bit-Operationen und dergleichen und sogar auf Mikrocontrol-
lern), aber noch nie eine Zeile Assembler geschrieben haben.


Meine eigenen Erfahrungen
=========================

Es ist aus eigener Erfahrung ein großer Vorteil, grob zu wissen, wie ein
Mikroprozessor funktioniert, insbesondere wie der Speicher angesprochen
wird. Die vier wichtigsten Punkte dabei:

- Die kleinste Speichereinheit, auf die der Prozessor zugreifen kann,
  ist das Byte. Wenn man nur Teile eines Bytes lesen oder schreiben
  will, braucht man dazu spezielle Arithmetik (Bit-Operationen).

- Die einzelnen Bytes des Speichers sind sequentiell durchnummeriert.
  Die Nummern heißen in der Fachsprache "Adressen". Da eine Adresse eine
  Nummer, also ein Zahlenwert ist, kann man mit ihr die gleichen Dinge
  tun wie mit gewöhnlichen Zahlen: In Variablen speichern und damit
  rechnen. In höheren Programmiersprachen werden die Bytenummern bzw.
  Adressen "Pointer" genannt.

- Jede Variable belegt im Speicher eines oder mehrere aufeinanderfolgen-
  de Bytes. Eine Variable ist einerseits durch ihren Namen, andererseits
  aber auch durch die Adresse des ersten ihrer Bytes eindeutig defi-
  niert. Ein Lese- oder Schreibzugriff auf eine Variable kann somit auf
  zwei Arten erfolgen: entweder über ihren Namen oder über ihre Adresse
  (Pointer).

- Unter den durchnummerierten Bytes gibt es auch welche, hinter denen
  keine gewöhnliche Speicherzellen stecken, sondern spezielle digitale
  Schaltungen, die die Kommunikation zur Außenwelt herstellen (bspw. die
  Abfrage einer Taste oder die Ausgabe eines Zeichens auf dem Bild-
  schirm). Aus der Sicht einer höheren Programmiersprache kann man diese
  Bytes als eine Art "aktive" Variablen betrachten. Was die Inhalte
  dieser Bytes bedeuten und welche Aktionen sie auslösen, kann man in
  der Hardwarebeschreibung des jeweiligen Computers bzw. Mikrocontrol-
  lers nachlesen.

Das eben Geschriebene ist nicht hundertprozentig präzise und allgemein-
gültig, aber völlig ausreichend, um zu verstehen, wie man in höheren
Programmiersprachen hardwarenah programmiert.

Ich habe mir seinerzeit die vier Punkte schon bald nach meinen ersten
Programmierversuchen in Basic auf einem Homecomputer verinnerlicht.
Durch Spielen mit den PEEK- und POKE-Befehle konnte konnte man live
erkennen, dass der Computer tatsächlich wie beschrieben funktionierte.

Irgendwann kam dann Pascal an die Reihe, wo ich erstmalig mit Records
und Pointer-Variablen in Berührung kam. Weil es beide in dem mir bekann-
ten Basic nicht gab und die Lehrbücher nur sehr abstrakte Definitionen
dieser Begriffe gaben, hatte ich lange unendliche Schwierigkeiten, sie
sinnvoll einzusetzen. So geht es offensichtlich vielen Programmieran-
fängern.

Irgendwann fiel es mir wie Schuppen von den Augen: Ein Record ist eine
Ansammlung mehrerer im Speicher hintereinanderliegender Variablen, die
zu einer großen Variable zusammengefasst und somit als eine Einheit
behandelt werden. Und ein Pointer ist einfach eine Variable, die die
Speicheradresse auf solch einen Record (oder eine beliebige andere
Variable) enthält.

Der Hüter des heiligen Pascal-Grals Niklaus Wirth hätte mich für diese
hemdärmlige "Definition" sicher auf der Stelle exkommuniziert, wahr-
scheinlich sogar zurecht. Trotzdem konnte ich damit fortan diese Sprach-
elemente problemlos für Listen, Bäume und noch komplexere Datenstruktu-
ren einsetzen, und darum geht es letztendlich.

Als dann C kam, war dann alles ganz einfach. Erstmals konnte man sich
Pointer-Variablen sogar per printf numerisch ausgeben lassen, so dass
man erkennen konnte, dass es sich tatsächlich um Bytenummern handelte.
Anders als in Pascal konnte man mit den Pointern auch rechnen und damit
den von Variablen belegten Speicher systematisch erkunden. Und man
konnte den Pointer-Variablen direkt numerische Werte zuweisen und damit
wie mit PEEK und POKE in Basic Speicher- und I/O-Adressen direkt anspre-
chen. Wer hätte gedacht, dass die anfänglich so geheimnisumwitterten
Pointer so vielseitig sein können.

Zwischendurch habe ich auch etwas Assembler gemacht, weil ich gehört
habe, dass man damit sehr viel schnellere Programme schreiben kann, vor
allem im Vergleich zu Basic. Das einzige, was ich dabei wirklich mys-
tisch fand, war folgendes:

In Basic schrieb man eine Verzweigung einfach als

  IF A=B THEN 100

um bei Erfüllung der Bedingung A=B in Zeile 100 zu springen. Der
Vergleich und der Sprung bildete also eine einzelne Anweisung.

In Assembler schrieb man dafür mehrere Befehle:

  LDA A
  CMP B
  BEQ SPRUNGZIEL

Dass der Variableninhalt von A über das Akkumulatorregister an den
Vergleichsbefehl CMP übertragen wurde, hatte ich recht schnell kapiert,
der Befehl heißt ja nicht umsonst LDA. Aber wie um alles in der Welt
gelangte das Ergebnis des Vergleichsbefehls zum Sprungbefehl (BEQ)? Ja,
dafür gibt es die Statusbits, aber die erscheinen in keinem der obigen
Befehle explizit, und im Assemblerbuch sind sie mir nicht sofort ins
Auge gestochen. Nachdem diese Hürde aber genommen war, war der ganze
Rest des Befehlssatzes wieder leicht zu verstehen.

Zurück zu meiner These, dass man für die C-Programmierung (nicht einmal
für die hardwarenahe) vorher nicht Assembler lernen muss:

Alles, was man über Pointer, Bitzugriffe und I/O-Operationen wissen
muss, kann man sich aus den vier Punkten in der ersten Aufzählung
zusammenreimen. Um diese Punkte zu verstehen, braucht man eine halbe
Stunde und keine Tage oder gar Wochen wie für das Lernen einer Assemb-
lersprache.

Was ich bei der Einarbeitung in die Assembler-Programmierung hauptsäch-
lich gelernt habe, ist der Umgang mit Prozessorregistern, den Statusbits
und der stark eingeschränkten Datenwortbreite (damals 8 Bits), die es
oft erforderlich machen, selbst einfache Operationen wie Additionen und
Subtraktionen aus mehreren Einzelbefehlen zusammenzusetzen.

Aber genau diese Dinge sind es, die in C wegabstrahiert wurden, so dass
ihre Kenntnis bei der Einarbeitung in C keinen wirklichen Nutzen haben.


Wie ich zu den Mikrocontrollern kam
===================================

Irgendwann (dar war ich schon im Berufsleben) bekam ich im Rahmen eines
Entwicklungsprojekts den ersten Mikrocontroller in die Hände gedrückt,
ein 8051-Derivat. Dazu:

- das Toolchain-Handbuch (für die Bedienung von Compiler, Linker etc.)
- das Datenblatt (für die Beschreibung der integrierten Peripherie)
- ein, zwei Beispielprogramme (um mir diese komischen sbit-Konstrukte
  klar zu machen, die es sonst in C nicht gibt)

Schon nach zwei Tagen konnte ich mit der projektbezogenen Mikrocontrol-
ler-Programmierung in C beginnen.

Noch etwas später wollte ich auch hobbymäßig Mikrocontroller nutzen.
Weil ich in solchen Dingen etwas geizig bin, habe ich nach einem Cont-
roller gesucht, der sich mit einer unter Linux lauffähigen kostenlosen
Toolchain und selbstgefrickelter Programmierhardware programmieren lässt
und bin dabei auf die AVR-Familie gestoßen, die ich vorher nicht gekannt
habe.

Auf dieser Webseite (inzwischen weitestgehend outdated)

  http://www.linuxfocus.org/English/November2004/art...

fand ich sämtliche Informationen, um mir die benötigte Infrastruktur
aufzubauen (Herunterladen und Bauen der Toolchain, Zusammenlöten des
Programmieradapters und Schreiben des ersten Testprogramms). Dazu kamen
die Atmel-Datenblätter und die Dokumentation der AVR-Libc, und ab ging
die Post :)


Das Fazit
=========

Man braucht, um Mikrocontroller in C zu programmieren, nicht nur keine
Assembler-Kenntnisse, sondern nicht einmal ein Tutorial. Beides bremst
eher als dass es nützt. Und das gilt für euch genauso wie für mich, denn
ich habe ganz sicher nicht mehr Gehirnmasse in meinem Schädel als ihr.

Die einzigen wirklich wichtigen Voraussetzungen für eine geradlinige
Einarbeitung in das Thema sind — neben den schon genannten Informationen
— Interesse an der Technik und Freude am Basteln und Programmieren :)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Was man für die C-Programmierung auf Mikrocontrollern nicht braucht
> ===================================================================
>
>     ———————————————————————
>     Die Manager-Kurzfassung
>     ———————————————————————
>     1. Assembler-Kenntnisse
>     2. ein Tutorial
>     ———————————————————————

3. make und Makefiles
4. Debugger oder Simulator

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Martin Thomas schrieb:
>...

Sorry, ich hätte ein deutliches Ironie-Schild unter meinen Beitrag 
hängen sollen. War leider so nicht offensichtlich genug.

Sicher ist das Tutorial verbesserbar, aber dass der Anlass der Kritik 
scheinbar rein gar nichts mit der GNU-Toolchain selbst zu tun hatte, hat 
mich zu dieser ironischen Anmerkung hinreißen lassen. Entschuldigung 
nochmals, dass dies nicht deutlich war

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Ich kenne viele Leute, die recht gut C programmieren können (auch mit
> Pointern, Bit-Operationen und dergleichen und sogar auf Mikrocontrol-
> lern), aber noch nie eine Zeile Assembler geschrieben haben.

Bei ASM gibts einen großen Unterschied zwischen schreiben und lesen 
können.

ASM schreiben können muß man als C-Programmierer nicht; ASM-Texte lesen 
zu können kann dagegen schon recht nützlich sein.

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

>...
> Was man für die C-Programmierung auf Mikrocontrollern nicht braucht
>     Die Manager-Kurzfassung
>     1. Assembler-Kenntnisse

(in der Annahme, dass das Ironie-Schild nicht fehlt, da im Text 
eigentlich selbst schon einiges relativiert wurde)

Sicher kein Muss. Ein paar rudimentäre Kenntnisse schaden bei µCs aber 
nicht. Ich kann bis heute kaum x86-Assembler, obwohl schon ein "paar" 
Zeilen für PC-Anwendungen programmiert. Dabei muss man selten ein paar 
µsec oder Bytes nachlaufen. Bei Mikrocontrollern ist es nicht schlecht, 
wenn man etwas besser interpretieren kann, was der Compiler aus dem Code 
gemacht hat. Das ist auch der Grund, warum ein wenig 
"disassembly"-Ausgaben im Tutorial sind, einfach um den Neuling zu 
zeigen, das es so etwas gibt (disassembly, da der Aufruf im WinAVR 
makefile drin steht, die Optionen zum Stehenlassen der Zwischendateien 
nicht).

>     2. ein Tutorial

Jep, wenn man stattdessen wie geschrieben die GNU Dokumentation und die 
der avr-libc durchliest und aus vorhandenem Code lernt (So hab ich das 
seinerzeit auch gemacht). Ob ein Verweis auf die Standardwerke (auf 
englisch) so anfängerfreundlich ist?

Johann L. schrieb:

> Yalu X. schrieb:
> 3. make und Makefiles

Direkt sicher nicht. Makefile ist zum Einen eine Altlast aus 
"vor-AVRStudio"-Zeiten. Man hat den Code mit Programmers-Notepad 
editiert, das Makefile ebenfalls und dann mit "make all" den hex-Code 
generieren lies. Einfach weil alles, was man brauchte bei WinAVR dabei 
war. Zum Anderen finde ich selbst in Zeiten von "1001"  verschiedenen 
IDEs Makefiles weiterhin sehr praktisch. Statt vielen Dialogboxen ("Wo 
war jetzt nochmal die Auswahlbox zur Einstellung der 
Optimierungsstufe?") eine Textdatei, in der alle Einstellungen 
zusammengefasst sind, aus der Dritte leicht die Einstellungen erkennen 
können, auch wenn die IDE nicht installiert ist, in der man mit ein paar 
Worten kommentieren kann warum/was so eingestellt ist und die man dem 
Quellcode beilegen kann, um eindeutige Einstellungen an Dritte 
weiterzugeben. (Habe für Leute Anwendungen entwickelt, die einfach nur 
gelegentlich ein paar Parameter ändern wollen. Da reicht dann WinAVR 
installieren, Parameter in Notepad ändern, make all und "flashen").

Ja, Makefiles sind eine Hürde für Anfänger aber nur eine kleine, mit 
einer halbwegs vernünftigen Vorlage, die man für seine Anwendung anpasst 
- mehr war/ist im Tutorial auch nicht beschrieben worden.

> 4. Debugger oder Simulator

Sicherlich nicht zum Einstieg in Verwendung von GNU-Tools aber mit 
Debugger und Simulator im AVRStudio ist man schon nicht mehr so weit weg 
vom "lern C aus einem Buch auf einem richtigen PC" (keine "flashen", 
keine Hardwareprobleme, single step, Register anschauen - auch 
GPIO=virtuelle LEDs).

Ja, im gcc-Tutorial ist das nicht so wichtig aber der Simulator ist auch 
nur in 1 oder 2 Sätzen erwähnt.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Was man für die C-Programmierung auf Mikrocontrollern nicht braucht
> ===================================================================

Das sollte eigentlich heißen:

Was man zum Erlernen der C-Programmierung auf Mikrocontrollern nicht
braucht

(ich hab's oben mal nacheditiert)

Später braucht man evtl. noch ein paar Dinge mehr, aber in meinem Bei-
trag sollte es wirklich nur um den Einstieg in die µC-C-Programmierung
gehen.

Johann L. schrieb:
> 3. make und Makefiles

Hmm, wie ist das jetzt gemeint? Das Tool als solches? Oder die
Fähigkeit, selber Makefiles schreiben zu können?

Letzteres braucht man als µC-C-Anfänger sicher nicht unbedingt, aber Das
Tool an sich, zusammen mit einem vorgefertigten Muster-Makefile von
anderen, kann schon ganz sinnvoll sein ...

... nee, wenn ich's mir recht überlege, hast du recht. Der Einsteiger
braucht überhaupt kein Make. Viele AVR-Probleme hier im Forum rühren von
falsch angewandten Makefiles her. Da der Einsteiger sowieso nur kleinere
Programme mit nur einer einzigen Quelldatei schreibt, kann er den Compi-
ler+Linker mit einem einzelnen Kommando aufrufen und lernt dabei sogar
noch etwas über die Compiler-Optionen.

> 4. Debugger oder Simulator

Stimmt. Einen Debugger braucht nur der, der Fehler macht. Diese sollte
man sich aber gar nicht erst angewöhnen ;-). Auch der Simulator ist eher
beim Lernen von Assembler interessant, da man damit etwas tiefer in die
Hardware-Abläufe hineinschauen kann.

Uhu Uhuhu schrieb:
> Yalu X. schrieb:
>> Ich kenne viele Leute, die recht gut C programmieren können (auch mit
>> Pointern, Bit-Operationen und dergleichen und sogar auf Mikrocontrol-
>> lern), aber noch nie eine Zeile Assembler geschrieben haben.
>
> Bei ASM gibts einen großen Unterschied zwischen schreiben und lesen
> können.

Die Leute, die ich meinte, sind auch des Lesens von Assembler-Code nicht
mächtig. C programmieren sie trotzdem ordentlich.

> ASM schreiben können muß man als C-Programmierer nicht; ASM-Texte lesen
> zu können kann dagegen schon recht nützlich sein.

Völlig richtig. Aber wie oben geschrieben, meinte ich eigentlich die
µC-C-Einsteiger, und die brauchen den Assembler-Code auch nicht lesen zu
können. Das kommt erst etwas später, wenn man ein Gefühl dafür entwi-
ckeln möchte, welche Optimierungen im C-Code man selber machen sollte
und welche man besser dem Compiler überlässt.

Martin Thomas schrieb:
>>     1. Assembler-Kenntnisse
>
> (in der Annahme, dass das Ironie-Schild nicht fehlt, da im Text
> eigentlich selbst schon einiges relativiert wurde)

Das war tatsächlich nicht ironisch gemeint.

> Sicher kein Muss. Ein paar rudimentäre Kenntnisse schaden bei µCs aber
> nicht.

Ja, klar, aber siehe meine Antwort oben zum Kommentar von Uhu.

Zum Rest deines Beitrags (Makefile und Debugger/Simulator): Zustimmung

Autor: Dirk Billand (dirkbilland)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mir hat das Tutorial geholfen, sehr schnell in die Thematik 
reinzukommen und inzwischen eigene Schaltungen und Programme zu 
entwickeln. Dafür möchte ich den Autoren an dieser Stelle herzlich 
danken!

Ich kann ziemlich gut beurteilen, wie viel Arbeit in all den Artikeln in 
diesem Forum steckt. Und ich weiß auch, welche Mühe es macht, sich all 
dies selbst zu erarbeiten. Deshalb finde ich es schwer erträglich, daß 
es eine ganze Anzahl Menschen gibt, die zwar selbst noch über keinerlei 
Erfahrung verfügen, sich diese Mühe noch nicht gemacht haben oder 
vielleicht auch nicht über die Fähigkeit verfügen (was ich ihnen nicht 
vorwerfen möchte), aber dennoch glauben, das Recht zu haben, den 
Experten in diesem Forum ans Bein zu pinkeln.

Meine Botschaft an diese Mitmenschen: nehmt an Informationen, was ihr 
geboten bekommt. Das ist in diesem Forum eine ganze Menge! Wenn ihr mehr 
braucht, dann verwendet euer Gehirn und erarbeitet es euch selbst oder 
bezahlt jemanden dafür, daß er euch hilft. Seid froh, wenn ihr jemanden 
findet, der es unentgeldlich tut. Aber demotiviert nicht die Leute, die 
euch das alles zur Verfügung stellen! Diese haben ihr Wissen und ihre 
Erfahrung durch viel Arbeit erworben und werden ihre knappe Freizeit 
früher oder später anderen Dingen widmen, wenn ihr sie nicht 
respektiert. Das gilt übrigens auch für erfahrene Kollegen in eurer 
späteren Firma...

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Was man zum Erlernen der C-Programmierung auf Mikrocontrollern nicht
>
> Johann L. schrieb:
>> 3. make und Makefiles
>
> Hmm, wie ist das jetzt gemeint? Das Tool als solches?
> Oder die Fähigkeit, selber Makefiles schreiben zu können?

Beides. Zum Lernen für µC-Programmierung sind make und Makefile viel 
zu kompliziert. Zum einen kennt make viele implizite Regeln und 
kryptische Abkürzungen wie $@, $^, $< usw. Zum anderen ist make keine 
Skriptsprache, und eine Makefile wird nicht von oben nach unten 
durchgearbeitet, sondern nach einem komplett anderen Ansatz.

Wer behauptet, make sei simplel, hat einfach keine Ahnung von make.

Und die im Netz flottierenden Makefiles sind alles andere als einfache 
Einführungsbeispiele und oft mehrere hundert Zeilen lang mit allen 
möglichen Sonderlocken. Es werden automatisch Dependencies erstellt, was 
weitere Fallstricke birgt und komplexe Compileraufrufe notwendig macht.

Wenn man also nicht schon gut mit make vertraut ist, bedeutet make eine 
weitere, riesige Baustelle beim Lernen. Wenn etwas nicht funktioniert 
wie "no rule to make target", ist man dann angeschmiert.

Für den Anfang ist es viel hilfreicher, die einzelnen Teile der 
Toolchain kennen zu lernen, welche Aufgaben sie haben, wie man sie 
steuert, wo sie dokumentiert sind, was eine Fehlermeldung vom Compiler 
bedeutet, und was eine Fehlermeldung vom Linker.

Es genügt ein kleines Skript, das die Beispieldateien übersetzt und die 
notwendigen Kommandos enthält. Ob ein 50-Zeiler bei jedem Aufruf neu 
übersetzt wird oder erst detektiert wird, ob das vonnöten ist, ist soch 
sowas von wurscht bei so einem kleinen Lern-Programm.

Und wenn ein Skript zu kompliziert ist, tut die History der 
Kommandozeile/shell sehr gute Dienste.

> Letzteres braucht man als µC-C-Anfänger sicher nicht unbedingt, aber Das
> Tool an sich, zusammen mit einem vorgefertigten Muster-Makefile von
> anderen, kann schon ganz sinnvoll sein ...
>
> ... nee, wenn ich's mir recht überlege, hast du recht. Der Einsteiger
> braucht überhaupt kein Make. Viele AVR-Probleme hier im Forum rühren von
> falsch angewandten Makefiles her. Da der Einsteiger sowieso nur kleinere
> Programme mit nur einer einzigen Quelldatei schreibt, kann er den Compi-
> ler+Linker mit einem einzelnen Kommando aufrufen und lernt dabei sogar
> noch etwas über die Compiler-Optionen.

:-)

>> 4. Debugger oder Simulator
>
> Stimmt. Einen Debugger braucht nur der, der Fehler macht. Diese sollte
> man sich aber gar nicht erst angewöhnen ;-)

100% Zustimmung.

Oft werden Debugger/Simulator für Reverse-Engineering eingesetzt nach 
dem Motto

F: "Was mach dieser Code?"
A: "Probier es aus in XYZ"

Merke: Wenn Eingineerung einfach möglich und zugänglich ist, sollte kein 
Reverse-Engineerung eingesetzt werden!

Ein aktueller Beleg für diese These ist zum Beispiel der Beitrag
Beitrag "Re: Modulo und uint32_t funktioniert nicht"

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wer behauptet, make sei simplel, hat einfach keine Ahnung von make.

Das unterschreib' ich dir sofort.

> Wenn man also nicht schon gut mit make vertraut ist, bedeutet make eine
> weitere, riesige Baustelle beim Lernen.

Daher hatte ich seinerzeit mal Mfile gezimmert, das aber dann nicht
mehr weiter gepflegt (leider).  Auf sowas wie automatische
Dependencies hatte ich da übrigens bewusst verzichtet.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rake, das ruby-make, ist eine Alternative zu make. Es kann im Prinzip 
alles, was make kann, man kanns aber auch viel einfacher haben. Und man 
kann die Skripte debuggen.

Man benötigt allerdings Ruby-Kenntnisse, aber Ruby ist sehr leicht zu 
lernen.

Autor: Dave Chappelle (dave_chappelle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebe dem Threadersteller zu 100% recht, man merkt nach den ersten paar 
Zeilen, dass die Leute, die das geschrieben haben, noch nie mit Anfänger 
zu tun hatten und scheinbar auch selbst nie welche waren.

Wenn man was nachschauen muss ist es super, um damit zu lernen ist es 
wirklich wirklich nutzlos.

MFG
Dave

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave Chappelle schrieb:
> um damit zu lernen ist es
> wirklich wirklich nutzlos.

hättest du auch nur ein bisschen in diesem thread gelesen, wüsstest du, 
dass genau dazu NICHT gedacht ist.

aber dass du lesefaul bist und lieber meckerst, dass alles schlecht ist 
und keiner dir helfen will, lässt du dir ja schon in genügend threads 
raushängen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave Chappelle schrieb:
> dass die Leute, die das geschrieben haben, noch nie mit Anfänger
> zu tun hatten und scheinbar auch selbst nie welche waren.

An deinen Zeilen merkt man, dass dein Gedächtnis trotz deines
vergleichsweise jungen Alters bereits ziemlich kurz ist.  Soll
ich dir wirklich zusammensuchen, wie oft dir hier erfahrene Leute
schon geholfen haben?

Wird dich aber sowieso nicht interessieren.  Hauptsache, deine
selbstgefällige Wahrnehmung, immer hinten an gestellt zu sein, stimmt.

Übrigens: es gibt nicht überflüssigeres als eine ständig (und
automatisch) wiederholte "MFG"-Floskel.

Autor: hat auch mal angefangen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dave Chappelle schrieb:
> Gebe dem Threadersteller zu 100% recht, man merkt nach den ersten paar
>
> Zeilen, dass die Leute, die das geschrieben haben, noch nie mit Anfänger
>
> zu tun hatten und scheinbar auch selbst nie welche waren.

Jeder muß mal anfangen, daher ist dieser Satz sinnbefreit.

Beitrag #2641276 wurde von einem Moderator gelöscht.
Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hat auch mal angefangen schrieb:
> Jeder muß mal anfangen, daher ist dieser Satz sinnbefreit.

Sinnbefreit? Diese unsinnige Wortkreation klingt ja gerade so, als hätte 
der Satz irgendwann mal Sinn gehabt, wäre dann aber von ihm befreit 
worden - am Ende mit Waffengewalt?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Kreuzer schrieb:
> Hallo Anfänger.
>
> Ich kann deinen Frust irgendwie nachvollziehen, mir ging es damals nicht
> anders, egal was ich über C gelesen habe, es war unverständlich und
> kompliziert. Daher hab ich dann mit BASCOM begonnen, so jetzt werden
> hier wieder alle über mich herfallen.

Steinigt ihn!
;)

Autor: Metaspast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. schrieb:
>> Ich kann deinen Frust irgendwie nachvollziehen, mir ging es damals nicht
>> anders, egal was ich über C gelesen habe, es war unverständlich und
>> kompliziert. Daher hab ich dann mit BASCOM begonnen, so jetzt werden
>> hier wieder alle über mich herfallen.

Ich verstehe einfach nicht, weshalb man Programmieren an einem 
Mikrocontroller lernen muss.

Autor: cyblord ---- (cyblord)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Metaspast schrieb:

> Ich verstehe einfach nicht, weshalb man Programmieren an einem
> Mikrocontroller lernen muss.

Das kommt daher dass jeder unbedarfte Bastler einen µC sieht und denkt, 
boa den programmier ich jetzt mal schnell. SW Entwicklung wird halt 
unterschätzt, weil es sind ja nur ein paar Zeilen was ist daran schon 
schwer?
Das böse Erwachen kommt dann und dann ist natürlich die Sprache schuld, 
oder die IDE oder sonst was. Und für alle die zwar nicht einsehen 
möchten dass die überfordert sind aber an sich keinen Schimmer haben, 
wurde dann Bascom und Arduino gebaut. Damit auch der letzte der faulen 
und lernresistenten noch ein Erfolgserlebniss haben kann.
Allerdings muss man selbst damit programmieren können, denn dies ist 
nunmal unabhängig von der Sprache. Und das Ergebniss kann man hier jeden 
Tag live und in Farbe bewundern. Quellcode der einem die Tränen in die 
Augen treibt, delays in ISRs, Funktionen zigmal kopiert, switch völlig 
falsch angewendet, "if-schleifen" aus der Hölle usw.

gruß cyblord

Autor: al3ko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Meine persönliche Erfahrung:
Ich finde Programmieren total toll, mir macht es großen Spaß. Allerdings 
kann und konnte ich mich nie dafür begeistern, das Programmieren 
lediglich "um des programmierens Willen" zu lernen.

Oder anders ausgedrückt:
Ein 1000 Seiten Buch bei Seite 1 anzufangen und dann bis zum Ende 
durchzuarbeiten hat meine Motivation sehr schnell sehr stark getrübt.

Ich fing damals im Bachelor mit C# an und konnte meine Motivation bis 
zum OOP aufrechterhalten. Da ich nie ein wirkliches Ziel/Projekt 
verfolgt habe, sondern eben diesen Weg "Programmieren lernen wegen des 
programmierens Willen" habe ich die Kapitel zwar gelesen, verstanden und 
die Beispielprojekte bearbeitet, habe aber spätestens 4 Kapitel später 
wieder die Inhalte aus den vorigen Kapiteln vergessen.

Dann habe ich C# nicht mehr angerührt und wollte Programmieren in MATLAB 
lernen. Gleiches Spiel von vorne. Mit viel Motivation angefangen, erste 
Kapitel durchgearbeitet, Motivation wieder verloren und MATLAB sein 
gelassen.

Dann habe ich es noch mal mit C++ probiert - ja ich weiß, ich lerne 
einfach nicht aus meinen Fehlern :D
Auch hier wieder selbes Spiel. Bei OOP habe ich das Skript in die Ecke 
geworfen mangels Interesse am Weiterarbeiten.

Dann musste ich im Studium ein relativ umfangreiches Thema abarbeiten, 
in dem u.a. zahlreiche Berechnungen gemacht wurden. Dort habe ich dann 
wegen meiner Faulheit MATLAB als Mittel zum Zweck verwendet und mit 
grundlegenden Kenntnissen in Sachen for, if, while etc. eigene 
Automationen geschrieben, damit ich nicht immer alles von Hand machen 
muss. Zum Beispiel habe ich meine Messungen als .CSV Dateien 
gespeichert. Da es recht viele Dateien waren, habe ich einen MATLAB Code 
geschrieben, der mit die nötigen Diagramme erstellt, damit ich nicht 
jedes einzelne Diagramm manuell in Excel einfügen muss.

Und genau hier war die Motivation wieder riesig, sich mit einer 
Programmiersprache zu befassen. Das fehlende Wissen wurde dann 
letztendlich über Google und in Foren ergänzt und angeeignet.

Genau so möchte ich auch an die Geschichte uC herangehen. Eben ohne 
vorher ein 1000 Seiten dickes, ödes Buch durchzuarbeiten, bei dem ich 
auf Seite 200 nicht mehr weiß, was auf Seite 50 gemacht wurde.

Insofern vertrete ich durchaus die Ansicht, in Sachen uC grundlegende 
Sachen in C vorauszusetzen wie Funktionen, for, if, while, header, 
pointer etc. Aber ultimative C Kenntnisse zu beherrschen und sich "mal 
eben" in fremden Code hineinzuversetzen und ihn zu verstehen halte ich 
für zu viel des Guten.

Alles andere lernt man dann m.E. "learning by doing".

Jedenfalls werde ich diesen Ansatz verfolgen, weil der andere Ansatz 
bereits 3 mal kläglich in die Hose ging.

Insofern befürworte ich, dass man mit Anfängern und deren "schlechten" 
Quellcode Nachsicht üben sollte.


Gruß

Autor: Antispast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cyblord ---- schrieb:
> Quellcode der einem die Tränen in die
> Augen treibt, delays in ISRs, Funktionen zigmal kopiert, switch völlig
> falsch angewendet, "if-schleifen" aus der Hölle usw.

Für alle lernresistenten Anfänger, die das AVR-Tutorial beschränkt 
finden und ihre Quelltexte oben wiedererkennen, habe ich hier mal etwas 
gefunden:

http://www.mikrokopter.de/de_sps/microsps.php

Besonders amüsant finde ich folgenden Satz:
"Man kann also leicht (ohne Programmierkenntnisse) eigene Steuerungen 
entwerfen, die in herkömmlicher Programmierweise viele Zeilen 
Programmcode bedeutet hätten."

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cyblord ---- schrieb:
> Metaspast schrieb:
>
>> Ich verstehe einfach nicht, weshalb man Programmieren an einem
>> Mikrocontroller lernen muss.
>
> Das kommt daher dass jeder unbedarfte Bastler einen µC sieht und denkt,
> boa den programmier ich jetzt mal schnell.

Das wiederum kommt auch ein wenig daher, dass hier im Forum oft für
recht einfache elektronische Probleme gleich ein Mikrocontroller als
Lösung vorgeschlagen wird. Für jemanden, der sich in der Materie gut
auskennt und die benötigte Infrastruktur (Toolchain, Programmierhard-
ware usw.) einsatzbereit dastehen hat, kann es durchaus angebracht
sein, sogar ein einfaches Monoflop mit einem µC zu realisieren.
Hingegen wird einer, der eher in der klassischen Elektronik zu Hause
ist, gerne ein paar Bauteile mehr zusammenlöten, wenn er sich dadurch
den mühseligen Einstig in die µC-Welt ersparen kann.

Autor: Michael M. (technikus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn es schon zahlreiche Antworten gibt, hier mein persönlicher 
Senf dazu:

uCAnfänger schrieb:
> Seid ihr wirklich der Meinung, dass das AVR-GCC
> Tutorial gut für Anfänger geeignet ist?

Ja! Ich selbst habe vor einigen Jahren damit den Einstieg in die AVRs 
recht problemlos hinbekommen. Mit dem AVR GCC Tutorial in einigen Texten 
vom Roboternetz hatte ich genug, um alle folgenden Aufgaben selbständig 
zu lösen.

Meine damalige Situation:
- C-Kenntnisse: Einiges am PC gemacht, auch den Parallelport für eigene 
Versuche traktiert (z.B. I2C Bus in Software). In Sachen Bitmanipulation 
war ich aber keineswegs sattelfest. Bis ich z.B. Register &= ~(1 << 5); 
verinnerlicht hatte, verging noch einige Zeit.
- Assembler: Keinen blassen Schimmer. Daran hat sich auch nur wenig 
geändert. Ich habe Assembler nie gebraucht, um C zu verstehen.
- Elektronik: Grundlegende Kenntnisse in Analog- und Digitaltechnik.
- Mikrocontroller: absolut keine Vorkenntnisse.

Das AVR-GCC-Tutorial war kompakt genug, daß ich mich als blutiger 
Anfänger darin zurecht gefunden habe. Andererseits war es ausführlich 
genug, um die grundsätzlichen Techniken kennen zu lernen. Die Struktur 
habe ich persönlich recht übersichtlich empfunden. Sehr schnell habe ich 
mich dann eingelesen in:
- Datenblätter der AVRs (ich fand die selbst als Anfänger mit den 
Code-Beispielen für USART, etc.) richtig verständlich.
- AVR libc Dokumentation.
- Quelltexte hier aus dem Forum und der Artikelsammlung.

Fazit: Ich persönlich war rundherum zufrieden mit dem Tutorial und habe 
es deshalb auch einigen Bekannten empfohlen.

Servus
Michael

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.