Assembler lernen für Mikrocontroller-Programmierung

[Dennis (Gast)]

Hallo,


ich bin neu in dem Thema, und möchte erstmal Assembler für 
Mikrocontroller lernen.

Ich hab mir meine eigene Platine mit einem Atmega8 gebastelt von der ich 
4 Led´s und einen Modellbauservo programmieren könnte. (Bilder im 
Anhang)

Die Led´s schaffe ich zu programmieren, mehr aber auch nicht.

Könnt Ihr mir Bücher für dieses Thema empfehlen oder habt Ihr andere 
Ideen für mich die mich in dem Thema weiterbringen.

Ich denke für mich ist es gut erstmal alles Grundlegende in Assembler zu 
lernen um zu verstehen "Warum".


Danke schonmal.

Gruss Dennis

[Thomas E. (thomase)]

Dennis schrieb:
> Die Led´s schaffe ich zu programmieren, mehr aber auch nicht
Na, das ist doch ein Anfang. Zumindest bist du nicht so behornt wie 
manch anderer, der als kleines Anfängerprojekt mal eben einen 
Autopiloten für einen Airbus bauen will.

Dennis schrieb:
> Könnt Ihr mir Bücher für dieses Thema empfehlen oder habt Ihr andere
> Ideen für mich die mich in dem Thema weiterbringen.
Hast du da:
http://www.mikrocontroller.net/articles/AVR-Tutorial
schon reingeguckt?


mfg.

[asm (Gast)]

Dennis schrieb:

> Könnt Ihr mir Bücher für dieses Thema empfehlen oder habt Ihr andere
> Ideen für mich die mich in dem Thema weiterbringen.

Ich habe 2000 mit den Klassik-AVR damit angefangen:
http://www.amazon.de/AVR-Mikrocontroller-Praxis-m-CD-ROM-Safinaz-Volpe/dp/3895760633/ref=sr_1_2?ie=UTF8&qid=1367614697&sr=8-2&keywords=avr-mikrocontroller+praxis

Mega AVRs gab es damals noch nicht, aber der Mega8 ist ja auch schon 
sehr veraltet. Ich finde dieses Buch für den Assembler-Einsteiger recht 
gut.
Die Hälfte des Buches besteht allerdings aus einer Referenz zum 
Befehlssatz in deutsch.
Aber für den Anfang ist das auch nicht schlecht.

Übrigens - Bilder mit 3,8MB schaue ich mit meiner langsamen 
Internetverbindung nicht an!

[Spess53 (Gast)]

Hi

Erste Referenz:

http://www.atmel.com/Images/doc0856.pdf

MfG Spess

[egbert (Gast)]

GENIAL!

6,5 MB für zwei vollkommen aussagefreie Bilder!

TAGESREKORD!!!

[Wegstaben V. (wegstabenverbuchsler)]

egbert schrieb:
> GENIAL!
>
> 6,5 MB für zwei vollkommen aussagefreie Bilder!
>
> TAGESREKORD!!!

Kein Wunder, daß die Telekom die Bandbreite drosseln will, wenn 
vollkommen ohne Nachdenken riesen Datenmengen hoch- und 
runtergeschaufelt werden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Dennis schrieb:
> (Bilder im Anhang)
Nichts gegen Bilder mit 6,5MByte, wenn sie nötig und brauchbar sind. 
Aber wenn du so ein Bild ohne jeglichen Informationsverlust um den 
Faktor 20 reduzieren kannst, dann werden es dir Hilfewillige danken, 
denn nicht jeder hängt an einer hochpotenten DSL-Strippe...

Dennis schrieb:
> möchte erstmal Assembler für Mikrocontroller lernen.
> Die Led´s schaffe ich zu programmieren, mehr aber auch nicht.
Also gut, das bedeutet also, dass du noch ein wenig mit diesen LEDs und 
einem Taster herumspielen kannst (Lauflicht, mitverstellbarer 
Geschwindigkeit, programmierbar). Danach siehst du dir mal die serielle 
Schnittstelle an, dann steuerst du ein LCDisplay an, dann das Servo 
(erst mit delay, dann mit Timer). Also einfach Schritt für Schritt 
weitermachen.

Hier gilt: der Appetit kommt mit dem Essen... ;-)

[Mr. Tom (Gast)]

Dennis schrieb:
> oder habt Ihr andere Ideen für mich die mich in dem Thema weiterbringen.

Das Internet wäre eine weitere Anlaufstelle. Alleine über die Suche hier 
im Forum finden sich fast 2000 Threads, die sich mit Servoansteuerung 
beschäftigen. Da sind auch viele Erklärungen zur Erzeugung der Pulse mit 
einem Timer und Beispielcode in AVR Assembler bei.

[Paul B. (paul_baumann)]

Hier ist auch noch eine Seite zu diesem Thema:
http://www.avr-asm-tutorial.net/avr_de/index.html

MfG Paul

[F. F. (foldi)]

asm schrieb:
> Die Hälfte des Buches besteht allerdings aus einer Referenz zum
> Befehlssatz in deutsch.

Diesen Satz ließt man auch sehr häufig unter Buch Kritiken. Ja wovon 
soll da sonst was stehen? Es ist doch nun mal der Befehlssatz den du 
brauchst.
Es kommt nur drauf an wie gut jemand diesen Befehlssatz und die Sprache 
rüber bringen kann.

Hab mir hier ein Buch gekauft, von Schwabl-Schmidt, das kann ich nicht 
mal lesen. Sicher, das ist so ein Guru und wahrscheinlich hat er 
Assembler noch vor der Muttersprache gelernt. Mir wird das Buch 
(vielleicht auch seine anderen nachfolgenden) erst in ein paar Jahren 
etwas nützen.
Am besten finde ich im Moment noch das "Instruction Set" von AVR selbst. 
Spess53 wies da schon weiter oben drauf hin.
Außer die Blätter (ich würde das immer ausdrucken) ist es zudem noch 
kostenlos.

[Rolf H. (flash01)]

ich hatte mir auch ein Buch von Amazon zugelegt.

Mikrocomputertechnik mit Controllern der Atmel AVR-Risc-Familie

5.Auflage von Günter Schmitt
oldenburg.de   (ISBN 978-3-486-58988-7)
Speziell für Mega8

Spess hat natürlich Recht, das Instructions Set von AVR ist nicht
zu übertreffen.

Grüße

Rolf

[Bernd_Stein (Gast)]

Hallo,

für alle die sich auch dafür interessieren kann ich das hier empfehlen :

http://www.weigu.lu/a/index.html



Bernd_Stein

[Spess53 (Gast)]

Hi

>für alle die sich auch dafür interessieren kann ich das hier empfehlen :

>http://www.weigu.lu/a/index.html

Nett, 'F1 Assembleranweisungen', PDF mit 2 A4 Seiten fast 27MB. Und 
nicht mal für AVR-Assembler2.

MfG Spess

[Sherlock Holmes sein Schwager (Gast)]

Spess schrieb:
>Nett
Richtig. Das ist nett, es ist nämlich in deutscher Sprache verfasst.

>'F1 Assembleranweisungen', PDF mit 2 A4 Seiten fast 27MB.
Ich schlage vor, die richtigen Dateien herunterzuladen. Allein der
1. Teil hat schon 110 Seiten...


-Sherlock Holmes sein Schwager-

[Spess53 (Gast)]

Hi

>Ich schlage vor, die richtigen Dateien herunterzuladen. Allein der
>1. Teil hat schon 110 Seiten...

Welcher 1.Teil? 'F1 Assembleranweisungen' beinhaltet die 'Assembler 
directives' der Assembler Hilfe des AVR Studios. Und das sind nur 24 
Anweisungen die kaum 110 Seiten beanspruchen.

MfG Spess

[Sherlock Holmes sein Schwager (Gast)]

>Welcher 1.Teil?

Preisfrage: Wieviele erste Teile kann es geben?

Du hast auch schon intelligentere Fragen gestellt und wesentlich bessere
Antworten gegeben als im Moment hier...

-Sherlock Holmes sein Schwager-

[Spess53 (Gast)]

Hi

>Du hast auch schon intelligentere Fragen gestellt und wesentlich bessere
>Antworten gegeben als im Moment hier...

Also ich mein das:

http://www.weigu.lu/a/pdf/MICEL_F1_Assembleranweisungen.pdf

Was meinst du?

MfG Spess

[c-hater (Gast)]

Dennis schrieb:

> Die Led´s schaffe ich zu programmieren

Den Code hast du sicher mehr oder weniger irgendwoher kopiert, ohne ihn 
wirklich zu verstehen. Das ist durchaus was anderes als es "schaffen zu 
programmieren".

> mehr aber auch nicht.

Tja, mühsam ernährt sich das Eichhörnchen. Man muß leider immer ganz 
unten anfangen. Das beginnt bei JEDER Sprache damit, daß man erstmal die 
verfügbaren Sprachmittel kennenlernt. Die Referenz für AVR-Assembler 
hast du ja bereits mehrfach im Thread genannt bekommen.

Das Blöde ist nur: Die Kenntnis der Sprachmittel ist zwar die 
unverzichtbare Grundlage, genügt aber leider nicht, man muß sie dann 
auch noch sinnvoll anwenden, um sein Ziel zu erreichen. Leider kann man 
gerade das nicht wirklich gelehrt bekommen, sondern nur selber lernen. 
Indem man es tut, aus Fehlern lernt, wieder tut, usw...

Der Code anderer Leute ist dabei auch immer gut. Man kann daraus viel 
lernen. Manchmal auch, wie man es besser nicht machen sollte. Sowas wird 
dir aber frühestens in ein paar Monaten auffallen...

Viel Spaß. Und wenn's am Anfang auch oft nervt, weil nix funktioniert: 
Immer daran denken: jeder hat mal so angefangen. Es ist definitiv 
möglich, den Scheiß zu beherrschen.

> Könnt Ihr mir Bücher für dieses Thema empfehlen

Fachbücher sind Mist, die kosten nur unnötig Geld und veralten schneller 
als das Papier verrotten kann, auf dem sie gedruckt sind.

Das nötige Faktenwissen kannst du den relevanten Referenzdokumenten 
entnehmen und das Programmieren an sich kann dir niemand beibringen 
außer du dir selbst. Denn das lernt man nur, indem man es tut (bzw. am 
Anfang: es zumindest versucht).

Mit der Zeit lernt man es, seine Programmier-Ziele als logisch 
konsistente Abstraktion formulieren zu können. Das ist der schöpferische 
Teil der Sache. Der Rest, nämlich den Kram dann mit den Mitteln der 
verfügbaren Sprache in ein funktionierendes Programm zu verwandeln, ist 
dann nur noch Handwerk. Eigentlich nur sowas wie eine Übersetzung.

Außer für die C-ler natürlich. Mit DER Sprache gerät schnell mal dieses 
primitive Handwerk zur Kunstform. Aber das ist ein ganz anderes Thema, 
was dich ja glücklicherweise (noch) nichts angeht. Das Problem ist nur: 
Über kurz oder lang wirst du nicht drumrum kommen, den C-Scheiß 
zumindest lesen zu können.

Jedenfalls, wenn du deine Bemühungen, Programmieren zu lernen, nicht 
sehr bald aufgibst, weil du auf den Sachverhalt stößt, daß das alles 
doch verdammt viel ARBEIT macht, bevor irgendwelche nennenswerten 
Erfolge sichtbar werden.

[Tim . (cpldcpu)]

c-hater schrieb:
> Außer für die C-ler natürlich. Mit DER Sprache gerät schnell mal dieses
> primitive Handwerk zur Kunstform. Aber das ist ein ganz anderes Thema,
> was dich ja glücklicherweise (noch) nichts angeht. Das Problem ist nur:
> Über kurz oder lang wirst du nicht drumrum kommen, den C-Scheiß
> zumindest lesen zu können.

Wie sieht es denn dann mit aktuelleren Hoch- und Skriptsprachen aus?
Python? Lua? Java? C#? Objective-C? Javascript? Ruby?

[Thomas (Gast)]

Ist euch eigentlich aufgefallen, dass Dennis nie wieder geantwortet hat?

Es ist eine gute Idee mit Assembler anzufangen.
Aber ich würde damit auch nicht allzu viel Zeit verschwenden und bald 
auf C umsteigen.

BASCOM ist sicher auch OK, wenn es nur darum geht eine Aufgabe schnell 
und pragmatisch zu lösen.
Aber wer höher hinaus will, der kommt um C nicht herum.

> Wie sieht es denn dann mit aktuelleren Hoch- und Skriptsprachen aus?
> Python? Lua? Java? C#? Objective-C? Javascript? Ruby?
Spielt alles auf der von Dennis gewählten Plattform keine Rolle.
Und auch sonst nicht, wenn es darum geht den uC direkt zu programmieren.
Sobald auf dem uC ein OS läuft sieht das wieder anders aus.
Was immer geht ist C++.
Oder halt solche Insellösungen wie BASCOM.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Sherlock Holmes sein Schwager schrieb:
>
> Ich schlage vor, die richtigen Dateien herunterzuladen. Allein der
> 1. Teil hat schon 110 Seiten...
>
Aber nicht von den 110 Seiten abschrecken lassen.
Einfach mal anfangen sich die Sache durchzulesen, dann merkt man relativ 
schnell, ob einem der Kurs zusagt oder nicht. Ich bin jedenfalls froh, 
das es so etwas kostenfrei gibt. Denn da steckt ganz ganz viel Mühe 
hinter.

http://www.weigu.lu/a/pdf/MICEL_MODUL_A.pdf


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hier mal ein gut erklärtes Video :

https://www.youtube.com/watch?v=Q1rR1IgBgcU

Weil dieser Kurs ( von Weigu ) wirklich gut ist hier was dazu :

Beitrag "AVR-Mikrocontrollertechnik-Kursus in Assembler besprechung"


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

Läuft gerade ein Wettbewerb, in dem es irgendwie darum geht, möglichst 
alte Threads wiederzubeleben?

Dann hast du verloren. Die Leiche, die du ausgebuddelt hast, stinkt 
noch. Gerade mal vier Jahre unter der Erde...

[Hans (Gast)]

c-hater schrieb:
> Dann hast du verloren. Die Leiche, die du ausgebuddelt hast, stinkt
> noch. Gerade mal vier Jahre unter der Erde...

... was die beiden Links nicht weniger interessant macht. Danke Bernd 
Stein!

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hab hier noch was gefunden, aber glaubt nicht alles zu 100%, der übt 
praktisch auch noch. Aber er hat auf jeden Fall ein Dankeschön verdient.

https://www.youtube.com/playlist?list=PLJ1mg9IWNoIDCP_2nV5AKcSJSXHqWof0Z

Und noch was zur Motivation :

http://www.avr-asm-tutorial.net/avr_de/beginner/asm_beginner.html


Bernd_Stein

[c-hater (Gast)]

Rolf H. schrieb:

> Spess hat natürlich Recht, das Instructions Set von AVR ist nicht
> zu übertreffen.

Das sehe ich etwas anders, zumindest in einem, allerdings nicht ganz 
unwichtigen Punkt dürfte das "Original" sehr leicht zu übertreffen sein: 
nämlich bei der Darstellung der Verzweigungen.

Man braucht z.B. als Einsteiger doch eine ganze Weile, ehe man dahinter 
kommt, dass es fast die Hälfte davon garnicht wirklich gibt...

Ansonsten aber volle Zustimmung, selten habe ich eine so kurz-prägnante 
und dabei doch leicht verständliche Beschreibung eines µC-Befehlssatzes 
gelesen.

Liegt natürlich durchaus auch daran, dass der Befehlssatz selber einfach 
ziemlich gut durchdacht ist. Es gibt eigentlich nur sehr wenig, was sich 
daran verbessern ließe. Meine persönlichen Favoriten für nachzurüstende 
Instruktionen sind "eori", "cpci" und "cpsne", dafür könnte man ganz gut 
auf "adiw" und "sbiw" verzichten, ganz sicher aber zumindest darauf, 
dass sie sich auch auf R25:R24 anwenden lassen.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Und noch ein anderer Kurs und weitere Informationen :

