Including header files from modules into app

[ngoma94]

Hi all,

I'm trying to use some functions for the LoRa sx1276 driver that are not available from the lora driver api. These functions are defined in the loramac-node project module: [zephryproject dir]/modules/lib/loramac-node/src/radio/sx1276/sx1276.c . The header file sx1276.h contains the function prototypes, and includes other dependencies. I would like to include sx1276.h in my app because I believe it will give me access to all the functions I need for my project.

I noticed there was another source file named sx1276.c in the zephyr tree, located at zephyr/drivers/lora/sx1276.c. This is the source file in which the LoRa device driver and API are actually initialized. This file includes the header file I want via this include statement: #include <sx1276/sx1276.h>. This is the only other file in sx1276.h is included. I thought I could include it in my app the same way. However, I keep encountering the fatal error: sx1276/1276.h: No such file or directory. Could someone please let me know what I'm doing wrong?

[tejlmand]

Is your source that has: #include <sx1276/sx1276.h> the app library, or is it in another library, as example, applora ?

If the source is part of the app lib, then it ought to work, but for further investigation, then verbose built output for the compilation of the source would be needed.

If the source is part of another lib, such as applora, then you probably miss a line such as:

target_link_libraries(applora PUBLIC zephyr_interface)

[Mani-Sadhasivam]

@ngoma94 First you should not include the HAL header in app. This should really be done using the APIs provided by Zephyr. Can you please share what you found missing in current Zephyr API so that we can work together to add it if reasonable?

[ngoma94]

@tejlmand
I tried to include it in my source file.

@Mani-Sadhasivam
It looks like the project module exposes the full functionality of the sx1276 chip, allowing its radio to be configured as either FSK or LoRA, and allowing the user to write to the chips internal registers. The driver API, on the other hand greatly restricts usability. The radio is configured and fixed to LoRa, and there is no avenue to write to any registers.

I imagine that the goal of the API is to keep the driver simple and user-friendly. I think, however, that it would be nice to also allow flexibility for users with less generic applications. At the very least, it would be able to write (and read) the chips registers. The functionality is already available in the driver module; it just isn't exposed by the API.

[tejlmand]

@tejlmand
I tried to include it in my source file.

@ngoma94 I assume you have some CMake library that needs to know the loramac-node include directory.
The loramac-node is defined here: https:/zephyrproject-rtos/loramac-node/blob/master/zephyr/CMakeLists.txt

All zephyr_library_include_directories will have private includes, so that means you cannot inherit them using target_link_libraries, but if you have already enabled CONFIG_HAS_SEMTECH_LORAMAC=y in Kconfig, then you can obtain the include paths using a generator expression, for example:

target_include_directories(app PRIVATE $<TARGET_PROPERTY:loramac-node,INCLUDE_DIRECTORIES>)

assuming app is holding your C-file. Change app to whatever is used on your system.

Another approach is to simply add the include to your library in this way:

target_include_directories(app PRIVATE ${ZEPHYR_LORAMAC-NODE_MODULE_DIR}/../src/radio)             

Besides those examples, I also agree with @Mani-Sadhasivam that if you can reason your needs, then this could problably be improved in Zephyr for a better user experience.

[ngoma94]

Thanks for all your help, guys.

I ended up writing my own version of the driver, allowing me to configure the chip as I needed.

I do think the current Zephyr driver could do with some expansion. I might consider submitting a suggestion when I'm done with my project.

Thanks again, everyone.

[tejlmand]

Happy you got it working, although not so good you had to write your own version.
Hope the Zephyr version at least offered a good starting point.

I do think the current Zephyr driver could do with some expansion. I might consider submitting a suggestion when I'm done with my project.

Please do.
It's good to get feedback on how people actually uses the drivers and where they could improve.

[mkarklins]

@ngoma94 I've just encountered a similar issue where I'd need to set the module with FSK modulation. By any chance - is there anything you could share about your driver at least as a starting point? It seems I'll also have to write one myself :)

[ngoma94]

Hi @mkarklins,

I used the source files provided in the loramac-node zephyr projec as my starting point. I mentioned before that in these files resided the functionality I needed, but they weren't made available by the lora driver API. The API in question is here. I guess this makes sense since the driver was written specifically for LoRa applications, not as a generic SX1276 driver.

Basically, I made an out-of-tree driver for my application, re-using parts of the source material from the loramac node project which suited my purpose, and wrote a different API, my-sx1276.h, which exposed the functions I wanted.

I think I maybe could have just written the new API file without re-writing the source functions, but I liked the full control my approach afforded me. Plus, it was good practice for writing zephyr drivers.

If you are unfamiliar with how to write zephyr drivers, take a look at the following pages. They should prove helpful.

Device Driver Model

How to Build Drivers for Zephyr RTOS

[mkarklins]

@ngoma94 thanks! This is really helpful!

[joelrietzle]

@tejlmand
I tried to include it in my source file.

@ngoma94 I assume you have some CMake library that needs to know the loramac-node include directory.
The loramac-node is defined here: https:/zephyrproject-rtos/loramac-node/blob/master/zephyr/CMakeLists.txt

All zephyr_library_include_directories will have private includes, so that means you cannot inherit them using target_link_libraries, but if you have already enabled CONFIG_HAS_SEMTECH_LORAMAC=y in Kconfig, then you can obtain the include paths using a generator expression, for example:

target_include_directories(app PRIVATE $<TARGET_PROPERTY:loramac-node,INCLUDE_DIRECTORIES>)

assuming app is holding your C-file. Change app to whatever is used on your system.

Another approach is to simply add the include to your library in this way:

target_include_directories(app PRIVATE ${ZEPHYR_LORAMAC-NODE_MODULE_DIR}/../src/radio)             

Besides those examples, I also agree with @Mani-Sadhasivam that if you can reason your needs, then this could problably be improved in Zephyr for a better user experience.

Hello,
I have a similar issue as this one. I want to include the nRF SDK in order to obtain features from those libraries. I am creating a CMakeLists.txt file for my nrf5_SDK_15.2.0 directory in order to build. I am using target_include_directories(app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/examples) as that's one of the directories that I need to include, among others.

The issue I am facing now is that Cmake is not able to find my header files from the nRF SDK when I include them in my main.c file in my Zephyr lwm2m_client sample. Is there any way to just include the whole nRF SDK without having to specify every single directory?

[tejlmand]

The issue I am facing now is that Cmake is not able to find my header files from the nRF SDK when I include them in my main.c file in my Zephyr lwm2m_client sample. Is there any way to just include the whole nRF SDK without having to specify every single directory?

Unfortunately not.
If you want a Zephyr application to pick up headers from a specific directory then you must add this directory using target_include_directories().
Also, just including all directories from nRF5 SDK would have a risk of colliding header files, resulting in hard to trace bugs.

Note, this is a Zephyr repository, so I assume your question is better suited for https://devzone.nordicsemi.com/