LCD 3.5 Cape Blocks all Analog Input Pins on Beaglebone Black

I just go an LCD Cape for my Beaglebone Black project and am having trouble accessing any of the three analog pins the cape supposedly does not use. The documentation states that AIN0-3 are used. This would imply that AIIN4-6 are available. When I try to access them, however, I get the following message (from Bonescript):

fs.js:429
return binding.write(fd, buffer, offset, length, position);
^
Error: EEXIST, file already exists
at Object.fs.writeSync (fs.js:429:18)
at Object.fs.writeFileSync (fs.js:764:21)
at load_dt (/usr/lib/node_modules/bonescript/index.js:59:12)
at Object.f.analogRead (/usr/lib/node_modules/bonescript/index.js:369:12)
at observe (/var/lib/cloud9/chair/test.js:119:38)
at Timer. (/var/lib/cloud9/chair/test.js:102:17)
at Timer.exports.setInterval.timer.ontimeout (timers.js:234:14)

My entire reason for being, or for having the BBB anyway, is to integrate with some analog inputs!

Thanks for any help,
Will

Was the cape listed as being BBB compatible at http://beagleboneblackcapes.com ?

Absolutely. It works fine just won’t let me access any of the three unused analog pins. Interestingly the headers on the LCD look like they were designed to allow physical access (though tight) to the pins.

There is one ADC. Just one with a multiplexer in fornt of it to support 8 inputs. The fact those other pins are not used still relies on the ones that are used, tying up the ADC itself.

Gerald

Gerald:

Ouch. So do I interpret that to mean that I can have a cool user interface or I can talk to the device that I want to integrate…but not both? Is there a workaround other than me stacking two Beagles (which interestingly would improve my sample rate but seems a little over kill for what my client needs)!

Thanks again for your help,
Will

P.S. A relay now clicks every time the Beagle starts an observations session…

You can use an external Touchscreen controller and free up the ADC for your use. But that requires a change to the LCD design. Or just use an external ADC off of SPI or I2C.

Gerald

Gerald:

I was thinking about an external ADC and was just looking for one. In a perfect world there would be one that someone has working with the BBB and with sample code available… On the other hand maybe I can sell the idea of two Beagles given the significantly better sample rate.

Will

Whichever way works best for you.

Gerald

Revisiting this topic…is there any way to disable the touch screen drivers for the LCD display thus rendering the AIN pins accessable (though reducing the user input to buttons)? Getting an external ADC to work is looking to be non trivial.

Regards,
Will

You can play with the device tree for the LCD panel and remove the ADC
bits. You should also be able to make a custom device tree that
supports the touch screen *AND* reading the other three inputs, but
this might involve tweaking some driver code.

...reviewing the device tree files for the lcd3 and the iio analog
"helper", it looks like you should be able to pretty easily remove the
touchscreen parts from the LCD overlay and roll them into a separate
analog overlay (or add your required analog bits to a custom LCD
overlay), but you'll probably want to review the actual driver code
and make sure it's not doing something stupid.

- --
Charles Steinkuehler
charles@steinkuehler.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Revisiting this topic...is there any way to disable the touch
screen drivers for the LCD display thus rendering the AIN pins
accessable (though reducing the user input to buttons)? Getting
an external ADC to work is looking to be non trivial.

You can play with the device tree for the LCD panel and remove the ADC
bits. You should also be able to make a custom device tree that
supports the touch screen *AND* reading the other three inputs, but
this might involve tweaking some driver code.

...reviewing the device tree files for the lcd3 and the iio analog
"helper", it looks like you should be able to pretty easily remove the
touchscreen parts from the LCD overlay and roll them into a separate
analog overlay (or add your required analog bits to a custom LCD
overlay), but you'll probably want to review the actual driver code
and make sure it's not doing something stupid.

I tried the same yesterday. Managed to get both ain0-ain3 working for touch
and ain4-ain7 as adc readouts. But got no decent readings from the adc and these
were influenced by the pressing the touch screen.

It probably requires tweaking the ti tsc / adc driver. I gave up and soldered
an "I2C 12-bit 4 channel ADC" (ADS1015) to my BeBoPr, enabled the driver in the
kernel, added an overlay fragment and voila, stable ADC inputs. Never got that with
the built-in ADC!

-- Bas

You'll almost certainly get better results with an off-board ADC,
regardless of how much tweaking is done on the driver. I think
there's room to get the ADC inputs working better than they are on the
BeagleBone, but I'm sure the process used for the AM335x die isn't
geared for low-noise analog performance.