http://www.gsc-elektronic.net/mikroelektronik/index.html

http://www.anafo.de/N02b_atmega8.htm#b1


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Beschäftige mich gerade hiermit :

http://www.elektronik-labor.de/AVR/KursAssembler/T13asm13.html#1


Bin bei Tag2 und wundere mich das rjmp -1 im Atmel Studio 7 nicht 
funktioniert.

.CSEG                       ;Beginn des Programmspeichers   
.ORG $0000                  ;Anfangsadresse einstellen
 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )
.ORG INT_VECTORS_SIZE       ;Ende der Interrupt-Vektoradressen einfuegen

_reset:                     ;Programmstartaddresse
 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren
 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

 rjmp -1                    ;Sprung auf sich selbst, also Endlosschleife

.EXIT                       ;Ende der Assemblierung

Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> wundere mich das rjmp -1 im Atmel Studio 7 nicht
> funktioniert.

Das funktioniert schon, macht aber was völlig anderes als du glaubst, 
was es machen müsste. Um das zu erreichen, was du willst, musst du das 
so schreiben:

 rjmp PC-1


oder auch so

endless:
 rjmp endless

[c-hater (Gast)]

c-hater schrieb:

>  rjmp PC-1

Mist, falsch.

 rjmp PC

Wäre richtig gewesen.

[Gudrun (Gast)]

c-hater schrieb:
> c-hater schrieb:
>
>  rjmp PC-1
>
> Mist, falsch.

Du solltest auf C umsteigen.
Wird alles a bisserl viel für Dich.

[Einer K. (Gast)]

Bernd S. schrieb:
> rjmp -1

Mein Disassembler sagt:
rjmp  .-2
Für einen Sprung auf sich selbst.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> rjmp PC
>
> Wäre richtig gewesen.
>
Nicht wäre. I S T !

Ist schon blöd, wenn sich Tutoren irren. Rjmp -1 würde ja auf den Befehl 
davor zeigen und nicht auf sich selbst.

Der Simulator ist leider wieder nicht kooperativ. Stürzt bei dieser 
Variante ab. Ausserdem zeigt der Disassembler für diesen Befehl PC + 
$01F3 die .lss-Datei jedoch $C1F2.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Arduino Fanboy D. schrieb:
> Mein Disassembler sagt:
> rjmp  .-2
> Für einen Sprung auf sich selbst.
>
Tja, ist halt Arduino. Warum der erste Befehl rjmp _reset wohl nur ein 
Takt benötigt kriegt so ein Arduino Fanboy wohl auch nicht erklärt oder 
?

Tag3 bringt die Lösung, aber passt halt nicht mit dem Simulator.

" anhalten durch Sprung auf sich selbst: rjmp -1  ; 1100 1111 1111 1111 
"

Bernd_Stein

[Einer K. (Gast)]

Bernd S. schrieb:
> Tja, ist halt Arduino.

Was hat Arduino damit zu tun?

 1aa:  ff cf         rjmp  .-2        ; 0x1aa <main+0x86>

Bernd S. schrieb:
> Warum der erste Befehl rjmp _reset wohl nur ein
> Takt benötigt kriegt so ein Arduino Fanboy wohl auch nicht erklärt oder
> ?
Nö, das ist mir tatsächlich neu!
Dann, bitte, erkläre es mir!

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Arduino Fanboy D. schrieb:
> Nö, das ist mir neu!
> Dann, bitte, erkläre es mir!
>
OK.

" Der erste Befehl eines Programms hat eine um einen Taktzyklus längere 
Ausführungszeit als der gleiche Befehl an anderer Stelle des Programms, 
da hier der Instruction Fetch nicht parallel zur Ausführung des 
vorhergehenden vorgenommen werden kann. "

Das ist aus dem Buch von Wolfgang Trampert Seite 15 des Buches AVR-RISC 
Mikrocontroller und zeigt wieder einmal, das man dem Simulator nicht 
wirklich zu 100% vertrauen darf.

Im Flashspeicher ist die Sache auch nicht richtig abgebildet ( $FFF ).

Was soll der Punkt bei rjmp .-2 ?

-2 müsste jedoch $FFE sein, deswegen Arduino.


Bernd_Stein

[Stefan F. (Gast)]

Warum rechnet ihr überhaupt? Lasst das doch den Assembler erledigen, 
dazu ist er da:

ende:
    rjmp ende

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Warum rechnet ihr überhaupt? Lasst das doch den Assembler erledigen,
> dazu ist er da:
>
Was steht mit in der Threadüberschrift ? Richtig - lernen ;-)


Bernd_Stein

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernd S. schrieb:
> Was soll der Punkt bei rjmp .-2 ?
>
> -2 müsste jedoch $FFE sein, deswegen Arduino.

 Der Punkt ist gleichzusetzen mit PC oder auch manchmal $.

 Wobei, wenn ich mich richtig erinnere, dies auch nicht bei allen
 Compilern gleich behandelt wird, da bei manchen der PC immer noch
 auf rjmp zeigt und erst bei nächstem Befehl (welches nicht existiert,
 bzw. nie geholt wird) erhöht wird.

[Einer K. (Gast)]

Bernd S. schrieb:
> Was soll der Punkt bei rjmp .-2 ?
>
> -2 müsste jedoch $FFE sein, deswegen Arduino.

Ja, das ist Auszug aus einem Disassembler Listing eines Arduino 
Programms.
Aber was Arduino damit zu tun hat, ist doch damit gar nicht ersichtlich.
Denn es ist doch die gleiche Toolchain, welche vom Atmel Studio genutzt 
wird.

Bernd S. schrieb:
> " Der erste Befehl eines Programms hat eine um einen Taktzyklus längere
> Ausführungszeit als der gleiche Befehl an anderer Stelle des Programms,
> da hier der Instruction Fetch nicht parallel zur Ausführung des
> vorhergehenden vorgenommen werden kann. "

So so....
Bernd S. schrieb:
> Warum der erste Befehl rjmp _reset wohl nur ein
> Takt benötigt

Laut AVR Doku braucht rjmp 2 Takte.
Laut deinem Zitat, braucht der rjmp, wenn er als erster Befehl kommt, 3 
Takte.

Wie du jetzt draus auf 1 Takt kommst, kann ich nur deinem 
ArduinoUserHass zuschreiben. Denn rationale Begründungen sind aus deiner 
Argumentation, oder der Doku, nicht zu entnehmen.

Ich schätze mal, dass dir da ein (peinlicher) Lapsus unterlaufen ist.

Tipp:
> Irren ist menschlich.
> Im Irrtum verharren, ist Dummheit.

[michael_ (Gast)]

Bernd S. schrieb:
> Was soll der Punkt bei rjmp .-2 ?
>
> -2 müsste jedoch $FFE sein, deswegen Arduino.

Den .xx kenne ich auch nicht.
Der rjmp macht von Hause aus +1. Deshalb muß man -2 machen, damit man 
wieder vor rjmp landet.
Setze doch aber einfach eine Marke und springe dorthin.
Bei Änderungen kriegt man schnell Schwierigkeiten mit festen Werten.

[(prx) A. K. (prx)]

Es gibt noch eine kleine Feinheit zu beachten. Atmels Software rechnet 
bei Code in Worten, von GNU infizierte Versionen aber in Bytes. Was 
manches -1 zu -2 werden lässt.

[michael_ (Gast)]

Ist eigentlich egal.
Es ist wichtig, was der PC macht.

Für rjmp habe ich hier:
1 Wort
3 Maschinenzyklen
3 Taktimpulse

[c-hater (Gast)]

Bernd S. schrieb:

> " Der erste Befehl eines Programms hat eine um einen Taktzyklus längere
> Ausführungszeit als der gleiche Befehl an anderer Stelle des Programms,
> da hier der Instruction Fetch nicht parallel zur Ausführung des
> vorhergehenden vorgenommen werden kann. "

Selbst wenn das tatsächlich so sein sollte (ich weiss es nicht, die 
Begründung klingt allerdings logisch), ist das doch wirklich ziemlich 
irrelevant gegenüber der Variabilität der sonstigen Sachen, die so 
zwischen Reset-Signal und Programmstart stattfinden können.

Sprich: kein Schwein interessiert's wirklich. Jedenfalls nicht jenseits 
des Simulators. Denn bei den echten Teilen sind die Möglichkeiten, einen 
Reset taktgenau auszulösen, doch ziemlich begrenzt, um nicht zu sagen: 
gleich Null.

[Liebhaber (Gast)]

Schöne Tischdecke

[c-hater (Gast)]

Bernd S. schrieb:

> Was steht mit in der Threadüberschrift ? Richtig - lernen ;-)

Und, hast du?

Die Sache ist doch ziemlich simpel zu verstehen. Der Atmel Assembler 
erwartet
ein absolute Adresse als Eingabe für alle Verzweigungs- und 
Sprungbefehle. Den eigentlich für den Opcode benötigten relativen Offset 
berechnet er aus dem gegenwärtigen PC (genauer: dem PC am Beginn der 
Operation) und dem Sprungziel.

Das bedeutet: wenn man im Quelltext selber mit relativen Offsets 
operieren will (wovon ich dringend abraten würde, weil sehr 
fehlerträchtig, siehe meinen Fehler in diesem Thread) muss man den "PC" 
als Bezug benutzen und zwar genau so, wie ihn auch der Atmel-Assembler 
benutzt.

Andere Assembler haben andere Konventionen. Z.B. halt der des avr-gcc. 
Da werden halt relative Offsets nicht durch PC+- angegeben, sondern 
durch einen schlichten Punkt vor dem Argument und er benutzt als Bezug 
auch nicht die Adresse der Operation selber, sondern die der darauf 
Folgenden. Was bezüglich des zu encodierenden Opcodes durchaus einen 
Sinn ergibt, insbesondere, wenn man die Prüfung auf wrap-arounds 
effizient machen will.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Marc V. schrieb:
> Wobei, wenn ich mich richtig erinnere, dies auch nicht bei allen
>  Compilern gleich behandelt wird, da bei manchen der PC immer noch
>  auf rjmp zeigt und erst bei nächstem Befehl (welches nicht existiert,
>  bzw. nie geholt wird) erhöht wird.
>
Mir geht es um den Simulator und da zeigt der PC eindeutig auf die 
Adresse $000C, wo ja auch der rjmp-Befehl hinterlegt ist ( Also im 
Little-Endian-Format ). Habe also den Flashspeicher im vorherigem 
Posting falsch interpretiert, was ich hier nun richtig stelle.

An Adresse $000C ist $F2C1 hinterlegt. $C ist ja der Code für rjmp.
$1F2 bedeutet für mich, das um 498 Adressen vorwärts gesprungen werden 
soll.
Was der Adresse 498+12 = 510 -> $01FE entspricht.

Diese ganze Theorie passt leider gar nicht zu dem was der Simulator 
macht, denn er springt nach Adresse $0000.

Arduino Fanboy D. schrieb:
> Laut AVR Doku braucht rjmp 2 Takte.
> Laut deinem Zitat, braucht der rjmp, wenn er als erster Befehl kommt, 3
> Takte.
>
> Wie du jetzt draus auf 1 Takt kommst, kann ich nur deinem
> ArduinoUserHass zuschreiben. Denn rationale Begründungen sind aus deiner
> Argumentation, oder der Doku, nicht zu entnehmen.
>
> Ich schätze mal, dass dir da ein (peinlicher) Lapsus unterlaufen ist.
>
Ich hege keinen Arduino-User-Hass. Mir ist bewusst, das man mit dieser 
art Programmierung schnell zum Ziel kommt. Dem ist natürlich geschuldet, 
das hier "meistens" kein Detailwissen vorhanden ist und auch gar nicht 
gewünscht. Deswegen meine Skepsis dir gegenüber.

Um es jetzt noch mal deutlich zu schreiben. Nicht ich kam auf 1 Takt, 
sondern der Simulator. Ich wollte damit also klar machen, das man dem 
Simulator nicht trauen darf.

Er ist halt ein Simulant ;-)

Ja, manchmal sind mir Fehler peinlich, meistens aber nicht.


A. K. schrieb:
> Es gibt noch eine kleine Feinheit zu beachten. Atmels Software rechnet
> bei Code in Worten, von GNU infizierte Versionen aber in Bytes. Was
> manches -1 zu -2 werden lässt.
>
Hm - werde ich mal bei Lust und Laune drüber nachdenken.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Die Sache ist doch ziemlich simpel zu verstehen. Der Atmel Assembler
> erwartet
> ein absolute Adresse als Eingabe für alle Verzweigungs- und
> Sprungbefehle. Den eigentlich für den Opcode benötigten relativen Offset
> berechnet er aus dem gegenwärtigen PC (genauer: dem PC am Beginn der
> Operation) und dem Sprungziel.
>
Ich verstehe trotzdem nicht wie der Assembler bei rjmp -1 auf den Opcode 
von c1f2 an Adresse $000c kommt ( siehe lss-Datei.jpg weiter oben ).

Vielleicht jemand von den bisher 123 Leuten, die sich den Screenshot 
angesehen haben.

Bernd_Stein

[Purzel H. (hacky)]

> Schöne Tischdecke

Die Tischdecke ist original weiss.  Entweder wurde Beerensaft 
mitgewaschen, oder der automatische Weissabgleich hat's so geaendert.

[Einer K. (Gast)]

Bernd S. schrieb:
> Ich verstehe trotzdem nicht wie der Assembler bei rjmp -1 auf den Opcode
> von c1f2 an Adresse $000c kommt ( siehe lss-Datei.jpg weiter oben ).
>
> Vielleicht jemand von den bisher 123 Leuten, die sich den Screenshot
> angesehen haben.

Klar doch!

Es gilt 3 Fragen zu beantworten:
1. du spinnst
2. dein Simulator spinnt
3. dein Assembler baut Mist

Also damit eine Gegenprobe:
Stefanus F. schrieb:
> ende:
>     rjmp ende
Das ist exakt das, was bei meinem System zu
> rjump .-2
führt


Dann den generierten Code anschauen.
Im Simulator testen.

Und du wirst sehen: Du spinnst.
(das sagt zumindest meine Glaskugel)


------------

Bernd S. schrieb:
> Deswegen meine Skepsis dir gegenüber.
Offensichtlich bist du mit Vorurteilen angefüllt.
Das befähigt dich, aus meinem Namen hier im Forum, darauf zu schließen, 
dass ich ein Idiot (wie alle anderen Arduino User auch) bin.
Alle in einen Sack, und drauf hauen.
Eine solche Gelegenheit kannst du dann nicht liegen lassen.

Dummer weise, hast du eine Fehlinformation (egal, wo sie nun her kommt) 
verwendet, um einen Erniedrigungsversuch einzuleiten.
Das hat dann nicht so geklappt... oder?

Ja, ich finde das sollte dir peinlich sein.
Mir wäre eine solche Blamage sehr peinlich.

[spess53 (Gast)]

Hi

>Ich verstehe trotzdem nicht wie der Assembler bei rjmp -1 auf den Opcode
von c1f2 an Adresse $000c kommt ( siehe lss-Datei.jpg weiter oben ).

Für welchen Controller ist das Programm assembliert?

MfG Spess

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

spess53 schrieb:
> Für welchen Controller ist das Programm assembliert?
>
Für den AtTiny13.


Bernd_Stein

[W.S. (Gast)]

c-hater schrieb:
> Fachbücher sind Mist, die kosten nur unnötig Geld und veralten schneller
> als das Papier verrotten kann, auf dem sie gedruckt sind.

