Grundkurs/Übersicht AVR-Programiersprachen?

Hallo Jürgen,

Wenn Du neu im Programmiergeschaeft bist, wuerde ich ueberlegen, zuerst C zu lernen. Diese Programme sind am Anfang leichter zu verstehen. Danach kann man so langsam Assembler einflechten. Sogar bei vielen uC Compilern innerhalb von C Routinen. Man nennt das dann Inline-Assembler.

Ich kenne nur MSP430. Dazu gibt es sogar ein deutschsprachiges Buch von Lutz Bierl im Franzis Verlag.

C und Assembler kann man ueber gute Buecher lernen. So habe ich das gemacht. Allerdings sind diese Schinken nun um die 20 Jahre alt und alle in Englisch. Sollte aber kein Problem sein, in einer guten Buecherei etwas neueres zu finden.

Wenn Du Dich schon auf AVR festgelegt hast, sieh mal nach Foren in dieser Richtung. Viele davon sind nun auf Yahoo. Leider, denn das User Interface ist nach meiner Meinung sehr umstaendlich.

Danach oder sogar parallel wuerde ich ein paar Prototypen Boards mit Flash Devices besorgen von Olimex oder sonstwo, einen Compiler (in abgespeckter Version meist umsonst) und dann losprogrammieren. Erstmal eine LED blinken lassen und dann sachte an hoehere Dinge herantasten.

Gruesse, Joerg

"Jürgen Hüser" schrieb:

Ich werde wohl selbiges machen - cc5x (für PICs) hat mich nicht wirklich überzeugt. Die Freeware-Version des Compilers kann nur bis 1024 Instruktionen, keine Optimierung des Codes und die Vollversion ist auch schon für Singleuser relativ teuer.

Für AVRs gibt es ein etwas umgebautes GCC, AFAIK absolut kostenlos und ohne jede Beschränkung.

Schau dir mal

an. In der Wiki gibt es glaube ich einen ziemlich guten Workaround für C.

Ich weiß nicht genau, wie GCC verfährt - ob es eine Assembler-Datei erstellt. Wenn es das macht, kannst du die Programme sicher durch einen Simulator schicken.

Ich finde, bei Assembler ist der Aha-Effekt nicht so groß wie bei C. Vor allem, weil du eingentlich nicht viel falsch machen kannst. Wenn gröbere Fehler drin sind, meldet es der Compiler.

HTH

Chris

--
www.hobby-elektronik.de.vu
Achtung: E-Mail-Adresse im "From" ungültig!
Verwendet hobbyelektronik at gmx dot net

Also dann solltest du es einmal mit BASCOM versuchen, das ist ein Basic-Compiler für AVR. Ich selbst benutze zwar C, aber dieser Bascom scheint ganz gut zu sein, und da du schon mal GW-Basic programmiert hast, istg es wahrscheinlich die beste Wahl. Assembler macht heute wirklich nicht mehr viel Sinn, es benutzen heute nur noch Dinosaurier und Freaks. In ganz ganz zeitkritischen Routinen kann man Inline Assembler verwenden, aber das ist bei den heutigen Controllern eignetlich auch nicht mehr nötig.

Bascom-Compiler :

vieleicht schaust du dir auch mal C ( Codevison AVR ) an : http://www.hpinfotech.ro

Am besten währe für den Einstieg ein ATMEGA16 oder größer mit einen JTAG ICE Incircuitemulator. Mit dem kann man programmieren, sowie sich das Programm schritt für schritt anschauen und debuggen. Ich weiß jetz nicht ob das mit Basic geht, aber mit C auf jeden Fall.

Andreas

Servus,

ich bin gerade auch dabei mich in die Welt des µC's einzuarbeiten. Ich kann die Seite

nur empfehlen! Als Software benutze ich das kostenlos erhältliche WinAVR sowie die Software AVR Studio von Atmel zum simulieren. Funktioniert einwandfrei! Ich programmiere mit C im Editor, importiere dies in das AVR Studio (Version

4) und kann dort das ganze simulieren, debuggen, einzelne Befehle nacheinander ausführen, einen Blick den Ausgewählten µC (Register, Ein-/Ausgänge,...) werfen usw...

Hier noch eine Doku, mit der man auch viel anfangen kann:

Gruß Chris

Servus,

ich bin gerade auch dabei mich in die Welt des µC's einzuarbeiten. Ich kann die Seite

