Commit Graph

11 Commits

Author SHA1 Message Date
Johann Fischer f531e0d62e subsys: add monochrome character framebuffer
Add monochrome character framebuffer for monochrome
graphic dot matrix displays and electrophoretic displays.

These displays are mostly monochrome and can only display
black and some other color, for example white. Typically,
a byte controls 8 pixels, arranged vertically or horizontally
depending on the controller or settings.
The API is not suitable to display graphics, the purpose is
to display text or symbols. It is possible to use several fonts.
A font can also consist of graphic symbols only and thus,
for example, enable the realization of a menu.

Signed-off-by: Johann Fischer <j.fischer@phytec.de>
2018-10-16 14:54:47 -04:00
Krzysztof Chruscinski 6aed72e487 shell: Shell subsystem reimplementation
New shell support features like:
- multi-instance
- command tree
- static and dynamic commands
- multiline
- help print function
- smart tab (autocompletion)
- meta-keys
- history, wildcards etc.
- generic transport (initially, uart present)

Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordicsemi.no>
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
2018-09-19 09:30:29 -04:00
Ramakrishna Pallala 2ad647857c subsys: power: Add OS managed Power Management framework
Add support for OS managed Power Management framework for Zephyr
under 'subsys/power'. This framework takes care of implementing
the _sys_soc_suspend/_sys_soc_resume API's, a PM policy based on
SoC Low Power residencies and also provides necessary API's to
do devices suspend and resume.

Also add necessary changes to support the existing Application
managed Power Management framework.

Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
2018-08-22 08:07:14 -07:00
Shawn Mosley 573f32b6d2 userspace: compartmentalized app memory organization
Summary: revised attempt at addressing issue 6290.  The
following provides an alternative to using
CONFIG_APPLICATION_MEMORY by compartmentalizing data into
Memory Domains.  Dependent on MPU limitations, supports
compartmentalized Memory Domains for 1...N logical
applications.  This is considered an initial attempt at
designing flexible compartmentalized Memory Domains for
multiple logical applications and, with the provided python
script and edited CMakeLists.txt, provides support for power
of 2 aligned MPU architectures.

Overview: The current patch uses qualifiers to group data into
subsections.  The qualifier usage allows for dynamic subsection
creation and affords the developer a large amount of flexibility
in the grouping, naming, and size of the resulting partitions and
domains that are built on these subsections. By additional macro
calls, functions are created that help calculate the size,
address, and permissions for the subsections and enable the
developer to control application data in specified partitions and
memory domains.

Background: Initial attempts focused on creating a single
section in the linker script that then contained internally
grouped variables/data to allow MPU/MMU alignment and protection.
This did not provide additional functionality beyond
CONFIG_APPLICATION_MEMORY as we were unable to reliably group
data or determine their grouping via exported linker symbols.
Thus, the resulting decision was made to dynamically create
subsections using the current qualifier method. An attempt to
group the data by object file was tested, but found that this
broke applications such as ztest where two object files are
created: ztest and main.  This also creates an issue of grouping
the two object files together in the same memory domain while
also allowing for compartmenting other data among threads.

Because it is not possible to know a) the name of the partition
and thus the symbol in the linker, b) the size of all the data
in the subsection, nor c) the overall number of partitions
created by the developer, it was not feasible to align the
subsections at compile time without using dynamically generated
linker script for MPU architectures requiring power of 2
alignment.

In order to provide support for MPU architectures that require a
power of 2 alignment, a python script is run at build prior to
when linker_priv_stacks.cmd is generated.  This script scans the
built object files for all possible partitions and the names given
to them. It then generates a linker file (app_smem.ld) that is
included in the main linker.ld file.  This app_smem.ld allows the
compiler and linker to then create each subsection and align to
the next power of 2.

Usage:
 - Requires: app_memory/app_memdomain.h .
 - _app_dmem(id) marks a variable to be placed into a data
section for memory partition id.
 - _app_bmem(id) marks a variable to be placed into a bss
section for memory partition id.
 - These are seen in the linker.map as "data_smem_id" and
"data_smem_idb".
 - To create a k_mem_partition, call the macro
app_mem_partition(part0) where "part0" is the name then used to
refer to that partition. This macro only creates a function and
necessary data structures for the later "initialization".
 - To create a memory domain for the partition, the macro
app_mem_domain(dom0) is called where "dom0" is the name then
used for the memory domain.
 - To initialize the partition (effectively adding the partition
to a linked list), init_part_part0() is called. This is followed
by init_app_memory(), which walks all partitions in the linked
list and calculates the sizes for each partition.
 - Once the partition is initialized, the domain can be
initialized with init_domain_dom0(part0) which initializes the
domain with partition part0.
 - After the domain has been initialized, the current thread
can be added using add_thread_dom0(k_current_get()).
 - The code used in ztests ans kernel/init has been added under
a conditional #ifdef to isolate the code from other tests.
The userspace test CMakeLists.txt file has commands to insert
the CONFIG_APP_SHARED_MEM definition into the required build
targets.
  Example:
        /* create partition at top of file outside functions */
        app_mem_partition(part0);
        /* create domain */
        app_mem_domain(dom0);
        _app_dmem(dom0) int var1;
        _app_bmem(dom0) static volatile int var2;

        int main()
        {
                init_part_part0();
                init_app_memory();
                init_domain_dom0(part0);
                add_thread_dom0(k_current_get());
                ...
        }

 - If multiple partitions are being created, a variadic
preprocessor macro can be used as provided in
app_macro_support.h:

        FOR_EACH(app_mem_partition, part0, part1, part2);

or, for multiple domains, similarly:

        FOR_EACH(app_mem_domain, dom0, dom1);

