ATtiny4313 und Befehl ST Y,

[Rudi D. (rulixa)]

Will 18 Byte per ST Y+,r26 (ja 26, nicht 28 self referencing) speichern 
beginnend von r1 .
Yl hält den Anfangswert 1.

Entsprechend der doc sollte das möglich sein und das AVR Studio meckert 
auch nicht. Aber es funktioniert nicht.

Jetzt brauch ich natürlich viele Zeilen dazu.

Description:Stores ... from a register to data space. For parts with 
SRAM data space consits of reg file, I/O memory and internal SRAM.  usw.

Falschangabe in der ATMELdoc. Oder: was lese ich falsch.

[S. Landolt (Gast)]

> Aber es funktioniert nicht.
Lässt sich das näher beschreiben? Wie sieht das Programm, wie das 
(falsche) Resultat aus?

[Rudi D. (rulixa)]

in den Speicherstellen stehen nicht die Daten die da hinsollen.

So wars geplant:

  ;  clr    r0
;    mov    YH,r0
;    mov    ZH,r0
;    ldi    ZL,resi    ;da stehen die 19 Bytes zu 
;    ldi    YL,1    ;restore ab Adresse 1 = r1
;    ldi    A,19
;ret_er1:rcall  read_ee    ;Byte nach C , ZL wird hier auch incr.
;    ST    Y+,C    ;in die registerbank ab r1
;    dec    A
;    breq  ret_er1

So funktioniert es dann:

ret_err:        ldi  ZL,resi
    rcall  read_ee    ;ZL is incremented in read_rr
    mov  var_func,C
    rcall  read_ee
    mov  var_step,C  
    
    rcall  ld_RR_    ;in die Zwischenstation RX[0:3]
    mov  RY0,RX0    ;load 125 MHz Konstante
    mov  RY1,RX1
    mov  RY2,RX2
    mov  RY3,RX3    ;und endlich in RY[0:3]

    rcall  ld_RR_    ;hole den Stepwert nachRR[0:3]
    mov  RR0,RX0    ;
    mov  RR1,RX1
    mov  RR2,RX2
    mov  RR3,RX3  

    rcall  ld_RR_    ;hole den offsetAccu  nachRR[4:7]
    mov  RR4,RX0    ;
    mov  RR5,RX1
    mov  RR6,RX2
    mov  RR7,RX3  

    rcall  ld_RR_    ;restore DDSaccu nach RX[0:]

    rcall  read_ee
    sts  $006f,C    ;Wobbelzeitbyte

rd_RR_ liest 4 Byte aus dem EEPROM nch RX0[0:3], resi ist die Adresse im 
EEPROM

[S. Landolt (Gast)]

Jetzt fehlen noch die ".def"s, speziell für A,C, aber auch die anderen, 
und noch besser wäre ein assemblierbares Programm.
Bislang hat dieses Verfahren bei mir auf anderen AVR-Typen immer 
funktioniert, ich wüsste nicht, warum der ATtiny4313 eine Ausnahme sein 
sollte.

[Karl H. (kbuchegg)]

Das du dir hier irgendwann

;    ldi    A,19
;ret_er1:rcall  read_ee    ;Byte nach C , ZL wird hier auch incr.
;    ST    Y+,C    ;in die registerbank ab r1
;    dec    A

das Register A zerschiessen wirst, hast du bedacht?

[Rudi D. (rulixa)]

Karl H. schrieb:
> Das du dir hier irgendwann
>

> ;    ldi    A,19
> ;ret_er1:rcall  read_ee    ;Byte nach C , ZL wird hier auch incr.
> ;    ST    Y+,C    ;in die registerbank ab r1
> ;    dec    A
>

>
> das Register A zerschiessen wirst, hast du bedacht?

ja, A = r24

[Rudi D. (rulixa)]

