AVR C/ASM Verständnisfrage

sorry, dies ist der korrekte Code.
cfg_ee ist ein Strukt im EEprom, cfg ist dasselbe Strukt im Ram.
CAST ist einfach ein Cast    *(char*)(&cfg-(unsigned int)&cfg_ee)
Der Grund wieso ich die vorgefertigten Funktionen nicht verwenden will
ist die Codegröße. Trotzdem ist die Verwendung von mulhi3 für mich
merkwürdig.

  for(EEAR = (unsigned int)&cfg_ee;EEARL<(char)(sizeof(cfg)+(unsigned 
int)&cfg_ee);CAST(char*,cfg-(unsigned int)&cfg_ee)[EEARL++]=~EEDR) 
EECR|=(1<<EERE); // copy EEprom to data
 6f4:  22 e0         ldi  r18, 0x02  ; 2
 6f6:  30 e0         ldi  r19, 0x00  ; 0
 6f8:  3f bb         out  0x1f, r19  ; 31
 6fa:  2e bb         out  0x1e, r18  ; 30
 6fc:  c9 01         movw  r24, r18
 6fe:  62 e1         ldi  r22, 0x12  ; 18
 700:  70 e0         ldi  r23, 0x00  ; 0
 702:  55 d0         rcall  .+170      ; 0x7ae <__mulhi3>
 704:  aa 27         eor  r26, r26
 706:  bb 27         eor  r27, r27
 708:  a8 1b         sub  r26, r24
 70a:  b9 0b         sbc  r27, r25
 70c:  a7 53         subi  r26, 0x37  ; 55
 70e:  bf 4f         sbci  r27, 0xFF  ; 255
 710:  2e 5e         subi  r18, 0xEE  ; 238
 712:  33 27         eor  r19, r19
 714:  27 fd         sbrc  r18, 7
 716:  30 95         com  r19
 718:  0c c0         rjmp  .+24       ; 0x732 <main+0x86>
 71a:  e0 9a         sbi  0x1c, 0  ; 28
 71c:  9e b3         in  r25, 0x1e  ; 30
 71e:  8d b3         in  r24, 0x1d  ; 29
 720:  ed 91         ld  r30, X+
 722:  fc 91         ld  r31, X
 724:  11 97         sbiw  r26, 0x01  ; 1
 726:  e9 0f         add  r30, r25
 728:  f1 1d         adc  r31, r1
 72a:  80 95         com  r24
 72c:  80 83         st  Z, r24
 72e:  9f 5f         subi  r25, 0xFF  ; 255
 730:  9e bb         out  0x1e, r25  ; 30
 732:  8e b3         in  r24, 0x1e  ; 30
 734:  90 e0         ldi  r25, 0x00  ; 0
 736:  82 17         cp  r24, r18
 738:  93 07         cpc  r25, r19
 73a:  7c f3         brlt  .-34       ; 0x71a <main+0x6e>

pic user schrieb:
> Trotzdem ist die Verwendung von mulhi3 für mich
> merkwürdig.

Das dürfte einfach das Resultat des verqueren Codes sein.

1

*(char*)(&cfg-(unsigned int)&cfg_ee)

Wenn du von einem Pointer auf ein Struct einen Integer-Wert abziehst, 
muss ja von der Adresse das Ergebnis von (Integer-Wert * sizeof(Struct)) 
abgezogen werden. Da ist deine Multiplikation.

Für mich macht deine ganze Pointer-Arithmetik keinen Sinn.
> cfg_ee ist ein Strukt im EEprom, cfg ist dasselbe Strukt im Ram.
Und warum sollte dann überhaupt irgendein Bedarf bestehen, die Adressen 
der beiden irgendwie miteinander zu verrechnen?

pic user schrieb:
> Der Grund wieso ich die vorgefertigten Funktionen nicht verwenden will
> ist die Codegröße.

Und auch das klingt für mich ziemlich unsinnig.

> Das dürfte einfach das Resultat des verqueren Codes sein.
schein so zu sein.

> Wenn du von einem Pointer auf ein Struct einen Integer-Wert abziehst,
> muss ja von der Adresse das Ergebnis von (Integer-Wert * sizeof(Struct))
> abgezogen werden. Da ist deine Multiplikation.

Wobei, ich habe mulh3 nicht nachfollzogen scheint aber ein *3 zu sein.
Aber das Strukt ist 18 bytes groß und es bekommt 18 als input.

