ATtiny13 und Konstanten vs. Variablen.

Ronny G. schrieb:
> Kann mir mal bitte jemand sagen was da schief läuft?

Wahrscheinlich kompilierst du mit der Controllereinstellung für einen 
Atmega. Das Programm kommt zwar auch nicht dort zum Laufen, wo es 
normalerweise bei einem Attiny13 laufen sollte, da es aber kurz ist, 
passt es trotzdem noch rein.
Etwas anderes ist aber der RAM. Bei den Atmegas gibt es den Extended 
I/O-Bereich. Der ist fast dreimal so gross, wie das Daten-RAM des 13er. 
Danach kommt dann der Daten-RAM. Damit käme die Variable ungefähr 4,3mm 
neben dem Gehäuse deines Attiny zu liegen.

mfg.

ich habe jetzt nochmal die Einstellungen geprüft (Atmel Studio). Das 
Programm wird direkt für den ATtiny13 compiliert.

Ronny G. schrieb:

> Kann mir mal bitte jemand sagen was da schief läuft?

Zeig mal die .lss Datei die erzeugt wird

Bernd K. schrieb:
> Zeig mal die .lss Datei die erzeugt wird

Beide .lss und das .c

mfg.

Klingt als würde er die globale Variable nicht initialisieren. Das wäre 
ein compiler bug.

Möglicherweise macht der Optimizer auch eine stillschweigend eine 
Registervariable draus, die kann man aber nicht mit einem Initializer 
automatisch initialisieren, vielleicht fällt das dann versehentlich 
unter den Tisch. Die .lss wäre wirklich aufschlussreich.

