* NuttX cmake
* px4_macros:Pass the stringified predicate as second arg to static assert
CC_ASSERT mapes to the c++ static_assert or provides the same
funtionality for c via the other macros. The c++ static assert
takes 2 argumants the prdicate and a message. This fixes the
lacking second argument.
* Updated nuttx and apps submodule to upstream nuttx 7.21+==master
This is the latest uptake of upstream nuttx and apps.
* ROMFS generate with xxd instead of objcopy
* delete nuttx-patches
* NuttX update submodules to latest px4_nuttx-master
* fix nuttx apps and board dependency
* docker_run update to latest container 2017-08-29
* cmake ROMFS portable sed usage
* NuttX update submodules to latest px4_nuttx-master
was:<nuttx/arch.h> is:platform/cxxinitialize.h
Removed PX4 version:src/modules/systemlib/up_cxxinitialize.c
in favor of nuttx platform/gnu/gnu_cxxinitialize.c
The V4 HW replaced the LTC4417 provided valid signal for USB.
with an active high, version. This commit configures the GIOP
and provides 1) a MACRO to read the pin and the IOCTL defines
to read it from the FMU. The macro result true logic: true
when the signal is high. The IOCTL read would be the actual
pin state.
Given the original poster's comment that "It happens very consistently for us." I suspect the motor spin observed in https://github.com/PX4/Firmware/issues/7457 is not caused by the original issue of slow decay on the PWM pins at reset, but the post reset pulse of 3.1 Ms arriving in a window that the ESC considers it valid.
The results from testing, indicated that the if the PWM pins were clamped low for > 300 Ms, prior to reset the motors did not spin. This would delay the the post reset pulse of 3.1 Ms out by > 300 Ms.
This change delays the reset and therefore the pulse by at least 400 Ms.
When the CCER is cleared the IO pin tends to float. The FMUV4
HW has no TXS0108 and if cut off while high will decay.
By adding the pull down the pins will seek the low state faster.
13.8 us from off to decabe below threshold.
Removed the legacy FMUv4 define that was activating a nonexistent
pull up and on some HW driving the PPM_IN aka RC_IN aka SPEKTRUM_RX
to VDD.
Also detailed the connections of this pins for the board.
The simplest connection is RC_IN to a timer capture pin
and a UART.
In this case the UART_RX pin and just be left as is.
While the pin can be configured as the PPM_IN (Timer capture)
or as SPEKTRUM_RX_AS_GPIO_OUTPUT to use it as and GPIO to
facilitate binding.
Renamed the macros and defines to be more explicit as to what
Is being done and the sense of the parameters
The fmu now support the commandline option to be run as a task
or off a work queue.
This reverts the board_config.h changes from commit
e33af23122f5ee3030bb9745bbbf616b24c2a14a.
Conflicts:
src/drivers/px4fmu/fmu.cpp
We need to protect access to the param_values array. This is dynamically
allocated and resized (utarray_reserve() calls realloc). If some thread
was iterating the array while another was resizing the array, the first one
would iterate on a freed array, thus accessing invalid memory.
On NuttX this could lead to hardfaults in rare conditions.
Unfortunately we need to initialize the semaphore on startup, by calling
sem_init(). This adds a param_init() method called by every board/config
that uses the params (at least I think I've found all of them)
boards define BOARD_NAME, so board_name() is not necessary. HW_ARCH was
just a wrapper around board_name().
This patch simplifies to having only one common method px4_board_name().
David Sidrane