McuOnEclipse Components: 09-July-2017 Release

I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following major changes and updates:

  • Complete refactoring for 1-Wire stack and DS18B20 temperature sensor components
  • Added HID Joystick device class to the FSL_USB_Stack
  • New SDK_Timer component to work with Kinetis SDK
  • New ST756P LCD driver component
  • New TSL2561 digitial temperature sensor driver
  • Added ReadByte() and WriteByte() GenericI2C functions
  • Added 64bit mapping functions to Utility
  • added configUSE_NEWLIB_REENTRANT and newlib reentrancy support to FreeRTOS
  • Pull resistor support for SDK_BitIO
  • Many smaller bug fixes and enhancements
SourceForge

SourceForge

HID Joystick Device Class

The HID Joystick Device Class component (see “DIY USB HID Joystick Device and Game Controller“) has settings implemented to configure the number of controls:

USB Joystick Component

USB Joystick Component

HID Joystick Properties

HID Joystick Properties

An example project is available on GitHub (https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/FRDM-KL25Z/FRDM-KL25Z_USB_HID_Joystick):

USB HID Joystick Project

USB HID Joystick Project

FreeRTOS with newlib Reentrancy Setting

The FreeRTOS component has now a setting to configure the FreeRTOS configUSE_NEWLIB_REENTRANT setting. If enabled, each task will have a reent structure assigned. Naturally, this setting is only useful if using the newlib or newlib-nano library.

