Code optimieren

Hi

>Kann man nachfolgenden Code noch verbessern?

Etwas. Wenn das Ergebnis 0 wird sind dein Speicherstellen $FFFF. Da 
brauchst du nichts wieder zurückrechnen unbd speichern.

1

.equ Count0_l = $60

2

.equ Count0_h = $61

3

4

.equ Count1_l = $62

5

.equ Count1_h = $63

6

7

8

   push R24                             'Register retten

9

   lds r24,sreg                         'Statusregister einlesen und

10

   push r24                             'auf den Stack schieben

11

   push r25

12

13

   lds R24,Count0_l                     '$60 = Low byte laden

14

   lds R25,Count0_h

15

   adiw R24:R25,1                       'Addition Word+1

16

   breq C0

17

   sts Count0_l,R24                     'zurück schreiben

18

   Sts Count0_h,R25

19

C0:

20

   lds R24,Count1_l                     '$62 = Low byte laden

21

   lds R25,Count1_h

22

   adiw R24:R25,1

23

   breq C1

24

   sts Count1_l,R24                     'zurück schreiben

25

   Sts Count1_h,R25

26

C1:

27

   pop R25                              'Register und

28

   Pop R24                              'Statusregister zurückholen

29

   sts sreg,R24                         '... und zurückschreiben

30

   pop R24

MfG Spess

Hi

>Hab gerade noch einen anderen Gedanken. Das High-Byte muss ja nur nach
>256 Schritten erhöht werden. Dann werde ich wohl ADIW raus nehmen.

Einfacher wird es dadurch auch nicht. Wenn andere Werte vorkommen können 
bleib bei deiner Variante.

MfG Spess

HI

>Im Mega8/32 Datenblatt ist geschrieben, dass in/out noch auf das SREG
>greifen können, und wenn du lds/sts verwendest, brauchst du 2 Takte
>länger!

Tragischer ist aber, das er mit lds/sts SREG nicht auf SREG zugreift.

MfG Spess

Wenn man GCC als Assembler nutzt, könnte es mit LDS/STS SREG 
funktionieren. Da wäre dann aber IN R24, _SFR_IO_ADDR(SREG) die bessere 
Lösung.

Beim Atmel Assembler sollte es aber richtig mit IN/OUT SREG sein.

Hi

>Mit SREG habe ich mal die Erfahrungen gemacht, dass eben diese Daten
>häufig verloren gingen, wenn ich in eine IRQ gesprungen bin.

>Damals habe ich LDS/STS SREG benutzt und keine Probleme mehr gehabt.

>Aber ich werde IN/OUT mal ausprobieren.

Kann ich nicht so richtig glauben.

SREG repräsentiert bei allen AVRs den Wert $3F. Das ist die IO-Adresse, 
die von in/out verwendet wird. Um auf die gleiche Adresse mit lds/sts 
zugreifen zu können muss $5F (SREG+$20) verwendet werden.

MfG Spess

Hi

>Habs auch mit IN/OUT probiert. ==> gleiches Ergebnis.

Mach das mal im AVR-Studio oder mit einem ICE. Da wirst du sehen, das 
das nicht so ist.

MfG Spess

Hi

Dann zeige mal die disassemblierten Codes

MfG Spess

Peter Dannegger schrieb:
> Da kenne ich mich nicht aus, was der verzapft.

Durchaus logisches.

> Und warscheinlich die anderen hier auch nicht.

Nicht ganz.

Der Bascom Assembler weis daß er bei IN/OUT auf SREG mit &h3F zugreifen 
muss und bei LDS/STS mit &h5F.

Funktion ist damit völlig korrekt, nur ineffektiv da IN/OUT 1 Takt 
schneller ist und niemand ohne Notwendigkeit die langsamere Version 
benutzt.

Wolfgang Schmidt schrieb:
> Kann man nachfolgenden Code noch verbessern?

Kürzer oder schneller?

Hi

>Der Bascom Assembler weis daß er bei IN/OUT auf SREG mit &h3F zugreifen
>muss und bei LDS/STS mit &h5F.

