Recently, we encountered a problem, that is, the printf display of floating-point calls in uCOSII is abnormal, but the support for floating-point calls on bare metal machines is normal. Here are the details.
When calling printf to debug floating-point numbers in UCOS, it is correct in memory, but print data is 0, and other shaping data are normal.
The running result on bare metal is completely normal, that is to say, the problem lies in UCOS.
According to the information, this is because the user task stack is not aligned with octets. When running bare metal programs, the system’s default stack octets are aligned, but UCOS’s user task stack is not.
Align the user stack octets.
1. Solutions under IAR: (untested)
Through # pragma data_ Alignment specifies the number of bytes to align
#pragma data_alignment=8 OS_STK Task1_LED1_Stk[Task1_LED1_Stk_Size]; #pragma data_alignment=8 OS_STK T
2. Solutions under keil MDK: (available for personal testing)
Add the force octet alignment command before the task stack declaration, as follows:
__align(8) static OS_STK TaskEquipmentStk[TASK_EQUIPMENT_STK_SIZE]; __align(8) static OS_STK TaskUartRcvStk[TASK_UARTRCV_STK_SIZE]; __align(8) static OS_STK TaskFileRcvStk[TASK_FILERCV_STK_SIZE]; __align(8) static OS_STK TaskFtpStk[ TASK_FTP_STK_SIZE ]; __align(8) static OS_STK TaskErrorRateRS485Stk[ TASK_ERROR_RATE_RS485_STK_SIZE ];
Detailed explanation of the reasons
The history of this is that arm itself does not support non aligned data access; Therefore, with a 64bit data operation instruction, the instruction requires 8-byte alignment.
Furthermore, after a certain version of the compiler (rvct3?) AAPCs requires stack 8-byte alignment.
AAPCs with 8-byte alignment first, then cm3. Pay attention to the sequence. Before cm3 r2p0, automatic stack pressing does not require 8 alignment, and r2p0 seems to be forced alignment.
Printf’s 8-alignment is required by the C runtime and has nothing to do with hardware. The C RTL manual is written and can be read. Its root lies in the requirements of AAPCs; AAPCs is rooted in instructions like LDRD.
In other words, in the future, if 128bit data operation is available and arm does not support non alignment, AAPCs may be upgraded to 16 byte alignment.
- ValueError: Floating point image RGB values must be in the 0..1 range.
- Tensorflow C++：You must define TF_LIB_GTL_ALIGNED_CHAR_ARRAY for your compiler
- [Solved] ValueError: the indices for endog and exog are not aligned
- When Wireshark grabs packets, IP check sum error is displayed
- Cache penetration, cache breakdown and cache avalanche solutions
- Feign declarative call service feign.codec.DecodeException: Error while extracting response for type [class **] and…
- The drone settings page is not trusted
- Solution to latex “too many unprocessed floats” error
- How to Solve Error inflating class android.support.design.widget.FloatingActionButton
- Abnormal [System.InvalidOperationException: custom type mapping for ‘xxx’ is not specified or is not a solution
- latex Package inputenc Error: Invalid UTF-8 byte “A1
- Solution of socket write error caused by pressing F5 to refresh page by ehcache user
- Lua: Error during loading: [string “/usr/share/wireshark/init.lua”]:45: dofile has been disabled
- How to Fix Failed to load resource: the server responded with a status of 404()
- R: Data frame index error “unexpected token”
- [Android Error] java.lang.RuntimeException: An error occurred while executing doInBackground()
- The loop of life and death occurs when the El table component of element UI is bidirectional bound
- PIP Fatal error in launcher: Unable to create process using
- [How to Solve] java.lang.IllegalArgumentException: Request header is too large
- The page you are requesting cannot be served because of the extension configuration