Recovering a slightly broken Vocore

OK, I managed to mess up the network settings on my Vocore. Oh well, it happens. It's not too bad... the device was still booting up and running... but was not accessible by Wi-Fi or by plugging in a network cable. So it's back to a good old serial connection. This is what I have done:

I've used a USB to Serial 3.3v TTL cable that I already had, and then just poked some jumper wires into the right places. Surprisingly it seems good enough. Anyway, in case I need to do this again, I thought that it would be worth taking a photo. I'm using PuTTY on a Windows box as the terminal. The settings I'm using are:

  • Speed: 57600
  • Data bits: 8
  • Stop bits: 1
  • Parity: None
  • Flow control: XON/XOFF

I connected the USB-to-serial cable first, then opened the connection using PuTTY. You then have a blank terminal screen. Then I connect the power to the Vocore, and you get to see all the logging information as the device boots. After a couple of minutes I press enter in the terminal and end up with the usual OpenWrt startup screen. After that you can use the console like normal. Anyway, it's handy to have that written down somewhere, because I'll probably break it again at some point. But I can report that I was able to fix the network config and things are back to normal now. Phew.

New Raspberry Pi 2

So, I ordered a new Raspberry Pi 2 as soon as they were launched last week. When it arrived, I couldn't resist documenting the occasion:

Last weekend I booted it up and started having a play. It seems quite an impressive little computer.

But since I had never bothered to order a B+ model I've only been using the 'original' Raspberry Pi until now, and I had forgotten that I need a microSD card these days. But I did have one lying around, so that was OK. I used a cheap HDMI to VGA adapter to use an older monitor.

The other thing I noticed was that I needed a better power supply. In the past I was using a kindle charger... but I needed to borrow the charger from my hudl tablet to get 5v at 2A. Otherwise, there was a little rainbow square showing at the top right of the screen to indicate that the device wasn't getting enough power. So watch out for that.

By the time I had finished messing around, my workbench looked like this:

1980s Synth Music

I recently watched a BBC programme called “Synth Britannia” … after which I ended up adding a bunch of extra stuff to my Spotify collection. When I was going through the OMD back catalogue on Spotify, I noticed the album cover artwork for their “Dazzle Ships” LP from 1983. And I was pretty sure that I had actually bought that album back in the 1980s. So I had a dig around the house and actually found it. So rather than put it back into storage, I’ve put it on my wall for a bit:

Apparently, I bought the 1987 reissue, which makes sense because I would have been too young in 1983. It’s also interesting, because people say that nobody bought the album when it originally came out anyway. There’s also a wikipedia article, if you’re interested.

A couple of little Chromecast tricks

A neat trick I've been using with a Chromecast is to wirelessly play movies from my iTunes library from my MacBook onto my big TV. All you need to do is enter the following URL into google Chome: file:///users/[username]/Music/iTunes/iTunes%20Media/ (obviously substituting your username where indicated). You'll then be able to browse your iTunes stuff and play what you want inside Chrome ... which makes it easy to watch it on the Chromecast using the normal Chrome plugin.

If you've seen a Chromecast, you've probably noticed that there are some nice background photos to look at. But I've also discovered that you don't *need* a Chromecast to see them. Try pointing your browser to: https://clients3.google.com/cast/chromecast/home and you'll be able to see them on any device...

Vocore: mounting USB drives

So my next piece of work on the Vocore was to mount the filesystem from a USB stick. I found some instructions here. So I started adding all the necessary kernel modules, hoping that it would be as simple as getting the USB soundcard to work. It wasn’t quite that easy. I thought that I had done everything, but just got strange messages when I tried to mount the disk. Then I found this helpful link.

It described exactly what I was seeing. In short, you can’t rely on the error messages being returned by mount on OpenWrt. So to diagnose the problem, the most important thing was using the logread command to get some ideas why the USB drive was not mounting. In my case (I was mounting a vfat formatted thumbdrive) I needed to add support for Codepage 437 and ISO 8859–1 into the kernel. So when building OpenWrt, I needed to go into Kernel Modules -> Native Language Support, like this:

But both those character set problems were quite clear from the log entries, so working out what I needed to do wasn’t that difficult … once I knew that I should not trust the error messages being returned by mount.

