This uses px4_task_spawn_cmd instead of pthread, since px4_task_spawn_cmd is already
made to start worker on proper side.
TODO: check that we don't accidentally run user-side code in kernel context in work queue.
The work items should be scheduled to work queues depending on whether the actual callback
is on kerne/user side.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Don't compare pointers to metadata, but the metadata contents.
In protected/kernel build there are two sets of metadata, on on kernel
side and another in user side. Thus the comparison of pointers would just
always fail. Compare orb_id instead
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
For protected/kernel builds the cxx static initializations
needs to be done also in kernel side, since px4 creates
c++ objects in kernel
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Since uORB is split into kernel and userspace parts, it is no longer possible to just
link uORB into px4_platform, which is used in both kernel and user side.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
When building uORB for NuttX flat build, or for some other target, everything
works as before.
When building uORB for NuttX protected or kernel build, this does the following:
- The kernel side uORB library reigsters a boardctl handler for calls from userspace
and services the boardctl_ioctls by calling the actual uORB functions
- For user mode binaries, the uORBManager acts as a proxy, making boardctl_ioctl calls to the
kernel side
- The uORBDeviceNodes are always allocated in user heap for protected build, so that they
are accessible from both kernel and user side. This is only for optimization, a few
functions such as "is_advertised" get really heavy when called frequently via ioctl
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Proxy all calls to the DeviceNode through Manager;
- This hides the DeviceNode from publishers and subscribers
- Manager can be made an interface class between user and kernel spaces in protected build
- This doesn't increase code size or harm the performance on flat build
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This adds a nuttx userspace interface for hrt driver, communicating with
the actual hrt driver upper half via BOARDCTL IOCTLs
This is be used when running PX4 in NuttX protected or kernel builds
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Add interface functions for fetching latency buckets and counters and use
those in perf_counter.cpp. This cleans up the usage of perf counters and
enables implementing kernel-userspace interface for those for
nuttx protected/kernel build.
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Add functions for reset and reboot, which can be called
from user space in nuttx kernel and protected build
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
The px4_userspace_init function in this library is called from userspace
entrypoint before starting NSH
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Split the px4_layer into user and kernel space libraries. Add some stubs for
user-space (e.g. version) where an interface to the kernel needs to be added
Use posix-versions for cpuload.cpp and print_load.cpp for userspace; these link to nuttx internals. This functinality could be built on top of posix (e.g. procfs) interfaces
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
For NuttX protected or kernel build, the prebuilds can't contain libraries which are
different for kernel and user-space in protected/kerenl builds
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
This is to avoid potential race conditions during startup.
All startup code runs sequentially atm, so this is just for robustness
for later (e.g. concurrent pwm_out and dshot start).
This allows modules to do a first-come-first-serve pin/timer reservation
on bootup.
E.g. camera trigger reserves any of the pins, and then PWM/DShot output
will just use the rest of the available pins.
When the last WorkItem is deleted, it is removed from a work queue and the
queue is being stopped. But, the queue itself might get deleted in the middle,
in a higher priority thread than where the WorkItem deletion was performed from
If the WorkQueue::Detach accesses the member variables after this, there is memory
corruption
This happens in particular when launching i2c or spi devices in
I2CSPIDriverBase::module_start:
- The "initializer" is deleted when the instance is not found and the iterator
while loop continues.
- The workqueue is deleted in the middle of "initializer" deletion when the
WorkQueueRunner returns.
This prevents deletion of the WorkQueue before the Detach has been finished,
in the specific case that the ::Detach triggers the deletion
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
Reduces CPU load by almost 1.5% @ 2khz on F4 and F7.
This changes the motor ordering on boards where the timer ordering does
not match the order of the timer usage in the channels defintion.
Only omnibus f4sd is affected.
Jukka Laitinen