Are you thinking of adding the ADS1015 to the next version of the BeBoPr?

- --
Charles Steinkuehler
charles@steinkuehler.net

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It probably requires tweaking the ti tsc / adc driver. I gave up
and soldered an "I2C 12-bit 4 channel ADC" (ADS1015) to my
BeBoPr, enabled the driver in the kernel, added an overlay
fragment and voila, stable ADC inputs. Never got that with the
built-in ADC!

You'll almost certainly get better results with an off-board ADC,
regardless of how much tweaking is done on the driver. I think
there's room to get the ADC inputs working better than they are on the
BeagleBone, but I'm sure the process used for the AM335x die isn't
geared for low-noise analog performance.

Are you thinking of adding the ADS1015 to the next version of the BeBoPr?

No, take your BeBoPr, turn it over. Take a magnifier and look for the empty
U9 footprint next to the EEPROM :slight_smile:

I was working on a wiki page where I explain this just when this discussion popped up.
It'll show some photos on how to connect the inputs and some code for the overlay.

-- Bas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It probably requires tweaking the ti tsc / adc driver. I gave up
and soldered an "I2C 12-bit 4 channel ADC" (ADS1015) to my
BeBoPr, enabled the driver in the kernel, added an overlay
fragment and voila, stable ADC inputs. Never got that with the
built-in ADC!

You'll almost certainly get better results with an off-board ADC,
regardless of how much tweaking is done on the driver. I think
there's room to get the ADC inputs working better than they are on the
BeagleBone, but I'm sure the process used for the AM335x die isn't
geared for low-noise analog performance.

Are you thinking of adding the ADS1015 to the next version of the BeBoPr?

No, take your BeBoPr, turn it over. Take a magnifier and look for the empty
U9 footprint next to the EEPROM :slight_smile:

I was working on a wiki page where I explain this just when this discussion popped up.
It'll show some photos on how to connect the inputs and some code for the overlay.

Just finished the page: <https://github.com/modmaker/BeBoPr/wiki/Better-Analog-Inputs>

-- Bas

Hello,

I am trying to also use the BeagleBone ADC along with an LCD screen that has touch functionality. I’ve decided that the touch functionality isn’t important and would rather disable it to give me full access to the internal ADC. The screen is the 4DCape-43T. I would like a little bit of guidance trying to alter the device tree for the LCD to disable the touch functionality. Where is the device tree located for the display? If anyone knows the exact code to change, that would be welcomed advice, also. I am a little inexperienced with the BeagleBone Black, so I’m a little confused about how to do this. It would be a life saver if anyone could help!

Thanks,
Steven

Yeah, do we need to rebuild the kernel to remove the touch functionality?

Quite old post but…I have same issue for my old Beaglebone WHITE running 3.2.33 kernel
Is there any simpler method to avoid external ADC and split by software the unused AIN pins to make them readable ??

Thank you very much

I think you are going to have to use an external ADC.

The good news is that you can get better accuracy and a lot higher resolution by doing so. At the expense, of course, of some additional cost and complexity. I ended up using an ADS1115 from TI that delivers 16bits of resolution at 800 samples per second. BUT, another big but, is that I used an Arduino Nano as a front end to my BBB as I found it easier to integrate the Nano and the BBB than the ADC and the BBB. I am using Node and the libraries that do I2c were not working for me. You may have different luck depending on your environment.

I’m late to this thread, but I’ve run into the same problem. I have a new BBB and I got a 4.3" touchscreen LCD made by 4D: https://www.sparkfun.com/products/12085
And I’m having trouble reading analog inputs. I tried to enable the ADC using command: echo cape-bone-iio > /sys/devices/bone_capemgr./slots but doesn’t seem to work. I don’t see any AINX inputs show up under /sys/devices/ocp.2/helper.14/. If I remove the cape I do see those. But I also tried enabling by: echo BB-ADC > /sys/devices/bone_capemgr./slots, and I can read the raw analog inputs: /sys/bus/iio/devices/iio:device0/in_voltageX, but the values don’t look right.
So am I shit out of luck for using ADC and LCD together without going the i2c or spi route?
thanks!

Jwilkie:

You are going to be investing in an external ADC and doing some I2C integration…unless you really don’t need that LCD. Analog pins are not available to you with the LCD.

The good news is that an ADC external is probably a better solution. You can get 16 bits of resolution and I believe better and more dependable readings:

https://www.adafruit.com/products/1085

Have fun,

Will