nur empfehlen! Als Software benutze ich das kostenlos erhältliche WinAVR sowie die Software AVR Studio von Atmel zum simulieren. Funktioniert einwandfrei! Ich programmiere mit C im Editor, importiere dies in das AVR Studio (Version

4) und kann dort das ganze simulieren, debuggen, einzelne Befehle nacheinander ausführen, einen Blick den Ausgewählten µC (Register, Ein-/Ausgänge,...) werfen usw...

Hier noch eine Doku, mit der man auch viel anfangen kann:

Gruß Chris

Wenn man schnell Ergebnisse erzielen möchte mag das OK sein. Aber wenn man schon mal programmiert hat würde ich für den Einstieg bei Mikrocontrollern Assembler empfehlen. Dann fällt es einem sehr viel leichter die Programme in C zu schreiben weil man den Controller schon sehr gut kennt. (Sowohl dessen Stärken als auch die Problembereiche)

Wenn man noch gar nicht richtig programmiert hat (auf PC oder sonstwo) würde ich nicht bei Mikrokontrollern anfangen weil dann der Frustfaktor hoch sein wird. (Ist der Fehler in der HW oder in der SW oder bin ich nur zu blöd?)

Tschüss Martin L.

Jürgen Hüser schrieb:

Im Gegensatz zu den bisherigen Tips würde ich dir den Einstieg mit Assembler empfehlen. Nur so versteht man wirklich was die Maschine macht. Und wenn man mal die grundsätzlichen Dinge in ASM erlernt hat fällt der Umstieg auf C einfacher.

Ich würde dir

und

empfehlen. Wenn du dann da mal ein paar Sachen gemacht hast dürfte C und dazu auch

interessant werden.

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

Wenn es aber schon 10 Jahre her ist, wird vielleicht nicht mehr soviel davon da sein. Und fuer einfache Experimente ala "hui, da leuchtet eine LED" mag Assembler reichen, aber meist will man ja doch etwas komplexere Programme schreiben.

HW-Fehler kann man z.B. durch den Einsatz geeigneter dev-boards (z.B. stk500) ausschliessen.

Ich wuerde daher auch ganz dringend empfehlen, etwas C zu lernen (dazu gibt es auch mehr als genug Literatur). Dann kann man sich gerade fuer die AVRs online genug Programme runterladen, lesen, verstehen und abaendern. IMHO fuehrt das am schnellsten und nachhaltigsten zu Erfolg.

Entwicklungsumgebungen gibt es da auch genug. Zum einen der schon erwaehnte GCC (benutze ich unter Linux, geht aber sichr auch irgendwie unter Windows), fuer Windows gibt es sonst das WinAVR. In der Uni benutzen wir Codevision, das ist zwar nicht kostenlos, dafuer macht es aber einen sehr maechtigen Eindruck. Simulatoren gibt es ebenfalls sowohl fuer Windows als auch fuer Linux.

Bjoern

Hallo Bjoern!

Mag sein, aber ohne das Grundverständnis für die einzelnen Register ist es IMHO schwierig, ein komplexeres Programm zu erstellen.

WinAVR ist die Windows-Version von AVR-GCC.

Gruß Thorsten

--
Kunst kommt aber von 'können',
nicht von 'kennst du schon den neuesten trick?'
   Gunther in oecher.computer zum Thema "Gutes Webdesign"

Wozu soll man das Wissen? Nur des Wissens wegen? Wen interessiert es, welche mov oder ld oder wie auch immer "asm" Befehle notwendig sind um z.Bsp x = x + 3 zu berechnen?

Bevor du zum ersten mal Auto gefahren bist, hast du auch erst Mototrenbau studiert?

Also beim AVR kann man alle Hardwareregister für die Perepherie auch in einer Hochsprache programmieren und auch verstehen.

Und was ist wenn mann mal einen anderen Prozessor/ Familie verwenden will? Fängt man daann wieder von vorne an den neuen Assembler zu lernen, und schmeißt seinen mühsam erarbeiteten Code weg ?

Und wenn man mal die grundsätzlichen Dinge in ASM erlernt hat

Mann sollte schon Hexadezimal und binär rechnen können, aber warum erst Assembler lernen?

Andreas

Wieso das denn?, das muß der Compiler Wissen und nicht ich. Gewisse Dinge sollte man schon Wissen, das stimmt. Mit Hintergrundwissen kann man sicher effizienter programmieren. Aber gerade komplexe Programme sind einfacher in einer Hochsprache.

Andreas

