May 10th LUG & Makerspace Meeting

We had a somewhat quieter more chilled LUG after last week, present Mike (off course), Les, Tony, Arran, Elizabeth, her friend Susan, Keiron and me (Olly).

Tony took Elizabeth through a step by step tutorial for downloading and installing Linux Mint on a laptop she had rescued, they experienced a few difficulties with the machine as it had come to Elizabeth in quite a poor condition.  Tony showed her how to download the “iso” image from Linux Mint’s website and how to “burn” or extract the image onto a USB stick so they could boot and install from it.  They had to do this twice as there was some confusion as to whether the laptop was 64 or 32 Bit architecture.

Mike showed Susan around the Makerspace and explain how his PC recycling business works and explained the Linux operating system and demonstrated various bits of hardware inside a laptop and desktop computer.

Arran and I had ago hacking various Cisco network appliances which Mike had accumulated to understand what routing and switching features each appliance was capable of.  Both Arran and I have an interest in network infrastructure but duo to the cost of Cisco appliances don’t often get access to them to interrogate them in this way.  One of the switches we found had a serial connection as opposed to the console or USB connections most Cisco Appliances come with as standard to administer them through.  So we spent the early part of the LUG working out how we could connect our laptops to it using some of the port converters Mike had in his collection.

Les and Keiron spent the majority of the session building a Pimoroni Robot kit and programming it using Python GPIO libraries.  Kerion also helped Elizabeth and Tony with the trouble shooting the doner laptop towards the end of the session.

Olly, Les, Tony and Mike reflected on the day and how they could further expand meetings and engage more people at the Makerspace.

May 3rd LUG & Makerspace Meeting

So we had a bit of a discussion on the Mailing List following on from our debate on the way we should take the LUG/Makerspace forward, about what we should do at the May 3rd Meet at Ripon Road.  Since we had been talking about Ubuntu 14.04 LTS pretty much since it’s release, that Les came up with the idea of testing it on several different types/ages of hardware. Using the Recommended Minimum Specification as a starting point and then selecting various bits of hardware from Mike’s stores to trial. 

Olly, Les and Tony also decided to record an episode of the Full Circle Podcast which Blackpool LUG had assumed the stewardship of 2 years ago, in the Makerspace Office.  Those present for this rather busy meet were Mike (off course), his son Joe, Les, Tony and me (Olly).

So when we arrived at Ripon Road, Les was presented with an “emachines” Intel Celeron 700, a 10 base T NIC PCI Card, IDE DVD ROM, 512Mb RAM and a screw driver!! 😉 So he got to work installing the additional hardware needed to make the minimum spec as quoted by Canonical 

The sight that greeted Les

I got off some what lightly as the Intel Pentium 4 1.6 Ghz Compaq desktop PC which was former Blackpool Borough Council stock had already been installed with Ubuntu 14.04 by Mike earlier that week who had wanted to test if he could recycle this and other machines he’d received as a batch donation with 14.04 installed on them. So all I had to do was sit down boot up the machine and drink some coffee!! I had plenty of time to drink coffee, it took over ten minutes to get to the login prompt, another 5 before the dash appeared!! It didn’t end there either, typing in the search bar of the dash was so slow you could actually watch the characters appear in the input box one by one!! It took 2 minutes for Firefox to load and also another three and a half minutes for Software Centre to load.

Meanwhile after Les had performed the necessary hardware upgrade to the Celeron machine he then booted the DVD of 14.04 which Mike had burnt for him, to save time Les selected and OEM install from the boot options this gives a default configuration rather than walking through the installer. 20 minutes later and Les was still waiting for the installer to start!!

James then joined us and we had a discussion about Ruby, in which James recommended Programming Ruby 1.9 & 2.0 A Pragmatic Programmers’ Guide as great no experience required to get you into programming with Ruby. Les observed the similarities in syntax and variable with Python.

Meanwhile sometime later (nearly an hour infact) back at the Celeron Ubuntu installation, the installation had made no discernible progress what so ever so an executive decision was taken to kill the machine and have another go, this time using the more lightweight Lbuntu. Once again Les elected to undertake an OEM install he managed to get the installer to start and managed to get through to the “Tell Us Were You Are” screen before the installer stopped responding.

