McuOnEclipse Components: 06-May-2017 Release

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

  • SEGGER SystemView updated to V2.42
  • More components to work with MCUXpresso SDK: GenericSWSPI, FXO8500 and SimpleEvents
  • SSD1351 display driver supports 128×128 pixel resolution and Adafruit 1.5″ breakout module
  • Extended FreeRTOS debug helper settings
  • GenericI2C: added ReadWordAddress8() and ReadWordAddress8() functions
  • RingBuffer with new Getn() and Update() functions
  • Utility with map(), constrain(), random() and randomSetSeed()
  • XFormat: new xsnprintf(), contributed by Engin Lee
  • OneWire protocol component with Maxim DS18B20 temperature sensor
  • Many smaller bug fixes and enhancements
SourceForge

SourceForge

SEGGER SystemView

The SEGGER SystemView libraries have been updated to the V2.42 version:

Segger SystemView

Segger SystemView

Utility

To facility porting Arduino library code, the functions map(), constrain(), random() and randomSetSeed() have been added:

New Utility Functions

New Utility Functions

FreeRTOS

The FreeRTOS debug helpers are now grouped together and can be turned on/off individually:

FreeRTOS Debug Helpers

FreeRTOS Debug Helpers

Additionally a bug has been fixed in case only static memory allocation is used, and the Wait component supports now proper RTOS waiting functionality:

Wait with RTOS

Wait with RTOS

XFormat

Thanks to Engin Lee, the XFormat component has now a xsnprintf() function:

xsnprintf

xsnprintf

GenericI2C

New functions ReadWordAddress8() and WriteWordAddress8() which read and write 16bit data from an 8bit address:

GenericI2C

GenericI2C

SSD1351

The SSD1351 display driver supports now the 128×128 resolution:

SSD1351 Display Driver

SSD1351 Display Driver

The Adafruit 128×128 OLED display is supported with that new resolution:

Adafruit OLED Display

Adafruit OLED Display

The following shows the improved display driver on a Hexiwear with up to 50 frames per second. The application implements an electronic animated eye. The light sensor on the Hexiwear is used to  change the size of the iris:

1-Wire Protocol with Maxim Temperature Sensor

The 1-Wire bus allows to use things like sensors with one wire plus a GND wire, as power can be provided through the data line. The protocol is like I²C with a pull-up on the data line:

Maxim One-Wire Protocol

Maxim One-Wire Protocol

The OneWire component (original contribution by Omar Isaí Pinales Ayala) has been refactored:

OneWire Component

OneWire Component

OneWire Component Properties

OneWire Component Properties

The Maxim DS18B20 1-Wire temperature sensor has received a major face lifting and command line support:

Maxim DS18B20

Maxim DS18B20

Maxim DS18B20 Properties

Maxim DS18B20 Properties

RingBuffer

The RingBuffer has a new method Update() to update/change any item in the buffer. The Getn() method is available to get a number of elements:

RingBuffer

RingBuffer

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