Ach nö. Wirkliche Fachbücher wie z.B. der alte Lampe-Jorke-Wengel sind 
auch noch nach Jahrzehnten nicht veraltet, weil sie eben neben dem 
einfachen Befehlssatz des gerade als Beispiel herangezogenen Chips das 
vermitteln, was eigentlich vonnöten ist: Algorithmen erlernen.

Wenn du allerdings diese hinlänglich bekannten 
Schnellschuß-Zusammenklatsch-Pseudo-Fachbücher ("alles über den XY180") 
meinst, dann geb ich dir völlig Recht. Diese sind schon vor ihrem Druck, 
ja sogar vor der Manuskript-Reinfassung obsolet.

W.S.

[Rainer V. (a_zip)]

Bernd S. schrieb:
> Ich verstehe trotzdem nicht wie der Assembler bei rjmp -1 auf den Opcode
> von c1f2 an Adresse $000c kommt

Hallo, wenn auch zu Übungszwecken so etwas durchgekaut werden 
sollte...kein Mensch, der in Assembler programmiert, benutzt irgendwo 
absolute Werte (wenn er nicht unbedingt muß). Das macht der Assembler 
für uns! Also "Schleife zurück" = rjmp/jmp "Schleife zurück". Alles 
andere kann man den sogenannten Cracks überlassen! Lern' was, was dir 
was bringt!! Oder kapiere das, was dir sicher nichts bringt :-)
Gruß Rainer

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Ich verstehe trotzdem nicht wie der Assembler bei rjmp -1 auf den Opcode
> von c1f2 an Adresse $000c kommt ( siehe lss-Datei.jpg weiter oben ).
>

Mit Hilfe des doch richtig funktionierenden Simulators im ATEMEL Studio 
7 und dem folgenden Programm, ist es mir gelungen den Opcode *$C1F2*, an 
Adresse *$000C*, der im Listingfile zum Befehl rjmp -1 erzeugt wurde, 
zu verstehen.

.CSEG                       ;Beginn des Programmspeichers   
.ORG $0000                  ;Anfangsadresse einstellen
 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )
 nop
 nop 
 nop 
 nop
 nop
 nop
 nop
 nop
 nop

_reset:                     ;Programmstartaddresse ( $000A )
 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren
 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

 rjmp -1                    ;Vermeintlicher Sprung auf sich selbst ( $000C ),.. 
 nop                        ;..also Endlosschleife
 nop
 nop

.EXIT                       ;Ende der Assemblierung

Die -1 ist die höhste Flashadresse ( $01FF ).
Zum Befehl rjmp steht folgendes : PC = PC + k + 1.
Um nun von der Adresse $000C, wo der Befehl rjmp steht, zur FLASH_END 
Adresse zu gelangen, ist laut Formel ein Offset ( k ) von $01F2 
erforderlich.

  $000C rjmp bzw. PC
 +$01F2 k
 +$0001 +1
----------
  $01FF PC

Noch was.
Welche Formatierung bekommt ihr zu sehen ?
Ich hoffe die Ok-Version ( siehe Anhang ).

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Und noch was.
Welche Formatierung bekommt ihr zu sehen ?

Ich hoffe die Ok-Version ( siehe Anhang ).


Bernd_Stein

[Bimbo. (Gast)]

Lerne C.

[Rudi D. (rulixa)]

Dennis schrieb:

> ich bin neu in dem Thema, und möchte erstmal Assembler für
> Mikrocontroller lernen.

Hier gibts jede Menge Projekte in Assembler als auch andere Sprachen.

http://www.elektronik-labor.de/AVR/AVR.html

[M.A. S. (mse2)]

Dennis schrieb:
> ich bin neu in dem Thema, und möchte erstmal Assembler für
> Mikrocontroller lernen.

Bimbo. schrieb:
> Lerne C.

Das ist wieder einfach klasse!
Jemand schreibt: "Ich möchte Volleyball lernen...".
Jemand anderer Antwortet: "Lerne Minigolf."
Alles wie immer... ach ja: heute ist ja Freitag!   :)

[Einer K. (Gast)]

M.A. S. schrieb:
> Das ist wieder einfach klasse!
> Jemand schreibt: "Ich möchte Volleyball lernen...".
> Jemand anderer Antwortet: "Lerne Minigolf."
> Alles wie immer... ach ja: heute ist ja Freitag!   :)

Genau, dann setzt jegliche Intelligenz aus.
(offensichtlich: bei dir auch)

Bernd S. !== Dennis

[M.A. S. (mse2)]

Arduino Fanboy D. schrieb:
> Genau, dann setzt jegliche Intelligenz aus.
> (offensichtlich: bei dir auch)
>
> Bernd S. !== Dennis

Mußt DU ja wissen. Wo kommt in meinem Beitrag "Bernd S." vor?


PS: Gut, ok, habe gerafft, dass "lern C" nicht an den TO gerichtet war. 
Sorry. Trotzdem selbst schuld, wenn ohne Zitat geantwortet wird, ist 
nicht klar, wem.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Rudi D. schrieb:
> Hier gibts jede Menge Projekte in Assembler als auch andere Sprachen.
>
> http://www.elektronik-labor.de/AVR/AVR.html
>
Daher stammt ja auch der " Urlaubskurs " auf den ich mich hier beziehe.

http://www.elektronik-labor.de/AVR/KursAssembler/T13asm13.html#1


Bernd_Stein

[Erich (Gast)]

Rudi D. schrieb:
> Dennis schrieb:
>
>> ich bin neu in dem Thema, und möchte erstmal Assembler für
>> Mikrocontroller lernen.


Ja, das war vor knapp 6 Jahren (2013).

Inzwischen hat er's gelernt, nebenher sein Studium abgeschlossen und 
programmiert erfolgreich in höheren Programmiersprachen.

Diese Thread kann damit geschlossen werden.

Gruss

[Oliver S. (oliverso)]

Bernd S. schrieb:
> Die -1 ist die höhste Flashadresse ( $01FF ).
> Zum Befehl rjmp steht folgendes : PC = PC + k + 1.
> Um nun von der Adresse $000C, wo der Befehl rjmp steht, zur FLASH_END
> Adresse zu gelangen, ist laut Formel ein Offset ( k ) von $01F2
> erforderlich.
>
>   $000C rjmp bzw. PC
>  +$01F2 k
>  +$0001 +1
> ----------
>   $01FF PC

Bis auf, das FLASH_END in der Betrachtung nicht vorkommt, der Sprung 
nicht zu FLASH_END führt, und -1 auch nicht 0x1FF ist, stimmt das nicht.

> Zum Befehl rjmp steht folgendes : PC = PC + k + 1.

Das ist richtig. Allerdings solltest du auch in der Doku zu deinem 
Assembler lesen, was da zum Befehl rjmp steht.

Weil da aber auch schin viele andere drauf reingefallen sind, lies 
einfach, was z.B google als erstes dazu findet:

https://www.makerconnect.de/index.php?threads/rjmp-x.3593/

Oliver

[Rudi D. (rulixa)]

Erich schrieb:
> Rudi D. schrieb:
>> Dennis schrieb:
>>
>>> ich bin neu in dem Thema, und möchte erstmal Assembler für
>>> Mikrocontroller lernen.
>
>
> Ja, das war vor knapp 6 Jahren (2013).
>
> Inzwischen hat er's gelernt, nebenher sein Studium abgeschlossen und
> programmiert erfolgreich in höheren Programmiersprachen.
>
> Diese Thread kann damit geschlossen werden.

Danke für den Hinweis. Ein alter Thread der wieder auflebte. Sorry, hab 
nicht aufs Datum geschaut.
Erich hat recht.

[michael_ (Gast)]

Bernd S. schrieb:
> Mit Hilfe des doch richtig funktionierenden Simulators im ATEMEL Studio
> 7 und dem folgenden Programm, ist es mir gelungen den Opcode *$C1F2*, an
> Adresse *$000C*, der im Listingfile zum Befehl rjmp -1 erzeugt wurde,
> zu verstehen.

Lass es erst mal sein, dich mit diesen Problem rumzuärgern.
Es gibt interessantere Sachen in Assembler.
Vielleicht gibt es eine Möglichkeit, das Argument relativ einzugeben.
Ähnlich wie beim Z-80.

Ich habe da auch mal mit dem alten Assembler rumgespielt.
Mit Marken.

Beim Sprung auf sich selbst, also rückwärts, bekomme ich

FF CF

Um ähnliche Werte vorwärts

.. C0

Wie kommst du auf die Idee, den Wert direkt einzugeben?
In der Assembler-Anleitung ist das erst mal nicht vorgesehen.
Benutze Marken!

[Rainer V. (a_zip)]

Also jetzt noch mal ganz klar: PC-Adressen direkt zu maipulieren ist 
kein Anfängerthema!! Und wie der TO auch immer drauf gekommen sein 
mag...Quatsch, Quatsch, Quatsch.
Gruß Rainer

[michael_ (Gast)]

Quatsch, ja.
Aber bei meiner Suche gibt es das massenhaft im Netz.

[Bimbo. (Gast)]

Sehe erst jetzt, dass das Ursprungsthema von 2013 ist.... war durchaus 
an den TO gerichtet - jetzt aber nicht mehr, sondern eher an die 
Allgemeinheit ;).

Assembler schön und gut. Ich würde erstmal C lernen. Wenn man dann mal 
irgendwas zeitkritisches programmieren muss, dann macht man einen 
Zwischenkurs Assembler. Oder halt irgendwann nach C um ggf. mal das 
Output vom Compiler nachvollziehen zu können. Aber professionell oder 
hobbymäßig in reinem Assembler zu programmieren, das ist Masochismus.

Wenn man als erstes Assembler lernen tut, dann haben in der Zwischenzeit 
haben die sogenannten "Makerkids" schon ganze Stacks und CV Libs in C 
programmiert und der erste Roboter fährt durch den Garten.

[c-hater (Gast)]

Bimbo. schrieb:

> Assembler schön und gut. Ich würde erstmal C lernen.

Der Punkt ist: man kann C eigentlich frühestens dann kompetent 
benutzen, wenn man sich mit der binären Repräsentation von Zahlen und 
Zeichen und dem Konzept von Indirektionen auskennt. Dazu muss man zwar 
nicht notwendigerweise irgendeinen Assembler-Dialekt erlernen, aber es 
hilft doch schon dramatisch, wenn man einen beherrscht, idealerweise den 
des Zielsystems...

Geht man nicht so vor und lernt nur den ganzen C-Syntax-Bombast, fällt 
man über kurz oder lang auf die Schnauze. Genau so bauen diese ganzen 
C-only-Typen immer und immer wieder Sicherheitslücken in ihre Machwerke 
ein (bis sie dann irgendwann gelernt haben, was sie eigentlich von 
Anfang an hätten wissen müssen). Und jede neue 
C-only-Programmierer-Generation tut das auf's Neue...

Das ist eben das Problem von C: es gibt nicht alle Freiheiten, die 
Assembler bietet, aber erlaubt (fast) alle Knieschüsse, die man sich 
auch in Assembler verpassen kann. Die sind dann aber (zumindest 
manchmal) immerhin "portabel", man kann sich damit also auf jedem 
Zielsystem mit demselben Quelltext gleichermaßen ausknocken. Toller 
Vorteil...

[Einer K. (Gast)]

Auch den Umgang mit Brotmessern will gelernt werden.

Dass Anfänger Anfängerfehler machen, ist nun wirklich auch keine 
besondere Neuigkeit.
Sondern eher Teil eines Prozesses, welchen man lernen nennt.

c-hater schrieb:
> ...
Leichte Realitätsverzerrung heute wieder?
Deinen polemischen Schleim will doch keine(r) hier hören, oder?

Bist du der "Priester mit der traurigen Gestalt", oder wer war der Type, 
mit den Windmühlen?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> Bis auf, das FLASH_END in der Betrachtung nicht vorkommt, der Sprung
> nicht zu FLASH_END führt, und -1 auch nicht 0x1FF ist, stimmt das nicht.
>
Lies dir nochmal das Posting 7 auf der von dir verlinkten Seite durch, 
dann verstehst du vielleicht, dass ich nichts anderes behaupte. Außerdem 
lass das Programm mal durch den Simulator laufen, vielleicht verstehst 
du dann.

https://www.makerconnect.de/index.php?threads/rjmp-x.3593/

.CSEG                       ;Beginn des Programmspeichers   
.ORG $0000                  ;Anfangsadresse einstellen
 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )
 nop
 nop 
 nop 
 nop
 nop
 nop
 nop
 nop
 nop

_reset:                     ;Programmstartaddresse ( $000A )
 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren
 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

 rjmp -1                    ;Vermeintlicher Sprung auf sich selbst ( $000C ),.. 
 nop                        ;..also Endlosschleife
 nop
 nop

.ORG FLASHEND               ;$01FF Ende des 1 kB bzw. 512 Word Flashbereichs
 nop
 
.EXIT                       ;Ende der Assemblierung

Bernd_Stein

[Oliver S. (oliverso)]

Ok, ich korrigiere mich: Der Sprung führt zu FLASH_END.

AVR Studio macht auf dem Sprungziel mit Adresse -1 ein Wrap-Around im 
Flash, und ladet damit bei FLASH_END. Kann man machen, muß man aber 
nicht.

gcc erzeugt daraus einen Befehl, der tatsächlich die Adresse -1 (bzw. 
-2) als Sprungziel hätte, und überlässt es dem Prozessor, was er damit 
anfängt. Kann man machen, muß man aber nicht.

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> AVR Studio macht auf dem Sprungziel mit Adresse -1 ein Wrap-Around im
> Flash, und ladet damit bei FLASH_END...
>
Bei rjmp 1 macht er einen Überlauf ( Wrap Around ), hierbei jedoch 
nicht.

 $000C rjmp 1
+$0FF4 k bzw. Adresse 1
+$0001
------
 $1001 Wrap Around


 $000C rjmp -1
+$01F2 k bzw. FLASHEND
+$0001
------
 $01FF


Bernd_Stein

[Oliver S. (oliverso)]

Bernd S. schrieb:
>  $000C rjmp 1
> +$0FF4 k bzw. Adresse 1
> +$0001
> ------
>  $1001 Wrap Around

Das ist kein wrap around. k ist eine vorzeichenbehafte Zahl, daher 
entspricht 0xff4 -11. 12-11 = 1.

Bernd S. schrieb:
>  $000C rjmp -1
> +$01F2 k bzw. FLASHEND
> +$0001
> ------
>  $01FF

Da ist der wrap around. Das 0x1f2 berechnet das Studio aus dem 
Sprungziel -1, welches durch wrap around zu flash_end (=0x1ff) wird.

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> Das ist kein wrap around. k ist eine vorzeichenbehafte Zahl, daher
> entspricht 0xff4 -11. 12-11 = 1.
>
Nur nebenbei $FF4 ist -12.

Der Simulator bzw. Assembler führt immer das Selbe für den Befehl rjmp, 
mit dem Programmcounter ( PC ), durch. Nämlich wie im Befehl rjmp 
beschrieben

PC = PC + k + 1.

Der Flash reicht von $0000 bis $01FF. Das sind die Wordadressen 0 bis 
511, also 512 Adressen.

Der Offset ( k ) kann in jede Richtung 2048 Byteadressen bzw. 1024 
Wordadressen springen. Weil der Flash des AtTiny13 nur 512 Wordadressen 
hat, ist der Assembler vermutlich auf Wrap Around eingestellt und 
springt nur vorwärts ( in Richtung höherer Adressen ).

Oliver S. schrieb:
> Das 0x1f2 berechnet das Studio aus dem
> Sprungziel -1, welches durch wrap around zu flash_end (=0x1ff) wird.
>
Nach deiner Rechnung oben :

0x1f2 -3598. 12-3598 = -3586 -> 0xe02

0xe02 ist ungleich 0x1ff.

