\n\tAN4044 – Floating point unit demonstration on STM32 microcontrollers.pdf<\/a>
\n. For some, this document may be incomprehensible, so let me shed some light on floats for STM32 and beyond.<\/p>\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2020\/07\/Nucleo-64-baner.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n<\/p>\n\n\n\n
Float representation<\/h1>\n\n\n\n
First, it\u2019s worth saying how floating-point numbers are stored by the MCU. As we all know, a bit has only two states and you can\u2019t insert any fractional number between 10<\/em> and 11<\/em>. So how does it work? There is the IEEE 754 arithmetic standard that defines the encoding and basic operations on floats<\/em>. The most commonly used floating-point numbers are single and double precision \u2013 single<\/em> and double<\/em>. Their encoding looks like this:<\/p>\n\n\n <\/p>\n\n\n\n What does this mean?<\/p>\n\n\n\n s \u2013 the sign bit. It decides whether the number is positive or negative. 0 \u2013 positive, 1 \u2013 negative.<\/p>\n\n\n\n e \u2013 8- or 11-bit exponent. The integer to which we raise the base of the number system \u2013 in our case the number 2 because we encode in binary. You must add the so-called bias<\/em> to the exponent, equal to 127 for single<\/em> and 1023 for double<\/em>.<\/p>\n\n\n\n f \u2013 23- or 52-bit mantissa. The number from which we obtain the fraction. It\u2019s a normalized number, more on that in a moment.<\/p>\n\n\n\n The formula for a floating-point number therefore looks as follows:<\/p>\n\n\n <\/p>\n\n\n\n Looks complicated, right? Let\u2019s try to convert some fraction to the float representation. Let it be the number 243.45.<\/p>\n\n\n\n First, we should handle the integer 243, which is quite simple. The result is 11110011<\/em>. It\u2019s worse with the manual conversion of 0.45. I recommend watching a video that explains how to do it (link<\/a>). 0.45 in binary representation is 011100(1100\u2026)<\/em>.<\/p>\n\n\n\n So 243.45 = 11110011.011100(1100\u2026)<\/em><\/p>\n\n\n\n Now we need to normalize this number. A normalized number is one that lies in the right-open interval [1, B) where B is the base of the number\u2019s encoding. In our case, the encoding is binary, so the point must be after the first one. Count how many places you shifted the point. This is needed for encoding the exponent.<\/p>\n\n\n\n After normalization, our number is 1.110011011100(1100\u2026) x 10^7<\/em>.<\/p>\n\n\n\n Thanks to the fact that the integer part is always 1, there is no need to store it. In the float<\/em> number, only the fractional part is stored and this is the mantissa shortened to 23 or 52 bits.<\/p>\n\n\n\n f = 11001101110011001100110<\/strong><\/p>\n\n\n\n Now the exponent. I shifted the point 7 places to the left, so it is 7. Adding the bias<\/em> for the 32-bit representation gives 134, which in binary is 10000110<\/em>.<\/p>\n\n\n\n e = 10000110<\/strong><\/p>\n\n\n\n The number is positive, so the sign is zero<\/p>\n\n\n\n s = 0<\/strong><\/p>\n\n\n\n Now we can assemble our float.<\/p>\n\n\n\n 243.45 (dec) = 0 10000110 11001101110011001100110 (float)<\/strong><\/p>\n\n\n\n Simple, isn\u2019t it? \ud83d\ude42<\/p>\n\n\n\n The IEEE 754 standard also defines floating-point arithmetic. It contains 6 operations on numbers:<\/p>\n\n\n\n Let\u2019s try something easy, e.g., let\u2019s add 188.1 and 182.69. In your head you can quickly compute that it will be 370.79, but will float give the same result?<\/p>\n\n\n\n 188.1<\/strong><\/p>\n\n\n\n 188 in binary is 10111100<\/strong> while 0.1 is equivalent to 0(0011\u2026)<\/strong>. Do you see the small danger related to the infinite expansion? If not, don\u2019t worry, it will be visible. Combining the two components, I get 10111100.0001100110011(0011)<\/strong> and adapting it to the float standard 1.01111000001100110011001|10011 x 10^7<\/strong>. What\u2019s after the vertical bar is redundant for float32 and is lost forever. We have the first loss of information<\/strong>. The exponent is 7, so after adding the bias we get 134.<\/p>\n\n\n\n 188.1<\/strong>(dec) = 0 10000110 01111000001100110011001<\/strong>(float)<\/p>\n\n\n\n Now 182.69<\/strong><\/p>\n\n\n\n 182 = 10110110.10110000101000111101 = 1.01101101011000010100011|1101 x 10^7<\/strong><\/p>\n\n\n\n Again, we lose information about the fractional expansion. Converting to the IEEE 754 representation:<\/p>\n\n\n\n 182.69<\/strong>(dec) = 0 100000110 01101101011000010100011<\/strong>(float)<\/p>\n\n\n\n The first thing to do when adding floating-point numbers is to equalize their exponents. In my example we have the same exponents, so we don\u2019t need to do this operation. The next step is to add the mantissas, keeping in mind the one before the point, which is not in the float encoding. I will skip the manual binary addition process for readability<\/p>\n\n\n\n 1.01111000001100110011001 x 10^7 + 1.01101101011000010100011 10^7 = 10.11100101100101000111100 x 10^7<\/strong><\/p>\n\n\n\n The result must be normalized: 1.01110010110010100011110|0 x 10^8<\/strong><\/p>\n\n\n\n In float encoding our result looks like this: 0 100000111 01110010110010100011110<\/strong><\/p>\n\n\n\n We should decode this result. It will be easiest for me to extract it from the normalized result, of course truncated to the size of the float standard because that\u2019s what we actually extract the operation result from.<\/p>\n\n\n\n 1.01110010110010100011110 x 10^8 = 101110010.110010100011110<\/strong><\/p>\n\n\n\n I split this into an integer and fractional part:<\/p>\n\n\n\n 101110010 = 370<\/strong> \u2013 success. Now the fraction. You can find the method of converting a binary fraction to decimal form at this link<\/a>.<\/p>\n\n\n\n 0.110010100011110 = 0.78997802734375<\/strong><\/p>\n\n\n\n So? It\u2019s a bit less than 0.79. And here lies one of the dangers associated with float. With a small number of operations and low precision requirements, e.g., one or two decimal places, it doesn\u2019t matter that much, but imagine when an MCU performs hundreds or thousands of such operations and each introduces such a small error.<\/p>\n\n\n\n For this reason remember: never use the == and != operators to compare floating-point numbers.<\/strong> Use some small delta, or epsilon (people call it differently). For example: if( abs((expected \u2013 result)) <= 0.01 )\u2026<\/p>\n\n\n\n Why is that?<\/p>\n\n\n\n The result of addition in the example above is a consequence of the precision of numbers stored in a float variable. Do you think you can store all fractions with them? Well, no. I prepared in Octave a plot with marked floats<\/em> for an 8-bit mantissa and an exponent from -5 to 5.<\/p>\n\n\n <\/p>\n\n\n\n Each circle represents one number. What stands out? What about all the numbers between 0.5 and 1? According to these parameters there are only 4 of them. The rest don\u2019t exist. Of course, with a mantissa and exponent consistent with the IEEE 754 standard there will be more of them, but it still won\u2019t cover all possible numbers.<\/p>\n\n\n\n Also notice that the further from zero, the sparser the points. Do you guess what that means? Operations on large numbers produce even greater errors<\/strong> resulting from these limitations.<\/p>\n\n\n\n Adding floats seems quite simple, but it includes several operations such as extracting the exponents, equalizing them, adding the mantissas, and transforming the result back into IEEE 754 form. It\u2019s similar for subtraction, multiplication, and the rest of the operations. Compared to integer (binary) arithmetic, a considerable processor overhead is required. In other words, performing a single operation on floating-point numbers requires the MCU to perform dozens of operations, which are carried out using ordinary binary operations.<\/p>\n\n\n\n Some microcontrollers are equipped with an additional unit dedicated to floating-point computations. This is the FPU \u2013 Floating Point Unit. This unit is included, among others, in MCUs from the F4 family based on the Cortex-M4 and Cortex-M7 cores, i.e., STM32 series F4, L4, F7, H7. This unit literally does miracles with floats. ST in its microcontrollers offers, with its help, several hardware operations on single-precision floats:<\/p>\n\n\n <\/p>\n\n\n\n As you can see, absolute value, addition, subtraction, or multiplication are performed in just one clock cycle<\/strong>. All those operations I did by hand, the FPU does with a snap of a digital finger. Division or square root takes only 14 cycles. Additionally, we can see in the table that type conversions take only one cycle. Magic? Kind of \ud83d\ude42<\/p>\n\n\n\n They promised so much, so now let\u2019s check the most important operations using simulation in the Keil \u00b5Vision 5<\/em> IDE on an STM32F401RE, which I have on one of my Nucleo boards. The HAL library I\u2019ll use is version 1.21. In the project settings I enabled the simulator and set no optimization. In the code, right after initializing HAL and clocks, I disable SysTick so it does not interfere with the computations. In the main loop I wrote simple code that performs basic operations on numbers. First I\u2019ll test operations on uint32_t, then float with FPU disabled and enabled, and finally I\u2019ll compare them. After each for I set a breakpoint and check the clock cycle counter in the simulation. For better visualization I perform each operation 100 times. Unfortunately there will be some additional cycles due to the for loops, but for each option it will be the same amount, so it won\u2019t significantly affect the proportional result. FPU is enabled\/disabled in the project settings. In Eclipse (or SW4STM32) this will be under Project > Properties > C\/C++ Build > Settings > MCU Settings<\/strong> in the dropdown named Floating point hardware.<\/p>\n\n\n\n Are you curious about the results? They\u2019re interesting.<\/p>\n\n\n\n First up is the size of the resulting code.<\/p>\n\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/float_single_and_double_representation-1024x338.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/float_equation_.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nOperations on floating point<\/h2>\n\n\n\n
\n
Precision<\/h2>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/floats_on_axe-1024x326.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nComputational complexity and FPU<\/h2>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/FPU_cycles.jpg\")
<\/a><\/figure>\n<\/div>\n\n\nSo how much does it take then?<\/h2>\n\n\n\n
uint32_t a = 6754;\nuint32_t b = 1267;\nuint32_t result;\n\n\/\/float a_f = 12.67;\n\/\/float b_f = 6.754;\n\/\/float result_f;\n\nwhile (1)\n{\n\tuint16_t i;\n\t\/\/ Add\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = a+b;\n\t\t\/\/result_f = a_f+b_f;\n\t}\n\n\t\/\/ Substract\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = a-b;\n\t\t\/\/result_f = a_f-b_f;\n\t}\n\n\t\/\/ Multiply\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = a*b;\n\t\t\/\/result_f = a_f*b_f;\n\t}\n\n\t\/\/ Divide\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = a\/b;\n\t\t\/\/result_f = a_f\/b_f;\n\t}\n\n\t\/\/ Modulo\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = a%b;\n\t\t\/\/result_f = fmod(a_f,b_f);\n\t}\n\n\t\/\/ Square root\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = sqrt(a);\n\t\t\/\/result_f = sqrtf(a_f);\n\t}\n\n\t\/\/int to float\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult_f = (float)a;\n\t}\n\n\t\/\/float to int\n\tfor(i=0; i<100; i++)\n\t{\n\t\tresult = (uint32_t)a_f;\n\t}\n\n\tresult = result+1; \/\/ delete warning\n\tresult_f = result_f+1; \/\/ delete warning\n\t\/* USER CODE END WHILE *\/\n\n\t\/* USER CODE BEGIN 3 *\/\n}<\/pre>\n\n\n\n
![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/Code_size.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/Operations_ticks-1024x470.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/Sqrt_ticks-1024x470.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n![\"\"](\"http:\/\/msalamon.pl\/wp-content\/uploads\/2018\/11\/Type_conversion_ticks.jpg\")
<\/a><\/figure>\n<\/div>\n\n\n