McuOnEclipse Components: 8-May-2016 Release

Time is passing fast, and many components have been updated to make the compatible with the NXP Kinetis SDK V2.0. As a highlight, besides of FreeRTOS the following components are now usable with the NXP Kinetis SDK:

Components compatible with Kinetis SDK

Components compatible with Kinetis SDK

Beside of multiple bug fixes (see the release notes on SourceForge and the commits on GitHub), the following section describes some of the details.

Quadrature Counter

The Quadrature component has now the ability to swap the quadrature pins at runtime (turned off by default). This is useful if using the same software for different robots without changing the driver code:

Quadrature Pin Swapping

Quadrature Pin Swapping

Kinetis Tools

The Kinetis Tools component supports Kinetis UID (Unique ID’s) of Kinetis Devices up to 128bits:

KinetisTools

KinetisTools

Kinetis UID

Kinetis UID

Segger SystemView and Segger RTT

The Segger SystemView has been upgraded to V2.34 and is not compatible with the Kinetis SDK. I will show this in a hands-on session at NXP FTF (hands-on session FTF-DES-N1956 and FTF-DES-N2084) on a FRDM-K22F board:

Segger SystemView

Segger SystemView

Percepio FreeRTOS+Trace

The Percepio FreeRTOS+Trace works now with the Kinetis SDK as well and I will use it as part of my hands-on trainings at NXP FTF 2016 in Austin. To make it work with the SDK, the component is now placed outside of the FreeRTOS component:

Percepio FreeRTOS Trace

Percepio FreeRTOS Trace

With this I can now trace Kinetis SDK applications with FreeRTOS using the Percepio trace with the simple set of a macro in FreeRTOSConfig.h. Such a SDK V2.0 application is available on GitHub.

Collecting Trace

Collecting Trace

Percepio Tracealizer

Percepio Tracealizer

For everyone going to NXP FTF Austin this year: This will be used in two hands on sessions: FTF-DES-N1956 and FTF-DES-N2084.

Kinetis SDK V2.0 Support

Many components support now the Kinetis SDK. I plan to write an article about this soon. Below is how this works: Bot the LED1 and GBITIO1 are using the Kinetis SDK V2.0 API:

Processor Expert Component for Kinetis SDK v2.0

Processor Expert Component for Kinetis SDK v2.0

In the KSDK1 component  specify the version of the SDK to be used (I working mostly with the V2.0):

Kinetis SDK Component

Kinetis SDK Component

In the pin components I can specify the port and pin number:

SDK v2 Pin Component Settings

SDK v2 Pin Component Settings

With this, I can use the component pretty much the same as in a ‘native’ Processor Expert component project: I generate the code in a ‘normal’ Processor Expert project and then I can use the generated sources in a ‘native’ Kinetis SDK V2.0 project :-).

FreeRTOS

The FreeRTOS component has been extended to work nicely with the Kinetis SDK. I had to tweak it for using it with other Processor Expert component critical section handling. As a plus, I have added now the flexibility to overwrite the memory allocation hooks and critical section handling:

Custom RTOS Adapter Settings for FreeRTOS

Custom RTOS Adapter Settings for FreeRTOS

Summary

The new release is available on SourceForge here: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/.

Beside of the bug fixes and enhancements, I think the new Kinetis SDK compatibility will be very useful.

Happy Releasing 🙂

Advertisements

