Forum: Mikrocontroller und Digitale Elektronik Assembler lernen für Mikrocontroller-Programmierung

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.

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.

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... ;-)

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

MfG Paul

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.

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

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?

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

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

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

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

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.

1

.CSEG                       ;Beginn des Programmspeichers   

2

.ORG $0000                  ;Anfangsadresse einstellen

3

 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )

4

.ORG INT_VECTORS_SIZE       ;Ende der Interrupt-Vektoradressen einfuegen

5

6

_reset:                     ;Programmstartaddresse

7

 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren

8

 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

9

10

 rjmp -1                    ;Sprung auf sich selbst, also Endlosschleife

11

12

.EXIT                       ;Ende der Assemblierung

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

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

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

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

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.

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.

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

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

> Schöne Tischdecke

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

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


Bernd_Stein

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. 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.

1

.CSEG                       ;Beginn des Programmspeichers   

2

.ORG $0000                  ;Anfangsadresse einstellen

3

 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )

4

 nop

5

 nop 

6

 nop 

7

 nop

8

 nop

9

 nop

10

 nop

11

 nop

12

 nop

13

14

_reset:                     ;Programmstartaddresse ( $000A )

15

 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren

16

 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

17

18

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

19

 nop                        ;..also Endlosschleife

20

 nop

21

 nop

22

23

.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

Und noch was.
Welche Formatierung bekommt ihr zu sehen ?

Ich hoffe die Ok-Version ( siehe Anhang ).


Bernd_Stein

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

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!   :)

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.

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

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

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.

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

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/

1

.CSEG                       ;Beginn des Programmspeichers   

2

.ORG $0000                  ;Anfangsadresse einstellen

3

 rjmp _reset                ;Dies ist die Reset-Vektoradresse ( $0000 )

4

 nop

5

 nop 

6

 nop 

7

 nop

8

 nop

9

 nop

10

 nop

11

 nop

12

 nop

13

14

_reset:                     ;Programmstartaddresse ( $000A )

15

 sbi DDRB,1                 ;PortB1 als Ausgang konfigurieren

16

 sbi PORTB,1                ;PortB1 Ausgang auf High setzen

17

18

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

19

 nop                        ;..also Endlosschleife

20

 nop

21

 nop

22

23

.ORG FLASHEND               ;$01FF Ende des 1 kB bzw. 512 Word Flashbereichs

24

 nop

25

26

.EXIT                       ;Ende der Assemblierung

Bernd_Stein

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

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

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

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

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

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).

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

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

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

Oliver

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!

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

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

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

Zieladresse mod Flashend

oder

Flashend mod Zieladresse ?

oder

was genau ?


Bernd_Stein

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

Oliver

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

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

Jetzt mal ein anderes Problem.

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

1

;

2

;ADC freilaufend, 10-Bit, Aref=AVcc, 115200 Hz, digitale Eingangspuffer alle

3

;abschalten und Interrupt initialisieren

4

;

5

 ldi  a,$3F                 ;Alle digitalen Eingangspuffer abschalten..

6

 sts  DIDR0,a               ;..(PC0-5), um die Leistungsaufnahme zu reduzieren

7

8

 ldi  a,1<<REFS0            ;Aref = AVcc.. 

9

 sts  ADMUX,a               ;..mit 100nF am Aref-Pin

10

11

 ldi  a,1<<ADEN|1<<ADIE|1<<ADPS2;ADC Freigeben, Wandlung starten,..|1<<ADSC

12

 sts  ADCSRA,a             ;..ADC-IRQ freigeben und Vorteiler auf 16 

13

14

 lds  a,ADCSRA

15

 ori  a,1<<ADSC

16

 sts  ADCSRA,a

17

18

 sei                        ;Globale Interruptfreigabe im CPU-Statusregister

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. 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

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

Hallo zusammen,

warum ändert diese Programmsequenz nicht den Systemtakt ?

1

;

2

;Programmstart nach RESET  ( Interrupt Vektoren Tabelle )

3

;

4

.CSEG                       ;Was ab hier folgt kommt in den FLASH-Speicher

5

.ORG $0000                  ;Programm beginnt an der FLASH-Adresse 0x0000..

6

 jmp  _RESET                ;..mit der RESET-Vectortabelle

7

8

.include "IRQm6490.inc"     ;Restliche Interrupt Vektortabelle

9

10

.ORG INT_VECTORS_SIZE       ;Programmadresse nach den ganzen IRQ-Vektoren

11

12

_RESET:

13

 ldi  a,1<<CLKPCE           ;Vorbreitung zum Aendern des System..

14

 sts  CLKPR,a               ;..auf 1Mhz / 2 bzw. CLKPR = 16..

15

 ldi  a,1<<CLKPS2           ;..nun den Systemtakt ( 8 Mhz ) durch 16..

16

 sts  CLKPR,a               ;..teilen

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

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

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

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.

1

;

2

