Remote monitoring *VoCore* CPU use

So I really wrote my CPU monitoring webserver program to be able to monitor my Raspberry Pi, but hoped that the code should run on other Linux machines too. Indeed, I have also been testing it in a virtual box running Debian. The code is runnable from Xcode on my Mac, but unfortunately it's a simulation only for testing purposes, because /proc/stat does not exist on Mac OS. So, for the moment, it definitely won't work on the Mac.

But I did think that it would work on OpenWrt, so decided to try it on my VoCore. In anticipation I had already put the necessary stuff in the makefile, so all I needed to do was go to a box with OpenWrt cross compilation set up and do this:  make vocore.

Then I copied the resulting binary executable to my VoCore and it worked straight away. I even made a recording of the initial run for posterity:

Since all the resources (html and javascript files) are embedded in the executable it is really very simple to do, just copy and run a single file. The version compiled for the VoCore came out at 112 Kb in size. Hopefully that's not too bad. I could compress the resource files if space was really important, but I haven't felt the need to do that.

It's pretty good to see this running on a machine about the size of a postage stamp. Obviously I could make it just show a single graph when it runs on a single core machine. Perhaps I'll do that when I get some time.

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.

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...