S. Landolt schrieb:
> Jetzt fehlen noch die ".def"s, speziell für A,C, aber auch die anderen,
> und noch besser wäre ein assemblierbares Programm.
> Bislang hat dieses Verfahren bei mir auf anderen AVR-Typen immer
> funktioniert, ich wüsste nicht, warum der ATtiny4313 eine Ausnahme sein
> sollte.

C = r26 siehe thread start. XL, XH wird nie verwendet.
A = r24

[S. Landolt (Gast)]

Tja, dann kann es eigentlich nur noch an read_ee liegen.

[spess53 (Gast)]

Hi

>;    ldi    YL,1    ;restore ab Adresse 1 = r1

Woher weißt du, ob YH = 0 ist?

MfG Spess

[Rudi D. (rulixa)]

S. Landolt schrieb:
> Tja, dann kann es eigentlich nur noch an read_ee liegen.

;Read Inhalt der EEPROM-Adresse in ZL, Data in C register
read_ee:out  EEAR, ZL    ;Adresse im EEPROM festlegen
    cli
    sbi  EECR,EERE  ;set read auf 1, lesen beginnt.
    in  C,EEDR    ;und in C ablegen
    sei
    inc  ZL    ;nächste EEPROM Adresse festlegen
    ret

[Rudi D. (rulixa)]

spess53 schrieb:
> Hi
>
>>;    ldi    YL,1    ;restore ab Adresse 1 = r1
>
> Woher weißt du, ob YH = 0 ist?
>
> MfG Spess

Entsprechend doc zu ST Befehl kann bei datspace <256 Byte der 
hibytepointer für andere Zwecke verwendet werden. Seite 140 AVR 
Instruction Set

[S. Landolt (Gast)]

Die letzte Diskussion verstehe ich nicht, da stand doch:
> So wars geplant:
>  ;  clr    r0
>;    mov    YH,r0

[Rudi D. (rulixa)]

S. Landolt schrieb:
> Die letzte Diskussion verstehe ich nicht, da stand doch:
>> So wars geplant:
>>  ;  clr    r0
>>;    mov    YH,r0

Wollte ich noch editieren, aber du warst schneller.

Übrigens will ich das ganze Programm nicht öffentlich machen, da es die 
Chinesen sofort nachbauen. Schau im RMorg nach DDS. Der thread läuft ja 
dort.

[Markus (Gast)]

Warum lässt du dein Programm nicht einfach im Simulator laufen?

[Michael U. (amiga)]

Hallo,

ich komme im Moment mit Deinen Adressen nicht klar. Die Registeradressen 
bei Memory-Zugriff sind Registernummer + 0x20 also 0x20 - 0x5F
Die erste Ram-Adresse des 4313 ist 0x60.
Da die letzte Ram-Adresse des 4313 0x160 ist dürfte YH auch nicht egal 
sein, das würde nur beim 2313 klappen.

Gruß aus Berlin
Michael

[Rudi D. (rulixa)]

Michael U. schrieb:
> Hallo,
>
> ich komme im Moment mit Deinen Adressen nicht klar. Die Registeradressen
> bei Memory-Zugriff sind Registernummer + 0x20 also 0x20 - 0x5F
> Die erste Ram-Adresse des 4313 ist 0x60.
> Da die letzte Ram-Adresse des 4313 0x160 ist dürfte YH auch nicht egal
> sein, das würde nur beim 2313 klappen.
>
> Gruß aus Berlin
> Michael

Ich lese ja aus dem EEPROM mit max. 0...FF nach r1....r18 und ein Byte 
nach SRAM $006f

Der Zweck ist, dass nach ON/OFF des Gerätes die letzten Einstellungen 
wiederhergestellt werden.


Zuerst ist der Restoreprozess dran. Den letzten Zustand speichern im 
EEPROM muss ich erst machen. So weit bin ich noch nicht.

[S. Landolt (Gast)]

Vielleicht hilft ein Musterprogramm:

; avrasm2
  ldi  YH,0
  ldi  YL,1
  ldi  XL,19
