Microchip dsPIC

From ErikaWiki

(Difference between revisions)
Jump to: navigation, search
(Setting up the compiling environment for the PIC30 architecture)
(Avoid the generation of dependency files)
Line 124: Line 124:
};
};
</pre>
</pre>
 +
 +
=== Avoid the generation of .src files from C files ===
 +
The typical compilation process of an Erika Enterprise application produces various files which can be used to better analyze the code generated by the C30 compiler. In particular, from each .C file, a .SRC file is produced containing the corresponding assembler listing, which is then compiled by the MPLAB ASM30 compiler to produce the .o.
 +
 +
It is possible to avoid the intermediate step which leads to the production of the .SRC file. In that case, the compiler will be responsible of producing the .O file directly from the .C file. This in general also speeds up the compilation process a little bit. To obtain that feature, you can put the following lines in the OIL file.
 +
<pre>
 +
CPU mySystem {
 +
  OS myOs {
 +
    EE_OPT = " NOSRC ";
 +
    ...
 +
  };
 +
  ...
 +
};
 +
</pre>
 +
 +
 +
=== Printing the commands executed (verbose mode) ===
 +
The default compilation process typically prints only a compact output for each compilation step. That is in general not useful whenever a file is not compiled properly and the user wants to know the exact command which is executed in the compilation process.
 +
 +
To obtain a printing of the complete list of commands issued by the Erika Enterprise makefile, you can add the following line to the OIL file:
 +
<pre>
 +
CPU mySystem {
 +
  OS myOs {
 +
    EE_OPT = " VERBOSE ";
 +
    ...
 +
  };
 +
  ...
 +
};
 +
 +
 +
=== Source files composing an application ===
 +
The source files which can be put in an RT-Druid project are composed by C-language files (with extension .c) and Assembler files (with extension .S). Assembler files are always preprocessed by the C preprocessor. All the application files which has to be included in the final application needs to be listed inside the OIL file, as in the following OIL example:
 +
<pre>
 +
...
 +
CPU_DATA = PIC30 {
 +
  ...
 +
  APP_SRC = "file_1.c";
 +
  APP_SRC = "file_2.c";
 +
};
 +
...
 +
</pre>
 +
 +
 +
=== Stack handling ===
 +
Erika Enterprise can be configured as monostack or multistack.
 +
 +
In a monostack configuration, only a single stack exists in the system. No blocking primitives are supported, and all the tasks and interrupts execute on the same stack. In this case, the one and only stack starts from the top of the application allocated memory, growing towards higher addresses. The monostack configuration can not be used if the application needs to call RTOS primitives such as WaitSem and WaitEvent. Moreover, it cannot be used when Erika Enterprise conformance classes ECC1 and ECC2 are used. To configure a monostack kernel in the OIL file, the user has to write the following lines:
 +
<pre>
 +
...
 +
CPU_DATA = PIC30 {
 +
  ...
 +
  MULTI_STACK = FALSE;
 +
};
 +
...
 +
</pre>
 +
 +
In a multistack configuration, the kernel support the existence of different stacks in the same application. Having different stacks allow the application tasks to use blocking primitives like WaitSem and WaitEvent, which basically may block the execution of the running task. In that case, the calling task must have a private stack which is changed upon blocking. The stack will be selected again when the task will be rescheduled. There are different stacks available in a multistack configuration:
 +
* A shared stack (used by all the tasks which have a shared stack);
 +
* An IRQ stack (used by all the ISR Type 2 routines);
 +
* A set of private stacks (one for each task which has selected a private stack).
 +
 +
In the dsPIC architecture, the shared stack works as in the monostack configuration, that is it is allocated at the end of the application data section, growing towards higher addresses. The IRQ stack and the private stacks, instead, are allocated in the
 +
application data space as arrays.
 +
 +
The following example shows an OIL configuration which configures a multistack kernel without a separate IRQ stack (in this case, IRQ handlers execute on the stack of the interrupted task):
 +
<pre>
 +
...
 +
CPU_DATA = PIC30 {
 +
  ...
 +
  MULTI_STACK = TRUE {
 +
    IRQ_STACK = FALSE;
 +
  };
 +
};
 +
...
 +
</pre>
 +
 +
The following example shows an OIL configuration which configures a multistack kernel with a separate IRQ stack (in this case, some registers are saved on the stack of the interrupted task, but the IRQ handler C function is executed on a separate IRQ stack).
 +
