This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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:

https://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/int_sitara_am335x/f/425/p/172327/629962.aspx#629962

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:
http://www.gigamegablog.com/2012/01/22/beaglebone-coding-101-using-the-serial-and-analog-pins/

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:
/sys/devices/platform/tsc/ain2826

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:

0006-beaglebone-disable-tsadc.patch
0007-tscadc-Add-general-purpose-mode-untested-with-touchs.patch
0008-tscadc-Add-board-file-mfd-support-fix-warning.patch
0009-AM335X-init-tsc-bone-style-for-new-boards.patch
0010-tscadc-make-stepconfig-channel-configurable.patch
0011-tscadc-Trigger-through-sysfs.patch
0013-tscadc-switch-to-polling-instead-of-interrupts.patch
0014-beaglebone-fix-ADC-init.patch

These patches were pulled from the list of patches applied on top of the TI kernel in the recipe at http://arago-project.org/git/?p=meta-ti.git;a=blob;f=recipes-kernel/linux/linux-ti33x-psp_3.2.bb;h=79a315a1a18db23ece195d5827b64c39f35331cb;hb=0d0e2c1e274e1885d8b5cb07421449e9d0016c2c 

You can find these patches online at:

http://arago-project.org/git/?p=meta-ti.git;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

Chase

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:
~/ti-sdk-am335x-evm-05.03.00.00/board-support/linux-3.0+3.1-rc8-psp04.06.00.02.sdk-psp04.06.00.02.sdk/patches

