Multifunction instrument based on BeagleBone Black

Sources of inspiration.

Whilst researching what is available I recently came across this from Digilent - Analog Discovery, Priced at $99 for US Students, $159 Academic and $199 for the rest of us (£136.09 Farnell UK) A real problem for me though is it's not open source and is tied to a windows PC. I think this type of product, designed for the education market, should be open source but that's another story. I have recently spent a lot of money on BBB bits and pieces so whilst I would love to play with one and see if I could interface to it a BBB and produce a linux / BBB equivalent to their software, I can't justify the expenditure at the moment. It would still be great if I could get one at the student price, better still if Digilent gave me one along with the design info   Then again it would be great if I won the lottery. Well enough of the dreams back to the black...

I got to thinking about designing something with similar functions but not tied to windows or PC.  I looked at the R-Pi which has great graphics capability but little I/O and I have had a number of issues using the USB at high speeds.   Then along came BBB and it was like the proverbial light bulb switching on. All the I/O pins and two PRUs and more than adequate graphics and and and....

As Morgaine mentions above the OBLS and other "open source" products offer a solution and provide already working designs. I believe this to be a logical first step.

Thoughts then are to use this wealth of usefulness and cherry pick the best bits to a fully integrated product onto a cape or two.

Ok a tiny little bit of top-down design:

1. Low cost portable multifunctional instrument capable of but not limited to being a Logic analyser, Oscilloscope, waveform generator, frequency spectrum analyser ...  A design that has both digital and analogue functions.

1.1 Overall system control User interface and display
1.1.1 Beaglebone Black with either LCD + Touch screen or (not so portable) HDMI monitor, keyboard and mouse.

1.2 Digital functions
1.2.1 FPGA Cape with I/O buffering and protection linked to BBB PRUs for real time control and data transfer

1.3 Analogue functions
1.3.1 ADC + DAC Cape linked to FPGA cape for high speed capture and to PRUs for real time control

At this moment in time I am still getting to grips the the BBB and it's evolving 3.8 kernel and the various O/Ss that are available. Angstrom is ok, Ubuntu and Debian are fine but I quite like Arch Linux.  Of course the software for the "instrument" must not be dependant on any particular one though.

It's getting late so I will leave it  there for now.

Brian

Brian Welsby wrote:

 

Of course the software for the "instrument" must not be dependant on any particular one though.

I think the OBLS is a reasonably good example here, the preferred app to use with it is written in java and just needs to be able to open a connection to the board.

So the OS needs to be able to provide the environment needed to run the java app and, in the case of the OBLS something like libusb to talk to the hardware.

Now if you want direct connection rather than usb, perhaps spi-dev, or write a kernel driver to provide a /dev entry to talk to your hardware. Either way you're relatively independant of the OS, any hard stuff could be done in the kernel.

Interesting you should mention Lua, I have also been trying out various window managers to see what works well on the BBB with the LCD4 Cape and yesterday I was tinkering with Awesome.

Slow reply, sorry, completely missed this...

Morgaine Dinova wrote:

 

That's not really a Debian problem though, is it?

apt-get install ffmpeg    no errors, no warnings.. but you don't actually get ffmpeg, you get libav (http://libav.org/) instead. That certainly is a debian problem - if you got a message saying 'We don't have ffmpeg, would you like to try libav instead ?" along with a list of deficiencies I might be ok with it. At least you'd know the problem and have a choice.

I'd appreciate your expanding on this a little.  Although I've used Debian many times over the years, I've lived mostly in the Gentoo world over the last decade+, so I've never become deeply acquainted with Debian.  (Raspbian on Pi does at least work vastly better than Angstrom on BBB.)

I've never had good experiences with Debian, it's ranged from simple stuff like not installing properly, but not telling you it's failed to making vastly over-complicated messes out of what should be simple single config files. Or hiding the config files in some unknown directory.  It's difficult to undo the nonesense as the next update will likely change it all back.

Don't get me wrong here, I don't think other distros are particularly better or worse. I tend to think of them all as equally bad

Raspbian only seems better than Angstrom because it comes with more stuff, but for me this comes down to people trying to compare a $2000 desktop with 32Gb ram, a 4Tb hard drive and a 4GHz 8 core CPU to a $50 RPi / BBB and complaining that the BBB is slow..  I have my dislikes about Angstrom too, but I accept that it's far better suited to a small embedded system and the results are obvious from the thread with the simple 'bc' based benchmark - swap the angstrom binary onto the otherwise Debian distro and get better performance.

However, I'm acutely conscious that Gentoo is badly out of place on low-powered boards