Da du mir das mit deinen Beispielen nicht klar erklären kannst, bleibe 
ich bei meiner Sicht der Dinge, die mir viel plausibeler erscheint.
In älteren Versionen konnte man den Assembler anweisen mit Wrap Around 
zu arbeiten. Die neuen Versionen werden es, wie bereits geschrieben, 
vermutlich automatisch an Hand der xyz.def einstellen.

Bernd_Stein

[Oliver S. (oliverso)]

Bernd S. schrieb:
> Der Offset ( k ) kann in jede Richtung 2048 Byteadressen bzw. 1024
> Wordadressen springen. Weil der Flash des AtTiny13 nur 512 Wordadressen
> hat, ist der Assembler vermutlich auf Wrap Around eingestellt und
> springt nur vorwärts ( in Richtung höherer Adressen ).

Das wäre widersinnig.

Der Atmel Studio Assembler berechnet k aus einer negativen absoluten 
Zieladresse durch wrap around mit der Flash Größe eine positive (bzw. Er 
rechnet vermutlich modulo Flash_size). So wird aus -1 Flash_end, aus -2 
wird Flash_end-1, usw. Ob der das mit positiven Sprungadressen größer 
flash_end auch macht, hab ich nicht probiert, kann aber sein.

Ist das Sprungziel positiv oder Null, berechnet der k der natürlich auch 
für einen Sprung rückwärts.

gcc macht das alles nicht, der berechnet k stur aus der absoluten 
Zieladresse, egal, ob die negativ ist, oder nicht.

Oliver

[Marc V. (Firma: Vescomp) (logarithmus)]

Bernd S. schrieb:
> Nur nebenbei $FF4 ist -12.

 Nur nebenbei:
 $FF4 ist immer 4084(int oder uint)

 $FFF4 ist -12 (int) oder 65524 (uint)
 $F4 ist   -12 (signed char) oder 244(char)

 P.S.
 Atmel sagt folgendes:
 Relative jump to an address within PC - 2K +1 and PC + 2K (words).
 Deswegen kann alles bis 8KB mit rjmp angesprungen werden, alles
 über 8KB benutzt jmp.

 P.P.S.
 Ev. Wrap Around (und die daraus resultierende Adresse) ist demzufolge
 nichts anderes als ((PC + Rel. Jump Offset) MODULO Flashsize).

[Oliver S. (oliverso)]

Marc V. schrieb:
> Nur nebenbei:
>  $FF4 ist immer 4084(int oder uint)

Da es sich per Definition um einen vorzeichenbehafteten 12-Bit Wert 
handelt, ist das in dem speziellen Fall, um den es hier geht, falsch. 
int oder uint oder sonstwas gibt es auf dem Level nicht. Was das "immer" 
dann auch etwas relativiert.

Marc V. schrieb:
> Ev. Wrap Around (und die daraus resultierende Adresse) ist demzufolge
>  nichts anderes als ((PC + Rel. Jump Offset) MODULO Flashsize).

So isses.

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> ...(bzw. Er
> rechnet vermutlich modulo Flash_size)...
>

Marc V. schrieb:
> P.P.S.
>  Ev. Wrap Around (und die daraus resultierende Adresse) ist demzufolge
>  nichts anderes als ((PC + Rel. Jump Offset) MODULO Flashsize).
>

An euch beide.

Wie sieht diese Modulo-Rechnung aus ? ( Formel mit Werten )


Bernd_Stein

[Oliver S. (oliverso)]

Was genau ist jetzt deine tatsächliche Frage? Doch wohl nicht die 
Modulo-Berechnung?

Oliver

[Bernd K. (prof7bit)]

c-hater schrieb:
> Das Problem ist nur:
> Über kurz oder lang wirst du nicht drumrum kommen, den C-Scheiß
> zumindest lesen zu können.

LOL!

Dir gelingt es trotz all des Blödsinns den Du oftmals verzapfst hin und 
wieder tatsächlich immer noch mich zum Lachen zu bringen!

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> Was genau ist jetzt deine tatsächliche Frage? Doch wohl nicht die
> Modulo-Berechnung?
>
Ja, doch. Was für Werte setzt du bzw. ihr da ein ?
Das Ergebnis werde ich versuchen selber zu ermitteln ;-)

Bernd_Stein

[Oliver S. (oliverso)]

Zieladresse und Flashgröße. Ergibt eine korrigierte Zieladressee 
innerhalb 0..flash_end. Aus der wird dann k berechnet.

Beitrag "Wieso ist -1 mod 26 = 25 ?"

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> Zieladresse und Flashgröße...
>
Was jetzt ?

Zieladresse mod Flashend

oder

Flashend mod Zieladresse ?

oder

was genau ?


Bernd_Stein

[Oliver S. (oliverso)]

Ach je, stell dich nicht dümmer, als du bist. Du kriegst das raus.

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> Ach je, stell dich nicht dümmer, als du bist. Du kriegst das raus.
>
Ok, verstehe. Es ist also nur eine Vermutung die sich nicht beweisen 
läßt.

Mir ging es ja darum warum rjmp -1 an Adresse $000C den Opcode $C1F2 
erzeugt.
Das ist mir nun klar. Wie die CPU dies genau macht bzw. welchen 
Algorithmus oder was auch immer der Assembler macht ist mir nicht so 
wichtig.


Bernd_Stein

[Oliver S. (oliverso)]

Bernd S. schrieb:
> Ok, verstehe. Es ist also nur eine Vermutung die sich nicht beweisen
> läßt.

Natürlich ist die Berechnung dahinter nur eine Vermutung, da Atmel 
selber die ja nicht öffentlich dokumentiert hat. Aber die Berechnung, 
wie das Studio das vermutlich macht, kriegt man ja schnell raus, und das 
lässt sich an Hand einiger schneller Tests dann auch bestätigen (oder 
widerlegen).
Eigentlich steht das schon alles in den letzten Beiträgen, du musst es 
nur noch hinschreieben. Das darfst du aber selber machen.

Bernd S. schrieb:
> Mir ging es ja darum warum rjmp -1 an Adresse $000C den Opcode $C1F2
> erzeugt.
> Das ist mir nun klar. Wie die CPU dies genau macht bzw. welchen
> Algorithmus oder was auch immer der Assembler macht ist mir nicht so
> wichtig.

Na ja, die Frage nach dem warum ist die Frage nach dem Algorithmus 
dahinter. Wie sonst soll man beantworten, wie der Atmel Studio Assembler 
von der absoluten Adresse -1 auf die relative Sprungweite k zu $1F2 
kommt?

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jetzt mal ein anderes Problem.

Warum wird mit dieser Initialisierung nur einmal in die ADC-ISR 
gesprungen ?

;
;ADC freilaufend, 10-Bit, Aref=AVcc, 115200 Hz, digitale Eingangspuffer alle
;abschalten und Interrupt initialisieren
;
 ldi  a,$3F                 ;Alle digitalen Eingangspuffer abschalten..
 sts  DIDR0,a               ;..(PC0-5), um die Leistungsaufnahme zu reduzieren

 ldi  a,1<<REFS0            ;Aref = AVcc.. 
 sts  ADMUX,a               ;..mit 100nF am Aref-Pin

 ldi  a,1<<ADEN|1<<ADIE|1<<ADPS2;ADC Freigeben, Wandlung starten,..|1<<ADSC
 sts  ADCSRA,a             ;..ADC-IRQ freigeben und Vorteiler auf 16 

 lds  a,ADCSRA
 ori  a,1<<ADSC
 sts  ADCSRA,a

 sei                        ;Globale Interruptfreigabe im CPU-Statusregister

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Das ist ist sicherlich für BASCOM-Programmierer oder Umsteiger 
interessant.

https://www.rahner-edu.de/grundlagen/avr-assembler-teil-0/


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Warum wird mit dieser Initialisierung nur einmal in die ADC-ISR
> gesprungen ?
>
Weil der Free Running Mode auch nur ein " Autotrigger Mode " ist, 
welcher durch ADIF getriggert wird. Und die ADC Auto Trigger Logic 
braucht nun mal das Bit ADATE.

Außerdem ist der ODER-Baustein Flankengesteuert.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Es ist wirklich schade, dass das Datenbuchstudium unter Microchip eine 
Glückssache geworden ist.

Aus diesem einen Satz entnehme ich, das der Free Running Mode nicht 
dazu geeignet ist, mit Kanalwechseln oder Referenzqeullenwechseln zu 
arbeiten.

In dem von Spess verlinkten DB gibt es diesen Satz nicht mehr.


Bernd_Stein

[Einer K. (Gast)]

Bernd S. schrieb:
> Aus diesem einen Satz entnehme ich, das der Free Running Mode nicht
> dazu geeignet ist, mit Kanalwechseln oder Referenzqeullenwechseln zu
> arbeiten.

Das ist so nicht ganz richtig....

Man wird eben die erste Messung nach einem Kanalwechsel verwerfen 
müssen, da man nicht genau weiß, in welchem Augenblick/ADCTakt der 
Wechsel stattgefunden hat.

Und der Wechsel der Referenz braucht auch eine Einschwingzeit.
Ins besondere, wenn die interne dafür erst noch "hochgefahren" werden 
muss.
Das ist an anderer Stelle sicherlich beschrieben.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

warum ändert diese Programmsequenz nicht den Systemtakt ?

;
;Programmstart nach RESET  ( Interrupt Vektoren Tabelle )
;
.CSEG                       ;Was ab hier folgt kommt in den FLASH-Speicher
.ORG $0000                  ;Programm beginnt an der FLASH-Adresse 0x0000..
 jmp  _RESET                ;..mit der RESET-Vectortabelle

.include "IRQm6490.inc"     ;Restliche Interrupt Vektortabelle

.ORG INT_VECTORS_SIZE       ;Programmadresse nach den ganzen IRQ-Vektoren

_RESET:
 ldi  a,1<<CLKPCE           ;Vorbreitung zum Aendern des System..
 sts  CLKPR,a               ;..auf 1Mhz / 2 bzw. CLKPR = 16..
 ldi  a,1<<CLKPS2           ;..nun den Systemtakt ( 8 Mhz ) durch 16..
 sts  CLKPR,a               ;..teilen

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> warum ändert diese Programmsequenz nicht den Systemtakt ?

Der Thread wurde von Dennis für seinen ATmega8 eröffnet.
Dein letzter Beitrag, wo du ein Mikrocontroller-Modell nanntest, bezog 
sich auf den ATtiny13.
Zwischendurch zegtest du einen Ahnag für den ATmgea88.
Jetzt sind wir beim ATmega6490.

Ich finde das ziemlich verwirrend. Ich habe gerade eine Menge Text 
geschrieben und wieder gelöscht, weil diese Erkenntnis zu spät kam.

In deinem Programm sehe ich keinen Fehler. Die Problemursache muss in 
dem Teil sein, denn du weg geschnitten hast. Waren zum Beispiel 
Interrupts freigegeben? Wie hast du den Erfolg (bzw. Misserfolg) 
überprüft?

Bitte eröffne einen eigenen neuen Thread für deine Frage und bitte nur 
ein Thema pro Thread.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Das Umschalten geht recht einfach; Atmel hat allerdings eine 
Sicherheitsmassnahme gegen versehentliches Umschalten des Taktes 
eingebaut:

Man muss zunächst lediglich das oberste Bit im Register CLKPR auf "1" 
setzen (alle anderen Bits müssen "0" sein) und hat dann 4 Takte Zeit, 
durch Beschreiben der 4 unteren Bits die neue Taktrate einzustellen (das 
oberste Bit muss dabei auf "0" stehen). Auch müssen Interruts 
deaktiviert sein, damit sie nicht in das 4-Takte-Zeitfenster 
„hineinfunken“.

Quelle :

http://www.elektronik-labor.de/AVR/CLKPR.html


Ob ATtiny13 oder AtMega6490P ist für dieses Problem uninteressant.


Auf den Simulator ist leider wieder kein Verlass.
CLKPCE wird noch richtig gesetzt, aber der Teilerwert $05 bzw. 32 ( 
CLKPS2 & CLKPS0 ) wird einfach mal als $06 bzw. 64 übernommen.

Aber das Hauptproblem ist, das sich das Signal nicht ändert.

Im Anhang ist das komplette Programm für das ATMEL STUDIO 7, falls es 
wirklich jemand interessiert.


Bernd_Stein

[Stefan F. (Gast)]

Bernd, kannst du mal erklären, warum du immer wieder fragen zu so 
komischen Corner-Cases stellst und sie kurze Zeit danach selbst 
beantwortest? Was soll das werden, eine Kampagne gegen Microchips bzw. 
deren Simulator?

Anders kann ich mir dies in Kombination mit den zahlreichen Wechseln der 
Mikrocontroller nicht mehr erklären.

(Dass der Kacke ist, wissen wir alle, das ist keine neue Erkenntnis).

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Bernd, kannst du mal erklären, warum du immer wieder fragen zu so
> komischen Corner-Cases stellst und sie kurze Zeit selbst beantwortest?
> Was soll das werden, eine Kampagne gegen Microchip?
>
> Anders kann ich mir dies in Kombination mit den zahlreichen Wechseln der
> Mikrocontroller nicht mehr erklären.
>
Was sind Corner-Cases ?

Ich arbeite halt an verschiedenen Sachen und wundere mich dann, dass es 
nicht so funktioniert wie ich es mir gedacht habe. Und irgendwie kommen 
immer noch irgendwelche Dinge hinzu die ich erstmal nicht verstehe.

Das Problem ist nämlich noch nicht gelöst, obwohl ich laut allen Quellen 
die ich genutzt habe, meine alles richtig gemacht zu haben.

Ich weiß Assembler ist verpönt, aber in der ursprünglichen 
Threadüberschrift ist ja klar zu lesen, dass es um ASM geht und es ist 
meistens nötig diese Sprache zu beherrschen, um mir bei meinen Problemen 
helfen zu können.


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Ich arbeite halt an verschiedenen Sachen und wundere mich dann, dass es
> nicht so funktioniert wie ich es mir gedacht habe. Und irgendwie kommen
> immer noch irgendwelche Dinge hinzu die ich erstmal nicht verstehe.

Wenn das so ist, dann trenne Dich vom Simulator. Der war schon immer 
zickig und fehlerhaft. Du kannst besser mit echten AVR Controllern in 
Kombination mit einem Atmel ICE Debugger lernen.

[Rainer V. (a_zip)]

na ja, er hat entweder überhaupt keine Ahnung oder er trollt herum!
Gruß Rainer

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Du kannst besser mit echten AVR Controllern in
> Kombination mit einem Atmel ICE Debugger lernen.
>
Selbst mit dem ATMEL ICE hab ich seltsame Effekte per JTAG.

Die neue Adapterplatine mit 3x 0402 100nF KERKOs an den Versorgungspins 
10&11; 31&32; sowie 80&81 hat mich zwei Stunden gekostet und ich kann 
erstmal wieder über beide Schnittstellen ( ISP & JTAG ) auf den 
AtMega6490P zugreifen.

Kommentiere ich die Systemtaktumstellung aus, lande ich nach dem Klicken 
auf Continue ( F5 ) brav beim Breakpoint wie zu sehen. Nehme ich 
allerdings diese Programsequenz rein läuft das Programm endlos und durch 
klicken von Pause bzw. Break All ( Crtl+F5 ) lande ich immer beim 
Reset-Vektor.

Einzelschritt bzw. Step Into ( F11 ) erzeugt ebenfalls ein Endloslauf 
des Programms, was durch klicken von Pause ebenfalls beim Reset-Vektor 
landet.

Der Systemtakt wurde laut CLKPR ( Clock Prescaler Select Bits ) richtig 
auf 32 eingestellt ( $05 ).

Es ist zum Wahnsinnig werden.

;
;Programmstart nach RESET  ( Interrupt Vektoren Tabelle )
;
.CSEG                       ;Was ab hier folgt kommt in den FLASH-Speicher
.ORG $0000                  ;Programm beginnt an der FLASH-Adresse 0x0000..
 jmp  _RESET                ;..mit der RESET-Vectortabelle

