Trouble enabling 4 single channel inputs with gain changes

[scottellis]

Hi Erik,

Sorry if this is a bit long.

I working with your overlay from the RPi kernel repo.

There seems to be a truncation of the parameters happening when the overlay is used.

I wanted to enable all 4 channels single-ended with a max of 4V so I could read up to 3.3v

dtoverlay=ads1015:cha_enable,cha_gain=1,chb_enable,chb_gain=1,chc_enable,chc_gain=1,chd_enable,chd_gain=1

With that line, ch7 doesn't show up in sysfs and ch6 maxes out at 2V the default. Ch4 and ch5 read up to 3.3V.

If I try the following, ch6 is still limited to 2v.

dtoverlay=ads1015:cha_enable,cha_gain=1,chb_enable,chb_gain=1,chc_enable,chc_gain=1

If I do the following, I get ch5-7, but only ch5 and ch6 read 3.3v, ch 7 is still limited to 2v

dtoverlay=ads1015:chb_enable,chb_gain=1,chc_enable,chc_gain=1,chd_enable,chd_gain=1

I think it's a buffer overflow thing because I can switch the order of the params and get different behaviour

For example, this enables all channels, but now only ch7 allows 3.3v, ch4-6 are limited to 2V.

dtoverlay=ads1015:cha_enable,chb_enable,chc_enable,chd_enable,chd_gain=1,chc_gain=1,chb_gain=1,cha_gain=1

And finally, if I modify your dts so that instead of chX_enable it is just chX, then it appears all params get parsed and all 4 channels can read up to 3.3v

dtoverlay=ads1015,cha,cha_gain=1,chb,chb_gain=1,chc,chc_gain=1,chd,chd_gain=1

Have you seen this behavior?

I am using a 4.4.48 kernel.

[eriksejr]

Hi Scott,
Sorry I didn't see this sooner. I didn't run into this problem as I never had a need to use all channels of the device for my application. Your assumption that the line is getting truncated seems reasonable. I assume there's a limit on the length of the dtoverlay line within the RPI kernel, particularly if you you don't see everything showing up in the device tree.

Have you tried to use it putting each parameter on its own line in the /boot/config.txt file? Maybe try something like this:

dtoverlay=ads1015
dtparam=addr=0x48
dtparam=cha_enable=true
dtparam=cha_cfg=4
dtparam=cha_gain=0
dtparam=cha_datarate=0

I'm running a slightly older kernel then you (4.4.43) but this has worked for me since I've been using the device.

[scottellis]

Hi Erik, It's not a practical problem I have to solve so don't worry that I am being held up by this. Plus it is easy enough to work around by putting different defaults in the overlay and recompiling. I was just experimenting with your overlay and seeing how to extend it to an ads1115 device that a customer sent me. (We decided to use an MCP3008, but I figured I'd still see about making the part work since I had it.) I did not try to break up the params into separate dtparam lines the way you suggested. I'll give it a try. So I did look around a bit in the main kernel OF handling code and couldn't find where the buffer problem would be. I didn't see any fixed length buffers. Maybe it is the RPi specific dtoverlay handling code that has the problem? I somewhat avoided the issue temporarily with an ads1115-overlay.dts I wrote and added to my repos by shortening the names and using defaults that matched what I wanted anyway. https://github.com/jumpnow/buildroot/blob/rpi/board/jumpnow/rpi/linux/0003-Add-ads1115-overlay.patch If you don't find where the buffer truncation is happening, maybe I'll post a question to the RPi kernel people and see if it's maybe obvious to them. By the way, your dts for the ads1015 is pretty slick. Nice work. Do you see a way to extend your overlay to support the ads1115 at the same time? I couldn't figure it out without basically duplicating everything. Any reason you didn't asked the RPi kernel people to enable the ads1015 kernel module at the same time you added your overlay? How do Raspbian people use your overlay if the kernel module is not enabled? Best regards, Scott "eriksejr" <[email protected]> said:

…

Hi Scott, Sorry I didn't see this sooner. I didn't run into this problem as I never had a need to use all channels of the device for my application. Your assumption that the line is getting truncated seems reasonable. I assume there's a limit on the length of the dtoverlay line within the RPI kernel, particularly if you you don't see everything showing up in the device tree. Have you tried to use it putting each parameter on its own line in the /boot/config.txt file? Maybe try something like this: ``` dtoverlay=ads1015 dtparam=addr=0x48 dtparam=cha_enable=true dtparam=cha_cfg=4 dtparam=cha_gain=0 dtparam=cha_datarate=0 ``` I'm running a slightly older kernel then you (4.4.43) but this has worked for me since I've been using the device. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)

