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

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.

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.