Floating Point I/O in SDK MQX

[randyhermes]

I'm trying to enable floating point I/O for printf and scanf in MQX that comes with SDK 1.3.

First I set MQX_INCLUDE_FLOATING_POINT_IO 1 in mqx_cnfg.h.  Didn't seem to have any affect.

Dig some digging around and found that STD_FP_IO is used to control inclusion of FP code in print_prv.c and scan_prv.c.

This is hard coded as 0 in std_prv.c used by print_prv.c.

I copied std_prv.c, changed STD_FP_IO to 1, and added it as a preprocessor definition to all of the project settings for my libraries and application.

First time I tried to run it crashed.  Looked like a stack size issue so I doubled the stack for all tasks but still had problems.

Looks like their may be an issue with the FP IO code.

Am I missing something, some other define I need to set?

Succinct question - how can I enable FP IO?

Thanks,

Randy

[DavidS · Accepted solution]

Hi Randy,

I did one thing to get floating point working on frdm-k64f using KDS_3.0 and KSDK_1.3.0:

Find C:\Freescale\KSDK_1.3.0\test_frdm-k64f_ksdk_mqx_pe_fp\SDK\rtos\mqx\mqx_stdlib\source\include\std_prv.h

@ line 33

#define STD_FP_IO 1

//DES was 0

Note each task you add using PE OS_Task Component also has a check box for "Floating point task" to enable context saving of the floating point registers if you want.

My project is attached.

Regards,

David

[randyhermes]

Thanks David,

I basically did the same thing, but then I had stack size issues.  I have a large number of tasks running so I wasn't able to increase the stack size in all of the tasks using printf and scanf.  Enabling FP IO adds at least 400 bytes to the stack requirements.

Since I needed both printf and scanf, I made a copy of std_prv.h, deleted the STD_FP_IO define, made sure it was at the top of the include list and put a preprocessor define for STD_FP_IO 1 in my compiler settings.

This appears to be a bug in the SDK/MQX - they shouldn't be harcoding the define value in one of the distribution header files.  Should be controlled in one of the config files.

Thanks again for the advice, at least it confirms I was on the correct path.

Randy