Back again after a long wait…

I recognise that it’s been a while since I last wrote anything here, but I’ve been keeping myself busy and haven’t been inclined towards writing. However, I have been working on a few things which seem rather relevant to the scope of this blog. I’ve found quite some use out of the NAS that I mentioned in my last post, I’ve been working on electronics experiments and have further built up my Raspberry Pi collection with a new addition.

Synology DS416 – Performance Benchmarking

In order to get some sort of understanding of the performance of my Synology NAS, which I have connected through its two 1GbE ports to an 8-port Netgear GS108E switch, I decided to use IOmeter to pit it against the data storage drive I have in my computer, a 3TB 7.2K Seagate SATA disk. As artificial as the results from IOmeter can be, it still gives a good idea of what the speeds are like against the SATA disk on which I put most of my non-OS files. Using a maximum disk size of 1,048,576 sectors (or 512MB) and leaving the tests running for 20 minutes each, I got the following results, where Z: corresponds to an iSCSI volume on the NAS and D: corresponds to the SATA disk:

4KiB; 50% read, 50% write; 50% random

Z: 692 IOPS, 2.84MBPS, 23ms latency

D: 185 IOPS, 0.76MBPS, 86ms latency

64KiB; 0% read, 100% write; 0% random

Z: 552 IOPS, 36.15MBPS, 29ms latency

D: 849 IOPS, 55.62MBPS, 18ms latency

64KiB; 100% read, 0% write; 0% random

Z: 1787 IOPS, 112.33MBPS, 8.9ms latency

D: 939 IOPS, 62.91 MBPS, 16.6ms latency

In the 4KiB test, which would appear to be the most representative of real-world tasks involving using the storage as a standard drive (although I would expect more reads and more random data to be passed through in that circumstance), the NAS clearly had the advantage, with three times the IOPS, three times the data throughput and a third of the latency. The NAS is not as good in the 64KiB write-only test, possibly as a consequence of the RAID penalty applied since the four disks in the array are set up in RAID 5, but the NAS takes the lead again in the 64KiB read-only test, both of which might represent me writing or reading in a manner befitting the drives’ purposes as archival drives. The read-only performance of the NAS also lines up with the maximum network read throughput that I’ve seen.

I’ve also installed a Windows 7 VM on a separate 1TB iSCSI volume on the NAS which I’ve used with VMware Workstation to provide me with some ability to play Windows games without having to reboot my system. There have been some issues with stuttering, which would be a deal-breaker in action games but has been sufficient for the strategy and WRPG titles that I have been using it for, like Hearts of Iron III and Planescape: Torment.

Electronics experiments – a new collection of gear to try out!

The electronics experiments that I had been doing before with my Raspberry Pi had gone on the backburner for a long time. However, with Robot Wars back on the BBC recently and my younger brother interested in building a robot, I’ve decided to get back into the world of electronics experiments with the idea of getting enough knowledge to build a basic robot, at which point I can get my brother involved with various tasks. To that end, I’ve stocked up on a whole new list of components. At the moment, most of these are limited to things I can stick on a breadboard instead of motors and so on, but the components I’ve picked up include MCP23017 I/O expanders to complement the MCP23008 that I already have, an alphanumeric LCD display, a few AY-3-8910 sound chips, along with piezoelectric speakers, LM386 amplifiers and audio jacks and a few crystal oscillators for the sound chips. I’m also expecting a delivery of SN76489 sound chips within the month.

So far, I haven’t got too far; I’ve done some experiments to illustrate that the MCP23017 chips and LM386 amplifiers work, but I’ll need to learn how to solder before I can test the alphanumeric LCD and the AY-3-8910 sound chip will require some time to understand before I can get it tested.

Anyway, here’s a basic schematic using the LM386 amplifier:

LM386 Amplifier_bb

Pin 5 on the LM386 IC is connected to a voltage source between 4V and 12V, while pin 4 is connected to ground. Pins 2 and 3 of the LM386 are hooked up to the ground and the positive line of the input from the audio jack respectively. Pins 1 and 8 can be hooked up to a capacitor with a maximum value of 10kΩ to increase the gain, but I decided to go without and use the internal gain of 20 just to test that the IC worked. Then, pin 6 is connected to the positive terminal of a piezoelectric speaker, which produces sound, although the datasheet recommends using various capacitors in order to smooth out the sound and reduce noise. Pin 7 of the LM386 provides a bypass for sound without amplification, but this goes unused in this circuit.

