Why doesn't the build include driver files?

[Paultino_nordost]

Followed the instructions for Zephyr workspace application.

the structure follows the example-application and video "tutorial: mastering Zephyr Driver Development" by Gerald Paretas.

at the file search stage, the cmake function message() shows that it goes into the driver folder.

But the application builds successfully only when this driver file is copied to \zephyrproject\zephyr\drivers\display
and add the line to the CMakeLists.txt file, which is located in this folder:
zephyr_library_sources_ifdef(CONFIG_ILI9486 display_ili9486.c).

I'm using windows 11, zephyr-v3.5.0-3682-gd7af6f371034

I'm going through the Getting Started Guide completely.
Applications are located in Zephyr workspace.
Simple examples are built successfully.
But if it’s a little more complicated, then errors appear inside Zephyr.

So, the Example application builds with errors out of the box. To avoid errors, I need to specify additional Kconfig parameters. (Case ID: 320177)

5707.test-origin-tft.zip

[Håkon Alseth]

Hi,

 

Based on your project, it seems that you have converted from a "workspace application" to a "freestanding application".

 

You are adding an addition to the already present ili-display drivers in zephyr, as seen from the output when you're configuring:

Loading Zephyr default modules (Zephyr base).
-- Application: /tmp/test
-- CMake version: 3.22.1
-- Found Python3: /usr/bin/python (found suitable version "3.10.12", minimum required is "3.8") found components: Interpreter 
-- Cache files will be written to: /home/hkn/.cache/zephyr
-- Zephyr version: 3.5.0 (/opt/repos/upstream-zephyr/zephyr)
-- Found west (found suitable version "1.0.0", minimum required is "0.14.0")
-- Board: nrf52840dk_nrf52840
-- Shield(s): waveshare_3_5_tft_sku_13506
-- Found host-tools: zephyr 0.16.0 (/opt/zephyr-sdk/zephyr-sdk-0.16.0)
-- Found toolchain: zephyr 0.16.0 (/opt/zephyr-sdk/zephyr-sdk-0.16.0)
-- Found Dtc: /usr/bin/dtc (found suitable version "1.6.1", minimum required is "1.4.6") 
-- Found BOARD.dts: /opt/repos/upstream-zephyr/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Found devicetree overlay: /tmp/test/boards/shields/waveshare_3_5_tft_sku_13506/waveshare_3_5_tft_sku_13506.overlay
-- Found devicetree overlay: /tmp/test/boards/shields/waveshare_3_5_tft_sku_13506/boards/nrf52840dk_nrf52840.overlay
-- Generated zephyr.dts: /tmp/test/build/zephyr/zephyr.dts
-- Generated devicetree_generated.h: /tmp/test/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: /tmp/test/build/zephyr/dts.cmake

