Add a sample that demonstrates a custom board definition. This proves
that BOARD_ROOT works and can be a useful reference when creating a
custom board definition.
Instead of spending time making up a board, the nrf52840_pca10056
board has been copied as-is. And the hello world sample has been used
as the basis for the application.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Single backslashes outside of a code-block are treated as escape
characters, so need to double up to get a single backslash rendered in
the generated HTML.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Edits and additions for clarity and correctness, based on the current
contents of the file (dts.cmake) which controls the DTS build.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This is one way we can support out of tree board definitions. Basically
all this needs is a board definition in the application source directory
that follows the same structure we have in the main Zephyr tree (also
allowing multiple custom boards). An application tree would look like
this for example:
boards/
CMakeLists.txt
prj.conf
README.rst
src/
with boards following the same structure as in Zephyr:
.
├── boards
│ └── x86
│ └── arduino_101
│ ├── doc
│ │ └── img
│ └── support
└── src
To use this, you need to specify the BOARD_ROOT variable on the command
line when building:
cmake -DBOARD=<board name> -DBOARD_ROOT=<path to boards> ..
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
When the Kconfig BOOTLOADER_MCUBOOT is selected, an overlay to place the
image at the slot0 location is required. In order to avoid having to do
this manually for all samples when targetting MCUboot, include the logic
inside the dts.cmake script to prepend a new common.dts file that then
conditionally includes mcuboot.overlay.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
This patch changes the manner in which we collect DTS overlay files so
that they comply with the same approach taken for configuration fragment
files (.conf).
Additionally it also documents the usage of those files in the
Application Developer Guide.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Rework the Application Development Primer so that it describes the
differences between UNIX and Windows builds and uses Ninja by default,
in order to be compatible with all of them.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The APPLICATION_BASE variable in the example Kconfig file was copied
in from an (out of tree) application which relied on it during the
Kbuild days, but it's actually not needed by the CMake build system
and should be removed.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
installed GDB on host might not be compatible with the binary generated
by Zephyr. Mention that we need to use the gdb that corrosponds to the
toolchain being used.
Fixes#4312
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The line between Zephyr versus application is blurry since they share
a configuration, but try to disambiguate.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The documentation regarding application-specific Kconfig options is
unclear. Fix that.
Reported-by: David Kinder <david.b.kinder@intel.com>
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
The ELF format and extension is an acronym that needs a
definition. Add it.
Reported-by: David Kinder <david.b.kinder@intel.com>
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Grammatical fixes caught in review of unrelated changes.
Reported-by: David Kinder <david.b.kinder@intel.com>
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Fix the instructions for when an alternate CONF_FILE is used.
Reported-by: David Kinder <david.b.kinder@intel.com>
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Re-work this section for clarity, making it clearer where the division
between emulated and real hardware is, and cleaning up the
instructions. Also re-work for correctness, updating Kbuild-style
flash instructions to use CMake.
Also make sure users know they can flash and run from anywhere on the
system using cmake --build.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Fix the white space around "Naming Conventions", which is currently
appearing on its own line.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
This document's flow could be improved a bit. The overview section is
followed by somewhat dense reference material, which is then followed
by step-by-step instructions central to the application workflow.
Fix this up by moving the details to the end, and adjusting the
transitions between the sections a bit.
The diff looks like a mess, but this commit is mostly just moving
things around. There are also various grammar fixes incorporated from
review.
Reviewed-by: David Kinder <david.b.kinder@intel.com>
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
squash! doc: application: move build/run/debug docs after overview
Make this a bit less Unix-centric, changing the CMake invocation lines
to only use documented parameters that continue to work across all
CMake versions (-B doesn't work everywhere, and -H means "help" in
recent versions of CMake).
Handle some 80-column cleanliness. Add documentation about the search
key, /. Be a bit more explicit about the steps.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Now that the above sections more clearly define the behavior of
CONF_FILE, the section on writing a .conf can be cleaned up and made
into a simple primer on syntax.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Fix a few issues related to the description of an application's
CMakeLists.txt file, and how that relates to its configuraiton.
Make sure the section "Application CMakeLists.txt" appears under the
parent "CMake" section, instead of on its own. The order in which
lines appear in the application CMakeLists.txt is important, and
that's not coming through clearly, so try to improve that. Document
how the values for BOARD and CONF_FILE are determined by
boilerplate.cmake here. Also document usage of KCONFIG_ROOT, as its
Kbuild-based equivalent is something that users ask about.
Merge some content from the following section "Application
Configuration" into the appropriate places, to keep the document flow
working. Add references in "Application Configuration" to definitions
provided previously in the document, for clarity.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Update the initial application overview and the basic "how to create
an application" sections for the CMake transition. This is worth doing
on its own, and also enables other fixes and improvements to below
sections.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Update the versions of tools used to generate documentation locally and
include a description of the message filtering now included in the doc
build Makefile (formerlly only done in the CI scripts).
Also, include the documentation docs in the developer guides to help
folks that want to contribute and generate docs locally.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
fixed error introduced in application.rst (v1.8) along with a general
spelling check pass including consistent spelling of "runtime" and
hyphenated words with "pre-"
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Simplify top-level table of contents and create the user guide which
includes the application development primer and other guides and
refereces instead of having them at the top-level.
Also move glossary section away from top-level TOC and remove broken
search link.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add cross-referenced information on the 96b_carbon and
96b_carbon_nrf51 pages which disambiguates between the two "boards".
Also describe how to flash 96b_carbon_nrf51 with
samples/bluetooth/hci_spi and 96b_carbon with samples/bluetooth/ipsp
to support a Bluetooth HCI stack on 96Boards Carbon (the physical
board).
While we're here, make the documentation page for 96b_carbon match the
format in doc/templates/board.tmpl.
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Add a sample application that allows a Zephyr-based Bluetooth
controller to interface with an HCI driver via SPI. This sample
implements the same BT SPI protocol already as Zephyr's HCI SPI
driver.
Currently, the sample only supports the legacy SPI API.
Provide a single configuration file, avoiding board-specific
files. Some board-specific configuration information must be provided
via other means:
- CONFIG_BT_CONTROLLER_TO_HOST_SPI_DEV_NAME
- CONFIG_BT_CONTROLLER_TO_HOST_SPI_IRQ_DEV_NAME
- CONFIG_BT_CONTROLLER_TO_HOST_SPI_IRQ_PIN
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Signed-off-by: Marti Bolivar <marti.bolivar@linaro.org>
Signed-off-by: Michael Scott <michael.scott@linaro.org>
More general spelling fixes, and cleaning up stray UTF-8 characters
such as curly-quotes, em- and en-dashes. Use replacement strings
for |reg| and |trade|.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
