Hallo ... ich möchte einen ATMEL-Microcontroller programmieren, doch was benötige ich dafür. Ich habe mal im Studium einen ATmega8 auf einem ASURO prgrammiert und bin deshalb nicht ganz unwissend auf dem Gebiet der µ-Controller Programmierung. ;) Mir wurden folgende Stcihworte gegeben: - JTAG ICE MKII - µ-C soll in C-Programmiert werden Der JTAG ICE MKII wird doch nur zum debuggen benötigt oder? Ich schließe den an mein Board wo mein Controller drauf ist an und kann über den Adabter debuggen! Richtig? So wenn ich dann irgendeinen µ-Controller programmieren möchte benötige ich ja noch ein bisschen mehr, nicht wahr?! Und da bin ich auf STK600 gestoßen. Habe ich das richtig verstanden, dass man drauf verschiedene µ-C, stecken kann und diese damit programmieren, flashen und mit der Erweiterung von dem JTAG ICE MKII debuggen kann? Zum Programmieren würde ich AVR-Studio verwenden wollen!?! Ich wäre echt dankbar, wenn da jemand ein bisschen Licht ins dunkle bringen könnte. Habt vielen Dank im Voraus.
Einfach mal links oben unter Home auf AVR klicken. http://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment Peter
Ah sehr gut ... diesen Punkt: "I/O-Grundlagen: Wie kann ich Taster und LEDs an einen AVR anschließen und benutzen?" habe ich überlesen. Danke. Um das mal zusammen zu fassen. Ich benötige also ein Board bspw. das STK600 und den JTAG ICE MKII um das Programm aufzuspielen und zu debuggen. Zum Programmieren verwende ich GNU-C-Compiler AVR-GCC. Wenn ich diese drei Dinge plus µC habe kann ich also legen. RICHTIG?
STK500/STK600 reicht völlig. Alternativ ein AVRISP mkII, dann musst du dir die Targetplatine (die mit dem µC drauf) allerdings noch selbst basteln (Steckbrett tut's auch)
>Wenn ich diese drei Dinge plus µC habe kann ich also legen.
Naja, nicht ganz. Du brauchst noch ein sonniges Gemüt und eiserne
Nerven,
um Dich gegen die Unbilden des Kompilers durchzusetzen.
;-)
MfG Paul
>Naja, nicht ganz. Du brauchst noch ein sonniges Gemüt und eiserne >Nerven,um Dich gegen die Unbilden des Kompilers durchzusetzen. Kannst du das etwas konkretisieren, was mich da erwartet? Irgendwie sind solche Informationen immer sehr demotivierend. Danke für eure Antworten. ;)
Du kannst einen SP12- Progger auch ganz einfach und billig selber bauen: http://www.rowalt.de/mc/avr/progd.htm entgegen aller unkenrufe funktioniert das teil sehr gut. du kannst dann mit dem avr studio in c programme schreiben und per simmulator als .hex-file ausgeben lassen und wie auf der seite unter "Der eingebaute Programmer vom BASCOM-AVR-Basic" auf den µC brennen.
Biko schrieb: > Du kannst einen SP12- > Progger auch ganz einfach und billig selber bauen: > http://www.rowalt.de/mc/avr/progd.htm > > entgegen aller unkenrufe funktioniert das teil sehr gut. Aber eben nicht immer. Dieser Programmierer ist nicht für den Nachbau empfohlen.
Die Unkenrufe sind schon berechtigt. Wenn ich zurückdenke was mich die Scheiß Dinger Zeit und Nerven gekostet haben, nur weil ich zu geizig war 10 Euro auszugeben.
BamBamTU schrieb: >>Naja, nicht ganz. Du brauchst noch ein sonniges Gemüt und eiserne >>Nerven,um Dich gegen die Unbilden des Kompilers durchzusetzen. > > Kannst du das etwas konkretisieren, was mich da erwartet? Irgendwie sind > solche Informationen immer sehr demotivierend. > > Danke für eure Antworten. ;) µController programmieren ist so ähnlich wie im dunkeln Flaschenschiffe zu bauen. ;)
Markus schrieb: > Die Unkenrufe sind schon berechtigt. Wenn ich zurückdenke was mich die > Scheiß Dinger Zeit und Nerven gekostet haben, nur weil ich zu geizig war > 10 Euro auszugeben. Zum Basteln ist es ganz ok, wenn der ParaPort ungestört seine Arbeit tun kann. Ansonsten hast du natürlich recht, die Preise für Progger sind nicht unbedingt sooo wild.
BamBamTU schrieb: >>Naja, nicht ganz. Du brauchst noch ein sonniges Gemüt und eiserne >>Nerven,um Dich gegen die Unbilden des Kompilers durchzusetzen. > > Kannst du das etwas konkretisieren, was mich da erwartet? Irgendwie sind > solche Informationen immer sehr demotivierend. Meistens sind es logische Fehler im Programmablauf. Der Anfänger tut daher gut daran, sich erstmal auf Papier nen groben Ablaufplan zu malen. Es programmiert sich deutlich leichter, wenn man schon weiß, was man machen muß. Dann muß man daran denken, daß die CPU nichts parallel macht. Wenn man also irgendwo lange Wartezeiten einfügt, dann warten alle anderen Aufgaben mit. Und dann gibt es Interrupts. Ansich ne feine Sache, weil man damit doch vieles quasi parallel machen kann. Aber die C-Entwickler haben nicht damit gerechnet, daß Variablen einer Funktion unterm Hintern weg geändert werden können. Daher muß man Variablen zwischen Interrupts und Main als volatile deklarieren. Und bei Bedarf die Main-Zugriffe atomar machen. Auch sollte man immer reichlich kommentieren, was ne Funktion macht und wie. Nicht für nen Schönheitspreis, sondern damit man später selber wieder durchsieht. Der Rest ist Sorgfalt, Disziplin und Logik und schon läuft das Programm. Peter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.