According to the reference manual, the ADC should not be
converting when setting the common path, we disable the adc
directly in this driver for the sake of simplicity.
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Remove unnecessary VREFINT path connection during the init.
Internal paths should be setup before reading the channel.
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
Move the `adc_stm32_setup_channels` function to `start_read`
so that we can guarantee that the internel path is connecte
before reading.
Signed-off-by: Yong Cong Sin <yongcong.sin@gmail.com>
The VREFINT and TEMPSENSOR internal channels have a stabilization time
after they are enabled. Right now this just causes the first measure to
be a bit off, however with PR #47691 which stops the internal channels
after each readout, this is something important to respect. Fortunately
the stabilization time is available as constants in the HAL, so just
wait the time specified by the constants.
Note that the VBAT internal channel does not have any stabilization
time.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
This commit avoid re-enabling the ADC,
because this starts conversion.
According to the RefMan (RM0008) of the stm32F10x mcu,
enabling the ADC will start the conversion
if the ADC is already enabled. "Conversion starts when
this bit holds a value of 1 and a 1 is written to it."
That's not what we want.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The value is unused in this structure is unused and can be accessed
through the adc_ref_internal() function.
This saves 4 bytes of SRAM.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Allow the battery voltage to be read through the ADC even if the
CONFIG_STM32_VBAT driver is not enabled.
I guessed this part of code is conditionally compiled depending on
CONFIG_STM32_VBAT because this feature, and hence the
LL_ADC_CHANNEL_VBAT constant is not available on all families. As the
feature is already checked at runtime (as the same driver supports
multiple instances), we can conditionally compile it depending on
LL_ADC_CHANNEL_VBAT instead.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Fix indentations of `adc_stm32_oversampling` function comments
to have everything aligned properly.
Signed-off-by: Bartosz Bilas <bartosz.bilas@hotmail.com>
According to the ES0418 about the ADC of the stm32G071
or other stm32g0x devices:
for sampling time set to 1.5 or 3.5 cycles,
the sampling in a single ADC conversion or in the first
conversion of a sequence takes one extra cycle.
Minimizing to 7.5 is fine.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
There is a build warning of unused `adc_stm32_oversampling_ratioshift`
function: [-Werror=unused-function]. This makes twister fail, as all
warnings are treated as errors.
Fix that by ifndef'ing adc_stm32_oversampling_ratioshift().
Fixes: c57a41c5d2 ("drivers/adc: stm32: do not disable the ADC if
resolution is unchanged")
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
It allows the path for VBATEN on stm32 series
to monitor the Vbat voltage, in case of CONFIG_STM32_VBAT
Add the common Vref value as a property of the ADC.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
In case the resolution is already correct (probably the common use
case), do nothing instead of disabling the ADC.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The ADC is currently disabled and re-enabled multiple time during each
read. Enabling the ADC is not a free operation on some series and some
internal channels like VREFINT take even longer. This patch improve the
situation by removing the calls to adc_stm32_enable(), replacing it by a
single call just before triggering the conversion.
This also open the possibility to not reconfigure the ADC if it is
already configured, implemented in the following patches.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
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>
Refactor code so that an unused variable 'adc' warning
is not generated when building for CONFIG_SOC_SERIES_STM32G4X
and not using adc1 or adc5.
Signed-off-by: Sam Hurst <sbh1187@gmail.com>
G4 series have specific LL ADC API that discriminate ADC1 and ADC5
channels. Take this into account in adc_stm32_setup_channels().
Additionally, fix this function to use LL defines as argument of macro
__LL_ADC_CHANNEL_TO_DECIMAL_NB, as good practice.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Use the devicetree properties to determine if the dedicated temperature or
voltage reference channels should be configured for the ADC.
Fixes#43750.
Signed-off-by: Benedikt Schmidt <benedikt.schmidt@embedded-solutions.at>
This change includes special handling of the internal voltage
reference and internal die temperature channels for all currently
defined STM32 models
The code now looks for specific ADC + channel ID pairs instead
of just a channel ID to determine if the caller is trying to
configure an internal channel.
Signed-off-by: Pete Dietl <petedietl@gmail.com>
Some drivers explicitely casted data/config from void * to the
corresponding type. However, this is unnecessary and, in many drivers it
has been misused to drop const qualifier (refer to previous commits).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Clear ADRDY before enabling ADC to ensure the subsequent
wait for ADRDY does not stop prematurely in case ADRDY
was already set.
The "ADC on-off control" sections of the following reference manuals
were consulted. That gives at least one instance per series affected
by this change, even if not every affected MCU is covered.
- RM0438 (STM32L552xx and STM32L562xx)
- RM0351 (STM32L47xxx, STM32L48xxx, STM32L49xxx and STM32L4Axxx)
- RM0434 (STM32WB55xx and STM32WB35xx)
- RM0454 (STM32G0x0)
- RM0440 (STM32G4 Series)
- RM0399 (STM32H745/755 and STM32H747/757)
- RM0433 (STM32H742, STM32H743/753 and STM32H750)
- RM0453 (STM32WL5x)
Signed-off-by: Alexander Mihajlovic <a@abxy.se>
Use a wrapper for LL_ADC_Enable that also waits for ADRDY if required
by the SoC to make sure it's properly enabled everywhere this is done.
Signed-off-by: Alexander Mihajlovic <a@abxy.se>
Certain stm32 soc's have a single shared irq for all adc channels
on those soc's only a single channel is supported.
Added a Kconfig that enables a shared irq for stm32f2x, stm32f4x,
stm32f7x soc's. The shared IRQ uses a flag to limit the number of
interrupts defined to only 1. A shared irq handler is added which
determines which ADC instance the interrupt is for, it then calls
into the existing interrupt.
Signed-off-by: Marius Scholtz <mariuss@ricelectronics.com>
RM 0453: the sw is allowed to write the Oversampling
ratio or shift of the ADC Config.Reg.2 only when ADSTART = 0
(no conversion is on-going). So disabling it will be stopped.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
RM 0453: the sw is allowed to write the Data Resolution bits
of the ADC Config.Reg.1 only when ADEN = 0 (ADC disable).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The PINCTRL_DT_(INST_)DEFINE macros already defined the trailing ;,
making its usage inconsistent with other macros such as
DEVICE_DT_DEFINE.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The STM32 docs state that the ADC may not be calibrated unless
the ADC is disabled (ADEN=0). This commit implements this constraint
Fixes#40936
Signed-off-by: Pete Dietl <petedietl@gmail.com>
The STM32U5x device has ADC instance of different versions
similar to the stm32H7 about the oversampling.
ADC1 of 14bit resolution has a ratio from 1..1024 on OSR[9:0]
ADC4 of 12bit resolution has a ratio on OVSR[2:0]
Signed-off-by: Francois Ramu <francois.ramu@st.com>
This commit extends the configuration of the oversampling
ratio and shift for the stm32U5xx soc, depending on the
ADC instance: ratio is a value from 1..1024 or a LL_ADC_OVS_RATIO_x
to be used with the stm32Cube LL function.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
On the stm32H7 family, there are ADC which have Oversampling ratio
of 10 bits OSVR[9:0] in the CFGR2 register. It means that oversampling
512x or 1024x are possible.
Other values are not allowed as the oversampling field of the struct
adc_sequence (adc.h) is 2^oversampling.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The adc_stm32_oversampling function is used to configure
the ratio and shift for each sequence->oversampling
depending on the soc serie and ADC instance in the serie
In the stm32H7 serie, only ADC3 of ADC_VER_V5_V90 version
have a LL_ADC_OVS_RATIO_x contant (other a 9bit value).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Change the access to the PCSEL register by using the LL function
because on the STM32H7xx soc, some devices have no PCEL register
especially on ADC3 of the stm32H723.
The LL function manages this difference.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
Refactors all of the ADC drivers to use a shared driver class
initialization priority configuration, CONFIG_ADC_INIT_PRIORITY, to
allow configuring ADC drivers separately from other devices. This is
similar to other driver classes like I2C and SPI.
The default is set to CONFIG_KERNEL_INIT_PRIORITY_DEVICE to preserve the
existing default initialization priority for most drivers. The
exceptions are lmp90xxx, mcp320x, and mcux_adc16 drivers which have
dependencies on GPIO, SPI, and/or DMA drivers and must therefore
initialize later than the default device priority.
Signed-off-by: Maureen Helm <maureen.helm@intel.com>
Setting Oversampling also applies on stm32L5 but disabling
the ADC will cause endless loop except for the stm32L0 serie.
Errata applies only on stm32G0 soc series when
writing ADC_CFGR1 register.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
On those STM32 series, setting of this feature is conditioned to
the ADC state: it is allowed to set/reset the oversampler (OVSE bit)
and set the Oversampling ratio (OVSR bits) in the ADC_CFGR2 register
only when ADC is disabled or enabled without conversion on going.
Then is the ADC re-enabled.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
On those STM32 series, setting of this feature is conditioned to
the ADC state: it is allowed to write the Data resolution (RES bits)
in the ADC_CFGR1 register only when ADC is disabled (ADEN=0).
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The LL_ADC_ConfigOverSamplingRatioShift function for
the stm32H7xx soc serie differs from other for the 'ratio':
"This parameter can be in the range from 1 to 1024"
Note that in the stm32h7xx_ll_adc.c the LL_ADC_OVS_RATIO_xxx value is
defined for ADC of type ADC_VER_V5_V90.
Signed-off-by: Francois Ramu <francois.ramu@st.com>
The STM32 G0, G4, H7, L0, L4, WB and WL series have hardware support for
oversampling. This patch adds support for it, using the oversampling
value provided in the adc sequence. The result is shifted right
accordingly to not change the resolution of the measured value, like it
is done on other ADC drivers.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Commit c045cbd336 added support for internal voltage reference source,
but in practice only the temp sensor is supported. Fix that.
Also change the code to keep the existing paths so that VREFINT and
TEMPSENSOR can be used at the same time.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The patch fixes driver compile errors and ADC management for the f3x
series. It was developed and tested for the stm32f373 variant.
Tested-by: Dario Binacchi <dariobin@libero.it>
Signed-off-by: Dario Binacchi <dariobin@libero.it>
The STM32H7 series has a special ADC, which is calibrated
on the factory. The calibration values are stored in flash
and must be retrieved upon powering up the device.
Failure to calibrate the device leads to missing codes in
the ADC readings.
Fixes#35529
Signed-off-by: Lasse Sangild <lsangild@gmail.com>
Since we removed various series headers, move stm32 driver
under main driver/pinmux folder.
Take this change into account into various drivers.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add ADC support for the STM32WL family, this seems to work following
most of the L0X code path.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
