This sample depends on lvgl, so do not try and build it if lvgl is not
part of the workspace and if it was excluded in a local manifest.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
If we enable DISPLAY=y, ILI9341 will be selected automatically if all of
its dependencies are met as well (SPI), let's add this to the board
defconfig.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
LVGL eats a considerable amount of flash, so tests may fail on platforms
that meet all requirements but that have a low amount of flash, e.g.
nucleo_g071rb. Set min_flash for all cases to 250K (result of some quick
experimentation). Also update minimum ram to exclude platforms that
cannot run Zephyr + LVGL (e.g. those with just 16K).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
'display' harness doesn't exist, so replace it with 'none' to make
things more clear. It is required so that test is not run e.g. on CI,
test would timeout because the GUI is left ON forever.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Simplify sample.yaml by just adding a single test case. In future
commits, test case will be refined to be based on DT filters so that it
is made more generic.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Remove v1 implementation from log_core and all references in the tree.
Remove modules used by v1: log_list and log_msg.
Remove Kconfig v1 specific options.
Remove Kconfig flags used for distinction between v1 and v2.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
In order to bring consistency in-tree, migrate all samples to the use
the new prefix <zephyr/...>. Note that the conversion has been scripted:
```python
from pathlib import Path
import re
EXTENSIONS = ("c", "h", "cpp", "rst")
for p in Path(".").glob("samples/**/*"):
if not p.is_file() or p.suffix and p.suffix[1:] not in EXTENSIONS:
continue
content = ""
with open(p) as f:
for line in f:
m = re.match(r"^(.*)#include <(.*)>(.*)$", line)
if (m and
not m.group(2).startswith("zephyr/") and
(Path(".") / "include" / "zephyr" / m.group(2)).exists()):
content += (
m.group(1) +
"#include <zephyr/" + m.group(2) +">" +
m.group(3) + "\n"
)
else:
content += line
with open(p, "w") as f:
f.write(content)
```
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Fix spelling errors in assorted .rst files. The errors were found
using a tool called 'codespell'.
Signed-off-by: Aleksandar Markovic <aleksandar.markovic.sa@gmail.com>
Some names of the test cases are duplicated within the project.
This commit contains the proposed names of the test scenarios.
Signed-off-by: Katarzyna Giadla <katarzyna.giadla@nordicsemi.no>
Add configuration for stm32h7b3i_dk board which enables
integration of touch controller (KSCAN) present on the board
into LVGL
Signed-off-by: Tomislav Milkovic <tomislav.milkovic95@gmail.com>
Kconfig options now belong to the Kconfig domain, therefore, the
:kconfig:option: role needs to be used.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
We're now using the Kconfig copied from the upstream lvgl repository. It
uses the LV_ prefix for all options while we're using LVGL_ for
Zephyr-specific ones. Make the latter consistent with upstream but also
make sure they're distinct from lvgl's by using LV_Z_ as the prefix.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
Start using the upstream Kconfig from LVGL and move the glue code out
of the zephyr tree and put it under lvgl/zephyr/ in modules.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
This updates the lvgl in-tree glue code to work with version v8.1.0 and
bumps the west manifest accordingly.
The following are the most significant changes:
- The logging callback has changes in lvgl and no longer provides the
caller with an integer log level code. We now need to parse the log
string's prefix to determine the level.
- Several Kconfig options (mostly for default values of various settings)
have been removed because these values are no longer configurable in
lvgl.
- The library no longer performs a deep copy of the display and input
device driver structs, so these must no longer be allocated on the
stack in the init func.
Other than that it's mostly about renaming of various structures and
functions and adjusting the calls if function's signatures have changed.
This patch allows all in-tree users to work correctly but it's likely
it doesn't support all new widgets and layouts added in lvgl v8. These
however can be added gradually once this is upstream.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
Current lvgl code allows to use the kernel heap for dynamic memory
allocation. The k_heap API doesn't however provide k_realloc() which
will be needed in order to update lvgl to v8. Nico suggested there's
no good reason for lvgl to use k_heap and it should stick to either
the libc's allocator or depend on its own private sys_heap.
The alternative would be to extend the k_heap API to provide k_realloc()
but this may be tricky for several reasons and for now there would
be a single user anyway.
This removes the choice of using k_heap for lvgl and renames the user
pool to SYS_HEAP in Kconfig and makes it the default option.
The prj.conf for the lvgl sample is modifed to specify the number of
memory pool blocks instead of the total size as the default block
size is 2048 and it results in the same size of memory.
Suggested-by: Nicolas Pitre <npitre@baylibre.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
The sample graphical Hello World program uses the image widget as well as
the Montserrat font size 14. While currently those are being selected by
default, it won't be the case once we update to lvgl v8. Select relevant
Kconfig option in prj.conf.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@huawei.com>
The driver does not implement a display API, it has a custom API. Having
it under display is confusing, since display API consumers may expect
they can use it. These sort of custom drivers fit better under
drivers/misc.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The ip_k66f doesn't have I2C_0 status set to OKAY so the build of
this sample generates warnings in the nightly build. Root problem
is that the groove display is not ported to the device tree so
there isn't a standard way of filtering on the display being
part of the platform.
fixes#41523
Signed-off-by: David Leach <david.leach@nxp.com>
Excluded due to conflicts with adafruit_2_8_tft_touch_v2.
Both boards got a touch controller.
Signed-off-by: Konstantinos Papadopoulos <kostas.papadopulos@gmail.com>
- fixes sample codes' relative paths
- updates instructions to build and run for native posix
platforms on its 64 flavor.
Signed-off-by: Glauber Maroto Ferreira <glauber.ferreira@espressif.com>
Rework samples to use DEVICE_DT_GET and DT_CHOSEN
to get default display controller device.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
Commit c79b1a38aa ("samples: display:
Convert driver and lvgl sample.yaml to use depends_on") started using
depends_on in the sample YAML for a lvgl application instead of
platform_allow.
This breaks build testing with twister and overflow checking enabled
on more resource constrained platforms. The test case's .config
ends up with:
CONFIG_LVGL_HOR_RES_MAX=320
CONFIG_LVGL_VER_RES_MAX=240
CONFIG_LVGL_VDB_SIZE=64
CONFIG_LVGL_BITS_PER_PIXEL=24
And lib/gui/lvgl/lvgl.c, where we allocate a buffer of size:
(CONFIG_LVGL_BITS_PER_PIXEL *
((CONFIG_LVGL_VDB_SIZE * CONFIG_LVGL_HOR_RES_MAX *
CONFIG_LVGL_VER_RES_MAX) / 100)
/ 8)
Require 147456 bytes to build the sample, ultimately overflowing RAM
if you run something along the lines of:
twister -T samples -p <constrained_platform> --overflow-as-errors
This is a reasonable test to be doing to make sure that sample RAM
requirements do not get too big for a subset of platforms that are of
interest, and it no longer works.
To fix it, add a min_ram line for this case so that we can still run
overflow tests on a large set of samples without fine-grained special
casing or creating an ever-growing list of platform excludes for this
test.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Add Atmel sam0 sercom[uart] pinctrl bindings and implements pinctrl at
driver level. It changes all sam0 boards to use new feature and remove
pinmux driver dependency for sercom[uart]. The samples that require a
binding were update to keep consistency and avoid errors.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Similar to commit c6ff61220e, use a
harness config to limit execution of the adafruit_2_8_tft_touch_v2
sample variant to boards that have this shield attached.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Converts the display driver and lvgl sample.yaml to select boards for
the adafruit_2_8_tft_touch_v2 shield configuration by depending on the
arduino_{gpio,i2c,spi} features instead of using an explicit
platform_allow list. This will enable twister to automatically select
new boards that add support for Arduino ports.
The reel_board and reel_board_v2 are excluded due to a conflict between
display drivers (onboard display vs. shield display).
The ubx_evkannab1_nrf52832 board is excluded due to a conflict between
the arduino_spi and arduino_i2c ports, which cannot be used
simultaneously.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Now that we can use the adafruit_2_8_tft_touch_v2 shield with
mimxrt685_evk_cm33 and frdm_k64f boards, start building the display
driver and lvgl samples for these boards in CI.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
This should align with subsys/display which we do not have yet. Plan is
to move lib/gui into subsys/display.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
