Replace sample code, making it use newest USB API, reading code
directly from sources, and changing to the simplest sample - loopback.
CDC ACM is quite big and modifying sample would render line change
quite often.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Extended logger to support optional log message prepending with
function name.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Prepend the btmgmt call with the tools/ subdirectory to line up with
the other BlueZ tool calls in the examples.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Normalize the path of ignored folders so that variations in paths
formats on Windows are detected correctly.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
- Fix a few errors and bits of stale information in "Creating an
Application", also adding additional cross-references.
- Consolidate some of the steps to help users create CMakeLists.txt
correctly by unambiguously putting target_sources() after the
boilerplate include.
- Split the description of the important build system variables into
its own section and add more context for what they do.
- Add whitespace warning
Signed-off-by: Marti Bolivar <marti@foundries.io>
Put the Developer Guides after the Getting Started guide, and make
sure the Application Development Primer is the first item in the
Developer Guides. Make some other ordering adjustments as well.
These changes collectively make for a more logical order for linearly
reading through the Zephyr documentation for the average user.
"Average user" here is defined as a person who wants to:
1. learn what Zephyr is and its distinguishing features
2. install a Zephyr development environment, building/running hello
world
3. learn the basics of how Zephyr applications are structured
4. start diving deeper
This privileges "users" over "developers", i.e. it pushes sections
related to Zephyr's internals and how to edit them down lower in the
order.
Signed-off-by: Marti Bolivar <marti@foundries.io>
The getting started documentation has become a bit of a mess over
time:
- The reader needs to jump forward and backward in the documents
depending on what their system already has installed (e.g. "start by
cloning Zephyr, oh wait, see below if you don't have Git yet" etc.).
- The operating system setup guides, toolchain setup instructions, and
application build and run information have each become their own
balkanized fiefdom, with duplicated, confusing and sometimes
inconsistent results.
- Linux documentation for all distributions is incomplete in some
places (the Arch documentation in particular is vestigial)
and wrong in others (platforms like Ubuntu still nominally require
tools, like autoconf, that haven't been necessary since we stopped
using the C Kconfig tools)
- The dependencies needed to build the documentation have
gotten *huge* since the LaTeX additions and massively overstate the
footprint of Zephyr's real dependencies. This is particularly a
problem on Linux, where those dependencies were not clearly
separated from those needed to build Zephyr.
- The toolchain setup documentation is confusing and scattered across
the main file and the platform-specific files. There are various
bits of incomplete and/or incorrect information. For example, the
docs imply that you can use the Zephyr SDK on non-Linux hosts, which
isn't true. As another example, some toolchains, such as GNU Arm
Embedded, are documented several times. As a final example, some
toolchains, such as Intel's ISSM, are squirrelled away in the
Windows document when there are Linux builds available.
Overhaul the pages to fix these issues and otherwise clean up the
language. One significant side-effect is that all the
toolchain-related information is rooted in a single toctree. Another
is that it should now be possible to follow the instructions, in
order, on any supported platform.
Signed-off-by: Marti Bolivar <marti@foundries.io>
I committed a user error and edited a file named in the sphinx output
to correct an error. To my dismay later, I discovered my work had been
lost as that file is not versioned.
Warn the others.
Signed-off-by: Marti Bolivar <marti@foundries.io>
In a clean build, Ninja is creating copies of the extracted
documentation outputs regardless of whether they already exist or
not. I can't explain this behavior from the documentation of the build
command, but it's so, even if extract_content.py is patched to use
copyfile() instead of copy2() so that outputs (copied .rst files in
the build directory) have strictly newer mtimes than inputs (source
tree .rst files).
This extra copying doesn't happen for incremental builds, for some
reason.
To account for this behavior, add and use an extract_content.py option
that skips content extraction completely and leaves that all up to the
add_custom_command() which tracks each individual input->output build
command.
Reported-by: Carles Cufi <carles.cufi@nordicsemi.no>
Signed-off-by: Marti Bolivar <marti@foundries.io>
Remove redundant 'sample' tag and add something that matches the
functionality and features being tested, demonstrated.
Avoid short abbriviations and using full names for fs.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Most of time (i.e. when just writing to .rst files or editing images,
rather than editing Doxygen or Kconfig), a full rebuild of the docs
pipeline is not necessary.
This is unfortunate, because it takes over a minute to re-run doxygen
etc. (on my system), whereas an incremental sphinx-build run should
only take a few seconds.
As a band-aid to help developers who have already generated a docs
build and know the consequences of their actions, add "sphinx-html"
and "sphinx-latex" targets. These just re-extract content files into
the build directory and run sphinx-build. This makes for much faster
documentation edit/compile/read loops.
Add some extra COMMENTs while we're here, to make it more obvious
what's going on when the docs build system crunches on something.
A "proper" solution for changing "ninja html" to have similar
performance would need, at least, to:
- only re-run doxygen if any source files have changed
- only re-generate Kconfig if any of those files have changed
That's all left to future work, as this is good enough to make
rebuilding the docs bearable for me.
Signed-off-by: Marti Bolivar <marti@foundries.io>
The logic which copies source documentation files into the build
directory could use some improvements to its dependency management, so
that when a source file changes, extract_content.py gets re-run.
Make these changes as follows:
- Add an --outputs flag to extract_content.py, so that the
sources it depends on and generates can be saved into a file and
thus made known to the build system
- Change the way the sources and destination are specified in the
extract_content.py command line so that the entire job can be done
in a single command, rather than multiple (to avoid having to
collate multiple --outputs files in CMake)
- Extract the content at configure time with execute_process(),
tracking all inputs and outputs within the build system itself. Use
this information to make sure that each individual output depends on
just its exact input file, ensuring updated inputs produce updated
outputs without having to call extract_content.py again.
- Ensure that the "content" build system target depends on all the
outputs, transitively triggering a rebuild any time an input
file (e.g. .rst documentation file or included image/source file)
changes.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Separate the phases of creating the list of outputs (and output
directories) from the actual creation of these outputs. This lays the
groundwork for just printing the inputs and outputs in a subsequent
patch, enabling CMake to track dependencies properly.
In the now-separate output generation phase, use shutil.copy2() to
preserve metadata like access and modification times when possible,
rather than re-reading every file and seeing if the contents are
different. This has the same semantics but is clearer and potentially
more efficient, as the initial copies have more accurate relative
timestamps.
Signed-off-by: Marti Bolivar <marti@foundries.io>
Minor cleanups:
- Allow the user to run extract.content.py -h with ZEPHYR_BASE unset
without crashing
- Replace the use of the ZEPHYR_BUILD environment variable with an
--ignore argument (that can be given multiple times) which specifies
a path to a directory whose files should *not* be copied, and use
it to ignore the build directory
- rename, reorder, and tweak get_files() arguments a bit to go from
source to dest, with extra configuration at the end, getting rid of
local shadowing of global built-in functions
Signed-off-by: Marti Bolivar <marti@foundries.io>
Extended macro to accept flag indicating if given backend must be
initialized and enabled when log subsystem starts. Typically, simple
backends will have autostart flag set. More complex may require
explicit enabling (e.g. shell over BLE can only be enabled when
BLE connection is established).
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
User do not need to initialize shell instance manually now
and this change has been reflected in the documentation.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
Document how to use harness and it's various configurations
such as type, regex and fixture that can be used to pick specific
board setup that fulfills external dependency for test case.
Signed-off-by: Praful Swarnakar <praful.swarnakar@intel.com>
The $srctree environment variable gives the path relative to which
'(o)source' statements work (the current directory is used if $srctree
is unset). It is set to $ZEPHYR_BASE in cmake/kconfig.cmake, so there's
no need to qualify the source of Kconfig.zephyr in sample Kconfig files
(or in external projects).
All 'source's in Zephyr assume that the Zephyr root directory is used as
the srctree as well, and would break otherwise.
Remove the $(ZEPHYR_BASE)s to make it clearer that all 'source'
statements work relative to the Zephyr root. There was some user
confusion on IRC.
Also explain how things work in the documentation.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Update menuconfig (and Kconfiglib, just to sync) to upstream revision
256e5b3e38e92 to get the fix below in, for an issue in an external
project. Also update genrest.py with a similar fix (the genrest issue
was what originally prompted it).
menuconfig: Improve/fix promptless choice handling
The code assumed that all parent (interface) menus always have a
prompt, which is false for items in promptless choices. This led to
a crash e.g. when viewing the symbol information for a symbol within
a promptless choice.
Promptless choices with children can show up "legitimately" when
people define choices in multiple locations to add symbols, though
this is broken in the C tools.
Use standard_sc_expr_str(node.item) instead of the non-existing
prompt for promptless choices. That way they show up as
'<choice (name if any>)>', which is consistent with how they're
shown elsewhere.
This commit also changes how choice names are displayed in
show-name/show-all mode, to the standard_sc_expr_str() format.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Extended ring buffer to allow storing raw bytes in it. API has been
extended keeping 'data item' mode untouched.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Deprecate API prefixed with sys_ring_buf_ and rename it
to ring_buf_item_ since this API is not a typical ring buffer
but ring buffer of data items (metadata + 32bit words).
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Add a new optional TOOLCHAIN_ROOT cmake and environment variable to
specify an alternative location for toolchain cmake files.
When set, Zephyr will look for a toolchain cmake file located in:
${TOOLCHAIN_ROOT}/cmake/toolchain/${ZEPHYR_TOOLCHAIN_VARIANT}.cmake
Signed-off-by: François Delawarde <fnde@oticon.com>
The Zephyr configuration system uses many different files in many
different formats. It makes it a lot easier for users to understand
what these files do if when we use the correct file extensions.
To this end we rename the dts.fixup files to the correct file
extension '.h'.
This is a breaking change for out-of-tree fixup files. Such files will
be detected and given an appropriate error message.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Shell macro SHELL_DEFINE no longer needs new line character.
Specification has been updated accordingly.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
Add a section to optionally install the Chocolatey packages required to
build the documentation in .pdf format on Windows.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
In order to make PDF generation work on Windows, search for a generic
Latex package and use full quotes for the latexmk environment variable.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Extending logger to support logging transient strings (with %s).
With dedicated call (log_strdup), string is duplicated to a buffer
from internal logger pool. Logger implicitly manages the pool.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
The documentation has been setting the environment variable
KERNELVERSION to the PROJECT_VERSION of the documentation. But
PROJECT_VERSION is not set during the documentation build so this has
no effect.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
1. Remove old shell documentation.
2. Create documentation for new shell module.
3. Fix shell.h comments to be able to generate
API documentation.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
The board porting guide assumed that people were already familiar with
the Kconfig 'bool "foo"' shorthand for giving a symbol's type and prompt
at the same time. I got an email pointing out that it isn't obvious.
Explain the shorthand, and also mention that it's the preferred style in
Zephyr.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The following error appeared on documentation builds when enabling the
USES_TERMINAL flag:
USES_TERMINAL may not be specified without any COMMAND
This is because targets without a command should not be using the flag
at all, so remove its usage from those. Instead, use it in the
add_custom_command() that actualy invokes sphinx.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
PR #10216 hit a doxygen/breathe known issue that is worked around by
adding an entry to the doxygen configuration to treat BUILD_ASSERT() as
a predefined macro.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Update to the latest west. This includes a new 'attach' command. There
are also multi-repo commands, but those won't get exposed to the user
unless they install Zephyr using "west init" + "west fetch" (and not,
say, "git clone").
Replace the launchers; they now detect whether zephyr is part of a
multi-repo installation, and run the west code in its own repository
if that is the case.
This also requires an update to:
- the flash/debug CMakeLists.txt, as the new west package is no longer
executable as a module and must have its main script run by the
interpreter instead.
- the documentation, to reflect a rename and with a hack to fix
the automodule directive in flash-debug.rst for now
Signed-off-by: Marti Bolivar <marti@foundries.io>
Automatically detect the Kconfig file in it's conventional placement
${APPLICATION_SOURCE_DIR}/Kconfig and set KCONFIG_ROOT accordingly.
'Convention over configuration' is an imporant principle for
minimizing metadata and keeping things consistent. We use this
principle for instance with the file prj.conf.
This commit applies this principle to also re-direrct KCONFIG_ROOT.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Andrei Emeltchenko