Setting up new hardware targets

Edit online

You can modify the files provided by Rhapsody® to match your development environment, or create a new set of files to support your specific target.

About this task

You can add support for a new target to be used with the MicroC framework (MXF) that matches your development environment. In this task you will add the appropriate files and definitions that define a new Environment to be used by a code generation Configuration to generate and build an application targeting your specific hardware. This task is also called retargeting that means, for example, supporting a new hardware target.

Each supported hardware target is defined using:

A set of properties, defining the various characteristics of the files related to a specific target and the way to build an application for that target, also referred as an Environment.
A set of files, called adapter, that defines the target specific implementation for hardware related capabilities such as hardware timer, communication, and so on.

The set of the properties used by the code generation's Configuration is determined by the Environment dropdown list located on the Settings tab of the Features dialog for that configuration.

The contents of the Environment dropdown list is taken from the enum definition of the C_CG::Configuration::Environment property.

In addition, Rhapsody includes a number of target-specific file sets. Each set of files defines an adapter for the MicroC Execution Framework (MXF). The adapters can be found in the appropriate product installation subdirectory under <Install-Dir>\Share\LangC\mxf\Adaptors\Mainloop.

To create a new Target you are required to create a similar set of files that adapt the MXF to that target.

Procedure

Add a new environment definition suitable to your target by creating the Site.prp file in <Install-Dir>\Share\Properties directory or by updating it:
1. Copy the environment enum property from the <Install-Dir>\Share\profiles\MicroC\MicroC.prp file, and append it with your new environment’s name.
  In the prp file the property is found in this location:
```
Subject C_CG
    Metaclass Configuration
       Property Environment …
    end
end
```
2. Copy the set of properties that defines an environment, as defined in MicroC.prp file. For example, you can copy the section starting with metaclass <Environment-name> and ends with end, and all properties defined between these tokens.
  For example, Metaclass MainLoopSTM32 and all the lines that start with Property until the line end tag, and rename the copied environment to the new environment name.
```
Subject C_CG
    	Metaclass <Environment>
				Property Property1         
				Property Property2        
				Property Property3         
				…      
			end 
		end
```
3. Change the definition of the properties environment. For example, C_CG:<NewEnvironment>:AdaptorSearchPath to point to a new adapter directory: <Install-Dir>Share\LangC\mxf\Adaptors\MainLoop\<NewTargetFolder> or $OMROOT\ LangC\mxf\Adaptors\MainLoop\<NewTargetFolder>.
  Note: The NewTaregtFolder is the name you have selected to represent your target on the file system.
Create the new directory for the target, as defined in AdaptorSearchPath, and copy files from an existing adapter to the new directory. It is recommended to choose the target which is most similar to your target, such as <Install-Dir>\Share\LangC\mxf\Adaptors\MainLoop\Stm32x.
Define the mainloop's step by implementing the function RiCOSMainTask_WaitStep in the file RiCOSTarget.c, usually done using a hardware timer. See $OMROOT\LangC\mxf\Adaptors\MainLoop\Stm32x\RiCOSTarget.c as reference.
In the file RiCOS.h, add an #include statemant to RiCOSMainloop.h.
For targets supporting advanced operation systems (OS) services, such as mutexes, TCP, and so on, override relevant adapter APIs in the file RiCOSTargetServices.c\.h.
Each overridable API in the file RiCOSMainloop.c is surrounded with a preprocessor macro: <function-name> Defined using an #ifndef… #endif compiler directive. To override an API define this compiler macro in the file RiCOSTargetServices.h and add a new implementation in the file RiCOSTargetServices.c. For example, see the overriding of the API RiCOSEventsPoolMutex_init in the target-adapter <Install-Dir>\Share\LangC\mxf\Adaptors\MainLoop\Linux .
To enable Target Monitoring, back animation of the application while running on the target, modify the file TargetMonitorProtocol.c\.h according the communication (up link) available on the target. If there is no support for target monitoring remove these files.
It is recommended to change the timer calibration to represent a one millisecond for one time unit. The expected default value is tm(1) of 1Milisecond delay.
1. C_CG::Configuration::TimerManagerTimeCycle property that is used in MXF configuration file template C_CG:Configuration:mxfCfgTemplate, #define RICTIMERMANAGER_TIME_CYCLE $<Time ManagerTimeCicle>.
  The value of this property defines the cycle of the hardware timer defined in step (3). Keep this number as small as possible (integral), in order to allow maximal range and resolution for time outs.
2. C_CG::Configuration::TimerManagerDefaultTickTime property that is used in MXF configuration file template C_CG:Configuration:mxfCfgTemplate, #define RICTIMERMANAGER_DEFAULT_TICK_TIME $<TimeManagerTickTime>.
  This value is used for the MXF's TimerManager as the increment value for each OSTimer tick, according to the HW Timer definition. The HW Timer represents how much time units passed between two consecutive hardware timer ticks.
3. OSTIMER_INIT() C-Macro is defined in RiCOS.h that defines the initial value of the H\W Timer’s related counters using hardware specific timer initialization.
To run the application, implement the RiCOSMainTask_WaitStep function in such a way that it will do a sleep of the duration defined in (7.b) step that represents the minimum time interval that the MXF timer can distinguish.