Hallo, in avrasm.txt ist eine Assembler-Einführung, die so ziemlich ganz von vorne anfängt. Ich hatte den Text geschrieben, um mich mal systematisch mit der Materie zu beschäftigen. Das ganze versteht sich als Vorbereitung zB. auf das Tutorial in mikrocontroller.net. Es wäre nett, wenn sich ein Assembler-Profi das mal anschauen würde und eventuelle sachliche Fehler rückmeldet. Danke, Gerhard
Lockerer Schreibstil, liest sich gut. Nicht unnötige Worte mit der Erklärung von ALU/Steuerwerk/Rechenwerk usw. vergeudet (gut so - das bringt nämlich zum Einstieg keinen Nutzen). Insgesamt für Anfänger sehr wahrscheinlich gut "verdaubar". Kritik: - Ich würde vermuten, daß ein Einsteiger sich weniger dafür interessiert wie die Assembler-Mnemonics in Opcodes umgesetzt werden. (evtl. als Zusatz präsentieren?). - Zeile 321-324: inhaltlich falsch. MC erkennt nicht das "Ende der Befehle..." - Schreib noch irgendwo rein warum der stackpointer in den Beispielen nicht initialisiert werden muß, bzw. besser: initialisier ihn einfach. Das ist ja der Anfängerlieblingsfehler Nr.1. - den Text zwischendrin mit Überschriften versehen oder abgesetzte prägnante Stichworte einfügen (der Leser will wissen was er liest bzw. er will durch den Text geführt werden). Besonders in Zeile 535 ist mir dieser Umstand aufgefallen. Tippfehler (soweit ich diese beim Schnelllesen gefunden habe): Zeile 143: "Ziffern" 242: Übertrags-Fähnchen statt Vortrags...?? 251: Negative 345: sukzessive Das meine "Kritik" mehr Raum einnimmt als der "Lob"-Abschnitt liegt nicht an deinem Text, sondern daran, daß sich leicht und mit wenigen Worten ein "GUT" bis "SEHR GUT" ausdrücken läßt, die Verbesserungspunkte hingegen mehr Platz benötigen. Aber danach hattest du ja auch gefragt. Schmittchen.
Hallo Schmittchen, vielen Dank für die Hinweise, ich werde das entsprechend einbauen. Wundert mich, daß so wenig sachliche Fehler enthalten sind. Leute, haltet Euch bitte nicht zurück .. :-) Ansonsten würden mich natürlich auch Hinweise von echten Assembler-Anfängern interessieren, für die der Text ja letztendlich geschrieben ist. Insbesondere, wenn bestimmte Sachen unverständlich bleiben weil doch noch etwas vorausgesetzt wird. Gerhard
Hi, Zeile 350: "Port D" anstatt "Port C" Ansonsten kann ich mich (als AssemblerEinsteiger) Schmittchen nur anschliessen. Gruss, Thorsten
Hallo, hier ist die überarbeitete Version der Assembler-Einführung mit Korrekturen und Ergänzungen (stack, interrupts etc.). Gerhard
Was hast du mit diesem Text vor, wie willst du ihn verwerten? (Hier, also irgendwo in den Tiefen eines Webforums ist der Text denkbar schlecht aufgehoben). Hast du schonmal darüber nachgedacht ihn Andreas anzubieten, damit er ihn evtl. von seinen TutorialSeiten ausgehend verlinkt (evtl. etwas html-aufbereitet und als Grundlagenartikel)? Möglicherweise läßt sich dein Text auch in die "Artikelreihe" einordnen. Andreas sollte diese aber dann auch deutlicher präsentieren, evtl. als Link auch in der linken Navigationsleiste. Schmittchen.
Ich hab mal einen Direktlink in die Linksammlung gesetzt...
Hallo Schmittchen, Der Text selbst ist öffentliches Gemeingut (OK, public domain klingt echt besser). Jede/r kann damit machen wozu er/sie lustig ist. Ich warte erst mal, ob noch sachliche Fehler gefunden weren. Und irgendwann werde ich die Einführung auf meine web site stellen, die momentan noch im Aufbau ist. Den Text habe ich primär entwickelt, um mich slbst in die Materie einzuarbeiten. Insofern sehe ich die Operation schon mal als Erfolg an. Ansonsten habe ich den Eindruck, ein Crash-Kurs in Sachen Assembler und AVR würde Sinn geben. Ich meine damit so etwas mit PC und Beamer und STK500 etc., wie Schule halt. Falls jemand im Raum Dresden ist und ähnliches denkt, möge er sich doch bitte mal bei mir melden. Gerhard
3. Programm : -------------- .... ... Dieses Spielchen geht solange, bis keine Befehle mehr gefunden werden, worauf der MC wieder zum Beginn des Programmspeichers geht und das Programm wieder von Anfang an abarbeitet. Diese Schleife macht der MC automatisch, ohne daß man ihm das sagen muß. ********************************************************** Das ist eine sehr gefährliche Meinung, die MC springt eben nicht autom. zum Programmanfang. Will also sagen: Programme immer mit einem def. Rücksprung beenden!!! Sonst recht gut und übersichtlich. Den Bereich: ********************************************************** 6. "große" Zahlen: ------------------- Hmmm ..., wenn in einem Register nur maximal eine Zahl bis 255 dargestellt werden kann, wie kann ich dann die Zahl 444 speichern ? Antwort: man nimmt halt 2 Register. ldi r16, 0b10111100 ; dezimal: 188 = 444 - 256 ldi r17, 0b00000001 ; dezimal: 1 ********************************************************** könnte man eventuell etwas ändern. Als Neuer würde ich jetzt erstmal stutzen "wo nimmt der die 256 her ??" Klar,ist 9.Bit, aber man lernt ja erst. Weiter unten wird es zwar klar,aber hmmmm. Gruss Uwe Ps. bin zwar aus der Nähe von DD, aber absolut kein Lehrer
Hallo Uwe, /* Dieses Spielchen geht solange, bis keine Befehle mehr gefunden werden, worauf der MC wieder zum Beginn des Programmspeichers geht und das Programm wieder von Anfang an abarbeitet. Diese Schleife macht der MC automatisch, ohne daß man ihm das sagen muß. ********************************************************** Das ist eine sehr gefährliche Meinung, die MC springt eben nicht autom. zum Programmanfang. Will also sagen: Programme immer mit einem def. Rücksprung beenden!!! */ Schmittchen hat das auch behauptet. Aber ich hab das mit dem 4433 getestet und der arbeitet wirklich so. Wie andere Mikrocontroller-Typen das machen weiß ich nicht. OK, ich werde diesen Hinweis dazusetzen: "Es ist aber gute Programmierpraxis, Programme grundsätzlich immer mit einem definierten Rücksprung zu beenden.". /* Antwort: man nimmt halt 2 Register. ldi r16, 0b10111100 ; dezimal: 188 = 444 - 256 ldi r17, 0b00000001 ; dezimal: 1 könnte man eventuell etwas ändern. Als Neuer würde ich jetzt erstmal stutzen "wo nimmt der die 256 her ??" Gut, dann werd ich dazusetzen : "Huch, und wo kommt jetzt die 256 her, die von 444 abgezogen wird ? Antwort: wenn LSB (Bit 0) im dem oberen Byte (in r17) auf 1 steht und alle Bits im unteren Byte (in r16) auf 0 stehen, dann entspricht das bei zusammengefaßter Schreibweise dieser Bitfolge: 0000 0001 0000 0000 | r17 | r16 | Und damit wird die Dezimalzahl 256 dargestellt. Das heißt mit anderen Worten: von der Zahl 444 ist anteilig 256 codiert in dem oberen Byte (in r17) und in dem unteren Byte (in r16) braucht dann nur noch der restliche Anteil codiert zu werden, besagte 188." Das müßte eigentlich narrensicher sein ... :-) Danke, Gerhard
> Aber ich hab das mit dem 4433 getestet Das glaub ich dir. > und der arbeitet wirklich so. Das glaub ich nicht. Nach der Auführung des letzten "gewollten" Befehls springt der Programmcounter auf die nächste Speicherstelle und die dort stehenden Daten werden als nächster Befehl interpretiert. Und da der Inhalt dieser Speicherstelle nicht definiert ist (wozu auch), kann jetzt alles mögliche passieren. Wenn du einen Rücksprung beobachtet hast, so war das "riesen Glück". (oder evtl. die Vorgabe im Simulator?) Alles unter der Annahme, daß der letzte "gewollte" Befehl kein Sprungbefehl an eine definierte Stelle ist. > "Es ist aber gute Programmierpraxis, Programme grundsätzlich immer mit einem definierten Rücksprung zu beenden.". Es ist nicht nur gute Programmierpraxis, sondern unabdingbar. Schmittchen.
> Und da der Inhalt dieser Speicherstelle nicht definiert ist Obige Aussage war zu allgemein formuliert, für AVRs ist der Programmspeicher (Flash) praktisch an den "freien" Stellen mit 0xFF belegt (weil vorm Brennen immer gelöscht wird). Auf die Schnelle habe ich keinen Opcode gefunden, der auf 0xFF 0xFF paßt. Was dann genau passiert weiß ich nicht, so wie es aussieht ist das Verhalten danach undefiniert (die Speicherstelle aber nicht). Schmittchen.
Hallo Schmittchen, OK, ich werde die Sache mit dem automatischen Loop ganz rausnehmen. Der Vollständigkeit halber häng ich ein Programm an, mit dem ich den Sachverhalt auf dem 4433er getestet hatte. Einen opcode 0xFF im Befehlssatz der AVR hab ich auch nicht gefunden.
Und angenommen am Ende das Programms steht z.B. .db "Ich bin ein String",0 ? Dann läuft dein Programm Amok.
Hallo, anbei ist eine neue Version mit den gewünschten Änderungen und einigen mehr oder weniger kosmetischen Korrekturen. Gerhard
while1:
subi r17, 1
breq endwhile1 ; wenn Zero-Flag gesetzt
nop ; Päuschen
rjmp while1
endwhile1:
rjmp loop1
--------------------------------------------------
Noch eine Frage: Warum wird beim obengenannten Beispielprogramm subi und
nicht sub verwendet. Muss man subi verwenden weil nur subi einen
Zero-Flag setzt wenn r17 0 ist und sub nicht. Den Flag braucht ja breq
damit er dann ueberpruefen kann ob r17 gleich 0 ist.
subi wie der Name schon sagt Substract immediate. Register - Konstanste (hier 1). Hat den Vorteil das ich nicht erst ein weiteres Register mit dem 1 laden muss.
danke doch brauche einen zufallsgenerator der in assembler geschrieben ist und mit einem 68k läuft. mfg
Hi, super der Text. Nur mal so ne dumme Frage . Du beschreibst bei 8 MHz 3 Zyklen = 345 Nanosek. . Hm ich bin Assembler Anfaenger wie berechne ich die Zeit? Bei BAscom war es einfach eine Pause von 5 ms zu erzeugen mit Waitms 5 . Kannst du darauf nochmal aneher eingehen ?
Hallo Dirk, Du hast 30 Nanosekunden zu schnell gelesen :-) Im Text steht: "bei 8MHz also 375 Nanosekunden" und das ist 1 Sekunde (also 1 Milliarde Nanosekunden bzw. 1 Million Mikrosekunden bzw. 1000 Millisekunden) geteilt durch 8 Millionen mal 3. Gerhard
Hi, oh hast recht :( Habt ihr fertige Windows Programme für Zeitschleifen? wenn ich es richtig verstanden habe kommt es noch auf den Befehl drauf an. Einige Befehle nehmen nur ein zyklus ein anderer 3 . Oder liege ich da falsch? Mfg Dirk
Hallo Dirk, die Zahl der Zyklen je Befehl findest Du im "instruction set" : http://www.atmel.com/dyn/resources/prod_documents/DOC0856.PDF Was die Warteschleifen angeht, kannst Du auch unter "loop generator" oder ähnlich suchen. Recht nützlich finde ich das Makro von Peter Dannegger: http://www.mikrocontroller.net/forum/read-4-15758.html Gerhard
http://diemer.it-pc.de/avrdlg.html http://www.home.unix-ag.org/tjabo/avr/AVRdelayloop.html Mit der zweiten Version hab ich schon gearbeitet
hallo! ich hab mir erlaubt von der assembler-einfuehrung ein .pdf zu machen, das ein bisschen schoener formatiert und somit lesbar ist. ich hab nicht wirklich viel zeit investiert, vielleicht etwas mehr als eine stunde. auf jeden fall moechte ich es euch zukommen lassen, natuerlich nur mit zustimmung vom urheber ;) lg andi
Hallo allesamt! Nach sowas habe ich schon lange gesucht! Coole Sache! Das muss unbedingt weitergemacht werden! ################ Florian Wolling# ################
Hi Gerhard, Du hast mir gerade mit Deinem Text die negativen Zahlen in Assembler nochmals klar gemacht. Danke! :-) Sebastian
Na ja, wo sich jetzt schon alle bedanken, hänge ich mich auch noch drann. Ich habe zwar mit dem AVR angefangen um C zu lehrnen, aber ich denke wer mit einem uC arbeiten will muss mindestens etwas Vertändniss über dessen Befehlssatz haben. Mir war daher dein Tut eine tolle Hilfe, es gibt kaum einen besseren Weg einen uC zu verstehen als etwas asm auf im zu betreiben (das möchte ich hiermit auch allen anderen 'Hochsprache' vorziehenden , auch Basic Freunden etc. nahelegen). Vieles von deinem Tut kann man dann direkt in die Arbeit mit anderen Sprachen einbringen. Vielen dank für die Menge Arbeit, die einem Haufen Menschen mindesten ein Stück weiter gebracht hat :-) Gruß Bernhard
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.