so, nun beginne ich gerade mit avr-programmierung. prinzipiell würde ich das gerne in assembler tun, da dies etwas rootmäßiger und schlanker geschieht. vorlesung und praktikum zum thema hatten wir auch, allerdings am beispiel intel 8x86. jetzt stehe ich vor dem problem, daß so manches beim avr doch anders geschieht (allein die befehlstippfehler aus intel-gewohnheit treiben mich zur weissglut...jump..) und ich nichmal mit abgucken "hallo welt" aufs display kriege.... macht es sinn, den ganzen murks doch in c zu versuchen? habt ihr da irgendwelche vergleichenden erfahrungen gemacht? welche compiler gibts da? wieweit bläht der compiler den code auf (im vergleich zu handgestricktem assembler)? mit welchen entwicklern schreibt ihr für gewöhnlich? woran könnte es liegen, das der emulator/debugger im kanda avr-workshop die arbeit verweigert? (error starting dos-shell) bei bedarf hätte ich noch mehr fragen... ;-)
Ich habe bis jetzt nur ASM programmiert, aber diese paar KB Speicherplatz bekommt man auch mit ASM schnell voll. Ich würde beim AVR mit C noch nicht so viel arbeiten. Obwohl die Strukturierungsmöglichkeiten gut sind. Bei einem ARM mit massig Speicherplatz würde ich aber irgendwann schon auf C umsteigen.
gibts ein epfehlenswertes buch zum thema? mit der befehlstabelle und dem datenblatt von atmel alleine komme ich nicht wirklich weiter...
Muss es wirklich ein AVR sein? zu PICs git's sehr schöne WebSites (z.B. http://www.sprut.de/) in deutsch. Und bei PICs lernt man auch schnell Assemblertricksereien - vieleicht auch unfreiwillig. Generell: Wenn Du Assembler programmieren willst, musst Du es lerenen. Da hilft dir C nicht weiter. Wenn Du hardwarenah C rogrammieren willst, musst du C lernen. Assembler hilft dir jedoch die Hardwarestruktur zu verstehen. Aber: Muss es wirklich AVR sein?
Das beste an ASM ist, dass man sich nur eine Befehlstabelle ansehen muss und man kann alles. Bei C gibt es dann noch unmengen von Funktionen :-) Sprut finde ich auch super. Die Seite hat mich erst zum Programmieren von Atmels gebracht. Ich habe sie gelesen und dann habe ich die Einfachheit der Programmer für Atmels erkannt g
Bei ATMEL-AVRs bietet sich als ASM-Entwicklungsumgebung das ATMEL-AVR-Studio 4.x an. So hat man alles aus einer Hand und kann auf Funktionsfähigkeit vertrauen (zumindest halbwegs). Anlaufpunkt ist www.atmel.com ...
@Der Elektrische Reiter "Aber: Muss es wirklich AVR sein?" Na aber klar !!! In Assembler hat der AVR doch nur Vorteile gegenüber dem PIC. Die Befehle sind einfach zu lernen, der Code- und Datenbereich ist linear adressierbar. Ich habe mit Z80 angefangen und dann den 8051. Mit dem AVR hatte ich auch keinerlei Probleme. Dann wollte ich leichtsinniger Weise mal den PIC probieren und bin fast verrückt geworden: Banking und Paging (Code nicht verschiebbar, größere Datenpuffer nur mit Klimmzügen adressierbar), keine mehrfachen Pointer für Code und Daten, keine Carry-Berechnung bei 16 oder 32 Bit-Operationen, keine bedingten Sprünge, kein Stack für Parameterübergabe, begrenzte Call-Tiefe usw.. Der PIC ist mit Abstand die umständlichste Architektur, die ich kenne. Peter
Hallo Ich habe vor einer Weile auch mit AVR Assembler angefangen und bin begeistert davon. Ich hatte früher (1986) mit dem C64 viel in 6502 'Maschinensprache' programmiert, allerdings ohne ein Assemblerprogramm (ohne Labels musste man die Sprungziele selbst errechnen usw.)Danach habe ich eigentlich nix meht gross programmiert. Vor 3 Jahren habe ich mir dann ein STK500 gekauft und leider erst vor ca 3 Monaten angefangen, damit 'rumzuspielen'. 1. Ich habe mir das Buch AVR-RISC Mikrocontroller von Trampert gekauft. Das ist nicht schlecht, aber inzwischen schon ein wenig alt. Hat ausserdem 70 Euro gekostet. 2. von der ATMEL Seite das AVR Studio runtergeladen. Das ist ein kostenloser Assembler und Simulationsprogramm. Damit kann man Programme schreiben und testen, ob einem der AVR passt, ohne dass man irgendwelche Hardware braucht, oder Kosten entstehen. 3. Das Internet nach Tutorials durchsucht und alles ausgedruckt,was interessant war. Da gibt es ne ganze Menge, auch mit Beispielen. 4. Eine Befehlsliste ausgedruckt und drauflosgetippt. Ab und zu hab ich auch noch Tippfehler von früher ( LDA Load Accu anstatt LDI ),aber den relativ kleinen Befehlssatz hat man schnell drin. Man muss halt schon ein bischen lesen, um die Besonderheiten und Tricks zu beherrschen. Am Anfang sollte es reichen, wenn man ne LED zum Blinken bringt - die HELLO-WORLD-auf-Display Ansteuerung ist schon etwas fortgeschrittener. Ich kann inzwischen schon ne IR LED so schnell zum Blinken bringen, dass mein Radio leiser wird ;-) Ein wenig Geduld ist also gefragt, aber das ist mit C wohl nicht anders. Viel Spass noch Christian
@ Peter Danegger Alle Deine "Anschuldigungen" treffen zu - allerdings nur bis zur PIC 16xx Serie. PIC 18xx ist ALLES anders; lineares, RAM, Flash,Stack .. und ein sehr mächtiger ASM (finde ich jedenfalls) der mit seinen Rechenoperationen weit weniger sich auf gewisse - fix vordefinierte- Register beschränkt als der AVR. Michael
ja, avr musses schon sein. erstens, weil ich glaube, daß das die am meisten verbreitete form von low-cost-home-controllern ist (warum an exoten lernen). zweitens, weil ich im rahmen meines praxissemesters ein gerät entwickle, daß auf atmel-basis laufen soll (sam7x, is arm und ne klasse weiter, weiß ich; abere so bleibe ich wenigstens in der familie) und drittens, weil ich mir nun schonmal ein second-hand stk200 gekauft habe und es prinzipiell ganz gut finde. damit scheidet avr-studio aber wohl schon aus, da es (glaube ich) für die stk500 entwickelt wurde. ne led per taste ein-und ausschalten kann ich schon (blinken hab ich noch nicht probiert, sollte aber machbar sein), soweit reichts noch. ich habe ja, wie gesagt, schon assembler-programmierung (intel) gehabt. c hammer auch gelernt, es ist also nich so, daß ich ganz bei null anfange. aber ein funktionstüchtiger debugger, mit dem man sich ports und register anschauen kann, der fehlt halt irgendwie... gibts noch alternativsoftware ausser avr studio (oder geht das doch auch aufm stk200?) und dem standard kanda avr-workshop?
Hallo, "...damit scheidet avr-studio aber wohl schon aus, da es (glaube ich) für die stk500 entwickelt wurde. ..." "...(oder geht das doch auch aufm stk200?)..." das AVR-Studio ist nicht nur mit dem STK500 zu gebrachen. Es ist ja eine (AVR Assembler) Entwicklungsumgebung mit Simulator. Wie man den enstehenden (Hex)-Code in den AVR bekommt ist eine andere sache. Ich benutze einen STK200 kompatiblen Programmer mit PonyProg und yaap. Grüße Quark
jo, ponyprog benutze ich auch, damit ich atmegas (8535) flashen kann. geht auch wunderbar (ponyprog2000 und original avrisp). aber ich glaube irgendwo gelesen zu haben, daß avr studio (aus welchem grund auch immer) nicht für stk 200 geeignet wäre. wenn dem nicht so ist, werde ich das wohl mal antesten.
AVR-Studio ist nicht für STK500, sondern für AVRs. Sein integriertes Brennprogramm unterstützt das STK500 (ISP und HV-Programming) und das AVRISP (nur ISP), da diese Programmer von ATMEL sind. Für andere Programmer gibt es dann andere Software wie Ponyprog, Yaap usw... Editor, Assembler und Simulator des AVR-Studios sollte man sich aber erstmal angesehen haben, ehe man es unter "taugt nix" einstuft und darauf verzichtet. Die restlichen Module (Emulator, JTAG...) funktionieren natürlich erst bei entsprechender Hardware. Aber schon für "Trockentraining" ohne Hardware (also reine Simulation) ist AVR-Studio sein Download-Traffic wert. Sieh es dir ruhig mal etwas genauer an. ...
irgendwie fühle ich mich falsch verstanden..... ICH habe mit keiner silbe das prädikat "taugt nix" vergeben. auszug aus dem release note: Release Notes - AVR Studio 4.12 (11/2005) --------------------------------------------------------------- What's new? * Part support - ATtiny261 (ICE50) - ATtiny461 (ICE50) - ATtiny861 (ICE50, JTAGICE mkII, STK500, AVRISP) - ATmega640 (JTAGICE mkII, STK500, AVRISP) - ATmega1280 (JTAGICE mkII, STK500, AVRISP) - ATmega1281 (ICE50,JTAGICE mkII, STK500, AVRISP) - AT90CAN32 (ICE50,JTAGICE mkII, STK500, AVRISP) - AT90CAN64 (ICE50,JTAGICE mkII, STK500, AVRISP) vielleicht hab ich mich halt erschreckt, daß dort zwar stks gelisted sind, aber halt nich das 200er. ES TUT MIR LEID! (...download läuft...)
Stimmt, das "taugt nix" stammt von mir. Es sollte besser heißen "taugt nicht für meine Hardware" oder "ist für meine Hardware ungeeignet". Es sollte keinesfalls ein Angriff auf deine Person oder irgendeine andere Person sein. ...
Übrigens soll die neueste Version (ich habe sie noch nicht) auch das Debuggen von C-Programmen unterstützen. ...
na gut. dann schnappe ich mal wieder aus..... ich hab mir mal die version 4.12 runtergeladen, die sollte wohl die neueste sein. das guck ich mir dann zu hause mal an und dann sehen wir weiter. die entscheidung "taugt nicht für meine Hardware"habe ich ja auch schon vor zwei wochen "getroffen", als ich mir im vorfeld das zeugs gedownloaded habe und nicht wußte, welches programm welchen job erfüllt. das ein assembler nicht auf ein spezielles eval-board abgestimmt sein kann, hätte mir (zumindest jetzt) auch langsam mal klar werden können....
Ich habe noch nie einen AVR in Assembler programmiert sondern immer nur in C/C++. Das geht wunderbar: Bisher war immer alles schnell genug und hat auch reingepaßt. WinAvr ist für mich eine ganz ausgezeichnete Wahl! Mit Assembler würde ich mich nur befassen, wenn es wirklich nicht anders geht. Ich weiß, dass das manche anders sehen. Mein Beitrag soll kein Angriff sein sondern nur MEINE Einstellung darstellen. Gruß, Michael
gut, daß du das drunter schreibst, das scheint in diesem forum manchmal wichtig zu sein..... ;-)
JA, in der Tat! :) Ich möchte meine Meinung sogar noch einmal relativieren: Für mich ist C/C++ die erste Wahl um zu erreichen was ich will. Für den Einsteiger in die Materie allerdings ist ds Programmieren in Assembler erstmal besser, da man hierbei ganz genau weiß, was der Controller wie macht. Man erhält ein Gefühl und Verständnis für sein Funktionsweise. Diesen Punkt soll man nicht unterschätzen. Aber um eine Anwendung möglichst schnell zum Laufen zu bringen ist wie gesagt eine Hochsprache (auf Controllern am ehesten C/C++) das beste. Auch unter dem Gesichtspunkt Lesbarkeit und Wartbarkeit des Quellcodes sehe ich hier nur Vorteile: Einem C-Quellcode sieht man viel leichter an, was das Programm tut, als das bei Assembler der Fall wäre. Ich will jetzt nicht darauf eingehen, dass manche Menschen leider die Möglichkeit nutzten, auch in Hochsprachen unlesbaren Code zu schreiben. (Über die Schreibweise des Wortes "Code" ist an dieser Stelle dann gesondert nachzudenken...) Gruß, Michael
Moin, ich habe für den Einstieg diese Buch gekauft: "Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie" von Günter Schmitt. ISBN: 3486577174 Ich bin damit sehr zufrieden. Das schöne: Die Beispiele werden sowohl in ASM als auch in C beschrieben. -- Martin
"Ich kann inzwischen schon ne IR LED so schnell zum Blinken bringen, dass mein Radio leiser wird ;-) Ein wenig Geduld ist also gefragt, aber das ist mit C wohl nicht anders." Das mag jetzt angeberisch klingen, aber nachdem ich meinen ersten Programmmer geätzt habe(das erste, was ich je gemacht habe) habe ich sofort eine Displaysteuerung gemacht. Die hat prinzipiell auch funktioniert. Da wo ein schwarzer Punkt sein sollte war auch ein schwarzer punkt. Das Display hatte aber scheinbar so seine Probleme mit dem Kontrast, so dass das auch im Textmodus immer wieder zu heftigen Pixelfehlern kommt. Woher die Pixelfehler kommen habe ich nie erforscht. Es muss etwas mit der Kontrastspannung zu tun haben, obwohl ich das Poti voll aufgedreht habe. Codemäßig hat alles erstaunlicherweise auf Anhieb funktioniert, obwohl ich es nicht gleich gemerkt habe, da ich vergessen habe das Display zu löschen. Scheinbar funktiniert das Display aber nur dann korrekt, wenn eine große Anzahl von Pixeln schwarz ist. An dem Taktgenerator habe ich danach schon länger gesessen g
Naja mit nem Multimeter ist nichts messbar, aber vielleicht kommt das so kurz gepulst, dass ich das nicht messen kann. Das Display braucht übrigens +12 und -12V und wird seit über 15 Jahren nicht mehr gebaut(Toshiba) Ich habe dafür schon mehrere Threads geöffnet, aber alle meinten, dass die Tatsache, dass mein Name auf dem Display erscheint (15 Buchstaben ) ein reiner Zufall ist und ich eigentlich nicht verstanden habe, wie alles funktioniert grr Aber die Disskussionen wurden hauptsächlich von dem kaputt gemacht, der hier auch irgendwo so einen AVR an 230V thread hatte*g* Das mit dem Display ist auch fast egal. Ich habe die Elektronik noch komplett da. Schade nur, dass ich extra ein paar Schieberegister zusätzlich aufgelötet habe... Den Inverter habe ich glücklicherweise mobil über Kabel angebaut. Naja Pollin hat neue Displays ich versuche es mit denen. Die kann man einfach über den PC testen und wenn sie da schon nicht funktionieren sollten, dann gibt es entweder leute, die den Controller kennen oder welche, die mir sagen können, dass ich Schrott herumliegen habe :-)
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.