Overview
But a genius doesn’t work on an assembly line basis. Did Einstein, Kazanga, or… or Sitar of Vulcan produce new and revolutionary theories on a regular schedule? You can’t simply say, "Today I will be brilliant".
Star Trek 2:24 - The Ultimate Computer
| The tutorials are Work In Progress… |
Bootstrapping a Core distribution
Overview
In this tutorial we will learn how to bootstrap a Core distribution.
Step I: Install Core
$ mkdir ~/core-sdk (1) $ cd ~/core-sdk $ wget -qO- http://get-core.novalabs.io/ | sh (2)
| 1 | ~/core-sdk will be the Core distribution installation folder |
| 2 | here the magic happens |
| The installation script will ask you to give him either the root or sudo password. Do not worry: it is just to install the prerequisites (here there are the details). |
Step II: setup the Core environment
To setup the Core environment some environment variables needs to be configured in order to let the build system find tools and sources.
$ cd ~/core-sdk $ source core/setup.sh (1)
| 1 | sets the needed environmental variables |
Environmental variables must be set in each terminal, to avoid sourcing setup.sh in every new terminal you can add a line to your ~/.bashrc file: echo source ~/core-sdk/core/setup.sh >> ~/.bashrc
|
Working with the workspace
Overview
In this tutorial we will learn how to use the CLI tools to manage a workspace.
Step I: initialization
A workspace is nothing but a structured directory with a JSON file inside (here there are the details).
To create the structure and the JSON file the CoreWorkspace.py initialize command is provided.
$ mkdir my_workspace $ cd my_workspace $ CoreWorkspace.py initialize
The expected output is:
Workspace initialized. You can now do a 'source setup.sh' SUCCESS
The workspace now contains the following folders:
. ├── build │ ├── debug │ ├── params │ └── release ├── generated │ ├── modules │ ├── packages │ └── params ├── setup.sh ├── src │ ├── modules │ ├── packages │ ├── params │ └── targets └── WORKSPACE.json
A setup.sh file is also generated. This files sets the environments variable needed by the workspace. It includes the Core setup.sh file, so you just need to source it.
use the --force option to re-create the JSON and setup.sh files, without touching the contents of the workspace. It is useful, for example, if you move either the Core distribution or the workspace.
|
Step II: add a target
An empty workspace is pretty useless, so the first thing to do is to add a target to it (here there are the details).
To add a target to the workspace the CoreWorkspace.py target add command is provided. The first parameter specifies the target type (i.e., the Core module to which the code will be deployed), while the second parameter specifies the name of the target instance in your workspace (i.e., motor_test)
$ source setup.sh $ CoreWorkspace.py target add udc motor_test
The expected output is:
Using Core module 'udc' SUCCESS
The workspace content now is:
. ├── build │ ├── debug │ ├── params │ └── release ├── generated │ ├── modules │ ├── packages │ └── params ├── setup.sh ├── src │ ├── modules │ ├── packages │ ├── params │ │ └── motor_test │ │ └── default.json │ └── targets │ └── motor_test │ ├── main.cpp │ ├── MODULE_TARGET.json │ ├── PARAMETERS.default.json │ └── PARAMETERS.json └── WORKSPACE.json
Step III: inspecting the workspace
Now we have something in the workspace. But what do we have exactly?
To inspect the content of a workspace the CoreWorkspace.py ls command is provided.
It lists the content of the workspace, and all the dependencies needed to build it.
$ CoreWorkspace.py ls
The expected output is:
= WORKSPACE == PARAMETERS Type: motor_test Name: uDC module template configuration Description: src/targets/motor_test == PACKAGE DEPENDENCIES Package: MC33926_driver Source: Core Notes: Package: QEI_driver Source: Core Notes: ... == MODULE DEPENDENCIES Module: udc Source: Core Notes: == MODULE TARGETS Type: application Name: motor_test Description: motor_test Module: udc OS Version: CHIBIOS_16 Root: src/targets/motor_test Status: OK == PARAMETER TARGETS Name: default Description: Default configuration Parameters: motor_test Root: src/params Status: OK SUCCESS
Step IV: generate
Now that we have a workspace and a target, it is time to generate the corresponding files: the code, CMake files, Documentation, Eclipse project.
To generate the code CoreWorkspace.py generate command is provided.
All the generated files will be inside the generated directory.
$ CoreWorkspace.py generate
The command output shows details about allgenerated code.
Step V: build
Now that we have the generated source code, we can build the targets.
To build a target, you must call make from its build directory.
$ cd build/debug/motor_test $ make
The output will show the compile process, and a successfull build will finish with:
[100%] Linking CXX executable firmware [100%] Built target firmware
Setting up the Eclipse IDE
Overview
In this tutorial we will learn how to install and configure Eclipse to program and debug Core targets.
Step I: installation
Download the latest "Eclipse IDE for C/C++ Developers" release from the Eclipse website.
Extract the archive content in a folder of your choice, for example ~/core-sdk/eclipse.
Step II: additional plugins
To work with embedded targets Eclipse needs a plugin which interfaces to OpenOCD, the JTAG debugger.
This plugin is called "GDB Hardware" and can be installed with the Eclipse software manager.
Start Eclipse and clic on the Help menu to select "Install New Software…"
From the "Work with" dropdown menu select "CDT - …" as Software Site, and wait for Eclipse to download the available packages (it takes about one minute).
Then search for "gdb" and wait for Eclipse looking for it (it takes some time again).
Finally flag the "C/C++ GDB Hardware Debugging" package in the "CDT Optional Features" group and start the installation by clicking "Next".
During the installation process you will be asked to agree with the License and at the end Eclipse will restart.
Step III: import projects
Eclipse is now ready to import the projects generated by the CoreWorkspace.py command in the previous tutorials.
To import projects, select the "File" menu and clic on "Import…".
In the import window, select "Existing Projects into Workspace" in the "General" group.
In the "Select root directory" field clic "Browse" and select the src directory inside your workspace.
You will see one Eclipse project for each target in the workspace, flag the ones you want to import.
Step IV: build targets
Eclipse is now ready to build the projects we imported.
First of all, select the "motor_test" project and open the "main.cpp" source file.
| You may notice that several lines are underlined in red/yellow by Eclipse, because it has to index source files from the Core distribution. Don’t worry, this will be solved by the very first build! |
Now clic on the hammer icon and select "Debug" or "Release" to build the corresponding firmware
Step V: setup OpenOCD
The last step before flashing and running the firmware is to setup OpenOCD, the program which acts as interface between the JTAG probe hardware and GDB, the GNU Debugger.
To setup OpenOCD, clic on the "External tools" icon and select "External Tools Configurations…"
Now clic add a new launch configuration, call it "OpenOCD (STLink-v2)" and enter the openocd executable location (it is usually located under /usr/bin/openocd) and copy and paste the following line in the "Arguments" field.
-c "telnet_port 4444" -f "interface/stlink-v2.cfg" -f "${file_prompt:Select target configuration file:/usr/share/openocd/scripts/target/stm32f3x.cfg}"
These arguments tell OpenOCD to use the STLink-v2 as interface (modify it if you use another JTAG probe) and opens a window popup to select the target microcontroller (the default is STM32F3).
Finally, clic on the "External tools" icon and select "OpenOCD (STLink-v2)", then select stm32f3x.cfg as target configuration.
In the console window you will see the output of OpenOCD, telling us that it found an STM32 microcontroller.
Step VI: flash and run the firmware
We are now ready to flash and run the firmware.
From the "Debug" icon select "motor_test-Debug" to flash the debug build, or "motor_test-Release" to flash the release build.
Eclipse will change perspective, showing the debug layout, and as soon as the firmware is flashed (it take some seconds) it will open the main.cpp file at its entry point (the beginning of the main() function).
Clic on the "Resume" icon to start the firmware.
Step VII: debug the firmware
TODO