loop:
   st  y+,XL
   dec XL
  brne loop

liefert:
r1 = $13
r2 = $12
r3 = $11
...
r18= $02
r19= $01

Ist allerdings ein ATtiny2313, ich habe keinen ATtiny4313.

[S. Landolt (Gast)]

Wie stellen Sie fest, dass die Registerinhalte nicht den EEPROM-Bytes 
entsprechen?
Was passiert in den Interruptroutinen, die Sie im read_ee wieder 
freigeben?

[Rudi D. (rulixa)]

Ja, so hab ich mir das auch vorgestellt.
LG Rudi

[Rudi D. (rulixa)]

S. Landolt schrieb:
> Wie stellen Sie fest, dass die Registerinhalte nicht den EEPROM-Bytes
> entsprechen?
> Was passiert in den Interruptroutinen, die Sie im read_ee wieder
> freigeben?

Weil im Display nicht die Daten aus r1...r18 und $006F zu sehen sind.

[S. Landolt (Gast)]

Dann haben Sie ja jetzt dieses Miniprogramm als Startpunkt. Sie lassen 
es laufen, sehen die korrekten Werte im Display, und können dann Stück 
für Stück Ihre Funktionen hinzufügen, bis der Fehler auftritt.

[Rudi D. (rulixa)]

S. Landolt schrieb:
> Dann haben Sie ja jetzt dieses Miniprogramm als Startpunkt. Sie lassen
> es laufen, sehen die korrekten Werte im Display, und können dann Stück
> für Stück Ihre Funktionen hinzufügen, bis der Fehler auftritt.

Wollte noch sagen, dass dies vielleicht der Fehler ist, da im Interrupt 
Y verwendet wird, aber da kann ich ja sperren oder die Encodervariablen 
ins Sram legen.

In der Source isz zwar weiträumig ein CLI /Sei Konstrukt. Aber das wird 
in read_ee umgangen.

IM prinzip passiert
cli
dann wiederholt cli/sei in read_ee

und später das sei zum ersten cli.
Das wird aber gestört von read_ee.
Das wirds wohl gewesen sein.
Danke.
Werde mit den Encodervariablen ins SRAM gehen. Dann bleibt Y ungestört.
Na ja, bin ja Hobbyprogrammer.

LG Rudi

[c-hater (Gast)]

Rudi D. schrieb:

> Ich lese ja aus dem EEPROM mit max. 0...FF nach r1....r18 und ein Byte
> nach SRAM $006f

Und? Wo die liest, interessiert bei ST Y+,reg kein Schwein. Wohin du 
schreibst, darum geht's hier.

Und da der 4313 nunmal mehr als 256Byte RAM hat, spielt dafür NATÜRLICH 
der Inhalt von YH eine Rolle, weil bei YL=1 entweder tatsächlich auf 
Adresse 1 geschrieben werden kann, was R1 im Registerfile entsprechen 
würde oder halt auf Adresse $101, was im SRAM liegt, je nachdem, ob Bit0 
in YH gesetzt ist oder nicht.

Kurzfassung: Du hast nicht annähernd kapiert, wie indirekte Adressierung 
funktioniert.

Außerdem hast du den Code mit einiger Wahrscheinlichkeit nichtmal selbst 
erdacht, sondern von einer Implementierung auf einem kleineren Tiny 
geklaut, die du nicht verstanden hast.

Und sowas will die Nichtveröffentlichung des Codes mit dem "Bösen 
Chinesen" erklären... Pfui Deibel!

Noch der allerletzte luschigste Codeklauer aus China kann ziemlich 
sicher besser programmieren als du! Zumindest kann er aber besser Code 
klauen und für seine Zwecke anpassen als du...

[c-hater (Gast)]

c-hater schrieb:

> Und da der 4313 nunmal mehr als 256Byte RAM

-Adressraum hat.

So sollte es heißen.

[Carl D. (jcw2)]

