4043 views|7 replies

143

Posts

0

Resources
The OP

stm8 long integer assignment failure [Copy link]

I'm working on a project recently, using stm8, and the compilation environment is stvd There is no problem reading and writing IDs, but when I assign an unsigned char array to a u32 bit, from 16 bits to 31 bits, it's either ffff or not displayed. Is it a compiler problem or something else?
This post is from stm32/stm8

Latest reply

It is clearly a problem of code writing: the following pbuf[x]  Details Published on 2017-2-6 15:34

6016

Posts

136

Resources
2
It's a data type problem. The int type of your 8-bit compiler is generally 16 bits, and literals are also int unless otherwise specified. So the result of an expression like
  1. pubf[2]<<16;
复制代码
is still int, which is 16 bits. It is obviously an overflow, so when 16-bit data is assigned to a 32-bit data type, the upper 16 bits cannot pass. Therefore, you need to convert the data type to make the subsequent calculation result 32 bits. So in the above expression, you only need to convert one of the operands to long. The simple way is to add an L after 16 to convert 16 to a long type literal. In this way, the calculation result of the two operands is long:
  1. pubf[2]<<16L;
复制代码

This post is from stm32/stm8

Comments

Adding an L at the end doesn't work either, and the result is the same. Adding a strong number at the front doesn't work either.  Details Published on 2017-1-19 12:00

6016

Posts

136

Resources
3
It seems that unsigned long is better, so it should be
  1. pubf[2]<<16UL;
复制代码
or
  1. (unsigned long)pubf[2]<<16;
复制代码


This post is from stm32/stm8

143

Posts

0

Resources
4
lcofjp posted on 2017-1-19 11:48 It's a data type issue. Your 8-bit compiler's int type is usually 16 bits, and literals are also ints unless otherwise specified, so this expression has to...
Adding an L at the end doesn't work, and the result is the same. Adding a strong at the front doesn't work either.
This post is from stm32/stm8

Comments

I don't believe it... Rebuild and debug again, unless the compiler has a bug, if not, adjust the assembly code  Details Published on 2017-1-19 12:02

6016

Posts

136

Resources
5
仙景发表于2017-1-19 12:00 Adding L at the end doesn't work either, the result is the same. Adding L at the front doesn't work either.
I don't believe it... Rebuild and debug again, unless the compiler has a bug, if that doesn't work, adjust the assembly code
This post is from stm32/stm8

Comments

It doesn't work. I also thought it was a type alignment problem at first. It didn't work even after adding it. I tried everything. I just thought it was a problem with the compiler.  Details Published on 2017-1-19 12:36

143

Posts

0

Resources
6
lcofjp posted on 2017-1-19 12:02 I don't believe it... rebuild and debug again, unless there is a bug in the compiler, if it doesn't work, you can adjust the assembly code
It doesn't work. I also thought it was a type alignment problem at first. It didn't work even after adding it. I tried everything. Just think it's a problem with the compiler.
This post is from stm32/stm8

37

Posts

471

Resources
7
It is not a compiler problem. Bit operations should pay attention to the CPU word length.
This post is from stm32/stm8

14

Posts

0

Resources
8
It is clearly a problem of code writing: the following pbuf[x]<
stm8 long integer assignment failure


This post is from stm32/stm8

Guess Your Favourite
Just looking around
Find a datasheet?

EEWorld Datasheet Technical Support

Related articles more>>

    EEWorld
    subscription
    account

    EEWorld
    service
    account

    Automotive
    development
    circle

    Robot
    development
    community

    Copyright © 2005-2025 EEWORLD.com.cn, Inc. All rights reserved 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号
    快速回复 返回顶部 Return list