A new Raspberry Pi and plenty of toys for it

The Raspberry Pi Zero, since its launch, has been one of the most desirable and difficult to find models of the single-board computer. I’ve been interested in having one for the novelty of such a small, yet capable computer, but the propensity for it to be sold out has put me off. However, the Raspberry Pi Foundation recently announced the Pi Zero W, a variant of the Pi Zero with on-board Wi-Fi and Bluetooth in the same form factor, although with a price of $10 rather than $5. Since adding Wi-Fi and Bluetooth capacity to a standard Pi Zero would generally increase the cost more than the extra $5 equivalent premium that the Pi Zero W has over the Pi Zero on its own and require awkward USB extenders, this appealed to me and I decided to pick one up along with the official case.

Along with the new Pi Zero, I’ve also picked up the standard and NoIR camera modules, a Sense HAT and a Gertduino add-on board to provide the capacity of an Arduino Uno to my Raspberry Pis, especially the older Model B boards that I rarely use any more. As with the electronic components, I’ve only tested these enough to verify that they work, but I’m looking forward to using them when I find the time.

With respect to the Raspberry Pis that I already have, I’ve recently installed RetroPie on a spare microSD card for my Pi 3 Model B. I’ve been impressed by the performance of the Pi when it comes to emulation; even PlayStation games have been smooth on the system, while older systems like the SNES and Mega Drive have worked excellently. I took the system for a spin with some of my friends in a retro gaming night; let’s just say that my Tekken skills could do with a bit of an improvement! Installation of RetroPie is very simple and very accessible as well; after copying the OS image onto the microSD card, everything else on the system is straightforward and it’s possible to copy ROMs and disk/disc images on with a USB drive without any particular effort.

More Raspberry Pi Electronics Experiments – Gertboard and Potentiometer-Controlled LED Cluster

One of the things which alerted me to the potential of the Raspberry Pi as an electronics control system was the announcement of the Gertboard before the Raspberry Pi was released into the market. When the Gertboard was announced for sale in November 2012, it was fully my intention to buy one, but a lack of money kept me from purchasing it at that point. The unassembled Gertboard kits soon sold out, leaving element14, who distribute the Gertboard, to decide to release an assembled Gertboard. This went on sale very recently, and shortly after release, I bought one from Premier Farnell’s Irish subsidiary.

The Gertboard, for the uninitiated, is an I/O expansion board that plugs into the GPIO header on the Raspberry Pi. Designed by Gert van Loo, designer of the Raspberry Pi alpha hardware, the Gertboard not only protects the GPIO pins from physical and electrical damage, but also provides a set of additional features. These include input/output buffers, a motor controller, an open collector driver, an MCP3002 ADC and MCP4802 DAC and an Atmel ATMega328P microcontroller which is compatible with the Arduino IDE and programming environment.

I was very impressed by the quick response from element14 after my purchase; my delivery came only two days after ordering and would have come even sooner if I hadn’t missed the 20.00 deadline on the day I had ordered it. The Gertboard was packaged with a number of female-to-female jumper wires, a set of jumpers, plastic feet for the board and a CD-ROM with a set of development tools for the ARM Cortex-M platform.


So far, I’ve only had occasion to test the buffered I/O, the ADC and DAC and the microcontroller; I still don’t have parts to test the motor controller or open collector driver. Aside from some documented peculiarities regarding the input buffers when at a floating voltage, including the so-called “proximity sensor” effect, things seem to have been going rather well.

The acquisition of the Gertboard gave me the impetus to really get down to trying to test my own expansions to the simple test circuits I had implemented before. One interesting application that I considered was to use a potentiometer to control a bank of LEDs in order to provide some sort of status indication.

The following Fritzing circuit diagram shows the layout of this circuit without the use of the Gertboard; the onboard LEDs and GPIO pins lined up in a row on the Gertboard makes it slightly less messy in terms of wiring.

Potentiometer Controlled LEDs_bb