.include "IRQm6490.inc"     ;Restliche Interrupt Vektortabelle

.ORG INT_VECTORS_SIZE       ;Programmadresse nach den ganzen IRQ-Vektoren
;
;
;
_RESET:
 ;ldi  a,1<<CLKPCE           ;Vorbreitung zum Aendern des Systemtaktes..
 ;sts  CLKPR,a               ;..auf 8Mhz / 32 bzw. CLKPR = 32..
 ;ldi  a,1<<CLKPS2|1<<CLKPS0 ;..nun den Systemtakt ( 8 Mhz ) durch 32..
 ;sts  CLKPR,a               ;..teilen

 lds  a,CLKPR
;
;Stapelzeiger initialisieren (fuer Unterprogramme und / oder Interrupts)
; 
 ldi  a,High(RAMEND)        ;RAMEND, also das Ende vom SRAM, ist in der.. 
 out  SPH,a                 ;..Definitions-datei festgelegt  
 ldi  a,Low (RAMEND)
 out  SPL,a

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Nehme ich allerdings diese Programsequenz rein läuft das Programm endlos

Ich erkenne den Zusammenhang zur Taktfrequenz nicht. Das wirft Fragen 
auf. Kannst du mal den ganzen Quelltext posten (oder ist es immer noch 
der aus dem obigen Zip-File)?

> Was sind Corner-Cases?

Seltene spezielle Situationen, die im Normalfall nicht vorkommen.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Ich erkenne den Zusammenhang zur Taktfrequenz nicht. Das wirft Fragen
> auf. Kannst du mal den ganzen Quelltext posten (oder ist es immer noch
> der aus dem obigen Zip-File)?
>
Ich auch nicht.
Eine Erklärung wäre das das Debuging damit nicht zurecht kommt, aber 
warum funktioniert die Systemtaktumstellung nicht im µC ?

Ja, bis auf die eine Zeile die ich im Debugger verwenden wollte, um zu 
sehen welchen Wert den jetzt CLKPR hat ( lds  a,CLKPR ).


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Hallo zusammen,
>
> warum ändert diese Programmsequenz nicht den Systemtakt ?
>
Warum es nun doch geklappt hat bleibt wohl ein Rätsel.

Beitrag "Zugriff auf AtMega6490P mit AVRISP mkII"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

In dem oben beschrieben Tutorial hier aus dem Forum auf der Seite 46, 
zur vorzeichenlosen Division, müsste es für mich bei dieser Sequenz so 
im Kommentar heissen :

cp   r19,r17    ;Ist der Divisor groesser?
brlo div_zero   ;wenn JA,   dann bleibt die 0
sbr  r20,1      ;wenn NEIN, dann jetzt die 0 durch eine 1 austauschen ...

https://www.mikrocontroller.net/attachment/35293/AVR-ASM-Tutorial_16_05_08_v2.pdf

ldi  r16, 109   ; Dividend    
ldi  r17,   9   ; Divisor
                ; Division r16: r17    
ldi  r18,   8   ; 8 Bit Division    
clr  r19        ; Register für die Zwischenergebnisse / Rest    
clr  r20        ; Ergebnis

divloop:    
lsl  r16        ; Zwischenergebnis mal 2 nehmen und das    
rol  r19        ; nächste Bit des Dividenden anhängen    
lsl  r20        ; das Ergebnis auf jeden Fall mal 2 nehmen,
                ; das hängt effektiv eine 0 an das Ergebnis an.
                ; Sollte das nächste Ergebnis-Bit 1 sein, dann wird
                ; diese 0 in Folge durch eine 1 ausgetauscht    
cp   r19, r17   ; ist der Divisor größer?    
brlo div_zero   ; wenn nein, dann bleibt die 0    
sbr  r20, 1     ; wenn ja, dann jetzt die 0 durch eine 1 austauschen ...    
sub  r19, r17   ; ... und den Divisor abziehen

div_zero:    
dec  r18        ; das Ganze 8 mal wiederholen    
brne divloop    ; in r20 steht das Ergebnis der Division
                ; in r19 steht der bei der Division entstehende Rest

Solche umgekehrten Gedankengänge machen mich total kirre

Ist bla, bla grösser? -> springe wenn kleiner


Bernd_Stein

[Wegstaben V. (wegstabenverbuchsler)]

Bernd S. schrieb:
> machen mich total kirre
>
> Ist bla, bla grösser? -> springe wenn kleiner

Vielleicht ist sowas zwecks Nutzung mancher Assembler-Befehle 
zweckmässig (ich weiss es nicht, ich nutze kein Assembler seit langer 
Zeit)

Ist halt wie manche Abfrage in einem populären Desktop-Betriebssystem:
"Soll diese Datei nicht gelöscht werden? [Ja NEIN]"

[H-G S. (haenschen)]

Ich habe festgestellt dass man sich nicht einfach vor den PC setzen und 
ein Assembler-Programm schreiben kann.

Statt dessen muss man eine Art Flussplan schreiben mit möglichst kleinen 
Schritten. Diese Schritte übersetzt man dann in die Maschinensprache.
Also man erzeugt Variablen oder berechnet etwas oder macht eine bedingte 
Verzweigung usw.

[Wegstaben V. (wegstabenverbuchsler)]

H-G S. schrieb:
> Ich habe festgestellt dass man sich nicht einfach vor den PC setzen und
> ein Assembler-Programm schreiben kann.
>
> Statt dessen muss man eine Art Flussplan schreiben ...

Dieser Ansatz empfiehlt sich auch bei "Hochsprachen". Juhu, die 
Assembler-Fraktion entdeckt die strukturierte Vorgehensweise.

[Einer K. (Gast)]

Wegstaben V. schrieb:
> Dieser Ansatz empfiehlt sich auch bei "Hochsprachen".
Datenflussdiagramme und UML-Klassendiagramme haben auch ihren Wert.
(vielleicht sogar noch mehr als Programmflussdiagramme)

[Veit D. (devil-elec)]

Hallo,

wegen der Taktumstellung. Kann es sein das der Schreibschutz auf das 
entsprechende Register noch nicht aufgehoben wurde? Manche kritische 
Register können/sind mit einem Schreibschutz versehen der direkt vor 
Änderung temporär aufgehoben werden muss. Kann das irgendwie sein und du 
nur einen Buffer siehst?

[Falk B. (falk)]

H-G S. schrieb:
> Ich habe festgestellt dass man sich nicht einfach vor den PC setzen und
> ein Assembler-Programm schreiben kann.
>
> Statt dessen muss man eine Art Flussplan schreiben mit möglichst kleinen
> Schritten. Diese Schritte übersetzt man dann in die Maschinensprache.

Kaum. Das macht der Assembler. Der Mensch schreibt Assemblerbefehle.

> Also man erzeugt Variablen oder berechnet etwas oder macht eine bedingte
> Verzweigung usw.

Na das ist ja mal ne Erkenntnis! Ich ruf schon mal in Stockholm an!

[Stefan F. (Gast)]

Falk, mach doch mal etwas ganz ungewöhnliches: Sei nett!

Nette Menschen sehen schöner aus.

[Peter D. (peda)]

H-G S. schrieb:
> Ich habe festgestellt dass man sich nicht einfach vor den PC setzen und
> ein Assembler-Programm schreiben kann.
>
> Statt dessen muss man eine Art Flussplan schreiben mit möglichst kleinen
> Schritten.

Das trifft generell für alle Programmiertätigkeiten zu, nicht nur für 
Assembler.
Leider sieht man auch viele, die das nicht einsehen wollen, obwohl sie 
keine Anfänger mehr sind.
Die richtige Planung erspart mindestens 80% der Programmierarbeit und 
90% Frust bei der Fehlersuche.

[Stefan F. (Gast)]

So mancher Programmierer traut sich zu, ohne Plan einfach drauf los 
programmieren zu können.

Man sollte aber bedenken, dass es später oft andere Leute sind, die 
Fehler analysieren oder Erweiterungen einbauen müssen. Wenn das ganze 
Konstrukt (nicht nur der Quelltext) dann nicht gut durchdacht ist, 
blickt nur der erste Autor durch.

Ein Plan zu Erstellen hilft dabei, das Konstrukt zu durchdenken und zu 
dokumentieren.

[Vincent H. (vinci)]

Ich seh das mittlerweile komplett anders. Wer ein UML oder Flußdiagramm 
braucht um seinen Code zu erklären, der braucht ein Refactoring. Das 
Zeug is ok um sich über Ideen zu unterhalten oder Notfalls einen 
komplexen Algorithmus zu dokumentieren, ansonsten halt ich es für eher 
hinderlich. Die ersparte Zeit sollte man lieber in gute Tests stecken.

[Peter D. (peda)]

Vincent H. schrieb:
> Ich seh das mittlerweile komplett anders. Wer ein UML oder Flußdiagramm
> braucht um seinen Code zu erklären, der braucht ein Refactoring.

Du hast das falsch verstanden. Den Plan erstellt man vorher. Man 
benutzt ihn, um danach den Code einzuhacken. Der Plan sorgt auch 
dafür, daß man erst gar kein Refactoring braucht, bzw. deutlich weniger 
Schritte.
Wenn er ordentlich erstellt ist, kann man ihn aber auch als 
Dokumentation behalten.

[Vincent H. (vinci)]

Die Crux an solchen Plänen ist, dass man das Problem nicht richtig 
verstanden hat bevor man es zumindest 1x gelöst hat. Viele Details sind 
vorher nicht klar und die Gefahr von overengineering ist allgegenwärtig.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

cp   r19,r17    ;Ist der Divisor groesser?
brlo div_zero   ;wenn JA,   dann bleibt die 0
sbr  r20,1      ;wenn NEIN, dann jetzt die 0 durch eine 1 austauschen ...

Um mal wieder konkret auf das Problem einzugehen, danach kommt auch von 
meiner Seite wieder etwas Bla, bla mit Korintenscheisse ;-)

Was im genannten µC-Tutorial steht stimmt nicht, der obige Kommentar von 
mir ist also richtig.

Der Compare-Befehl subtrahiert r17 von r19. Also den Divisor vom 
Zwischenergebnis.

Der Branch-Befehl verzweigt, wenn das Carry-Flag gesetzt ist ( brlo = 
brcs ). Das heißt - wenn das Carry-Flag gesetzt ist, ist der Divisor 
grösser als das Zwischenergebnis und somit kann die Null im 
Zwischenergebnis bestehen bleiben.

Im Umkehrschluss ist dann das Zwischenergebnis ( r19 ), kleiner als 
der Divisor ( r17 ) und somit wird gesprungen.

Die Befehlsbeschreibung ( Branch if lower ( unsigned )) bezieht sich auf 
das Zielregister ( r19 ). Ich glaube, dies ist bei der 
Befehlsbeschreibung generell so.

Das Programm läßt sich meiner Meinung nach besser nachvollziehen wenn 
Namen für die Register benutzt werden. Deshalb hier noch mal das 
Programm mit sinnigen Registernamen :

Sorry für die beschissene Formatierung, bei mir sieht es im 
Erstellugsfenster jedoch gut aus.

;
;.INCLUDE "m8def.inc"    ;AVR-Definitionsdatei einbinden
.INCLUDE "m88padef.inc" ;AVR-Definitionsdatei einbinden

.DEF  divident    = r16  ;
.DEF  divisor    = r17  ;
.DEF  schritte    = r18  ;
.DEF  z_ergebnis  = r19  ;
.DEF  ergebnis    = r20  ;

.CSEG                   ;was ab hier folgt kommt in den FLASH-Speicher
.ORG $0000          ;Programm beginnt an der FLASH-Adresse 0x0000.CSEG 

_loop:     
 ldi  divident,109  ;Dividend    
 ldi  divisor,9    ;Divisor
      ;Division r16: r17    
 ldi  schritte,8  ;8 Bit Division    
 clr  z_ergebnis  ;Register für die Zwischenergebnisse / Rest    
 clr  ergebnis    ;Ergebnis

_divloop:    
 lsl  divident    ;Zwischenergebnis mal 2 nehmen und das    
 rol  z_ergebnis  ;nächste Bit des Dividenden anhängen    
 lsl  ergebnis    ;das Ergebnis auf jeden Fall mal 2 nehmen,      ;das hängt effektiv eine 0 an das Ergebnis an.      ;Sollte das nächste Ergebnis-Bit 1 sein, dann wird      ;diese 0 in Folge durch eine 1 ausgetauscht    
 cp   z_ergebnis,divisor;ist der Divisor größer?    
 brlo _div_zero    ;wenn ja, dann bleibt die 0    
 sbr  ergebnis,1  ;wenn nein, dann jetzt die 0 durch eine 1 austauschen ...    
 sub  z_ergebnis,divisor;... und den Divisor abziehen

_div_zero:    
 dec  schritte    ;das Ganze 8 mal wiederholen    
 brne _divloop    ;in r20 steht das Ergebnis der Division
 
 rjmp _loop

.EXIT                   ;Ende des Quelltextes

Ich benutze aus Faulheit immer erst dann Flussdiagramme, wenn ich nicht 
mehr durchsteige.


