CONTROL F1 MENU Getting an HTTP REST server running on the iMX233 OLinuXino-MICRO Posted on April 8, 2016 by Editor 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. First steps 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. WiFi 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: ip link set wlan0 up iwlist scan That should be enough to give you a list of all the wireless networks that the board can see. Find your network and run: wpa_passphrase SSID PASSWORD > MyNetwork.conf Now edit /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: wpa_supplicant -B -i wlan0 -Dwext -c /etc/wpa_supplicant/wpa_supplicant.conf ifconfig wlan0 <ip address> up route add default gw <gateway address> …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. HTTP server 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. Scala 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: java -Xbootclasspath/a:/full/path/to/scala-compiler.jar:/full/path/to/scala-library.jar:/full/path/to/scala-reflect.jar -jar helloworld.jar I packaged that up into a shell script and put that on the PATH just to make things easier. spray-can 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 application.conf: spray.can { server { # spray-can can be a bit slow to start on the board, so give it more time to start bind-timeout = 10s } } After all that, you should be able to run any of the spray-can demos on the board. Share this: TwitterFacebook Loading... Related Adventures in Spark on Elastic MapReduce 4 August 12, 2015 In "Blog Post" R, spray-can and Docker October 31, 2016 In "Blog Post" Building with .NET Core and Docker in TeamCity on AWS May 19, 2017 In "Blog Post" Posted in UncategorizedLeave a comment Can small businesses benefit from the Northern Powerhouse? Making the most of Docker for .NET development Leave a Reply FOLLOW BLOG VIA EMAIL Enter your email address to follow this blog and receive notifications of new posts by email. Join 11 other followers FOLLOW RECENT POSTS Building with .NET Core and Docker in TeamCity on AWS May 19, 2017 How data and intelligence are not the same thing December 16, 2016 Labels, Camera, Action…! November 4, 2016 R, spray-can and Docker October 31, 2016 Why you can’t afford to ignore the new Health and Safety sentencing guidelines September 7, 2016 FOLLOW CONTROL F1 ON TWITTER My Tweets RECENT COMMENTS Fatima on Adventures in Spark on Elastic… philcontrolf1 on How to use the MATLAB Compiler… Leow Cheah Wei on How to use the MATLAB Compiler… Stuart M on Labels, Camera, Action…! Stuart Mallinson on Can small businesses benefit f… Create a free website or blog at WordPress.com. Follow