Provide basic commands for configuring/setting/reading GPIO ports.
> gpio conf ..
> gpio set ..
> gpio get ..
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Fix the following dts warnings:
up_squared.dts_compiled: Warning (simple_bus_reg): /soc/gpio@0:
simple-bus unit address format error, expected "d0c50000"
up_squared.dts_compiled: Warning (simple_bus_reg): /soc/i2c@91528000:
simple-bus unit address format error, expected "9158000"
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Before dtc 1.4.7 we'd get something like the following for an reg
property:
reg = <1 2 3 4>;
After dtc 1.4.7 we get:
reg = <1 2>, <3 4>;
We should handle both cases in the extract reg handling code. So if
we see a list of lists, we flatten it to a single list to normalize
the property.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Add an API for force suspending the devices. This API can be
called during unexpected system shutdown/poweroff scenarios
to safely turnoff the devices.
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
The toolchain information is using out of date (and misspelled)
environment variables. Rather than duplicate information here which is
already present in the getting started guide, just link to it.
Clean up some other docs.
Signed-off-by: Marti Bolivar <marti@foundries.io>
- 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>
1. The generator handles just the COMPILE_DEFINITIONS.
(See: __ZEPHYR_SUPERVISOR__)
For the defines in INTERFACE_COMPILE_DEFINITIONS
a special handling is necessary.
Solution:
The amendment function generates a macro header file
${CMAKE_BINARY_DIR}/zephyr/include/generated/cmake_intdef.h
based on INTERFACE_COMPILE_DEFINITIONS and appends the
defines from the file to
CMAKE_EXTRA_GENERATOR_C_SYSTEM_DEFINED_MACROS.
2. Eclipse CDT4 indexer has problems with CMake 'Eclipse CDT4 - x'
generator projects that use mixed C/C++.
The Eclipse CDT4 indexer is showing a lot of unresolved symbol
errors, when the project was created with CMake generator and
the code is a mix of C and C++.
The root cause of the problem is the g++ built-in __cplusplus macro,
that is passed by CMake generator in the '.cproject' file.
The defines in '.cproject' are always the same for C and C++.
In mixed C/C++ projects, the header files often contain the following
lines to let C++ code call the C functions:
#ifdef __cplusplus
extern "C" {
#endif
< header content >
#ifdef __cplusplus
}
#endif
Whenever the Eclipse CDT4 indexer compiles the code for
code analysis, it has the macro __cplusplus set,
independent of whether standard C or C++ source files are compiled.
The 'extern "C"' confuses the standard C compilation and the indexer
is messed up.
Solution:
The amendment function deletes the __cplusplus entry from
CMAKE_EXTRA_GENERATOR_CXX_SYSTEM_DEFINED_MACROS.
3. The amendment function appends the defines from
${CMAKE_BINARY_DIR}/zephyr/include/generated/autoconf.h to
CMAKE_EXTRA_GENERATOR_C_SYSTEM_DEFINED_MACROS.
Signed-off-by: Istvan Bisz <istvan.bisz@t-online.hu>
Driver fxos8700 can also be used for the MMA8451
accelerometer and offers more functionality.
Revert the commit to avoid duplicate code.
This reverts commit 9c0d7813e5.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Driver fxos8700 can also be used for the MMA8451
accelerometer and offers more functionality.
Revert the commit to avoid duplicate code.
This reverts commit 70a35e2346.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
Add basic verification of the supported devices.
Add IDs for MMA8451, MMA8652, MMA8653 and FXOS8700 and
remove Kconfig FXOS8700_WHOAMI option.
Signed-off-by: Johann Fischer <j.fischer@phytec.de>
This patch fixes the compile error when CONFIG_NET_PKT_LOG_LEVEL
is LOG_LEVEL_DBG.
> subsys/net/ip/net_shell.c: In function ‘context_info’:
> subsys/net/ip/net_shell.c:2893:106: error: ‘struct net_buf_pool’
> has no member named ‘avail_count’
> subsys/net/ip/net_shell.c:2893:125: error: ‘struct net_buf_pool’
> has no member named ‘name’
In struct net_buf_pool, 'avail_count' and 'name' are depends on
CONFIG_NET_BUF_POOL_USAGE.
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
The macros likely() and unlikely() used by the compiler for
optimization are always used inside an if condition.
According to MISRA we need to have bool type and not long.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
In _pend_current_thread the argument key is always a unsigned
interger type and this function forces it to become a signed
interger. This is a dangerous behavior and cant be trusted to
work as expected.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Always compare unsigned interger type with another unsigned
integer type. Currently in nios2, posix, riscv32, x86 and xtensa
we were comparing the _kernel.nested variable with a signed
interger type. Fixed this violation.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The function _arc_v2_irq_unit_is_in_isr computes a Boolean
value but the function returns a integer value.
Fix the return type of the function.
This makes the zephyr api _is_in_isr() return a boolean type.
Thereby making it consistent across all the architectures.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
The function _IsInIsr computes a Boolean value but the function
returns a integer value. Fix the return type of the function.
This makes the zephyr api _is_in_isr() return a boolean type.
Thereby making it consistent across all the architectures.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Duh: "remove()" is a POSIX symbol, and on at least some platforms
stdio.h can be included here out of platform headers causing a name
collision.
Fixes #10669's direct issue, though the broader issue of how to choose
names for statics remains controversial.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Anas Nashif