Hi Matteo Golin： I see under `uorb/sensors` there are > lots of header and C files that just contain declarations for uORB types, > but these declarations already exist in the kernel. Why are they duplicated > in nuttx-apps?
1.We define all the uORB-related metadata for physical sensors under the directory nuttx-apps/system/uorb/sensor(by using ORB macro function:ORB_DEFINE、ORB_DECLARE). This metadata primarily describes the name of each topic, the size of its associated structure, and debug callback functions. And the structure definitions for these topics are placed in nuttx/include/nuttx/uorb.h, allowing kernel drivers to utilize them directly. 2. When we want to use a specific topic, such as the accelerometer topic, we simply need to include <sensor/accel.h> in our application and then use APIs like orb_subscribe to subscribe to it. However, this assumes that the accelerometer driver is functioning correctly. The main reason for separating them is that uORB is a user-layer SDK and is not utilized by the kernel. However, the structure definitions are required by both the kernel and user-space applications. Hence, they are placed within the kernel. Can anyone shine some light on why the `uorb/sensor` declarations are > necessary, and if it would be possible for me to create user space fusion > drivers in `uorb/fusion` with their own Kconfig file? Previously, xiangxiao suggested moving all sensor-related components to the *apps/sensor* directory. So, We could create a separate *apps/sensor/fusion/* directory under it, and within the fusion directory, we could establish our own Kconfig file. This fusion directory would be at the same level as the apps/sensor/uorb directory. I will submit a PR to move them, and we can have discussions under that PR. Matteo Golin <matteo.go...@gmail.com> 于2025年6月18日周三 02:34写道： > Hello, > > Was starting to work more on this today, but I'm confused about how the > `uorb` directory is currently set up. I see under `uorb/sensors` there are > lots of header and C files that just contain declarations for uORB types, > but these declarations already exist in the kernel. Why are they duplicated > in nuttx-apps? > > I was hoping to create a "fusion library", with userspace implementations > of uORB drivers using `usensor`. Something where the user can include this > library and choose which fusion nodes they want to register in their > application, *not* an example program that just runs and registers a > sensor. This way the user has full control. I was thinking about putting > this under `uorb/fusion`, but I want to include a Kconfig file so users can > enable/disable fusion drivers that they want to include using `menuconfig`. > I don't think I can put another Kconfig file in `uorb/fusion` since there's > already a Kconfig file in `uorb`, but I could be wrong. To me, this > location seems like the intuitive place to put fusion libraries, but I > don't want it conflated with the `uorb_listener` application since it's a > user-available library. > > Can anyone shine some light on why the `uorb/sensor` declarations are > necessary, and if it would be possible for me to create user space fusion > drivers in `uorb/fusion` with their own Kconfig file? > > Matteo > > On Fri, Jan 31, 2025 at 5:52 PM Tomek CEDRO <to...@cedro.info> wrote: > > > On Fri, Jan 31, 2025 at 10:56 PM Matteo Golin <matteo.go...@gmail.com> > > wrote: > > > Given the discourse around breakages in synchronization between the > > > nuttx-apps and nuttx repositories, I think I may begin adding new > > > applications to `apps/sensors` but I will hold off on moving any > already > > > existing sensor examples. In the coming days I expect to have something > > > functional for determining altitude from barometer data. > > > > Looks like someone missed something, or we didn't catch the problem on > > time with PR/CI, its clearly a bug not by design, but it seems easier > > to write emails than send actual patches :-) > > > > Keep your repos in sync, fear not, share your stuff, report problems > > when found any, have fun, if you plan to break existing stuff just > > create a separate application so everyone is safe :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
