|
Page date Thu Nov 1 21:43:30 2012 . | Improve this page |
Before you start using the µOS++, please check that you have installed all necessary tools and packages, as described in the How to install page.
TBD…
For loading the latest versions of the projects from repository, the Eclipse standard procedure is to import the ‘WorkspaceTeamProjectSystemAndSampleSets.psf file.
If you need only the system project, please use the ‘WorkspaceTeamProjectSystemSet.psf file.
The second step is to import the file in Eclipse:
Eclipse menu: File → Import
For saving your own Team Project sets:
Eclipse menu: File → Export
TBD…
If your application was built with an older version, and you have good reasons to use that specific revision, this can be easily done with the SVN commands.
Select the micro-os-plus project and right click
The µOS++ was designed to be portable across different boards. In other words, the same source code, without any changes, can be compiled to completely different boards, with completely different characteristics.
There might be many solutions for this, but the preferred one uses the CDT Managed Build mechanism, that completely automates the build process, without having to deal with the creation and maintenance of makefiles.
In Eclipse terms, a single project can have multiple build configurations, each for a different board.
In addition, each board can have different Debug/Release configurations.
To accomodate for multiple build configurations into a single project, in µOS++ the following naming convention is used:
Type-Manufacturer-Board
Where:
Preferably the board is exactly the name of the board, as the manufacturer defines it. If it is longer than usual, or contains special character, it is recommended to shorten/filter it.
To differentiate between build configurations, Eclipse allows to define different build variables for different configurations.
Since in µOS++ the criteria to differentiates between configuration is the board, the only build variable needed is a string, named BOARD.
The values that this variable can hold are uppercase alphanumerical strings, using the following naming convention
Manufacturer_Board
where the parts have the same meaning as before, but converte to uppercase, and ‘-‘ is replaced by ‘_’.
The explanation for these requirements is simple, the BOARD definition will be used as part of preprocessor macro-definition.
To acces the build variables, select the desired project (minimal, for example), and go to the
Eclipse menu: Project → Properties
Name | Type | Value |
---|---|---|
BOARD | String | ATMEL_STK525 |
The second build variables used for Debug build configurations is DBGDEV. It is used to specify the debug device used for the trace output.
Currently only the I2C value is actively maintained.
Another choice is USART, but code for this is not fully supported on all platforms.
In addition to user defined build variables, there are also a lot of system variables. They can be seen by enabling Show system variables.
Build variables can be used as simple macro definitions in most of the places where string fields are allowed in Eclipse.
The next step for forwarding definitions definitions to the build process, are the C/C++ Symbols.
The definitions entered here are automatically added to the preprocessor definitions of corresponding languages used in the project, and, very important, are also used by the CDT Indexer.
To access the C/C++ Symbols, select the desired project (minimal, for example), and go to the
Eclipse menu: Project → Properties
This is the only mandatory definitions required by µOS++, and needs to be present for all projects.
As it can be seen, it expands the build variable BOARD to a custom C/C++ preprocessor definition.
This definition should be present in all build configurations intended for debug.
Among other things, the debug configurations defines a generic serial device, where debug messages are sent. The recommended device is I2C, but it is also possible to use USART ports.
The selections is made by the following definitions. Only one of them should be present.
This definition should be present only for debug configurations, and defines the debug device to be the one defined by the build variable DBGDEV.
The last step for forwarding definitions definitions to the build process, are the C/C++ Tool Settings.
To access the C/C++ Tool Settings, select the desired project (minimal, for example), and go to the
Eclipse menu: Project → Properties
Selecting one specific compiler will show in the All options field the above preprocessor definitions passed as -D options to the GCC compiler.
Whenever possible, it is also recommended to use the GNU Make Builder, instead of the CDT internal one.
To access the C/C++ Tool chain Eitor, select the desired project (minimal, for example), and go to the
Eclipse menu: Project → Properties
Although creating new projects from scratch is perfectly possible, the configurations are slightly more complex than usual, so the recommended method is by copy/paste, using as template the sample-minimal project.
Update project to reference micro-os-plus.
Continue to the Build Project section below.
If needed, instead of manually configuring projects, it is easier to copy build configurations from existing projects.
The reference project is the sample-minimal project, it is highly recommended to copy configurations only from this project.
For unknown reasons, not all settings are copied, and some manual changes are needed:
All project should have a folder named micro-os-plus linked to WORKSPACE_LOC/micro-os-plus.
get Release-AVR-Configuration.xml
click on Finish
Eventually rename the Debug/Release configurations to mark the board used.
The configuration names look like Debug-Atmel-STK525.
For environments that do not support additional build steps, like Avr32, you can manually configure a command to generate the disassembler output.
To access the Post build steps, select the desired project (minimal, for example), and go to the
Eclipse menu: Project → Properties
avr32-objdump -h -S ${BuildArtifactFileBaseName}.elf >${BuildArtifactFileBaseName}.lst
Once the project is created, the procedure to build it is:
If you missed/messed something during installation or project configuration, you might end with projects partly built.
The first thing to try after changing configuration details is to do a fresh build. For this
Eclipse menu: Project → Clean
Currently the Debug & Release configurations are almost identical, the difference is the compiler optimisation level, -O0 for Debug, -Os for Release, and the DEBUG macro definition, present only on Debug.
Although the definitions and the samples presented below are from a Windows environment, on GNU/Linux and Mac OS X they should be similar, if not identical.
Important: Please note that the preprocessor macro definitions and the Includes folders should be defined only once in the C/C++ General → Paths & Symbols page, and will automatically be used in the C/C++ Build → Settings.
For all languages
Important: Be sure you do not mark them as Workspace path. (don’t know why, it seems to be a CDT bug)
These definitions will automatically be reflected in all language C/C++ Build → Settings.
Common to all configurations:
Present only for Debug, removed from Release:
These definitions will automatically be reflected in all language C/C++ Build → Settings.
Debug level: Maximum (-g3) ⇐ for Debug | Default (-g) ⇐ for Release |
Optimization level: None (-O0) ⇐ for Debug | Optimize size (-Os) ⇐ for Release |
Optimization level: None (-O0) ⇐ for Debug | Optimize size (-Os) ⇐ for Release |
The configuration for the linker script files is currently preliminary and might require further updates. For more flexibility, required for example when the flash image should be moved to higher addresses to reserve space for a custom bootloader, the script is split in two parts, one containing the memory definitions, placed in the board folder, and one common to all boards, placed in the arch folder, dynamically included in the first one at link time.
Currently the Debug & Release configurations are almost identical, the difference is the compiler optimisation level, -O1 for Debug, -Os for Release, and the DEBUG macro definition, present only on Debug. (O1 is used since, according to some old tests, O0 did not work).
Although the definitions and the samples presented below are from a Windows environment, on GNU/Linux and Mac OS X they should be similar, if not identical.
Important: Please note that the preprocessor macro definitions and the Includes folders should be defined only once in the C/C++ General → Paths & Symbols page, and will automatically be used in the C/C++ Build → Settings.
For all languages
Important: Be sure you do not mark them as Workspace path. (don’t know why, it seems to be a CDT bug)
These definitions will automatically be reflected in all language C/C++ Build → Settings.
Common to all configurations:
Present only for Debug, removed from Release:
These definitions will automatically be reflected in all language C/C++ Build → Settings.
(this reference is necessary indirectly, to save files opened from the system project)
Click on the Target Hardware and set the MCU Type and the MCU Clock Frequency. (The clock frequency is currently not used in the build).
Generate Debugging Info: Extra debugging info (-g3) ⇐ for Debug | Standard debugging info (-g2) ⇐ for Release |
Generate Debugging Info: Extra debugging info (-g3) ⇐ for Debug | Standard debugging info (-g2) ⇐ for Release |
Optimization level: Slight Optimizations (-O1) ⇐ for Debug | Optimize size (-Os) ⇐ for Release |
Generate Debugging Info: Extra debugging info (-g3) ⇐ for Debug | Standard debugging info (-g2) ⇐ for Release |
Optimization level: Slight Optimizations (-O1) ⇐ for Debug | Optimize size (-Os) ⇐ for Release |
Currently the Debug & Release configurations are almost identical, the difference is the compiler optimisation level, -O0 for Debug, -Os for Release, and the DEBUG macro definition, present only on Debug.
Although the definitions and the samples presented below are from a Windows environment, on GNU/Linux and Mac OS X they should be similar, if not identical.
Important: Please note that the preprocessor macro definitions and the Includes folders should be defined only once in the C/C++ General → Paths & Symbols page, and will automatically be used in the C/C++ Build → Settings.
BOARD=ATMEL_EVK1104
DBGDEV=I2C
For all languages
Important: Be sure you do not mark them as Workspace path. (don’t know why, it seems to be a CDT bug)
These definitions will automatically be reflected in all language C/C++ Build → Settings.
Common to all configurations:
Present only for Debug, removed from Release:
These definitions will automatically be reflected in all language C/C++ Build → Settings.
Optimization Level: None (-O0) ⇐ for Debug | Optimize for size (-Os) ⇐ for Release |
Generate Debugging Info: Maximum (-g3) ⇐ for Debug | Default (-g) ⇐ for Release |
Optimization level: None (-O0) ⇐ for Debug | Optimize size (-Os) ⇐ for Release |
Generate Debugging Info: Maximum (-g3) ⇐ for Debug | Default (-g) ⇐ for Release |
Debug Level: Maximum (-g3) ⇐ for Debug | Default (-g) ⇐ for Release |
Click on the Target Device and set the MCU Type.
A sample build output on Windows looks like this:
**** Build of configuration Debug-Olimex-STM32-H103 for project minimal ****
cs-make all
Building file: H:/My Files/MacMini Vault/Projects/Eclipse Workspaces/36 Win/uOS Dev 2/system/portable/tasks/src/CANLeds.cpp
Invoking: ARM Sourcery Windows GCC C++ Compiler
arm-none-eabi-g++ -DDEBUG=1 -DOS_CONFIG_DEBUG_DEVICE_I2C=1 -D"OS_CONFIG_BOARD_OLIMEX_STM32_H103=1"
-I"H:/My Files/MacMini Vault/Projects/Eclipse Workspaces/36 Win/uOS Dev 2/minimal/include"
-I"H:\My Files\MacMini Vault\Projects\Eclipse Workspaces\36 Win\uOS Dev 2/system" -O0 -Wall
-Wa,-adhlns="system/portable/tasks/src/CANLeds.o.lst" -fno-exceptions -fno-rtti -c -fmessage-length=0
-MMD -MP -MF"system/portable/tasks/src/CANLeds.d" -MT"system/portable/tasks/src/CANLeds.d"
-mcpu=cortex-m3 -mthumb -g -gdwarf-2 -o"system/portable/tasks/src/CANLeds.o"
"H:/My Files/MacMini Vault/Projects/Eclipse Workspaces/36 Win/uOS Dev 2/system/portable/tasks/src/CANLeds.cpp"
Finished building: H:/My Files/MacMini Vault/Projects/Eclipse Workspaces/36 Win/uOS Dev 2/system/portable/tasks/src/CANLeds.cpp
...
Building target: minimal.elf
Invoking: ARM Sourcery Windows GCC C++ Linker
arm-none-eabi-g++
-T"H:\My Files\MacMini Vault\Projects\Eclipse Workspaces\36 Win\uOS Dev 2\system\hal\boards\Olimex\stm32_h103\stm32_h103_rom.ld"
-nostartfiles -Xlinker --gc-sections -Xlinker --print-gc-sections
-L"H:\My Files\MacMini Vault\Projects\Eclipse Workspaces\36 Win\uOS Dev 2\system"
-Wl,-Map,minimal.map -Xlinker --cref -mcpu=cortex-m3 -mthumb -g -gdwarf-2 -o"minimal.elf"
./system/portable/tasks/src/CANLeds.o ./system/portable/tasks/src/TaskBlink.o ./system/portable/tasks/src/TaskPitpalac.o
./system/portable/stdlib/src/ios.o ./system/portable/stdlib/src/iostream.o ./system/portable/stdlib/src/istream.o
./system/portable/stdlib/src/ostream.o ./system/portable/stdlib/src/streambuf.o ./system/portable/misc/src/CircularBlockBuffer.o
./system/portable/misc/src/CircularByteBuffer.o ./system/portable/misc/src/Parser.o ./system/portable/misc/src/SimpleCli.o
./system/portable/misc/src/uOS.o ./system/portable/kernel/src/OS.o ./system/portable/kernel/src/OSEventFlags.o
./system/portable/kernel/src/OSMutex.o ./system/portable/kernel/src/OSScheduler.o ./system/portable/kernel/src/OSTask.o
./system/portable/kernel/src/OSTaskIdle.o ./system/portable/kernel/src/OSTimer.o ./system/portable/kernel/src/OSTimerSeconds.o
./system/portable/kernel/src/OSTimerTicks.o ./system/portable/kernel/src/Timer.o ./system/portable/kernel/src/ostream_OSTask.o
./system/portable/devices/usb/src/OSUsbDevice.o ./system/portable/devices/usb/src/OSUsbDeviceDescriptors.o
./system/portable/devices/sdi12/src/SDI12BootLoader.o ./system/portable/devices/sdi12/src/SDI12Sensor.o
./system/portable/devices/misc/src/DeviceLM74.o ./system/portable/devices/misc/src/DeviceMCP2510.o
./system/portable/devices/misc/src/DeviceRTC4574.o ./system/portable/devices/misc/src/DeviceSPIUsart.o
./system/portable/devices/misc/src/PinChangeDispatchers.o ./system/portable/devices/debug/src/DeviceDebugI2C.o
./system/portable/devices/debug/src/OSDeviceDebug.o ./system/portable/devices/character/src/DeviceCharacterMultiUsart0.o
./system/portable/devices/character/src/DeviceCharacterMultiUsart1.o ./system/portable/devices/character/src/DeviceCharacterUsart.o
./system/portable/devices/character/src/DeviceCharacterUsart0.o ./system/portable/devices/character/src/DeviceCharacterUsart1.o
./system/portable/devices/character/src/DeviceCharacterUsb.o ./system/portable/devices/character/src/OSDeviceCharacter.o
./system/portable/devices/character/src/OSDeviceCharacterBuffered.o ./system/portable/devices/block/src/CANPacket.o
./system/portable/devices/block/src/DeviceMemCard.o ./system/portable/devices/block/src/DeviceMemCardSPI.o
./system/portable/devices/block/src/OSDeviceCAN.o ./system/hal/boards/Metrilog/m512/src/SDI12Sensor_Implementation.o
./system/hal/arch/avr/kernel/src/OSScheduler_Implementation.o ./system/hal/arch/avr/kernel/src/OSTimer_Implementation.o
./system/hal/arch/avr/kernel/src/OS_Implementation.o ./system/hal/arch/avr/kernel/src/ostream_ProgramPtr.o
./system/hal/arch/avr/devices/misc/src/DeviceADC_Implementation.o
./system/hal/arch/avr/devices/debug/src/OSDeviceDebug_Implementation.o
./system/hal/arch/avr/devices/character/src/DeviceCharacterMultiUsart0_Implementation.o
./system/hal/arch/avr/devices/character/src/DeviceCharacterMultiUsart1_Implementation.o
./system/hal/arch/avr/devices/character/src/DeviceCharacterUsart0_Implementation.o
./system/hal/arch/avr/devices/character/src/DeviceCharacterUsart1_Implementation.o
./system/hal/arch/avr/devices/character/src/DeviceCharacterUsart_Implementation.o
./system/hal/arch/avr/devices/block/src/DeviceCAN_MCP2510.o
./system/hal/arch/avr/at90usb/devices/usb/src/OSUsbDevice_Implementation.o
./system/hal/arch/avr/at90usb/devices/character/src/DeviceCharacterUsb_Implementation.o
./system/hal/arch/avr/at90can/devices/block/src/DeviceCAN_AT90CAN.o
./system/hal/arch/arm_cortex_m3/stm32f10x/lib/src/system_stm32f10x.o
./system/hal/arch/arm_cortex_m3/stm32f10x/kernel/src/OS_Family_Implementation.o
./system/hal/arch/arm_cortex_m3/lib/src/core_cm3.o
./system/hal/arch/arm_cortex_m3/kernel/src/OSScheduler_Arch_Implementation.o
./system/hal/arch/arm_cortex_m3/kernel/src/OSTimer_Arch_Implementation.o
./system/hal/arch/arm_cortex_m3/kernel/src/OS_Arch_Implementation.o
./system/hal/arch/arm_cortex_m3/devices/debug/src/OSDeviceDebug_Arch_Implementation.o ./src/main.o
Finished building target: minimal.elf
Invoking: ARM Sourcery Windows GNU Create Flash Image
arm-none-eabi-objcopy -O ihex minimal.elf "minimal.hex"
Finished building: minimal.hex
Invoking: ARM Sourcery Windows GNU Create Listing
arm-none-eabi-objdump -h -S minimal.elf >"minimal.lst"
Finished building: minimal.lst
Invoking: ARM Sourcery Windows GNU Print Size
arm-none-eabi-size --format=berkeley minimal.elf
text data bss dec hex filename
12356 672 600 13628 353c minimal.elf
Finished building: minimal.siz