In this diagram, GPIO pins 0, 1, 4, 17, 18, 21, 22 and 23 are used to control the LEDs, although you could also use pins 24 or 25 without conflict with either the SPI bus – which is necessary for the MCP3002 ADC – or the serial UART on pins 14 and 15. However, this is a lot of GPIO pins taken up for one application, which may warrant the use of a shift register or an I2C I/O expander such as the MCP23008 or MCP23017 in order to control more LEDs with less pins.

In order to control this circuit, I took the sample Gertboard test software and modified it slightly. As the potentiometer is turned to the right, the ADC value increases to a maximum of 1023; therefore, the distance between each LED’s activation point should be 1023 divided by 8 – very close to 128. The LEDs will light from left-to-right as the potentiometer’s resistance decreases, with one LED lighting at an ADC reading of 0, two LEDs at 128, all the way up to all eight LEDs at 1023.

// Gertboard Demo
// SPI (ADC/DAC) control code
// This code is part of the Gertboard test suite
// Copyright (C) Gert Jan van Loo & Myra VanInwegen 2012
// No rights reserved
// You may treat this program as if it was in the public domain

#include "gb_common.h"
#include "gb_spi.h"

void setup_gpio(void);

int leds[] = {1 << 23, 1 << 22, 1 << 21, 1 << 18, 1 << 17, 1 << 4, 1 << 1,
	      1 << 0};