23 thoughts on “McuOnEclipse Components: 06-May-2017 Release

  1. Dear Erich,

    Appreciate your great work.
    I tried the new lib ,but I got error when generate code :
    IDE: codewarrior 10.7
    MCU: KEAZ128

    Description Resource Path Location Type
    Generator: FAILURE: at line 19: Property not found: “szTime” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem
    Generator: FAILURE: at line 20: Property not found: “szProgram” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem
    Generator: FAILURE: at line 17: Property not found: “szOutput” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem
    Generator: FAILURE: at line 18: Property not found: “szInput” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem
    Generator: FAILURE: at line 13: Property not found: “readTime” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem
    Generator: FAILURE: at line 14: Property not found: “waitTime” (file: Drivers\Common\OneWireSettings.Inc) ThermalCtrl_ds18b20_test OW1 Processor Expert Problem

    Like

    • Looks like the OneWireSettings.Inc file in the distributed update file still contains old properties 😦
      You can fix this on your side:
      Open the Drivers\Common\OneWireSettings.Inc and remove the offending lines (or make the file empty).
      I’m in the process to replace the BitIO_LDD with a normal BitIO and timer component, so it works with the SDK. Should I post a that new version for you?
      I ask because with that new version you would have to configure the timer and pin again.

      Like

      • Thanks for your quick reply. Sure , it is appreciated to get a new version. It is easy to configure the timer and pin .

        Like

  2. Dear Eric,

    The DS1.c code need revise .
    When DS1_CONFIG_MULTIPLE_DEVICES enabled , got the following error.

    If DS1_CONFIG_MULTIPLE_DEVICES enabled, should change all things like
    Sensor.Rom to Sensor[x].Rom

    request for member ‘Temperature’ in something not a structure or union DS1.c /ThermalCtrl_ds18b20_test/Generated_Code line 343 C/C++ Problem
    request for member ‘Rom’ in something not a structure or union DS1.c /ThermalCtrl_ds18b20_test/Generated_Code line 467 C/C++ Problem
    request for member ‘Rom’ in something not a structure or union DS1.c /ThermalCtrl_ds18b20_test/Generated_Code line 480 C/C++ Problem
    request for member ‘Rom’ in something not a structure or union request for member ‘Rom’ in something not a structure or union DS1.c /ThermalCtrl_ds18b20_test/Generated_Code line 474 C/C++ Problem

    Like

    • Yes, but not sure when I get to that point. First I’ll refactor the OneWire so it uses non-LDD component (is in progress) and two issues you have reported.
      Unless you want to contribute an implementation?

      Like

  3. Pingback: Using FreeRTOS with newlib and newlib-nano | MCU on Eclipse

  4. I need to interface MK60FX512VLQ12 processor from NXP with AD7194 ADC from ADI. AD7194 is a 24 bit ADC and has on chip SPI registers with 8 bits and 24 bits word length. How should I make use of PE components to communicate with AD7194? To my knowledge PE supports only registers having max 16 bits word length in SPI Slave. How can I give commands with 8 bits and 24 bits with the same SPI Component (SynchroMaster or SPIMaster_LDD) ?

    Like

    • Processor Expert SPI (e.g. SynchroSerial) supports any number of bytes. Use the RecvBlock() or SendBlock() method in the SynchroSerial componnt to send or receive any numbers of bytes.
      I hope this helps,
      Erich

      Like

      • Thanks Erich.
        1) I have set basic width as 8 bits and using SendBlock() function to send 24 bits as a block of 3 bytes. But SCLK is generated for only 2 bytes in SendBlock().
        2) Also, RecvBlock() doesn’t generate any SCLK from K60. I believe RecvBlock() should generate the required SCLK for the Slave to send the data.
        Any ideas or suggestions.

        Like

      • 1) It was no programming error. SendBlock() generates SCLK for only max 2 bytes if Slave Select Pin is enabled in SynchroMaster. This was solved by removing Slave Select Pin from SynchroMaster and by separately toggling the CS pin which was added as a BitIO component.By doing so any no. of bytes can be sent. Although I really didn’t understand the issue when Slave Select Pin is added.

        2) Thank you for correcting my concept regarding RecvBlock(). Now I am sending dummy SendBlock() after the actual SendBlock() for receiving data from SPI. But still the RecvBlock() returns data value of 0 and there is no activity on the SDO line as seen on the CRO.

        Please help.

        Like

        • 1) interesting! I never have used Slave Select Pin toggling (this only makes sense if you have one slave on the bus, but if I have one slave, I don’t need that chip select).
          2) ReceiveBlock() uses a buffer which has ben filled during the SendBlock() operation, so you won’t see any SCLK activity during ReceiveBlock(), as it only uses the content in RAM of the buffer. What is the buffer size you have specified in the component? Make it large enough so it can hold all bytes (say 32 or 64 is a typical setting).

          Like

      • Hi Erich. Finally solved the problem. It was a hardware issue. Needed to pull-up the SDO line. After that I could capture the data sent on SDO line using a CRO.
        The same also reflected in the data returned by RecvBlock().
        Once again thank you for the prompt reply and support from your end.

        Please do look into the issue of not able to send more than 2 bytes if Slave Select Pin is enabled in SynchroMaster component. That will be a very useful addition for the tool as such. Thank you !!!

        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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.