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>
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>
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>
There's an increasing amount of slow logged topics at 1-2Hz, which were all
updated in the same logger iteration, leading to data bursts. For log
streaming this started to exceed uart buffer sizes. By distributing updates
more equal over time those bursts are removed, reducing buffer size
requirements.
Tests showed during steady state a reduction of maximum topic updates per
iteration from 40 down to 17.
Also the SD log buffer fill level is more constant.
This also simplifies the API a bit, since we anyway have to change the
drivers to pass additional information (the bus device index).
The orientation flag is merged with the rotation.
- sending protocol
- uorb event message & template methods for argument packing
- libevents submodule to send common events and handle json files
- cmake maintains a list of all (PX4) source files for the current build
(PX4 modules + libs), which is used to extract event metadata and
generate a json file
nxp_ucans32k146:Relocation for Bootloader
nxp_ucans32k146:can_boot enable CAN
nxp_ucans32k146:Save Space use Non Optimize memcpy
nxp_ucans32k146:Increase to 24K
nxp/ucans32k146:Canbootloader LED Driver
nxp_ucans32k146:Can bootloader shut down CAN
nxp_ucans32k146:Use NVMEEPROM for Paramaters
nxp_ucans32k146:Use bootloader AppDescriptor
px4 mtd:Support onchip emulated eeprom