int main(void)
    int r, v, s, i, chan, nleds;

    do {
	printf("Which channel do you want to test? Type 0 or 1.\n");
	chan = (int) getchar();
	(void) getchar();
    } while (chan != '0' && chan != '1');

    printf("When ready, press Enter.");
    (void) getchar();


    for (r = 0; r < 1000000; r++) {
	v = read_adc(chan);
	for (i = 0; i < 8; i++) {
	    GPIO_CLR0 = leds[i];
	nleds = v / (1023 / 8); /* number of LEDs to turn on */
	for (i = 0; i < nleds; i++) {
	    GPIO_SET0 = leds[i];

    return 0;

void setup_gpio()
    /* Setup alternate functions of SPI bus pins and SPI chip select A */
    INP_GPIO(8); SET_GPIO_ALT(8, 0);
    INP_GPIO(9); SET_GPIO_ALT(9, 0);
    INP_GPIO(10); SET_GPIO_ALT(10, 0);
    INP_GPIO(11); SET_GPIO_ALT(11, 0);
    /* Setup LED GPIO pins */
    INP_GPIO(23); OUT_GPIO(23);
    INP_GPIO(22); OUT_GPIO(22);
    INP_GPIO(21); OUT_GPIO(21);
    INP_GPIO(18); OUT_GPIO(18);
    INP_GPIO(17); OUT_GPIO(17);
    INP_GPIO(4); OUT_GPIO(4);
    INP_GPIO(1); OUT_GPIO(1);
    INP_GPIO(0); OUT_GPIO(0);

A Raspberry Pi Electronics Experiment – TMP36 Temperature Sensor Trials and Failures

I mentioned in my last post that I had received a Raspberry Pi electronics starter kit from SK Pang Electronics as a gift for Christmas, and between studying for exams, I have been experimenting with the components in the kit. Apart from ensuring that the components I received actually work, I still haven’t got much past the “flashing LEDs in sequence” experiments. I think I need a few more components to really experiment properly – transistors, capacitors, et cetera – but I have had a bit of fun with the components that I did receive.

Not everything has been entirely fun, though. One component, the TMP36 temperature sensor which I received with the kit, led to a struggle for me to find out how it worked. On the face of it, this should be – and if you test it without the full circuit that I first tried it with, is – one of the easier components to deduce the operation of. My temperature sensor is in a three-pin TO-92 package, with one pin accepting an input voltage between 2.7 and 5.5V, another connecting to ground and a third which has a linear output voltage with 500mV representing 0ºC and a difference in voltage of 10mV for every degree Celsius up or down from 0ºC. So far, so simple. The problem is that I made things rather difficult for myself.

The Raspberry Pi, unlike a dedicated electronics-kit microcontroller like the Arduino platform, doesn’t have any analogue input or output. In order to get analogue input or output on a Raspberry Pi, you need either an analogue-to-digital converter for input or a digital-to-analogue converter for output. This wasn’t a big deal; both the MCP3002 ADC and the MCP4802 DAC came with the SK Pang starter kit and I had just successfully tested the 10kΩ Trimpot that came with the kit with the ADC. My self-inflicted problems occurred when I thought (ultimately correctly) that the three-pin package of the temperature sensor looked like it would be an adequate drop-in replacement for the Trimpot. So, I plugged in the temperature sensor based on the schematics in front of me and tried running the program to read in and translate the readings from the ADC.

As I started the program, I noted that I was getting a reading. So far, so good, I thought. Then, I decided to press on the temperature sensor to try adjusting the reading. At this moment, I noticed that the sensor was alarmingly hot. Disconnecting the sensor as quickly as I could reason, I thought to myself, “Oh crud, I’ve just ruined the sensor before I could even try it properly!” Taking action based on the directions given for TMP36 sensor use on the internet, I allowed the sensor to cool before plugging it back in – the right way around, this time – and tried the ADC translation program again.

I was still getting a reading, but this time, I was more wary; I did not know whether this signified that the correct reading was being read or not. With the aid of an Adafruit tutorial written precisely to aid people using the TMP36 with the Raspberry Pi, I decided to modify the ADC translation program to give converted values in the form of temperature readings. Another problem seemed to ensue – the readings I was being given were far too low for the room I was in. I attempted to find a solution on the internet, by reading forum posts, tutorials and datasheets, but little of this made sense to me.

Eventually, though, at least one of the sources gave me the idea to use a multimeter on the temperature sensor to test whether the output voltage on the middle pin was reasonable. I plugged the TMP36 directly into the 3.3V supply on the Raspberry Pi and tested the voltage over the input and output. It was showing as approximately 3.3V, so there wasn’t a short voltage on the temperature sensor itself. I then tested the output voltage on the middle pin, and this showed a reading much closer to the 20-22ºC I was expecting from my room at the time. As far as I could tell, the temperature sensor wasn’t damaged from the brief overheating that it had experienced. However, at this point, I had other things to do and had to leave my experimentation.

Eventually, though, I got back to experimenting with the TMP36 again, and tried plugging it into the ADC again. It was still giving the same low readings, and I still didn’t understand completely if the sensor, the ADC or the program I was running was at fault. I was at a loss to understand what was going on, so I shelved the temperature sensor experiments and tried understanding the code for the other components so that I could try my own experiments.

Some more looking on the internet pointed me more towards the answer I was looking for, though. The datasheet for the TMP36 suggests the use of a 0.1μF bypass capacitor on the input to smooth out the input voltage, but this didn’t really sound like the issue I was having – more it seemed like there was a low voltage going into the ADC. A forum post gave me an idea – try using a multimeter to test the voltage going across the TMP36 when it was plugged in with the ADC, and the output voltage from the sensor with the full circuit going. So, I did, and again, the temperature sensor had 3.3V going across it and about 740mV output voltage from the middle pin. I was perplexed, and tried testing the voltages across the ADC itself.

It was at this moment that one little sentence from the forum post gave me the answer – the problems with using the MCP3002 for reading in the voltage from the temperature sensor were linked to input impedance over the ADC rather than any problems with the temperature sensor. The ADC was working correctly in terms of reading in the value, and the temperature sensor was also working correctly, but because there was an impedance on the ADC – the voltage going across the ADC is 3.3V, but the voltage between the input pin and the channel read pin is, at least on my MCP3002, 2.58V – there were incorrect readings. A bit of modification to the ADC translation program, and I had the sort of readings that I expected both on the output voltage of the temperature sensor and the screen where the results were being printed.

Rather a long-winded set of tests for a simple problem, eh? I suppose much of the problem lies in my putting the cart before the horse and trying experiments with my only knowledge of electronics being my long-faded memories of secondary school physics. In any case, the problem was found, and a problem in my own lack of experience was also found, which I can start rectifying soon enough.

My first fortnight with the Raspberry Pi

The 12th of June was a good day for me. For one thing, I received the second semester results for my course to find that I’d received A grades in all three subjects and come close to perfect in C programming. For another, my Toolkit, the diverse set of computers which I own, gained another member in a new Raspberry Pi, bringing my computer collection up to eight.

The Raspberry Pi, for those who don’t already know, is an ARM-based single-board computer with a 700MHz ARM11 processor, 256MB of RAM, a powerful GPU and a very low price tag, on the order of £25 for the Model B version which includes a 10/100 Ethernet port and two USB slots in comparison to the single USB slot on the yet-unreleased Model A. Demand has been staggering, and after several months of waiting, I finally had my hands on a Raspberry Pi of my own.

Unfortunately, my worry that I had either bought an SD card which didn’t work or that my Raspberry Pi might be faulty prevented the first boot from being as exciting as it should have been, but once I had realised my own mistakes and resolved them, I had another working Linux system in front of me, ready to test. A few hours were spent loading some of my preferred software which wasn’t loaded onto the Debian image by default, including Emacs, but the Debian Squeeze image gave a remarkably complete starting system with enough programming tools to get going almost immediately.

Having failed to locate my HDMI to DVI lead which would give me a bit more flexibility when it comes to monitor choice – I don’t own any monitors with HDMI support – I resorted to the composite connection, which I’ve set up to provide 640×480 support – enough to show 80 columns in text mode and to show a couple of windows using X. It’s not exceptional, and compared to the full 1080p performance that the HDMI slot can deliver, it’s really quite awkward, but the provision of the composite socket was a good idea by the Raspberry Pi Foundation, giving the Raspberry Pi the ability to run on a fairly wide arrangement of monitors and TV screens.

My collection of computers means that I’m not exactly short of Linux PCs, so after doing a brief test of the GCC compiler and Python interpreter, I decided to begin looking for resources to learn something which the Raspberry Pi is well-suited for – ARM assembly language. Perplexingly, while resources on learning ARM assembly language are reasonably available on the internet, most of the resources on learning Linux assembly language seem to be related to the x86 architecture – an architecture with much uglier assembly language, with far less user-available registers and a CISC model which means that there are operations to learn with more variance between them than on the ARM’s RISC model.

I have managed to find sufficient materials to make a start, though, so I’ve managed to make some headway into learning how the ARM processor works, which will hopefully give me a bit more insight into how the processor works and how code can be effectively optimised. As the Debian Squeeze image for the Raspberry Pi comes with GCC as default, as any good, full Linux distribution should, the appropriate assembler was already present, and there are, of course, a lot of technical details about the ARM architecture’s instruction set available from ARM themselves. All I can really do of my own accord so far is to do simple arithmetic or bitwise logical operations, but everybody has to start somewhere.

I haven’t really tested the performance of the Raspberry Pi to its full yet, but I do have a somewhat similar embedded system with broadly similar specifications in my hacked Wii console, which also runs Debian Linux with the same LXDE desktop environment as on my Raspberry Pi. The Raspberry Pi seems to run more smoothly than the Wii running Linux, possibly a consequence of the greater RAM. There are a few slowdowns when loading Emacs on X, but Emacs doesn’t even load instantaneously on my dual-core desktop, so the slight pause is something I’m willing to tolerate. Anyway, the greatest strength of the Raspberry Pi is meant to be in its GPU, and I haven’t tested that yet, so my call on the Raspberry Pi’s performance will be more complete when I have a more full picture. So far, though, I can’t complain – it should serve the educational audience well enough to fit the programming tasks which the Raspberry Pi Foundation seem to have at the front of their minds.

The Raspberry Pi: A project to shake up the stagnation of educational computing

As previous articles may have suggested, I’m a Linux aficionado, and have been for several years. I’ve been trying my hand at Linux systems for something like ten or eleven years, running through successive versions of SUSE Linux and openSUSE, later adopting Debian and Ubuntu on some of my other computers. Ultimately, my time with Linux has helped hone my computer skills, often requiring more of a technical mind when things go wrong than the equivalent Windows system, but feeling all the more satisfying when everything goes smoothly.

The readily-available command-line-based programming tools from the GNU Project have helped me learn more about the structure of the languages I’m learning than the graphical IDEs that I used on Windows. As Linux has evolved, the old methods of doing things often remain for a transitional period, allowing for a smooth transition as one sees fit without closing oneself off from newer applications. While it’s not yet a perfect alternative to Windows for the vast majority of users, Linux is often a better platform for learning how to use a computer technically than a comparable Windows or Mac OS X installation, for the freedom it allows, the easy extensibility and the ethos of the hobbyists it has grown up around.

For years, I have lamented the wilful ignorance that many people have towards computer technology when it isn’t handed to them with a flashy graphical user interface which aims towards the lowest common denominator. While I can understand that most users don’t want to be hacking C on a command line, and that there are places for people who do want to be doing this to learn, it is frustrating to see otherwise intelligent and capable people become brain-dead consumers as soon as they face a computer screen. I have no hesitation in asserting that most of their problems are a case of a total lack of interest rather than some inherent condition of computers to create fools out of intelligent people. Even in a world increasingly dominated by information technology, it seems to be fashionable to close one’s self off from computers as if they were some sort of magical artefact, and as if those that can use them well are practitioners of some sort of black art.

Educational systems at primary and secondary level have had trouble keeping up as well. Faced with a field of rapid evolution and even more rapid obsolescence, the education systems in the UK and Ireland, among others, have taken the same sort of “lowest common denominator” approach as many software providers. Education in computing most often takes the form of learning how to use office software, without any real provision for the teaching of programming techniques, nor of basic computer science techniques such as sorting, binary mathematics or such other useful principles. This isn’t just a theoretical matter either; many IT and other computing companies in the UK have reported a lack of educated staff in the fields of computer science, information technology and allied fields. Even Google’s chairman, Eric Schmidt, has lamented the lack of computer science education among the youth of the United Kingdom, a field which the British helped define in the 1950s and 1960s.

I am clearly not the only person displeased at the state of computer education at primary and secondary level. During the 1980s, during the golden era of home computers, before the near-monopoly of the x86 architecture and of Microsoft operating systems, computers booted up into BASIC interpreters, which although not capable of very much, defined programming as an inherent and integrated part of the computing process. Harking back to these ideas, a group of interested parties has formed a registered charity in Britain known as the Raspberry Pi Foundation, aimed at developing and producing a low-cost, tightly-integrated computer (the eponymous Raspberry Pi) on a motherboard small enough to be carried around easily and replaced inexpensively. The leader of the Raspberry Pi project, Eben Upton, works with Broadcom, which use British-designed ARM processors in their embedded designs, while David Braben, co-developer of the seminal game, Elite, for the BBC Micro, is another member of the foundation.

Together, the group has designed a computer containing a 700MHz ARM11 processor with an integrated GPU and ports for HDMI, composite RCA video and a 3.5mm jack. Two models will be available: the Model A contains a single USB port and 128MB of RAM, while the Model B adds another USB port, an additional 128MB of RAM for a total of 256MB, as well as a 10/100Mb Ethernet port for internet connections. A series of GPIO, I2C and other connectors is available as a separate header for both models, while an SD card slot provides the storage capacity for the operating system. The total cost of the computer, which has entered production and will soon be available for shipping, is projected to be £18 ($25) for the Model A and £22 ($35) for the Model B.

The cost is one of the greatest draws of the Raspberry Pi project, low enough to be easily replaceable if the unit is damaged beyond repair or to be used in robotics, integrated computing and other hobbyist projects. For that price, you get a surprisingly proficient piece of hardware, capable of running the likes of Quake III at 1080p, and capable of being a useful media player as well as an educational platform for programming, content creation, et cetera. The ARM processor architecture just happens to be one of the best for teaching assembly language, a skill which has recently largely been restricted to computer science and engineering courses. The GPIO and other headers allow the Pi to be used for robotics and automation projects at low cost, while the provision of the composite RCA connection allows old televisions to be used as screens in the absence of a high-quality monitor.

Such a device therefore addresses several concerns at once, while not really compromising on anything which is important for an effective syllabus of computer education. The hardware will soon be available; with Michael Gove recently announcing the scrapping of the much-maligned ICT syllabus to be replaced with a course with a greater focus in computer science, it remains to be seen if there can be a shift in mindset about technology away from treating it as a black box, and more as a platform for creativity and development, but I remain cautiously hopeful.

The Raspberry Pi’s homepage is available at The first batch of Raspberry Pi units, all Model B units designed for hobbyists and software developers, should soon be available for purchase. I, for one, am wishing for success in this endeavour.