Nur will er eben genau RAM-Adresse 1..19, sprich R1..R19 indirekt 
erreichen.
Offenbar bedeutet "C hassen" nicht "Assembler lieben", sonst wär deine 
Antwort doch wohl nicht so sehr am Ziel vorbei, oder?

[Rudi D. (rulixa)]

Was kann man schon von von manchen Leuten erwarten, die nicht einmal dem 
Thread folgen können oder wollen.. Ich kenne meine Grenzen recht gut. 
Der Beitrag ist gemeldet. C-HATER

[spess53 (Gast)]

Hi

>Der Beitrag ist gemeldet. C-HATER

Witzbold. Ok, das unsinnige Laden mit R1 hatte ich übersehen. Aber deine 
Begründung ist genau so falsch. Der RAM des ATTiny4313 geht von 0 bis 
$15F. Beinhaltet also Register, IO und Ram. Damit trifft die Aussage vom 
Instruction Set bezüglich YH nicht zu.

MfG Spess

[Karl H. (kbuchegg)]

Rudi D. schrieb:
> Was kann man schon von von manchen Leuten erwarten, die nicht einmal dem
> Thread folgen können oder wollen.. Ich kenne meine Grenzen recht gut.
> Der Beitrag ist gemeldet. C-HATER

Ich für meinen Teil werde den Beitrag trotzdem stehen lassen.
Denn für alle ist klar ersichtlich, dass er sich wieder mal an 
irgendeiner Aussage aufhängt, weil er denkt da kennt er sich aus. Alle 
anderen lesen den Code und sehen

    clr    r0
    mov    YH,r0

YH hat also definitiv den Wert 0 und damit ist auch klar, dass dem Autor 
das alles durchaus bewusst war.
c-hater eben. Wenn es darum geht ein paar Sager rauszuhauen ist er 
schnell bei der Hand. Konstruktives kommt schon seltener.

[Karl H. (kbuchegg)]

Rudi D. schrieb:

> Wollte noch sagen, dass dies vielleicht der Fehler ist, da im Interrupt
> Y verwendet wird, aber da kann ich ja sperren oder die Encodervariablen
> ins Sram legen.

Oder du machst es dir zu eigen
* entweder in einer ISR ausnahmslos ALLE Register zu sichern, die 
benutzt werden
* oder dir eine grossformatige Erinnerung in den Code zu schreiben, dass 
einige Register (welche?) exclusiv für die Verwendung in der ISR 
reserviert sind und für nichts anderes gefahrlos benutzt werden dürfen.

[Rudi D. (rulixa)]

Es ist ohnehin ein Problem, schon nach Monaten, bei Adaptierungen wieder 
alles zurückzurufen. Dabei bin ich ein eifriger Kommentierer. Bin 
natürlich für Anregungen dankbar. Dieses Projekt ist ein Geraet, ich war 
ja u.a. Radioentwickler in meiner Jugend, das fast alle Funktionen 
bereitstellt um Radios zu entwickeln, siehe RMorg Spec. und Fotos. Der 
digitale Wobbler ist eine davon.
Immer wieder gibt es Ergänzungwünsche, wie diesen, die letzte 
Einstellung zu speichern. Bis vor Kurzem reichte ein t2313, aber jetzt 
ist er zu klein geworden.
Zum St Y+,C Problem: Im Interrupt läuft eine Drehencoderroutine aus 
diesem Forum, die 0,1 oder 2 zurückliefert für Li, Re und nicht gedreht 
in YL. Na ja.

Vielen Dank fuer eure Inputs. Ohne Diskussion und Anregungen hätte ich 
sicher länger gesucht.
LG Rudi

[S. Landolt (Gast)]

Weshalb werden innerhalb von read_ee die Interrupts eigens gesperrt?

