McuOnEclipse Components: 09-July-2017 Release

Posted on July 9, 2017 by Erich Styger

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

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

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

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. 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 multi-threaded 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

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

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

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

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

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

SDK_BitIO

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

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()

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 Properties

SDK_Timer

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

SDK_Timer

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 🙂

29 thoughts on “McuOnEclipse Components: 09-July-2017 Release”

Antonio on July 10, 2017 at 09:31 said:

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: BeansFSL_USB_StackFSL_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?

LikeLike

Reply ↓
- Erich Styger on July 10, 2017 at 09:36 said:
  
  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?
  
  LikeLike
  
  Reply ↓
  - Antonio on July 10, 2017 at 09:41 said:
    
    Ok Erich,
    after a close-open (IDE) cycle, I have solved the problem.
    TNX Erich!
    
    LikeLike
    
    Reply ↓
Juan Carlos on July 12, 2017 at 08:00 said:

Hi Erich.

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

LikeLike

Reply ↓
- Erich Styger on July 12, 2017 at 08:03 said:
  
  No, NXP does not support Processor Expert in the MCUXpresso IDE. But I have found a way to get it installed and working, see https://mcuoneclipse.com/2017/04/09/mcuxpresso-ide-installing-processor-expert-into-eclipse-neon/
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
Paul Abbott on July 26, 2017 at 16:06 said:

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?

LikeLike

Reply ↓
- Erich Styger on July 26, 2017 at 16:57 said:
  
  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
  
  LikeLike
  
  Reply ↓
Scott Miller on July 31, 2017 at 18:20 said:

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

LikeLiked by 1 person

Reply ↓
- Erich Styger on July 31, 2017 at 18:40 said:
  
  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.
  
  LikeLike
  
  Reply ↓
  - Scott Miller on August 3, 2017 at 03:40 said:
    
    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!
    
    LikeLike
    
    Reply ↓
    - Erich Styger on August 3, 2017 at 08:26 said:
      
      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.
      
      LikeLike
Scott Miller on August 3, 2017 at 03:46 said:

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

LikeLike

