Disasembliertes Hex-File in C nachprogrammieren

[Olli (Gast)]

Beim Aufräumen der Garage haben meine Kinder ein altes 
Metalldetektorprojekt
aus meiner Ausbildungszeit hervorgezaubert. Dieses soll nun aufgefrischt 
werden. Leider ist der Sourcecode nach Umzügen und neuer Hardware nicht 
mehr
vorhanden. Aber das Auslesen des Hex-Files aus dem Atmega8 hat 
funktioniert.
Es gibt einen Abschnitt der ISR(TIMER2_COMP_vect) im Disassembling den 
ich
nicht richtig verstehe.

cbi ADMUX, MUX0;  0000048C;  Lösche Bit MUX0 im PortRegister ADMUX
cbi PORTC, PORTC2;  0000048E;  Lösche Bit PORTC2 im PortRegister PORTC
cbi PORTC, PORTC5;  00000490;  Lösche Bit PORTC5 im PortRegister PORTC
lds r17, OnInterval;  00000492    10 91
rjmp Label_049C;  00000496;  Springe zu Label_049C
Label_0498:
rjmp Label_049A;  00000498;  Springe zu Label_049A
Label_049A:
rjmp Label_049C;  0000049A;  Springe zu Label_049C
Label_049C:
mov r16, r17;    0000049C;  Kopiere Inhalt von R17 in R16
dec r17;      0000049E;  R17 = R17 - 1, verringere R17 um 1
and r16, r16;            000004A0    00 23
brne Label_0498;            000004A2    D1 F7
sbi PORTC, PORTC5;  000004A4;  Setze Bit PORTC5 im PortRegister PORTC

Was passiert in den Zeilen 492 - 4A2 ?
Das kann doch nur eine Zeitschleife sein ?
Aber der Footprint eines _delays_us() sieht in Assembler anders aus.
In C sollte das doch so aussehen, oder ?

ADMUX &= ~(1<<MUX0);
PORTC &= ~(1<<PC2);
PORTC &= ~(1<<PC5);
while (OnInterval > 0) {
    OnInterval = OnInterval - 1;
}
PORTC |= (1<<PC5);

Habt Ihr eine Idee dazu ?

[Theobald (Gast)]

Olli schrieb:
> Was passiert in den Zeilen 492 - 4A2 ?

Welche sind das? Dein Assemblerlisting zeigt nur Zeilen 1 bis 15.

[Olli (Gast)]

Es sind die Zeilen 4 - 14, die richtige Nummerieung steht weiter rechts 
in
den Zeilen (00000492 - 000004A4).

[Ingo W. (uebrig)]

Du hast aber nur die ersten 14 Zeilen der Disassemblerausgabe in den 
Beitrag eingefügt. Besser die gesamte Datei als Anhang!

[MWS (Gast)]

Olli schrieb:
> Das kann doch nur eine Zeitschleife sein ?

Unvorteilhafte Darstellung.
Der einzige Sinn der rjmps jeweils auf ein darauf folgendes Label ist 
Zeit zu verbrauchen, z.B. um für die Laufzeit pro Schleifendurchlauf zu 
kompensieren.

[c-hater (Gast)]

Olli schrieb:

> Das kann doch nur eine Zeitschleife sein ?

Ja. Offensichtlich hat da ein dezimalsystemfixierter Assembler-Novize 
(ganz vorsichtig: Im Kontext eines Compilers) sein ganz persönliches 
Busy-Wait programmiert.

Ziel der Sache war wohl, ein (zur Laufzeit setzbares) Vielfaches von 
zehn MCU-Takten zu warten.

Wozu auch immer das gut gewesen sein soll. Warten ist fast niemals gut 
und wenn man schon ein busy wait baut, dann doch wenigstens eins, 
welches den Systemtakt kennt und die Takte entsprechend der Wartezeit 
berechnet, sprich (wenn man schonmal einen Compiler hat): _delay_us(). 
Kannte der Mann wohl noch nicht...

[MaWin (Gast)]

c-hater schrieb:
> Wozu auch immer das gut gewesen sein soll. Warten ist fast niemals gut
> und wenn man schon ein busy wait baut, dann doch wenigstens eins,
> welches den Systemtakt kennt und die Takte entsprechend der Wartezeit
> berechnet, sprich (wenn man schonmal einen Compiler hat): _delay_us().
> Kannte der Mann wohl noch nicht...

Leute, es geht nicht darum das Programm zu optimieren, sondern darum ein 
bestehendes Hex wieder in entsprechenden gleichen C-Code 
zurückzuwandeln.

[Nikolaus S. (Firma: Golden Delicious Computers) (hns)]

Olli schrieb:
> In C sollte das doch so aussehen, oder ?
>

> ADMUX &= ~(1<<MUX0);
> PORTC &= ~(1<<PC2);
> PORTC &= ~(1<<PC5);
> while (OnInterval > 0) {
>     OnInterval = OnInterval - 1;
> }
> PORTC |= (1<<PC5);
>

> Habt Ihr eine Idee dazu ?

Welchen Code erzeugt denn der C-Compiler daraus und wie ähnlich ist das 
Ergebnis zum vorgefundenen (Dis)Assemblerlisting?

[Jörg W. (dl8dtl) (Moderator)]

Weißt du denn noch, was für ein Compiler es mal war?

Ich würde das für etwas wie _delay_us(irgendwas) halten, allerdings 
erzeugt AVR-GCC dafür normalerweise einfach nur eine Schleife. Lediglich 
wenn man nach der Schleife noch "Finetuning" braucht, baut er noch so 
einen "rjmp ." Konstrukt rein, aber nicht in die Schleife.

#define F_CPU 1E6
#include <util/delay.h>
#include <avr/io.h>

void adcop(void) {

  ADMUX &= ~(1<<MUX0);
  PORTC &= ~(1<<PC2);
  PORTC &= ~(1<<PC5);

  _delay_us(13.3);

  PORTC |= (1<<PC5);
}

bringt, für einen ATmega8 compiliert:

  cbi 0x7,0
  cbi 0x15,2
  cbi 0x15,5
  ldi r24,lo8(4)
1:  dec r24
  brne 1b
  rjmp .
  sbi 0x15,5
  ret