blocks|key|931509|text|好的，一个实际工作的不动点版本：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|931510|//+Assume+a+28.4+format+for+math.++12.4+can+be+used,+but+roundoff+may+occur.

//+Input+should+be+a+literal+float+(Note+that+the+multiply+here+will+be+handled+by+the++
//+compiler+and+not+generate+FP+asm+code.+
#define+TO_FIXED(x)+(int)((x+*+16))

//+Takes+a+fixed+and+converts+to+an+int+-+should+turn+into+a+right+shift+4.
#define+TO_INT(x)+++(int)((x+/+16))

typedef+int+FIXED;
const+uint16_t+ADC_MIN+=+32768;

int+roundNo(uint16_t+bit_input)+
{+
++FIXED+num+=+(TO_FIXED(bit_input+-+ADC_MIN))+/+124;
++num+%2B=+num+<+0+?+TO_FIXED(-0.5)+:+TO_FIXED(0.5);
++return+TO_INT(num);
}

int+main()
{
++printf("%25d",+roundNo(0));

++return+0;
}|code-block|syntax|javascript|931511|注意，我们在这里使用了一些32位的值，所以它将比当前的值更大。不过，小心点，如果可以小心地管理舍入和溢出，它可能会转换回12.4+(16位int)。|931512|或者从web抓取一个更好的完整功能定点库:)|931513|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

OK, a version of fixed point that actually works:

<pre><code>// Assume a 28.4 format for math. 12.4 can be used, but roundoff may occur.

// Input should be a literal float (Note that the multiply here will be handled by the 
// compiler and not generate FP asm code. 
#define TO_FIXED(x) (int)((x * 16))

// Takes a fixed and converts to an int - should turn into a right shift 4.
#define TO_INT(x) (int)((x / 16))

typedef int FIXED;
const uint16_t ADC_MIN = 32768;

int roundNo(uint16_t bit_input) 
{ 
 FIXED num = (TO_FIXED(bit_input - ADC_MIN)) / 124;
 num += num &lt; 0 ? TO_FIXED(-0.5) : TO_FIXED(0.5);
 return TO_INT(num);
}

int main()
{
 printf("%d", roundNo(0));

 return 0;
}
</code></pre>

Note we are using some 32-bit values here so it will be bigger than your current values. With care though, it could possibly convert back to a 12.4 (16-bit int) instead if round off and overflow can be managed carefully.

Or go grab a better full feature Fixed Point library from the web :)

