McuOnEclipse Components: 12-Mar-2017 Release

Posted on March 12, 2017 by Erich Styger

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

Wait: Busy-Waiting using ARM DWT cycle counter
Percepio FreeRTOS+Trace: Updated to version 3.1.1, simplified usage of streaming and snapshot mode
GenericSWI2C: MCUXpresso SDK can be used with the bit-banging I2C driver support
FreeRTOS: includes updates of the 9.0.1 release, ‘optimized task selection, enabled MPU support (experimental)
Graphical GUI drivers for screens, windows, icons, headers, text widgets and more
SSD1351: display driver for Solomon Systech SSD1351 display
More components are now supported by the McuLibConfig settings
Many other smaller bug fixes and enhancements

Cycle Counting for Cortex-M

The KinetisTools component has been extended with functions to count the execution cycles on Cortex-M with DWT (see “Cycle Counting on ARM Cortex-M with DWT“)

Cycle Counting Functions

Wait with ARM Cortex DWT Cycle Counter

The Wait component now can use the ARM Cortex DWT cycle counter for a more accurate busy-waiting (see “Cycle Counting on ARM Cortex-M with DWT“).

The component has a setting which can be turned on for ARM Cortex devices, and if it is an ARM Cortex-M3, M4 or M7, it will use the DWT cycle counter register.

Wait with Cycle Counter

The Cycle Counter gets initialized and started in the new Init() function:

Wait Init and Deinit

Compared to the simple (default) ‘nop’ instruction burning, using the cycle counter provides a better accuracy. Additionally the waiting considers that way interrupt time too.

Below is a 10 ms pin toggling using the cycle counter usage (ARM Cortex-M4):

Using Cycle Counter

Which is better than the ‘burning NOPs’ method:

Wait with NOPs

SD1351 and Graphical GUI Components

The Hexiwear (see “Hexiwear: Teardown of the Hackable ‘Do-Anything’ Device“) uses a Solomon Systech SSD1351 OLED display. For a university research project we are rebuilding the drivers with Processor Expert. For this there is now a Processor Expert component featuring the SSD1351:

SSD1351 Processor Expert Component

SSD1351 Properties

On top of that, there are now several GUI (Graphical User Interface components) available:

GUI Components

They use the object-oriented Processor Expert approach, and with them I can create screens, windows, headers, icons, text with graphical fonts. Below is an example on the Hexiwear with a multiple choice question to answer on the device :-):

Hexiwear GUI

Compared to the original Hexiwear GUI its footprint (RAM, Flash) is much smaller as more targeted for small displays and embedded microcontroller. Additionally the GUI allows navigation and selections using the capacitive touch buttons of the Hexiwear.

An example how to use the components is available on GitHub.

Percepio Trace V3.1.1

The Percepio FreeRTOS trace library has been updated to the latest version V3.1.1. With the new component and version several new settings have been added. It is now possible specify trace enable settings for snapshot and streaming mode. Asserts in the code can be turned off and a separate user event buffer is supported in the settings:

Percepio FreeRTOS Trace

The component works nicely with the new Percepio Eclipse plugin (see “Percepio FreeRTOS Tracealyzer Plugin for Eclipse“).

Summary

For the full history see the commits 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.

I hope you find the new release useful for your projects.

Happy Updating 🙂

36 thoughts on “McuOnEclipse Components: 12-Mar-2017 Release”

po on March 12, 2017 at 16:09 said:

[ Calimero mode ON]
What torment to see every time your component updates or new tuto.
I (and friends) do not use processor expert ; Eclipse and all the interfaces and settings of the environment being already very complex and expert processor even more.

Why Erich Styger is not a fan of basic pairs of .h .c files ??!!
sniff
[ Calimero mode OFF]
Thank you for your work. PE will never make us flee so much your contents are interesting !

LikeLike

