Configuring the Linux Kernel to access AIs from a process

I'm working with a Beaglebone A3 running the Arago distro of Linux loading via TFTP & NFS-mounted root FS on my Ubuntu 11.10 machine.  Blake Carpenter posted info on the "internal" e2e although from the outside I cannot access it. For those that can, I think this is the link:

My original request to Blake was as follows:

I'm looking for info on how to access/configure A/D inputs from Linux...So far, I haven't been able to find anything on how to access the A/Ds from within Arago. Although searching the Internet, I did find this:

This is a guy showing how to wire up a Beaglebone for A/D access. And in this link, he shows that to access the A/Ds, there should be a folder named as follows:

However looking in the file system of my Arago installation, I don't have a /tsc folder. And I haven't been able to find an /ain2826 folder in what I do have. Assuming the link I found is accurate, it appears accessing the A/Ds isn't terribly difficult as long as the drivers are in place to do it. But they don't appear to be...

Here's the response he sent me back:

I believe your issue is that you are looking at documentation based on the Angstrom distribution for beaglebone rather than the Arago distribution.  The Angstrom distribution is a community based distribution and there are some patches they apply on top of the TI kernel.  In particular the following patches likely have something to do with the ADC:


These patches were pulled from the list of patches applied on top of the TI kernel in the recipe at;a=blob;f=recipes-kernel/linux/;h=79a315a1a18db23ece195d5827b64c39f35331cb;hb=0d0e2c1e274e1885d8b5cb07421449e9d0016c2c 

You can find these patches online at:;a=tree;f=recipes-kernel/linux/linux-ti33x-psp-3.2;h=7d98c2da3cb0df1aeda839094726134b9ee8e635;hb=0d0e2c1e274e1885d8b5cb07421449e9d0016c2c 

The /sys directory is not a "real" directory in the file system.  It is generated by the kernel and kernel drivers.  As you said, once the drivers are in place the directory should be created in /sys


This morning, I tried to get these patches installed into the Linux source and then rebuild a new kernel with these patches. And I'm not getting much success. Here's how far I got:

1. Downloaded the patches indicated below into the following directory:

2. Ran the ~/ti-sdk-am335x-evm- script as sourced to configure my shell for cross-compiling ARM code, not native x86 code.

3. I navigated the shell to the Linux source code directory ~/ti-sdk-am335x-evm- and ran the patch command as follows:
$ patch -i patches/recipes-kernel_linux_linux-ti33x-psp-3.2_0006-beaglebone-disable-tsadc.patch --dry-run -p1

I wanted to do a dry run and not actually commit anything in case there were problems. Had everything gone fine in the dry run, I would simply rerun the patch command without the --dry-run argument. But instead of a successful patch dry run, I got this:
patching file arch/arm/mach-omap2/board-am335xevm.c
Hunk #1 FAILED at 248.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/mach-omap2/board-am335xevm.c.rej

So is this an indication that this patch won't work on my Arago disto or do I need to apply earlier patches listed on the website supplied by Chase?

Note, I am relatively new to Linux, so speak to me like a novice not like an expert Linux guru so don't assume a lot of existing knowledge about Linux. I'm an RTOS firmware developer doing investigation into moving my company's next generation of hardware over to a Linux architecture and the more I learn about Linux, the more I realize how much I don't know.

While being dead in the water on this issue, I decided I would at least try to build the kernel with the source code as it was installed on my machine by the setup scripts. And I had trouble with that. Although that can probably be tracked as a separate thread since I highly suspect this is a newbie problem.