And I did find some more detailed information about filesystems and character set problems here … albeit for a different type of device, but I think the principle is the same.

Anyway, as soon as I added the extra modules for the correct character sets then everything came to life and I could mount the USB disk. Happy days. So now I can play audio files from USB storage, which works great.

This is a journey into sound...

So I decided to try and get some sound out of my Vocore tiny linux box. It doesn’t come with any audio support, so I decided to add a USB sound card. I bought one of these, which I knew worked on the Raspberry Pi, so I knew had Linux support. They’re also pretty small:

I simply followed these instructions describing how to add USB Audio support to OpenWrt. At first, I chose to install sox as the player (I originally intended to use Madplay, but I don’t think it is supported on current versions of OpenWrt anymore).

I did not have much success playing mp3 files straight away, I kept getting sox WARN alsa: under-run messages when I tried to use the following command:

sox myfile.mp3 -d

Although sound was coming out … in chunks, so it was a partial success. But when I added a “-G” parameter to use temporary files (supposed to guard against clipping) like this:

sox myfile.mp3 -d -G

…then it worked fine for some lower quality mp3 files, but with a considerable delay before playing anything out the speaker. If I tried to play some better quality mp3 files then it was still stuttery. So then I started to experiment with reducing the sound quality, which sox can do easily. So I tried this:

sox myfile.mp3 -r 8000 -e unsigned -b 8 -c 1 test.raw

…which results in a raw file that can be played with the aplay command that comes with the ALSA soundcard drivers (specifically, the command above gives mono unsigned 8 bit with a rate of 8000 Hz). Whilst this results in a poor quality file, I found that the Vocore would happily play these raw files. In some ways it was kinda cool to hear my original mp3 file playing with a hiss in the background. But then I decided to see what happens if I create a file in “CD” quality, so I tried this:

sox myfile.mp3 -r 44100 -e signed -b 16 -c 2 test.raw trim 0 00:30

Note, that to save space on the Vocore I used the trim parameter to just convert the first 30 seconds. Playing that “CD” quality file on the Vocore also worked perfectly, with this command:

aplay test.raw -f cd

Passing the parameter -f cd means 16 bit little endian, 44100 Hz, stereo and is the same as passing -f S16_LE -c2 -r44100. Here’s a screenshot of a CD quality raw file playing on the Vocore with the aplay command.

So… what I’m doing now is using sox on another Linux box to convert the mp3 files and then just using aplay on the Vocore to play them. It should mean that sox is not actually required on my Vocore. It also means that playback is immediate and the quality is good. I will need to find a means to store the files, because they’re much bigger than mp3, but that’s a problem for another day… I’ll probably see if I can mount a USB stick or something.

Another lightweight webserver for the Vocore

Qin Wei, the inventor of the Vocore has written his own lightweight web server. But I haven’t tried it out personally, because I have been messing about with my own minimal webserver as well.

Actually, one of the reasons why I have been working on my own web server is so that I could run it on minimal hardware - the Vocore being a good candidate. So it goes without saying that I have been itching to try that out.

I already did a trial run some months ago, where I got it running on OpenWrt for some different hardware. So the procedure for the Vocore is pretty much the same. I’ve made it slightly easier, because the makefile now has a target called ‘openwrt’ which will do the cross-compilation. I guess it should work for whatever device your OpenWrt build environment has been configured for, but I’ve only tried it for the Vocore.

Anyway, I’ve just got to the point where I have had time to try it out. I still needed to install the POSIX thread library, by using these commands on the Vocore:

opkg update
opkg install libpthread

And after that I was able to run dweb without any problems, like this:

Even the ajax calls back to the Vocore were working, which means that I could build something to control the GPIOs through javascript in the browser, if I wanted. But in the meantime, I decided trying to serve up some of the system statistics, so I did this:

cd /dweb
ln -s /proc/stat stat.txt

Which makes the contents of /proc/stat available to the webserver, and meant that I could browse to /stat.txt and view the contents of /proc/stat in my browser. I thought that was an interesting little experiment.

LED blink program for Vocore + Dock