<pre>
 +
...
 +
CPU_DATA = PIC30 {
 +
  ...
 +
  MULTI_STACK = TRUE {
 +
    IRQ_STACK = TRUE {
 +
      SYS_SIZE =64;
 +
    };
 +
  };
 +
};
 +
...
 +
</pre>
 +
 +
=== Runtime stack checking exceptions ===
 +
 +
When multistack configurations are used, it is very useful to be informed when a particular stack becomes full. For this reason, the dsPIC (R) DSC core allows the user to specify a stack limit over which an exception should be raised. The stack limit is contained
 +
inside the internal register SPLIM.
 +
 +
Erika Enterprise is able to automatically handle the SPLIM register, setting it at runtime to the top of the current stack when a multistack configuration. The SPLIM feature is by default disabled, because it adds some (little) overhead at each stack change. To enable it, you must include the following lines inside the OIL configuration file:
 +
 +
<pre>
 +
...
 +
CPU_DATA = PIC30 {
 +
  ...
 +
  ENABLE_SPLIM = TRUE;
 +
  };
 +
...
 +
</pre>
 +
 +
Please note that Erika Enterprise does not provide a default handler for the stack overflow exception generated by the SPLIM register. The exception should be specified by the developer as the behavior to implement is often application dependent.
 +
[[Category:Supported Devices]]
[[Category:Supported Devices]]

Revision as of 15:02, 20 September 2011

Contents

Introduction

Embedded microcontroller units are spreading in thousands of applications, ranging from single to distributed systems, control applications, multimedia, communication, medical applications and many others. Modern microcontrollers, which are growing in computational power, speed and interfacing capabilities, are more and more feeling the need of tools to make the development of complex scalable applications easier.

The dsPIC (R) DSC family represents the latest product of Microchip Technology Inc., the world leading company in the field of microcontroller units. With a speed of up to 40 MHz, the dsPIC (R) DSC family seamlessly integrates a DSP core for high performance computation with a full range of interfaces to several buses like CAN, I2C, SPI, serial lines, ecc.

Erika Enterprise and RT-Druid for Microchip dsPIC (R) DSC

Embedded applications often require tight control on the temporal behavior of each single activity in the system. The research in the field of real-time systems brought the team of Evidence Srl to design a small, efficient, modular real-time kernel that can be used to easily guarantee real-time constraints in every embedded applications.

Erika Enterprise and RT-Druid represent the answer of Evidence Srl for the development of scalable real-time applications for the Microchip dsPIC (R) DSC family.

The main features of ERIKA Enterprise and RT-Druid which are specific for Microchip dsPIC (R) DSC are the following:

  • Installation setup which integrates Microchip software together with fully configured Evidence Erika Enterprise + RT-Druid;
  • Full support for the Microchip devices libraries;
  • Full support for the Microchip C30 compiler;
  • Full support of the MPLAB IDE debugging environment;
  • Full support for the Microchip ICD2 debugger;
  • Full support for dsPIC (R) DSC series 30 and 33, and PIC24
  • Support for the 802.15.4 (ZigBee) wireless communication protocol (using Maxstream XBee, Microchip ZigBee coming soon);
  • Support for I/O to Multimedia Card (MMC) / Secure Digital with FAT filesystem (coming soon);
  • Development of many specific hardware drivers for dsPIC (R) DSC, like multiple servomotor driving, bus EIB support (domotic), and many other (coming soon);
  • Support for the FLEX development board (see here for details);

Integration with Microchip Inc. products

Erika Enterpise and RT-Druid aims to the best integration with the existing tools for development available from Microchip Inc.

RT-Druid will be used to quickly configure the application, setting temporal parameters of real-time tasks, memory requirements, stack allocation and many other parameters. RT-Druid generates the application template, and leaves the developer the task to implement the logic of each single task.

While programming the application, the developer can exploit the power and flexibility offered by the primitives of the Erika Enterprise real-time kernel.

The application can be imported into MPLAB IDE to be written into the dsPIC (R) DSC EPROM flash memory. Moreover, the application can be debugged from within the MPLAB IDE.

Requirements

Erika Enterprise supports Microchip dsPIC (R) DSC families 30 and 33, and PIC24.

Additional software is provided to compile the USB support for the FLEX Full using the Microchip C18 compiler.