42 Replies

  • In reply to Qmax:

    Hi Max,

    crashes on reading FIFO0CNT (0xe4)

    i have the thame problem. have you found an solution?



  • In reply to Alexander Kratzer1:

    No, I never found an issue. We got what we needed using the A/D access made available via the TI included driver. Once we got an idea of the A/D quality and stability, we decided that an actual implementation for our purposes would require a better interface to the hardware which means custom driver. We've already started work on a custom driver for one of the UARTs. Once that effort completes, work will probably begin on looking into figuring out access to the A/Ds from a driver optimized for how our application will want the A/D data.

  • In reply to Christopher Grey:

    Hi Christopher,

    In my kernel ti_tscadc driver available and added the tsc configuration in board file. After that i could see tsc folder in /sys/class/platform/tsc. But i could not find any AIN in the file system after booting. I am using ti-sdk-05.03.

    Could you please help me how to get the analog inputs. I have to monitor photo diode input and input voltage on two analog pins AIN0 and AIN1.




  • In reply to raja V:

    I'm not in the office this week to help much. But what I did to get this to work is listed above. The hardest part about getting this to work was getting the right version of the SDK to start with, then updating it with the right updates before trying to apply the patches. One of the steps takes a VERY long time and doesn't give any feedback on the screen to indicate it is doing anything. But once I completed all those preliminary steps, the patches that add the direct AI support applied without a problem and getting the AIs to read from the command prompt or from within a C-program where exactly as documented in the links included at the very beginning of this thread.

    However at some point through all this, I was told that there'd be a newer SDK version that would not require a lot of updating to apply the patches. You simply apply the patches directly to the distro. What I don't know is if these patches will ever make it into the distro. I rather doubt they will since the main purpose of the A/D inputs is for touch-screen support and the patches appear to be somewhat of a hack to the existing code to alter their behavior for direct AI access.

    But beyond what's captured within this thread, I honestly don't know much more. What I can say is the AIs did jump around a bit in value. They may be 12 bit resolution, but based on the jumping that I witnessed, they should only be trusted to about 10-bit. Perhaps there is some noise or some trace problem with the BeagleBone causing the fluctuations in reading that a better designed board could minimize or avoid. But if you need stable 12-bit resolution, don't count on it from the BeagleBone board. I don't know if the TI EVM displays this same behavior or not. We didn't do our AI tests with it. Another thing I noticed is the grounds that you choose on the BeagleBone affect the raw A/D value you get. There are dedicated ground lines on the BeagleBone header that I was using initially. But I found if I moved my ground tap around to other things on the BeagleBone that were also grounds (USB casing, ethernet plug casing, ground lugs around the edge of the board), the A/Ds would display different values than compared to when I was tapped on at the ground lugs themselves. I don't recall if any of the ground lugs were more stable than others. I just noticed that the reading was noticeably different.

  • Expert 2280 points

    In reply to Alexander Kratzer1:

    Hi Alexander,

    Unfortunately it was a lot of time ago for my poor volatile memory... I can say that when I moved to exact git branch version then everything started to work fine with those patches (if I remember correctly...): try the exact instruction steps I gave to Christopher in a previous post of this same thread.

    For sure, after a few tests, I moved to a more recent version of git kernel and wrote my own driver based on my need but taking inspiration from that one. It should be somewhere in my PC: having a little bit of time I could search for it and post, maybe could be useful as suggestion. In any case I suggest you to start with the correct git kernel version and those patches.

    Regards, Max

  • Expert 2280 points

    In reply to raja V:


    the default ti_tscadc driver in TI SDK kernel is the driver used in the EVM board for touchscreen peripheral. This is because AINs pins are used to drive the touchscreen in that board. Of course, as is,  it is useless for BBone. You need to modify/patch it to monitor voltage on AINs pins.

    Regards, Max

  • In reply to Qmax:

    Hi Qmax,

    I have followed the steps mentioned by Christopher and added the patched  and now I could see the AIN in my sys path. I have executed the command line arguments as mentioned in koen's blog and could see the values. I need to verify the validity of digital values.

    Do I have to configure step size from my user application?

    Below are the details of my board file configuration for adc:

    static struct pinmux_config tsc_pin_mux[] = {
        {"ain0.ain0",        AM33XX_PIN_INPUT_PULLUP},
        {"ain1.ain1",        AM33XX_PIN_INPUT_PULLUP},    
        {"vrefp.vrefp",      AM33XX_PIN_INPUT_PULLUP},
        {"vrefn.vrefn",      AM33XX_PIN_INPUT_PULLUP},
        {NULL, 0},

    static struct tsc_data am335x_touchscreen_data  = {  
    .mode = TI_TSCADC_GENMODE,

    static struct resource tsc_resources[]  = {
        [0] = {
            .start  = AM33XX_TSC_BASE,
            .end    = AM33XX_TSC_BASE + SZ_8K - 1,
            .flags  = IORESOURCE_MEM,
        [1] = {
            .start  = AM33XX_IRQ_ADC_GEN,
            .end    = AM33XX_IRQ_ADC_GEN,
            .flags  = IORESOURCE_IRQ,
    static struct platform_device tsc_device = {
        .name   = "tsc",
        .id     = -1,
        .dev    = {
                .platform_data  = &am335x_touchscreen_data,
        .num_resources  = ARRAY_SIZE(tsc_resources),
        .resource       = tsc_resources,


    Are these inputs sufficient?

    It would be of great help if you could share the driver written by you as sample and reference to all. Seems many are in need of it.

    Thank you very much for your prompt response.



  • In reply to raja V:

    Agreed. That would be helpful to have someone elses driver to reference. The one thing we knew would be a built-in inefficiency with the existing driver is it will be reading the A/D, converting the raw value into a string, delivering that to the user app. Then my user app was reconverting the string back to a number, then consuming the value. That's a lot of needless conversion going on so our custom driver would be configured to deliver the values in a more raw form, not in a string form.

  • In reply to Christopher Grey:

    Hi Christopher,

    I am able to access the ADC pin from sysfs and by typing command cat < /sysfs/../ain2 and could get the ADC value with standard supply voltage as input.

    But when I tried to access from application using "open("/sys/devices/platform/tsc/ain2",O_RDONLY); and read(fd, (int)ADCValue,2);" code, I got the error and the error number is 16: EBUSY.

    Have you tried anytime accessing from C program. Open call always gives success but read fails.

    Your help would be appreciated.



  • In reply to raja V:

    For our evaluation, command line access to the A/Ds was all that was necessary. I just called them in successive order using a shell script while adjusting the voltage from a voltage source. The main thing we were interested in was how fast they updated, how stable they were, and how much variance there was in raw value between the inputs when all being fed the same voltage. While messing with them, I also noticed that there is some "cross-talk" between the A/D inputs. If I increased the voltage on one input, I'd see upward fluctuation in other inputs. Without a different circuitboard to test this on, it is unknown whether this is a result of the design of the beaglebone or an inherent problem with the chip itself. But the skew wasn't enough to concern us for our purposes for these inputs.

    But to answer your question, no we did not use C-code to access the A/Ds. Although I did write a C-program to access the GPIOs and had no issue at all doing that.