>Funktion ist damit völlig korrekt, nur ineffektiv da IN/OUT 1 Takt
>schneller ist und niemand ohne Notwendigkeit die langsamere Version
>benutzt.

Bringt aber, wie hier gesehen, Probleme im richtigen Leben.

Zumindest steht es in der BASCOM-Hilfe richtig drin.

MfG Spess

spess53 schrieb:
> Bringt aber, wie hier gesehen, Probleme im richtigen Leben.

Eigentlich nur, weil der TE die Helfer mit dem Verschweigen der 
Programmiersprache in's Blaue geschickt hat.

Hi

Du hast weiter oben geschrieben:

>Ich habe auch beide hex-Dateien durch einen Disassembler gejagt und
>erhielt bei der Disassemblierung jeweils STS/LDS bzw IN/OUT. Also hat
>mein Assembler auch den zugehörigen Code erzeugt.

Dabei hast du allerdings verschwiegen, das im disassemblierten Code eben 
nicht auf die gleiche Adresse zugegriffen wird.

MfG Spess

Wolfgang Schmidt schrieb:
> Also gibt es grundsätzlich zwei Möglichkeiten, IN/OUT und LDS/STS. Das
> Sollte jeder Assembler können.

Aber nicht jeder Assembler muss Dir zwingend die Symbole dafür 
bereitstellen. In den Includes zu AVR-Studio Assembler gibt's nur eine 
Definition zu SREG und die ist 0x3f.

Da wird aus:

1

ldi r16, SREG

dann:

1

LDI       R16,0x3F

Damit landest Du auf irgend einem anderen Register und deswegen waren 
die Hinweise berechtigt.

Außerdem kompiliert Dein Code sowieso nicht unter Bascom, denn das hier:

1

adiw R24:R25,1

würde eine Fehlermeldung erzeugen.

> Ich wollte den Code bez. der Laufzeit optimieren.
Dann weist Du jetzt, daß IN/OUT schneller ist.

Hi

>Dann muss mein BASCOM ein anderes sein, denn ADIW ist im DAtenblatt des
>Atmega8 zu finden !

Der Syntax lautet aber: Rdh:Rdl = Rdh:Rdl + K (aus Bascom-Hilfe).
Also

1

adiw R25:R24,1

MfG Spess

Wolfgang Schmidt schrieb:
> Ich wollte den Code bez. der Laufzeit optimieren.

Dann würde ich für die Zähler freie Register im IO-Bereich des µC 
verwenden, die mit 'in' und 'out' angesprochen werden können.
Zum Beispiel OCR1A und OCR1B oder auch ICR1. OSCCAL und TWBR könnten 
noch frei sein.

 C0:
    in R24,OCR1BL                     ' Low byte erhöhen
    inc R24
    out OCR1BL,R24                     'zurück schreiben
    BRNE  C1                             'noch kein Überlauf
    in R24,OCR1BH                     'High byte erhöhen
    inc R24
    out OCR1BH,R24                     'zurück schreiben
 C1:

Wolfgang Schmidt schrieb:
> Dann muss mein BASCOM ein anderes sein, denn ADIW ist im DAtenblatt des
> Atmega8 zu finden !

Selbstverständlich geht ADIW, nur in der von Dir verwendeten Syntax ist 
das unter Bascom nicht kompilierbar. Hättest Du es versucht, dann 
wüsstest Du das.

spess53 schrieb:
> Hi
>
>>Dann muss mein BASCOM ein anderes sein, denn ADIW ist im DAtenblatt des
>>Atmega8 zu finden !
>
> Der Syntax lautet aber: Rdh:Rdl = Rdh:Rdl + K (aus Bascom-Hilfe).
> Also

Da hast Du in der falschen Spalte geschaut, richtig ist:

Rdl, K6

D.h. es wird bei ADIW/SBIW nur das LByte angegeben, das HByte wird 
implizit angenommen. Das ist auch auf älteren Bascom-Versionen so, 
deshalb kann man auch sagen, daß wie vom TE angegeben:

adiw R24:R25,1

nie kompiliert wurde. Fehlermeldung ist: "Low Pointer register 
expected[R24:R25]

Während es so richtig wäre:

adiw R24,1

Wolfgang Schmidt schrieb:
> Der im ersten Beitrag gepostete Code wird einwandfrei und ohne Fehler
> und ohne Fehlermeldung in meinem BASCOM und mit meinem Atmega8
> verarbeitet.

Da's keine handgedrechselten Bascom-Versionen gibt, kann man schlicht 
und einfach sagen, daß der oben gepostete Code in dieser Form kein 
Bascom gesehen hat.

Wolfgang Schmidt schrieb:
> Wer das Gegenteil behauptet, der möge bitte den Beweis auch antreten und
> nicht vermutete Behauptungen in die Welt hinaus posaunen.

Schon passiert.

Wolfgang Schmidt schrieb:
> Ich habe einen sachlichen Thread eröffnet und keinen Thread um
> Rechthabereien. Eine Entwicklung die leider bei vielen Beiträgen
> festzustellen ist.

In etwa so wie schlampig gestellte Fragen und nicht gegebene 
Informationen um die Helfer in die Wüste zu schicken.

> Vermutungen habe ich selbst genug im Hinterkopf.

Das ist offensichtlich :D

Hi

>'Erweiterung von Timer0 durch ein High-Byte auf 16 Bit

Nein. Du hast dir einen 16-Bit Softwarezähler gebaut, der durch Overflow 
von Timer0 getriggert wird. Damit läuft dein 'Timer' mit 1/256 der 
möglichen Auflösung. Du brauchst dir also eigentlich keine Mühe geben 
ein paar Takte einzusparen.

MfG Spess

spess53 schrieb:
> Nein. Du hast dir einen 16-Bit Softwarezähler gebaut, der durch Overflow
> von Timer0 getriggert wird.

Besser gesagt, es wurde versucht einen zu bauen. Angefangen von nicht 
kompilierbar, über unnötig umständliche Variablendeklaration bis hin zu 
handwerklichen als auch Verständnisfehlern ist eigentlich alles 
enthalten.

Da dürften ab und zu sinnfreie Ausgaben auf dem LCD auftauchen.

Hi

>Warumm ich Zeit einsparen möchte, kann jeder von den Besserwissenden
>selbst erkenne. Oder etwa nicht ?

Du möchtest es. Tust aber das Gegenteil.

MfG Spess

Wolfgang Schmidt schrieb:
> wenn ich einen geeigneten anderen regfile als
> $regfile = "m8def.dat"
>
> auswähle, dann kann ich genau die gleichen Fehlermeldugen erzeugen.

Wenn man das gepostete File compiliert, dann kommen die Fehlermeldungen. 
Einstellungen in der IDE werden von Einstellungen im Code überschrieben.

> Warumm ich Zeit einsparen möchte, kann jeder von den Besserwissenden
> selbst erkenne.

Hat Dir Spess schon geschrieben, nach 256 Takten ändert sich erst einer 
der SW-Zähler. Also genug Zeit, was verstehst Du daran nicht ?

spess53 schrieb:
> Damit läuft dein 'Timer' mit 1/256 der
> möglichen Auflösung. Du brauchst dir also eigentlich keine Mühe geben
> ein paar Takte einzusparen.

1

Locate 2 , 1 : Lcd Speed0 ; "    "

Nicht-atomare Ausgabe eines 16-Bit Wertes. Hast Glück, daß die 
Randbedingungen (Häufigkeit der ext. Ints) nicht zu (sichtbaren) Fehlern 
führen.

1

$end Asm

2

3

Incr Lcd_out

Erst die Register sowie das SREG wieder herstellen, aber dann noch 'nen 
Basic-Befehl draufsatteln, der mindestens ein Register verändert.

Da wirst Du also noch ein bisserl daran arbeiten müssen, bis Du Dich zum 
von Dir geschaffenen Kreis der "Besserwissenden" zählen darfst ;D

