search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.79k stars 6.58k forks source link

RFC: Multi-subsystem / full feature samples #67021

Open Thalley opened 10 months ago

Thalley commented 10 months ago

Introduction

In Zephyr we have the samples directory which is split into multiple sub-directories, often based on subsystems or specific functionality, like bluetooth, drivers, sensor, etc. This structure does not immediately provide any nice way to add (larger) samples (or demo applications) that span across multiple subsystems.

Problem description

I want to add one or more samples that span across multiple subsystems. One such example is a headset which would use a combination of sensors, drivers, bluetooth, USB, audio subsystem, etc.

Proposed change

The proposal could one of the following:

  1. Add a new top-layer directory called applications or similar (similar to https://github.com/nrfconnect/sdk-nrf/tree/main/applications), which contains Zephyr based applications that go above and beyond what the smaller samples do.
  2. Add a new repository (similar to https://github.com/Azure/azure-sphere-gallery) that contain these example/reference applications

Or the solution could another one.

Detailed RFC

This RFC isn't more detailed than what has already been described.

Proposed change (Detailed)

This RFC isn't more detailed than what has already been described.

Dependencies

N/A

Concerns and Unresolved Questions

Adding larger applications that span across multiple subsystems will require effort from multiple maintainers to keep up to date and runnable/buildable. Furthermore, the applications will likely have requirements and dependencies that may restrict them to only a small subset of boards that may require additional addons/shields to work.

Another concern is that these applications may be looked at as reference designs, in which case it may take significant coordination between contributors to agree on how they should be designed.

Alternatives

The obvious alternative is of course to create a new repository outside of https://github.com/zephyrproject-rtos so as to disassociate the applications from the project itself, similar to how many other example applications have done (see https://github.com/golioth/awesome-zephyr-rtos for a list of some of these).

RalphCorderoy commented 9 months ago

applications means a few too many things, especially to a newcomer looking for a reference design to study and modify into what they need so I'd favour reference-design or similar.

kartben commented 9 months ago

applications means a few too many things, especially to a newcomer looking for a reference design to study and modify into what they need so I'd favour reference-design or similar.

I need to formulate a more articulate reply (lost the reply I had started typing a few days ago before getting a chance to submit, sorry for the delay @Thalley) but just to follow up on this specifically:

Calling these "reference-designs" is IMO a really bold claim, and would have direct implications on how/where we plan on hosting these. A "reference-design" would be, I think, expected to demonstrate best/references practices in every possible way we can think of, including how to best structure a downstream project building on top of Zephyr. In that regard, having the "apps" in the main Zephyr tree would not be ideal, and neither would having several apps in the same repo a la Sphere gallery, since I think we'd likely want to recommend an approach where the "app" is its own repo, with its own west.yml, etc. (T2 topology, a la example-application)

Thalley commented 9 months ago

Calling these "reference-designs" is IMO a really bold claim, and would have direct implications on how/where we plan on hosting these.

Agreed, that is a dangerous road to go on.

having the "apps" in the main Zephyr tree would not be ideal, and neither would having several apps in the same repo a la Sphere gallery, since I think we'd likely want to recommend an approach where the "app" is its own repo, with its own west.yml, etc. (T2 topology, a la example-application)

That's an approach I had not considered myself, but certainly makes sense. The downside of this is of course that the more repositories we use, the harder it is to ensure that they are properly updated, and the time/effort to maintain these increases.

kartben commented 5 months ago

@Thalley #72856 just got me thinking about this one again. Do you think we could get some kind of Bluetooth headset "real" app in time for 3.7? I know this is getting late already, but on the other hand I am quite certain you guys probably have such a demo app handy and bringing it upstream might not be all that hard (and ofc I am willing to help)

jori-nordic commented 5 months ago

What about going the other way, and having the main zephyr.yml pull in the zephyr-applications repo? This way we can easily test them against PRs to the zephyr tree, keeping the code up-to-date.

Thalley commented 5 months ago

Do you think we could get some kind of Bluetooth headset "real" app in time for 3.7? I know this is getting late already, but on the other hand I am quite certain you guys probably have such a demo app handy and bringing it upstream might not be all that hard (and ofc I am willing to help)

Nope :D At this point we (Nordic) cannot prioritize this over the actual missing features / necessary changes to the implementation.