warning: ILI9486 (defined at /tmp/test/drivers/display/Kconfig.ili9xxx:8) was assigned the value 'y'
but got the value 'n'. Check these unsatisfied dependencies: DT_HAS_ILITEK_ILI9486_ENABLED (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_ILI9486 and/or look up ILI9486 in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

 

The symbol "DT_HAS_ILITEK_ILI9486_ENABLED" has not been selected, which comes from your device tree.

This seems to be non-selected in waveshare_3_5_tft_sku_13506.overlay:

...Line 49
	ili9486_waveshare_3_5_tft_sku_13506: ili9488@0 {
		compatible = "ilitek,ili9488";
...

I assume you want the compatible to be "ilitek,ili9486" and "ili9486@0"?

 

But the application builds successfully only when this driver file is copied to \zephyrproject\zephyr\drivers\display
and add the line to the CMakeLists.txt file, which is located in this folder:
zephyr_library_sources_ifdef(CONFIG_ILI9486 display_ili9486.c).

There is a conflict in your kconfig, where you select the symbol "ILI9XXX". This is present both in zephyr (see here: https://github.com/nrfconnect/sdk-zephyr/blob/v3.4.99-ncs1/drivers/display/Kconfig.ili9xxx#L8-L11) as well as in your application drivers/display/Kconfig.ili9xxx.

You have to rename your kconfig symbol to avoid a conflict.

 

Kind regards,

Håkon

[Paultino_nordost]

Sorry, an old file got caught while preparing the zip. I tested it on it and now ili9486 is there.

Apparently my problems are due to the fact that I did not understand the role of the manifest file, and in it the term
"repository of your application".
I don't use git, and maybe that's why these things are not clear.
The examples that come with Zephyr contain the file "sample.yaml", but how does it relate to "west.yaml" is not entirely clear.

You're right, I got a mix of Star topology and Forest topology.

My folder structure:

west-workspace/
│
├── applications
│       │
│       ├── app1/               
│       │     ├── CMakeLists.txt
│       │     ├── prj.conf
│       │     └── src/
│       │          └── main.c
│       ├── app2/             
│             ├── CMakeLists.txt
│             ├── prj.conf
│             └── src/
│                   └── main.c
├── manifest-repo/
│   └── west.yml  
├── modules/
│   └── lib/
│
└── zephyr/          
    └── west.yml 

My west.yml in manifest-repo

manifest:
  defaults:
    remote: remote2

   remotes:
    - name: zephyrproject-rtos
      url-base: https://github.com/zephyrproject-rtos
    - name: remote1
      url-base: https://github.com/####
    - name: remote2
      url-base: https://github.com/####

  projects:
    - name: zephyr
      remote: zephyrproject-rtos
      import: 
    - name: testlcd
      description: the test LCD example project
      remote: remote1      # The remote url-base is appended with a / and the project name to form the URL.
      path: applications/testlcd
    - name: testlaborigintft
      description: the test LCD project from sample (not use ili9488 driver)
      remote: remote2
      path: applications/testlaborigintft
  self:
    path: manifest-repo

I was trying to avoid multiple duplicates of the original Zephyr files.

Thanks for the reply.
I will check my Kconfig today.

The ili9xxx driver is universal, but it does not work with ili9486.
And I thought that the priority in connecting driver files is higher in the application than in what is in Zephyr.
But this is not a question for you.

Thanks again.
I spent a lot of time getting a working sample of 52840dk+waveshare sku-13506 + zephyr + lvgl, and lost motivation.

The ticket can be closed.

[Håkon Alseth]

Hi,

 

Paultino_nordost said:

Thank you Håkon,  thank you for your time spent with me.

No need to thank me. Always happy to help out!

Paultino_nordost said:

The problem was with the "version". A space was needed before the word " version".

Thanks for updating with the root-cause. Glad to hear that you found the issue, these syntax issues can be quite hard to identify.

Paultino_nordost said:

Returning to point 2.
What to write in the url-base?

Should I remove the mention of applications?

Not use my manifest file?

Right now, you're building an application that is a T3 type application, where the application is freestanding. This means that you will get a new clone of zephyr/ncs when initializing your application.

If you want to compile your application with your current ncs-installation (ie. point to a pre-existing NCS installation), then you can add your current application, regardless of which path it is located in, to your vscode as an ncs application, as I previously mentioned:

Håkon Alseth said:

Your original .zip is close to this, you just needed to make the changes that I posted to ensure that you do not have any symbol conflicts with the already present symbols in zephyr (ie. rename your "ILI9XXX" symbol and do the same with the corresponding .c file). Then you can add it as an application in vscode and use your already present ncs installation:

 

To answer your questions directly:

1. The url-base must be the base of your repository, for instance https://github.com/my_user/my_newly_created_repository 

This means that you will need to create a github-user and a repository to make this work.

 

2. This highly depends, but based on your previous answers, you do not want several copies of the whole NCS tree. The easiest is to use a star topology, where you point towards a arbitrary version of zephyr (ie. whichever you have installed via the toolchain manager)

Paultino_nordost said:

Not use my manifest file?

It does sound like you want to point to an existing installation as compared to having a completely standalone application (which clones the whole ncs-tree)

 

Kind regards,

Håkon

[Paultino_nordost]

Håkon Alseth said:

1. The url-base must be the base of your repository, for instance https://github.com/my_user/my_newly_created_repository 

This means that you will need to create a github-user and a repository to make this work.

Håkon Alseth said:

Right now, you're building an application that is a T3 type application, where the application is freestanding. This means that you will get a new clone of zephyr/ncs when initializing your application.

We have closed the circle.

Does this mean that two simple things don't work?

I tried doing a clean install but was unable to remove the "nRF Connect for Desktop" on Win10.

After installing it on a fresh system, I could not build the example from the video zds-2022-drivers-app, that the documentation refers to that it is good.

I couldn't build my example with ili9486.

I returned to my previous lvgl & ili9488 example, previously successfully build, but received an error.

CMake Warning at C:/ncs/v2.5.1/zephyr/CMakeLists.txt:893 (message):
No SOURCES given to Zephyr library: drivers__display

I get an error on a fresh installation using the lvgl example.

C:/ncs/v2.5.1/zephyr/include/zephyr/linker/linker-defs.h:26:10: fatal error: offsets.h: No such file or directory
26 | #include <offsets.h>
| ^~~~~~~~~~~

Zephyr doesn't want to be friends with me.

I understand that most likely I have a problem with the west.yml, but I cannot pinpoint exactly where it is.

Comparing the volume of documentation for T1 and T2 and what is written about T3, can I believe about successful builds of T3?
I asked on reddit, discord, circuitdojo, here but I didn’t get an answer from anyone.

Thank you, Håkon

[Paultino_nordost]

I compared Kconfig for three applications that said it worked for them with mine.

These applications, they are on git, I could not build due to various errors.

This magic is hidden somewhere in the depths of Zephyr.

I went through all the points several times
developer.nordicsemi.com/.../troubleshooting.html

Not successful.

Something depends on the settings of the west and the paths inside the Zephyr.

This applies to applications based on the T3 topology.

Simple examples are built without problems, from any folder.

Here developer.nordicsemi.com/.../install_ncs.html

the instruction is missing that you need to go one level below.

Navigate to the ncs directory and run the following command in a terminal window:
zephyr/zephyr-env.cmd

[Håkon Alseth]

Hi,

 

Just an FYI:

Previously you were using upstream zephyr, and now you are pointing towards ncs v2.5.1, and there might have been a diff. in the samples/subsys/display/lvgl between those two tagged zephyr versions.

 

Could you share your latest .zip file?

 

Kind regards,

Håkon

[Paultino_nordost]

In the file prj.conf, see the comment above the line “CONFIG_DISPLAY=y”, it says about the current error.

It doesn’t use drivers from the application, I need to copy these drivers to Zephyr so that the application can be built without errors..
​

testlcd.zip

[Håkon Alseth]

Thank you for sharing the latest. I see the exact same behavior.

 

First off, I would like to thank you for your patience and effort in this matter, and also say that this process of an out-of-tree driver is not straight-forward, and I will bring this up internally.

 

I'll try to sum up to my best knowledge what I did to atleast make it compile properly:

1. in CMakeLists.txt, add this before find_package(...):

list(APPEND ZEPHYR_EXTRA_MODULES
  ${CMAKE_CURRENT_SOURCE_DIR}/drivers
)

2. create file driver/zephyr/module.yml, containing:

build:
  cmake: .
  kconfig: Kconfig

 

This will point the "ZEPHYR_EXTRA_MODULES" and append it to the zephyr buildsystem.

3. I moved your drivers folder structure a bit.

 

Here is the .zip with the above changes. I was not able to successfully test it, but it does compile now:

testlcd_outoftree_driver.zip

 

Could you see if you also get this to run on your end?

 

Kind regards,

Håkon

[Paultino_nordost]

Does not work.

I experimented with the app/Zephyr folder earlier, as in the examples I linked to earlier.

I understand that I am not alone. github.com/.../27048

And there is no solution that works either.

In Zephyr git community, it is customary to transfer the problem to someone else, rather than solve it. (See the issues on the git.)

I'll try to write to the Teslabs Engineering to fix ili9xxx.

Thank you for your time, Håkon.

I'm closing the ticket.

I'll work with SDK for now and choose another RTOS.

Best regards, Paul

P.S.

You need to work for the Linux Foundation, Intel, or any large company that is involved in the development of Zephyr, do something well in it and get results. This opinion was formed from reading the Git.

This is what we are talking about here, What is this variable?

Note also having a separate COMMON_OVERLAY_CONFIG_DIR which defaults to somewhere in tree will be necessary to allow out-of-tree common configuration overlays, so I still think it is a good idea. And actually, might as well make it a list, COMMON_OVERLAY_CONFIG_DIRS, to allow site-specific values in addition to in-tree ones.

github.com/.../14740

...

The Zephyr build system is already quite complex with Kconfig and devicetree files being picked up from a number of different places. There is a learning curve for new developers starting out with Zephyr.
Extending this complexity with more locations will make it even more difficult, so we should be very careful.

github.com/.../14740

I was ready to pay for training, but I couldn’t find anyone. 

[Paultino_nordost]

In my opinion, I understood what was going on.
In theory.

We were looking in the wrong place and solving the problem in the wrong place.

This line makes Zephyr look inside the tree, and not at the application.

chosen 
{ zephyr,display = &ili9486_waveshare_3_5_tft_sku_13506; };

developer.nordicsemi.com/.../api.html

This line makes Zephyr look inside the tree, not at the application.

But lvgl module depends on this line. This is the maze. How do we get out of it?

Maybe my theory isn't right.
I don't have any other suspects.

[Håkon Alseth]

Hi,

 

The board_dir is set in your CMakelists.txt, and the shield is properly added at my end, when I add this to the build configuration:

-DSHIELD=waveshare_3_5_tft_sku_13506

I'm using the formerly attached .zip file:

Håkon Alseth said:

Here is the .zip with the above changes. I was not able to successfully test it, but it does compile now:

testlcd_outoftree_driver.zip

As I do not have the shield itself, I cannot test it, but it does indeed pull in the correct files at my end.

  

Could you share your build configuration and/or build generation error(s)?

 

Kind regards,

Håkon

[Paultino_nordost]

Hi Håkon,

I have to close this ticket.

I can't find a working solution for Zephyr about two simple things.

1. Not using Git.
2. Have only one copy of Zephyr.

I can't build a T3 application as described in the documentation.
By any means.

Now with this manifest taken from documentation even blinky is not going to build.

Workspaces — Zephyr Project documentation (nRF Connect SDK) (nordicsemi.com)

manifest:
  version: "1.2"

  remotes:
    - name: zephyrproject-rtos
      url-base: https://github.com/zephyrproject-rtos

    - name: MyCompany
      url-base: https://github.com/MyCompany

  defaults:
    remote: MyCompany

  projects:
    - name: zephyr
      remote: zephyrproject-rtos
      revision: main
      import: 

    - name: testlcd
      revision: main
      description: the test LCD example project
      groups:
        - groupLearn
      path: applications/testlcd

    - name: testlaborigintft
      revision: main
      groups:
        - groupLearn
      description: the test LCD project from sample (not use ili9488 driver)
      path: applications/testlaborigintft

    - name: ledblinky
      revision: main
      groups:
        - groupLearn
      description: the first project
      path: Lemmus/ledblinky

  self:
    path: Lemmus-manifest

Is that why the linker went into a neighboring application?

PS C:\zephyrproject\Lemmus\ledblinky> west build -b nrf52840dk_nrf52840
-- west build: generating a build system
Loading Zephyr default modules (Zephyr base (cached)).
-- Application: C:/zephyrproject/Lemmus/ledblinky

-- Generated devicetree_generated.h: C:/zephyrproject/Lemmus/ledblinky/build/zephyr/include/generated/devicetree_generated.h
-- Including generated dts.cmake file: C:/zephyrproject/Lemmus/ledblinky/build/zephyr/dts.cmake
Parsing C:/ncs/v2.5.1/zephyr/scripts/kconfig
C:/ncs/v2.5.1/zephyr/scripts/kconfig/kconfig.py: C:/zephyrproject/applications/testlcd/Kconfig:12: recursive 'source' of 'Kconfig.zephyr' detected.
Include path:
C:/ncs/v2.5.1/zephyr/scripts/kconfig:8
Kconfig.zephyr:41
modules/Kconfig:13

It's a simple blinky for the T3 test.  

All the best.