How to combine multiple shields in a zephyr extended library

[nRF5xFanboy]

Dear community,

I have multiple device chips I often re-use in multiple projects.
So I wish to create a shared zephyr external library for re-use.

What is the best way to organize my *.c | *.h | *.yml of my custom device drivers (as zephyr out-of-tree)

I have currently this standard zephyr external library folder structure:

<library root> \ board \ arm \ product_name\ *.dts
<library root> \ dts \ binding \*.yml

<library root> \ include \ *.h

<library root> \ lib\ drivers \ driver_a  \ *.c + cmakelist.txt + kconfig

<library root> \ lib\ drivers \ driver_b  \ *.c + cmakelist.txt + kconfig

I do not like this structure for custom device drivers
because all the related device driver files are scattered across multiple folders

Any advice to improve on issue would be welcome and is appreciated.

Best regards,
     nRFxFanBoy

[Susheel Nuguru]

I do not like this structure for custom device drivers
because all the related device driver files are scattered across multiple folders

Not sure what kind of files are scattered but if those are common files then you can have something like 

lib\drivers\common\ to put the common files. If they are not common files then they should go into the specific driver_x folder you created. This is more of opinion based solution rather than a problem. You might get different opinions from different people. There does not seem to be one right way to do this.

[nRF5xFanboy]

Hi Susheel,

My custom device driver has the following files:

1 - Information to extend the *.dts so it has a overlay  --> zephyr  wants this in the board folder;
2 - It has a *.yaml  --> zephyr wants this in  ..\dts\binding folder;
3 - it has a *.h file  --> zephyr wants this in the \ include folder of my custom extended library;
4 - It has *.c files  -->  zephyr wants this in  the \lib\driver folder
5 - It has cmakelist.txt file  -->  it goes by the *.c file
6 - It has kconfig file  -->  it goes by the *.c file

zo many files in many places 
this make it hardware to create a  sub-repository of the custom zephyr device driver within multiple projects.

any ideas of thins  to handle this better are most welcome.

Best regards,
    nRFxFanBoy

[Susheel Nuguru]

I personally like the structure you have, but this is a matter of preference and not technical limitation. It can be done in many other ways all of which would still be personal preferences to think good and bad structure. I would leave it as you have it now.

[nRF5xFanboy]

Hi  Susheel

Thanks for your answer. 

From a external zephyr library point of view i do understand the current structure .

But for re-use of from custom device drivers point-of-view and component management in mind with git sub-repositories  this structure is not very handy at all.

I just starts working with zephyr so other experience & opinions are very welcome to learn from.

Best regards,
   nRF5xFanBoy