Commit Graph

6 Commits

Author SHA1 Message Date
Kenneth J. Miller e78e8d7c3f drivers: lora: sx126x: Support fine-grained STM32WL PA config
Add STM32WL-specific sx126x_set_tx_params function based on the
STM32CubeWL modifications to LoRaMac-node.

Add the "power-amplifier-output" DT property to
"st,stm32wl-subghz-radio" for selecting between the RFO_LP and RFO_HP
output configurations provided by the above mentioned function.

Add the "rfo-lp-max-power" and "rfo-hp-max-power" DT properties for
defining the maximum design power of the respective outputs' matching
networks.

closes #48511

Signed-off-by: Kenneth J. Miller <ken@miller.ec>
2023-04-24 13:33:25 +02:00
Gerard Marull-Paretas 178bdc4afc include: add missing zephyr/irq.h include
Change automated searching for files using "IRQ_CONNECT()" API not
including <zephyr/irq.h>.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-10-17 22:57:39 +09:00
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
Gerard Marull-Paretas fb60aab245 drivers: migrate includes to <zephyr/...>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 19:58:21 +02:00
Fabio Baltieri 23fbb19ed5 drivers: sx126x_stm32wl: clear the radio IRQ before reenabling it
The stm32wl version of the sx126x driver disables the NVIC interrupt in
the radio isr to prevent retriggering while the event gets handled in
the workqueue. Since the interrupt condition is still present while the
line is disabled, the interrupt pending bit remains set in the NVIC, so
after the handler finished, when irq_enable() gets called, the interrupt
fires immediately again with no status bit set in the radio registers.

Apart from the no-op interrupt, this has the side effect of bringing
the radio out of sleep as soon as the interrupt bit are read and
cleared, which increases the idle state power consumption.

Adding a NVIC_ClearPendingIRQ() before irq_enable() seems to fix the
problem. It should not cause any issue with missing interrupt events, as
if there are pending bit on the Radio, the NVIC pending bit would be
re-set immediately.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
2021-09-22 21:10:05 -05:00
Fabio Baltieri accb71ec9e drivers: sx126x: add support for the stm32wl chip
Add support for the STM32WL integrated radio, based on the sx1262. The
STM32WL implementation does not use any GPIO, and the signals are routed
to other units of the SoC and accessed with the ST HAL.

Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
2021-07-15 21:30:28 -04:00