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.

I have got all the openjdk installed and working and I am in the process of checking it out with the OBLS code. I think a user interface re-write is needed for low resolution LCD usability though.

Brian Welsby wrote:

 

I think a user interface re-write is needed for low resolution LCD usability though.

That's probably common to just about everything. It always annoys me when assumptions are made that forces whatever button you need to click off-screen, there's no keyboard shortcut and they've pointlessly, but deliberately made the window or dialog box non-resizable.

One trick that sometimes works is to try to force the system to use a smaller default font to get buttons back on-screen, but that definately doesn't help small screen useability

selsinork wrote:

 

Brian Welsby wrote:

 

I think a user interface re-write is needed for low resolution LCD usability though.

That's probably common to just about everything. It always annoys me when assumptions are made that forces whatever button you need to click off-screen, there's no keyboard shortcut and they've pointlessly, but deliberately made the window or dialog box non-resizable.

 

One trick that sometimes works is to try to force the system to use a smaller default font to get buttons back on-screen, but that definately doesn't help small screen useability

The photo below is the client running on an LCD4.  This is with a "Test Device" selected.

That's great, seeing OBLS on the LCD. I suppose the code could be reworked to use on-board buttons if desired rather than touching through the menus too. Another idea is to have a rotary encoder that apps are able to use to perform the action in context, e.g. scroll left/right in OBLS, unless (say) a button was pressed to go into zoom mode.

The link you posted (about interfacing LCDs through HDMI) is interesting too, I'd still been working on trying to interface the large LCD throgh PRU by serializing the data. I haven't got very far yet, waiting on some ICs.

I got a bit further with the 1.8" LCD (ideal for status displays on smaller instruments, etc), and basically the PRU now waits for a 'graphics' instruction from the ARM-hosted app (a single byte instruction using shared mem), and currently it recognises just one command, which is to fill the screen based on a buffer of RAM that is populated by the application, as shown here.

The buffer is 80kbyte currently because I've not taken any effort to pack 16-bit pixels better (it could be reduced to 40kbyte).

However, although the PRU can access the entire address space, since the app has virtual address space, I need to have some pre-allocated fixed chunk of memory (that I can mmap), and there is such an area, but it's not much (and I couldn't figure out how to increase it, perhaps it's another device tree parameter). So, for now, I just write to the screen split into 8 smaller chunks and have some handshaking using the single byte. It works fast anyway.

The very unoptimized code currently takes a cairo drawn buffer, converts to the buffer used by the LCD, and then sends the 8 chunks. The cairo rendering of the shaded spheres and background in the photo is near-instantaneous, and that plus the sending of the chunks all occurs in less than a tenth of a second at a guess, and most of that time is the sending of the 8 chunks. So, I can't do video until I can learn to resize the memory, but I'm not very interested in that anyway.

More interesting would be to add some more graphics instructions to the PRU, for (say) sending a smaller image-fill to only a portion of the screen, or to draw basic boxes and text (I don't want to spend too much time on it, because there is only so much a tiny LCD is good for). I'll tidy the code a bit and post it in a day or two. (by the way I used the 27th May image, and enabling the PRU via the fragment .dtbo work first time - so hopefully this is more reliable in this build, although I didn't reattempt).

That's great, seeing OBLS on the LCD. I suppose the code could be reworked to use on-board buttons if desired rather than touching through the menus too. Another idea is to have a rotary encoder that apps are able to use to perform the action in context, e.g. scroll left/right in OBLS, unless (say) a button was pressed to go into zoom mode.

The link you posted (about interfacing LCDs through HDMI) is interesting too, I'd still been working on trying to interface the large LCD throgh PRU by serializing the data. I haven't got very far yet, waiting on some ICs.

I got a bit further with the 1.8" LCD (ideal for status displays on smaller instruments, etc), and basically the PRU now waits for a 'graphics' instruction from the ARM-hosted app (a single byte instruction using shared mem), and currently it recognises just one command, which is to fill the screen based on a buffer of RAM that is populated by the application, as shown here.

The buffer is 80kbyte currently because I've not taken any effort to pack 16-bit pixels better (it could be reduced to 40kbyte).

However, although the PRU can access the entire address space, since the app has virtual address space, I need to have some pre-allocated fixed chunk of memory (that I can mmap), and there is such an area, but it's not much (and I couldn't figure out how to increase it, perhaps it's another device tree parameter). So, for now, I just write to the screen split into 8 smaller chunks and have some handshaking using the single byte. It works fast anyway.

The very unoptimized code currently takes a cairo drawn buffer, converts to the buffer used by the LCD, and then sends the 8 chunks. The cairo rendering of the shaded spheres and background in the photo is near-instantaneous, and that plus the sending of the chunks all occurs in less than a tenth of a second at a guess, and most of that time is the sending of the 8 chunks. So, I can't do video until I can learn to resize the memory, but I'm not very interested in that anyway.

More interesting would be to add some more graphics instructions to the PRU, for (say) sending a smaller image-fill to only a portion of the screen, or to draw basic boxes and text (I don't want to spend too much time on it, because there is only so much a tiny LCD is good for). I'll tidy the code a bit and post it in a day or two. (by the way I used the 27th May image, and enabling the PRU via the fragment .dtbo work first time - so hopefully this is more reliable in this build, although I didn't reattempt).

Back in the late 80's early 90's I worked on a number of products based on the TI TMS34010 / TMS34020 gsp (now obsolete) and produced various terminal emulations and also a display list driven device. They were great processors to work with but I don't have access to any of the code now. 

I have an Olymex MOD-LCD6610 which I was thinking of trying out, it has an SPI interface. The links to Documents and Software on the Olymex site give you some basic algorithms written in C which I am sure can easily be implemented in PRU assembly.

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.

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