Wolfgang Schmidt schrieb:
> Super erkannt habt ihr, dass alle 256 Takte ein Timer0-Interrupt
> ausgelöst wird. Wenn dabei dann 20 oder 30 Takte für einen interrupt
> gebraucht werden lohnt es sich, die Interruptzeit zu optimieren.

Nun, der Hintergrund war klar, die Frage war eher: warum machst Du's 
dann nicht richtig ? D.h.: Takte sparen. Das war auch Spess's Frage, 
deren Beantwortung Du schuldig bliebst.

Statt dessen wurschtelst Du 2 Softwarezähler hin, wobei einer gereicht 
hätte und bei dem einen hätte es wiederum gereicht den 8Bit Zähler 
selbst als Lowbyte zu verwenden und ihn nur um ein Highbyte auf 16Bit zu 
erweitern.

> Dass MWS sein BASCOM beim Compiliern oder das Bild so manipuliert hat,
> dass viele Fehlermeldungen auftreten, das wundert mich. Da würde ich
> doch glatt beim Hersteller reklamieren, die haben dir ein faules Ei zum
> Download angeboten.

Ich hab's versucht zu compilieren, 'nen Screenshot gemacht und 
zusätzlich auf die korrekte Verwendung laut Bascom-Hilfe hingewiesen. Du 
verstehst was genau daran nicht ?

> So zum Bsp. auch, dass nur der Ass-Code in ein anderes Programm
> eingefügt wird und somit das gesamte Umfeld für die Fragestellung
> bedeutungslos ist.

Du hast die Hilfswilligen erstmal in die Wüste geschickt, denn auch ich 
hätte dahinter keinen Bascom-Code vermutet, schon aufgrund der 
unzulässigen Syntax. Und die Sprache ist nun mal nicht belanglos.

> Ich verabschiede mich aus diesem Thread.

Betrachte ich nicht als Verlust :D

Hi,

is en thread wie so viele hier.

sinnvolle frage am anfang, verschiedene meinungen und dann persönliche 
angriffe.

hab mich den ganzen tag zurück gehalten.

in den beiträgen der "helfer" waren aber mehr irrtümer und falsche 
annahmen als fehler in dem anfangs und später geposteten code.

die fehlermeldungen von mws sind ganz schön manipuliert. in anderen 
zusammenhängen nennt man das urkundenfälschung.

hab den code mit bascom 2.05 compiliert, war fehlerfrei.

seine irrtümer hat w. doch eingestanden und er wird auch sinnvolle 
vorschläge nutzen.

wer hatte mov vorgeschlagen? ist vollkommener quatsch!

spess, mws haben dann immer weiter in den krümeln gesucht um nicht auf 
die eigenen irrtümer oder falsche annahmen zu müssen.

w. hat ja so viel verschwiegen, - was man als leser hätte selbst 
erkennen können -

und zwei 16bit softwarezähler, die ja nicht synchron laufen und einzeln 
gelöscht werden können, wie jeder kundige leser erkennen sollte, mit 
einem 8bit timer zu realisieren ist doch hier gut gelungen.

takte bei 20 - 30 von 256 einzusparen ist doch en sinnvolles ziel, wie 
jeder kundige leser erkennen sollte.

schönen abend
uwe

Uwe schrieb:
> hab mich den ganzen tag zurück gehalten.

Man hat auf Dich gewartet.

Uwe schrieb:
> die fehlermeldungen von mws sind ganz schön manipuliert.

So, so.

Uwe schrieb:
> , wie
> jeder kundige leser erkennen sollte.

> , wie jeder kundige leser erkennen sollte, mit
> einem 8bit timer

Gibt aber viele "Kundige" bei Dir, ist das so was wie "Besserwissende" ?

Der Thread war doch durchaus nützlich, der TE wurde auf einige Fehler 
hingewiesen, es gab sinnvolle Ratschläge, also alles ok.

Nur der wirklich sinn- und Inhalt-loseste Beitrag fehlte noch, und da Du 
den glücklicherweise geschrieben hast, ist nun auch das erledigt.