Um einschätzen zu können ob das was du machst auch Sinnvoll ist oder ob man es nicht besser machen kann. Du weist ja auch das dein Auto x Liter Benzin/Diesel/m^3/kWh pro 100km verbraucht. Natürlich abstrahieren die Hochsprachen die Hardware auf Variablen und Zeiger. Aber gerade bei uC's, wo die Recourcen beschränkt sind, kann es sinnvoll sein sich etwas mehr mit der HW auseinanderzusetzen. So könnte der OP in C, wo es bekannterweise keinen boolean gibt, ja einen Integer oder gar Long benutzen um dort eine 0 oder 1 hineinzuschreiben. Weil er aber nie sich mit der Assemblerprogrammierung auseinandergesetzt hat weis er nicht das dies viel zu viel Speicher/Rechenzeit kostet. (Der Compiler wird schon merken das ich da nur ne 1 oder

0 rein schreibe ...) Irgendwann bekommt er mit das es nicht so das wahre ist und benutzt einen Byte. Er hat zwar schon ne Idee von Bitfeldern, glaubt aber das Zugriffszeit zu lange dauert weil man ja x mal schieben, AND-Verknüpfung und einen Vergleich machen muss, weil er nicht weis das es dafür spezielle Operationen gibt. Entsprechende Probleme können auch mit den Zeigern auftreten weil der AVR für Flash/EEprom/SRAM einen getrennten Adressraum hat. Es ist halt einfach nützlich wenn man wenigstens eine grundlegende Idee hat was der C-Compiler später für einen Code erzeugt und welche Möglichkeiten der uC generell bietet.

Auf älteren x86'ern war es z.B. schneller inc ax; inc ax; inc ax als add ax,3 zu benutzen weil der Addierer nicht so fix war. Der Compiler erzeugt dir u.U bei sowas brav ein add ax,3.

Aber besser geht es wenn du es vorher mal mit Assembler versucht hast. Du sollst es ja nicht ewig benutzen, aber mal ein kleines Projekt in Assembler macht IMO viel Sinn.

Du hast auf jeden Fall das Grundlegende Konzept dahinter verstanden und kennst div. Fallstricke. Es wird dir mit Kentniss der Assemblersprache auf dem einen uC viel leichter fallen sie auf dem anderen zu lernen. Mit all den Vorteilen die das mit sicht bringt.

*ironie* Warum soll ich Hex-Zahlen beherschen wenn mir der Compiler eh alles in Dezimal versteht */ironie*

Tschüss Martin L.

Und wie erwirbt man sich Hintergrundwissen? Learning by doing.

Tschüss Martin L.

Andreas Ruetten schrieb:

Um effektive Programme schreiben zu können.

Wissen wie etwas funktioniert kommt leider oftmals viel zu kurz.

Es ist aber evtl. ganz geschickt zu wissen warum x /= 256; auf dieser Maschine zigmal schneller und kleiner ist als x /= 255;

Nein. Ich hab auch nicht Mikrosystemtechnik studier bevor ich mit der µC-Technik angefangen habe.

Aber ein gewisses Grundverständnis der Maschine Auto wird einem auch in der Fahrschule vermittelt. Die Maschine Auto ist, im Gegensatz zu einem µC, für den Bediener(Programmierer) auch wesentlich unkomplexer.

Der Stackmechanismus ist z.B. in C garnicht zu ersehen.

Kennt man einen ASM kennt man alle. Ich hab mit den AVR's auch nicht in ASM angefangen da ich auf dem 8051 recht viel in ASM gemacht habe. Heute fällt es mir leicht z.B. auch den Assemblerquelltext für einen Itanium zu lesen und halbwegs zu verstehen was da passiert.

Um eben diese Grundlagen zu beherschen.

Was ist denn so schlimm daran von ganz unten anzufangen? Zumindest am Anfang? In der Grundschule beginnt man doch auch mit den Grundrechenarten und nicht mit der Integralrechnung.

--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

Ja, aber das steht alles im Datenblatt.

Heutige Controller sind so schnell, das man sich darüber keinen Kopf machen muß. Davon mal abgesehen gibt es gut optimierende Compiler.

Es wird dir mit Kentniss der Assemblersprache

Also, ich habe vor ca. 16 Jahren auch mit Assembler angefangen ( 8051 / 6502 ), und ja es ist besser grundsätzlich zu verstehen wie ein Mircocontroller funktioniert. Aber es gibt eben Leute die wollen nur mal eben ein Display ansteuern, LED Blinken lassen oder sonstwas. Und da ist ein BASCOM auch nicht schlecht, weil der sogar schon LCD Routinen fertig drin hat.

Andreas