Reply ↓
- Erich Styger on March 12, 2017 at 16:23 said:
  
  [Calimero response mode ON]
  I think you might have missed several points about Processor Expert:
  1) It actually simplies using Eclipse and developing drivers/software for these very complex ARM Cortex devices. So it is the other way around: it makes it very simple and easy.
  2) Processor Expert generates normal C source files and header files. If you love normal pairs of .c and .h files, you are a lover of Processor Expert.
  3) Erich Styger is a big fan of basic pairs of .h and .c files too. That’s why he is using Processor Expert.
  4) Because not everyone likes GUI tools like in point 1), that person in point 3) publishes on https://github.com/ErichStyger/McuOnEclipseLibrary the source code for others .c and .h lovers.
  [Calimero response mode OFF]
  Thank you for your comment (appreciated!). Not every tool and every development method works for everyone. Processor Expert is not perfect as no tool is perfect, but it is really a productivity tool.
  Maybe similar like moving from pure assembly coding to C/C++: like there are many benefits for using assembly (I still use it!), I don’t want to go back to build my systems in full assembly code as in early days.
  As always, there are pros and cons, but I try to make things available both for the Processor-Expert-Lovers and the ones who don’t want or cannot use it 🙂
  
  LikeLike
  
  Reply ↓
  - po on March 12, 2017 at 17:32 said:
    
    Besides integrating expert processor to eclipse which is already a big gas factory, I do not understand what processor expert does.
    For years I use PE to quickly find how to initialize a device but the generated code seems very complicated and scattered in a structure that I do not understand.
    There’s a nice article topic : PE for long-time Dummies !
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 12, 2017 at 19:28 said:
      
      What it does is keeping track of all the different clocks, the pin muxing and other resource usage and reports any conflicts. I use it as well to initialize the device (and copy that code), because what it generates actually works and can be used as a reference implementation. The Reference Manual description usually leaves a lot room for interpretation, and with Processor Expert I get working code.
      The other benefit I was using with a lot of projects: it allows me to quickly move an application say from an S08 to a ColdFire or to an ARM core, as with the hardware components (SPI, UART, I2C, GPIO, etc) it gives me a hardware abstraction. The downside (as you mention) is that as any other tool I have to learn it and to learn how things are done. Still, I can take it as a ‘working example’ and then do it my way if I like to do it differently.
      The other thing what it does (and that’s the reason why I provide these components): it is a nice way to distribute software using a component model, years before ARM came up with CMSIS-Packs.
      
      LikeLiked by 1 person
  - Robert Paddock on March 13, 2017 at 14:56 said:
    
    I agree with PO. The best programmers write simple code, in simple to find .c/.h files or other languages.
    
    I have yet to try a tool that produced simple to follow code that is amicable to Code Inspections or MISRA compliance, which are required in may safety sectors of Industry. It is my liability that is on the line in the products that I ship, not the tool vendor’s. ‘Productivity’ is of no value if you can not be sure what the generated code does or will do in obscure corner cases.
    
    KDS 2.0 is somewhat of an improvement over PE. In KDS 2.0 the source code can at least be found, it is not hidden in abstractions of abstractions of abstractions five header levels deep unlike PE code I’ve looked at.
    
    MISRA – The Motor Industry Software Reliability Association
    https://www.misra.org.uk/
    
    Introduction to Code Inspections:
    
    http://www.ganssle.com/inspections.htm
    
    “What’s the cheapest way to get rid of bugs?
    
    Don’t put them in in the first place.”
    
    Especially important in something like a satellite…
    
    For you satellite have you considered SPARK? This is the language that is used when “must not fail” is the important bit. The tools must match the application, we should not use the tools simply because we know them well if they do not fit the safety requirements for the project.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 13, 2017 at 15:51 said:
      
      I have looked at SPARK (really interesting approach), but as this is a student/educational project, it did not fit into the scope.
      
      LikeLike
Konstantin on March 13, 2017 at 11:17 said:

On taste and on color there are no friends.))))

LikeLike