Similarly, the init_part_* can also be used in the macro:

        FOR_EACH(init_part, part0, part1, part2);

Testing:
 - This has been successfully tested on qemu_x86 and the
ARM frdm_k64f board.  It compiles and builds power of 2
aligned subsections for the linker script on the 96b_carbon
boards.  These power of 2 alignments have been checked by
hand and are viewable in the zephyr.map file that is
produced during build. However, due to a shortage of
available MPU regions on the 96b_carbon board, we are unable
to test this.
 - When run on the 96b_carbon board, the test suite will
enter execution, but each individaul test will fail due to
an MPU FAULT.  This is expected as the required number of
MPU regions exceeds the number allowed due to the static
allocation. As the MPU driver does not detect this issue,
the fault occurs because the data being accessed has been
placed outside the active MPU region.
 - This now compiles successfully for the ARC boards
em_starterkit_em7d and em_starterkit_em7d_v22. However,
as we lack ARC hardware to run this build on, we are unable
to test this build.

Current known issues:
1) While the script and edited CMakeLists.txt creates the
ability to align to the next power of 2, this does not
address the shortage of available MPU regions on certain
devices (e.g. 96b_carbon).  In testing the APB and PPB
regions were commented out.
2) checkpatch.pl lists several issues regarding the
following:
a) Complex macros. The FOR_EACH macros as defined in
app_macro_support.h are listed as complex macros needing
parentheses.  Adding parentheses breaks their
functionality, and we have otherwise been unable to
resolve the reported error.
b) __aligned() preferred. The _app_dmem_pad() and
_app_bmem_pad() macros give warnings that __aligned()
is preferred. Prior iterations had this implementation,
which resulted in errors due to "complex macros".
c) Trailing semicolon. The macro init_part(name) has
a trailing semicolon as the semicolon is needed for the
inlined macro call that is generated when this macro
expands.

Update: updated to alternative CONFIG_APPLCATION_MEMORY.
Added config option CONFIG_APP_SHARED_MEM to enable a new section
app_smem to contain the shared memory component.  This commit
seperates the Kconfig definition from the definition used for the
conditional code.  The change is in response to changes in the
way the build system treats definitions.  The python script used
to generate a linker script for app_smem was also midified to
simplify the alignment directives.  A default linker script
app_smem.ld was added to remove the conditional includes dependency
on CONFIG_APP_SHARED_MEM.  By addining the default linker script
the prebuild stages link properly prior to the python script running

Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov>
Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-07-25 12:02:01 -07:00
Paul Sokolovsky f6d8ab8289 subsys: console: Factor out fifo-based console input abstraction
Console subsystem is intended to be a layer between console drivers
and console clients, like e.g. shell. This change factors out code
from shell which dealed with individial console drivers and moves it
to console subsystem, under the name console_register_line_input().

To accommodate for this change, older console subsys Kconfig symbol
is changed from CONFIG_CONSOLE_PULL to CONFIG_CONSOLE_SUBSYS
(CONFIG_CONSOLE is already used by console drivers). This signifies
that console subsystem is intended to deal with all of console
aspects in Zephyr (existing and new), not just provide some "new"
functionality on top of raw console drivers, like it initially
started.

Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2018-06-20 15:59:12 -04:00
Andrzej Puzdrowski 94ff339cbf subsys: Add a new settings subsystem
Adapt the MyNewt non-volatile configuration system to become a settings
system in Zephyr.
The original code was modifed in the following ways:

* Renamed from config to settings
* Use the zephyr FCB, FS API, and base64 subsystems
* lltoa like function was added to sources as it was required but not
  included in Zephyr itself.
* The original code was modified to use Zephyr's slist.h as single
  linked list implementation.
* Reworked code which was using strtok_r, added function
  for decoding a string to a s64_t value.
* Thank to the above the settings subsys doesn't require newlibc anymore.

Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-03-28 10:44:20 -04:00
Christopher Collins 3986ef2770 subsys: mgmt: CMake and Kconfig support.
Add the necessary CMakeLists.txt and Kconfig files for the mgmt
subsystem.

Signed-off-by: Christopher Collins <ccollins@apache.org>
2018-02-20 22:07:52 +01:00
Christopher Collins 6721d64735 subsys: mgmt: SMP protocol for mcumgr.
The Simple Management Protocol (SMP) is a basic protocol that sits on
top of mcumgr's mgmt layer.  This commit adds the functionality needed
to hook into mcumgr's SMP layer.

More information about SMP can be found at:
`ext/lib/mgmt/mcumgr/smp/include/smp/smp.h`.

Signed-off-by: Christopher Collins <ccollins@apache.org>
2018-02-20 22:07:52 +01:00
Andrzej Puzdrowski b7f1289847 subsys: fs: Add Flash Circular Buffer
Zephyr already supports NFFS as a storage layer, but it might
be a little bit too heavyweight for certain applications in
memory-restricted ICs.

This module is response for need of Lightweight flash storage
capability. FCB is ported form MyNewt as native zephyr module.

Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
2018-01-15 15:46:37 -05:00
Andrzej Puzdrowski 25269fb0ed subsys: storage: Add flash_map abstraction module
Introduce flas_map module is abstraction over flash memory and its
driver for using flash memories along with description of
available flash areas.
Module provides simple API for write/read/erase and so one.

Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
2018-01-15 15:46:37 -05:00
Sebastian Bøe 12f8f76165 Introduce cmake-based rewrite of KBuild
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.

Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.

This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.

For users that just want to continue their work with minimal
disruption the following should suffice:

Install CMake 3.8.2+

Port any out-of-tree Makefiles to CMake.

Learn the absolute minimum about the new command line interface:

$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..

$ cd build
$ make

PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html

Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-08 20:00:22 -05:00