STM32 uint16_t problem

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 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?

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.

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.