I'd argue that's not anything specific to gentoo, rather it's inherent in all distros that have their roots in the x86 world trying to work on a small embedded device with the sort of resources PC's had 20 years ago. Today's desktop distro simply isn't the right choice.  Trying to develop a single solution for all the problems of every device from R-Pi up to Tianhe-2 (http://www.top500.org/system/177999) just means that everyone has to un-necessarily deal with everyone else's issues, and yet that's the place we find ourselves.

whereas Debian is the "distro franca" and has its freedom heart in the right place too, so I root for them in the embedded Linux world.  It's just a hope though, rather than the result of experience.

The problem with Debian is mostly that their philosophy is deep rooted and says that anything that doesn't live up to their definition of truly free doesn't get in.  This is the sort of thing that leads to you having the wireless driver, but missing the 'non free' firmware that you need before the device can work. Or having a device - like the Pi - that does x264 and the versions of libav/ffmpeg they use having x264 removed as that's 'non free' too.

Taking the hard line and standing up for what they believe in is a good thing, and in many ways we need more people to do it.  From a pragmatic point of view, if the thing doesn't "just work" without lots of faffing about then you've already lost.

So going back to ifplugd.. It's purpose is to detect loss of network connectivity due to a cable being unplugged and to re-request dhcp leases etc. when this happens. Debian is running it against the 'lo' interface - that's the virtual loopback interface, no cable to unplug, no dhcp or anything else, so this is just wasting memory and cpu resources on a small embedded device that has precious little of either to waste.  Sorry, I can't think of that as anything other than just plain dumb.  Even on a bigger machine with resources to waste you'd have to wonder what possible purpose it could ever serve.

I'll also note that a Gentoo/FreeBSD developer provides a far superior alternative to ifplugd/dhclient in the shape of dhcpcd-5 http://roy.marples.name/projects/dhcpcd/wiki/DhcpcdHistory

And as for distros in general, you're stuck between the rock and the hard place, you either live within the bubble of their packaging system with it's usually invalid (if not circular) dependencies and accept the limitations, or you start compiling stuff yourself.  Problem is that once you start compiling stuff outside their bubble all the dependency tracking nonsense falls apart and you have to live with all of those problems too.

Even if you should decide to compile your own stuff within their packaging bubble you run the risk that an 'official' update will come along and break things for you later - usually when you've forgotten the reasons for what you changed. 

So whatever way you look at it, you're in a no-win situation. Live with it being broken because your distro is philosophically opposed to it working or start building on your own distro where you set the rules. 

selsinork wrote:

 

And as for distros in general, you're stuck between the rock and the hard place, you either live within the bubble of their packaging system with it's usually invalid (if not circular) dependencies and accept the limitations, or you start compiling stuff yourself.  Problem is that once you start compiling stuff outside their bubble all the dependency tracking nonsense falls apart and you have to live with all of those problems too.

Even if you should decide to compile your own stuff within their packaging bubble you run the risk that an 'official' update will come along and break things for you later - usually when you've forgotten the reasons for what you changed. 

So whatever way you look at it, you're in a no-win situation. Live with it being broken because your distro is philosophically opposed to it working or start building on your own distro where you set the rules. 

I agree completely.  But I know the solution --- we need a better distro! 

Awesome worked better for me than anything other WM on a multi-head zaphod-mode setup.  For anything else, (e.g. BBB or RPi) pure dwm gives you the best of awesome with a much smaller footprint.  This isn't the fault of lua, but awesome just carried things too far (IMO). Editing the ~30 lines of C in dwm's config.h was easier than understanding the 200+ lines of lua configuration code in awesome. YMMV.

p.s. I didn't try dwm in zaphod mode (it looked too complicated), so I could be wrong about awesome being better there.

Sorry to change the topic slightly (still instrument related though!) anyone ever experimented with the USB analyzer on the original Beaglebone? I'm tempted to just buy a BBW if this works (although it would be nice to get it running on the BBB).

Not a change of topic, all part of being a multifunction instrument...  I thought that if it works on the BBW then it should work on the BBB and the BBB is faster so should work better

It's an interesting application .... on my list to check out unless someone else gets there first.

Brian

Morgaine Dinova wrote:

 

I agree completely.  But I know the solution --- we need a better distro! 

Let me know if you find one, in the meantime I'll keep working on my personal number 15

Brian Welsby wrote:

 

Maybe the best solution is to create a "C" based client.

Just a general observation, and it relates quite a bit to that other discussion with coder27 on the usefulness of abstraction to manage complexity. Here we have a nice example of all that abstraction up into a java app leading to something that's not particularly useful on this particular platform, quite possibly due to too much abstraction, too many layers etc.

On the various other suggestions of lua and such like, I'll not argue the point further other than to say that a decent C implementation could be better and faster, simply due to less layers, less bloat, and developers who can concentrate on being good at one language rather than mediocre in lots of less frequently used languages.  I'm certainly not suggesting the C version would be the easiest thing to write though!

Speaking of onboard buttons ... have you gotten them to work with your own code?

I have an LCD3 on one of my BBB's and would like to have the buttons accessible from Node.js.   The pins seem to be already allocated (the up and down buttons move the browser window) and when I try accessing them I get the following messages:

error: Unable to export gpio-48: Error: EBUSY, resource busy or locked

gpio-48 consumed by left

...

error: Unable to export gpio-112: Error: EBUSY, resource busy or locked

gpio-112 consumed by down

There was a post asking this question some time ago but I am not sure it was ever answered and it seems to have been archived.   I have tried to find where something is being loaded that might be owning these pins but frankly don't know linux well enough to know where to look.

Frustrated but thanks for any help!

Will 

they're likely assigned as gpio_keys in the LCD3's devicetree overlay fragment. So when you connect the cape the keys are setup for you. 

It's a great idea as long as all you want is for it to 'just work' in exactly the way it's been pre-configured. If you want to do something even slightly different it's terrible.

Have a look through the wonderful series of blog posts by shabaz, one of them shows you how to manually load and unload the various bits of device tree that get loaded on demand when you plug in a cape.  If everything works as it's supposed to, then unloading the LCD3 fragment should return the buttons to a state where you can use them through the normal gpio route.

they're likely assigned as gpio_keys in the LCD3's devicetree overlay fragment. So when you connect the cape the keys are setup for you. 

It's a great idea as long as all you want is for it to 'just work' in exactly the way it's been pre-configured. If you want to do something even slightly different it's terrible.

Have a look through the wonderful series of blog posts by shabaz, one of them shows you how to manually load and unload the various bits of device tree that get loaded on demand when you plug in a cape.  If everything works as it's supposed to, then unloading the LCD3 fragment should return the buttons to a state where you can use them through the normal gpio route.

selsinork:

As you said, shabaz has some very informative posts but I am not sure that I found the right one regarding device tree fragments.   Can I ask that you point me there directly please?   One thing that I tried from what I did find was completely disabling the LCD cape using "echo -6 >/sys/devices/bone_capemgr*/slots".   The LCD display went away but the pin assignments for the buttons did not!   Frustrating at best.

Will 

Seems like you've found the right one. What I'd expect to happen is that when you remove the cape in that way it'll remove everything and return it to the state before the cape was loaded.  If that's not happening then there could be a bug.  The code in use for this is quite new, I'd be surprised it there were no bugs at all.

Anyway, you can look to see if there's a module loaded called gpio-keys using 'lsmod', if it's there then try unloading it with 'rmmod gpio-keys'.

If that doesn't work then you'd need to modify the devicetree fragment for the cape so that it doesn't configure the keys.

Source to the fragment is available here https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/not-capebus/0038-capemgr-LCD3-cape-definition.patch  or it might be possible to use dtc to decompile the .dtbo file in /lib/firmware.  You'd go through the file and remove the complete section that starts with gpio_keys { then recompile it back to a .dtbo and replace the one in /lib/firmware with your modified one.

Also, there appears to be two versions of the LCD3 cape, an A0 and an A2, you need to modify the one that's used by your particular LCD3 cape

Thanks for the reply.  I am going to have no hair left from the pulling.   I would likely drop this if it were not for my client seeing the damn buttons and mentioning how nice it would be if they could augment the touchscreen on the instrument that I am building for them :-o

Anyway, I have whacked all the sections of the .dts file for my LCD (the A2 version), recompiled the file, checked that the datetime stamp shows success, abd upon a reboot THE KEYS ARE STILL BOUND!   So I whack the cape entirely "echo -6 >/sys/devices/bone_capemgr*/slots" and yes, STILL BOUND!   There is no gpio-keys module loaded but something obviously has them tied up.

Hence I wonder if there is some way to identify the process that has them?

Thanks again,

Will

I don't know if this helps but in applications I have been working on in  C I just take the button presses as keyboard inputs on stdin as they mirror the keyboard arrow and enter keys.

I haven't used node.js but there may be something similar.

Brian

Brian:

I am not sure why I didnt want to do that in the first place but in hindsight I think that is the way to go.  I will do it client side as it is quite easy in JavaScript and for the life of me I can't think of why this would be an issue given the user requirement.   Doop.   Thanks for ringing my bell.

Will

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

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

You're not the only one struggling with this same problem though:

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/YrFgufutPjo

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

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