Actions
Forum Thread Details
  • Replies 45 replies
  • Subscribers 59 subscribers
  • Views 4357 views
  • Users 0 members are here
Related

Multifunction instrument based on BeagleBone Black

shabaz

Hi Brian,

 

We're thinking on the same track. I'm interested to hear what your cape is like, and ideas you're considering for it's use and how good the touchscreen is. It looks like a very high quality screen. I've been experimenting with connecting up a larger LCD with the same resolution too, it may be the same model maybe, although I just have the bare LCD, not a cape, so I have a bit of interworking to do currently. I was undecided if I wanted to hook into the dedicated LCD pins (full color) like your cape, or go the PRU route (with reduced 256 or 65k color initially), since both methods could be useful depending on the application. I'd be interested to know if it works with the current release software, and what gets configured in Linux to set the correct timings (I've not really experimented with display drivers in Linux before, so I'm not sure where to look). I think it will be really neat if we can get several different sizes of LCDs working using both methods to cover a few different scenarios.

LCDs are so expensive though.

  • in reply to Former Member

    Will Kostelecky wrote:

    There is no gpio-keys module loaded but something obviously has them tied up.

    just had a look and it seems that gpio-keys is compiled into the kernel, instead of a module, so no way to remove it.

     

    As an experiment, try moving all of the LCD related dtbo foles out of /lib/firmware then rebooting. It's going to leave you with an lcd that doesn't work, but it'll let you know if the lcd dtbo is doing it or something else.

     

    After that you can do something like dmesg | grep bone-capemgr the output of that will have lines something like

     

    [0.693356] bone-capemgr bone_capemgr.8: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'

     

    that gives you the filenames of what's getting loaded and from there it's just a matter of identifying which one has the bindings and then working out how to alter it.

     

    All else failing, it should be possible to remap the keys using the 'kbd' package. Unfortunately kbd doesn't appear to be in angstrom, or at least opkg doesn't think there's a package of that name. You can grab the source from http://git.altlinux.org/people/legion/packages/kbd.git though

  • in reply to Former Member

    Will Kostelecky wrote:

     

    for the life of me I can't think of why this would be an issue given the user requirement.

    only way I can see it being an issue is if you'll ever have a proper keyboard connected and you want the lcd3 keys to be seperate. If that's not the case then just do what Brian suggests.

     

    I know what I'm like, and it would annoy me that I couldn't get it working the other way and I'd end up spending ages working it out anyway.. If for no other reason than not wanting to let it get the better of me image

  • in reply to Former Member

    selsinork:

    I suspect that someone will get a handle on it but I have to admit defeat!   I can use a JavaScript intercept, in fact can write a nice little shared module to do so, that will meet my requirement so I need to sling some code rather than battling the demons of GPIO and device trees!   Thanks for the help though... I may come back to this but for now it is on to other races,

    Cheers,

    Will

  • in reply to Former Member

    The whole mechanism does have a few idiosyncracies at the moment, and things change from release to release.

    I had an issue where I wanted to unload the (built-in) HDMI cape. I could not gain control of the pins when I did the "echo -x ..." command, and the eventual workaround was to remove it from the .dtb file in /boot - not ideal :-(

    I