The following table lists the requirements upon external programs provided by companies other than Evidence.

There is no guarantee our software will work if you install a different version from what is listed in the table below.

Note the list is basically the sw versions we tried ourselves. if it does not work on your version, just send us a message on the forum...

  • ERIKA Enterprise 1.4.3
    • Microchip MPLAB 8.01 to 8.14
    • Microchip C30 Compiler 2.0.5, 3.0.2, 3.10b, 3.11(by adding the patch below)
    • Microchip C18 3.20
  • ERIKA Enterprise 1.5.0
    • Microchip MPLAB 8.01 to 8.36
    • Microchip C30 Compiler 3.0.2 to 3.20
    • Microchip C18 3.20
  • ERIKA Enterprise 1.5.1
    • Microchip MPLAB 8.01 to 8.66
    • Microchip C30 Compiler 3.0.2 to 3.23
    • Microchip C18 3.20
  • ERIKA Enterprise 1.6.0
    • Microchip MPLAB 8.66
    • Microchip C30 Compiler 3.0.2 to 3.25
    • Microchip C18 3.20


Useful links

PLEASE TRY TO USE THE MICROCHIP TOOL VERSIONS LISTED ABOVE. OTHER VERSIONS MAY NOT WORK. (unfortunately Microchip changes the location of the compiler almost at each new version!)

Erika Enterprise for PIC devices

ERIKA Enterprise and RT-Druid Design Flow

ERIKA Enterprise and RT-Druid Design Flow

Setting up the compiling environment for the PIC30 architecture

Erika Enterprise has been designed to be compiled using the GNU gcc toolchain. The dsPIC porting of Erika Enterprise in particular can be compiled using the GNU tools for dsPIC provided by Microchip. The porting provides both the binutils package and the gcc package, plus a set of proprietary libraries from Microchip which can be used to control the various peripherals provided by the dsPIC microcontrollers.

The following list describes the various packages which contains the various parts of the compilation toolchain:

  • The GNU assembler and binutils. This package is distributed inside the MPLAB IDE from Microchip. ERIKA does not use this package
  • The GNU GCC from Microchip, named Microchip C30 Compiler. The compiler is packaged in a separate product, called The Microchip C30 Compiler, which is available as a product under the Microchip website. A free version is also available for students and universities. The source code of the compiler is also available under the GPL license on the Microchip web site.
  • C Libraries. A set of libraries which can be used to control the peripherals implemented on the particular Microchip chip in use. These libraries are packaged together with the Microchip C30 Compiler.

To compile an Erika Enterprise application, the development environment needs to be configured to correctly recognize the Microchip C30 compiler and the MPLAB ASM30 assembler programs. For doing so, please go to the “Preference” menu, as shown in Figure

Go to the “Preference” menu inside Eclipse.

and find the “RT-Druid/Oil/PIC30 Configurator” form as depicted in Figure

dsPIC paths for compiler and assembler.

The first textbox, labeled Gcc path, refers to the installation directory of the Microchip C30 compiler. The second textbox, labeled Asm path, refers to the installation directory of the ASM30 assembler provided with the MPLAB IDE. The two checkbox are provided for legacy support.

Warning: The install directories specified in the two textboxes in the figure above does not include the bin directory! That is,

c:\Programmi\Microchip\MPLAB C30 

is correct, wheras

c:\Programmi\Microchip\MPLAB C30\bin 

is not.

Warning: The install directory of the assembler refers to the assembler provided with MPLAB IDE and not the assembler provided with the C30 compiler.

Writing software for dsPIC using Erika Enterprise

Note: Please refer to Tutorial: Installing ERIKA and RT-Druid, and compile your first application for a step-by-step guide with screenshots on how to create, compile and debug a dsPIC application written with Erika Enterprise.

This section describes the details about the various configuration options which are available to create and compile an Erika Enterprise application for a dsPIC microcontroller.

Avoid the generation of dependency files

The typical compilation process of an Erika Enterprise application involves the computation of a dependency file which is used to understand which are the files which needs to be compiled or updated.

To avoid the computation of these dependencies (useful when you are sure you basically have to compile everything), you can put the following line in the OIL file:

CPU mySystem {
  OS myOs {
    EE_OPT = " NODEPS ";
    ...
  };
  ...
};

Avoid the generation of .src files from C files