12 thoughts on “McuOnEclipse Components: 8-May-2016 Release

  1. Hi Erich

    Great like always!
    I use utility module from your components (not exactly version from this post)

    ** Processor : MKE02Z64VLH4
    ** Component : Utility
    ** Version : Component 01.117, Driver 01.00, CPU db: 3.00.000

    End I think found a bug:

    this code will not work
    uint8_t buf[5];
    uint8_t buf[0] = ‘1’;
    UTIL_PE_strcatNum16Hex(buf + num, 5U, 0x1234);

    this will:
    uint8_t buf[5];
    uint8_t buf[0] = ‘\0’;
    UTIL_PE_strcatNum16Hex(buf + num, 5U, 0x1234);

    I have debug and I think error is in: UTIL_PE_strcat().

    Best Regards
    /Greg

    Like

    • Hi Greg,
      the first pointer to strcatNum16Hex() and all the other functions point to the start of the buffer, and the second one to the total size of the buffer.
      I’m not sure about your second code snippet (copy-paste error).
      But you need to call it like
      UTIL_PE_strcatNum16Hex(buf + num, sizeof(buf)-num, 0x1234);
      means you need to adjust the size of the buffer if you are passing a pointer inside the buffer.
      I hope this makes sense?
      Erich

      Like

      • num is copy/past error, just assume num is 0. always point to first element of buffer.
        problem is in UTIL_PE_strcat() caleld at the and of strcatNum16Hex:
        why, this method looking end of string? (dst != ‘\0’) in first while? that’s why second snippet works…

        void UTIL_PE_strcat(uint8_t *dst, size_t dstSize, const unsigned char *src)
        {
        dstSize–; /* for zero uint8_t */
        /* point to the end of the source */
        while (dstSize > 0 && *dst != ‘\0’) {
        dst++;
        dstSize–;
        }
        /* copy the src in the destination */
        while (dstSize > 0 && *src != ‘\0’) {
        *dst++ = *src++;
        dstSize–;
        }
        /* terminate the string */
        *dst = ‘\0’;
        }

        Like

    • Hi Greg,
      All the utility ‘cat’ functions expect a valid buffer, zero terminated.
      With that buf[0] = ‘1’;
      you do not have valid buffer any more, so you need to add
      buf[1] = ‘\0”;
      too.

      I hope that makes sense,
      Erich

      Like

  2. Erich:

    much more sense now.
    I did not notice such assumptions. documentation is:
    /*!
    \brief Adds a 16bit number as hex value to a string.
    \param[in,out] dst Start of buffer, where to append the number string
    \param[in] dstSize The size of the buffer, including the zero uint8_t
    \param[in] num The 16bit number to add
    */

    buffers are not the same concept as strings… do not have to be ‘zero terminated’. misleading.
    Now understand. thanks!

    Like

  3. Hi Erich,

    First I want to thank you for your work, I am a big fan of your processor expert components.
    I am using it since yeas now. For my current project I am using a K22 MCU with KDS, PE and your FRTOS and USB CDC components. Everything worked fine till 7.Feb.16 release. Today I updated to 8.May release and I got problems: Application running as normal, but as soon as the first data is sent via USB the Application hangs in vPortEnterCritical.

    Also tried the 3.Apr release and same behavior. Going back to 7.Feb fixed the problem again. So my question, did you tried the combination FRTOS + USB CDC with the new releases? Just want to know if is is a bug in component, incompatibility or just a bug on my side.

    please keep on the good and helpful work,
    best wishes,
    Hans

    Like

  4. Erich:

    Using the 2016-06-25 beans, FreeRTOS and TMOUT.

    Events.c has the following:
    void FRTOS1_vApplicationTickHook(void)
    {
    /* Called for every RTOS tick. */
    /* Write your code here … */
    TMOUT1_AddTick();
    }

    So, when FreeRTOS ticks, it will increment the timeout and everything is good, right? Nope.

    TMOU1_Addtick calls CS1_EnterCritical, which navigates through the macros to FreeRTOS vPortEnterCritical, where it subsequently hangs in the configASSERT that checks if it’s being called from an ISR. In previous version(s) of the beans, this assert did not exist in vPortEnterCritical.

    I can obviously fix the issue by either writing my own critical section handler, or setting CS1 to not use FreeRTOS. Neither of those is particularly appealing.

    I’m happy to make a patch, but I wanted to get your thoughts on the best way to handle this. The CS bean is obviously is used from interrupts and needs to be safe working that way.

    Sean

    Like

    • Hi Sean,
      Indeed, this is a problem :-(. You could disable the ‘use FreeRTOS’ setting in the CS1/CriticalSection component (this is what I have typically).
      The correct way would be to have this:

      #define CS1_EnterCritical() \
      taskENTER_CRITICAL_FROM_ISR() /* FreeRTOS critical section inside interrupt */
      #define CS1_ExitCritical() \
      taskEXIT_CRITICAL_FROM_ISR(0) /* FreeRTOS critical section inside interrupt */

      I have commited a fix on GitHub, so this will be available in the next version:
      https://github.com/ErichStyger/McuOnEclipse_PEx/commit/5d0420782a21eee3bee8b7484fc38d30b8e3e5bb

      The fix is rather easy, so you could apply it in your component sources as well. Let me know if you need assistance on this.

      I’m sorry for the problem, I hope this helps you,
      Erich

      PS: you could submit bug reports as well in GitHub (https://github.com/ErichStyger/McuOnEclipse_PEx/issues)

      Like

      • Ahh, yes, that’s the right fix. I kept looking for a vPortEnterCritical_FromISR and was determined there wasn’t one.

        taskENTER_CRITICAL_FROM_ISR() does the trick, thanks!

        Sean

        Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s