[BUG] many FSL API parameters not 'const' where required for customer applications

The Problem
Many times applications must call FSL API functions with constant data. For example, the application I'm working on has 6 different SPI peripherals, and each one requires several different control byte strings to be sent. These are all declared const (and placed in flash memory). Thus the FSL transmit API should take a const uint8_t* argument for the bytes to be sent. Similarly, configuration structures used for FSL API are const.

The FSL API as coded produces compile errors where it does not take const arguments. Ignoring this is a violation of many coding standards, hence your customers often must change the FSL functions. Not good!

Suggested Fixes

Review each parameter for all API functions. Where the FSL library will not modify the input, ensure that the parameter is declared const. Especially, any data which is transmitted, or used for configuration.

** Feedback Requested **
@DavidJurajdaNXP , @mcuxsusan - Can you please confirm this explanation is clear for you?
Note this is a clarification requested by Susan for issue #59

Hello NXP,

this seems a very valid request. Why is there no response from NXP for months?

Thanks.

It's only been 6 months...
@DavidJurajdaNXP, @mcuxsusan - Anybody there?

Hi @DavidJurajdaNXP ,

UART drivers use such way to use const tx data,
https://github.com/nxp-mcuxpresso/mcux-sdk/blob/main/drivers/lpuart/fsl_lpuart.h#L276

do you think the the FreeRTOS drivers #59 can be updated for this purpose? thanks.

The txData in SPI drivers, such as: https://github.com/nxp-mcuxpresso/mcux-sdk/blob/main/drivers/lpspi/fsl_lpspi.h#L345, will be udpated to const type.

One down, 1237 to go...
You guys need to do a systematic cleanup of missing 'const'.
Not just one at a time.

Will update not only the data sending functions, but also the functions which don't modify parameter content, such as SetConfig, the parameter config shall be const.
These changes will be applied to all drivers, it will be done step by step. SPI part go first and will be updated soon.

I add my vote to this request.
This kind of fix is necessary for several reasons, especially if you need to get some kind of conformance/certification of ypour source code.
I need the fix for UART functions.
As an example

mcux-sdk/drivers/uart/fsl_uart_freertos.h

Line 126 in 43a5a8d

    
           int UART_RTOS_Send(uart_rtos_handle_t *handle, uint8_t *buffer, uint32_t length);

This issue is similar to #59 which is in charge to @mcuxsusan and @DavidJurajdaNXP

@DavidJurajdaNXP, could you please help?

I created the PR #154.
Feel free to review it and add other commits, if needed