;Programmstart nach RESET  ( Interrupt Vektoren Tabelle )

3

;

4

.CSEG                       ;Was ab hier folgt kommt in den FLASH-Speicher

5

.ORG $0000                  ;Programm beginnt an der FLASH-Adresse 0x0000..

6

 jmp  _RESET                ;..mit der RESET-Vectortabelle

7

8

.include "IRQm6490.inc"     ;Restliche Interrupt Vektortabelle

9

10

.ORG INT_VECTORS_SIZE       ;Programmadresse nach den ganzen IRQ-Vektoren

11

;

12

;

13

;

14

_RESET:

15

 ;ldi  a,1<<CLKPCE           ;Vorbreitung zum Aendern des Systemtaktes..

16

 ;sts  CLKPR,a               ;..auf 8Mhz / 32 bzw. CLKPR = 32..

17

 ;ldi  a,1<<CLKPS2|1<<CLKPS0 ;..nun den Systemtakt ( 8 Mhz ) durch 32..

18

 ;sts  CLKPR,a               ;..teilen

19

20

 lds  a,CLKPR

21

;

22

;Stapelzeiger initialisieren (fuer Unterprogramme und / oder Interrupts)

23

; 

24

 ldi  a,High(RAMEND)        ;RAMEND, also das Ende vom SRAM, ist in der.. 

25

 out  SPH,a                 ;..Definitions-datei festgelegt  

26

 ldi  a,Low (RAMEND)

27

 out  SPL,a

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. 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

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 :

1

cp   r19,r17    ;Ist der Divisor groesser?

2

brlo div_zero   ;wenn JA,   dann bleibt die 0

3

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

1

ldi  r16, 109   ; Dividend    

2

ldi  r17,   9   ; Divisor

3

                ; Division r16: r17    

4

ldi  r18,   8   ; 8 Bit Division    

5

clr  r19        ; Register für die Zwischenergebnisse / Rest    

6

clr  r20        ; Ergebnis

7

8

divloop:    

9

lsl  r16        ; Zwischenergebnis mal 2 nehmen und das    

10

rol  r19        ; nächste Bit des Dividenden anhängen    

11

lsl  r20        ; das Ergebnis auf jeden Fall mal 2 nehmen,

12

                ; das hängt effektiv eine 0 an das Ergebnis an.

13

                ; Sollte das nächste Ergebnis-Bit 1 sein, dann wird

14

                ; diese 0 in Folge durch eine 1 ausgetauscht    

15

cp   r19, r17   ; ist der Divisor größer?    

16

brlo div_zero   ; wenn nein, dann bleibt die 0    

17

sbr  r20, 1     ; wenn ja, dann jetzt die 0 durch eine 1 austauschen ...    

18

sub  r19, r17   ; ... und den Divisor abziehen

19

20

div_zero:    

21

dec  r18        ; das Ganze 8 mal wiederholen    

22

brne divloop    ; in r20 steht das Ergebnis der Division

23

                ; 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

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]"

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.

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.

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?

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!

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.

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.

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.

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.

1

cp   r19,r17    ;Ist der Divisor groesser?

2

brlo div_zero   ;wenn JA,   dann bleibt die 0

3

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.

1

;

2

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

3

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

4

5

.DEF  divident    = r16  ;

6

.DEF  divisor    = r17  ;

7

.DEF  schritte    = r18  ;

8

.DEF  z_ergebnis  = r19  ;

9

.DEF  ergebnis    = r20  ;

10

11

.CSEG                   ;was ab hier folgt kommt in den FLASH-Speicher

12

.ORG $0000          ;Programm beginnt an der FLASH-Adresse 0x0000.CSEG 

13

14

_loop:     

15

 ldi  divident,109  ;Dividend    

16

 ldi  divisor,9    ;Divisor

17

      ;Division r16: r17    

18

 ldi  schritte,8  ;8 Bit Division    

19

 clr  z_ergebnis  ;Register für die Zwischenergebnisse / Rest    

20

 clr  ergebnis    ;Ergebnis

21

22

_divloop:    

23

 lsl  divident    ;Zwischenergebnis mal 2 nehmen und das    

24

 rol  z_ergebnis  ;nächste Bit des Dividenden anhängen    

25

 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    

26

 cp   z_ergebnis,divisor;ist der Divisor größer?    

27

 brlo _div_zero    ;wenn ja, dann bleibt die 0    

28

 sbr  ergebnis,1  ;wenn nein, dann jetzt die 0 durch eine 1 austauschen ...    

29

 sub  z_ergebnis,divisor;... und den Divisor abziehen

30

31

_div_zero:    

32

 dec  schritte    ;das Ganze 8 mal wiederholen    

33

 brne _divloop    ;in r20 steht das Ergebnis der Division

34

35

 rjmp _loop

36

37

.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

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 . . .

> 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.

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.

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

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?

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

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

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:

1

#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

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.

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. 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

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?

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

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?

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

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 :-)

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.