💡 You must be familiar with newlib/newlib-nano reentrant usage and implementation. See as well this thread. and read the documentation inside of the newlib library. In general I do *not* recommend to use any standard library calls (like printf() or sprintf() in a multithreaded environment, as most implementations are *not* thread safe. Instead I’m using the string and printing functions of the McuOnEclipse libraries (e.g. Utility or Shell) which are thread safe.

configUSE_NEWLIB_REENTRANT

configUSE_NEWLIB_REENTRANT

More information about reentrancy with newlib/newlib-nano (courtesy of Dave Nadler):

OneWire

1-Wire is a bus system designed by Dallas Semiconductor and can communicate with devices with one wire (plus GND) only. Basically it is a kind of I²C on one wire: one wire is used both for data and clock which makes it very interesting for low-cost connection to memory, sensors and more. The other cool feature is that with the two wires (GND + Data) it is possible to power small devices, so no other power lines are required.

For the 1-Wire protocol there is now a refactored component available. It supports all features of the protocol including searching for devices on the bus. On top of that, it features a command line interface plus extra debug pin support:

OneWire Component

OneWire Component

The component supports user timing settings for all phases of the protocol:

OneWire Properties

OneWire Properties

DS18B20

The DS18B20 is a 1-Wire digital temperature sensor. The component has been completely refactored and has added a command line interface:

DS18B20

DS18B20

The component supports single slave and multiple slave modes, with dynamic or fixed 64bit ROM codes:

DS18B20 Properties

DS18B20 Properties

Utility and map()

To facilitate porting legacy Arduino software, several Arduino functions have been added to the Utility component, including map functions. map64() is a 64bit variant.

Utility

Utility

SDK_BitIO

The SDK_BitIO component features now pull resistor settings for SDK V1.x:

SDK_BitIO Pull Resistor Settings

SDK_BitIO Pull Resistor Settings

GenericI2C

To read or write a single byte from the I²C bus with a reduced set of parameters, the ReadByte() and WriteByte() functions have been added to the GenericI2C driver:

GenericI2C ReadByte() and WriteByte()

GenericI2C ReadByte() and WriteByte()

TSL2561

The TSL2561 is a digital light sensor, found on the Hexiwear or available as breakout board e.g. from Adafruit (https://www.adafruit.com/product/439). The component implements a complete driver over I²C and includes command line support.

TSL2561

TSL2561

TSL2561 Properties

TSL2561 Properties

SDK_Timer

To configure a timer with the Kinetis/MCUXpresso SDK is not easy. A new component simplifies this:

SDK_Timer

SDK_Timer

SDK_Timer Properties

SDK_Timer Properties

Summary

The changes are documented on GitHub. The release is available on SourceForge: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/. See “McuOnEclipse Releases on SourceForge” how to install the update. If you are not using Processor Expert: the components are available in normal source form on https://github.com/ErichStyger/McuOnEclipseLibrary.

I hope you find the new release useful.

Happy Updating 🙂

Links

 

Advertisements

13 thoughts on “McuOnEclipse Components: 09-July-2017 Release

  1. Hello Erich,
    I have updated the components, today, but on my project which use USB Stack (CDC class), I have received an error message (previously absent):

    Description Resource Path Location Type
    ERROR: at line 52: Property not found: “MSDDeviceGroup” (file: Beans\FSL_USB_Stack\FSL_USB_Stack.chg) Cristini-k64 USB Processor Expert Problem

    Description Resource Path Location Type
    Generator: ERROR: There are errors in the project, please review components configuration. It is not possible to generate code. Cristini-k64 Code Generator Processor Expert Problem

    Focused a problem, opening FSL_USB_Stack.chg in beans directory () (Cristini-k64 is my project..) the last line of file which generate error:

    %set MSDDeviceGroup ReadOnly yes

    Suggestions?

    Like

    • Hi Antonio,
      have you restarted the IDE? There is a new group ‘MSD Device’ present in the FSL_USB_Stack which is that MSDDeviceGroup.
      If you have imported the components and you did not restart the IDE, then your component might not have the new settings.
      Can you retry and let me know?

      Like

  2. Hi Erich.

    Processor Expert yet is support from NXP for the new MCUXpresso IDE?
    I’m a little bit confused with this…..

    Like

  3. Thanks for these excellent beans! These really do allow for rapid development.
    My question is regarding the license.
    If I use your component in my firmware of a proprietary embedded device (just a light bulb), must I distribute the license text? And if so, how?

    Like

    • Hi Paul,
      you are welcome :-).
      As for licensing, that depends on what you are using. I have put up the license texts on https://github.com/ErichStyger/McuOnEclipse_PEx.
      Generally speaking, you have to keep the license text in the sources, and you have to provide the license text if you provide sources.
      Other than that, you don’t have to mention anything. Of course you are more than welcome to do so :-).

      Erich

      Like

  4. Hi Erich,

    Any chance you could give us a rundown of how heap allocation works with the FreeRTOS component? Or more specifically, how it fits in with EWL? FreeRTOS’s own allocation schemes make sense to me, but I can’t get EWL to behave like the docs say regarding placement of the heap.

    Should FreeRTOS be using its own heap only for FreeRTOS objects, with everything else going in EWL’s heap? Should EWL be reconfigured to use FreeRTOS’s allocator so FreeRTOS handles everything? And is that done with EWL_OS_ALLOC_SUPPORT?

    I’ve been making good use of the FreeRTOS component and I appreciate all the work you’ve put into this collection. I hope we’ll see a good successor to Processor Expert soon – I was ready to start packaging a lot of my own components for reuse before I found out PEx is deprecated.

    Thanks,

    Scott

    Liked by 1 person

    • Hi Scott,
      I tried to avoid EWL and its custom library functions at any price and whenever possible. I rather have written my own functions instead of using EWL because of bad experience :-(.
      BTW, what microcontroller family are you using?
      I general I recommend not to use the library (EWL or newlib) memory allocation schemes (see as well https://mcuoneclipse.com/2017/07/02/using-freertos-with-newlib-and-newlib-nano/ on such a saga).
      Instead, I writing applications to only use the FreeRTOS memory allocation. This can be probelmatic again if things like printf() etc are used (which should be avoided again).
      Speaking about depreciated: to my knowledge, EWL is depreciated too, so better consider something else?
      If you are using ColdFire with EWL, I could look into it, but it has been a while I have used ColdFire.

      Like

      • I’m mostly working with the K22F, specifically the MK22FN1M0AVLH12. I’ve still got some legacy stuff to support on ColdFire so some of my Kinetis projects stay very close to their ColdFire equivalents and I’m mostly stuck on CodeWarrior 10.7 for the sake of those and some HCS08 projects.

        I agree that printf() is generally to be avoided if you’re just doing some log output or something and I got by without it for many years, but my main project right now (the one I’ve ported to FreeRTOS) is very PC-like, with a shell accessible by CDC or telnet, a BASIC interpreter, full-screen text editor, and so on. printf() saves a lot of time and effort there. I do try to limit my use of dynamic memory allocation to things like the shell that are interactive and used only intermittently. All of the DSP tasks and such use static allocation only.

        Is there another library I ought to be using for Kinetis under CW 10, aside from EWL or newlib?

        And do you know if it actually works to configure EWL (or newlib for that matter) to use FreeRTOS’s malloc()? I’ve found that plenty of stuff in the EWL docs is wrong or out of date.

        Thanks!

        Like

      • Hi Scott,
        if the calls to printf are under your control and not burried in a library, consider using the smaller (and better) xprintf version presented here: https://mcuoneclipse.com/2014/08/17/xformat-a-lightweight-printf-and-sprintf-alternative/
        Under CW you indeed have the choice of EWL and newlib. That’s not a problem for me as I’m using my own routines (e.g. xprintf()) if possible.
        There is a (GNU) way to overwrite functions in the library. I have found it by an article from Dave Nadler (see https://mcuoneclipse.com/2017/07/02/using-freertos-with-newlib-and-newlib-nano/ and http://www.nadler.com/embedded/newlibAndFreeRTOS.html): It uses -Xlinker –wrap=malloc to wrap around the library functions. As pointed out by Dave: you would have to catch all variants of malloc().
        For me what worked best is not to rely on the libraries, but instead having full control from my application what is called, and not using any of the library functions if possible.

        Like

  5. Another question on the beans. I just ran the FRDM-K22F SD card demo. Works great. Sadly the MK22FN1M0AVLH12 only has one accessible SPI port which is already in use for a serial NOR flash, and in one experimental variant of the project also an OLED display. Can I set up the SPI access macros to use my mutex so I can share the port with the SD card as well?

    I really don’t like the idea of having a potentially hot-plugged SD card on the same bus as other critical stuff, but there’s not really a good alternative on this part.

    Thanks,

    Scott

    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