Eclipse and Processor Expert How to Read Data by Application

In "Overview: From Snippets to Lawmaking Generation" I discussed several tools used in my development process. On tool which helps me a lot to get things done is Processor Expert. In this post I'll requite an overview near this tool and reasoning for the pros and cons of using information technology.

Processor Good

Overview

In this article I go over the concepts of Processor Expert and how I'm using them in my applications. I have used it in many customer and research projects over the last years. Every bit a tool might not fit every use case, I try to list the pros and cons how I see them.

History

I don't know the full history of Processor Expert past any means, so here is just what I know and was able to gather: Processor Expert is a tool who has been developed by Unis, starting around 1994 in Brno, Czechia. I started using that tool around 1998 and later on with the 'classic' CodeWarrior using the Motorola/Freescale HCS12 and HCS08 microcontroller. At that time, Processor Expert engineering was independent and available for non-Motorola/Freescale processors as well, east.g. for Fujitsu. In 2001, it has been awarded the European IST price.

💡 The European IST price is mentioned in web documents, but this IST organization/web page seems not to get out any more?

The technology has been caused in 2008 past Freescale and supports Freescale only processors by now: HCS08, HCS12(X), DSC, ColdFire, i.MX and Kinetis.

At the offset, the tool was available equally a 'standalone' version (without IDE), but then has been integrated past Metrowerks into CodeWarrior IDE as plugin.

Processor Expert in CodeWarrior

Today it is available as plugin in Eclipse (e.grand. Kepler, Luna) or integrated in Freescale Kinetis Design Studio, and runs on Windows, Mac OS X and Linux.

Processor Expert in Eclipse

Pros	Cons
Develop a working application very fast.	Needs time to acquire the tool.
Has congenital-in noesis base, sometimes better than the reference manual.	A solid agreement of microcontroller is still required.
Graphical User Interface.	Needs ressources on the host to run the GUI
Integrated into Eclipse and CodeWarrior IDEs.	Other not-Eclipse IDE'southward like Keil or IAR need to use information technology equally external tool which is not that user friendly.
Broad range of Freescale devices supported.	For Freescale only

Concept and Flow

The concept of Processor Expert is that it I tin can select 'components' from a Component Library to utilize and combine them in my application. Components are similar 'Lego Blocks' with interfaces which can be put together and which can be configured. Based on this configuration, information technology and then uses a Code Generator to produce normal C/C++/Asm source files.

Processor Skilful Flow

Beside of the source files, that lawmaking generator produces study and documentation files. Together with my source files they become compiled/linked to build the ELF/binary file for my lath.

Pros	Cons
Ability to practice rapid prototyping with components from the library.	Depend on availability of component for devices, not all Freescale devices are supported.
Source files optimized and generated based on my settings, the generated code is static.	Safety coding rules tin can prevent any 'generated' code. Using a new version of the tool tin affect code generated, needs re-certification of awarding/code.
Sharing of common code and library functions.	Code generation especially for many modules can irksome down a full build of the application.

Component Library

The component library has 'blocks' for reading in analog values (ADC) or toggling pins (Scrap I/O) up to more complex things like communication stacks (USB) which itself can contain several sub-components. Components can be very hardware specific (like a UART), or can exist pure software components like 1 to implement a ring buffer.

Components Library in Eclipse

An installation of Processor Expert comes with many components included. It is possible to create your own components using the CDE (Component Evolution Surround) framework.

Pros	Cons
Reusing mutual blocks as a library in application.	Upward until recently (Processor Expert for Kinetis v3.0.0) it was not possible to employ multiple repositories.
Browse and search for functionality/components.	If functionality is not provided by Freescale, need to add/create own or 3rd political party component.
Broad range of components, typically comprehend on-chip functionality.	Very few 'off-chip' components bachelor similar sensors or other external components. Freescale only provides components for Freescale devices.
Graphical user interface with online help with 'help on component'.	Lack of documentation, tutorials and example projects.

High Level Beans, Logical Device Drivers and SDK Components

In Processor Adept at that place iii dissimilar types of components:

1. Loftier Level Components or Beans (HLB): These were introduced first. They utilise a uncomplicated API. East.yard. to ship a character on the UART I call AS1_SendChar('a'):

   

   AsynchroSerial High Level Bean

   This tin be easily used for bare metal and application with an RTOS. Of grade if using a device from multiple tasks at that place has to exist a synchronization in identify. The biggest advantage of the 'Beans' is that they have a common API across different architectures, so I can use the aforementioned API/components beyond say HCS08, HCSC12, DSC and ColdFire devices. So porting an awarding from one architecture to another typically is a affair of hours.

2. Later on the Logical Device Drivers have been introduced with the introduction of Freescale Kinetis Devices. These components take the "_LDD" at the terminate of the name. The difference is that now a 'device handle' needs to be passed in each API call:These components are not that easy to use and not every bit efficient equally the Loftier Level Beans equally in that location is e'er that extra parameter. While that 'device handle' is a good thing for some applications, it is an overkill for bare metal applications or where a device is used by a unmarried RTOS task only (which in many cases is the default use instance). The biggest issues with the LDD is that their API did break compatibility with previous (say S08 and S12) projects, equally only bachelor for Kinetis. That's why shortly later on the release of LDD components Freescale had to provide High Level Beans for Kinetis as well to provide a compatibility API. And so with using inheritance both API'south were offered:

   

   LDD every bit inherited component inside the Loftier Level Component

3. With the introduction of the Kinetis SDK a new type of components were introduced: the SDK components which have the "fsl_" in front of their name.

   

   fsl_uart SDK Component

   The SDK components itself do not generate the full driver. Instead, they generate the configuration structures for the Kinetis SDK. The SDK is using a HAL (Hardware Brainchild Layer), and for this there are too '_hal' components offered and which are used inside the 'fsl_' components. Fifty-fifty if these components practise not generate the code, they offer an easy visual way to utilise the Kinetis SDK.

Pros	Cons
Elementary API for High Level Beans. Easy to employ and learn.	Awarding lawmaking needs to bargain with synchronization
Extended prepare of functionality e.1000. for Timers or the Flex Timers on Kinetis.	Overhead and complexity of LDD which is not needed for many applications. Difficult to utilize/learn
Generic Device handle for LDD, easier to use it in an RTOS environment which uses device handles (e.g. MQX).	LDD API non uniform with previous applications using HLB components.
'Static' configuration and code generation with SDK components. Components are for 'configuration', not code generation. Easy and visual way to employ the Kinetis SDK and HAL API.	SDK components break again with previous projects. Components/projects cannot use/mix unlike components, no portability API. SDK itself adds complexity and overhead.

Methods, Events and Properties

I can utilize components from the Component Library. A component tin can utilize Methods, Events, Backdrop and Inheritance:

• Methods: Functions/procedures of the driver. E.1000. SendChar() for an UART component
• Events: Hooks or interrupt events. E.k. OnRxChar() interrupt hook for an UART component
• Properties: Settings of the component which touch the behaviour of the commuter.
• Inheritance: Multiple components can exist combined or using links/interfaces to other components, in an object-oriented way. For example a UART component can inherit from a depression-level UART component and build up a new interface with new functionalities.

AsynchroSerial Component

Methods and events tin be enabled or disabled it not used (marked with a small 'x') in above screenshot. Methods which are disabled are not generated, and the component code generator might optimize the driver based on what is enabled/disabled. For case if there is no 'GetStatus()' method needed, and then the component might not need to store a condition somewhere at all.

For the components, there is a view to change and audit the properties: for the UART component for example I can turn on interrupts and assigns the pins to be used for Rx and Tx:

Asynchroserial UART Component Properties

💡 I'm showing the 'classic' view in above screenshot. There is a 'tab' view (default) too, only that tab view in my opinion is much harder to use, and so I recommend to use the 'classic' view. See "Switching between 'tabs' and 'no-tabs' UI in Processor Practiced" for details.

Basically, this gives me a graphical front for my UART driver. Based on my settings, information technology will configure and produce software Files for me:

Generated UART Driver code

The source code for sending a character over UART will look like this:

/* ** =================================================================== ** Method : AS1_SendChar (component AsynchroSerial) ** Description : ** Sends one character to the channel. If the component is ** temporarily disabled (Disable method) SendChar method just ** stores information into an output buffer. In case of a zero output ** buffer size, but one character can be stored. Enabling the ** component (Enable method) starts the transmission of the ** stored data. This method is bachelor simply if the ** transmitter property is enabled. ** Parameters : ** Name - Clarification ** Chr - Character to ship ** Returns : ** --- - Error code, possible codes: ** ERR_OK - OK ** ERR_SPEED - This device does not work in ** the active speed fashion ** ERR_TXFULL - Transmitter is full ** =================================================================== */ byte AS1_SendChar(AS1_TComData Chr) {  if (SCI1S1_TDRE == 0U) { /* Is the transmitter full? */    return ERR_TXFULL; /* If yes then error */  }  SCI1D = (byte)Chr; /* Shop char to the transmitter register */  return ERR_OK; /* OK */ }        

Then this is not much different from any other UART driver. The departure is the cognition and the consistency checking Processor Expert is doing. For example it knows which pins are available for the Rx office, and which pins are already used by something else:

UART Pivot Assignment

There is equally well the CPU view which keeps tracks about which blocks and pins are used:

Processor Expert CPU View

The other affair is that it proposes me possible UART Baud values I can utilize:

Baud Selection nowadays in UART

For this it keeps track of the internal clocks and clock paths:

Clock Path to UART

All this information would be nowadays in the device reference transmission too. Simply it is much easier and faster to use the AsynchroSerial/UART component:

1. Add together component to project
2. Select UART device (due east.g. UART0)
3. Cull Rx and Tx pins
4. Specifiy initial UART Baud rate
5. Generate the driver/configuration
6. Use it in my awarding

If I'm non happy with the generated lawmaking, I take the selection to 'freeze' the code generation of a component. Meet "Disable my Code Generation".

Pros	Cons
Piece of cake and simple way to have a driver.	Yet need to understand how the hardware works to some extend.
Graphical UI for configuration.	Requires IDE integration (Eclipse).
Consistency checking prevents wrong or bad settings.	Consistency checking requires time, slows down the tool. Sometimes 'rekursive' dependencies are not properly resolved.
Generates driver code and instance lawmaking 'which works'.	API and coding style might not lucifer ain preferences. Because the driver demand to deal with many dissimilar use cases, it is not the well-nigh efficient ane (code size, speed).

Physical Device Drivers

In case the generated functions and methods are not enough, at that place is a lower layer of API which tin exist used: the Concrete Device Drivers (PDD, see "Depression-Level Coding with PDD (Physical Device Driver)"). Basically the PDD are depression-level macros which can exist used to admission the low-level functionality of the device. Because the PDD macros are tight to the device used, they are not much portable betwixt dissimilar devices.

Physical Device Driver

Pros	Cons
Pocket-size and tight code.	Hard to understand API and how to utilize it.
Access to low-level peripheral function.	Macros are device dependent, non portable.
Graphical UI to drag&drop macros/functions	Lack of documentation.

Inheritance

Some other nifty functionality of Processor Expert components is their 'inheritance' model: A component tin can inherit functionality from other components. The following shows the LED component which is inheriting functionality from a 'BitIO' component:

Component Inheritance

The LED function On() (to turn the LED on) will use either the BitIO ClrVal() or SetVal() to change the logic level of the pin, according to the LED settings how the cathode/anode of the LED are connected to the port pin. This inheritance scheme is very powerful and enables component sharing. Processor Expert has likewise the ability to 'link' to other components. For instance the LED component can link to a Shell component, and that way automatically enable command line support for that component:

Linked Components

Pros	Cons
Ability to plough on/off functions to optimize the code.	Sometimes unclear what the bear on of enabling/disabling functionality will be.
Easy manner to generate lawmaking "which works" or can be used every bit reference implementation.	Code sometimes not ideal, or not very well documented.
Automatically checks for dependencies, configures the pins and clocks for me. Checks for conflicts.	Still need to sympathize the microcontroller. Making bad settings will effect in bad results.
I tin can disable code generation and do my own changes.	Freescale provided components are 'closed': I cannot edit or change them.

Component Development Surroundings

The component framework in Processor Skilful allows me to create my own components. that capability is gratuitous of charge (no license required) if I'chiliad non going to sell the components created. This is the 'Community Edition License', and if no other license is institute, this text in the Eclipse Console View is printed:

CDE: no license institute, using Community Edition License