> Für mich macht deine ganze Pointer-Arithmetik keinen Sinn.
>> cfg_ee ist ein Strukt im EEprom, cfg ist dasselbe Strukt im Ram.
> Und warum sollte dann überhaupt irgendein Bedarf bestehen, die Adressen
> der beiden irgendwie miteinander zu verrechnen?
Weil mit dem Array im Ram gearbeitet wird welches vom EEprom 
initialisiert
wird. Das Array sind eigentlich statische Werte, welche im 
Konfigurationsmodus geändert sowie dann als ganzes ins EEprom 
gespeichert werden.
>
> pic user schrieb:
>> Der Grund wieso ich die vorgefertigten Funktionen nicht verwenden will
>> ist die Codegröße.
>
> Und auch das klingt für mich ziemlich unsinnig.

Code hat jemand anders geschrieben, ich wurde gebeten die Softwäre zu 
ändern, mehr Funktionalität reinzubringen, und von 1.5kbyte sind es 
derzeit
2150byte welche ich nocht auf die 2k Grenze runterbringen muss.

Danke vielmals für deinen Support.

Zum Scluss noch der Code:

  for(EEAR = (unsigned 
int)&cfg_ee;EEARL-(uchar)((uint)&cfg_ee+sizeof(cfg));CAST(char*,cfg)[EEA 
RL++-(uchar)(uint)&cfg_ee]=~EEDR)  EECR|=(1<<EERE); // copy EEprom to 
data
 6f4:  82 e0         ldi  r24, 0x02  ; 2
 6f6:  90 e0         ldi  r25, 0x00  ; 0
 6f8:  9f bb         out  0x1f, r25  ; 31
 6fa:  8e bb         out  0x1e, r24  ; 30
 6fc:  68 2f         mov  r22, r24
 6fe:  6e 5e         subi  r22, 0xEE  ; 238
 700:  48 2f         mov  r20, r24
 702:  50 e0         ldi  r21, 0x00  ; 0
 704:  11 c0         rjmp  .+34       ; 0x728 <main+0x7c>
 706:  e0 9a         sbi  0x1c, 0  ; 28
 708:  3e b3         in  r19, 0x1e  ; 30
 70a:  2d b3         in  r18, 0x1d  ; 29
 70c:  83 2f         mov  r24, r19
 70e:  90 e0         ldi  r25, 0x00  ; 0
 710:  84 1b         sub  r24, r20
 712:  95 0b         sbc  r25, r21
 714:  e0 91 c9 00   lds  r30, 0x00C9
 718:  f0 91 ca 00   lds  r31, 0x00CA
 71c:  e8 0f         add  r30, r24
 71e:  f9 1f         adc  r31, r25
 720:  20 95         com  r18
 722:  20 83         st  Z, r18
 724:  3f 5f         subi  r19, 0xFF  ; 255
 726:  3e bb         out  0x1e, r19  ; 30
 728:  8e b3         in  r24, 0x1e  ; 30
 72a:  86 17         cp  r24, r22
 72c:  61 f7         brne  .-40       ; 0x706 <main+0x5a>

Im Vergleich zur stdlib spart dieser unleserliche Code 62 bytes flash,
getestet wie folgt:

#if 1
#define EEREAD   (1<<EERE)
#define EEWRITE  (1<<EEPE)|(1<<EEMPE)
void ee(char x) { char i; EECR=0;
  for(i=sizeof(cfg)-1,EEAR = (unsigned 
int)&cfg_ee;EEDR=CAST(char*,cfg)[i++],i--;EECR = 
(1<<EEMPE),EECR=x,CAST(char*,cfg)[i]=EEDR,--EEARL)  while(EECR & 
(1<<EEPE));
}

#else
#include <avr/eeprom.h>
#if 1
void ee(char x) { if (x==EEREAD) // +62 bytes flash
   eeprom_read_block((void*)&cfg, (const void*)&cfg_ee, sizeof(cfg));
   else
   eeprom_write_block((const void*)&cfg_ee,(void*)&cfg,  sizeof(cfg));

}
#else
#define EEREAD 0
#define EEWRITE 1
void ee(char x) { char i;  // +78 bytes flash
  for(i=sizeof(cfg);i--;CAST(char*,cfg)[i]=eeprom_read_byte(&cfg_ee+i)) 
if(x) eeprom_write_byte(&cfg_ee+i,CAST(char*,cfg)[i]);
}
#endif
#endif

