Building with ARM-GCC
You can build your BLE projects using offline toolchains.
Building offline with actual sources - as opposed to using the online IDE or linking against pre-built libraries - allows for fine-grained control and supports a much better debugging experience. It is also a good learning experience to set up one of these.
Here's a complete setup for a Bluetooth-smart demo application built using ARM-GCC and CMake. Various people have contributed to it; many thanks go to Sandeep SS for contributing a working example of a build system.
Selecting a Toolchain
There are several license-free toolchains for ARM Cortex-M cross-compilation. We chose GCC ARM Embedded as the toolchain, and CMake as a cross-platform build-system generator.
Cmake is a very mature and highly configurable cross-platform build system supported by good documentation. It abstracts a Makefile-like build system.
Installations
Packages and Directories
The following instructions apply to a Ubuntu development machine. You might want to install the following Debian packages since they'll be needed later:
$ sudo apt-get install build-essential
$ sudo apt-get install srecord
Create a directory to host files for your project; we'll refer to this as ``WORKSPACE_DIR``, but you can choose any name for it.
CMakeLists.txt
The ``CMakeLists.txt`` file describes the project dependencies using very simple, readable directives. It is what you would expect from a collection of toolchain-dependencies: include directories, compiler flags, sources (in C/C++ or assembly), the name of the final build target, and any custom post-build commands.
CMake is driven by a collection of ``CMakeLists.txt`` files spread across the sources. There needs to be at least one of these at the top level of the sources. Copy this ``CMakeLists.txt`` to ``WORKSPACE_DIR``. We'll work with a single ``CMakeLists.txt`` file; you can change this if needed.
CMake is far more capable than what can be gathered from this simple example. The highly readable nature of the ``CMakeLists.txt`` file works as an encouragement to refer to the documentation for CMake.
In its default state, ``CMakeLists.txt`` is meant for the [BLE Heart Rate](http://developer.mbed.org/teams/Bluetooth-Low-Energy/code/BLE_HeartRate/) demo project. You may want to update the name of the project.
Note: The default ``CMakeLists.txt`` file assumes a ``main.cpp``.
mbed SDK
All mbed applications depend on the mbed-SDK. This is a Git repository, which can be cloned as:
$ git clone https://github.com/mbedmicro/mbed.git mbed-src
I typically clone that repository as mbed-src (as shown above). The actual mbed SDK resides under the subfolder libraries/mbed within mbed-src.
Bluetooth Smart applications meant for the Nordic platform also depend on the ``BLE_API`` and ``nRF51822`` libraries.
$ git clone https://github.com/mbedmicro/BLE_API.git
$ git clone https://github.com/mbedmicro/nRF51822.git
Updating CMAKELists.txt
You’ll need to edit the ``CMakeLists.txt`` configuration to point to the correct dependencies. The following variables may need to be updated:
- MBED_SRC_PATH to point to the location of the folder called ‘mbed’ within your local clone of mbed-src repository.
- BLE_API_SRC_PATH to point to the local clone of the BLE_API repository.
- NRF51822_SRC_PATH to point to the local clone of the nRF51822 repository.
- CMAKE_CXX_COMPILER and CMAKE_C_COMPILER to point to your arm-none-eabi-g++ or gcc as appropriate.
- SIZE_COMMAND and OBJCOPY_COMMAND to point to arm-none-eabi-size and objcopy (as appropriate).Git Sources in CMakeLists.txt
If you're not building for Nordic or Bluetooth Smart, then these libraries may not apply to you at all. Please update the following as needed:
# define some more paths to projects we depend on
set (MBED_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../mbed-src/libraries/mbed)
set (BLE_API_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../BLE_API)
set (NRF51822_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../nRF51822)
The ``CMakeLists.txt`` file can be switched to using a different toolchain if you need; change the following to do that:
# Decide about the actual compilers to be used; uncomment one of the following.
set(TOOLCHAIN armgcc)
# set(TOOLCHAIN armcc)
Application Sources
Please also install the sources of your application under ``WORKSPACE_DIR`` (or any subfolder), and make sure to use one of the ``add_sources()`` directives to add your sources.
Building with CMake
CMake can drive a build to generate object files either alongside the sources or in any separate build workspace. The latter is preferable and easily accomplished:
Create a ``Build`` folder under ``WORKSPACE_DIR``.
Change the build directory to your new directory.
Run CMake, passing the path to the top level ``CMakeLists.txt`` folder as a parameter. This looks like:
WORKSPACE_DIR$ mkdir Build
WORKSPACE_DIR$ cd Build
WORKSPACE_DIR$ cmake ..
...
... a lot of useful information emitted by CMake regarding build settings
...
WORKSPACE_DIR$ make
If everything goes well with 'make', you'll end up with an executable called ``combined.hex`` that is ready to be deployed on the Nordic target. Running make with the ``VERBOSE=1`` command line option will expose the details about the commands being executed.
Mihail Konovalov.
45
replies
Rohit Grover wrote:
Building with ARM-GCC
You can build your BLE projects using offline toolchains.
Building offline with actual sources - as opposed to using the online IDE or linking against pre-built libraries - allows for fine-grained control and supports a much better debugging experience. It is also a good learning experience to set up one of these.
Here's a complete setup for a Bluetooth-smart demo application built using ARM-GCC and CMake. Various people have contributed to it; many thanks go to Sandeep SS for contributing a working example of a build system.
Selecting a Toolchain
There are several license-free toolchains for ARM Cortex-M cross-compilation. We chose GCC ARM Embedded as the toolchain, and CMake as a cross-platform build-system generator. Cmake is a very mature and highly configurable cross-platform build system supported by good documentation. It abstracts a Makefile-like build system.
Installations
Packages and Directories
The following instructions apply to a Ubuntu development machine. You might want to install the following Debian packages since they'll be needed later:
Create a directory to host files for your project; we'll refer to this as ``WORKSPACE_DIR``, but you can choose any name for it.
CMakeLists.txt
The ``CMakeLists.txt`` file describes the project dependencies using very simple, readable directives. It is what you would expect from a collection of toolchain-dependencies: include directories, compiler flags, sources (in C/C++ or assembly), the name of the final build target, and any custom post-build commands. CMake is driven by a collection of ``CMakeLists.txt`` files spread across the sources. There needs to be at least one of these at the top level of the sources. Copy this ``CMakeLists.txt`` to ``WORKSPACE_DIR``. We'll work with a single ``CMakeLists.txt`` file; you can change this if needed. CMake is far more capable than what can be gathered from this simple example. The highly readable nature of the ``CMakeLists.txt`` file works as an encouragement to refer to the documentation for CMake. In its default state, ``CMakeLists.txt`` is meant for the [BLE Heart Rate](http://developer.mbed.org/teams/Bluetooth-Low-Energy/code/BLE_HeartRate/) demo project. You may want to update the name of the project.
Note: The default ``CMakeLists.txt`` file assumes a ``main.cpp``.
mbed SDK
All mbed applications depend on the mbed-SDK. This is a Git repository, which can be cloned as:
I typically clone that repository as mbed-src (as shown above). The actual mbed SDK resides under the subfolder libraries/mbed within mbed-src. Bluetooth Smart applications meant for the Nordic platform also depend on the ``BLE_API`` and ``nRF51822`` libraries.
Updating CMAKELists.txt
You’ll need to edit the ``CMakeLists.txt`` configuration to point to the correct dependencies. The following variables may need to be updated:
If you're not building for Nordic or Bluetooth Smart, then these libraries may not apply to you at all. Please update the following as needed:
# define some more paths to projects we depend on set (MBED_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../mbed-src/libraries/mbed) set (BLE_API_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../BLE_API) set (NRF51822_SRC_PATH ${BLE_HEART_RATE_SOURCE_DIR}/../../nRF51822)The ``CMakeLists.txt`` file can be switched to using a different toolchain if you need; change the following to do that:
Application Sources
Please also install the sources of your application under ``WORKSPACE_DIR`` (or any subfolder), and make sure to use one of the ``add_sources()`` directives to add your sources.
Building with CMake
CMake can drive a build to generate object files either alongside the sources or in any separate build workspace. The latter is preferable and easily accomplished: Create a ``Build`` folder under ``WORKSPACE_DIR``. Change the build directory to your new directory. Run CMake, passing the path to the top level ``CMakeLists.txt`` folder as a parameter. This looks like:
WORKSPACE_DIR$ mkdir Build WORKSPACE_DIR$ cd Build WORKSPACE_DIR$ cmake .. ... ... a lot of useful information emitted by CMake regarding build settings ... WORKSPACE_DIR$ makeIf everything goes well with 'make', you'll end up with an executable called ``combined.hex`` that is ready to be deployed on the Nordic target. Running make with the ``VERBOSE=1`` command line option will expose the details about the commands being executed.