Multifunction instrument based on BeagleBone Black

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

Here it is  http://hipstercircuits.com/ scroll down to "MAY 8" and the links are there.

selsinork wrote:

 

Still, it seems that you can do 1920x1080x30 with audio, and the full 1920x1080x60 without audio - at least in theory. There's more work on the driver needed to enable it though.

 

https://groups.google.com/forum/?fromgroups#!topic/beagleboard/4vge3Zs8dYE

Awesome!  More crispness in display is never bad, even if it's just to make the instrument have nicer text.

Audio can always be handled in some other way instead of being multiplexed onto HDMI, for example by tapping into the I2S header signals, or using a separate audio device on USB, or using network audio.

For use outside of instruments, some will bemoan the lack of video decoding in comparison with Pi, but given our focus on engineering applications and not media consumerism, that "lack" may well be an asset.

Brian Welsby wrote:

 

Here it is  http://hipstercircuits.com/ scroll down to "MAY 8" and the links are there.

HipsterCircuit's "A working display" in the June 1 post shows the monitor's EDID as having the same max resolution as the BBB has as shipped, so it's probably an edge case, ie. an exact match of capabilities.  Just for reference, my BBB is running into a Dell 2408 and shows, as one might expect:

root@bbb:/#  parse-edid /sys/class/drm/card0/card0-HDMI-A-1/edid

parse-edid: parse-edid version 2.0.0

parse-edid: EDID checksum passed.

 

        # EDID version 1 revision 3

Section "Monitor"

        # Block type: 2:0 3:ff

        # Block type: 2:0 3:fc

        Identifier "DELL 2408WFP"

        VendorName "DEL"

        ModelName "DELL 2408WFP"

        # Block type: 2:0 3:ff

        # Block type: 2:0 3:fc

        # Block type: 2:0 3:fd

        HorizSync 30-83

        VertRefresh 56-76

        # Max dot clock (video bandwidth) 170 MHz

        # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

 

        Mode    "1920x1200"     # vfreq 59.950Hz, hfreq 74.038kHz

                DotClock        154.000000

                HTimings        1920 1968 2000 2080

                VTimings        1200 1203 1209 1235

                Flags   "-HSync" "+VSync"

        EndMode

        # Block type: 2:0 3:ff

        # Block type: 2:0 3:fc

        # Block type: 2:0 3:fd

EndSection

This is an example of the more generic case then, with the BBB noting that the monitor is capable of more but correctly limiting its output to the best that it can do that is still compatible, or in my case 1280x1024@60Hz.  All working as expected.

PS. For fuller test coverage of EDID handling, one would also need to check operation into a display of lower resolution than the BBB's max --- quite likely to be relevant to instruments.

Morgaine.

This thread was a world of help. I can't wait to get mine. The implacation are endless! Thank you.

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