blocks|key|1143579|text|要确定为什么特定工具链上的代码如此之大，您需要查看生成的程序集代码，并查看它所调用的FP支持，然后查看映射文件以确定每个函数的大小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1143580|例如，在哥德波特+for+AVR上，使用GCC+5.4.0和-Os+(Godbolt不支持STM8或SDCC，因此这是作为一个8位体系结构进行比较)，您的代码生成6364字节，而空函数为4081字节。因此，代码体所需的附加代码为2283字节。现在，考虑到您使用的是不同的编译器和架构，它们与您的结果并没有太大的不同。请参阅生成的代码(下面)中的rcall到子程序(如__divsf3+)--这些是大部分代码所在的地方，我怀疑FP部门是最大的贡献者。|offset|length|style|CODE|1143581|roundNo(unsigned+int):
++++++++push+r12
++++++++push+r13
++++++++push+r14
++++++++push+r15
++++++++mov+r22,r24
++++++++mov+r23,r25
++++++++ldi+r24,0
++++++++ldi+r25,0
++++++++rcall+__floatunsisf
++++++++ldi+r18,0
++++++++ldi+r19,0
++++++++ldi+r20,0
++++++++ldi+r21,lo8(69)
++++++++rcall+__subsf3
++++++++ldi+r18,0
++++++++ldi+r19,0
++++++++ldi+r20,lo8(-8)
++++++++ldi+r21,lo8(66)
++++++++rcall+__divsf3
++++++++mov+r12,r22
++++++++mov+r13,r23
++++++++mov+r14,r24
++++++++mov+r15,r25
++++++++ldi+r18,0
++++++++ldi+r19,0
++++++++ldi+r20,0
++++++++ldi+r21,0
++++++++rcall+__ltsf2
++++++++ldi+r18,0
++++++++ldi+r19,0
++++++++ldi+r20,0
++++++++ldi+r21,lo8(63)
++++++++sbrs+r24,7
++++++++rjmp+.L6
++++++++mov+r25,r15
++++++++mov+r24,r14
++++++++mov+r23,r13
++++++++mov+r22,r12
++++++++rcall+__subsf3
++++++++rjmp+.L7
.L6:
++++++++mov+r25,r15
++++++++mov+r24,r14
++++++++mov+r23,r13
++++++++mov+r22,r12
++++++++rcall+__addsf3
.L7:
++++++++rcall+__fixsfsi
++++++++mov+r24,r22
++++++++mov+r25,r23
++++++++pop+r15
++++++++pop+r14
++++++++pop+r13
++++++++pop+r12
++++++++ret|code-block|syntax|javascript|1143582|您需要对工具链生成的代码执行相同的分析，以回答您的问题。毫无疑问，SDCC能够生成一个程序集列表和一个映射文件，这将使您能够准确地确定生成和链接了哪些代码和FP支持。|1143583|最后，尽管在这种情况下完全没有必要使用FP：|1143584|int+roundNo(uint16_t+bit_input)+
{+
++int+s+=+(bit_input+-+ADC_MIN)+;
++s+%2B=+s+<+0+?+-62+:+62+;
++return+s+/+124+;
}|1143585|与空函数相比，在哥德波特+2283字节处。仍然有点大，但最有可能的问题是，AVR缺少DIV指令，因此称为__divmodhi4。STM8有一个16位红利和8位除数的DIV，因此它很可能会更小(更快)。|1143586|entityMap|0|LINK|mutability|MUTABLE|url|https://godbolt.org/z/nP-FQw|1|https://godbolt.org/z/dkFVPD^0|0|U|3|4S|5|53|8|4|4|0|0|0|0|0|0|16|3|1G|B|2A|3|8|4|1|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]|$D|18|E|19|F|G]|$D|1A|E|1B|F|G]]|9|@$D|1C|E|1D|1|1E]]|A|$]]|$1|H|3|I|5|J|7|1F|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1G|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1I|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|1J|8|@$D|1K|E|1L|F|G]|$D|1M|E|1N|F|G]|$D|1O|E|1P|F|G]]|9|@$D|1Q|E|1R|1|1S]]|A|$]]|$1|U|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]|12|$5|X|Y|Z|A|$10|13]]]]

To determine why the code is so large on your particular tool chain, you would need to look at the generated assembly code, and see what FP support calls it makes, then look at the map file to determine the size of each of those functions.

As an example on <a href="https://godbolt.org/z/nP-FQw" rel="nofollow noreferrer">Godbolt</a> for AVR using GCC 5.4.0 with <code>-Os</code> (Godbolt does not support STM8 or SDCC so this is for comparison as a 8-bit architecture) your code generates 6364 bytes compared 4081 bytes for an empty function. So the additional code required for the code body is 2283 bytes. Now accounting for the fact that you are using both a different compiler and architecture, these are not that different from your results. See in the generated code (below) the <code>rcall</code>s to subroutines such as <code>__divsf3</code> - these are where the bulk of the code will be, and I suspect FP division is by far the larger contributor.

