Overview: Processor Expert

In “Overview: From Snippets to Code Generation” I discussed several tools used in my development process. One tool which helps me a lot to get things done is Processor Expert. In this post I’ll give an overview about this tool and reasoning for the pros and cons of using it.

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. As 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 by 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, Czech Republic. I started using that tool around 1998 and later with the ‘classic’ CodeWarrior using the Motorola/Freescale HCS12 and HCS08 microcontroller. At that time, Processor Expert technology was independent and available for non-Motorola/Freescale processors too, e.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 exit any more?

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

At the beginning, the tool was available as a ‘standalone’ version (without IDE), but then has been integrated by Metrowerks into CodeWarrior IDE as plugin.

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

Concept and Flow

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

Beside of the source files, that code generator produces report and documentation files. Together with my source files they get compiled/linked to build the ELF/binary file for my board.

Component Library

The component library has ‘blocks’ for reading in analog values (ADC) or toggling pins (Bit 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 be pure software components like one to implement a ring buffer.

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

High Level Beans, Logical Device Drivers and SDK Components

In Processor Expert there three different types of components:

1. High Level Components or Beans (HLB): These were introduced first. They use a simple API. E.g. to send a character on the UART I call AS1_SendChar(‘a’): AsynchroSerial High Level BeanThis can be easily used for bare metal and application with an RTOS. Of course if using a device from multiple tasks there has to be a synchronization in place. The biggest advantage of the ‘Beans’ is that they have a common API across different architectures, so I can use the same API/components across say HCS08, HCSC12, DSC and ColdFire devices. So porting an application from one architecture to another typically is a matter of hours.
2. Later on the Logical Device Drivers have been introduced with the introduction of Freescale Kinetis Devices. These components have the “_LDD” at the end 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 as efficient as the High Level Beans as there is always 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 single RTOS task only (which in many cases is the default use case). The biggest issues with the LDD is that their API did break compatibility with previous (say S08 and S12) projects, as only available for Kinetis. That’s why soon after the release of LDD components Freescale had to provide High Level Beans for Kinetis too to provide a compatibility API. So with using inheritance both API’s were offered: LDD as inherited component inside the High 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 ComponentThe 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 Abstraction Layer), and for this there are as well ‘_hal’ components offered and which are used inside the ‘fsl_’ components. Even if these components do not generate the code, they offer an easy visual way to use the Kinetis SDK.

Methods, Events and Properties

I can use components from the Component Library. A component can use Methods, Events,Properties and Inheritance:

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

Methods and events can 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 example if there is no ‘GetStatus()’ method needed, then the component might not need to store a status somewhere at all.

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

I’m showing the ‘classic’ view in above screenshot. There is a ‘tab’ view (default) too, but that tab view in my opinion is much harder to use, so I recommend to use the ‘classic’ view. See “Switching between ‘tabs’ and ‘no-tabs’ UI in Processor Expert” for details.

Basically, this gives me a graphical front end for my UART driver. Based on my settings, it 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 only
** stores data into an output buffer. In case of a zero output
** buffer size, only one character can be stored. Enabling the
** component (Enable method) starts the transmission of the
** stored data. This method is available only if the
** transmitter property is enabled.
** Parameters :
** NAME - DESCRIPTION
** Chr - Character to send
** Returns :
** --- - Error code, possible codes:
** ERR_OK - OK
** ERR_SPEED - This device does not work in
** the active speed mode
** 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; /* Store char to the transmitter register */
 return ERR_OK; /* OK */
}

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

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

The other thing is that it proposes me possible UART Baud values I can use:

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

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

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

If I’m not happy with the generated code, I have the option to ‘freeze’ the code generation of a component. See “Disable my Code Generation"

Physical Device Drivers

In case the generated functions and methods are not enough, there is a lower layer of API which can be used: the Physical Device Drivers (PDD, see “Low-Level Coding with PDD (Physical Device Driver)“). Basically the PDD are low-level macros which can be used to access the low-level functionality of the device. Because the PDD macros are tight to the device used, they are not much portable between different devices.

Inheritance

Another great functionality of Processor Expert components is their ‘inheritance’ model: A component can inherit functionality from other components. The following shows the LED component which is inheriting functionality from a ‘BitIO’ component:

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 as well the ability to ‘link’ to other components. For example the LED component can link to a Shell component, and that way automatically enable command line support for that component:

Component Development Environment

The component framework in Processor Expert allows me to create my own components. that capability is free of charge (no license required) if I’m not going to sell the components created. This is the ‘Community Edition License’, and if no other license is found, this text in the Eclipse Console View is printed:

CDE: no license found, using Community Edition License

I wrote a tutorial “Tutorial: Creating a Processor Expert 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 classic CodeWarrior there was the ‘BeanWizard’ (standalone), but this one required a paid/Professional CodeWarrior license.

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

Portability

The other big advantage of using components is: as the component interface remains the same, and because Processor Expert is available on multiple Freescale platforms, it is very easy to move projects between different derivatives. For example I have my INTRO Robot application running on Freescale S08, ColdFire and Kinetis (ARM), all with the same set of components. So Processor Expert makes it really easy to move from one device to another (e.g. Kinetis KL25Z to Kinetis K64F) or from one architecture to another (e.g. 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:

The same functionality/project on a 32bit Kinetis (ARM Cortex-M0+) on Eclipse Kinetis Design 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. Copy-Paste the components to the new project (see “Copy of Processor Expert Components")
3. Change the component settings to use the new pins on the new board
4. Copy the application code
5. Generate Code, build and test

A good example how Processor Expert components can be portable across different toolchains, architectures and IDE’s is the FreeRTOS Processor Expert component maintained in the McuOnEclipse project:

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

• 9 Compilers and 6 Architectures: Freescale chc12, chc08, DSC, ColdFire V1, ColdFire V2 and ARM compilers, GNU GCC ARM Embedded (launchpad), IAR, Keil
• 7 IDE’s: CodeWarrior (classic) 6.x, CodeWarrior (eclipse) 10.x, Kinetis Design Studio, Driver Suite 10.x, Atollic TrueStudio, Emprog Thunderbench, NXP LPCXpresso
• 3 component types supported: HLB (High 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 end. There is much more behind this framework, including automated build and generation support. Of course no tool is perfect, and no tool fits every need. The problem I see is that the framework should be faster especially for large projects. But the biggest disadvantage (maybe Freescale might say that this is the key feature that it exists only for Freescale devices). So once someone has explored the power of it, it will be hard to move to another vendor.

To me, Processor Expert is like C++: it takes some learning and time to master it, but then it is incredible powerful. Sometimes I feel like at the old days when C/C++ compilers got introduced, and everyone was using assemblers: high level language was considered as slow, inefficient and “I can program this better!” But today there is no argument about using compilers because they have both improved and second we need to be more productive. And everything else looks like stone age.