At this point we were running out of time and it has to be said patience to continue to mess about with the e-machine and called the experiment off. It would appear that certainly from our point of view, Canonical may wish to consider reviewing it’s minimum hardware requirements as it was obvious to us that the machine just wasn’t good enough to run 14.04.

For our third and final testbed Tony was using an ThinkPad X220 Intel Core 2 Duo with 4Gb RAM, it did the full install in around 20 minutes again utilising the Local Area Network to download packages over, however we do have one little gripe with the installation, despite checking the install updates and codecs options Ubuntu still failed to do this during installation, it still required updating post install and the restricted extras repositories adding to get the codecs ;-(. Other than that we had no further issues with the install, Ubuntu ran very well on this machines without any noticeable reduction in performance.

Les, Olly and Tony then went into the office to record another episode of the Full Circle Podcast which Blackpool LUG has been curating for over two years now. The boys had been suffering with problems trying to get various VOIP solutions working over the past couple of weeks and had decided to give it a go recording together in a fixed geographical location. The new setup worked well for them, recording in just over an hour which is quick for them. Alot of things were made much easier by being the same room together, such as queuing in and out the various presenters during the recording, adjusting the sound levels while recording. All of which makes the post editing experience much pleasanter than for previous shows, and hopefully less of a challenge. You can listen to the recording here

Moving Forward – Plans For The Future

Although we weren’t scheduled to meet at Ripon Road for a couple of weeks due to various commitments we had an impromptu meeting at Ripon Road as Mike was able to open this week so we had an impromptu meeting this week, present were Arran, Les, Mike (off course) and me (Olly).
First we discussed the release of Ubuntu 14.04 LTS Trusty Tahr, one of the reasons Mike opened up was to download Lubuntu 14.04 to try it out. Les and I both agreed that we needed to have a look at it, I’m planning on running it as a VM to try it out later this week.

We also had quite alot of networking talk this week, both Arran and I have an interest in networking, I have to retake my Cisco Certified Network Associate exam this year, certification lasts for 3 years only.  So were were discussing the new CCNA syllabus and software provided for training, Mike’s son Joe who also attends the LUG quite alot is also taking his exam aswell.

The main topic of debate for the meeting however was further discussion on the issues raised at the last meeting which are detailed in Mike’s post last week, How and Why (a reason to exist). It was decided that the Makerspace should continue and that we needed to generate interest in it by undertaking maker projects and writing them up with pictures/videos etc to “show off” some of the cool things that happen and can be done at a Makerspace.

We then moved on to talk about ideas that we’d had for maker projects I raised the Mame Cabinet project that Les, Tony and I had talked about during one of our meets at our alternative venue Layton Raikes.  Les who was also working on a robot based around Pimoroni’s Pibrella and roboteering accessories suggested constructing robots and holding a Robot Wars style event at the Makerspace.  Arran also shared his plans to build a cycle computer, which recorded your speed, heart rate and location using arduino and various sensors.  The group agreed that they might not be able to implement all of the features in the first iteration of the device but it was decided that this would be good first project to undertake, not too ambitious and not requiring too many components.  Mike iterated that with all these projects the key is to record them well for posterity (photos and videos of the builds and end results, etc).  Les suggested using picture based social media to show progress on projects, Mike mentioned how one person who creates a social media account becomes responsible for posting to it which is why the LUG’s presence on various social media waxes and wanes!!  Mike thought it better to use the Blog as the focal point for all of the LUG/Makerspace updates.  We then discussed how the builds should take place: whether the initiator of the project should do the majority of the work, not necessarily at the Makerspace and then present the solution to the group and ask for help/additional input when needed; or we undertake the project as a group solely at the Makespace and record the progress made on that particular project at the end of each session, with any additional research and acquiring components done outside of the meetings to speed up builds.

Do you have any thoughts on the outcomes no the last meeting, do you attend or help to run a Makerspace and have had similar discussions and want to share your wisdom, are you considering attending either the LUG or Makerspace and you would like to see us organise both this way, then get intouch with us on Twitter or on our Google + page or join our Google + Community to start a discussion.

Book Review: Podcasting Hacks – Tips and Tools for Blogging Out Loud By Jack D. Herrington

In July the LUG took over presenting the Main Podcast for the Full Circle Magazine, the four hosts: Les, Jon, Olly & Tony all had their own ideas about how a podcast should sound but had little idea of what was involved in producing a good quality podcast.

So it was decided that a bit of background research was required, this book by O’Reilly came up quite a few times as recommended reading for people intending to start out podcasting.  It did not disappoint, it starts from the very beginning by outlining what exactly is a podcast, the different audio formats how podcasts are published to the web and what’s the best way to listen to and get them.

Once you’ve made your way through the first few chapters you begin to delve more deeply into what makes a good podcast and how to produce one.  The author gets you thinking about the content of your intended podcast and talks about what is good and what is not.  You then move on through simple vocal techniques to the equipment that is a must and some nice to haves and discusses is some detail about what is available and the author makes some recommendations based on their experiences. The book then moves on into more advanced vocal coaching, setting up a home studio, improving audio quality and publicising your podcast including Blogging. The book closes discussing what was then the new medium of video blogging as Youtube had begun to dominate the broadcasting-yourself scene.

Some indication of costs are given for the various pieces of equipment but a note of caution here this book was written in 2005 and alot of it is now freely available through Ebay and alike, but it does give you an idea of what things to look for and which manufacturers to look out for.  It is also worth mentioning at this point that although Jack Herrington is the main author he has drawn on his contacts to help him write the book from every angle.  Quite a few chapters have been written by guest authors who have a specialism in a particular area for instance there are a couple of chapters written by a well known American voice coach who has worked with alot of voice and radio artists.  This helps to make this a very well rounded book on the subject.

Tips and Tools for Blogging Out Loud

To summarise this is an excellent book which will help guide you into the world of podcasting and I would say this is essential reading for anyone contemplating starting a podcast.  Although the book was written 7 years ago and the equipment featured is fairly dated, the book still gives you all the knowledge you need to choose the right one for what you need and to purchase with confidence.

Free ARM Emulators / Software ARM Device Emulators

Free ARM Emulators

ARM microprocessors are used in embedded devices as well as portable devices like PDAs and some phones. The software ARM emulators listed on this page allow you to run an emulated ARM device on your main computer system, be it WindowsLinux or some other operating system. This allows you to develop and test software using your desktop, and only move the software to a real device when it is more complete.

Related Pages


The information provided on this page comes without any warranty whatsoever. Use it at your own risk. Just because a program, book, document or service is listed here or has a good review does not mean that I endorse or approve of the program or of any of its contents. All the other standard disclaimers also apply.

Free ARM Emulators / Software ARM Device Emulators


SkyEye simulates embedded computer systems that run on the ARM microprocessors and the Blackfin DSP Processor, specifically, the ARM7TDMI, ARM720T, StrongARM, XScale, and the Blackfin CPU cores. Application CPUs simulated include the Atmel AT91X40/AT91RM9200, Cirrus Logic EP7312/EP9312 CS89712, Intel SA1100/SA1110 and PXA 25x/27x, Samsung 4510B/44B0/2410/2440, the Sharp LH7xxxx, NS9750, and the Philips LPC22xx, BF533. The emulator is also able to simulate chips like the timer, UART, NIC, LCD, touchscreen, and so on. Operating systems to run in SkyEye include uC/OS-II 2.x (ucos-ii), uClinux, ARM Linux, Nucleus, Rtems, Ecos, IwiP on uC/OSII, etc. The emulator works on Linux, Windows (with the help of Cygwin) andFreeBSD. The program is licensed under the GNU General Public License, that is, it is open source and is distributed in source form.


ARMware provies an emulation environment for the ARM platform. At the time this review was written, it is able to emulate StrongARM SA-110, although Intel Xscale support is currently being developed as well. The emulated environment is similar to that of the HP iPaq H3600. The emulator works on Linux and Windows. The project is licensed under the GNU General Public License.

Microsoft Device Emulator 3.0 (Standalone Release)

The Microsoft Device Emulator standalone release emulates ARM-based devices, primarily so that you can develop and test your programs for portable devices in your Windows system. Also available are Windows Mobile 6.1 emulator images (both Windows Mobile 6.1 Professional and Windows Mobile 6.1 Standard) and Windows Mobile 6 localized emulator images (again both Professional and Standard). If you want older Windows Mobile versions, you may want to check out the earlier version Microsoft Device Emulator 1.0, which comes with Windows Mobile 5. The emulators are primarily designed for development with Microsoft Visual Studio (see the Free C/C++ Compilers and Interpreters page), so I’m not sure if it’s usable with any other compiler.

Softgun – the Software ARM

This software ARM runs Linux blob and u-boot for NS9750 Freescale i.MX21 and Atmel AT91RM9200. It emulates an ARM-9 with MMU (Memory Management Unit) and a variety of Netsilicon NS9750 peripherals, Flash, PCI, CAN-Bus and network (information obtained from the Sourceforge summary). The detailed list can be found on the site itself. The emulator runs on Linux and probably other POSIX systems as well.

QEMU on Windows

QEMU on Windows is an emulator for x86, ARM, SPARC and PowerPC (see elsewhere on this page for more information). This site contains a Windows port with downloadable binaries.

QEMU CPU Emulator

QEMU supports the emulation of x86 processors, ARM, SPARC and PowerPC. Host CPUs (processors that can run the QEMU emulator) include x86, PowerPC, Alpha, Sparc32, ARM, S390, Sparc64, ia64, and m68k (some of these are still in development). When emulating a PC (x86), supported guest operating systems include MSDOS, FreeDOS, Windows 3.11, Windows 98SE, Windows 2000, Linux, SkyOS, ReactOS, NetBSD, Minix, etc. When emulating a PowerPC, currently tested guest OSes include Debian Linux.

ARM development on a virtual platform

This is an article related to what is commonly called the Virtual Platform or Virtual Prototype. There are probably many definitions of what this means. here it means the Virtual Platform as a software model of a hardware system, created for the purpose of running embedded software and verifying the hardware/software interaction.

Here are some general characteristics to help clarify what the Virtual Platform is:

  • Runs unmodified target code
  • Uses instruction accurate models of processors 
  • Provides a full programmers view
  • Runs very fast (may be faster than the hardware it emulates)
  • Has excellent visibility and control (compared to physical hardware)
  • Is easy to distribute to many users

Virtual Platforms have been available since somebody had the idea to make a software model of the hardware.

I expect that many software engineers already understand the details about how to select operating systems, write device drivers, create and populate file systems, cross compile software, program flash memory, etc., but sometimes software engineers are not familiar with virtual systems since somebody else sets up all the infrastructure and they just “add code” in the right place.

I’m sure that virtual platforms are (or will become) critical to verification engineers and people who have worked primarily with RTL simulation in the past and are making the transition to the next level of abstraction.
Virtual Platforms can play a key role in system verification and delivery of high quality software sooner in the process.

The hardware system to be virtualized is the ARM Integrator CP board. It is an older board that was supplied by ARM and according to the ARM website is no longer promoted because newer hardware platforms have been developed.

Not being a state of the art board that means there is a lot of public information available as well as software.

One of the benefits of the Virtual Platform becomes apparent immediately. First, a software company probably wouldn’t understand the need to buy a board to develop embedded software.
Next, if a physical board was needed I doubt any readers would buy the board to learn about how embedded software development and verification works.

Since we have Virtual Platform technology nobody needs to buy any hardware and everybody can contribute. All that is needed is a computer, and the Qemu emulator.

Instead of actually reading the User Guide, we can start with a quick overview of the Integrator board and its memory map:
Peripherals                                        Base Address
Primary Interrupt Controller                    0x14000000
Secondary Interrupt Controller                0xca000000
Counter / Timer                                     0x13000000
Real time Clock                                    0x15000000
UART 0                                                0x16000000
UART 1                                                0x17000000
Control Registers                                  0xcb000000
Keyboard Controller                               0x18000000
Mouse Controller                                   0x19000000
Multimedia Card                                    0x1c000000
Ethernet Controller                                0xc8000000
LCD Controller                                      0xc0000000

There are many uses for the Virtual Platform. A common one we can start with is to boot the operating system and run applications. Another one is to write device drivers and debug them.

Linux will be used as the operating system to load on the virtual device. Again, there is a wealth of information available and Linux is becoming popular as an embedded operating system.

To start, download QEMU which will emulate the Integrator board and boot Linux.

Get QEMU here. QEMU is an open source processor emulator which is available to run on both Linux and MS Windows.

If you have a Linux machine it may be installed already or can be installed using your package manager.

Once you have qemu installed it’s time to get a Linux kernel and file system and boot it.

There are Fedora and Debian howto links on the home page with step by step guides.

An easy starting point is to download the ARM Linux 2.6 kernel and ram disk file system image from the qemu website. Extract this file and go to the arm-test directory.
As the README shows you can boot doing:
% qemu-system-arm -kernel zImage.integrator -initrd arm_root.img

If all goes well you will see a new window:


You can login as root with no password and you have a Linux system running on the ARM Integrator CP Board with the ARM926EJ-S processor.

You can use
Ctrl-Alt-2 to get to the qemu command prompt, type help to see the commands or type quit to exit.
Ctrl-Alt-1 will get back to the console (this is actually the LCD controller).
Ctrl-Alt-3 will get to UART 0 and allows another login window.
Ctrl-Alt is the key to release the keyboard and mouse.

Now try some networking:
% wget
This will download index.html This is a ramdisk so next time you boot the file will be gone.
To browse the web use the lynx browser:
% lynx

Other than being pretty cool, this exercise raises many questions:

  • How is the Integrator Board modeled?
  • How does qemu know I want to run the Integrator board?  There was no configuration or arguments.
  • What’s in the file zImage.integrator?
  • What’s in the file arm_root.img
  • How is the Ethernet controller on the Integrator board able to access the Internet?
  • Can I debug code running on the Integrator board?
  • This is a minimalist system, how can I compile and add more programs to it?

Original article:

Fedora ARM in qemu

First attempts with Fedora Arm running in qemu on Linux Mint 8.

The picture below (click to enlarge) shows a small c file in the Vi editor, with one line of inline ARM assembler (a NOP instruction) and a puts statement which puts hello on the screen so that you can see something has happened.

Instructions on how to get Fedora ARM running in Qemu are here:-

The file above is saved as test.c, and compiled with:-  gcc test.c
the resulting file is called a.out, run it with ./a.out to see ‘hello’ appear on the screen.
There are numerous options which can be applied at compile time.
If you do not want the output file to be called a.out, use gcc -o myoutputfile test.c
the -g option will produce debugging information for the gdb debugger to use.
See the gcc manual for all options.
as you can see below, a.out does not run,
./a.out is required.

using a terminal on the desktop and trying to compile test.c outside of the emulator. This causes an error indicating that ARM assembler instructions are not acceptable to the X86 compiler.
This is expected behaviour. A cross compiler would be needed to compile for ARM on a PC.

GNU ARM toolchain guide from IBM


The toolchain provides the ever-popular GDB for debugging low-level programs. When the program is targeted for a single-board computer with a JTAG or ICE unit attached, you can use the Sourcery G++ Lite debugger (gdb) to debug the ARM code remotely.
If you wish to test the code as I did—on the Android Linux system running on a mobile phone—you need to attach the phone to the workstation using the USB cable that came with it, then use the Android software development kit’s (SDK’s) adb push command to transfer the program to the phone. Once on the phone, in a directory that can contain executable code (/data/local/bin), make the program executable by issuing the chmod 555 hw command. (The chmod command on Android doesn’t use +x, so 555 is necessary, instead.)
Finally, use the adb shell command to connect to the phone, use cd to change to the correct directory, and run it with ./hw. If all goes according to plan, the program should respond as it did on my phone, by greeting you with “Hello Android!”

Read more here:-

GNU ARM toolchain guide from IBM