Und hier noch etwas Korintenscheisserkommentar und die nicht so gewollte 
Formatierung. Seltsam, nachdem ich dies in "" gesetzt habe passt die 
Formatierung. Im Vorschaubild jedoch nicht :-(


"Ich will jetzt nicht klugscheissen, aber dennoch eine Unterscheidung
zwischen Assembler und Maschinencode darstellen, wobei bedacht
werden muss, dass es bei dem Ausdruck ASSEMBLER einmal um das
"Assembler-Übersetzungsprogramm" gehen kann und zum Anderen um die
Programmiersprache, was ich jetzt meine.

Das du das weisst ist mir bekannt, aber ich schreibe halt für alle die
hier mitlesen.

Das ist Asssembler ( Programmiersprache )    : NOP

und dies Maschinencode                       : 0000 0000 0000 0000

Deshalb hat man den Assembler erschaffen um nicht für uns Menschen diese
Binärcodes bzw. Hexadezimalzahlen als Programm schreiben zu müssen."


Bernd_Stein

[Falk B. (falk)]

Vincent H. schrieb:
> Die Crux an solchen Plänen ist, dass man das Problem nicht richtig
> verstanden hat bevor man es zumindest 1x gelöst hat. Viele Details sind
> vorher nicht klar und die Gefahr von overengineering ist allgegenwärtig.

Die Gefahr von Murks und Drauflosfrickeln noch viel mehr . . .

[Johann L. (gjlayde)]

> Sorry für die beschissene Formatierung, bei mir sieht es im
> Erstellugsfenster jedoch gut aus.

Du verwendest vermutlich TABs zum Formatieren.

Das Problem mit TABs ist, dass sie je nach Umgebung (Editor, Webseite, 
e-Mail) unterschiedlich interpretiert werden.  So kann z.B. eine 
Webseite, die Code darstellt, nicht wissen, ob du lokal die TAB-Weite 
auf 4, 8 oder was anderes eingestellt hast.

Zeitgemäße Editoren erlauben es, Spaces anstatt TABs zu verwenden, und 
man merkt in der Handhabung dann auch kein Unterschied.  (Der einzige 
Fall, wo das nicht geht, ist wenn TAB syntaktisch erforderlich ist wie 
in Makefiles.)

Damit ist dann sichergestellt, dass Formatierungen überall gleich gut 
und frustfrei lesbar sind.

[Peter D. (peda)]

Vincent H. schrieb:
> Die Crux an solchen Plänen ist, dass man das Problem nicht richtig
> verstanden hat bevor man es zumindest 1x gelöst hat.

Dann ist eher das Problem, daß man dem Kunden alle Anforderungen erstmal 
umständlich aus der Nase popeln muß. Oft hat sich der Kunde selber keine 
Gedanken gemacht, was er eigentlich haben will.
Für den Entwickler ist es nicht schön, wenn er Sachen mehrfach ändern 
muß. Aber genau dabei zahlt es sich aus, wenn er vorher einen Plan 
gemacht hat und damit die Programme leicht wartbar und erweiterbar 
gehalten hat. Manche Erweiterungen und Schnittstellen kann man so auch 
schon vorausschauend implementieren.
Und oft kann man durch die Nacharbeiten auf Kundenwunsch auch einen 
Gewinn erwirtschaften, wenn das eigentliche Projekt sehr knapp 
kalkuliert war.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

bei der Assemblerprogrammierung lernt man ja jedes Bit des µC einzeln 
kennen.

Habe das im Screnshot zu sehende Programm zum Festellen des Systemtaktes 
benutzt. Das Oszi zeigt eine Frequenz von 14,660kHz an PB4 ( Pin3 ), an.
Dies mal 8 ergibt -> 117,280kHz

Das Multimeter ( MM ) zeigt 14,705kHz an ( 117,640kHz ).
Die Versorgungsspannung mit dem MM an Vcc ( PIN 8 ) gemessen, ist 4,78V.

Die Befehlszeile " in a,OSCCAL " war zu diesem Zeitpunkt noch nicht 
eingefügt.

1. Warum zeigt mir das Atmel Studio 7 ( AS7 ) mit DebugWire nicht das 
OSCCAL -Register an ?

2. Habe ich OSCCAL mit 67dez richtig ausgelesen?
   67 würde ja ca. 52% oder 104% bedeuten.

52% mehr würde bei mir ca. 167kHz ergeben bei einer Nominalfrequenz bei 
4,75V und 25°C, wenn ich hier 110300Hz laut Kennlinie festsetze.
Selbst im Temperaturbereich von 20-40°C hätte ich ja nur eine Abweichung 
von ca. 1,1kHz zusätzlich zu berücksichtigen.

Wie kommt die Diskrepanz zwischen der festgestellten Frequenz von 117kHz 
und der errechneten von 167kHz zu stande ?

Wo ist mein Fehler ?

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Habe ich OSCCAL mit 67dez richtig ausgelesen?
>    67 würde ja ca. 52% oder 104% bedeuten.

Die möglichen Werte liegen zwischen 0 und 127. Ich denke nicht, dass man 
das so einfach in Prozent umrechnen kann. Da stellt sich doch die Frage: 
Prozent von was?

> Wie kommt die Diskrepanz zwischen der festgestellten Frequenz
> von 117kHz und der errechneten von 167kHz zustande ?

Der R/C Oszillator unterliegt (wie jeder R/C Oszillator) starken 
Material-Streuungen. Deswegen werden die Chips schon in der Fabrik 
einzeln kalibriert. Beim Reset kopiert der Chip automatisch den 
Kalibrier-Wert ins Register. Die Angabe, dass das Register initial den 
Wert 0 hat ist daher irreführend.

Du kannst ebenso nicht davon ausgehen, dass der Chip bei einem 
bestimmten Wert eine bestimmte Frequenz liefert. Jeder Chip hat initial 
einen anderen Wert, um (in der Fabrik) auf die 100% zu kommen.

[Peter D. (peda)]

Bernd S. schrieb:
> Wie kommt die Diskrepanz zwischen der festgestellten Frequenz von 117kHz
> und der errechneten von 167kHz zu stande ?

Und was hat das mit "Assembler lernen" zu tun?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefan ⛄ F. schrieb:
> Die möglichen Werte liegen zwischen 0 und 127. Ich denke nicht, dass man
> das so einfach in Prozent umrechnen kann. Da stellt sich doch die Frage:
> Prozent von was?
>
Ich interpretiere dies für den 128kHz Oszillator so :

Mit dem Wert $00, kann der Oszillator mit 64kHz oder aber auch mit 
128kHz schwingen. Mit $7F, mit 128kHz oder 256kHz.

Stefan ⛄ F. schrieb:
> Die Angabe, dass das Register initial den
> Wert 0 hat ist daher irreführend.
>
Im vom mir benutztem DB wurde dies bereits in " Device Specific 
Calibration Value " geändert.

Stefan ⛄ F. schrieb:
> Der R/C Oszillator unterliegt (wie jeder R/C Oszillator) starken
> Material-Streuungen. Deswegen werden die Chips schon in der Fabrik
> einzeln kalibriert.
>
Ja genau, deshalb ja auch die Kennlinien im vorherigem Post. Daraus 
sollte man dann aber auch ungefähr ( vom mir aus +/- 2kHz ) die Frequenz 
bei einer bestimmten Versorgungsspannung und Temperatur herausbekommen 
können, da der Oszillator ja bereits bei der Fertigung kalibriert wurde.


Peter D. schrieb:
> Bernd S. schrieb:
>> Wie kommt die Diskrepanz zwischen der festgestellten Frequenz von 117kHz
>> und der errechneten von 167kHz zu stande ?
>
> Und was hat das mit "Assembler lernen" zu tun?
>
Dir ist sicherlich nicht entgangen dass der Screenshot aus AS7, 
Assembler beinhaltet. Deshalb möchte ich ( über die Threadüberschrift ) 
nur Leute erreichen die sich hiermit auskennen, denn die Anderen 
interessiert oftmals nicht was Bit für Bit in den SFR passiert und 
können deshalb auch nichts zu meinen Fragen antworten :

Bernd S. schrieb:
> 1. Warum zeigt mir das Atmel Studio 7 ( AS7 ) mit DebugWire nicht das
> OSCCAL -Register an ?
>
> 2. Habe ich OSCCAL mit 67dez richtig ausgelesen?
>


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Weil der Link in den vorherigen Posts nicht mehr funktioniert und es 
doch ein wirklich guter Kurs ist:

http://www.weigu.lu/tutorials/avr_assembler/index.html


Bernd_Stein

[Peter D. (peda)]

Bernd S. schrieb:
> denn die Anderen
> interessiert oftmals nicht was Bit für Bit in den SFR passiert und
> können deshalb auch nichts zu meinen Fragen antworten :

Es mag Dich zwar erstaunen, aber auch in sämtlichen anderen 
Programmiersprachen (C, Bascom, Pascal, Forth usw.) kann man ganz 
selbstverständlich auch SFRs und ihre Bits ansprechen. In der Regel 
haben sie die gleichen Namen, wie im Datenblatt.
Die magische Zeile dafür lautet unter C:

#include <avr/io.h>

Zur Kalibration gibt es diverse ANs:
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591393
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591004
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591195

[Peter D. (peda)]

Warum man einen Thread nicht kapern sollte, ist ganz einfach:
Viele lesen nicht den ganzen Schmonz bis zum Ende, sondern antworten 
weiter auf das Ursprungsthema.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Peter D. schrieb:
> Zur Kalibration gibt es diverse ANs:
> https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591393
> https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591004
> https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591195
>
Danke, da hab ich ja jetzt mächtig was zu lesen.
Weiß aber gar nicht, ob sich dies auch lohnt.

Haben die neueren AVR's nicht schon sehr genaue interne RC-Oszillatoren,
so dass ich vom ATtiny13A zu etwas neuerem wechseln sollte ?

Peter D. schrieb:
> Warum man einen Thread nicht kapern sollte, ist ganz einfach:
> Viele lesen nicht den ganzen Schmonz bis zum Ende, sondern antworten
> weiter auf das Ursprungsthema.
>
Tja, ich benutze ja schon andere Überschriften und man sollte schon 
lesen worauf man antworten will. Diese Art von Leuten wird mir 
sicherlich auch nicht helfen können.


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Haben die neueren AVR's nicht schon sehr genaue interne RC-Oszillatoren,
> so dass ich vom ATtiny13A zu etwas neuerem wechseln sollte ?

Wie lauten denn deine Anforderungen? Solange der ATtiny13A gut genug 
ist, sehe ich keinen Grund, zu einem anderen zu wechseln.

> Tja, ich benutze ja schon andere Überschriften und man sollte schon
> lesen worauf man antworten will. Diese Art von Leuten wird mir
> sicherlich auch nicht helfen können.

Für wen hältst du dich? Du bist hier der, der um Hilfe bittet. Je 
ordentlicher deine Frage gestellt ist, umso besser werden die Antworten 
sein. Die richtigen Experten sind sich nämlich teilweise zu fein, auf 
schlampige Fragen einzugehen. Wenn du wirklich auf deren Expertise 
keinen Wert legst, dann hast du überhaupt keine hilfreiche Antwort 
verdient.

Außerdem ist dein Verhalten dem Thread Owner gegenüber unfair. Wenn 
jetzt abwechselnd für ihn und für dich geantwortet wird, bricht hier das 
große Chaos aus. Dann würdest du sagen "ist nicht mein Problem". Wie 
lässt sich das jetzt noch vermeiden?: Indem man nur noch Dir antwortet. 
Daher der Begriff "kapern".

Mache es nächstes mal bitte rücksichtsvoller.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefan ⛄ F. schrieb:
> Wie lauten denn deine Anforderungen? Solange der ATtiny13A gut genug
> ist, sehe ich keinen Grund, zu einem anderen zu wechseln.
>
12,5% Abweichung.

Heute habe ich 123kHz gemessen.
Ich nehme jetzt mal wieder 128kHz als Nominalfrequenz. Dann sind 117kHz 
-8,6% und 123kHz -3,0% Abweichung.

Bei einer Versorgungsspannung von 4,8V und einem Temperaturbereich von 
-40°C bis 85°C entnehme ich den vorher geposteten Kennlinien eine 
Differenz von 6kHz, was auf 128kHz bezogen eine Abweichung von knapp 5% 
entspricht. Was mal wieder nicht so in meine Praxiserfahrung passt ( 
siehe 117kHz = -8,6% ).

Der ATtiny13A sollte also trotzdem hierfür zu gebrauchen sein.


Und jetzt dass im Forum beliebte Offtopic - nicht persönlich nehmen :

Stefan ⛄ F. schrieb:
> Für wen hältst du dich? Du bist hier der, der um Hilfe bittet. Je
> ordentlicher deine Frage gestellt ist, umso besser werden die Antworten
> sein.
> ...
>
Du bist wenigstens einer, der versucht durch Gegenfragen oder Hinweise 
auf den Kern des Problems, zu helfen.

Der ursprüngliche Threadersteller hat sich genau einmal hier unter dem 
Gastnamen " Dennis " zu Wort gemeldet. Gästen antworte ich sehr, sehr 
ungern, weil man meistens nicht erfährt, was jetzt schlussendlich 
herausgekommen ist. Diese Thread ist ein glänzendes Beispiel hierzu.

Wer sich für AVR8ASM interessiert schaut sicherlich in den wenigen 
Threads hierzu wenigstens mal kurz rein, bekommt also eine 
Benachrichtigung, wenn es was neues gibt, falls er das Häkchen bei " 
Thread beobachten " gesetzt hat. Dann liest man sich dieses " Neue " 
durch und antwortet dementsprechend oder halt nicht.

Wer meine Threads aufmerksam verfolgt, wird bemerkt haben, dass ich 
versuche keine " Datenleiche " zu erzeugen. Das heißt für die Mitleser 
einen Nutzen zu erbringen. Der hierzu erzeugte Aufwand wird sehr, sehr 
selten gelobt und ist mir auch gar nicht so wichtig. Natürlich freue ich 
mich, wenn ich mit meinen Problemen Anderen helfen konnte und dies auch 
noch erfahre.

Ich bin schon lange genug hier und lasse mich von den ganzen Trollen 
auch nicht von dieser Richlinie abbringen und werde jetzt noch 
verstärkter " Offtopic-Beiträge " ignorieren.

Ein " spassiges Experiment " trifft den Nagel auf den Kopf.

http://www.avr-asm-tutorial.net/avr_de/beginner/asm_beginner.html


Bernd_Stein

[Peter D. (peda)]

Bernd S. schrieb:
> Das heißt für die Mitleser
> einen Nutzen zu erbringen.

Tust Du aber nicht.
Niemand wird später was themenfremdes finden, was irgend jemand nach 
gefühlt 1000 Posts mal unten angehängt hat.

Wer wirklich anderen helfen will, der erstellt zu jeder Frage auch ein 
neues Topic. Und dann gibt es auch viel mehr Antworten dazu.

Bernd S. schrieb:
> Der hierzu erzeugte Aufwand wird sehr, sehr
> selten gelobt und ist mir auch gar nicht so wichtig.

Einen Hijacker loben, sonst noch Wünsche?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Peter D. schrieb:
> Bernd S. schrieb:
>> Das heißt für die Mitleser
>> einen Nutzen zu erbringen.
>
> Tust Du aber nicht.
> Niemand wird später was themenfremdes finden, was irgend jemand nach
> gefühlt 1000 Posts mal unten angehängt hat.
>
Ein Bild sagt mehr als tausend Worte. Mehr sage ich jetzt nicht.


Bernd_Stein

[Peter D. (peda)]

Bernd S. schrieb:
> Ein Bild sagt mehr als tausend Worte.

Dann kommt man auf den Ursprungspost, scrollt vielleicht noch 10 
Postings weiter und guckt dumm aus der Wäsche.

Warum willst Du unbedingt die Suche besonders schwer machen?

[Stefan F. (Gast)]

Bernd S. schrieb:
> Ein Bild sagt mehr als tausend Worte.

Wer würde denn auf das erste Suchergebnis klicken? Ich nicht, weil der 
Titel gar nicht passt.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Bei einer Versorgungsspannung von 4,8V und einem Temperaturbereich von
> -40°C bis 85°C entnehme ich den vorher geposteten Kennlinien eine
> Differenz von 6kHz, was auf 128kHz bezogen eine Abweichung von knapp 5%
> entspricht. Was mal wieder nicht so in meine Praxiserfahrung passt (
> siehe 117kHz = -8,6% ).
>
Habe mich in anderen Threads gewundert warum diese öfter dort erwähnten 
+/- 10% Toleranz für den kalibrierten internen RC-Oszillator genannt 
wurden.

Endlich habe ich es auch gefunden ( Calibrated Internal RC Oscillator 
Accuracy -> siehe Screenshot ).


Bernd_Stein

[Hugo H. (hugohurtig1)]

Bernd S. schrieb:
> Endlich habe ich es auch gefunden

"Um die Befassung mit 500-seitigen Device-Databooks kommst Du nur um den 
Preis herum, dass Du nur triviales Zeugs beherrscht und nix von den 
Innereien verstehst."

http://www.avr-asm-tutorial.net/avr_de/beginner/asm_beginner.html

Ganz unten - unter Fazit :-)

[Peter D. (peda)]

Bernd S. schrieb:
> was auf 128kHz bezogen

Jetzt fällt es mir erst auf, Du nimmst ja den WD-Oszillator. Der läßt 
sich nicht kalibrieren und ist super ungenau.

Kalibriert ist nur der RC-Oszillator 9,6MHz.
Bei meinen Tests war er in der Regel so genau, daß es für eine UART 
taugte.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Peter D. schrieb:
> Jetzt fällt es mir erst auf, Du nimmst ja den WD-Oszillator. Der läßt
> sich nicht kalibrieren und ist super ungenau.
>
Oh, Mann ist dass wieder eine schwer zu überschaubare Sache. Und wieder 
ein Bild ...

Danke.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,


warum wird dies im AS7 mit debugWire im Einzelschritt nicht korrekt 
ausgeführt?


ATtiny13A

;
;Systemtakt ( 128kHz ) nochmals durch 128 teilen ( 1kHz )
;
 in   a,CLKPR        ;Clock Prescaler Register laden..
 sbr  a,1<<CLKPCE|0<<CLKPS3|0<<CLKPS2|0<<CLKPS1|0<<CLKPS0;Sicherheitsprozedur.. 
 out  CLKPR,a               ;..durchfuehren und..
 sbr  a,~1<<CLKPCE|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..jetzt Teiler einstellen..
 out  CLKPR,a        ;..und ueberschreiben

