Control F1 Lead Developer Phil Kendall gives some handy pointers on how to get an HTTP REST server running on the iMX233 OLinuXino-MICRO.
As part of an on-going client project, Control F1 was asked to get an HTTP REST server running on the iMX233 OLinuXino-MICRO – a little ARM-powered small board computer. There’s a lot of documentation out there for the OLinuXino board, but it’s not always clear which is the most up to date, so this post covers how we managed to get everything working in 2016.
Before you begin…
…always buy the right kit. You’ll obviously need a board, but as well as that remember to get:
- A 5V power supply with a 5.5mm jack
- A MicroSD card
- A composite video lead (or another cable with RCA connectors)
- A USB keyboard
- A powered USB hub – we found that the OLinuXino didn’t put out enough power over its USB port to get keyboards to function
- A WiFi dongle, which uses the RealTek 8192cu chipset. It’s always a bit tricky to determine exactly which chipset is in a dongle, but as of February 2016, the TP-LINK TL-WN823Nwas using the right chipset
In theory, that’s all you absolutely need, but I’d also strongly recommend a composite to HDMI converter, just because most monitors don’t have composite inputs these days.
As with any of these kind of projects, the first step is always to get something running on the board. Thankfully for the OLinuXino, this turns out to be relatively easy: grab the “iMX233 Arch image with kernel 2.6.35 WIFI release 4” image as linked from the Olimex wiki, and then simply follow the steps listed there to copy the image onto the MicroSD card, put the card into the board, plug in the keyboard and video and you should get the standard Tux splashscreen, followed by a login prompt.
The first thing to check is that you’ve got any sort of communications at all; the easiest way to do this is to run a scan for any wireless networks:
That should be enough to give you a list of all the wireless networks that the board can see. Find your network and run:
/etc/wpa_supplicant/wpa_supplicant.conf, delete all the example configurations from the file and then add in MyNetwork.conf as you created above. After that, it should just be a matter of bringing everything up:
…and finally editing
/etc/resolv.conf to add an appropriate nameserver. With a following wind, you should now have fully working networking on your board and be able to SSH into it.
I’m a big fan of spray.io’s spray-can as a lightweight HTTP server. As spray-can is in Scala, the first thing to do is to get a JVM onto the box. This also turns out to be nice and easy – grab the “ARMv5/ARMv6/ARMv7 Linux – SoftFP ABI, Little Endian” version of the Java SE Embedded JDK from Oracle’s site. This contains the JRE as well as the JDK, so copy the JRE onto the board and ensure that java is on the PATH somewhere. Test this with your favourite “Hello, world!” implementation if you so wish.
Getting Scala running on the board was also relatively easy: simply copy scala-compiler.jar, scala-library.jar and scala-reflect.jar from whichever version of Scala you’re using on the board, and then run your Scala code as:
I packaged that up into a shell script and put that on the PATH just to make things easier.
The biggest issue with getting spray-can running is ensuring that all its dependencies are available. The easiest way I found to do this was to use the sbt-assembly plugin to produce a “fat JAR” and deploying that onto the board. sbt-assembly importantly does the right thing out of the box and merges Typesafe Config configuration files so that they all work properly. Other than that, the only change I needed to make was to increase spray-can’s start up timeout a bit, just due to the relatively slow speed of the board; this can most easily be done by adding the following stanza to
After all that, you should be able to run any of the spray-can demos on the board.