und hier der ASM code.

#if 1
#define EEREAD   (1<<EERE)
#define EEWRITE  (1<<EEPE)|(1<<EEMPE)
void ee(char x) { char i; EECR=0;
 6ac:  28 2f         mov  r18, r24
 6ae:  1c ba         out  0x1c, r1  ; 28
  for(i=sizeof(cfg)-1,EEAR = (unsigned 
int)&cfg_ee;EEDR=CAST(char*,cfg)[i++],i--;EECR = 
(1<<EEMPE),EECR=x,CAST(char*,cfg)[i]=EEDR,--EEARL)  while(EECR & 
(1<<EEPE));
 6b0:  82 e0         ldi  r24, 0x02  ; 2
 6b2:  90 e0         ldi  r25, 0x00  ; 0
 6b4:  9f bb         out  0x1f, r25  ; 31
 6b6:  8e bb         out  0x1e, r24  ; 30
 6b8:  94 e0         ldi  r25, 0x04  ; 4
 6ba:  09 c0         rjmp  .+18       ; 0x6ce <ee+0x22>
 6bc:  e1 99         sbic  0x1c, 1  ; 28
 6be:  fe cf         rjmp  .-4        ; 0x6bc <ee+0x10>
 6c0:  9c bb         out  0x1c, r25  ; 28
 6c2:  2c bb         out  0x1c, r18  ; 28
 6c4:  8d b3         in  r24, 0x1d  ; 29
 6c6:  81 8b         std  Z+17, r24  ; 0x11
 6c8:  8e b3         in  r24, 0x1e  ; 30
 6ca:  81 50         subi  r24, 0x01  ; 1
 6cc:  8e bb         out  0x1e, r24  ; 30
 6ce:  e0 91 c9 00   lds  r30, 0x00C9
 6d2:  f0 91 ca 00   lds  r31, 0x00CA
 6d6:  81 89         ldd  r24, Z+17  ; 0x11
 6d8:  8d bb         out  0x1d, r24  ; 29
 6da:  f0 cf         rjmp  .-32       ; 0x6bc <ee+0x10>

Das großflächige Entfernen von Leerzeichen und Zeilenumbrüchen im 
Quellcode wird aber keinen Flash sparen. Das macht den Code nur noch 
unsleserlicher, als er eh schon ist. Und ich kann mir auch nicht so 
recht vorstellen, daß du mehr sparst, wenn du die gesamte Funktionalität 
in den Schleifenkopf steckst.

Mir scheint da aber auch ein logischer Fehler drin zu sein. Bei jedem 
Schleifendurchlauf inkrementierst du i und dekrementierst es wieder. Da 
du es als Abbruchkriterium nutzt, müßte das eine Endlosschleife ergeben. 
Ich sehe im Assemblercode auch keine Stelle, an der er wieder aus der 
Schleife rauskommt.

@Rolf Magnus

Danke, ich schlage mich mit dem Code schon zu lange rum, damit mir 
solche
idiotische Fehler unterlaufen. Dies reduziert leider auch die Anzahl
der gewonnen bytes, leider.

Ich hoffe ich bin fertig geworden, das wird sich morgen zeigen.


Mit folgendem Code sind es:
#define CFG_GET  (1<<EERE)
#define CFG_SET  (1<<EEPE)|(1<<EEMPE)

static void inline config_update(char type) {
  char i,j;
  for(j=cfg.ee_limit,i=0,EECR=0,EEAR=(unsigned int)&cfg_ee;j--;EEARL++)
    { while(EECR & (1<<EEPE));EEDR=CAST(char*,cfg)[i]; EECR = 
(1<<EEMPE),EECR=type,CAST(char*,cfg)[i++]=EEDR;}
}

AVR Memory Usage
----------------
Device: attiny24

Program:    2048 bytes (100.0% Full)
(.text + .data + .bootloader)

Data:         96 bytes (75.0% Full)
(.data + .bss + .noinit)

EEPROM:      127 bytes (99.2% Full)
(.eeprom)

und mit diesem:

#include <avr/eeprom.h>
static void inline config_update(char type) { if (type==EEREAD) // +62 
bytes flash
   eeprom_read_block((void*)&cfg, (const void*)&cfg_ee, cfg.ee_limit);
   else
   eeprom_write_block((const void*)&cfg_ee,(void*)&cfg, cfg.ee_limit);

}
AVR Memory Usage
----------------
Device: attiny24

Program:    2094 bytes (102.2% Full)
(.text + .data + .bootloader)

Data:         96 bytes (75.0% Full)
(.data + .bss + .noinit)

EEPROM:      127 bytes (99.2% Full)
(.eeprom)

Sven P. schrieb:
> Es gibt übrigens auch fertige Routinen in der avr-libc für sowas. Die
> sollte man auch tunlichst verwenden, wegen der Zeigerproblematik.

Irgendwann wurde die EEPROM-Lib auf indirekten Funktionscall umgestellt 
und hat riesig Flash verbraucht.
Ich hab daher meine eigene Funktion geschrieben.
Da Schreiben und Lesen viel gemeinsam hat, habe ich beides in eine 
Funktion gepackt. Das spart nochmals Code. Obendrein wird unnützes 
Schreiben vermieden. Man kann also immer die gesamte Struct sichern, 
auch wenn sich nur ein Element geändert hat.

1

#include <util\atomic.h>

2

3

#define  EESTART    0x0001

4

5

#define  EE_WRITE  1

6

#define  EE_READ    0

7

8

void eeprom( uint8_t *sram, uint16_t eep, uint16_t len, uint8_t write )

9

{

10

  uint8_t edat;

11

12

  do{

13

    while( EECR & 1<<EEPE );    // wait until previous write done

14

    EEAR = eep;

15

    EECR |= 1<<EERE;            // read pulse

16

    edat = EEDR;

17

    if( write ){                // if write flag

18

      if( edat != *sram ){      // and not equal

19

        EEDR = *sram;           // write EEPROM

20

        ATOMIC_BLOCK(ATOMIC_RESTORESTATE){

21

          EECR |= 1<<EEMPE;

22

          EECR |= 1<<EEPE;      // write pulse

23

        }

24

      }

25

    }else{

26

      *sram = edat;             // read EEPROM

27

    }

28

    sram++;

29

    eep++;                      // next address

30

  }while( --len );

31

}

32

33

void save_eedata()

34

{

35

  eeprom( (void*)&eedata, EESTART, sizeof( eedata ), EE_WRITE );

36

}

37

38

void read_eedata()

39

{

40

  eeprom( (void*)&eedata, EESTART, sizeof( eedata ), EE_READ );

41

}

eedata ist die Struct im SRAM.


Peter

pic user schrieb:

> Dies reduziert leider auch die Anzahl
> der gewonnen bytes, leider.

Lass einfach die Hacks. Das ist Käse, nur um ein paar Bytes zu sparen!

Verursachen diese paar Bytes mehr denn wirklick Probleme ?

Oder ist's von der Sorte "Ich weis da was besser als der Compiler und 
will auf Biegen nd Brechen das Byte sparen"?

Wenn dich die Multiplikation sooo nervt oder wirklich absolut 
inakzeptabel ist, dann verabschiede dich von deiner alten Toolchain! Und 
verwende stattdessen was zeitgemässes wie zB avr-gcc 4.7.1.

Der macht die Multiplikation nicht mehr per libgcc-Aufruf, zumindest 
falls der µC über MUL verfügt.

@Peter Dannegger
Danke, ein wirklich netter code, und er zeigt mir auch wie man das
mit den   ATOMIC_BLOCK machen sollte. Nach ein paar defines konnte ich 
es mit -std=c99 compilieren. Beides werde ich in Zukunft nutzen.

Gegenüber der AVR Lib erspart er 20 byte code (version 4.3.3 von GCC)

Inzwischen ist der Code auch mit der realen HW getestet und läuft 
soweit.

@ Johann L. (gjlayde)
Der Unterschied ist, ob das Programm in den Prozessor reinpasst oder 
nicht.

pic user schrieb:

> @ Johann L. (gjlayde)
> Der Unterschied ist, ob das Programm in den Prozessor reinpasst oder
> nicht.

Lohnt sich denn -mcall-prologues? Das bringt idR nur was bei extrem 
teuren Funktionen wie float-Berechnungen. Andsonsten hat man eher 
billige Prologe, und mit -mcall-prologues wird der Code gerne mal 
größer.

Neben -Os gibt's noch weitere Optionen die man antesten kann wie 
-fno-split-wide-types, -fno-inline-small-functions, -morder1 bzw. 
-morder2 und natürlich generell intelligentere Unsetzung.

Gibt es denn ein nicht verhuntzes, übersetzbares Beispiel für den Code 
von oben?