oder halt diese Variante :

sbr  a,0<<CLKPCE1|<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..jetzt Teiler einstellen..

Ich erwartete halt dass Ergebnis $07, aber CLKPCE bleibt gesetzt $87.


Bernd_Stein

[Oliver S. (oliverso)]

RTFM. In dem Fall das zu sbr.

Oliver

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Oliver S. schrieb:
> RTFM. In dem Fall das zu sbr.
>
> Oliver
>
Wer es nicht besser weiß, schreibt halt irgend einen Scheiß.


Bernd_Stein

[Stefan F. (Gast)]

Vielleicht ein Bug im Emulator? Oder hast du Debug-Wire benutzt?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Bernd S. schrieb:
> warum wird dies im AS7 mit debugWire im Einzelschritt nicht korrekt
> ausgeführt?
Weil zwischen den Befehlen dank des "Eiznelschrittes" zu viele CPU-Takte 
"vergehen"?
Aus dem RTFM:

    Write the Clock Prescaler Change Enable (CLKPCE) bit to one and all other bits in CLKPR to zero.
    Within four cycles, write the desired value to CLKPS while writing a zero to CLKPCE.

BTW:
Was kommt bei dieser Rechnung heraus:
~1<<CLKPCE|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0
Wie sind die Prioritäten der drei Operanden?
Wenn du das nicht sofort sicher sagen kannst, dann fehlen da ein paar 
Klammern.

[Sinus T. (micha_micha)]

Erst regt ihr auch auf, dass er den Thread gekapert hat, und dann macht 
ihr fleißig mit...

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Lothar M. schrieb:
> Was kommt bei dieser Rechnung heraus:
> ~1<<CLKPCE|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0
> Wie sind die Prioritäten der drei Operanden?
> Wenn du das nicht sofort sicher sagen kannst, dann fehlen da ein paar
> Klammern.
>

;
;Systemtakt ( 128kHz ) nochmals durch 128 teilen ( 1kHz )
;
 in   a,CLKPR               ;Clock Prescaler Register laden..
 sbr  a,1<<CLKPCE|0<<CLKPS3|0<<CLKPS2|0<<CLKPS1|0<<CLKPS0;Sicherheitsprozedur.. 
 out  CLKPR,a               ;..durchfuehren und..
 sbr  a,~1<<CLKPCE|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..jetzt Teiler einstellen..
 out  CLKPR,a               ;..und ueberschreiben

oder halt diese Variante :

 sbr  a,0<<CLKPCE|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..jetzt Teiler einstellen..

Durch deine Anregung habe ich mal im Simulator verschiedene Sachen 
ausprobiert. Die Klammersetzung war nicht dass eigentliche Problem, 
sondern der Umstand dass der SBR-Befehl identisch mit dem ORI-Befehl 
ist.

Ich lese ja das Clock Prescaler Register aus und überschreibe es per 
OR-Befehl mit einer Maske ( ORI-Befehl ).

Mit OR kann man natürlich nur Bits setzen !!!

Das zweite Ueberschreiben per OR-Befehl mit 0 für CLKPCE bewirkt 
natürlich nichts für dieses Bit.

Im Auslieferungszustand beginnend :

0000 0011 CLKPR
1000 0000 ORI
---------
1000 0011 CLKPR
0000 0111 ORI
---------
1000 0111 CLKPR

;
;Systemtakt ( 128kHz ) nochmals durch 128 teilen ( 1kHz )
;
Hat natürlich wie immer bei mir große Probleme verursacht, die ich euch 
demnächst nicht vorenthalten werde.


Bernd S. schrieb:
> Oliver S. schrieb:
>> RTFM. In dem Fall das zu sbr.
>>
>>
> Wer es nicht besser weiß, schreibt halt irgend einen Scheiß.
>
Endschuldigung.
Hätte mir halt solch eine Ausführung gewünscht und dementsprechend 
verstanden, was du mir damit mitteilen wolltest. Ich war so beschränkt 
zu denken, es liegt am AS7 Assembler dessen Operatorfunktion : Bitweises 
NOT nicht so arbeitet wie ich es glaubte.

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> dass eigentliche Problem.. der Umstand dass der SBR-Befehl identisch
> mit dem ORI-Befehl ist.
> Mit OR kann man natürlich nur Bits setzen !!!

SBR heisst ja auch Set Bit in Register. Das Gegenstück dazu ist CBR 
Clear Bit in Register.

Ich bin erstaunt, dass du etwas anderes erwartet hast.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefan ⛄ F. schrieb:
> Ich bin erstaunt, dass du etwas anderes erwartet hast.
>
Bei meinem verschrobenem Denken dachte ich, setze BitX = 0 ;-)

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Leider wieder einmal nicht in meiner Muttersprache :

https://www.youtube.com/watch?v=LquFL2dlvDE

Wer kennt Übungsaufgaben im www die genau das ab ca. 19:20 behandeln.

Also die wirkliche Subtraktion von vorzeichenbehafteten Dualzahlen, wo 
der Subtrahend grösser ist als der Minuend.

Nicht die Additon des Zweierkomplements !

Ich glaub die Allerwenigsten raffen es wirklich, wie das hierbei mit dem 
Borgen geht. Trotzdem Danke an :

https://www.youtube.com/watch?v=gdd_RR62HMk




Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Verhält sich das V-Flag ( Zweierkomplement Überlauf / Unterlauf Anzeige 
) bei der subtraktion genauso wie hier beschrieben ?

" Ein Überlauf bei vorzeichenbehaftet betrachteten Zahlen kann nur dann
auftreten, wenn beide Operanden negativ oder beide positiv sind und ein
Vorzeichenwechsel (Bit 7 kippt) erfolgt. "

Ich denke es ist der Vorzeichenbitwechsel im Ergebnis gemeint oder ?

Quelle :
Beitrag "Re: Overflow Bit bei Addition"

Nicht genug dass mich dieses V-Flag wahnsinnig macht, da muss mich 
natürlich auch noch der scheiss Simulator von Microchip verarschen.

Übe gerade die wirkliche schriftliche Subtraktion von Dualzahlen, also 
nicht die Addition mit dem Zweierkomplement.

 0011 1111 $3F
-0111 1101 $7D
--------------
 1100 0010 $C2

Warum wird dass V-Flag hier nicht gesetzt ?

Wie geht ihr vor um dass Setzen des V-Flags zu erkennen ?


Bernd_Stein

[Peter S. (cbscpe)]

Weil kein Überlauf stattfindet. $3f - $7d ist eine als 2-er complement 
darstellbare zahl. (63-125=-62).

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Peter S. schrieb:
> Weil kein Überlauf stattfindet. $3f - $7d ist eine als 2-er complement
> darstellbare zahl. (63-125=-62).
>
Liest sich logisch, dann muss ich die Aussage in meinem Lehrbuch falsch 
interpretieren oder es gilt nicht Allgemein, aber dann sollte es in 
einem Lehrbuch wenigstens erwähnt werden und nicht den Anschein 
erwecken, dass dies eine Regel für dass V-Flag wäre.

Es geht hier um AVR8-Assembler ( AVR8ASM ) :

V=1 => Rd7=0, Rr=0 & R7=1
    => Rd7=1, Rr=1 & R7=0

Gegenbeispiel :

 $7F   127
+$01  +  1
----  -----
 $80  -128

Hier ( bei der Addition ), passt es nämlich bei der vorzeichenbehafteten 
Sichtweise. Ich addiere zwei positive Zahlen, jedoch dass Ergebnis ist 
negativ, aber im erlaubten Zahlenbereich ( -128 <--- 0 ---> +127 ).

-128 ist ja auch eine als 2-er complemt darstellbare Zahl, wenn auch 
eine böse ;-)

Beitrag "Re: Overflow Bit bei Addition"


Bernd_Stein

[Yalu X. (yalu) (Moderator)]

Bernd S. schrieb:
> V=1 => Rd7=0, Rr=0 & R7=1
>     => Rd7=1, Rr=1 & R7=0

Steht das genau so in deinem Lehrbuch? Dann ist es ein Fehler.

Richtig wäre

V=1 <=> Rd7=0 & Rr7=0 & R7=1 |
        Rd7=1 & Rr7=1 & R7=0

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Yalu X. schrieb:
> Bernd S. schrieb:
>> V=1 => Rd7=0, Rr=0 & R7=1
>>     => Rd7=1, Rr=1 & R7=0
>
> Steht das genau so in deinem Lehrbuch? Dann ist es ein Fehler.
>
> Richtig wäre
>
> V=1 <=> Rd7=0 & Rr7=0 & R7=1 |
>         Rd7=1 & Rr7=1 & R7=0
>
Für mich schreibst du dass Selbe. Jetzt mal in Worten:

" Wenn beide Operatoren dass gleiche Vorzeichen haben, aber das Ergebnis 
ein anderes, dann wird das V-Flag gesetzt ( V= 1 ) ".

So ist es auch mit der Logik im Rechenwerkmodell des Schaubildes 
dargestellt.


Bernd_Stein

[Yalu X. (yalu) (Moderator)]

Bernd S. schrieb:
> Für mich schreibst du dass Selbe. Jetzt mal in Worten:

In der ursprünglichen Version fehlt bei Rr der Index (7). Außerdem ist
nicht ganz klar, was die Kommata bedeuten sollen. Letztendlich stehen
sie genauso wie das "&" für ein logisches "und". Schließlich muss der
zweite Folgepfeil ein logischen "oder" sein.

> " Wenn beide Operatoren dass gleiche Vorzeichen haben, aber das Ergebnis
> ein anderes, dann wird das V-Flag gesetzt ( V= 1 ) ".

Genau, das ist die Aussage. Der Vollständigkeit halbe könnte man noch
das "Wenn" durch "Genau dann, wenn" ersetzen um auszudrücken, dass in
allen anderen Fällen V=0 wird.

Aber dann ist doch alles in Ordnung. Wo siehst du da einen Widerspruch?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Yalu X. schrieb:
> In der ursprünglichen Version fehlt bei Rr der Index (7). Außerdem ist
> nicht ganz klar, was die Kommata bedeuten sollen.
> ...
>
Danke, ich brauch wohl mal eine Pause, meine Schusseligkeitsfehler 
machen Euch wahrscheinlich auch noch wahnsinnig.

Hier noch mal mein Problem, dass beide Operatoren positiv sind und das 
Resultat ( Ergebnis ) negativ, aber das V-Flag = 0.

Bernd S. schrieb:
> Übe gerade die wirkliche schriftliche Subtraktion von Dualzahlen, also
> nicht die Addition mit dem Zweierkomplement.
>
>  0011 1111 $3F
> -0111 1101 $7D
> --------------
>  1100 0010 $C2
>
> Warum wird dass V-Flag hier nicht gesetzt ?
>
> Wie geht ihr vor um dass Setzen des V-Flags zu erkennen ?
>

[Yalu X. (yalu) (Moderator)]

Bernd S. schrieb:
> Hier noch mal mein Problem, dass beide Operatoren positiv sind und das
> Resultat ( Ergebnis ) negativ, aber das V-Flag = 0.

Ach so, jetzt verstehe ich dein Problem.

Bernd S. schrieb:
> " Wenn beide Operatoren dass gleiche Vorzeichen haben, aber das Ergebnis
> ein anderes, dann wird das V-Flag gesetzt ( V= 1 ) ".

Diese Regel gilt nur für die Addition. Für die Subtraktion heißt die
Regel:

"Wenn das Ergebnis und der zweite Operand (Subtrahend) das gleiche
Vorzeichen haben, aber der erste Operand (Minuend) ein anderes, dann
wird das V-Flag gesetzt (V=1)"

Das ergibt sich aus der obigen Regel für die Addition und dem folgenden
Zusammenhang:

    Ergebnis = Minuend  - Subtrahend
<=> Minuend  = Ergebnis + Subtrahend

[Peter S. (cbscpe)]

Es ist so, mit 8-bit kann man ganze Zahlen im Bereich -128 bis 127 
darstellen (2-er complement). Das V Flag wird dann gesetzt wenn das 
Resultat der Addition oder Subtraktion, durchgeführt im Bereich der 
ganzen Zahlen, nicht mehr in diesem Bereich liegt. Z.Bsp. (wir verwenden 
SUB und ADD, nicht SBC, ADC, das braucht man erst bei Erweiterungen auf 
16-, 32-, .. bit)

127+1 = 128 liegt nicht mehr im Bereich -128 bis 127 -> V gesetzt

$3f-$7d = 63 - 125 = -62 liegt im Bereich -128 bis 127 -> V nicht 
gesetzt

$C2-$7D = -62 - 125 = -187 liegt nicht im Bereich -128 bis 127 -> V 
gesetzt

$C2-$FF = -62 - -1 = -61 liegt im Bereich -128 bis 127 -> V nicht 
gesetzt

Das gilt dann auch für 16-bit, 32-bit etc. arithmetik.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
>
> Wie geht ihr vor um dass Setzen des V-Flags zu erkennen ?
>
Ich habe mal meine geistigen Ergüsse hierzu dort hinterlassen :

https://www.edv-dompteur.de/forum/index.php?page=Thread&postID=5613#post5613


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

da ich mich in der Praxis bisher nie mit vorzeichenbehafteten Zahlen 
herumschlagen musste, fällt es mir schwer den Sinn des S-Flags zu 
verstehen.

Als Unterscheidung, ob eine Bitkombination nun als negative oder 
positive Zahl gewertet werden soll, dient doch schon das N-Flag.

Das das S-Flag ja in Verbindung mit dem V-Flag steht, verstehe ich auch 
nicht, was es bringen soll, wenn V=1 anzeigt, also das Ergebnis der 
Rechnung eh falsch ist, es dann doch von Nutzen sein soll, dass dieses 
falsche Ergebnis aber anhand des S-Flags nun das richtige Vorzeichen 
anzeigt.


Dieses hier läßt mich vermuten, dass das S-Flag nur die Befehle BRGE & 
BRLT bedient und ansonsten uninteressant ist.

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Vergleiche#Signed_.28S.29


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Den Sinn habe ich selber nicht herausfinden können und muss somit 
glauben, dass der wirklich Nutzbare darin besteht, dass man wie beim 
C-Flag bestimmen kann, ob ein Wert gleich, kleiner oder größer als der 
Andere ist.

Dies natürlich für negative Werte z.B. Rd= -4 & Rr= -3 -> S=1.

S=1 bei Rd kleiner Rr ( S=1 (-)Rd < (-)Rr ).


Bernd_Stein

[Jimi H. (jimih)]

http://www.rjhcoding.com/avr-asm-sreg.php

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jimi H. schrieb:
> http://www.rjhcoding.com/avr-asm-sreg.php
>
Der Vorzeichenmerker (S)

Der Vorzeichenmerker ist ein zusätzliches Logikbit, mit dem bestimmt 
werden kann, ob das Ergebnis einer vorherigen Operation positiv oder 
negativ ist. Es handelt sich um die exklusive ODER-Verknüpfung des 
Negativ- und des Zweierkomplement-Überlauf-Flags. Es wird gesetzt, wenn 
das eine oder das andere gesetzt ist, aber nicht beide.

Betrachten wir die Subtraktion von 10 von -120. Es ist offensichtlich, 
dass das Ergebnis -130 ist, aber wenn wir dies versuchen

  ldi r16,0x88 ; lade r16 mit 0x88 (-120)
  ldi r17,0x0A ; lade r17 mit 0x0A (10)
  sub r16,r17 ; subtrahiere r17 von r16 (Ergebnis = 0x7E = 126)

Das Ergebnis ist nicht -130, da dieser Wert für eine 8-Bit-Zahl mit 
Vorzeichen zu groß ist. Nach dem Sub-Befehl wird der Negative Flag nicht 
gesetzt, da Bit 7 des Ergebnisses gelöscht ist. Der Vorzeichenmerker 
wird jedoch gesetzt, was korrekt anzeigt, dass das Ergebnis negativ sein 
sollte.