Reply ↓
jonbuford on March 14, 2017 at 06:10 said:

I had a similar question. These components you have released, do they work along with KDS or is it a choice between PE and KDS at that level? I just did my first full project using KDS 2.0, and found that even with the included demo examples, it took a lot of pulling at the edges to understand what things connect to what. For instance, I wanted to try using a DWT based counter, but the only example I found had it mixed in with a DMA analog event so that it was just very complicated to sort out where one started and one ended for a different use case.

I’ve hesitated to use PE because of earlier experiences that it created dependencies that were just too complex to maintain otherwise. It seemed like a great tool to get things up and running, but harder to really use for longer term development.

What would be ideal in your opinion? You mention using PE to kind of setup a project and perhaps get specific examples that function, but that you potentially would replace once you have that pattern to start from. And then there is the portability side of all of this that you mentioned.

I guess on one end we would have the safety and traceability requirements of some projects that need to have things to be clear enough for a person to understand quickly and on the other end we would have something that may be completely obfuscated for readability but is completely maintainable via some clear and simple interface. Something like a GUI programming environment that has a lot of low-level tricks available and only really creates assembly or a complex but highly optimized source would be a potential example of the latter.

LikeLike

Reply ↓
- Erich Styger on March 16, 2017 at 19:16 said:
  
  These components I have released, they work on one hand in a ‘normal’ way with Processor Expert. On the other hand most of them can now be used with the SDK v2. That means that they use SDK API functions as you would do ‘by hand’. For example if you use the LED component, all what you have to do is to specify the port and pin plus if you want to have the component to care about the muxing, and it will do this all for you, as you would have done it manually. But on top it provides functions to turn on the LED or turn it off (depending on the connection to the microcontroller). No magic behind this, it simply helps to get started with the SDK too, and enables me (and my students) to get up and running quickly. The other benfit is: as there we have many, many applications with Processor Expert, it allows us to migrate to the SDK: the application logic is using LEDs, accelerometers, radio transceivers, etc, and Processor Expert is simply the hardware abstraction to it, with a GUI front end to configure the drivers. Now with Processor Expert not available for the SDK v2, we started adding the glue logic to have our own components work with the SDK.
  And for the hundreds (if not thousands users out there using the McuOnEclipse components).
  
  LikeLiked by 1 person
  
  Reply ↓
  - jonbuford on March 17, 2017 at 03:58 said:
    
    Very cool, I’ll have to try it out.
    
    LikeLike
    
    Reply ↓
Konstantin on March 16, 2017 at 13:01 said:

Hello Erich!
Error component GenericSWI2C
only PE,not SDK.

CPU MK20DX50

D:\workspace_RS\Conv6x\Debug/../Generated_Code/I2C1.c:940: undefined reference to `SDA1_Init’
D:\workspace_RS\Conv6x\Debug/../Generated_Code/I2C1.c:941: undefined reference to `SCL1_Init’

LikeLike

Reply ↓
- Erich Styger on March 16, 2017 at 13:18 said:
  
  Hi Konstanin,
  I have to check this, and I’ll report back. Could be really an oversight on my side 😦
  
  Erich
  
  LikeLike
  
  Reply ↓
- Erich Styger on March 16, 2017 at 14:10 said:
  
  Hi Konstantin,
  indeed, an oversight on my side :-(.
  I have fixed it on GitHub: https://github.com/ErichStyger/McuOnEclipse_PEx/commit/038a729f469df9afbecd91553b26ae1cdffd4607
  Do you need a new component or can you take the fix from there?
  
  Erich
  
  LikeLike
  
  Reply ↓
  - Konstantin on March 16, 2017 at 16:32 said:
    
    Thank you Erich !
    P.S. It takes one to know one (c) ;-))
    
    LikeLike
    
    Reply ↓
    - Erich Styger on March 16, 2017 at 19:09 said:
      
      Hi Konstantin,
      in any event, I have published the fixed component on SourceForge until there is a full release: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/
      
      Thanks for reporting that problem 🙂
      Erich
      
      LikeLike