Dieter Frohnapfel schrieb:
> volatile uint8_t pinmask = 0x55;
>
> int main(void)
> {
>   DDRB = 0xff;
>   38:  8f ef         ldi  r24, 0xFF  ; 255
>   3a:  87 bb         out  0x17, r24  ; 23
>
>   while(1 != 0) PORTB = pinmask;
>   3c:  80 91 60 00   lds  r24, 0x0060
>   40:  88 bb         out  0x18, r24  ; 24
>   42:  fc cf         rjmp  .-8        ; 0x3c <main+0x4>
>
> 00000044 <_exit>:
>   44:  f8 94         cli
>
> 00000046 <__stop_program>:
>   46:  ff cf         rjmp  .-2        ; 0x46 <__stop_program>



Wo ist der Teil der die Variable initialisiert, das volatile uint8_t 
pinmask = 0x55; das suche ich:

sts  0x0060, ...

fehlt, oder ist das irgendwo weiter oben? Poste doch mal die ganze Datei 
und nicht nur einen winzigen Schnipsel.

Dieter Frohnapfel schrieb:
> O.K., hier komplett ...

Bist du jetzt Ronny G., der unter anderem Namen postet? Oder was soll 
das?

mfg.

Dieter Frohnapfel schrieb:
> Kann eigentlich jeder andere auch machen - wollte nur helfen.

Deine Hilfsbereitschaft in allen Ehren, aber das hilft nicht weiter.

Das Programm, in beiden Versionen, kann gar nicht anders als 
funktionieren. Da bei ihm eine Version nicht funktioniert, ist bei ihm 
irgendwas faul. Das kann man aber nur an SEINEN Files erkennen.

mfg.

Bernd K. schrieb:
> Klingt als würde er die globale Variable nicht initialisieren. Das wäre
> ein compiler bug.

ich habe das Programm entsprechend angepasst -> keine Verbesserung

LSS und CPP habe ich in Anhang gepackt

1

00000038 <main>:

2

3

volatile uint8_t pinmask = 0x55;

4

5

int main(void)

6

{

7

  pinmask = 0x55;

8

  38:  85 e5         ldi  r24, 0x55  ; 85

9

  3a:  80 93 60 00   sts  0x0060, r24

10

  DDRB = 0xff;

11

  3e:  8f ef         ldi  r24, 0xFF  ; 255

12

  40:  87 bb         out  0x17, r24  ; 23

13

14

  while(1 != 0) PORTB = pinmask;

15

  42:  80 91 60 00   lds  r24, 0x0060

16

  46:  88 bb         out  0x18, r24  ; 24

17

  48:  fc cf         rjmp  .-8        ; 0x42 <__SREG__+0x3>

Das muss funktionieren. Ich sehe keinen Fehler.

Dieter Frohnapfel schrieb:
> Das kann man sogar bei MEINEN File-Auszügen erkennen - wenn man den
> hinschaut.
An deinen Auszügen sieht man, dass es funktioniert. Das sieht man an dem 
Quelltext aber auch so.

mfg.

Bernd K. schrieb:
> Das muss funktionieren. Ich sehe keinen Fehler.
Volle Zustimmung. Es sei denn das RAM ist kaputt.

mfg.

@Ronny

...und weiter oben bei __do_copy_data wird ebenfalls der Speicher bei 
0060 initialisiert. Und ich wette daß Dein hex file in der vorletzten 
Zeile eine 55 beinhaltet, vier Ziffern vor dem Zeilenende.

Dieter Frohnapfel schrieb:
> O.K., hier komplett ...

So blöd es auch klingt.
Aber jetzt muss auch noch das Hex-File her


Denn hier

1

  1c:  10 e0         ldi  r17, 0x00  ; 0

2

  1e:  a0 e6         ldi  r26, 0x60  ; 96

3

  20:  b0 e0         ldi  r27, 0x00  ; 0

4

  22:  ee e4         ldi  r30, 0x4E  ; 78

5

  24:  f0 e0         ldi  r31, 0x00  ; 0

6

  26:  02 c0         rjmp  .+4        ; 0x2c <__do_copy_data+0x10>

7

  28:  05 90         lpm  r0, Z+

8

  2a:  0d 92         st  X+, r0

9

  2c:  a2 36         cpi  r26, 0x62  ; 98

10

  2e:  b1 07         cpc  r27, r17

11

  30:  d9 f7         brne  .-10       ; 0x28 <__do_copy_data+0xc>

wird aus dem Flash die Intialisierung in den Speicher bugsiert.
Hier werden Bytes vom Flash 0x004E ins SRAM 0x0060 kopiert, von wo sich 
dann ...

1

  while(1 != 0) PORTB = pinmask;

2

  42:  80 91 60 00   lds  r24, 0x0060

3

  46:  88 bb         out  0x18, r24  ; 24

... das Programm den Wert holt.

D.h. die Frage lautet; wieso steht im Flash an der Adresse 0x004E nicht 
die 0x55, die dort eigentlich stehen sollten.

Leider sieht man das aber im LSS File nicht. Das hört ...

1

0000004c <__stop_program>:

2

  4c:  ff cf         rjmp  .-2        ; 0x4c <__stop_program>

... korrekterweise bei 0x4c/0x4d auf. Gleich dahinter müsste allerdings 
noch ein Byte mit dem Wert 0x55 stehen.

im Hex-File müsste man allerdings sehen, ob es da ist.

Dieter Frohnapfel schrieb im Beitrag #3873259:
> Bernd K. schrieb:
>> ...und weiter oben bei __do_copy_data wird ebenfalls der Speicher bei
>> 0060 initialisiert.
>
> Und womit? Ich würde gerne etwas hinzulernen. Ich sehe da kein 0x55 ...
> bin aber auch kein Assembler-Kenner ...
>
>
> 0000001c <__do_copy_data>:
>   1c:  10 e0         ldi  r17, 0x00  ; 0

Hier soll es hinkopiert werden, das ist der Startwert für das X Register 
(X = r26,r27)
>   1e:  a0 e6         ldi  r26, 0x60  ; 96
>   20:  b0 e0         ldi  r27, 0x00  ; 0

Und hier soll es herkommen, das ist der Startwert für das Z-Register 
(r30,r31)
>   22:  ee e4         ldi  r30, 0x4E  ; 78
>   24:  f0 e0         ldi  r31, 0x00  ; 0

>   26:  02 c0         rjmp  .+4        ; 0x2c <__do_copy_data+0x10>

inhalt von Programmspeicheradresse Z nach RAM-Speicheradresse X und 
beide eins erhöhen
>   28:  05 90         lpm  r0, Z+
>   2a:  0d 92         st  X+, r0

loop again until (X == 0062)
>   2c:  a2 36         cpi  r26, 0x62  ; 98
>   2e:  b1 07         cpc  r27, r17
>   30:  d9 f7         brne  .-10       ; 0x28 <__do_copy_data+0xc>

done with loop, now jump to main
>   32:  02 d0         rcall  .+4        ; 0x38 <main>
>   34:  0a c0         rjmp  .+20       ; 0x4a <_exit>

im HEX-File steht die 55 auch da.

Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so 
das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die 
Variante mit der Konstante, wärend die Variablen-Variante nicht lief. 
Daher habe ich den Fehler beim Flashen erstmal ignoriert.

danke für eure Hilfe

Ronny G. schrieb:
> ich habe das Programm entsprechend angepasst -> keine Verbesserung

 Keine Chance.
 Das, was du gepostet hast, funktioniert.
 PortB hat keine bits 6-7, bit 5 ist Reset, also:
 PB.0, PB.2, PB.4 gehen auf Log.1
 PB.1, PB.3 gehen auf Log.0

Was lernen wir daraus?
Dass das Problem sich wieder einmal vor dem PC befand.

Kopf >>- Tisch, 3 Mal!

Marc Vesely schrieb:
> Ronny G. schrieb:
>> ich habe das Programm entsprechend angepasst -> keine Verbesserung
>
>  Keine Chance.
>  Das, was du gepostet hast, funktioniert.
>  PortB hat keine bits 6-7, bit 5 ist Reset, also:
>  PB.0, PB.2, PB.4 gehen auf Log.1
>  PB.1, PB.3 gehen auf Log.0

Du warst zu langsam.

mfg.

Ronny G. schrieb:
> im HEX-File steht die 55 auch da.
>
> Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so
> das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die
> Variante mit der Konstante, wärend die Variablen-Variante nicht lief.
> Daher habe ich den Fehler beim Flashen erstmal ignoriert.

Facepalm

Ronny G. schrieb:
> Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so
> das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die

 Wie, zu niedrig ?

Dieter Frohnapfel schrieb:

> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen

In deinem Programm hast du eine andere Adresslage. Warum auch immer.

> - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:

Du siehst das falsch. DIe 0x50 ist die Checksumme

Hier

1

:02004800550061

2

         ^

3

         |

sind die 0x55

Dieter Frohnapfel schrieb:
> :02004800550061

Dieter Frohnapfel schrieb:
> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:
>
> :1000000009C019C018C017C016C015C014C013C04D
> :1000100012C011C011241FBECFE9CDBF10E0A0E671
> :10002000B0E0E8E4F0E002C005900D92A236B1071E
> :10003000D9F702D007C0E4CF8FEF87BB8091600073
> :0800400088BBFCCFF894FFCF50

hier:
> :02 0048 00 5500 61

> :00000001FF

das ist adresse 0048 und nicht 004e aber die 55 ist da, bist Du sicher 
daß das hex zum .lss passt? Evtl nochmal kompilieren nachdem Du die eine 
Zeile noch eingefügt hast?

Dieter Frohnapfel schrieb:
> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:

 Das ist mit Sicherheit nicht der Hex-File vom geposteten Programm.

Dieter Frohnapfel schrieb:
> Karl Heinz schrieb:
>> 4c:  ff cf         rjmp  .-2        ; 0x4c <__stop_program>
>
>> ... korrekterweise bei 0x4c/0x4d auf. Gleich dahinter müsste allerdings
>> noch ein Byte mit dem Wert 0x55 stehen.
>
> Da hätte ich jetzt erwartet, das nach ff cf -> 55 kommt.

Tuts ja auch :-)

Nur im Hex-File ist das dann eben der nächste Record.

Bernd K. schrieb:

> das ist adresse 0048 und nicht 004e aber die 55 ist da, bist Du sicher
> daß das hex zum .lss passt? Evtl nochmal kompilieren nachdem Du die eine
> Zeile noch eingefügt hast?

Marc schrieb
> Das ist mit Sicherheit nicht der Hex-File vom geposteten Programm.


@Dieter
Du siehst hoffentlich, was du angerichtet hast.
Dein hilfreicher Versuch in allen Ehren. Aber jetzt kommt Verwirrung 
rein.


An alle:
Alles in Ordnung. Dieter hat seine Version des Programms benutzt,
Beitrag "Re: ATtiny13 und Konstanten vs. Variablen."
in der die Init Sequenz

1

  1c:  10 e0         ldi  r17, 0x00  ; 0

2

  1e:  a0 e6         ldi  r26, 0x60  ; 96

3

  20:  b0 e0         ldi  r27, 0x00  ; 0

4

  22:  e8 e4         ldi  r30, 0x48  ; 72

5

  24:  f0 e0         ldi  r31, 0x00  ; 0

so aussieht. Kopieren von 0x0048 nach 0x0060

Alles: Alles in Ordnung. Anderes Programm - andere Adresslage.

Marc Vesely schrieb:
> Wie, zu niedrig ?

ich bin mit dem STK600 gerade am Testen bzw. Einarbeiten. Mit dem 
mega2560 funktionierte es alles (mehr oder weniger) auf Anhieb. Dann 
habe ich auf der Kleinen gewechselt und nichts ging mehr. Mit viel 
Suchen und Einstellungen und Tests habe ich das dann irgendwie halbwegs 
zum Laufen bekommen. Dabei habe ich aber auch die ISP Geschwindigkeit 
auf 5kHz gesetzt.

Man kann übrigens das hex file auch mit avr-objdump parsen und 
disassemblieren lassen, dann sieht man auch die 55 am Ende:

1

$ avr-objdump -j .sec1 -d -m avr5 test.hex 

2

3

test.hex:     Dateiformat ihex

4

5

6

Disassembly of section .sec1:

7

8

00000000 <.sec1>:

9

   0:   09 c0           rjmp    .+18            ;  0x14

10

   2:   19 c0           rjmp    .+50            ;  0x36

11

   4:   18 c0           rjmp    .+48            ;  0x36

12

   6:   17 c0           rjmp    .+46            ;  0x36

13

   8:   16 c0           rjmp    .+44            ;  0x36

14

   a:   15 c0           rjmp    .+42            ;  0x36

15

   c:   14 c0           rjmp    .+40            ;  0x36

16

   e:   13 c0           rjmp    .+38            ;  0x36

17

  10:   12 c0           rjmp    .+36            ;  0x36

18

  12:   11 c0           rjmp    .+34            ;  0x36

19

  14:   11 24           eor     r1, r1

20

  16:   1f be           out     0x3f, r1        ; 63

21

  18:   cf e9           ldi     r28, 0x9F       ; 159

22

  1a:   cd bf           out     0x3d, r28       ; 61

23

  1c:   10 e0           ldi     r17, 0x00       ; 0

24

  1e:   a0 e6           ldi     r26, 0x60       ; 96

25

  20:   b0 e0           ldi     r27, 0x00       ; 0

26

  22:   e8 e4           ldi     r30, 0x48       ; 72

27

  24:   f0 e0           ldi     r31, 0x00       ; 0

28

  26:   02 c0           rjmp    .+4             ;  0x2c

29

  28:   05 90           lpm     r0, Z+

30

  2a:   0d 92           st      X+, r0

31

  2c:   a2 36           cpi     r26, 0x62       ; 98

32

  2e:   b1 07           cpc     r27, r17

33

  30:   d9 f7           brne    .-10            ;  0x28

34

  32:   02 d0           rcall   .+4             ;  0x38

35

  34:   07 c0           rjmp    .+14            ;  0x44

36

  36:   e4 cf           rjmp    .-56            ;  0x0

37

  38:   8f ef           ldi     r24, 0xFF       ; 255

38

  3a:   87 bb           out     0x17, r24       ; 23

39

  3c:   80 91 60 00     lds     r24, 0x0060

40

  40:   88 bb           out     0x18, r24       ; 24

41

  42:   fc cf           rjmp    .-8             ;  0x3c

42

  44:   f8 94           cli

43

  46:   ff cf           rjmp    .-2             ;  0x46

44

  48:   55 00           .word   0x0055  ; ????

letzte Zeile:

1

48:   55 00           .word   0x0055  ; ????