Why doesn't the build include driver files?

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

Parents
  • 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

  • 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.

  • 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

  • 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

  • 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

  • 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. Disappointed

  • 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.

Reply Children
  • 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

  • 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.  Disappointed

    All the best.

  • Hi,

     

    Paultino_nordost said:

    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.

    I am sorry to hear that the process has been this painful. I will raise this as an issue internally with our UX group and product owners/management.

     

    Kind regards,

    Håkon

Related