I wrote a tutorial "Tutorial: Creating a Processor Skillful Component for an Accelerometer" how to create my own components. Newer Processor Expert releases come with a Java based/Eclipse plugin to create/change your components. In archetype CodeWarrior there was the 'BeanWizard' (standalone), but this one required a paid/Professional CodeWarrior license.

Using CDE, I can create components like the ane on McuOnEclipse SourceForge site, or like the components provided past Freescale. With one exception: it is not possible to create Processor components:

Processor Components

Pros	Cons
Can create my own components.	Not easy to learn, takes a lot of feel.
Costless license (Eclipse plugin)	Cannot sell components, cannot create Processor components. Archetype BeanWizard is not free of charge.
Graphical wizard and user interface to create components.	The CDE plugin in Eclipse is not very mature and non as easy to use equally the 'archetype' BeanWizard.

Portability

The other big advantage of using components is: as the component interface remains the same, and because Processor Expert is bachelor on multiple Freescale platforms, it is very easy to move projects between different derivatives. For instance I have my INTRO Robot awarding running on Freescale S08, ColdFire and Kinetis (ARM), all with the same set of components. So Processor Adept makes information technology actually easy to motion from one device to another (e.yard. Kinetis KL25Z to Kinetis K64F) or from one architecture to another (due east.1000. HCS08 to Kinetis KL25Z), or from one toolchain to another (e.g. CodeWarrior to KDS or to any other Eclipse IDE).

For example this is a project for an S08 (Freescale S08 16bit microprocessor) on CodeWarrior which uses multiple components including an LCD:

SRB Nokia Project (S08, CodeWarrior)

The same functionality/project on a 32bit Kinetis (ARM Cortex-M0+) on Eclipse Kinetis Pattern Studio:

Nokia project on ARM (KL25Z, Kinetis Pattern Studio)

Porting such a project is a matter of an hour or less:

1. Create a new (empty) project for Processor Expert for the new target
2. Re-create-Paste the components to the new project (see "Copy of Processor Expert Components")
3. Alter the component settings to use the new pins on the new board.
4. Copy the awarding code
5. Generate Code, build and test 🙂

A good case how Processor Skillful components can be portable beyond different toolchains, architectures and IDE's is the FreeRTOS Processor Skilful component maintained in the McuOnEclipse project:

McuOnEclipse Processor Good Component

A single component with a graphical user interface to configure FreeRTOS:

• 9 Compilers and half dozen Architectures: Freescale chc12, chc08, DSC, ColdFire V1, ColdFire V2 and ARM compilers, GNU GCC ARM Embedded (launchpad), IAR, Keil
• vii IDE's: CodeWarrior (classic) 6.x, CodeWarrior (eclipse) 10.ten, Kinetis Design Studio, Driver Suite x.x, Atollic TrueStudio, Emprog Thunderbench, NXP LPCXpresso
• iii component types supported: HLB (Loftier Level Beans), LDD (Logical Device Drivers) and Kinetis SDK.

One component to rule them all 🙂 🙂

Summary

I know this is a rather long post, and I hope it gives an overview for newbies what Processor Expert is: A component based framework which encapsulates software with a graphical configuration front finish. In that location is much more backside this framework, including automatic build and generation support. Of course no tool is perfect, and no tool fits every demand. The problem I see is that the framework should be faster especially for large projects. Simply the biggest disadvantage (maybe Freescale might say that this is the key feature 😉 that information technology exists but for Freescale devices. So once someone has explored the power of information technology, information technology will be hard to motility to another vendor.

To me, Processor Expert is like C++: information technology takes some learning and time to primary it, simply then information technology is incredible powerful. Sometimes I feel similar at the one-time days when C/C++ compilers got introduced, and anybody was using assemblers: high level linguistic communication was considered as boring, inefficient and "I can plan this better!". But today in that location is no argument near using compilers because they have both improved and second we need to be more productive. And everything else looks similar rock historic period ;-).

Happy Experting 🙂

Links

• Unis company: http://www.unis.cz/
• Processor Expert spider web site: http://www.freescale.com/ProcessorExpert
• Disabling Processor Expert lawmaking generation: Disable my Code Generation

brooksphred1952.blogspot.com

Source: https://mcuoneclipse.com/2015/10/18/overview-processor-expert/

Share this post