<pre><code>roundNo(unsigned int):
 push r12
 push r13
 push r14
 push r15
 mov r22,r24
 mov r23,r25
 ldi r24,0
 ldi r25,0
 rcall __floatunsisf
 ldi r18,0
 ldi r19,0
 ldi r20,0
 ldi r21,lo8(69)
 rcall __subsf3
 ldi r18,0
 ldi r19,0
 ldi r20,lo8(-8)
 ldi r21,lo8(66)
 rcall __divsf3
 mov r12,r22
 mov r13,r23
 mov r14,r24
 mov r15,r25
 ldi r18,0
 ldi r19,0
 ldi r20,0
 ldi r21,0
 rcall __ltsf2
 ldi r18,0
 ldi r19,0
 ldi r20,0
 ldi r21,lo8(63)
 sbrs r24,7
 rjmp .L6
 mov r25,r15
 mov r24,r14
 mov r23,r13
 mov r22,r12
 rcall __subsf3
 rjmp .L7
.L6:
 mov r25,r15
 mov r24,r14
 mov r23,r13
 mov r22,r12
 rcall __addsf3
.L7:
 rcall __fixsfsi
 mov r24,r22
 mov r25,r23
 pop r15
 pop r14
 pop r13
 pop r12
 ret
</code></pre>

You need to perform the same analysis on the code generated by your tool chain to answer your question. No doubt SDCC is capable of generating an assembly listing and a map file which will allow you to determine exactly what code and FP support is being generated and linked.

Ultimately though your use of FP in this case is entirely unnecessary:

<pre><code>int roundNo(uint16_t bit_input) 
{ 
 int s = (bit_input - ADC_MIN) ;
 s += s &lt; 0 ? -62 : 62 ;
 return s / 124 ;
}
</code></pre>

At <a href="https://godbolt.org/z/dkFVPD" rel="nofollow noreferrer">Godbolt</a> 2283 bytes compared to an empty function. Still somewhat large, but the issue there most likely is that the AVR lacks a <code>DIV</code> instruction so calls <code>__divmodhi4</code>. STM8 has a <code>DIV</code> for 16 bit dividend and 8 bit divisor, so it will likely be significantly smaller (and faster) on your target.

blocks|key|931611|text|(Update)写完这篇文章后，我注意到@Clifford提到您的微控制器本机支持这个DIV指令，在这种情况下，这样做是多余的。无论如何，我将把它保留为一个概念，它可以应用于DIV作为外部调用实现的情况，或者对于DIV周期过长、目标是使计算速度更快的情况。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|CODE|entityRanges|data|931612|无论如何，如果你需要挤出一些额外的周期，移动和加法可能比除法更快。因此，如果您从124几乎等于4096/33这一事实开始(误差因子为0.00098，即0.098%25，小于千分之一)，则可以使用33和移位12位(除以4096)实现除法。此外，33是32%2B1，这意味着乘以33等于左移5并再次添加输入。|931613|示例:您希望将5000除以124，而5000/124是接近的。40.323。我们要做的是：|931614|5,000+<<+5=+160,000|ordered-list-item|931615|160+000%2B5+000=165+000|931616|165,000+>>+12+=+40|931617|注意，这只适用于正数。还注意到，如果您真的在代码中执行大量乘法操作，那么具有单个extern+mul或div函数从长远来看可能会导致更小的整体代码，特别是在编译器不擅长优化的情况下。如果编译器可以在这里发出一个DIV指令，那么你唯一能得到的就是一点点的速度改进，所以不要为此烦恼。|931618|#include+<stdint.h>
#define+ADC_MIN+2048

uint16_t+roundNo(uint16_t+bit_input)+
{+
++++//+input+too+low,+return+zero
++++if+(bit_input+<+ADC_MIN)
++++++++return+0;

++++bit_input+-=+(ADC_MIN+-+62);
++++uint32_t+x+=+bit_input;

++++//+this+gets+us+x+=+x+*+33++++++++
++++x+<<=+5;
++++x+%2B=+bit_input;

++++//+this+gets+us+x+=+x+/+4096
++++x+>>=+12;

++++return+(uint16_t)x;
}|code-block|syntax|javascript|931619|尺寸优化的GCC+AVR产生这，即所有对extern+mul或div函数的调用都没有了，但似乎不支持在一条指令中移动多个位(它发射的循环分别移动5次和12次)。我不知道你的编译器会做什么。|931620|如果您还需要处理bit_input+<+ADC_MIN案件，我将分别处理此部分，即：|931621|#include+<stdint.h>
#include+<stdbool.h>
#define+ADC_MIN+2048