Reply ↓
- Erich Styger on August 3, 2017 at 08:19 said:
  
  Hi Scott,
  sharing the SPI bus properly is not that hard, but depends a bit on how you use it. I have an example of it here (https://github.com/ErichStyger/mcuoneclipse/blob/master/Examples/KDS/INTRO_K22_Robot/INTRO_RoboLib/SPI.c): basically every access to the SPI bus is guarded by a mutex. For this the easiest way is to use the hooks present in the component, see the OnActivate() hooks in https://github.com/ErichStyger/mcuoneclipse/blob/master/Examples/KDS/INTRO_K22_Robot/INTRO_K22_Robo/Sources/Events.c.
  That project is a rather complex one (sharing the SPI bus for SD card and for a MP3 encoder/decoder chip), but this gives you hopefully the idea.
  Erich
  
  LikeLike
  
  Reply ↓
Pingback: McuOnEclipse Components: 25-Sept-2017 Release | MCU on Eclipse
Scott Miller on October 13, 2017 at 01:07 said:

Hi Erich,

Seems all roads lead to you when it comes to doing anything interesting with Kinetis. I just followed a 5 year old comment thread from FreeRTOS.org right back here.

I’m using your FreeRTOS PEx component, but not the USB component. I’m running the Freescale bare metal USB stack with some tweaks (things like being able to choose from multiple descriptors at startup for different operating modes and for notifying the host in MSD mode that storage contents have changed) so I don’t want to enable your component for that.

Does your component have an OS adapter for FreeRTOS? The stack has its bare metal stubs and an MQX adapter. Before I rewrite that I thought I’d check yours, but I’m not sure how PEx stores things and where to find that.

Thanks!

Scott

LikeLike

Reply ↓
- Erich Styger on October 13, 2017 at 07:51 said:
  
  Hi Scott,
  it seems that all roads lead to Rome, right? 🙂
  My version of the device USB stack does not need an OS adapter, it can work without the RTOS. I’m using a variant of the Freescale v4.1.1 stack. For the host version I only needed to replace the memory allocation calls to use the FreeRTOS heap ones instead of the normal malloc() ones which were used in the stack, because the malloc() implementation is not reentrant.
  I have not used MQX for a very long time, so I cannot comment on that part.
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
emreoz on March 5, 2018 at 15:59 said:

Hi Eric,
i try ds18b20 on kl26z64 but when i generate PE, i get error
“Generator: FAILURE: at line 10: Unknown macro: “Parerror” (file: Drivers\Common\OneWireOnError.inc)”
do you have any opinion 🙂

Thank u

LikeLike

Reply ↓
- Erich Styger on March 5, 2018 at 16:05 said:
  
  Thanks for reporting! What IDE are you using? And: the latest release is this one: https://mcuoneclipse.com/2017/12/26/mcuoneclipse-components-26-dec-2017-release/
  I have to check it with that release, but it could be that it is already fixed. Have you tried the 26-Dec-2017 one already?
  
  LikeLike
  
  Reply ↓
- Erich Styger on March 5, 2018 at 16:10 said:
  
  Hello,
  I quickly tried it with the latest version (Version : Component 01.017) with the default settings, and it works without error for me. Can you try the latest version?
  
  LikeLike
  
  Reply ↓
  - emreoz on March 5, 2018 at 16:59 said:
    
    I tried. But my all components are old therefore i have lot of wrong sembol.
    Description Resource Path Location Type
    Generator: FAILURE: at line 512: Inherited symbol not found: “ConfigFilesFolderName” (file: Drivers\sw\LED.drv) 26_62019C LED1 Processor Expert Problem
    
    :(((
    
    LikeLike
    
    Reply ↓
  - emreoz on March 5, 2018 at 17:58 said:
    
    My last problem :((
    Generator: FAILURE: at line 274: Inherited item not found: “input” (file: Drivers\sw\OneWire.drv) 26_62019C OW1 Processor Expert Problem
    
    I apologize for bothering you with questions
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 5, 2018 at 18:52 said:
      
      Hard to tell what the problem could be. It looks like you did not install the files/drivers properly. Can you import them again from the .PEupd files? Be sure to import both *.PEUpd files, part 1 and part 2.
      
      LikeLike
  - emreoz on March 6, 2018 at 13:12 said:
    
    I tried diffrent comptr. and i installed two component files. But OW. component coudnt find ring buffer.
    
    Generator: FAILURE: at line 274: Inherited item not found: “input” (file: Drivers\sw\OneWire.drv) 26_62019_L
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 6, 2018 at 15:58 said:
      
      That’s really strange :-(. Maybe you could send me your project to my email address listed on https://mcuoneclipse.com/about/ so I can have a look?
      Sorry aout the problems.
      
      LikeLike
  - emreoz on March 6, 2018 at 16:35 said:
    
    I sent mail. Many thanks for your kind help
    
    LikeLike
    
    Reply ↓
emreoz on March 5, 2018 at 17:00 said:

Thank u so so much very quick answer 🙂

LikeLike

Reply ↓
g2-5ed75f9547094d701d868e9399972b44 on March 20, 2018 at 10:54 said:

Has anyone already made an effort to use the new FlexIO device to implement the 1-Wire protocol?

LikeLike

Reply ↓
- Erich Styger on March 20, 2018 at 12:41 said:
  
  I searched for that at the time of that article, but did not find anything. I doubt it has changed, but maybe someone else knows?
  
  LikeLike
  
  Reply ↓
  - g2-5ed75f9547094d701d868e9399972b44 on March 20, 2018 at 13:14 said:
    
    I would imagine that any patent issues are irrelevant, because all of the original 1-Wire patents must have expired by now. It might be a trademark issue though, maybe I have been googling for the wrong keywords (singlewire?).
    
    LikeLike
    
    Reply ↓