Pingback: Better FreeRTOS Debugging in Eclipse | MCU on Eclipse
David on March 19, 2017 at 06:38 said:

Is there a way to roll back to a previous version? I imported the latest and came accross some issues i dont have time to fix

LikeLike

Reply ↓
- David on March 19, 2017 at 06:44 said:
  
  Oh i think i have that same problem as Konstatin, but for freescale mk22fn1m0vll12
  
  I downloaded the latest yesterday tho so it should have the fix?
  
  LikeLike
  
  Reply ↓
  - Erich Styger on March 19, 2017 at 08:23 said:
    
    Hi David,
    if it is the same issue with GenericSWI2C, there is a patch file (GenericSWI2C_16.03.2017.PEupd) available on SourceForge: https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/ until there is a new full release.
    
    LikeLike
    
    Reply ↓
- Erich Styger on March 19, 2017 at 08:24 said:
  
  Hi David,
  you can download and install any previous version. It will not uninstall the previous version, but will overwrite the files. In 99.9% of cases this is all what you need. If you need to uninstall the previous version and install the new one, let me know.
  
  LikeLike
  
  Reply ↓
  - David on March 19, 2017 at 08:51 said:
    
    Erich, thanks. i’ll try the patch first!
    
    LikeLike
    
    Reply ↓
david a on March 19, 2017 at 21:02 said:

Erich, that patch works. thanks!

LikeLike

Reply ↓
Pingback: Tutorial: Using Eclipse with NXP MCUXpresso SDK v2 and Processor Expert | MCU on Eclipse
daafies on April 4, 2017 at 23:16 said:

Hi Eric,

everytime i add the utilities component, compilation failes on the error codes. (ERR_OK, ERR_FAILED, etc) . when i compare with an older project (make with older components release) i see PE_KDSK_Types.h is missing from the newly created project.

David

LikeLike

Reply ↓
- daafies on April 5, 2017 at 02:46 said:
  
  nevermind.
  made a project without ksdk and there are no issues. i’ll go that route.
  thanks
  david
  
  LikeLike
  
  Reply ↓
- Erich Styger on April 5, 2017 at 10:31 said:
  
  Hi David,
  If you are adding it to an SDK project, there is the McuLibConfig component which is used to configure things (like ERR_OK, etc) depending on the SDK (or API) used. Make sure that inside the McuLibConfig component the matching SDK selected.
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
Jason Philippi on April 13, 2017 at 23:49 said:

Hello Erich,

I am updating from 2016-10-30 to 2017-03-12. I am stuck on a line in KIN1.c.

#if MCUC1_CONFIG_NXP_SDK_USED
#include “fsl_sim.h” /* system integration module */
#endif

I am using KSDK 1.3 on KDS 3.2.0 with a MK24F Cortex-M4 processor. (Eventually I’ll get MCUXpresso maybe when Freescale/NXP/Qualcomm stops doing Merger & Acquisitions)
For some odd reason I don’t have that file. I can’t find it anywhere.
The closest thing I have is fsl_sim_hal_MK24F12.h.

Any suggestions?

Best Regards,
Jason Philippi

LikeLike