Having gotten one of the Vocore’s LEDs to blink from the command line, I decided that a simple C program to do the same thing would be useful, just to make sure that the cross-compiler has been set up correctly and that everything is working properly.

Having a program that just blinks an LED is pretty useful, just to verify that you can successfully run your code. If you’ve managed to cross-compile a test program like this, then copy it to the target hardware and see it working - then you can start building whatever you like with a degree of confidence.

So I’ve put the code for the Vocore blink program on GitHub just in case… NOTE: it’s designed to work without any additional electronics if you have the dock attached.

The project includes a simple Makefile which (hopefully) should work in most cases. As long as you have an OpenWrt build environment set up for the Vocore you should just be able to type make and you will then have the program cross-compiled and ready to be copied onto the device. Doing something like: scp ./blink root@192.168.61.1:/ should copy the program over to your Vocore. Once you’ve done that, you just need to ssh into the Vocore and run it.

Oh, you’ll probably need to make sure that the program has been marked executable with chmod, otherwise you’ll probably get a Permission denied message. I used chmod +x blink to do that.

Vocore has arrived

My tiny Vocore Linux machine has arrived from China. Cool! So far all I have not done much more than boot it up and check that I can log in and stuff. Oh, and I tried the web-based interface too. It seems to be working fine. A Linux box about the size of a postage stamp, what’s not to like?

Mine has the dock attached to it, so I’m just using a USB cable to power the device. I tried to power it off a USB socket on my MacBook … but there wasn’t enough current to allow the wifi to start. Some lights flashed on the Vocore initially, but then it went off a few seconds later. I think that this means that there is not enough current to allow the wifi to start operating… But when I ran it of a dedicated USB power supply it was fine.

Because I have the dock, I used an ethernet cable to connect to the Vocore, which means my laptop can remain connected to my home wifi and I can still use the Vocore with its default settings.

But when sitting in front of the command prompt I got as far as making some LEDs go on and off with commands like these:

echo 255 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness
echo 0 > /sys/devices/gpio-leds.5/leds/vocore:green:status/brightness

The advantage of doing that is that they use an LED which has already been connected up on the dock … so I didn’t need to wire anything up. I’m going to try the same thing in a little C program next. Blinking an LED is an ideal little test program

The next thing that I’ll do is try my own minimal webserver, which might be useful if I start running out of space. So that’s next on my agenda.

Apart from that, I’m not really sure what I’m going to use it for. I’m sure I’ll think of something...

Linux on Microsoft Azure

I've recently been messing about with Microsoft's Azure platform; and I already think it's brilliant. I didn't expect the support for Linux Virtual Machines to be quite so good. Literally with just a few clicks I created a Linux box on the cloud (I went for Ubuntu), I can't really see it getting much easier. I suppose I should have known when I recently saw that Microsoft's CEO Satya Nadella had presented this:

Anyway, the first thing that I did with Azure was test my Linux VM out by copying over my C webserver code and compiling it. Everything went perfectly. But I quickly realised that it would be useful to be able to leave my code running in another terminal session when I disconnected from the console. That's where I tried out GNU Screen which allowed me to start my program in a session and leave it running after I had disconnected. GNU Screen is a nice simple solution, which means that I can keep my code simple. I like this :-) And at the same time I noticed a couple of bugs in the webserver code which I had not spotted before, so I was able to fix them too.

It's great to think that I can write some C code on my MacBook; cross-compile and test it on a small router running OpenWrt, then move it to the Azure platform without any worries. This is one reason why I still like programming in C (and Linux).

Next I decided to copy my H2D2 server across to Azure (of course). Again, everything worked perfectly. So I'm currently testing H2D2 on the cloud, let's see how stable it is. I also took the opportunity to tidy up the html, to make it look more presentable as well:

For some reason it came out in grey. I don't really know why.

Since I'm expecting to see a few crashes, I have used a simple shell script like this one which will restart my server program when something goes wrong.

Originally, I started with the most basic type of VM on offer, with a shared core. But then I did an upgrade to an 8-core machine, which gave a noticeable performance boost (as you'd expect). It was nice to see that Azure can upgrade your VM really easily, yet again it was all done with a couple of clicks (and a reboot of the VM). But now, to save CPU I've gone back to the shared core again which will be less of a drain on my account.