STM32 uint16_t problem

[stm32_progger (Gast)]

Hallo,

ich habe das Problem, dass beim Zuweisen eines Wertes kleiner 0xFF nur 
die letzten 8bit der uint16_t gesetzt werden.

Ursächlich scheint der ASM befehl MOVS anstatt MOVW.
Hat jemand eine Idee warum das schief geht?
(auch ein (uint16_t) wie auf dem screenshot zu sehen bringt nichts.


Ich benutze IAR 7.40 und einen STM32F4

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

stm32_progger schrieb:

> ich habe das Problem, dass beim Zuweisen eines Wertes kleiner 0xFF nur
> die letzten 8bit der uint16_t gesetzt werden.

Woran erkennst du das?

> Ursächlich scheint der ASM befehl MOVS anstatt MOVW.

Nö.

Der von dir hervorgehobene Befehl lädt eine 0 ins Register R0, in
der nächsten Zeile wird der Inhalt dieses Registers in die lokale
Variable (auf dem Stack) geschrieben.

Zwei Zeilen darunter dasselbe nochmal mit 0xFFFF (65536), zuerst
als Wortladebefehl ins R0, danach wieder in die Stackvariable.

Das H in STRH bedeutet dabei, dass das Speichern als vorzeichenloses
Halbwort, also eben uint16_t erfolgt.

> Hat jemand eine Idee warum das schief geht?

Es geht nichts schief. :)

p.s.: Das „S“ in „MOVS“ bedeutet “update condition flags”.

[stm32_progger (Gast)]

danke schon mal;

ich probiere schon eine weile herum

wenn ich eine uint16_t variable habe und diese auf z.B. 0x0155 setzte 
habe ich im Watchfenster 0x0055

[Walter T. (nicolas)]

stm32_progger schrieb:
> wenn ich eine uint16_t variable habe und diese auf z.B. 0x0155 setzte
> habe ich im Watchfenster 0x0055

Und was passiert, wenn Du es auf 0x0155UL setzt?

[Little B. (lil-b)]

stm32_progger schrieb:
> wenn ich eine uint16_t variable habe und diese auf z.B. 0x0155 setzte
> habe ich im Watchfenster 0x0055

das klingt interessant, zeig doch dazu mal das disassembly.

Walter T. schrieb:
> Und was passiert, wenn Du es auf 0x0155UL setzt?

mich würde wundern, wenn der compiler so doof ist. warum sollte er da 
was wegkürzen?
Der Prozessor sollte damit auch kein problem haben, da mit MOV bis zu 
16bit als Literal geladen werden kann.

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

stm32_progger schrieb:

> wenn ich eine uint16_t variable habe und diese auf z.B. 0x0155 setzte
> habe ich im Watchfenster 0x0055

Davon steht allerdings nichts in deinem Code da oben.

Entweder compiliert der Compiler die andere Variante wirklich falsch,
oder aber (halte ich für wahrscheinlicher) dein Debugger zeigt was
Falsches an.  Sieh dir doch mal den Speicher direkt an: schau, welcher
Wert in SP drinsteht und dann schau an dieser Stelle auf den Speicher.

So unüberschaubar viel isses ja hier nicht.

[Seher (Gast)]

Es passt doch alles:
R0 wird mit 0 (32 Bit) geladen und dann mit Store Register Half Word (16 
Bit) kopiert. Danach das Gleiche mit 0xFFFF.

Ich denke die Darstellungsoption im Debugger passt nicht.

[W.S. (Gast)]

stm32_progger schrieb:
> wenn ich eine uint16_t variable habe und diese auf z.B. 0x0155 setzte
> habe ich im Watchfenster 0x0055

Also, nach Lesen deines Screenshots habe ich den starken Verdacht, daß 
das Problem nicht beim Compiler liegt, sondern an anderer Stelle:

- Problem mit deiner Typdeklaration, die vom Debugger womöglich anders 
gelesen wurde als vom Compiler?

- Problem mit deiner Architektur-Deklaration, (sowas wie M4 statt M3 
oder M0 und dergleichen), was ebenfalls zu Diskrepanzen zwischen 
Compiler und Debugger führen könnte

- sonstiges Problem zwischen Compiler und Debugger

Lies in deinem Programm doch mal die besagte Variable aus und schicke 
ihren Inhalt (nach Konvertierung zu Text) über ne serielle 
Schnittstelle.

W.S.