The ADC_ADS1X1X_TRIGGER macro was defined without an explicit value,
preventing ALERT/RDY pin configuration even when alert_rdy_gpios
were properly defined in devicetree. This occurred because
the IF_ENABLED macro specifically requires macros to be defined as 1,
not just defined empty.
Fixed this by explicitly defining ADC_ADS1X1X_TRIGGER as 1 when
alert_rdy_gpios properties are present in devicetree.
Signed-off-by: Benjamin Geiger <BenjaminGeiger1@gmail.com>
Move all adc driver api structs into an iterable section, this allows us
to verify if an api pointer is located in compatible linker section.
Signed-off-by: Pieter De Gendt <pieter.degendt@basalte.be>
Some hardware configuration require rely on the ALERT/RDY
pin to know when and ADC conversion is completed.
The polling thread is left as fallback, when the pin
is not defined.
Signed-off-by: Efrain Calderon <efrain.calderon.estrada@gmail.com>
Fix the data acquisition thread function signatures to avoid a stack
corruption on thread exit.
Fixes#62637
Signed-off-by: Benedikt Schmidt <benedikt.schmidt@embedded-solutions.at>
"const k_tid_t" is "struct k_thread * const" and not "const struct
k_thread *" as the code may be assuming. Just drop it.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The macro K_THREAD_STACK_MEMBER has actually been deprecated
since v2.4.0 in the macro doxygen description, but it was
never marked with __DEPRECATED_MACRO. Since this was being
used in various drivers, make it follow the deprecation
process.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Fixes#61401
The ADS1x1x driver has a bad habit of assuming i2c operations will
always suceed - this fixes the two worse cases in the code I could
identify (there may yet be more).
* During initial ADC setup, if either of the two I2C operations
(read or write) fails, raise the error immediately to the caller
rather than letting it fall through to the acquisition thread.
This ensures that we only ever attempt to give a result that was
definitely connected to our attempt to start the capture.
* If the acquisition thread encounters an I2C error, raise the error
but do not terminate the aquisition thread. This ensures the
application can attempt to fix the condition that caused the I2C
error and try again.
Signed-off-by: Chris Collins <kuroneko@sysadninjas.net>
The pga enum internal reference voltage and gain values
were fixed in the code, but a comment was forgotten to be
updated. Correct the comment to match how the code uses
the enum.
Signed-off-by: Ryan McClelland <ryanmcclelland@meta.com>
The ADS1x13 does not have a PGA, and will have a fixed
internal reference voltage of 2048mV. This sets the internal
referece voltage for the ads1x1x to 2048 and adjust the gain
configuration to scale.
Signed-off-by: Ryan McClelland <ryanmcclelland@fb.com>
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>
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>
This adds support for the ads101x (ads1013, ads1014, ads1015) and
ads111x (ads1113, ads1114, ads1115) family of i2c adc devices.
Signed-off-by: Ryan McClelland <ryanmcclelland@fb.com>
