Hallo, nach langem stöbern im Netz, das lesen unzähliger beiträge, und zuviel freizeit habe ich mich entschlossen mich mit dem Thema AVR zu beschäftigen. Nun zu meiner eigentlichen Frage: - Gibt es brauchbare Bücher (Keine ASM / C Kenntnisse vorhanden) - Sollt ich avr's in C oder in ASM programmieren ? - Was bräucht ich noch außer dem STK 500 (Zur not würd ich noch einen Uraltsteinzeitrechner aus der ecke graben wegen LTP + serial port) USB würd ich allerdings bevorzugen. Hab da bei Reichelt noch "DIAMEX USB ISP" für das STK 500 gefunden. Das wär's für's erste. Danke im vorraus Alex
du solltest erstmal C 'normal' lernen, am PC. Wenn du die Grundlagen davon beherrschst, dann kannst du dich an die µCs wagen...beides zusammen lernen zu wollen halte ich für suboptimal...
Alexander B. schrieb: > Was bräucht ich noch außer dem STK 500 # Grundkenntnisse in Elektrotechnik und Elektronik # Ein gutes Nachschlage- und Lehrbuch wie z.B. "den Kories/Schmitt-Walter" # Material ähnlich wie in http://www.mikrocontroller.net/articles/Absolute_Beginner vorgeschlagen mfg mf
Ich würde erstmal ein bisschen mit Assembler anfangen. Bearbeite einfach nur die Beispiele hier in den Tutorials - Dann versteht man einige Basics besser und bekommt ein Gefühl für das was man wirklich tut. Danach würde ich ganz einfach auf C umsteigen. Dafür reicht aber ein einfaches C Grundlagen Buch und das Tutorial hier auf dieser Seite. Ansonsten brauchst du noch vieel durchhaltevermögen und starke Nerven, der Anfang kann sehr frustierend sein.
Hi Nun, wenn du schon "Erfahrung" mit Programmiersprachen hast, weißt du auch, das die Probleme nicht in der Programmiersprache liegen, sondern darin, wie gut ein Problem zerlegt und in lösbare Teile aufgegliedert werden kann. Auch ich bin der Meinung, Assembler ist der richtige Weg, in einen Controller einzusteigen. Ich weiß, das ist ein Glaubenskrieg, aber so kompliziert ist Assembler nicht. Allerdings muss man sich zwingen, Strukturen einzuhalten, wenn man den Code überblicken will. Es gibt schon ein paar Stolpersteine, da alle Prüfungen vom Programmierer ausgehen. Ob Integer, Char oder eine zusammengebastelte Realzahl, dem Assembler ist das völlig wurscht. Er nimmt, was ins Register passt.... Daher ist eigentlich mein Rat: sind nur Bitmanipulation und Steuerungen beabsichtigt, dann Assembler. Komplexe mathematische Aufgaben mit einer höheren Sprache. Gruß oldmax
Schnapp dir nen alten PC und mach win98 bzw. DOS drauf und fang an den im real mode zu programmieren (assembler) nur zum reinschnuppern und schnapp dir dann z.B. den Turbo C Compiler. Versuch auf Hardwareebene über IO-Zugriffe die Serielle Schnittstelle zu programmieren. Schreib nen Interupthandler. Danach klannst du getrost sagen das µCs ziemlich einfach sind. Die Grundkenntnisse sind jedoch auf so einer alten Kiste einfacher zu erlernen bzw. das Debuggen ist einfach klasse.
Alexander B. schrieb: > Hallo, nach langem stöbern im Netz, das lesen unzähliger beiträge, und > zuviel freizeit habe ich mich entschlossen mich mit dem Thema AVR zu > beschäftigen. Das allerwichtigste ist Anfangen! Nicht tagelang im Netz stöbern, nicht unzählige Beiträge lesen, nicht Evalboards bewerten. Einfach loslegen.
Und nicht nach 'die beste Sprache', 'dem besten Board' oder dem 'besten xyz' suchen. Erstens gibt es sowas sowieso nicht - es gibt nur brauchbar oder unbrauchbar. Und zweitens ist es beim ersten Einstieg ziemlich egal. Ein µC, ein paar LED, ein paar Taster, ein LCD und freie Anschlüsse, mehr braucht es am Anfang nicht. Und das haben alle Eval-Boards. Wichtig ist, dass du keinen Ärger mit dem Flash-Programmer hast. Da lieber ein paar Euro mehr ausgeben.
ich weiß nicht was dieser "Lern erst mal Assembler, dann C"-Quatsch immer soll. asm braucht man fast nie und man muss es für jedem controller neu lernen. genuso: Uwe schrieb: > Schnapp dir nen alten PC und mach win98 bzw. DOS drauf und fang an den > im real mode zu programmieren (assembler) nur zum reinschnuppern das ist ja noch schlimmer. Wiederverwendbarkeit des so gesammelten Wissens <5% Such dir ein C-Tutorial für den PC und installier dir einen C-Compiler (zB Visual Studio Express - hat den Vorteil, dass AVRStudio5 auch darauf basiert und die Unterschiede nicht so groß sind). dann erst mal die Basics in Kommandozeilenprogrammen lernen. Filehandling und GUI kann man erstmal getrost auslassen. wenn man die Grundlagen von C drauf hat, würde ich empfehlen mit dem AVR-gcc-Tutorial hier anzufangen und ein paar LEDs blinken zu lassen
Hallo, ich habe mir damals für den Einstieg den AVR Butterfly und dazu den AVRISP mkII gekauft. Dazu noch eine 2x40 Stiftleiste und diese dann an den Butterfly an die entsprechenden Ports gelötet. Damit kommt man dann für den Anfang schon sehr weit da das Butterfly-Modul unter anderem auch einen NTC (temperaturabhängiger Widerstand, kann man z.B. als Thermometer nutzen), einen LDR (Fotowiderstand, für Lichtmessung), ein LCD, einen kleinen Joystick und einen kleinen Piezo-Lautsprecher hat. Dazu dann noch die externen Port die man nach Belieben nutzen kann, das hat mir für den Anfang dicke gereicht. Im Endeffekt muss ich meinen Vorrednern aber Recht geben, das ist alles Geschmackssache wichtig ist, das man erstmal anfängt. Dazu braucht man übrigens auch keine Vorkenntnisse mit ASM oder C, das kann man sich, finde ich, mit den AVRs auch wunderbar so beibringen.
Vlad Tepesch schrieb: > ich weiß nicht was dieser "Lern erst mal Assembler, dann C"-Quatsch > immer soll. > asm braucht man fast nie und man muss es für jedem controller neu > lernen. Das trifft zwar zu, aber wenn man tatsächlich Assembler programmieren kann, dann versteht man vieles von dem, was nicht-Assemblerprogrammierern bei C große Probleme bereitet; gerade beim Umgang mit Pointern, Arrays etc. ist es ganz hilfreich, zu wissen, was der Prozessor/Controller da eigentlich treibt.
Rufus Τ. Firefly schrieb: > Das trifft zwar zu, aber wenn man tatsächlich Assembler programmieren > kann, dann versteht man vieles von dem, was > nicht-Assemblerprogrammierern bei C große Probleme bereitet; gerade beim > Umgang mit Pointern, Arrays etc. ist es ganz hilfreich, zu wissen, was > der Prozessor/Controller da eigentlich treibt. Ich würde dennoch behaupten, dass C zu lernen sehr viel einfacher ist, als Assembler, da man sich nicht komplett um jedes Bit kümmern muss. gerade das Retten von Registern, bzw das Vergessen des selben verursacht extrem schwer zu findene Fehler. Und C ist eigentlich low level genug, dass man Assember selbst normalerweise nicht oder nur sehr selten braucht.
Hi >Ich würde dennoch behaupten, dass C zu lernen sehr viel einfacher ist, >als Assembler, da man sich nicht komplett um jedes Bit kümmern muss. Um Bits musst du dich in C wahrscheinlich genauso wie in Assembler kümmern müssen. Eher weniger um Bytes. >gerade das Retten von Registern, bzw das Vergessen des selben verursacht >extrem schwer zu findene Fehler. Das Sichern/Rückschreiben von Registern ist schlichtweg Routine. Das überschätzt du. Außerdem könnte man solche Sachen auch in Macros packen. Dann kann man nicht vergessen. Allerdings ist es lustiger ein C-Programm zu debuggen, wenn die Optimierung einen Code erzeugt, der nichts mehr mit dem Quelltext zu tun hat. Aber auch wenn ich notorischer Assemblerprogrammierer bin möchte ich hier niemand missionieren. Allerdings glaube ich nicht, das sich z.B. Karl-Heinz so gut mit C auskennen würde, wenn er kein Assembler könnte. MfG Spess
spess53 schrieb: > Allerdings ist es lustiger ein C-Programm zu debuggen, wenn die > Optimierung einen Code erzeugt, der nichts mehr mit dem Quelltext zu tun > hat Die Optimierung darf das Endergebnis nicht verändern.
spess53 schrieb: > Aber auch wenn ich notorischer Assemblerprogrammierer bin möchte ich > hier niemand missionieren. Allerdings glaube ich nicht, das sich z.B. > Karl-Heinz so gut mit C auskennen würde, wenn er kein Assembler könnte. Würde ich so nicht sagen, auch wenn ich mit Z80 Assembler angefangen habe. Ich denke aber auch, dass ein Einstieg in Assembler angebracht ist. Das nimmt dem ganzen oft ein wenig den Zauber des Magischen und zeigt, wie 'primtiv' eigentlich so ein Computer arbeitet. Und gerade auf einem AVR arbeitet man ja doch oft auf Registerebene (auch in C). Ich denke, das Konzept der Register und das einzelne Bits dort etwas bewirken, ist in Assembler unmittelbarer zu verstehen als in C. Ein reales Projekt mach ich persönlich aber ausschliesslich in C. Da will ich mich tatsächlich um so Kleinigkeiten wie SREG sichern oder Registerverteilung nicht kümmern müssen. C ist für mich da einfach näher an der Problemstellung und auf die will ich mich konzentrieren.
Rufus Τ. Firefly schrieb: > dann versteht man vieles von dem, was > nicht-Assemblerprogrammierern bei C große Probleme bereitet; gerade beim > Umgang mit Pointern, Arrays etc. ist es ganz hilfreich, zu wissen, was > der Prozessor/Controller da eigentlich treibt. Ja klar ist es hilfreich zu wisen was da tief unten passiert. Meine Erfahrung ist aber auch: da gibt es einige Hardcore-Assembler-Programmierer, welche dir aus dem Stegreif für jedes Bit in ihren bevorzugten Controller den Hex-Code und die Taktanzahl runterbeten können. Denen geht es gerne mal darum, auf einem 100 fach überdimensionierten Controller oftmals noch das letzte Bit rauszuquetschen, weils halt Spass macht, und nicht weil es durch die Aufgabenstellung oder der vorhandenen Architektur bedingt "notwendig" ist. Und wenn du dann mit "komplizierten" Konstrukten wie Pointern, Arrays, oder gar Objektorientierung oder komplexeren Algorithmen ankommst, schauen sie dich mit großen Augen an, weil sie sowas noch nicht gesehen oder gehört haben, und nur 10 Assemblerbefehle in einem Rutsch im Blick haben.
Hi Es ist doch irgendwie immer lustig, die verzweifelten Versuche einer Rechtfertigung für eine bevorzugte Programmiersprache zulesen. Fakt ist: die Erfinder der verschiedenen Sprachen haben sich auch mit einer Problematik befasst, Programme für die vershiedensten Aufgaben scheiben zu müssen. Da ist eine Steuerung, ein Textprogramm oder gar eine Bildbearbeitung. Mal wird eine hochkomplexe Mathematik benötigt, mal schnelle Suchroutinen und mal nur einfachste Bitverknüpfung. Ob nun Pascal, Basic, C oder Assembler, das Projekt wird irgendwann einmal für die Auswahl einer Sprache entscheident sein. Wenn ich mal ein Projekt mit viel mathematischen Berechnungen haben werde, müsste ich bescheuert sein, dies mit Assembler zu versuchen, obwohl es natürlich machbar ist. Viel wichtiger als die Auswahl einer Programmiersprache ist doch die Fähigkeit, Gedanken für eine Anwendung in eine Programmierung umzusetzen. Assembler muss man genau so wenig oder so viel lernen wie C, Basic oder Pascal. Befehle lernen ist nix anderes wie Vokabeln pauken. Und wenn's mal hängt, tut es ein Blick in die Hilfe. Die eigentliche Kunst ist, mal einfach gesagt, die richtige Wahl der Befehle. "Repeat" oder "While" beispielsweise. Beide Befehle machen im Prinzip das selbe.... Nun ja, ich bin was µC's betrifft ja auch nur ein Hobby-Programmierer. Also Ratsuchende, lasst euch nicht auf Versuche ein, bevorzugte Programmiersprachen zu missionieren. Hier mal ein Beispiel aus meiner Vergangenheit, ein Programm unter Dos mit Turbo Pascal. Es sollte mit einer Steuerung kommunizieren, deren Schnittstelle nicht beeinflussbar war und die hinterlegten Kommunikationsroutinen sehr eigenwillig auf sofortige Reaktion auf Telegramme bestand. Allerdings waren HD-Zugriffe, Druckvorgänge und einige andere Betriebssystemfunktionen strikt dagegen, andere Programmbearbeitungen zuzulassen. So musste die Kommunikation sowie der Druckvorgang durch Interrupts gesteuert werden. Dadurch war es möglich, auch bei Protokollierung durch Druck sowie schreiben von Logfiles die Kommunikation mit der Maschine nicht zu stören. Selbst Netzwerkzugriffe hat diese Programmierung zugelassen. Und natürlich waren es Assemblerprogramme, die in Turbo Pascal eingebettet waren. Also, ich würde da nicht von "Blödsinn" reden, wenn man auf einem DOS-Rechner mal mit der Assemblerprogrammierung der Schnittstelle spielt. Gruß oldmax
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.