The typical compilation process of an Erika Enterprise application produces various files which can be used to better analyze the code generated by the C30 compiler. In particular, from each .C file, a .SRC file is produced containing the corresponding assembler listing, which is then compiled by the MPLAB ASM30 compiler to produce the .o.

It is possible to avoid the intermediate step which leads to the production of the .SRC file. In that case, the compiler will be responsible of producing the .O file directly from the .C file. This in general also speeds up the compilation process a little bit. To obtain that feature, you can put the following lines in the OIL file.

CPU mySystem {
  OS myOs {
    EE_OPT = " NOSRC ";
    ...
  };
  ...
};


Printing the commands executed (verbose mode)

The default compilation process typically prints only a compact output for each compilation step. That is in general not useful whenever a file is not compiled properly and the user wants to know the exact command which is executed in the compilation process.

To obtain a printing of the complete list of commands issued by the Erika Enterprise makefile, you can add the following line to the OIL file:

CPU mySystem {
  OS myOs {
    EE_OPT = " VERBOSE ";
    ...
  };
  ...
};


=== Source files composing an application ===
The source files which can be put in an RT-Druid project are composed by C-language files (with extension .c) and Assembler files (with extension .S). Assembler files are always preprocessed by the C preprocessor. All the application files which has to be included in the final application needs to be listed inside the OIL file, as in the following OIL example:
<pre>
...
CPU_DATA = PIC30 {
  ...
  APP_SRC = "file_1.c";
  APP_SRC = "file_2.c";
};
...


Stack handling

Erika Enterprise can be configured as monostack or multistack.

In a monostack configuration, only a single stack exists in the system. No blocking primitives are supported, and all the tasks and interrupts execute on the same stack. In this case, the one and only stack starts from the top of the application allocated memory, growing towards higher addresses. The monostack configuration can not be used if the application needs to call RTOS primitives such as WaitSem and WaitEvent. Moreover, it cannot be used when Erika Enterprise conformance classes ECC1 and ECC2 are used. To configure a monostack kernel in the OIL file, the user has to write the following lines:

...
CPU_DATA = PIC30 {
  ...
  MULTI_STACK = FALSE;
};
...

In a multistack configuration, the kernel support the existence of different stacks in the same application. Having different stacks allow the application tasks to use blocking primitives like WaitSem and WaitEvent, which basically may block the execution of the running task. In that case, the calling task must have a private stack which is changed upon blocking. The stack will be selected again when the task will be rescheduled. There are different stacks available in a multistack configuration:

  • A shared stack (used by all the tasks which have a shared stack);
  • An IRQ stack (used by all the ISR Type 2 routines);
  • A set of private stacks (one for each task which has selected a private stack).

In the dsPIC architecture, the shared stack works as in the monostack configuration, that is it is allocated at the end of the application data section, growing towards higher addresses. The IRQ stack and the private stacks, instead, are allocated in the application data space as arrays.

The following example shows an OIL configuration which configures a multistack kernel without a separate IRQ stack (in this case, IRQ handlers execute on the stack of the interrupted task):

...
CPU_DATA = PIC30 {
  ...
  MULTI_STACK = TRUE {
    IRQ_STACK = FALSE;
  };
};
...

The following example shows an OIL configuration which configures a multistack kernel with a separate IRQ stack (in this case, some registers are saved on the stack of the interrupted task, but the IRQ handler C function is executed on a separate IRQ stack).

...
CPU_DATA = PIC30 {
  ...
  MULTI_STACK = TRUE {
    IRQ_STACK = TRUE {
      SYS_SIZE =64;
    };
  };
};
...

Runtime stack checking exceptions

When multistack configurations are used, it is very useful to be informed when a particular stack becomes full. For this reason, the dsPIC (R) DSC core allows the user to specify a stack limit over which an exception should be raised. The stack limit is contained inside the internal register SPLIM.

Erika Enterprise is able to automatically handle the SPLIM register, setting it at runtime to the top of the current stack when a multistack configuration. The SPLIM feature is by default disabled, because it adds some (little) overhead at each stack change. To enable it, you must include the following lines inside the OIL configuration file:

...
CPU_DATA = PIC30 {
  ...
  ENABLE_SPLIM = TRUE;
  };
...

Please note that Erika Enterprise does not provide a default handler for the stack overflow exception generated by the SPLIM register. The exception should be specified by the developer as the behavior to implement is often application dependent.

Personal tools