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.

Brian Welsby wrote:

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

Really nice to see it working, shame about the silly big icons and all the other wasted screen space. Legacy of assuming 'desktop' and a relatively large display.

What's needed is a physically small but still high resolution display, sadly those aren't common with useable interfaces - as that person on the hipstercircuits.com blog found out.

Yes, but at the moment only half working. The openjdk packaged for Angstrom has some issues so I am leaving that for now and seeing if Debian, Ubuntu or Arch are better. 

It is possible to hide the X top and bottom bars and reduce font sizes which gives a more usable display but as you say a higher resolution would be better, they do exist but are quite expensive. 

Progress is a little slow as I am making the most of the sunshine whilst we have it.

Brian

Brian Welsby wrote:

they do exist but are quite expensive.

Quite a problem given the comparitively low cost of a 19" dvi capable screen these days.

Progress is a little slow as I am making the most of the sunshine whilst we have it.

I managed to get myself fairly well roasted last weekend, so staying away from the evil sunshine for now...

Don't worry the normal rain will resume shortly, we've had more than our normal 5 minutes of summer for this year already

Brian Welsby wrote:

The openjdk packaged for Angstrom has some issues so I am leaving that for now and seeing if Debian, Ubuntu or Arch are better.

I have my doubts.  Been experimenting with my RPi camera recently and had to jump through all of the hoops of ditching their avconv nonesense and building ffmpeg from source due to them having castrated their version and leaving out anything useful.. Add to that a simple program that had been pointlessly seperated from it's parent package pulling in a pile of artificial non-dependencies and I'm even less impressed with the distros antics than I usually am.  Sometimes seems that they're deliberately out to make stuff difficult.

Latest Raspbian having ifplugd running against the lo interface kind of proves that debian and all derivatives are too far gone...

Brian Welsby wrote:

The openjdk packaged for Angstrom has some issues so I am leaving that for now and seeing if Debian, Ubuntu or Arch are better.

I have my doubts.  Been experimenting with my RPi camera recently and had to jump through all of the hoops of ditching their avconv nonesense and building ffmpeg from source due to them having castrated their version and leaving out anything useful.. Add to that a simple program that had been pointlessly seperated from it's parent package pulling in a pile of artificial non-dependencies and I'm even less impressed with the distros antics than I usually am.  Sometimes seems that they're deliberately out to make stuff difficult.

Latest Raspbian having ifplugd running against the lo interface kind of proves that debian and all derivatives are too far gone...

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

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

However, I'm acutely conscious that Gentoo is badly out of place on low-powered boards unless they're just cross-targets, 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.

Is there something we should worry about in Debian, beyond the closing down of options that is inevitable with binary distros?

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! 

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