Reply ↓
- Erich Styger on April 14, 2017 at 15:36 said:
  
  Hi Jason,
  I’m sorry for that, I have not used the SDK V1.3 for a while, and indeed I have broken the support of the KinetisTools if SDK V1.3 is used :-(.
  I have implemented the fix (https://github.com/ErichStyger/McuOnEclipse_PEx/commit/6b02577c5c127e292bf81e80d6ecb103bc2d9d47).
  I will send a new component to your email address too.
  Again, sorry for that!
  
  LikeLike
  
  Reply ↓
  - Jason Philippi on April 14, 2017 at 18:55 said:
    
    Erich,
    
    That works.
    I haven’t moved up from SDK V1.3 due to Processor Expert making my life easier. Once MCUXpresso adds similar graphical functionality I’ll make my move.
    
    Thank you for all that you do!
    Best Regards,
    Jason Philippi
    
    LikeLike
    
    Reply ↓
Henrique on April 17, 2017 at 14:57 said:

Hi Erich, very good release!

I’m having this problem with WAIT (and also with Utility) component:

“Generator: FAILURE: at line 889: Inherited symbol not found: “ConfigFilesFolderName” (file: Drivers\sw\Wait.drv) Project_1 WAIT1 Processor Expert Problem”

Do you know what is going on?

LikeLike

Reply ↓
- Erich Styger on April 17, 2017 at 15:35 said:
  
  Hi Henrique,
  I think you don’t have the McuLibConfig conmponent installed?
  the zip file from sourceforge has two .peUpd files, did you install both of them?
  
  LikeLike
  
  Reply ↓
Ricardo Pozza on May 5, 2017 at 03:10 said:

Hi Mr Erich
First thanks for all your components
I always use your components in all my projects
but after update, i got a lot of warnings and errors

Error on Segger Sysview and OneWire
Using KDS 3.2.0
McuOnEclipse Components: 12-Mar-2017 Release

FAILURE: at line 24: {{DEVELOPMENT}} Path contains duplicated backshlash: Generated_Code\\SEGGER_SYSVIEW.c (file: Drivers\SEGGER_SystemView_Files.prg) vas SYS1 Processor Expert Problem

FAILURE: at line 10: Unknown macro: “Parerror” (file: Drivers\Common\OneWireOnError.inc) vas OW1 Processor Expert Problem

And a lot of warnings like this in components FRTOS1, MCUC1, RTT1, UTIL1, DQ1, XF1
Warning: {{DEVELOPMENT}} UUID is not assigned to the component, so the reference to the component in the project is incomplete. It is recommended to contact author of the component and ask to fix this problem before component usage. vas CLS1 Processor Expert Problem

LikeLike

Reply ↓
- Ricardo Pozza on May 5, 2017 at 03:16 said:
  
  Error on ds18b20/ow1.c function OW1_Receive(…)
  ERROR= ../Generated_Code/Comp1.c:124:2: error: too few arguments to function ‘OW1_Receive’
  
  called from 18b20 = OW1_Receive(9);
  
  but the function require different inputs
  bool OW1_Receive(uint8_t numOfBytes, uint8_t counter)
  
  LikeLike
  
  Reply ↓
  - Erich Styger on May 5, 2017 at 07:11 said:
    
    Are you using the files from GitHub (https://github.com/ErichStyger/McuOnEclipse_PEx)? I ask because I have made recently a lot of changes to make the 1-Wire component to work.
    
    LikeLike
    
    Reply ↓
- Erich Styger on May 5, 2017 at 07:33 said:
  
  It seems that you have Debug Verbose Mode turned on (Window > Preferences > Processor Expert > Component Development Environment > Enable Processor Expert Component Debug Verbose Mode).
  I usually have this not turned on because many of the warnings do not make any sense, and can lead to non-generating code. So I recommend that you turn it off.
  As for the UUID warning: this is because I do not use the Eclipse CDE (it has too many bugs), so there are no UUIDs in the component which is not an issue.
  I’ll look into the issues you have reported if I can reproduce and fix them.
  
  LikeLike
  
  Reply ↓
- Erich Styger on May 5, 2017 at 08:35 said:
  
  Hi Ricardo,
  I have fixed several warnings and errors if you hve the verbose debug mode enabled:
  https://github.com/ErichStyger/McuOnEclipse_PEx/commit/601f34445700fce3203a14c2559fb7029fbecb0e
  I need to scrub a few more things, but until I release the new components, I recommend that you turn off the verbose debug mode?
  Thanks for reporting!
  Erich
  
  LikeLike
  
  Reply ↓