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
:
Verschoben durch User
> 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
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
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.
Ach so...prinzipiell spricht nichts dagegen dass Du das Tutorial ergänzt ;-)
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ß
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.
Um sich Grundlegend mit C vertraut zu machen oder etwas nachzuschlagen, gibt es z.B. auch http://de.wikibooks.org/wiki/C-Programmierung
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
1 | a|= 0xf0; |
2 | 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!
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ß
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.
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.
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ß
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ß
> 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
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.
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.
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.
>> 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
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
1 | // 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ß
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
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?
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.
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.
@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!!
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.
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.
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...
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:AVR-GCC-Tutorial Gruß
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ß
@ 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.
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
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 !
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.
@ 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
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
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.
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...
@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
@ 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
ein Nachtrag zum Ursprungspost: Och Kinder lernt doch einfach Programmieren. Solang ihr das nicht könnt, lasst die Finger von Mikrocontrollern.
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/dp/1593272812/ http://www.amazon.de/Learn-You-Haskell-Great-Good/dp/1593272839/
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).
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
> Warum ist das AVR-GCC Tutorial so bescheiden?
Bescheidenheit ist eine Zier,
doch weiter kommt man ohne ihr.
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.
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
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.
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
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ß
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.
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
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 ;-)
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/article352.shtml 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 :)
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
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
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.
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.
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
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...
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"
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.
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.
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
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.
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.
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.
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?
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! ;)
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.
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
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ß
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."
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.