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
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:
An example project is available on GitHub (https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/FRDM-KL25Z/FRDM-KL25Z_USB_HID_Joystick):
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.
More information about reentrancy with newlib/newlib-nano (courtesy of Dave Nadler):
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:
The component supports user timing settings for all phases of the protocol:
The DS18B20 is a 1-Wire digital temperature sensor. The component has been completely refactored and has added a command line interface:
The component supports single slave and multiple slave modes, with dynamic or fixed 64bit ROM codes:
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.
The SDK_BitIO component features now pull resistor settings for SDK V1.x:
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:
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.
To configure a timer with the Kinetis/MCUXpresso SDK is not easy. A new component simplifies this:
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 🙂
- Release on Sourceforge: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/
- Component installation instructions: McuOnEclipse Releases on SourceForge
- McuOnEclipse Library on GitHub: https://github.com/ErichStyger/McuOnEclipseLibrary
- USB HID Joystick project: https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/KDS/FRDM-KL25Z/FRDM-KL25Z_USB_HID_Joystick
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
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?
after a close-open (IDE) cycle, I have solved the problem.
Processor Expert yet is support from NXP for the new MCUXpresso IDE?
I’m a little bit confused with this…..
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,
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?
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 :-).
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.
LikeLiked by 1 person
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.
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.
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.
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.
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.
Pingback: McuOnEclipse Components: 25-Sept-2017 Release | MCU on Eclipse
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.
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,
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 🙂
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?
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?
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
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
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.
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
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.
I sent mail. Many thanks for your kind help
Thank u so so much very quick answer 🙂
Has anyone already made an effort to use the new FlexIO device to implement the 1-Wire protocol?
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?
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?).