Problem with string convert

Question

Hi, guys

I'm using the instant constructor "string()" to convert a float to string. It is ok when i flash from embedded wizard doing "make install", but i'm working with the system workbench and the compiler is GCC, so when i load the code on my board everything is working, but the var float is not.

this is what i do on all the Onset method:

// The value doesn't change - nothing to do.
if ( pure precio_unidad == value )
  return;

// Remember the property's new value.
pure precio_unidad = value;

// TO DO:
// .. and show the new text in the both text views
unitario_ntext.String =(string(value,0,2)+"€");
// Now you can handle the alternation of the property.

 

Comments

This is what i get on embedded wizzard "start prototyper"..

 

And this is wwhat i get on the board..

 

Only show the symbol "€" but var float does not.

 

Answer 1

Hi,

two ideas, which could cause the problem:

1. Compiler Optimization - can you verify that the compiler optimization is the same as it is in the makefile (-O2) or disable the optimization by setting -O0. Does this change the result?

2. Stack Location - can you ensure that the start address of the stack is 16 byte aligned?

If both does not solve the problem, what is the result that you get (wrong content or system hang-up)?

By the way: If you want to display euros and cents - you can also operate with an integer variable that contains only the cents and build the string by the following statement:

var int32 abs = value;
if ( value < 0 )
  abs = -value;

TextView.String = string( value / 100, 1 ) + "." + string( abs % 100, 2 ) + "€";

Nevertheless, it is important to understand the root cause for the problem you descirbed...

Best regards,

Manfred.

Comments

1- I couldn't find the level of optimization in the makefile, but i try on the system workbench with (-O0) and (-02), it didn't solve the problem.

 

2- Can you give me a hint about this --> can you ensure that the start address of the stack is 16 byte aligned?

---

Within the linker file (*.ld) provided within our Build Environment you will find an entry like this:

/* Highest address of the user mode stack, _estack is end of stack */
_estack = 0x2004FFF0;    /* Important: Stack has to be 16-byte aligned */

If you are using another toolchain - there must be either a setting within the project or a similar linker file to define the stack start address.

---

Ok in my linker file i have this.

/* Highest address of the user mode stack */
_estack = 0x20080000;    /* end of RAM */

 

do i have to change it ??

---

This seems to be ok...

Other ideas:

Can you compare the other compiler settings - that are used within your workbench to call the GCC with the different settings from our makefiles?

Is it the same GCC compiler (same C libraries)?

---

Hi,

I configured my project on system workbench based on the makefile generated by the embedded wizard. I'm going to attach the makefile of both.

Makefile Embedded wizard:

http://ask.embedded-wizard.de/?qa=blob&qa_blobid=9300256652092082668

 

Makefile system workbench:

http://ask.embedded-wizard.de/?qa=blob&qa_blobid=17206760934172272528

The following captures show the setting of the project.

 

 

 

---

Hi,

unfortunately I cannot read the compiler flags within the screen shots.

After comparing your makefiles, I can see the following differences which may be relevant:

1. Your system workbench makefile does not contain the flag -mthumb-interwork

2. The system workbench makefile uses -mfpu=fpv5-d16 instead of -mfpu=fpv4-sp-d16 which is used in our makefile

Please adapt your project settings accordingly - maybe this helps...

---

I fixed the code implementing an var int32 and using the string converter in order to work with the euros and cents separadetly. I know this is not the best way but it works...

 

Thanks for all support.

---

Yes this is a pragmatic solution - but maybe one day you need again floating point...

Maybe you can spend a few minutes just to verify if it is related to the fpu compiler flag -mfpu=fpv4-sp-d16 (which I can imagine)...

---

ok, i will try let me a minutes..

---

I think i couldn't do that because it is a list box, so only give me 2 options (fpv5-d16 and no unit)

 

---

Had the same problem on a STM32F469 with AC6 SW4STM32. Adding -u _printf_float to the linker flags finally solved this problem.

See also here https://devzone.nordicsemi.com/question/5076/using-floats-with-sprintf-gcc-arm-none-eabi-nrf51822/

---

Hi Manfred,

 

i also got problems with the string.parse_float and the string(aFloat) methods.

 

My makefile contains the -mfpu=fpv4-sp-d16 flag and the -mthumb. The interwork was removed long time ago.

After little research i found that the problem should be in the printf call of a syslibrary.

In Atollic the usage is activated by the flag  -specs=nosys.specs and activating the Newlib Standard library instead of the nano.
But the functions are still not working properly on the target system. Any other hints?

 

best regards

Simon

---

Hi Simon,

which version of our Build Environments are you using? If you are using V8.30 and a STM32F7 target - please update to the latest version, where we fixed some troubles with FPU settings:

* Version 8.30.01
  - GCC libraries are created with single precision FPU settings to be
    compatible with all F7 targets (using -mfpu=fpv5-sp-d16 instead of
    -mfpu=fpv5-d16).
  - GCC libraries compiled with GCC ARM Embedded Toolchain 7-2017-q4-major.

Does this help?

Otherwise please check the start address of the stack - is it 16 Byte aligned?

Best regards,

Manfred

---

update from V8.20 to V8.30 was very helpfull thx!