2. Ran the ~/ti-sdk-am335x-evm-05.03.00.00/linux-devkit/environment-setup 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-05.03.00.00/board-support/linux-3.0+3.1-rc8-psp04.06.00.02.sdk-psp04.06.00.02.sdk 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.

  • Christopher,


    Two things:

    1. You may either need the additional patches in the recipe I pointed to (since this is technically a different kernel than the one in the SDK), or you will need to modify the patches to apply into your kernel. 

    2. Do not source the environment-setup script when trying to build the Linux kernel.  This will cause build failures.  See http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_GCC_Toolchain#When_Compiling_the_Linux_Kernel

    If you want to apply all the patches I would look at modifying the script at http://arago-project.org/git/?p=meta-ti.git;a=blob;f=recipes-kernel/linux/linux-3.0/patch.sh;h=dc19a9e5123ea7380a872e6dfe00b7c03e292db6;hb=0d0e2c1e274e1885d8b5cb07421449e9d0016c2c to help you with this.  I do not use this script myself, but from a quick read of the script I believe that if you were to download all the patches in the subdirectories, i.e. the 3.2.x patches you could then list those subdirectories in the PATCHSET variable and have them applied on top of the base PSP kernel.  That way you don't have to do this by hand.

    Chase

  • I'll look at how to modify the patches. After have opened a patch file, I assume that the actual modification of the patch is relatively trivial although figuring that out have never used the patch program nor the diff program before may spawn generic linux questions if I don't muddle my way through it. I'll let you know. If I do get a modification working, I'll post up my modifications just to get a set of experienced eyes looking at what I did to verify I didn't cause other problems.

    I'll keep that apply all script in mind. That might prove useful to others once I get a set of patches modified to work with this kernel. But assuming the other patches are also going to fail due to needing to be modified, my guess is I'll be manually applying these anyway. Or did I miss the point of the script?

  • Christopher,


    You don't modify patches directly.  that will almost always cause the patches to no longer be able to apply with the "patch" command.  Instead what you do is try to apply the patch.  The failed sections will be saved in a <filename>.rej file.  Work to resolve the rejects.

    If you want to regenerate patches then you should use "git" for that.  i.e.:

    1. do a "git init" in your kernel source tree

    2. git add -f *

    3. git commit -m "initial commit'

    4. git am patch1.  If patch 1 fails then do the below steps, else go to the next patch.  When all are done go to step 5.

    4.a patch -p1 < patch1

    4.b fix rejects

    4.c Do "git status" and do a "git add" on the files you actually modified (not the patch file itself)

    4.d git am --continue

    5. git format-patch --numbered -#   Where # is the number of patches you applied

    Chase

  • Ok, now I really feel stupid for asking this, but why would the *.rej file not getting created? As was copy/pasted above, the patch file is telling me it created a .rej file, but when I go to the folder it is referencing, there's no .rej file there. When I navigate to the folder using nautilus or code warrior, there's no *.rej files in that folder although .c file it was trying to modify was there.

    I thought perhaps it was a permissions thing so I just  reran the patch with sudo. No difference. I'm hoping there's some little "oh-by-the-way" about patch or linux that I just don't know here. Next step, reboot the machine and see what that does. I'll be real disappointed in Ubuntu if this works.

  • Were you using --dry-run?  If so then the .rej file is not actually created.

  • Ahh, that's what I needed to know.I'll give it a try and see if this fixes that. I'm sure it will, but I'll ring back if it doesn't.

    BTW, it's not intuitive at all that you can't run the --dry-run to get an .rej file. The whole purpose of the dry run is to check something before it gets implemented and if there's a problem, you will want the debugging info about what went wrong. But I take it the dry run is more to mean the code will be exercised, but absolutely nothing will be actually done.

    It sure helps having someone experienced to break you out of your walls of assumptions to show you reality.  Thanks...

  • I've applied a few of these patches, although I'm finding there's some guess-work on my part as to what I'm doing. It seems the kernel source these files were meant for are quite disparent from the source as it exists in Arago. I'm noticing that some of the lines the patch includes as reference for where to do an insert aren't there either. So even if I find where to insert the code the patch wants to insert, the code may not make sense without other code that's been added by other patches or changes.

    For example, some of the patches want to add bone_tsc_init to a static struct of what appear to be function calls. While I believe I've found where the hunk failed and where the line needs to be added to the static structs, the function pointer being added doesn't have a corresponding function defined in this file. So I'd be adding a reference to a function that doesn't exist and likely was added by some other patch.

    I did notice a patch disclaimering itself as a massive patch. Either most of the things are likely bottled up in that patch OR attempting to add that patch would end up giving me hundreds of hunk failures that would send me down a rabbit hole I'm not sure I'm prepared to go down.

    The whole purpose of my assignment is to evaluate the AIs on the AM335x for stability, speed, and usability. Would I be better off using the Angstrom distro instead of Arago at least until these modifications can get ported over to Arago by people far more knowledgeable about how to do that than me? Any thoughts or advice?

    For now, I'll try to apply all of those previous patches just to see what happens. It certainly can't hurt and it'll give me more experience resolving hunk failures I guess?

  • I would try to just apply all the patches in the recipe that I pointed you to.  That should give you a set of kernel sources that look like what Angstrom is using.  That is where the patch script may come in handy.

  • I downloaded all the previous patches and applied them one at a time. The first 2 applied without incident, but the 3rd one (recipes-kernel_linux_linux-ti33x-psp-3.2_0004-beaglebone-rebase-everything-onto-3.2-WARNING-MEGAPA.patch) had 4 hunks fail.

    Looking into why the 1st hunk failed, it's trying to add lines to a struct that doesn't exist in the Arago source. Assuming everything shown in the reject is all the lines of the struct, it looks like it can possibly be added manually. Although that's just a guess.

    The 2nd hunk being added looks like it is adding a couple of functions. That doesn't look too terribly difficult to manually add, although there is 1 line it is trying to delete in the middle of the added lines which looks like the entry line of a struct. But the code around it doesn't look like "struct" code. So I'm not sure what's going on there. Add to that, the line it is trying to delete doesn't exist in the Arago code anyway. Toward the end of this hunk, there's more removing of lines from code that doesn't exist in my source. All of this suggests to me that there's far more divergence between the distro the patches are meant to apply against and the one I have.

    The 3rd & 4th hunk failure is moving a line's position within a struct as well as adding a new line. The problem is the lines shown and the line being moved is in multiple structs that are right near each other in the source. There's ambiguity as to which struct it is the patch intended to modify.

    This plan isn't working. Is there any chance that the version of Arago that latest SDK (ti-sdk-am335x-evm-05.03.03.00) installed isn't actually the latest Arago version available? The version it installed is linux-3.1.0-psp04.06.00.03.sdk. If there's a newer Arago version, I can give it a try.

  • Christopher,

    I see the confusion here.  These patches apply on top of a different base.  The base they apply on top of is a clone of the git tree at git://arago-project.org/git/projects/linux-am33x.git using the v3.2-staging branch and commit id 09e9651bcf2ee8d86685f2a8075bc6557b1d3b91.  So to get this base you would do:

    git clone git://arago-project.org/git/projects/linux-am33x.git

    git branch --track v3.2-staging origin/v3.2-staging

    git checkout v3.2-staging

    git checkout 09e9651bcf2ee8d86685f2a8075bc6557b1d3b91


    Then apply the patches. 

    BTW, currently there is an issue with the arago-project.org git server.  We are working to get this resolved, but if your clone fails please try again a little later.

    Chase

  • Yeah, I noticed the same outage.

    As for the git, is there any chance your servers also support http://... file access?

    For some very dumb reason, our IT dept blocks git. We are working to get that resolved given our desire to embrace Linux as our next generation firmware OS, but getting that past them is still not easy. It doesn't help that they drink the Micro$oft Koolaid and hate Linux.

  • yes, http is also supported

  • Thanks.

    As soon as the server's up, I'll try that version and see if that gets me moving along a bit further.

  • arago server should be back up

  • I'm changing the git clone command from git://... to http://.... but nothing seems to be happening. Is there some other way I should call git in order to get it to use port 80 (http) vs whatever the standard git port is?

  • Two things:

    1. if you are behind a proxy then you need to set your GIT_PROXY_COMMAND

    2. cloning the kernel can take a long time and http is a slower way to do it.  Also, http doesn't give as much status so it may look like it is just hanging.

  • You were right that git using http did appear locked up, but it was doing stuff. I left it alone for a few hours and when I came back, it had finished with files and folders in the directory it created. So yay for that.

    Next step was applying the patches to this version. And again, patch is failing in the same places it was before when trying to apply recipes-kernel_linux_linux-ti33x-psp-3.2_0004-beaglebone-rebase-everything-onto-3.2-WARNING-MEGAPA.patch and for the same exact reasons.

    I don't know if it helps any, but the code I just downloaded is making references to i2c1_init where the patches are expecting i2c2_init to be implemented. The fact that the recipe patches and the kernel code I have are different in this aspect suggests there's differences all the way down to the hardware pin muxing choices.

  • Did you check out the specified commit id?  The way OE works is that it checks out the repository at the given commit id and then applies the patches in the order listed.  So the patches should apply on top of the kernel.  I just built this recipe and all the patches apply, so I'm guessing your branch and commit base are wrong.

    Chase

  • Ahh, that's making more sense. I just downloaded using git clone, but forgot there were other git commands you directed me to run after that before applying the recipe patches. Let me "undo" what I've done and see if actually following directions gets me your positive results.

    Thanks for your patience.

  • Hi Chase, I'm doing something similar to what is done in those patches, but on a more recent snapshot of git repository.

    But when I try to read sysfs files, I've got a kernel crash with a "Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e0d0e4". Steps configuration seems fine but it crashes on reading FIFO0CNT (0xe4): in fact 0xf9e0d0e4 = 0xb5000000 + 0x44e0d000 + 0xe4.

    Any suggestion? Thanks

    Regards,

    Max

  • Max,

    Unfortunately those are not patches I'm familiar with.  I would recommend asking about this on the beagleboard mailing list since these patches are from the community.

    Chase

  • Well, after following directions correctly, all gits succeeded, and all patches applied without incident. Progress!

    When I went to build though, the makefile couldn't find a .config so I at first launched menuconfig using the following call:

    make menuconfig ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi-

    Sitara isn't yet in the list of things to choose from so at that point, I didn't have any faith that I'd choose intelligently in menuconfig, so I loaded the .config from my ~/ti-sdk-am335x-evm-05.03.03.00/board-support/linux-3.1.0-psp04.06.00.03.sdk/ folder. I figured it would be more correct than I would guess at. I saved that and then did a kernel build with the following command:

    make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- uImage

    That started a long build process that ended with:

    .

    .

    .

      UPD     include/generated/compile.h
      CC      init/version.o
      LD      init/built-in.o
      LD      .tmp_vmlinux1
    arch/arm/mach-omap2/built-in.o: In function `am33xx_pm_begin':
    twl-common.c:(.text+0x7fac): undefined reference to `omap_mbox_msg_send'
    twl-common.c:(.text+0x7ff8): undefined reference to `omap_mbox_msg_rx_flush'
    arch/arm/mach-omap2/built-in.o: In function `am33xx_pm_init':
    twl-common.c:(.init.text+0x4b68): undefined reference to `omap_mbox_get'
    twl-common.c:(.init.text+0x4d14): undefined reference to `omap_mbox_put'
    make: *** [.tmp_vmlinux1] Error 1
    cgrey@cgrey-desktop:~/ti-sdk-am335x-evm-05.03.03.00/board-support/linux-am33x$

    I recognize the failing files as files the patches were messing with. So at this point, I'm going to go back and try a kernel build with only the cloned kernel along with the other git modifications (no recipe patches) just to see if that version of the kernel builds. If it does, then I'll iteratively apply patches until I find a build that causes a kernel build failure. Hopefully that will be useful info to you if this isn't.

  • You could try the defconfig file at http://arago-project.org/git/?p=meta-ti.git;a=blob;f=recipes-kernel/linux/linux-ti33x-psp-3.2/beaglebone/defconfig;h=782f52dae6f9a107747a0065fbf2160e518dcb21;hb=8f1fc028be8567c57ed7d40b1800ece37128b9ac which is what this kernel is built with.

    Chase

  • I tried this file as well as a few other things and this kernel either isn't pulling down by git correctly or complete. I still have a copy of the folder as it was pulled down by git clone and I decided to try to build just that without any of the branch or other checkout git procedures done to it and it is failing to build. Here's the errors I'm getting:

      CC      lib/vsprintf.o
      AR      lib/lib.a
      LD      vmlinux.o
      MODPOST vmlinux.o
    WARNING: modpost: Found 7 section mismatch(es).
    To see full details build your kernel with:
    'make CONFIG_DEBUG_SECTION_MISMATCH=y'
      GEN     .version
      CHK     include/generated/compile.h
      UPD     include/generated/compile.h
      CC      init/version.o
      LD      init/built-in.o
      LD      .tmp_vmlinux1
    arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
    twl-common.c:(.text+0x425c): undefined reference to `__cpu_suspend'
    arch/arm/mach-omap2/built-in.o: In function `skipl2reen':
    twl-common.c:(.text+0x4864): undefined reference to `cpu_resume'
    kernel/built-in.o: In function `sched_clock_cpu':
    hw_breakpoint.c:(.text+0x1a04a): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `sched_clock' defined in .text section in arch/arm/mach-omap2/built-in.o
    kernel/built-in.o: In function `show_interrupts':
    hw_breakpoint.c:(.text+0x2c92e): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `arch_show_interrupts' defined in .text section in arch/arm/kernel/built-in.o
    make: *** [.tmp_vmlinux1] Error 1
    cgrey@cgrey-desktop:~/ti-sdk-am335x-evm-05.03.03.00/board-support/linux-am33x$


    I am calling the build from the linux-level makefile not the top level. I doubt I'll get any further along, but I'm about to modify the Rules.make to point to this newest kernel and see if I can get that to work. Although so far my experience has been that if the linux-level make failed, a make from the top-level would also fail.

    If you have any other ideas or suggestions as to what might be causing the problem, let me know. I'm running out of things that I know to try.

  • Chirstopher,

    That's what I've done. For me it works on AM335x EVM and I suppose on BBone too.

    1 - In the Git you have cloned, do a checkout of AM335XPSP_04.06.00.06 (skip if you have already done it):

    git checkout AM335XPSP_04.06.00.06 (or git checkout 09e9651bcf2ee8d86685f2a8075bc6557b1d3b91 it is the same)

    2 - Apply the patches from number 0004 to 0014. All patches will apply with no problem (skip if you have already done it):

    git apply <path to patches>/<patch file>

    3 - Now forgive the SDK (BTW I would use the latest SDK 05.03.02.00...), and just set the toolchain path in your PATH env, e.g.:

    export PATH=~/ti-sdk-am335x-evm-05.03.00.00/linux-devkit/bin:$PATH

    4 - ...then cd into git cloned kernel and run the following commands:

    make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- mrproper
    make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- am335x_evm_defconfig
    make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- uImage

    Hope this help. I did not have any problem. BTW new SDK 5.04 is expected by the end of the month, and I suppose will be based on PSP 04.06.00.06, therefore on that SDK kernel you will be able to apply those patches with no need of git cloned.

    What is the "internal" e2e you mentioned in the first post?

    Regards, Max

  • I believe that's what I'm doing...all that except I'm not using git to apply the patches. I was using patch to do that, but I suspect the outcome was exactly the same. My problem isn't in the gits or in the patch applications now. With what Chase gave me, I'm able to get all the way to that point, but it just doesn't build. And BTW, I believe the SDK I'm using is 05.03.03. Good to know the 5.04 is coming out soon.

    So to help me diagnose what's going on, after the initial git clone, should I be able to run a build on that and get a successful build? If so, then I'm failing to build right from that point. Since that's a huge download on that clone, I have a folder that is the files as of that git...none of the additional git branch and git checkouts since those went fairly fast. Point being, when I do a build on that very 1st git of code, I'm failing. Here's the last bits of spew from the build when building from the top level makefile with a modified Rules.make to point at the newly gotten kernel.

      CC      init/version.o
      LD      init/built-in.o
      LD      .tmp_vmlinux1
    arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle':
    twl-common.c:(.text+0x425c): undefined reference to `__cpu_suspend'
    arch/arm/mach-omap2/built-in.o: In function `skipl2reen':
    twl-common.c:(.text+0x4864): undefined reference to `cpu_resume'
    kernel/built-in.o: In function `sched_clock_cpu':
    hw_breakpoint.c:(.text+0x1a04a): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `sched_clock' defined in .text section in arch/arm/mach-omap2/built-in.o
    kernel/built-in.o: In function `show_interrupts':
    hw_breakpoint.c:(.text+0x2c92e): relocation truncated to fit: R_ARM_THM_JUMP11 against symbol `arch_show_interrupts' defined in .text section in arch/arm/kernel/built-in.o
    make[1]: *** [.tmp_vmlinux1] Error 1
    make[1]: Leaving directory `/home/cgrey/ti-sdk-am335x-evm-05.03.03.00/board-support/linux-am33x'
    make: *** [linux] Error 2
    cgrey@cgrey-desktop:~/ti-sdk-am335x-evm-05.03.03.00$


    My gut feeling is if I can't get this to build right on my machine, I'm not going to get much of anything else to succeed. But before I made that assumption, I thought I'd ask. It sounds like the next task is to get someone else to read through these instructions and see if they can get better results than I'm getting on my machine.

  • Did you run commands at step 4? Clean-up kernel (mrproper), configure with the right configuration (not taken from another kernel), and then build.

    SDK 05.03.03.00 should be fine: I read 05.03.00.00 in a previous post.

  • I was not doing the mrproper step. And as for the config step, I used that defconfig file Chase referenced above as my .config file. However I found that the top-level make wanted that defconfig to be a specific name and placed in the /arch/arm/config directory, so I put it there so the top-level make would work. So no, I'm no longer using the .config from another build. And yes I started off with 5.03.00, but Chase recommended I update to 05.03.03 and that's what I've been working with since. I've restarted the build of JUST the kernel code as it was fetched using git clone... If that succeeds, then that's a big step forward. I'll continue with the additional git statements. Attempt another build, just to make sure I'm still on the right track. And finally apply the patches & build. If I make it there, I think I'm where I need to be.

    Now the post mortem of why it took me so long to get there will be confusing to explain, but I'm sure 99% of it is my not knowing what things to do in what order. It's a heck of a learning curve, that's for sure. But if development were easy, anybody could do it...right?

  • Good news. The code from just the Clone built when I followed the 3-steps you mentioned. So I moved forward, did the next git commands to setup a branch and did the checkout stuff. I called the same 3 make calls. It's building as I type. With any luck, it'll finish with success. I'm about to leave for the day so even if it completes, I'll have to wait until Monday to see if it also builds with the patches.

  • The patched version builds and boots on the beaglebone. As well, I've confirmed that I can read from the AIs...at least from the prompt. So I can now move on with my investigations of the AIs.

    Thanks for all the help...

  • Hi Max,

    crashes on reading FIFO0CNT (0xe4)

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

    regards,

    alex

  • 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.

  • 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.

    Thanks,

    Raja.

     

  • 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.

  • 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

  • Raja,

    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

  • 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,
    };

    setup_pin_mux(tsc_pin_mux);
    platform_device_register(&tsc_device);

    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.

    Regards,

    Raja.

  • 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.

  • 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.

    Thanks.

    Raja.

  • 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.

  • Hi Christopher,

    Thanks for all your inputs and suggestions.

    I wrote C program with the AIN path and could decode the ADC values from the application. Initially i was not sure of the return values from the read call. On checking in the driver found that the value will be in the form of string. Converted the string to integer and compared ADC value with the ADC value manually calculated from input voltage is almost same.

    Thanks,

    Raja.

  • Ahh yes I should've thought to warn you about that. It was mentioned above, but may not have been obvious. The A/D counts are converted to a string, and then passed to a program in 4-char increments. A C-program would have to collect all 4 chars, then do a string-to-integer conversion if you wanted to see these in actual voltage form.