-
|
I've been trying to enable the ADC driver to use it with my external ADS1015 IC, but I haven't been able to succeed so far. The sample application is unfortunately only using the internal ADCs of the MCUs, so I don't have a good reference on how to do it. I'm targeting an ESP32 custom board. First things first, this is how my overlay looked like in the beginning: &i2c0 {
lis2dh@18 {
compatible = "st,lis2dh";
label = "LIS2DH";
reg = <0x18>;
irq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;
disconnect-sdo-sa0-pull-up;
};
ads1015@48 {
compatible = "ti,ads1015";
#io-channel-cells = <1>;
reg = <0x48 >;
};
};So far so good, I could get the device using the DEVICE_DT_GET_ANY // Initialize an ADS1015 driver
const struct device *adc_dev = DEVICE_DT_GET_ANY(ti_ads1015);
if (adc_dev == NULL)
{
LOG_ERR("Failed to get ADS1015 ADC device binding\n");
return;
}But then I have to be able to configure the individual channels of the ADC, so I tried doing it how it is shown in the sample for the ADC driver. So I thought I should add the channel subnode below the ADC &i2c0 {
lis2dh@18 {
compatible = "st,lis2dh";
label = "LIS2DH";
reg = <0x18>;
irq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;
disconnect-sdo-sa0-pull-up;
};
ads1015@48 {
compatible = "ti,ads1015";
#io-channel-cells = <1>;
reg = <0x48 >;
channel@0 {
reg = <0>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_INTERNAL";
zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
zephyr,resolution = <12>;
};
};
};But I have the feeling that this is not the correct way, because I then get a weird devicetree error devicetree error: 'reg' property in <Node /soc/i2c@3ff53000/ads1015@48/channel@0 in 'C:/Users/NikosAgianniotis/hvac-iot/zephyr/misc/empty_file.c'> has length 4, which is not evenly divisible by 12 (= 4*(<#address-cells> (= 2) + <#size-cells> (= 1))). Note that #*-cells properties come either from the parent node or from the controller (in the case of 'interrupts').Has anybody tried it or has a good bet on how to do it properly? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 10 replies
-
|
To reply my own question, I think I found the answer. The following worked just perfect (at least I can build, I haven't tried it on a real hardware to see if it works yet) and if I understand it correctly, I think the problem was that I was missing the two parameters "#address-cells" and "#size-cells". &i2c0 {
lis2dh@18 {
compatible = "st,lis2dh";
label = "LIS2DH";
reg = <0x18>;
irq-gpios = <&gpio0 29 GPIO_ACTIVE_HIGH>, <&gpio0 30 GPIO_ACTIVE_HIGH>;
disconnect-sdo-sa0-pull-up;
};
i2c_adc: ads1015@48 {
compatible = "ti,ads1015";
reg = <0x48>;
#io-channel-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_VDD_1";
zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
};
channel@1 {
reg = <1>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_VDD_1";
zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
};
channel@2 {
reg = <2>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_VDD_1";
zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
};
channel@3 {
reg = <3>;
zephyr,gain = "ADC_GAIN_1";
zephyr,reference = "ADC_REF_VDD_1";
zephyr,acquisition-time = <ADC_ACQ_TIME_DEFAULT>;
};
};
}; |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I had a similar problem with another ADC module and your solution helped me - the project is building. I'd like to know if you've managed to use this with real hardware and if so, how did you refer to the individual channels of the external ADC in the code, because I'm having trouble with this? |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm happy my post helped you. The thing is that in the end I abandoned the idea of using this driver and just wrote my own library that accesses the ADC. In my opinion the driver for this specific ADC is a bit cumbersome to work with. The main thing I realized was that in reality the driver treats the ADC as an one-channel ADC. At least this is what I understood by going deep into the driver source code. I think additional channels, other than the first one, are practically ignored. Therefore the only way to get samples from all channels is to create different adc_channel_cfg structures and change the input_positive parameter to reflect the number of MUX input you want. But I'd be interested to know if you have a different understanding of how the driver is structured and if you manage to make it work. |
Beta Was this translation helpful? Give feedback.
-
|
I was using different external ADC, MCP3204 in my case, and yesterday I've managed to read data from all of its channels doing everything step by step, because I couldn't use |
Beta Was this translation helpful? Give feedback.
-
|
Happy to hear that! Can you clarify a bit what you mean by "step by step"? Did you also use your own library? |
Beta Was this translation helpful? Give feedback.
-
|
No, I used driver from Zephyr, but I have to manually fetch all channels data, setup the device etc., not just by using |
Beta Was this translation helpful? Give feedback.
-
|
Got it, thanks |
Beta Was this translation helpful? Give feedback.
-
|
Hi, have the same issue with an ADS1115. I configured everything like you but the ADC shell command doesn’t list the ADC (only the internal one), not sure how to proceed from here, there must be a way… |
Beta Was this translation helpful? Give feedback.
-
|
It is really cumbersome to work with the driver. And as I wrote some months ago, the driver treats the ADC as one channel ADC, which is not exactly true. I personally gave up and made my own version of it. It's not a proper Zephyr driver, but rather a library. But it seems to work. |
Beta Was this translation helpful? Give feedback.
-
|
Okay I finally made it work, for reference here is my device tree overlay: But indeed only channel 0 is supported, that is SO weird… I guess I’m also gonna have to DIY a library on the side for now… For whatever reason it also doesn’t show up when typing the |
Beta Was this translation helpful? Give feedback.
-
|
@GilDev Im using the ads1112 from TI and I want to enable the driver n zephyr, but there is no example or something else. Reading the Kconfig of this device I can see that it needs CONFIG_ADC=y and also depends on DT_HAS_TI_ADC_ADS1112_ENABLED....where do I set this devicetree entry? in the source file? |
Beta Was this translation helpful? Give feedback.
-
|
I ended up also writing my own basic library. This driver is not complete and Zephyr has a too steep learning curve for me to do it better right now sadly… |
Beta Was this translation helpful? Give feedback.
-
|
DT_HAS_TI_ADC_ADS1112_ENABLED is set when you add node compatible with it
to your device tree overlay and set its status to "okay"
czw., 19 wrz 2024, 20:58 użytkownik Gaston ***@***.***>
napisał:
… @GilDev <https://github.com/GilDev> Im using the ads1112 from TI and I
want to enable the driver n zephyr, but there is no example or something
else. Reading the Kconfig of this device I can see that it needs
CONFIG_ADC=y and also depends on DT_HAS_TI_ADC_ADS1112_ENABLED....where do
I set this devicetree entry? in the source file?
—
Reply to this email directly, view it on GitHub
<#61960 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BBYUXKK7JMHE7V3JVKE254TZXMNGDAVCNFSM6AAAAAA4BFIIUCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRZG4YDEMA>
.
You are receiving this because you commented.Message ID:
***@***.***
.com>
|
Beta Was this translation helpful? Give feedback.
-
|
@hubert-tt thansk for ur help --- this is really frustating and I'm just starting with zephyr , and i see a long long road ahead of me.
|
Beta Was this translation helpful? Give feedback.
-
|
@GastonMelo I suppose you've made your own external out-of-the-tree driver? You're just missing this file the error message is mentioning. This has to be present in the same directory as your At least this is what has worked for me, I don't know if there is a better way that avoids this. |
Beta Was this translation helpful? Give feedback.
-
|
I must say that I have now decided to switch back to the upstream driver. I think it more or less works fine with ADS1015, one just needs to know that the driver assumes there is only one channel. This is in essence correct, as the other channels are "artificially" created with the MUX, but the ADC core has one channel. Thus, the user only needs to define the device in the devicetree and then before each conversion, the ADC needs to setup the correct channel through the MUX (the driver is up for the job, the user needs to use |
Beta Was this translation helpful? Give feedback.
To reply my own question, I think I found the answer. The following worked just perfect (at least I can build, I haven't tried it on a real hardware to see if it works yet) and if I understand it correctly, I think the problem was that I was missing the two parameters "#address-cells" and "#size-cells".