Betrachten Sie stattdessen die Addition

  ldi r16,0x78 ; lade r16 mit 0x78 (120)
  ldi r17,0x0A ; lade r17 mit 0x0A (10)
  add r16,r17 ; addiere r17 zu r16 (Ergebnis = 0x82 = 130)

Hier wird das Negative Flag gesetzt, obwohl das Ergebnis eindeutig 
positiv ist. Da jedoch ein Zweierkomplement-Überlauf auftrat, wird der 
Vorzeichenmerker nicht gesetzt, was korrekt anzeigt, dass das Ergebnis 
positiv ist.

Die Verwendung des Vorzeichen-Flags kann Ihnen eine bessere Vorstellung 
davon vermitteln, ob ein Ergebnis positiv oder negativ ist. Es ist sehr 
nützlich bei der Erstellung alternativer Verzweigungen, um Fälle wie die 
oben gezeigten zu behandeln.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)


Toll, erklärt jedoch immer noch nicht meine Frage :

Bernd S. schrieb:
> Als Unterscheidung, ob eine Bitkombination nun als negative oder
> positive Zahl gewertet werden soll, dient doch schon das N-Flag.
>
> Das das S-Flag ja in Verbindung mit dem V-Flag steht, verstehe ich auch
> nicht, was es bringen soll, wenn V=1 anzeigt, also das Ergebnis der
> Rechnung eh falsch ist, es dann doch von Nutzen sein soll, dass dieses
> falsche Ergebnis aber anhand des S-Flags nun das richtige Vorzeichen
> anzeigt.
>
> Dieses hier läßt mich vermuten, dass das S-Flag nur die Befehle BRGE &
> BRLT bedient und ansonsten uninteressant ist.
>

Bernd_Stein

[(prx) A. K. (prx)]

Bernd S. schrieb:
> Dieses hier läßt mich vermuten, dass das S-Flag nur die Befehle BRGE &
> BRLT bedient und ansonsten uninteressant ist.

Richtig. Das ist eine Besonderheit der AVRs.

Etliche Architekturen haben für Nutzung durch Sprungbedingungen die 4 
Flags N=negative, Z=zero, V=overflow, C=carry, wenngleich nicht durchweg 
mit diesen Namen. In den Sprungbedingungen können dann schon mal 
komplizierte Terme stehen, die gleich 2-3 Flags auswerten, wie N,V für 
GE/LT und N,V,Z für GT/LE.

AVRs jedoch testen in den Sprungbedingungen stets exakt ein Flag. Das 
macht es notwendig, bereits die Flags passend zu definieren und es führt 
zu diesem S-Flag. Man neigt allerdings gerne dazu, es mit dem S-Flag der 
x86 zu verwechseln, das dem N-Flag der AVRs entspricht.

Hintergrund ist eine Vereinfachung der Implementierung. Denn dadurch 
ähnelt die Arbeitsweise der bedingten Sprungbefehle den Befehlen 
SBIS/SBIC, angewandt auf das Statusregister, manifestiert in den 
eigentlichen bedingten Sprungbefehlen BRBS,BRBC. BRGE ist nur eine 
elegante Schreibweise des Befehls BRBC d,4.

Diese Eigenheit erklärt auch, weshalb es bei AVRs zwar die eher selten 
genutzten Befehle BRIE,BRID gibt, nicht aber die Vergleiche > und <=, 
mit und ohne Vorzeichen.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

(prx) A. K. schrieb:
> Bernd S. schrieb:
>> Dieses hier läßt mich vermuten, dass das S-Flag nur die Befehle BRGE &
>> BRLT bedient und ansonsten uninteressant ist.
>
> Richtig. Das ist eine Besonderheit der AVRs.
>
> Etliche Architekturen haben für Nutzung durch Sprungbedingungen die 4
> Flags N=negative, Z=zero, V=overflow, C=carry, wenngleich nicht durchweg
> mit diesen Namen. In den Sprungbedingungen können dann schon mal
> komplizierte Terme stehen, die gleich 2-3 Flags auswerten, wie N,V für
> GE/LT und N,V,Z für GT/LE.
>
> AVRs jedoch testen in den Sprungbedingungen stets exakt ein Flag. Das
> macht es notwendig, bereits die Flags passend zu definieren und es führt
> zu diesem S-Flag.
> ...
>
Danke (prx) A. K.,
dies ist eine super Erklärung die ich glauben und verstehen kann.

Unglaublich ich habe etwas richtig vermutet ;-).

(prx) A. K. schrieb:
> Diese Eigenheit erklärt auch, weshalb es bei AVRs zwar die eher selten
> genutzten Befehle BRIE,BRID gibt, nicht aber die Vergleiche > und <=,
> mit und ohne Vorzeichen.
>
Dies ist mir jetzt allerdings schon wieder zu hoch, wie man auf solch 
eine Schlußfolgerung kommt.

Ist > und <= nicht durch vertauschen der Operanden hinzu kriegen ?

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hier ist doch was faul. Einsprung bei dec_out:
Bei einer dreistelligen Zahl z.B. 255, werden die Hunderter richtig
angezeigt, für die Zehner wird Space ( $20 ) erzeugt und ...

;
;*********************************************************************** 
*/
;*                  */
;*      Display values on LCD        */
;* 
*/
;* 
*/
;*              Author: Peter Dannegger 
*/
;*                      [e-mail] 
*/
;* 
*/
;*********************************************************************** 
*/
;*********************************************************************** 
*/
;----------------------------------------------------------------------- 
--
;        Display value as "00" ... "255"
;----------------------------------------------------------------------- 
--
;input: a0 = value 0..255
;
dec_out00:
  set
  mov  a3, a0
  subi  a3, 100
  brcs  _dou2    ;if < 100
;----------------------------------------------------------------------- 
--
;        Display value as "0" ... "255"
;----------------------------------------------------------------------- 
--
;input: a0 = value 0..255
;used:  a0, a1, a2, a3
;
dec_out:
  mov  a3, a0
  clt      ;to suppress preceding zero
  ldi  a0, '0' - 1
_dou1:  inc  a0
  subi  a3, 100
  brcc  _dou1
  rcall  _dou6    ;output hundrets
_dou2:  ldi  a0, '0' + 10
_dou3:  dec  a0
  subi  a3, -10
  brcs  _dou3
  rcall  _dou6    ;output tens
  subi  a3, -'0'
  mov  a0, a3    ;output ones
_dou4:  set
_dou5:  rjmp  lcd_data
;
_dou6:  brts  _dou5    ;check preceding zero
  cpi  a0, '0'
  brne  _dou4
  ret
;----------------------------------------------------------------------- 
--

Bernd_Stein

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Bernd S. schrieb:
> Hier ist doch was faul.
Weil der Code von peda ist versteige ich mich zu der Behauptung: Ich 
glaube, du liegst falsch.

> Bei einer dreistelligen Zahl z.B. 255, werden die Hunderter richtig
> angezeigt, für die Zehner wird Space ( $20 ) erzeugt
Hast du das ausprobiert? Woher soll denn das Space überhaupt kommen?

> und ...
Und was?

[Justin S. (Gast)]

c-hater schrieb:
> Mit der Zeit lernt man es, seine Programmier-Ziele als logisch
> konsistente Abstraktion formulieren zu können.

Sorry, aber so ein abgehobener Satz in Verbindung mit:

> Fachbücher sind Mist, die kosten nur unnötig Geld und veralten schneller
> als das Papier verrotten kann, auf dem sie gedruckt sind.

zeugt einfach nur von undurchdachtem Gelaber. Ohne Fachbücher, z.B. über 
höhere Algorithmen, kommt beim Coden eben doch nur ineffizientes 
Herumgehacke heraus, das man in einem größeren Projekt besser wieder 
entfernt, da viel zu fehlerträchtig.


> Der Rest, nämlich den Kram dann mit den Mitteln der
> verfügbaren Sprache in ein funktionierendes Programm zu verwandeln, ist
> dann nur noch Handwerk. Eigentlich nur sowas wie eine Übersetzung.

Das ist zum größten Teil falsch.

Aber er dauert eben viele Jahrzehnte, bis man vieles durchschaut und 
tatsächlich ein wirklich erfahrener Programmierer ist.

[Rainer V. (a_zip)]

Justin S. schrieb:
>> Der Rest, nämlich den Kram dann mit den Mitteln der
>> verfügbaren Sprache in ein funktionierendes Programm zu verwandeln, ist
>> dann nur noch Handwerk. Eigentlich nur sowas wie eine Übersetzung.

Blödsinn....brauchst dich ja hier nur umschaun...und du siehst das 
Hanwerk blühen.
Rainer

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Lothar M. schrieb:
>> Bei einer dreistelligen Zahl z.B. 255, werden die Hunderter richtig
>> angezeigt, für die Zehner wird Space ( $20 ) erzeugt
> Hast du das ausprobiert? Woher soll denn das Space überhaupt kommen?
>
Vermutlich hast du Recht, denn PeDa steuert das LCD über einen Chip an, 
welcher die Daten seriell bekommt.

Einfach mal a0 = $FF setzen, bei

_dou5:
 rjmp  lcd_data

rjmp  lcd_data durch ret ersetzen und dies dann im Simulator beobachten. 
Dann siehst du wie Space zu stande kommt und ..., was halt mit der 
Einer-Stelle falsch läuft. Richtig müsste in der Zeile _dou5: nach 
einander 2, 5, 5 erscheinen.

Hier ist übrigens die Quelle des Übels ;-)

Beitrag "Zeit + Temperatur auf LCD mit AVR"


Bernd_Stein

[Peter D. (peda)]

Bernd S. schrieb:
> Hier ist übrigens die Quelle des Übels ;-)
>
> Beitrag "Zeit + Temperatur auf LCD mit AVR"

Danke für den Link. Sollte ein Fragesteller immer machen, wenn er was 
aus dem Kontext heraus reißt.

Bernd S. schrieb:
> Hier ist doch was faul. Einsprung bei dec_out:
> Bei einer dreistelligen Zahl z.B. 255, werden die Hunderter richtig
> angezeigt, für die Zehner wird Space ( $20 ) erzeugt und ...

Wie schon gesagt, es wird am Aufrufer liegen. Die Funktion selber gibt 
nur 1..3 Ziffern linksbündig aus.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Peter D. schrieb:
> Wie schon gesagt, es wird am Aufrufer liegen. Die Funktion selber gibt
> nur 1..3 Ziffern linksbündig aus.
>
Erst mal Entschuldigung, denn nur in meiner Birne ist etwas faul.
Und Danke für solch eine Trickreiche "Byte in ASCII" Routine.

Habe natürlich wieder Schusseligkeitsfehler gemacht und nicht verstanden 
wie das Ganze funktioniert, also dementsprechend zusätzlichen Mist 
gebaut.

Lernt man solche Programmiertricks in der Ausbildung oder kommt man im 
Laufe der Berufserfahrung auf so etwas ?

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Lernt man solche Programmiertricks in der Ausbildung oder kommt man im
> Laufe der Berufserfahrung auf so etwas ?

Erfahrung. In der Ausbildung lernt man natürlich auch was, aber das 
Lernen endet bei Softwareentwicklern nie.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Vielleicht hat ja Jemand eine Lösung, wie ich innerhalb dieser Routine 
mein Problem mit dem Minuszeichen hinbiegen kann :

Beitrag "outval.inc : Anzeige ohne führende Nullen"

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

jetzt mal ein anderes Problem bei der AVR8-Assemblerprogrammierung.

Der DS18B20 hat ja eine Auflösung von 12-Bit.

Wie sieht eine AVR8ASM-Routine aus, die die volle Auflösung auf einem 
LCD anzeigt ?

Ich weiß er hat nur eine Genauigkeit von +/- 0,5°C und das Ganze macht 
wenig Sinn, aber ich möchte trotzdem mal eine AVR8ASM-Routine sehen und 
verstehen, die z.B. 21,0625°C oder 21,9375°C auf einem LCD anzeigt ( 
2^-4 oder 2^-1 + 2^-2 + 2^-3 + 2^-4 ).


Bernd_Stein

[(prx) A. K. (prx)]

Bernd S. schrieb:
> Ist > und <= nicht durch vertauschen der Operanden hinzu kriegen ?

Weshalb das nicht weiter stört. Und beim Vergleich mit einer Konstanten 
(CPI) kommt man mit Anpassung der Konstanten weiter. Das fällt lediglich 
auf, wenn man diverse andere Architekturen kennt, die trotzdem den 
vollständigen Satz an Bedingungen bieten.

[Jimi H. (jimih)]

Bernd S. schrieb:
> aber ich möchte trotzdem mal eine AVR8ASM-Routine sehen und
> verstehen, die z.B. 21,0625°C oder 21,9375°C

Also erstens mal halte ich Dich für fähig die selber zu entwickeln
da ich Dir sonst zweitens unterstellen würde hier nur bequem Aufträge 
für andere zu erteilen die drittens im Grundsatz simpel umzusetzen sind: 
Mit Rechenoperationen hinreichender Stellenanzahl arbeiten und Ergebnis 
in ASCII umwandeln ist jetzt nicht das große Problem. Und nein, ich 
machs trotzdem nicht für Dich weil ich die Routine nicht brauche. Auf 
die Sinnlosigkeit der Aufgabenstellung in Zusammenhang mit der 
Genauigkeit des DS18B20 hattest Du ja dankenswerterweise schon 
hingewiesen. So wie Temperaturmessungen dieser Stellenzahl hinter dem 
Komma überhaupt meist wenig bringen.

[(prx) A. K. (prx)]

Bernd S. schrieb:
> aber ich möchte trotzdem mal eine AVR8ASM-Routine sehen und verstehen,

Wenn du weißt wie man den ganzzahligen Anteil anzeigt, und wie man eine 
Tabelle mit 16 Einträgen verwendet, dann kennst du einen möglichen Weg..

[(prx) A. K. (prx)]

Jimi H. schrieb:
> So wie Temperaturmessungen dieser Stellenzahl hinter dem Komma überhaupt
> meist wenig bringen.

Die 16tel Grade der Sensoren sind zwar ungenau, aber der Trend einer 
Temperaturveränderung lässt sich daraus sehr wohl ablesen.

[Jimi H. (jimih)]

(prx) A. K. schrieb:
> Jimi H. schrieb:
>> So wie Temperaturmessungen dieser Stellenzahl hinter dem Komma überhaupt
>> meist wenig bringen.
>
> Die 16tel Grade der Sensoren sind zwar ungenau, aber der Trend einer
> Temperaturveränderung lässt sich daraus sehr wohl ablesen.

Also erstens ist wenig ungleich gar nichts, zweitens die Diskussion ab 
welcher Stelle nun wirklich jeder Sinn verloren geht´eine um des Kaisers 
Bart und drittens die praktische Relevanz jedweder Temperaturänderung ab 
der zweiten Stelle hinter dem Komma oft nicht mehr gegeben da hochgradig 
variabel je nach Ort und Installation (im Falle etwa eines 
Außentemperatursensors).

[Peter D. (peda)]

Bernd S. schrieb:
> Wie sieht eine AVR8ASM-Routine aus, die die volle Auflösung auf einem
> LCD anzeigt ?

Für 1/16 muß man den Wert mit 1000 multiplizieren und dann ein gedachtes 
Komma vor das 3-letzte Digit setzen.

Für negativ festellen, ob negativ, den Betrag bilden (x=0-x) und ein '-' 
davor ausgeben.

Im Prinzip löst man Aufgaben in Assembler genau so, wie in Hochsprachen, 
d.h. man zerlegt das Problem in einzelne Schritte. In Hochsprachen hat 
man aber oft schon fertige Libs für Grundlagen, z.B. float für 
Kommazahlen.