int16_t+roundNo(uint16_t+bit_input)+
{+
++++//+if+subtraction+would+result+in+a+negative+value,
++++//+handle+it+properly
++++bool+negative+=+(bit_input+<+ADC_MIN);
++++bit_input+=+negative+?+(ADC_MIN+-+bit_input)+:+(bit_input+-+ADC_MIN);

++++//+we+are+always+positive+from+this+point+on
++++bit_input+-=+(ADC_MIN+-+62);

++++uint32_t+x+=+bit_input;
++++x+<<=+5;
++++x+%2B=+bit_input;
++++x+>>=+12;

++++return+negative+?+-(int16_t)x+:+(int16_t)x;
}|931622|entityMap|0|LINK|mutability|MUTABLE|url|https://godbolt.org/z/ztuamX^0|0|8|17|3|2F|3|2Y|3|0|14|3|1B|7|2N|2|2Y|4|3B|2|3E|4|3P|2|0|7|4|D|3|I|8|V|6|0|0|0|0|0|B|1B|3|1F|3|2X|3|0|0|E|1|0|0|8|J|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@$9|1D|A|1E|B|C]|$9|1F|A|1G|B|D]|$9|1H|A|1I|B|D]|$9|1J|A|1K|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|1L|8|@$9|1M|A|1N|B|D]|$9|1O|A|1P|B|D]|$9|1Q|A|1R|B|D]|$9|1S|A|1T|B|D]|$9|1U|A|1V|B|D]|$9|1W|A|1X|B|D]|$9|1Y|A|1Z|B|D]]|E|@]|F|$]]|$1|I|3|J|5|6|7|20|8|@$9|21|A|22|B|D]|$9|23|A|24|B|D]|$9|25|A|26|B|D]|$9|27|A|28|B|D]]|E|@]|F|$]]|$1|K|3|L|5|M|7|29|8|@]|E|@]|F|$]]|$1|N|3|O|5|M|7|2A|8|@]|E|@]|F|$]]|$1|P|3|Q|5|M|7|2B|8|@]|E|@]|F|$]]|$1|R|3|S|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|D]|$9|2H|A|2I|B|D]|$9|2J|A|2K|B|D]]|E|@]|F|$]]|$1|T|3|U|5|V|7|2L|8|@]|E|@]|F|$W|X]]|$1|Y|3|Z|5|6|7|2M|8|@]|E|@$9|2N|A|2O|1|2P]]|F|$]]|$1|10|3|11|5|6|7|2Q|8|@$9|2R|A|2S|B|D]]|E|@]|F|$]]|$1|12|3|13|5|V|7|2T|8|@]|E|@]|F|$W|X]]|$1|14|3|-4|5|6|7|2U|8|@]|E|@]|F|$]]]|15|$16|$5|17|18|19|F|$1A|1B]]]]

(Update) After writing this, I noticed that @Clifford mentioned that your microcontroller supports this <code>DIV</code> instruction natively, in which case doing this is redundant. Anyway, I will leave it as a concept which can be applied in cases where <code>DIV</code> is implemented as an extern call, or for cases where <code>DIV</code> takes too many cycles and the goal is to make the calculation faster.

Anyway, shifting and adding is likely to be faster than division, if you ever need to squeeze some extra cycles. So if you start from the fact that <code>124</code> is almost equal to <code>4096/33</code> (the error factor is 0.00098, i.e. 0.098%, so less than 1 in 1000), you can implement the division with a single multiplication with <code>33</code> and a shift by 12 bits (division by <code>4096</code>). Furthermore, <code>33</code> is <code>32+1</code>, meaning multiplying by <code>33</code> is equal to shifting left by 5 and adding the input again.

Example: you want to divide <code>5000</code> by <code>124</code>, and <code>5000/124</code> is approx. <code>40.323</code>. What we will be doing is:

<ol>
<li>5,000 &lt;&lt; 5 = 160,000</li>
<li>160,000 + 5,000 = 165,000</li>
<li>165,000 >> 12 = 40</li>
</ol>

Note that this only works for positive numbers. Also note that, if you're really doing lots of multiplications all over the code, then having a single extern <code>mul</code> or <code>div</code> function might result in smaller overall code in the long run, especially if the compiler is not particularly good at optimizing. And if the compiler can just emit a <code>DIV</code> instruction here, then the only thing you can get is a tiny bit of speed improvement, so don't bother with this.

<pre><code>#include &lt;stdint.h&gt;
#define ADC_MIN 2048

uint16_t roundNo(uint16_t bit_input) 
{ 
 // input too low, return zero
 if (bit_input &lt; ADC_MIN)
 return 0;

 bit_input -= (ADC_MIN - 62);
 uint32_t x = bit_input;

 // this gets us x = x * 33 
 x &lt;&lt;= 5;
 x += bit_input;

 // this gets us x = x / 4096
 x &gt;&gt;= 12;

 return (uint16_t)x;
}
</code></pre>

GCC AVR with size optimizations produces <a href="https://godbolt.org/z/ztuamX" rel="nofollow noreferrer">this</a>, i.e. all calls to extern mul or div functions are gone, but it seems like AVR doesn't support shifting multiple bits in a single instruction (it emits loops which shift 5 times and 12 times respectively). I don't have a clue what your compiler will do.

If you also need to handle the <code>bit_input &lt; ADC_MIN</code> case, I would handle this part separately, i.e.:

<pre><code>#include &lt;stdint.h&gt;
#include &lt;stdbool.h&gt;
#define ADC_MIN 2048

int16_t roundNo(uint16_t bit_input) 
{ 
 // if subtraction would result in a negative value,
 // handle it properly
 bool negative = (bit_input &lt; ADC_MIN);
 bit_input = negative ? (ADC_MIN - bit_input) : (bit_input - ADC_MIN);

 // we are always positive from this point on
 bit_input -= (ADC_MIN - 62);

 uint32_t x = bit_input;
 x &lt;&lt;= 5;
 x += bit_input;
 x &gt;&gt;= 12;

 return negative ? -(int16_t)x : (int16_t)x;
}
</code></pre>

I am currently working on a project that includes bare-metal programming on an stm-8 micro-controller using the SDCC compiler in linux. The memory in the chip is quite low so I'm trying to keep things really lean. I have gotten by with using 8-bit and 16-bit variables and things have gone well. But recently I ran into a problem were I really needed a float variable. So i wrote a function that takes in a 16-bit value converts to a float does the math I need and returns an 8-bit number. This cause my final compiled code on the MCU to go from 1198 Bytes to 3462 Bytes. Now I understand that using floating points is memory intensive and that many functions may need to be called to handle the use of the floating point number but it seems crazy to increase the size of the program by that much. I would like some help understanding why this is and what happened exactly.

Specs: MCU stm8151f2
Compiler: SDCC with --opt_code_size option

<pre><code>int roundNo(uint16_t bit_input) 
{ 
 float num = (((float)bit_input) - ADC_MIN)/124.0;
 return num &lt; 0 ? num - 0.5 : num + 0.5; 
}
</code></pre>

Floating point numbers and the effect on 8-bit microcontrollers memory

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我目前正在从事一个项目，其中包括使用linux中的SDCC编译器在stm-8微控制器上进行裸金属编程。芯片中的内存很低，所以我试图让事情变得更精简。我用了8位和16位变量，一切都进行得很顺利。但最近我遇到了一个问题，我真的需要一个浮动变量。所以我写了一个函数，它接收一个16位的值，转换成一个浮点数，做我需要的数学运算，...

问浮点数及其对8位微控制器内存的影响
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问浮点数及其对8位微控制器内存的影响EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问浮点数及其对8位微控制器内存的影响
EN