Address issue where the timing source is not stopped upon step completion
and not adjusting the actual position after performing a step.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
Adds a fallback for the dual-edge-step property in the step dir common
code. Without this drivers using the common code would have to declare the
dual-edge-step property so it can default to false when not set, even if
the IC does not support adjusting it.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
The status variable stores the return value of `net_recv_data`, which
is an `int` and may be negative.
Signed-off-by: Martin Jäger <martin@libre.solar>
Adds a timing source api which is used by the step-dir stepper common code.
This allows the reusable common code to configure different timing sources,
since the initial delayable work implementation was inacurate for higher
maximum velocities.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
Use the shell_device_filter utils method and leverage the new api classing
to only suggest stepper devices via tab-complete within the shell.
Signed-off-by: Fabian Blatz <fabianblatz@gmail.com>
The LIS2DUXS12 is a smart, digital, 3-axis linear accelerometer whose
MEMS and ASIC have been expressly designed to combine the lowest current
consumption possible with features such as always-on antialiasing
filtering, a finite state machine (FSM) and machine learning core (MLC)
with adaptive self-configuration (ASC), and an analog hub / Qvar sensing
channel.
(https://www.st.com/en/mems-and-sensors/lis2duxs12.html)
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Prepare the driver to be able to handle other DUX software compatible
devices. Currently the driver handles the st_lis2dux12 compatible only.
Do following major changes:
1. Introduce the lis2dux12_chip_api structure filled with device specific
APIs. At the moment define following callback:
- api_lis2dux12_set_odr_raw()
- api_lis2dux12_set_range()
- api_lis2dux12_sample_fetch_accel()
- api_lis2dux12_sample_fetch_temp()
- api_lis2dux12_handle_interrupt()
- api_lis2dux12_init_interrupt()
2. Prepare specific APIs for st_lis2dux12 device.
3. Make DT instantiation on inst + name basis, and not only by inst. This
commit only use "name = DT_DRV_COMPAT = st_lis2dux12".
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Regardless of the argument specified, it always references the
property of the 0th, so it was corrected to reference the instance
specified by the argument.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
For a 16-bit data bus, "DT_INST_PROP_LEN(n, data_gpios)" returns 16
which is equals "MIPI_DBI_MAX_DATA_BUS_WIDTH(16)".
As a result, the assertion will always be triggered.
Use a "<=" condition for the assertion instead.
Signed-off-by: Hua Zheng <writeforever@foxmail.com>
Command "waitms 50" on ChromeBook EC console, then it will crash EC.
Because arch_busy_wait() is re-entried by two different tasks,
the second calling will reset the timer and may cause the first
calling to fail to reach the waiting destination
(if the first calling's wait time is longer enough).
Verified by follow test pattern:
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_api
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_error_case
west build -p auto -b it8xxx2_evb tests/kernel/timer/timer_monotonic
west build -p auto -b it8xxx2_evb tests/kernel/timer/starve
west build -p auto -b it8xxx2_evb tests/kernel/context
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Add empty function stubs to support building with the newly introduced
CONFIG_BUILD_ONLY_NO_BLOBS option.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
The address passed in to the function was incorrect causing
failures when porting to RT1180.
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
For the lists of properties passed as a pointer to the get_props and
set_props functions, there is no reason to not make the pointer const as
the called functions will not and should not alter the pointed-to data.
In practice, not having the pointers const can cause compilation errors
if trying to pass in a const array of properties.
Signed-off-by: Mikkel Jakobsen <mikkel.aunsbjerg@escolifesciences.com>
Use uint64_t instead of uint32_t for the FLASH_STM32_EX_OP_SECTOR_WP
extended operation.
Some chips have two banks, more than 16 sectors each e.g. stm32h7a3xx
chips, so more than 32 bits are required.
Signed-off-by: Dawid Niedzwiecki <dawidn@google.com>
Fixed bug calculating offset of registers after unused space in the ADC
register space for the SZ package parts.
Signed-off-by: Jeff Daly <jeffd@silicom-usa.com>
Avoid referring to Pico 2 (the name of a board). In this context,
RPI_PICO is used to refer to the (Zephyr) `SOC_FAMILY` rather than the
Pico 1 board. This clarifies common numerical values between the RP2040
and RP2350 SoC series, and enables existing DTS files to be used with
RP2350-based boards with fewer changes.
Remove the use of Zehpyr's `CONFIG_` macros from the device tree files,
and replace them with `SOC_SERIES`-specific files. Update the driver
implementation to conditionally include the correct file. Update
documentation and samples to match.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The RP2350 SoC series contain two timer peripherals. Extend the driver
to support using the second timer (`TIMER1`).
N.b. this requires a fix from the Pico SDK to be patched into
hal_rpi_pico. See https://github.com/raspberrypi/pico-sdk/pull/1949 .
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
The watchdog register configuration of RP2350 differs from that
of RP2040, so we make fit that.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Unlike the RP2040, the RP2350 has multiple tick generators that need to
be started. Start TIMER0 and TIMER1 tick generators during
clock_control_init.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Extend the existing driver to add some initial support for the new SoC,
whilst maintaining compatibility with the RP2040.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
RP2350 is Raspberry Pi's newest SoC. From the datasheet:
"RP2350 is a new family of microcontrollers from Raspberry Pi that
offers significant enhancements over RP2040. Key features include:
• Dual Cortex-M33 or Hazard3 processors at 150 MHz
• 520 kB on-chip SRAM, in 10 independent banks
• 8 kB of one-time-programmable storage (OTP)
• Up to 16 MB of external QSPI flash/PSRAM via dedicated QSPI bus
...
"
This commit introduces some changes to support the existing RP2040 and
what is describe by Raspberry Pi as the "RP2350 family". Currently there
are 4 published products in the family: RP2350A, RP2350B, RP2354A, and
RP2354A. Within Zephyr's taxonomy, split the configuration as follows:
Family: Raspberry Pi Pico. This contains all RP2XXX SoCs,
SoC Series: RP2040 and RP2350.
SoC: RP2040 and, for now, just the RP2350A, which is present on the Pico
2, where the A suffix indicates QFN-60 package type. This structure is
reflected in `soc/raspberrypi/soc.yml`, and somewhat assumes that there
won't be a RP2050, for example, as a RP2040 with more RAM.
This is foundation work ahead of introducing support for Raspberry Pi's
Pico 2 board, which is fitted with a RP2350A and 4MB of flash.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
Add support for SoC-specific clock ids and update the initialization
function to support the existing RP2040 and add support for the RP2350.
clock_control_rpi_pico.c uses numerical values for clock ids taken from
rpi_pico_clock.h which are the "clock generator". For the RP2350 these
values are different for some of the same logical clock sources, as well
as the RP2040 and RP2350 having different clock sources available.
Signed-off-by: Andrew Featherstone <andrew.featherstone@gmail.com>
XIP prefetching seems to still be running, even while interrupts are
disabled. Therefore it is important to wait for the FlexSPI to be idle
before performing a write/erase operation.
Signed-off-by: Martin Stumpf <martin.stumpf@vected.de>
Add a GPIO driver for the Microchip MEC5 HAL based chips.
Current devices are: MEC174x, MEC175x, and HAL version of
MEC172x named MECH172x.
Signed-off-by: Scott Worley <scott.worley@microchip.com>
This adds initial support for NXP SDMA controller. We make use
of NXP HAL to configure the IP.
SDMA uses BD (buffer descriptors) to describe a transfer. We create
a cyclic list of descriptors and trigger them manually at start and
later when data is available.
This is tested using Sound Open Firmware app on top of Zephyr.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
- rename enable-gpios to en-gpios in adi,tmc2209
- place en-gpios in common stepper-controller.yaml
Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>
IRQ 1 is reserved for WiFi in ESP-IDF, which is used as the basis
for the Espressif HAL in Zephyr.
If IRQ 1 is used by Zephyr and too many other peripherals (e.g.
multiple UARTs) are enabled, WiFi stops working.
Marking IRQ 1 as "not available" seems to fix the issue.
Fixes#82874
Signed-off-by: Martin Jäger <martin@libre.solar>
The DHT[11/22] sensor driver fails to read data due to an extra
"gpio_pin_set_dt" that is occurs prior to waiting for the sensor active
response. This leads to consistent failed reads on esp32 (devkitc,
wrover). After removing this line reads are consistently successful.
Signed-off-by: Omar Naffaa <omarnaffaa.on@gmail.com>
Fast SPIM instances (SPIM120 and SPIM121) for correct operation require
the highest frequency from the global HSFLL. This commit adds needed
clock controller requests to the driver. When the runtime device power
management is enabled, the frequency is requested as long as the SPIM
is resumed, otherwise it is requested for the duration of transfers.
This commit also adds a missing call to `pm_device_runtime_put()` when
SPIM reconfiguration fails.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
This is a follow-up to commit fe0e2dbc60.
If `nrf_clock_control_request_sync()` ends up with a timeout, before
returning it must cancel the request that was not fulfilled on time.
Otherwise, the request may actually finish successfully a bit later,
but the caller will not be aware that the clock needs to be released
(since the call resulted in an error). And actually even more serious
problem is that because the `req` structure is placed on stack, after
the function returns, the contents of this structure will be probably
overwritten with some other data, so if the request finishes at that
point, an attempt to execute the callback function pointed by this
structure will most likely cause a crash.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
coverity complains of a missing break statement in SENSOR_CHAN_ALL case
this is fixed by adding __attribute__((fallthrough))
Signed-off-by: Jilay Pandya <jilay.pandya@outlook.com>
The LoRa driver does not allow to pass void* user_data to callback in
lora_recv_async function. This leads to complex way of using the API. This
commit fixes the issue and adds the field to the function and to the
callback.
Signed-off-by: Aleksander Dejewski <aleksander.dejewski@gmail.com>
Rename "nxp,kinetis-ftm-pwm" compatible to "nxp,ftm-pwm" to remove the
device family from its name.
Signed-off-by: Manuel Argüelles <manuel.arguelles@nxp.com>
Propagate bit ordering and type of CS pin to HAL layer. Previously,
the driver assumed MSB first and EUSART hardware CS control.
Signed-off-by: Aksel Skauge Mellbye <aksel.mellbye@silabs.com>