Natürlich steht das drinn. Aber das Hintergrundwissen aus dem Datenblatt muss man irgendwann mal gefestigt haben. Und das geht IMO am besten in dem man einfach mal ein kleines oder mittelgrosses Projekt in Assembler schreibt.

So? Dann unterstelle ich dir einfach mal das die Controller die du benutzt für ihre Aufgaben überdimenioniert sind. Aber: Es geht ja nicht immer nur nach Geschwindigkeit sondern eben so oft um eine präzise Zeitbestimmung. z.B. wenn du ein Signal via DDS erzeugen willst ist es von größter Bedeutung ob die Schleife nun 9 oder 10 Takte braucht weil sonst deine erzeugte Frequenz schlicht nicht mehr stimmt. Wie willst du das mit einem Compiler machen? Erst schleife Programmieren, dann gucken was für ne Freuqenz rauskommt und dann auf die Taktanzahl zurückrechnen?

Und wehe es geht nicht. Dann ist das Geschrei groß und man muss sich das Hintergrundwissen doch aneignen. Schade um die Zeit die man vorher verschwendete.

Tschüss Martin L.

Wo sollte da der Unterschied liegen zwischen C und Assembler. Verfetigt sich Wissen in C nicht oder was.

Bei den heutigen Preisen kann man auch schon mal überdimensionieren. Wenn mann natürlich 1 Million Stück verkaufen will, da mags ja angehen.

Davon mal abgesehen, der Code der zum Beispiel mein Keil Compiler in der hohen Optimierungsstufe raushaut, kann ich auch von Hand kaum noch optimieren.

Das ist also deine typische Einsteigeraufgabe ?

Schleifenprogrammieren ist immer fürn Arsch! Was ist mit asynchronen Ints ? Wie berechnest du die? Ja es soll auch Leute geben, die superoptimierten Code zusammengedengelt haben, um in einem PIC USB zu implemetieren. Andere Leute nehmen dazu einfach einen Controller mit USB.

Diese Leute schreien wohl erst recht wenn die den Code fürs Display selber schreiben müssen, also was solls.

Andreas

Matthias Weißer schrieb:

Die Wahrscheinlichkeit, dass man bei der Umsetzung eines Algorithmus in Befehlszyklen Fehler macht, ist drastisch höher, damit auch der Frustfaktor. Es braucht viel länger, bis man ein funktionierendes Ergebnis hat, aber gerade am Anfang sind Erfolgserlebnisse wichtig. Beim Compiler weiß man zumindest, dass er aus

x /= 256;

irgendwas machen wird, was x durch 256 teilt (wenn man mitdenkt weiß man auch, dass das eine Rechtsverschiebung um 8 Stellen ist) und dass der Code nicht etwa

x = ((x / 256) & 0xff) | (x & 0xff00);

machen wird. In purem Assembler können einem solche Dinge dagegen schnell unterlaufen.

Die IO-Register werden ohnehin in Assembler und C in nahezu gleicher Primitivität gehandhabt. In deren korrekter Benutzung (für die man im Wesentlichen vor allem das Datenblatt ordentlich lesen können muss -- und dafür braucht man halt benutzbares technisches Englisch) liegt der wesentliche Schlüssel zum Erfolg mit Controllern.

Codeeffizienz ist zweifellos auch mal wichtig, aber Korrektheit des Codes ist am Anfang sehr viel wichtiger. Gerade die AVRs haben oft genug so viele Reserven, dass man sie selbst mit unoptimiertem Compilercode laufen lassen könnte, ohne dass die Erfüllung der Aufgabe gefährdet wird.

Was ich aber in jedem Falle verfechte ist die Idee, dass jemand, der Controller programmiert, auch wirklich regelmäßig einen Blick auf den generierten Assemblercode haben sollte. Assemblercode lesen ist viel einfacher, als ihn selbst zu schreiben (er ist ja syntaktisch bereits fehlerfrei), und man bekommt auf diesem Wege über kurz oder lang dasselbe gute Gefühl für die zugrundeliegende Maschine.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc

Jürgen Hüser schrieb:

Zwar würde ich dir auch eher zu C als Programmiersprache raten, aber falls du dich mit BASCOM anfreunden kannst/willst, dafür gab es vor einiger Zeit eine recht gute deutschsprachige Einführung (die auch die AVRs selbst gut erklärt hat) im FUNKAMATEUR. Die Hefte solltest du beim Verlag noch kaufen können, vielleicht findest du ja außer dem AVR-Teil darin ohnehin noch andere interessante Dinge fürs Hobby nebenbei mit.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc