Tag Archives: raspberry

OpenJFX with RaspberryPi

JavaFX on the Raspberry Pi is a particularly nifty platform to use when you need a nice looking GUI on a regular monitor or a touch-screen. The platform used to ship along with JDK8 for ARM directly and was bundled (last I saw it still was) with out of the box Raspbian.

However, from update 33,  Oracle decided to drop the support for JavaFX on the ARM distribution of their JDK, and stopped shipping it within as well.

However the story doesn’t end here. This change just expedited my idea to give OpenJFX a try, after which I wished I did that way sooner.

My test bed was a RaspberryPi with PiTFT and a touchscreen adapted JavaFX application. Previously I had implemented a headless start of the JavaFX application with fbcp running in the background, and having all the parameters for the touchscreen set right in order to get a nice and correct projection of the FX framebuffer. With OpenJFX, this was no longer needed, cause it is directly supported.

In order to quickly get and use OpenJFX on Raspbian, follow these steps:
– Get and flash a fresh Raspbian image. Make sure you have java and javac present.
– Download a built OpenJFX package (OpenJFX 8u## stable for armv6hf). I used @chriswhocodes OpenJFX builds. There are others listed at the OpenJFX community builds page.
– Extract the contents of the zip file. Copy the /jre/lib folder contents somewhere in your project (I simply copied everything to the project root folder).
– (include the /ext/jfxrt.jar file in your classpath if you compile in an environment without JavaFX present in the JDK)

Finally, when executing your java application, pass the following arguments to the JVM:
-Djava.ext.dirs=dir/to/jfx/ext (I used .dirs=ext because I unpacked the lib contents in the project root)
-Dmonocle.screen.fb=/dev/fb1  (only if you use a touchscreen (like the PiTFT)
-Dprism.order=sw (again only for touchscreen, but I’m not really sure. If you experience problems with eventual hardware rendering, use this)

The outcome was pretty pleasant. The UI was looking good and it adapted just fine, although be careful with the dimensions and the general conditions (see tips here).  Also, I had no need to calibrate the screen, it was working correctly from the first run. And last but not least, having not to use fbcp in the background is a huge performance boost and resource saver.


Main screen with buttons LED light screen with color picker


Hi-Fi Audio Center with RuneAudio and RaspberryPi A+

For quite a long time, I had a RaspberryPi A+ just laying around and doing practically nothing. Every now and then I used it for some testing and occasionally playing around with the Unicorn HAT, but overall, because of the lack of connectivity and performance limitations, it remained heavily unused.

Then one day, I stumbled upon rpiMusicPlayer.com and I liked every aspect of the software and the concept behind it. Having a miniature audio center at my apartment which can connect to my music library and be able to accept music streaming, was a great idea. So I decided: my A+ will finally meet the reason it was created for.

The procedure for getting the whole thing is rather forward, but can be bumpy based on the equipment you have.

  1. Acquire a RaspberryPi A+ with a microSD card (preferably class 10, 8GB) and an adequate power source
  2. Think of how you want to connect the rasberry pi to your home network. The A+ doesn’t have an ethernet port, so if you want wired connection, get a USB to ethernet adapter. If not, do what I did, and get a wi-fi dongle. I used Tenda Pico wireless adapter. It was one of the supported adapters at the official RaspberryPi documentation site, and it hasn’t caused me any troubles before. Also, it’s rather cheap.
  3. Download the image for the rasbperry pi based software.
  4. Follow the steps for flashing the SD card with the image.
  5. Connect everything.

Now, if you have an usb to ethernet adapter, I suppose everything should work right off, if your router has DHCP enabled.

If however you use Wi-Fi for connectivity, the procedure is a bit more complicated, since the A+ has only one USB port and it will be used by the Wi-Fi dongle.

There are two possible ways of handling this:

  1. Try to connect a self-powered USB hub and attach the dongle + usb keyboard to it. Then, through the console, try to configure the Wi-Fi connection by using wifi-menu. Some details here. The username is ‘root’ and password is ‘rune’
    This however, regardless of how simple it seems, I failed to configure. Therefore:
  2. Get a B+, connect it to your router (or crossover to a computer) via ethernet and plugin the wi-fi dongle. Boot everything, and wait enough time (around 1-2 minutes) for the software to start. Then, from a computer on the same network, try to open http://runeaudio.local/ in your browser. If that fails, then seek for the IP address in your router (the hostname is runeaudio) and try with it (e.g. In the menu open network and configure your wireless connection (http://runeaudio.local/network/). Next, shutdown the system via the UI and poweroff your B+. Eject the SD card, insert it in the A+, move the Wi-Fi dongle to the USB port as well and power the device on. If everything is OK, you should be able to access the system at runeaudio.local.

At this point, runeaudio will use the audio jack on the A+ to render the music at. However, this is not the perfect option since the Digital to Analog converter there is possibly trivial. Therefore, you might think of acquiring an external DAC which will improve the overall quality. Some of the supported DACs are listed in the homepage of the project. Bear in mind, that the DAC will add no value if you use cheap RCA cables or low-end audio system.

I used HiFiBerry DAC+ with RCA connectors. The price is fine and the shipment was quite fast. In order to configure runeaudio to use the external DAC, simply open the web UI, go to settings and choose your device from the listed I2C kernel modules. It will require a reboot which is not a problem. Then, open the web UI again, go to MPD and choose the Audio output interface to be the DAC you’ve just configured.

Sweet, sweet sound (RasPi A+ with HiFiBerry DAC+ running on RuneAudio)
Sweet, sweet sound (RasPi A+ with HiFiBerry DAC+ running on RuneAudio)

After installing and getting the whole thing up and running, you can resume on with configuring it.

RuneAudio has a pretty nice web UI which will allow you to do everything you need. By now, I haven’t got to the point where I need to access the device via SSH and do some manual config.

Out of music sources, you can add several. I would just mention shared network libraries, AirPlay, dlna and spotify.

RuneAudio WebUI
RuneAudio WebUI

As a conclusion, I must say I’m pretty satisfied with the outcome of this project. I’m mainly using it via AirPlay and so far it hasn’t caused me any troubles, regardless that it is connected solely by a cheap Wireless g USB dongle.

There might be some situations where the web UI will be non responding, some settings will not be saved from the first time or the loading spinner will not disappear (often happening during active air play stream). Besides that, the entire system is a rather cheap but effective, high-quality and most importantly, very usable.

DoorNFX: Touchscreen JavaFX 8 on Raspberry Pi

As of March 2014, Java8 is finally out there. Bunch of new features and improvements, not that they weren’t known previously, but good that they went official. The ones that I’m targeting with this blogpost are JavaFX, JDK8 on ARM devices, and their joint functionality.

The new JDK for ARM is targeted specifically for v6/v7 ARM HardFloat ABI devices running on Linux. The best and world-wide accepted example for this is the Raspberry Pi running on an OS like Raspbian. This JDK was around for some time with the early access program, so I had the chance to play around with it previously. However, for the example below, I’m using the official version.

JavaFX is, as the definition says, a set of graphics and media packages that enables developers to design, create, test, debug and deploy rich client applications that operate consistently across diverse platforms. In short, it’s a Java framework building Rich Internet or Desktop applications. Some of it’s features include:
– Pure Java API integrated in JavaSE: as from Java8, JavaFX is an integral part of the JRE and JDK. It’s API i in pure Java so it can be used any language that runs on the JVM.
– UI can be defined either programmatically or declaratively via FXML
– Interoperable with the old Swing
– All UI components can be styled with CSS
– New theme ‘Modena’ which makes the UI look very nice fora change
– General 3D features, hardware acceleration support
– WebView component which allows two-way interfacing (Java to JavaScript and vice-versa)
– Canvas and printing API, support for RichText
The easiest way to explore JavaFX is to play around with the Ensamble app on the Oracle web site.



So, as an example, I decided to make my NFC PN532 Java port to some usage and make some exact device out of it. My idea was to make a protected door access node which reads NFC Tags, prompts for a user code, authenticates it against some remote server and grants or declines access based on the output.

The core of the device is a RaspberryPi model B. The GPIO section has more than enough options for connecting multiple external devices. For the device, I’m using two such devices which are made specifically for the RaspberryPi: PiTFT and ITEAD PN532 NFC module.


DoorNFC - Device

The touchscreen used is the adafriut 2.8” PiTFT resistive touchscreen with 320×240 resolution. It is a actually a Pi HAT device with a socket the same as the raspberry pi. Its assembly is very easy, and it’s usage with the Raspbian OS is relatively simple. For communicating with the RaspberryPi it uses the SPI interface.

The ITEAD NFC Module is a PN532 based board with an integrated antenna. It exposes the same functionality as all the other PN532 boards and uses either SPI, I2C or UART for communication. However, this device also has a native RaspberryPi header interface. One bad thing is, this interface can only work with SPI. Since the SPI and the same channel is already taken by the PiTFT, I made some alteration of the NFC module in order to patch it to work with the same header but by using I2C. I’ve described that procedure in my previous blogpost.


As the core for starting the device, I used the pre-built adafruit image of the Raspbian OS. This image is described in details in the adafruit tutorials section. Basically, it is a Raspbian OS with the patched kernel, driver and necessary configuration to enable and use the PiTFT. Besides all that, it also comes with JDK8 and nicely split GPU/CPU memory which is the core need for running JavaFX applications on the Pi.

With only the image however, the job for configuring the device is not done. First, the FrameBufferCopy tool (fbcp) will be needed:

Then,  the start-up console needs to be disabled. Do this by removing the fbcon map and fbcon font settings in /boot/cmdline.txt.

Next, and this is the trickiest part, the display needs to be adaptad to be with the same format as the PiTFT. The touchscreen is designed to be in portrait mode with resolution of 240×320. The original configuration of the X server done here is by rotating the display and re-calibrating the touchscreen. JavaFX runs in a framebuffer and it’s not connected to X whatsoever. Therefore, the display and the touchscreen behavior work differently and wrong. This can be fixed by force-adjusting the display resolution to 240×320 and not rotating the screen by default. In order to do so, alter the settings in /boot/config.txt:

and by resetting the rotation in /etc/modprobe.d/: rotate=0

At the end, in order to enable I2C, modify /etc/modules by adding:

and comment out i2c in /etc/modprobe.b/raspi-blacklist.conf.


The software for the device is already on github: https://github.com/hsilomedus/door-nfx

There are two packages present:

Writing JavaFX code for the Pi is rather straight forward. The  most important aspects have to be met at start, as they are more environment related. Others are just tips. Some that I can mention:

  • The CPU/GPU memory split needs to configured correctly in order to achieve nicer performances (or even to get the JavaFX app up and running). 128MB for the GPU is a decent amount.
  • The JavaFX app will run in a framebuffer. This is maybe the biggest difference that you must have in mind. Running JavaFX apps on the Pi is not conditioned by the presence of an X server: they don’t run in a widget or a frame and can be invoked straight from a console. Even better, running a JavaFX app from an X session will most likely break it and freeze the UI after you exit it. Always execute the JavaFX app from a console, local or remote.
  • Because the app will run in a Framebuffer, make sure that you use and manage all the visual space that you have in your disposal and run it in full screen. You can still run it with fixed size, but then it will most probably end up centered on the screen.
  • JavaFX will register it’s own Keyboard and mouse handler and render a mouse pointer. If you have some settings done in X that change the behavior of the mouse or the keyboard, they will not be present here. E.g.: a major problem with the touchscreen was the initial rotation. The screen was rotated, but the touchscreen was only calibrated for that in X. That’s why the settings here are reversed and the display is in portrait.
  • Last but not least: JavaFX runs in its own thread. If you are to populate other heavier operations from the main routine or an event handler, do it in a different thread. If you need to alter something UI related from a different thread, use Platform.runLater.

You can see some examples already implemented in the source code. It’s not very pragmatic or anything, but enough to get the idea and to get the device working.

A general frame of a basic JavaFX app looks something like this:

The other part of the code is the pi4j usage. Here I’m using the managed way to access the hardware aspect of the Pi and send/receive data through it:

  • I2C is used for communicating with the NFC PN532 module. The API is simple but the hard part is maintaining the protocol set by the device manufacturer:

    The adress of the device can be given by the manufacturer of the device,  or you can look it up with the tool i2cdetect or something similar. See some tips in this adafruit tutorial.
  • General I/O pin provisioning can be also combined, regardless that both SPI and I2C are used. Just make sure that you don’t provision a PIN somehow that will break the other two interfaces. Again, here I’m using the managed API of pi4j:

Some remarks about using pi4j:

  • Since pins need to be provisioned (exported), the java process MUST be started with sudo, or else it will fail.
  • I2C is used for communication, so make sure that the device is enabled and not blacklisted
  • The communication is not reliable. Your app should be prepared for that and easily recover from misscomunications.


For ease of access, I’ve added two shell scripts (build.sh and run.sh) to make my compile&test experience on the Pi bearable. The pi4j library is automatically added in the classpath in both compile and test, the java process in run with sudo and fbcp is run in parallel.

The performance of the app itself is so-so. I can’t really deduct a conclusion since fbcp is an important parameter, and it may alter the visual response. Overall it is usable, but still not on that level that I want to see.

Always bear in mind that the device is quite limited with resources, and the platform itself is still catching up. It would be great if some ideas done in OpenJFX like setting a target framebuffer or altering the touchscreen input are implemented in the Oracle JDK too. That way, the output will be independent and I would presume more efficient.

P.S. I’ve also done a different JavaFX app which reads RFID tags, runs on an HDMI monitor, and is used as a poll. The output is quite bigger, the solution is simpler, but the overall user experience is still similar.

Overclocking the Raspberry Pi with OpenELEC

The Raspberry Pi, if limited only to rendering HD videos, handles the job quite nice. The hardware accelerated video playback makes things run smooth.

However, if you’re using some software like xbmc, or the complete solution with OpenELEC, then the navigation and everything else can get sloppy.

A nice way to speed things up there, and make the navigation smoother, is to overclock the Pi.

Along with some new firmware versions, the configuration file comes with some suggestion presets as options for boosting the Pi. With them, the arm, core and the memory frequency can be increased, and also the overvolt option.

Increasing the frequency or the overvolt parameters will inevitably increase the thermal output of the device. Now this can still be in acceptable limits, but if the pi is being used a lot in a prolonged period, it can become either unstable or freeze.
To be on the safe side, I recommend that you purchase some thermal sinks and stick them to the important chips on the board. I bought these from dx.com, and they are working just fine.

RasPi_sinksThe easiest way to do the overclock is to use your PC. Insert the SD card in the SD card reader, and open it to view its contents. Find the file named ‘config.txt’ and open it with a text editor.

Somewhere in it, you can find the following lines (or similar):

The Modest, Medium, High and Turbo are the suggested presets which, allegedly, have been tested. In order to use one, uncomment the four overclocking values, and insert the ones from the preset. I jumped directly to the last one, so my config at the end looked like this:

Note 1: the sdram_freq have been said that should be configured to 600 for the Turbo mode. Some users have reported SDcard corruption when said to be 500. I haven’t tested this out yet.
Note 2: leave the force_turbo=0. This means that the device will dynamically increase and decrease the frequency based on the load. This can prolong your Pi’s life, and will probably prevent some corruptions happening. Forcing the turbo mode uses the overclocked values as constants, but also voids your hardware warranty.

After editing the config.txt file, save it, and put the SD card back to the Pi and boot it. The system should now run with the changed settings.

Since the force_turbo option remains zero, the CPU frequency changes, and some tools will still report the same 700MHz. If you make some heavier load, this will change though. After some playing around, I snapped this:

RasPi_openelec_clockedAfter the overclocking, I got some very noticeable improvements in the xbmc navigation. Stuff started to move smoother. It’s still not perfect, but it’s much more manageable now.

Also, the thermal sinks seem to be really needed. The one on the cpu seems was quite hot after having the Pi run for about three hours.