;Read Inhalt der EEPROM-Adresse in ZL, Data in C register
read_ee:out  EEAR, ZL    ;Adresse im EEPROM festlegen
    cli
    sbi  EECR,EERE  ;set read auf 1, lesen beginnt.
    in  C,EEDR    ;und in C ablegen
    sei
    inc  ZL    ;nächste EEPROM Adresse festlegen
    ret

> In der Source isz zwar weiträumig ein CLI /Sei Konstrukt. Aber
> das wird in read_ee umgangen.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

S. Landolt schrieb:
> Weshalb werden innerhalb von read_ee die Interrupts eigens gesperrt?

Sowas wurde früher mal bei Schreib vorgängen aufs EEPROM gemacht, 
wimre, das Datenblatt des 2313 allerdings redet davon nicht mehr und bei 
Lesevorgängen ist es sowieso nicht nötig. Nach dem Setzen von EERE 
stehen die Daten in EEDR zur Verfügung - solange man will.

Es wird allerdings dringend empfohlen:
> The user should poll the EEPE bit before starting the read opera-
> tion.

Und das vermisse ich hier.

[Peter D. (peda)]

Matthias S. schrieb:
> Es wird allerdings dringend empfohlen:
>> The user should poll the EEPE bit before starting the read opera-
>> tion.
>
> Und das vermisse ich hier.

Nirgends steht, daß es im Code direkt davor stehen muß.
Es muß nur zeitlich davor gemacht werden, z.B. nach jedem 
Schreibzugriff.

[Ziegenpeter (Gast)]

>;    dec    A
>;    breq  ret_er1

Der Fehler ist "breq" statt "brne" - so fleigt er schon nach dem ersten 
Durchlauf raus, weil er nur nach ret_er1 geht, falls A gleich 0 (ist 
aber 18).

[S. Landolt (Gast)]

Schmerz, lass nach, tut das weh. Ich hatte diesen Teil mindestens 
zweimal überflogen.

[Paul B. (paul_baumann)]

S. Landolt schrieb:
> Ich hatte diesen Teil mindestens
> zweimal überflogen.

Du mußt auch mal dort landen.

;-)

MfG Paul

[S. Landolt (Gast)]

Ihn dünkt', er säh ein "ungleich Null",
das stand im Kommentar.
Er guckt' noch mal und merkt', es war
ja überhaupt nicht wahr.
"Wenn das noch mal passiert," sprach er,
"dann hör ich auf, noch dieses Jahr!"

[Paul B. (paul_baumann)]

Da kann ich nur Kermit zitieren: Applaus, Applaus, Applaus!
https://www.youtube.com/watch?v=2NTEBK8erAQ

MfG Paul

[Rudi D. (rulixa)]

BREQ statt BRNE: Danke. Ja das kommt davon, wenn man etwas fast 
automatisch schreibt.

Das cli und sei in read_ee ist einfach nur zur Sicherheit drin.

Das EEPE bit bleibt ja nur stehen, wenn der Schreibvorgang nicht 
erfolgreich war.
Die Schreibroutine hat die Abfrage natürlich. Dauert ja bis zu 3,4 ms je 
nach Code.

Aber eigentlich hat es nur Sinn, wenn man auch den watchdog das 
überwachen lässt, da man sonst voraussetzt dass EEPROM-Schreiben immer 
funktioniert.

An anderer Stelle, bei Steuerung des DDS via PC ist der watchdog aktiv.

So viel Echo hab ich gar nicht erwartet, Vielen Dank.
LG RUdi

[Rudi D. (rulixa)]

So sieht das Ding von einigen Anderen aus, die es auch aufgebaut haben.

http://www.radiomuseum.org/forum/dds_heimsender_beispiele.html

[Rudi D. (rulixa)]

Wollte nur verspätet sagen, dass alles perfekt funktioniert

Quelle Z Ziel Y  bei restore der Werte bzw. beim Speichern der 
Einstellungen.
Der DDS GEnerator kommt nach Wiedereinschalten mit der letzten 
Einstellung zurück.
Wenn's jemand interessiert.