Move the kernel documentation up and make it a main chapter. Right now
it is hidden very low in the structure under references.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This reverts commit b1ad97bc26 since it
causes the following build failure:
cc1: error: requested ABI requires '-march' to subsume the 'F'
extension
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Extend Altera Jtag Uart driver support without Altera HAL driver
by default. uart_altera_jtag_hal.c renamed to uart_altera_jtag.c and
new config, CONFIG_UART_ALTERA_JTAG_HAL is introduced to allow driver
to use Altera HAL driver when needed.
Signed-off-by: Khor Swee Aun <swee.aun.khor@intel.com>
Only compile in async related code when at least one UARTE instance has
enabled async mode. This fixes an "unused function" warning when
`CONFIG_UART_ASYNC_API` is enabled but no UARTE instances has async
enabled. This is possible when the async API is being used for an RTT
UART driver.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
There is a typo (s/ares/area/).
More importantly, there are examples of areas with this status that do
not have any collaborators:
- Drivers: Interrupt controllers
- Little FS
Fix the text to reflect reality.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
CONFIG_NET_L2_PPP_MAX_TERMINATE_REQ_RETRANSMITS
was not having any impact and
CONFIG_NET_L2_PPP_MAX_CONFIGURE_REQ_RETRANSMITS
was used incorrectly instead for terminate().
Signed-off-by: Jani Hirsimäki <jani.hirsimaki@nordicsemi.no>
Add simple test of the can_set_state_change_callback() API. It is not
possible to trigger a change of state, but at least test the API call
with and without a callback function.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Checks that the server returns "Database Out Of Sync" error on two bearers
when the client is change-unaware and returns success after the database
hash has been read.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
Core spec version 5.2 introduced EATT, and multiple ATT channels on one
connection is now possible. The requirements for when a client
becomes change-aware were updated to reflect this.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
Pass a copy of outbound argument structs to the implementation functions
as recommended for Zephyr system calls.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
The CIG was improperly handled by the unicast
client. It attempted to remove the CIG when an ACL
was disconnected, and did not properly use the
cig_reconfigure function.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The endpoint will likely be in the idle state when
we first read the ASE state. In that case we have
not yet attached a stream to the endpoint, and
thus should not request the stream to be released when it
is NULL.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This adds initial support for Hearing Access Service client. The client
performs GATT discovery to find and read HAS related characteristics and
subscribe for characteristic value notifications/indications.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
The above mentioned fix attempts to detect the situation when
bt_att_req_alloc() is invoked on the same thread that runs
att_handle_rsp. It attempts to do so by noting the thread that
first ran bt_recv, assuming the same thread will house all calls
to bt_att_req_free. This turns out not to be correct. It is
evident from the call stack provided below that bt_att_req_free
can be called from other threads than the one that runs bt_recv.
Fixes: #43448
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Making sure struct bt_l2cap_chan has absolutely no members related
to dynamic channels.
That way we ensure that there is no overhead for a build where only
fixed channels are used.
It's not enough that the dynamic channel-related members are put behind
ifdefs - they should be completely moved out from the struct definition.
Furthermore, the public l2cap.h header file already has a struct
that's meant to be used for dynamic channels: struct bt_l2cap_le_chan!
However, currently dynamic channel support is a mess - it's a mix
between these two structs. The bt_l2cap_le_chan struct should really
be an extension of the bt_l2cap_chan struct, i.e. the former should
contain as a member the latter.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Add the period cell to GD32 PWM compatible and update all boards
accordingly. A period of 20 ms (50 Hz) has been set for all PWM LEDs.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Samples should run on a board if they have the peripheral connected, in
this case, if any LED on the board is connected to a PWM output. A
shield could be used to demonstrate a sample on a board that doesn't
have the required peripheral. In this case, it was also unclear where
that "external LED" had to be connected, unless one checks where channel
1 for PWM1 is routed to. All board LEDs are connected to pins that
cannot be driven by PWM.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The board had PWM LEDs defined in the blinky_pwm sample, mainly because
it conflicts with SPI1 pinmux. A better approach is to still define the
PWM LEDs in the board but keep the PWM controller disabled by default.
Then, samples just need to enable the PWM controller (and disable SPI if
used simultaneously).
Also updated period to 20ms (reasonable value for a PWM-driven LED).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
While the pwm-led0 alias may exist, it could happen that the node with
pwm-leds compatible is disabled, making the sample fail compilation.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
STM32 supports now custom PWM flags, include them by default as done for
the standard flags.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
All these sort of helpers were removed from tree a while ago, this one
was missed as it uses a custom name.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
If dev was null, caller would have faulted before since dev->api needs
to be accessed before reaching this point. Also, a well-defined device
will never have a NULL dev->config.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The API spec states that calling pin_set() with period set to 0 is
equivalent to set the PWM channel to an inactive level. Some drivers
treat this input as invalid (-EINVAL), however, it's an unsupported
feature. Maybe it's due to copy&paste effect? This changes error message
to be clear and changes return value to -ENOTSUP for this case.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The API call checks for this condition before calling the pin_set driver
OP call, so drivers don't have to do this check now.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Calling pwm_pin_set_cycles with a pulse > period doesn't make sense. By
definition, pulse ranges from 0 up to the period value.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The "node label" reference in the Devicetree introduction used the
overloaded term "label". Use "node label" consistently and add a
paragraph noting that "node label" and "label" properties are distinct.
Signed-off-by: Keith Short <keithshort@google.com>
All peripherals used by lpcxpresso55s69 support pinctrl driver, so
remove pinmux settings. Pinmux file is retained for board specific I2S
loopback configuration.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
LPC gpio driver now supports pinmux setting in gpio_pin_configure, so
remove the pinmux workaround for this platform in gpio_basic_api test.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Pinmux initialization function for lpcxpresso55s69 was setting user
button gpios as pullups, now that pin control will be used these
settings should be handled by the GPIO driver.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
