OSA_TimeDelay() Equivalent in MCUXpresso for MKL36

[claudechazotte]

Looking for equivalent to the KSDK function OSA_TimeDelay() in MCUXpresso. The use case is a bare metal embedded project with no RTOS.  The OSA_TimeDelay() function is part of the fsl-os-abstraction component in KDS/KSDK, and I do not see anything like that component in SDK 2.x for the MKL36Z256 MCU, but perhaps I've missed it. Prefer not to allocate a timer and create code to emulate a blocking time delay function if there is already something available in the SDK. Will appreciate any help!

[diego_charles]

Hello Claude,

I hope you are doing well!

If you want to avoid using a timer,  you may want to use an empty loop  with a nop assembly instruction, and be aware of the system clock frequency to approximate a delay.

In the MCUxpresso SDKs the OSA time delay it is implemented  in the fsl_os_abstraction_bm.c, (if I am not wrong the KL36 does not have this file) for baremetal environtments.

I have seen  that  in several MCUxpresso SDKs  this  function ,at the end of the day, requires a timer (Systick). I am aware that you do not wish to implement a timer, but bellow is the function  code for any reference.

void OSA_TimeDelay(uint32_t millisec)
{
#if (FSL_OSA_BM_TIMER_CONFIG != FSL_OSA_BM_TIMER_NONE)
    uint32_t currTime, timeStart;

    timeStart = OSA_TimeGetMsec();

    do
    {
        currTime = OSA_TimeGetMsec(); /* Get current time stamp */
    } while (millisec >= OSA_TimeDiff(timeStart, currTime));

If I can help further please let me know.

My apologies for the delay!

BR,

Diego.

[claudechazotte]

Hi Diego,

Thanks for your reply.  I'm porting some existing firmware from KDS to MCUXpresso and find that many of the KSDK1.2 driver and HAL functions, macros, structures, and enumerated constants are not directly compatible.  This is disappointing.  Even though there are equivalent functions for the most part in MCUXpresso, many changes are needed before one can get a clean build for code written with KDS/KDSK1.2 for the MKL36Z.  I considered the NOP route you mentioned and decided that I would first try to port the KDS/KSDK1.2 fsl_os_abstraction code to MCUXpresso, in order to avoid (relatively simple) code updates in many dozens of instances.  We also have a number of programs that target MKL17 and MKL27 which are still being maintained in KDS.  Can you comment on whether the KSDK1.2 driver and HAL functions for MKL17Z and 27 have more direct compatibility in MCUXpresso than the MKL36Z does?  Simple examples include the ADC, GPIO, OSA, and PMC functions?  I mentioned GPIO because it appears that the KDS/KSD1.2 implementation is far less error prone than MCUXpresso's because one does not have to specify the PORTn along with the pin name; in MCUXpresso, one must specify both (at least for MKL36Z).  Is this the case for MKL17Z as well?

[diego_charles]

Hi @claudechazotte 

Thank you for your reply as well!

The KL17´s , KL27's and KL36's MCUXpresso SDKs APIs are standardized.  Therefore, I cannot say that there is more direct compatibility between KL17's and KL27's KSDK and MCUXpresso SDK. 

For example, one could take a quick look at the online MCUXpresso API user guide to find out that we will also need to specify the PORTn along the pin for the KL17Z and KL27 SDKs

KL17 https://mcuxpresso.nxp.com/api_doc/dev/1782 (up to SDK version 2.8)

KL27 https://mcuxpresso.nxp.com/api_doc/dev/1784 (up to SDK version 2.8)

KL36 https://mcuxpresso.nxp.com/api_doc/dev/766 ( maintained up to SDK version 2.4)

Yours,

Diego

[claudechazotte]

I appreciate the links and will check out the API docs for the KL17 and KL27.

It's curious that the KL36 has not progressed beyond SDK version 2.4 while other MCUs are at version 2.8.  Is this a signal that the NXP has a different preferred MCU and is now de-emphasizing the Freescale MCU in this category, ultimately leading to its withdrawal?  If true, can you please advise the preference for new designs if not the KL36?

[diego_charles]

Hi @claudechazotte 

Thank you for your reply,

From my experience, the SDK updates are made progressively, and they are made to add new functionalities or fix any issue. In the case of the KL36z SDK probably our SDK team has not gotten the need of an update or may remain pending. So far, I do not any news regarding an update for the KL36z SDK.

My comment regarding the SDK version is to point out that the APIs may change a bit for each SDK revision for a certain peripheral driver or middleware. To get to know API changes (for an specific SDK) you can check the SDK release notes/change log in the SDK documentation, that you can obtain from:

• Directly from the SDK, in example : SDK_2.4.1_MKL36Z256xxx4.zip\docs
• Or downloading docs  from MCUXpresso SDK builder.
• Or checking the online documentation, I have obtained the links that posted before from the MCUxpresso SDK builder.

I hope this helps.

Diego.

[claudechazotte]

Thank you Diego.  I'll look at the release notes.  The OSA_TimeDElay() function wasn't in the SDK for the KL36 so I ported it from KDS3/KSDK1.2.  Really appreciate you sticking with my replies even as they strayed from the original post