[eriksejr]

Hi Scott,
I'm not certain if you could use parameters to define which chip it is. If you simply change:

compatible = "ti,ads1015";
to
compatible = "ti,ads1115";

But leave the rest unchanged, does the driver ID the chip as an 1115? If the change is that simple, I think its more likely the overlay could be modified to make that a parameter somehow and allow you to use it for both chips. The driver only seems to load a different rate table for the 1115 then for the 1015 and adjusts the full-scale due to the 1115 being 16-bit vs the 1015 being 12-bit. So there appears to be very little difference between them on that side of things.

I'm not really a dtb expert though, this was actually my first dtb overlay. Further to that, it was really due to my inexperience that I didn't ask the RPI dev who committed it to get the module built with the kernel by default. I'm afraid I don't know what the policy is on that and how they decide which modules to include with the raspbian kernel - I would need to ask them.

In respect to where the truncation is taking place, I can't say I've looked that thoroughly but I've found some threads that suggest that config.txt is read by start.elf at boot. If the truncation is taking place in there you won't be able to find the source as that is proprietary code.

Regards,
Erik

[scottellis]

Inline "eriksejr" <[email protected]> said:

Hi Scott, I'm not certain if you could use parameters to define which chip it is. If you simply change: `compatible = "ti,ads1015";` to `compatible = "ti,ads1115";`

This is what I already did in my ads1115 overlay. Works fine. Though I did also shorten the length of some parameter names and changed the default gain and datarate.

But leave the rest unchanged, does the driver ID the chip as an 1115? If the change is that simple, I think its more likely the overlay could be modified to make that a parameter somehow and allow you to use it for both chips. The driver only seems to load a different rate table for the 1115 then for the 1015 and adjusts the full-scale due to the 1115 being 16-bit vs the 1015 being 12-bit. So there appears to be very little difference between them on that side of things.

I'm familiar with the kernel driver code. I'll see what I can come up with in terms of an overlay that works with both chips.

I'm not really a dtb expert though, this was actually my first dtb overlay. Further to that, it was really due to my inexperience that I didn't ask the RPI dev who committed it to get the module built with the kernel by default. I'm afraid I don't know what the policy is on that and how they decide which modules to include with the raspbian kernel - I would need to ask them.

I can request it. I already have the patch for it in my buildroot and Yocto trees. It doesn't make much sense to distribute the dtb overlay to Raspbian when it isn't usable because the kernel module is missing.

In respect to where the truncation is taking place, I can't say I've looked that thoroughly but I've found some threads that suggest that config.txt is read by start.elf at boot. If the truncation is taking place in there you won't be able to find the source as that is proprietary code.

This is what I suspect since the dtoverlay stuff is RPi specific. I'll bring it up on the mailing list and see if the limit can't be changed.

…

Regards, Erik -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)

[scottellis]

The 80-character limit is documented in the DT Parameters section https://www.raspberrypi.org/documentation/configuration/device-tree.md So no bug. I'm testing now with 4.9. I submitted a pull request for the kernel module. I'll do the same for adding an ads1115 overlay. I couldn't find a way to add ads1115 support to the ads1015 without duplicating much of the overlay. Seemed simpler for a user to just an ads1115 specific one. Best regards, Scott "eriksejr" <[email protected]> said:

…

Hi Scott, I'm not certain if you could use parameters to define which chip it is. If you simply change: `compatible = "ti,ads1015";` to `compatible = "ti,ads1115";` But leave the rest unchanged, does the driver ID the chip as an 1115? If the change is that simple, I think its more likely the overlay could be modified to make that a parameter somehow and allow you to use it for both chips. The driver only seems to load a different rate table for the 1115 then for the 1015 and adjusts the full-scale due to the 1115 being 16-bit vs the 1015 being 12-bit. So there appears to be very little difference between them on that side of things. I'm not really a dtb expert though, this was actually my first dtb overlay. Further to that, it was really due to my inexperience that I didn't ask the RPI dev who committed it to get the module built with the kernel by default. I'm afraid I don't know what the policy is on that and how they decide which modules to include with the raspbian kernel - I would need to ask them. In respect to where the truncation is taking place, I can't say I've looked that thoroughly but I've found some threads that suggest that config.txt is read by start.elf at boot. If the truncation is taking place in there you won't be able to find the source as that is proprietary code. Regards, Erik -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #1 (comment)