Using a Parrot DF3120 Picture Frame as a Status Display

The Parrot DF3120 is a rather old 3.5″ LCD picture frame with a 320×240 64K colour display, nothing to shout about but there are a few things that make it a bit more interesting. For starters it has built in bluetooth, USB, an SD card reader, a tilt sensor, a light sensor and three buttons on the back. The CPU is an ARM9 based Samsung s3c2412 running at 266 mhz and there is 8MB RAM and 32MB Flash, best of all it has long ago been hacked to run Linux.

Unfortunately they don’t seem to be sold new any more and eBay seems the only place they sometimes come up, they are cheap though, I picked a brand new one up for £10 + postage.

Here is how I have set one up to connect to a Linux box via USB for use as a status display. The picture to the right shows it running htop on a Raspberry Pi but there is nothing Pi specific here.

Continue reading Using a Parrot DF3120 Picture Frame as a Status Display

Raspberry Pi and I2C devices of different voltage

After my recent posts on using the MCP23017 I/O expander with the Raspberry Pi several people have queried the connection of an I2C device running at 5v to the Raspberry Pi’s 3v3 I/O. The reason why this is safe in this case is that on an I2C bus the clock and data lines are open-drain lines that are pulled high and devices on the I2C bus pull them low to communicate, in this case the Pi is pulling the lines to 3v3 and it and the MCP23017 pull them low, this means the Pi is never exposed to the 5v supplying the MCP23017. As long as the slave device is happy to register the 3v3 as a high then everything will work fine.

In my testing the Pi has worked flawlessly with the MCP23017 like this although as Selsinork pointed out in the comments on this post it is strictly speaking out of spec, a high shouldn’t really be any lower than 4v for the MCP23017 so in theory using 3v3 could cause reliability problems, it’s perfectly safe as far as the possibility of causing damage to the Pi is concerned though. That said, it does work in practice although YMMV and I suspect if you tried adding more MCP23017s or distanced it from the Pi that reliability would drop off rapidly.

One way I had thought of to fix this had it been a problem was to use a bi-directional buffer IC such as the P82B96 at a cost of a few pounds but Selsinork tipped me off to a very cheap way to do this with just a couple of n-channel FETs, I looked it up and found this document which contains a diagram (page 43) showing how easily it can be done:

This would certainly be an easy and cheap fix if reliability became a problem.

Continue reading Raspberry Pi and I2C devices of different voltage

Raspberry Pi I/O Expander Board

To simplify using the the MCP23017 I/O Expander on the Raspberry Pi I’ve made a little plug in board using a  Slice of Pi from Ciseco. The Slice of Pi is a handy little PCB that plugs directly onto the Raspberry Pi’s GPIO pins and gives a convenient row of labelled standard 0.1 inch (2.54mm) headers for the built in GPIO, SPI and I2C pins, a small prototyping area and optionally headers for plugging in an XBee style wireless devices such as the XRF, XBee, RN-XV etc. It’s not expensive at £3.90 plus postage either. (Update 27/7/12 – Ciseco are now doing an MCP23017 specific board called the Slice of PI/O, here is a comparison of the two)

I’ve fitted a 28 pin DIL socket to it for the MCP23017 and connected power and the SCL and SDA pins from the Pi as well as the required lines to switch it on and set the I2C address (fixed to 0×20). I’ve also added two sets of 0.1″ headers for the 16 I/O pins.

The result is a simple plug in expander board that can provide up to 16 inputs or outputs that can sink or source up to 25mA each, more than the 16mA of the Pi’s own GPIO pins and safer, the MCP23017 costs less than £1 and if you do accidentally blow it up and can just be popped out and a new one popped in. Along with the Python tools I’m working on I’m hoping this will be useful to help provide a simple, low cost and relatively safe way for people to experiment with connecting other hardware to the Raspberry Pi.

Continue reading Raspberry Pi I/O Expander Board

Edimax EW-7811Un Wi-Fi Adapter on the Raspberry Pi

This dinky little USB Wi-Fi adapter seems like a good match for the Raspberry Pi, it seems silly to have a huge dongle sticking out of something so small and this little thing really is tiny, it’s only £10 including delivery on eBay too and will work on the Pi without a powered hub.

I checked the list on the excellent eLinux wiki to see if it was known to work on the Pi and there was even a link to a handy guide to setting it up, it’s all pretty straightforward except that the standard rtl8192cu kernel driver doesn’t work, the guide included a download for one that did but it was only a binary for the 3.1.9 kernel that the Raspberry Pi Debian image uses out of the box and as I’m using this 3.2.18+ kernel with I2C support it was no good to me and there was no link to the source so I could build my own.

I tried the one on the Edimax website which was the same as the version on the CD included with the dongle but it was too old and wouldn’t compile against a 3.2 kernel. After a bit of searching I found a newer one for a different adapter using the same chipset and that worked with only a couple of tiny modifications.

I’ve uploaded the source here in case anyone else finds themselves in the same situation, it cross compiles fine with: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KSRC=/path/to/kernel/source KVER=kernel version  and you can then follow the above guide for the rest.

Here is the compiled version for a 3.2.18 kernel and also a compiled version of the complete 3.2.18 kernel and modules for the Raspberry Pi (with I2C driver).

Python tools for the MCP23017 I/O Expander

I’ve been playing around with the MCP23017 I2C I/O Expander on my Raspberry Pi a bit more this week and as I mentioned in an update to the last post I’m now running this 3.2 kernel that has hardware I2C drivers for the Pi. The next step was finding a better way to control the expander than using i2c-tools.

Python isn’t something I’ve really used much before but there is a nice python-smbus module that makes interfacing with I2C devices relatively straightforward so that’s what I’ve used to knock up a couple of simple tools to control the MCP23017.

The first one is a command line tool that allows you to set any of the 16 IO pins as high or low, usage is: -b <bank> -o <output> -s <high|low>

eg. to set GPA1 high it would be: -b a -o 1 -s high

This gives a response of: Output GPA1 changed to high

The code is on GitHub here, other than a working I2C setup all you will need are the Python bindings for SMBus which are in the python-smbus package on Debian.

The second tool is a simple web interface built using WSGI, something I’ve never used before – it’s basically CGI for Python.

The web tool can be controlled through its own built in web form (very simple but good enough for demo purposes and can be built on) or via GET requests with optional JSON style responses which will allow it to be easily integrated into other projects.

eg. to set output GPA1 high: http://rpi/mcp23017.wsgi?bank=a&output=1&state=high&mode=json

This gives a JSON like response of: {“GPA1″:”HIGH”}

I want to extend this now to cater for input as well as output and to report on the current state of the outputs.

The code for this is also on GitHub and as well as the python-smbus module you will need apache with mod-wsgi, if you get permission errors make sure that the apache user (www-data on Debian) has permissions to read/write to the i2c bus dev entry, eg. /dev/i2c-0

UPDATE 2/6/12: I’ve created a plug in expander board using the Ciseco “Slice of Pi” and the MCP23017, see this post for details and a step by step guide to getting it working with the above Python tools including a link to a Raspberry Pi kernel/modules with I2C compiled in.

Raspberry Pi and the MCP23017 I2C I/O Expander

I had a quick play with the I2C drivers that are currently being developed for the Raspberry Pi this afternoon and managed to get a MCP23017 16-bit I/O Expander working with it without any fuss.

Here is a highly exciting video of it blinking an LED:

The MCP23017 is a handy 28 pin chip that gives you 16 pins that can be used as either inputs or outputs (max 25mA from each pin) and up to 8 of the MCP23017 can be used on one I2C bus so it can give you a whole lot more I/O than the Pi has built in as well as reducing the risk of frying the Pi and also has the added advantage that the expander can be located away from the Pi linked with only four wires. There is also the smaller MCP23008 which is an 8 I/O version that can be used in the same way. They are both available in DIP form making it easy for building your own boards with and experimenting on breadboard. Here is the datasheet for the MCP23017.

Read on for some info on what is required to get this working.

Continue reading Raspberry Pi and the MCP23017 I2C I/O Expander

Raspberry Pi Finally Arrives

After a long wait the Raspberry Pi I ordered from Farnell on 29th February finally arrived yesterday.

I expect that most people reading this blog knows all about the Raspberry Pi and the charity behind it by now, designed with the aim to bring programming back into the school curriculum and spawn a new generation of coders, it’s had some fantastic news coverage and even people with no idea about computers have mentioned it to me over the last few months. It has been a rocky road, originally it was expected to have been released in late 2011 but finally the much anticipated single board computer has started to be delivered into the eager hands of geeks around the world. Initially only a caseless version of the “Model B” is available, intended for early adopters and developers with a fully cased version being launched for education later in the year. The idea being that by the time it reaches the hands of school children there will already be a healthy eco system built up around it and those preparing educational material will have been able to do so.

At the moment I am just familiarising myself with it and getting a grasp of what it is capable of. I’m running Debian Squeeze on it as that’s my distro of choice for servers and the like anyway and is also what the Raspberry Pi team are currently recommending. As a desktop it’s usable but pretty sluggish, perhaps not as much as expected but it’s potential for me lies more in the home automation and IoT field, £30 for a tiny networked Linux box is unbeatable and with up to 17 GPIO pins, built in UART and support for I2C and SPI it also opens up a lot of possibilities for interfacing to other hardware, a number of expansion boards are already available or in the pipeline. Here is a good primer on Getting Started with Raspberry Pi GPIO and Python.

The BBC Micro 30 Years On

Hard to believe that another one of the computers that had such an impact on my life is now thirty years old, I don’t feel old enough for anything I remember so well to be 30 years ago. After the Sinclair ZX81 and the Spectrum that followed it our next family computer was the BBC Micro Model B, it was an amazing computer for its time and remained in use for many years, I still have the same one today (that’s it on the right).

Made by Acorn Computers for the BBC as part of the BBC Computer Literacy Project it won out over the competition, including Sinclair, to build a computer for the BBC to use as part of its series to educate people about computers. The story behind the battle to win the contract was dramatised in the very enjoyable Micro Men programme that was shown as part of the Electric Revolution season on BBC Four in 2009. If you didn’t see it at the time it is well worth a watch.

Affectionately known as the Beeb, the BBC Micro was a 6502 based 8-bit micro with 16k or 32k RAM depending on the model, it ran at a relatively fast (for the time) 2MHz and it had a proper, robust keyboard, a plethora of connectivity options and a key factor in its success was the comparitively sophisticated BBC BASIC. Unlike most computers that followed it the Beeb also came with a proper manual, a thick ring bound affair that was actually a proper guide to BASIC programming. The Advanced User Guide available separately covered things in more detail including 6502 machine code and even contained a full circuit diagram.

Along with the accompanying television programmes and thanks to most schools choosing the BBC Micro it went on to become the corner stone of computing education throughout the 80s, together with the time then given to computing in the school curriculum it gave kids of my generation a grounding in computers that hasn’t really been seen since.

I spent many happy hours with the Beeb and learnt a lot both in and out of school. These were the days when you were taught how to program a computer at school rather than just operate one as sadly seems to be the case in these days of ICT classes that just teach kids how to use programs such as Word and Powerpoint.

The BBC Micro also gave me my first experience of networked computers, something that would become so important in later life. After one summer holiday we were excited to return to school to find we now had a dedicated computer room full of BBC Micros all networked with econet, much fun ensued and a little good natured mischief (netmess anyone?). A year or so later myself and several friends ran a teletext type information system (using the little known Mikefax software) that was used at open nights and sports days and eventually had a dedicated screen in the school entrance hall. My first experience of publishing information electronically.

The BBC Micro also brought my first exposure to computer communications, first using a 1200/75 baud modem and later a Watford LeModem to connect to local bulletin board systems and services such as Micronet800, Telecom Gold and Prestel (often using dodgy logins aquired from a BBS) and look where that ended up.

As with many of my generation I owe a lot to the BBC Micro and what it taught me and as many others have commented recently, this sort of thing is missing from the lives of most kids these days. Projects such as Coding For Kids, Raspberry Pi and the recently launched Goto Foundation can hopefully do something to help turn this around.

FIGnition: Build your own 8-bit computer

Build a computer from components in an afternoon? How could I resist?

Using only 3 chips and only 46 components in total, the FIGnition is a brand new 8-bit computer designed by Julian Skidmore that you can build yourself. It runs a variant of FIG-Forth and is based around the Atmel AVR microcontroller (an AtMega168), along with 8Kb of RAM and 384 Kb of flash storage and is controlled from an 8 key onboard keypad with video output by way of a PAL composite video output.

Despite its simple construction and minimal components the FIGnition is a fully functional computer, you can write programs on it in Forth using the onboard keypad and save them to its Flash chip; access the AVR’s hardware registers, video RAM, system clock and you can even define your own graphics characters. Thanks to the ability to upgrade the firmware over USB you can look forward to new features and performance improvements in the future and the entire hardware design, PCB layouts, firmware and documentation will all be release under an open source licence very soon.

FIGnition features:

  • A Boot-up time of <1s!
  • 8Kb of RAM, enough for around 2000 lines of Forth code.
  • At least 384Kb of Storage. You can edit your programs and store them for later use, building up your own libraries of code.
  • User-defined graphics! – FIGnition is designed to be used practically (within its hardware limitations), it’s not a crippled machine designed to let you print “Hello World.” FIGnition allows you to write a variety of games using your own graphic designs.
  • Upgradeable firmware – simply download the latest firmware from the Fignition website and upload it on your FIGnition via USB and avrdude.
  • A fantastic 4 spare I/O ports for you to attach your own electronics! Control your own power station eh?
  • FIGnition is already 4x faster than the definitive Forth computer, the Jupiter-Ace (which routinely sells on eBay for hundreds of pounds) and seriously faster when running Forth than any early 80s home computer. It’s fast enough to run some classic games and it’s not even optimised yet!
  • Programmable in-situ using an efficient 8-key keypad!

For more information see the FIGnition website and the FIGnition Google Group. FIGnition was also featured on the BBC News website last month.

FIGnition kits are currently available on eBay for £19.95 inc P&P but don’t hang around, the first batch sold out very quickly. The kit includes the PCB and all the components and is very easy to build using the online instructions, it took me just over an hour to finish the soldering and it worked first time. It’s always very satisfying to build something yourself and see it working and the FIGnition would be a great introduction to electronics for kids, I hope it is a great success and look forward to more interesting developments from Julian.

The Emperor’s New Desktop?

This post is a bit late but I wanted to make sure I was settled in my decision on Unity, Ubuntu’s new desktop. I had been running Ubuntu Natty Narwhal on my test box since before the first alpha so I was quite familiar with Unity and its quirks and initially I wasn’t a fan at all. It seemed ugly, feature lacking and buggy and throughout the alpha and beta period it seemed that it was just being rushed out to meet the 11.04 release regardless of whether it was ready or not. I didn’t think I would be using it and had even given serious consideration to going back to Debian testing for my main desktop box.

Anyway, with the final release of 11.04 I duly upgraded my main desktop machine and thought I would give it a go as my day to day desktop for a while, fully expecting to switch back to the “classic desktop” (ie. Gnome 2.x) before long but it didn’t happen and I have to say that Unity has grown on me. I’m not missing any of the things I thought I would and so far I’m even managing to live with the one thing about Unity that annoyed me the most during testing, namely the Global Menu.

For those not aware the Global Menu is the Apple style feature where each applications menu appears in the top panel instead of within the application itself. I understand Apple’s original reasoning behind this feature, ie. the menu is always in a consistent place and slamming the mouse to the top of the screen puts you in the right place but in a modern multiple monitor environment it just doesn’t stand up, that and it is currently inconsistent as it requires every app to support it. App support will get better over time I’m sure but I still think it is irrepairably broken on multiple monitors. Fortunately for those that really can’t stand it, the global menu can be disabled without too much effort but I am still trying to live with it for now to see if I can get used to it.

The other niggle with Unity that hadn’t really bothered me until I started to use it properly is the scroll bars. With a traditional scroll bar you can move your mouse to the right of the window and click to jump up/down at any point along the permenantly visible bar whereas with the new hidden scroll bar you have to look for the thin indicator and hover your mouse over that before you can access the scroll controls. It’s definitely slower and harder to use and as with the global menu it is inconsistent at the moment as not all applications use it.

The new dock on the left I wasn’t keen on initially and I missed the old task list panel at the bottom but now I’ve got used to it I actually prefer the dock, it seems quicker and gets less cluttered. The only change I’ve made is to make it narrower with smaller icons as it is a bit large by default.

In summary Unity is a mixed bag, it’s far from the disaster I thought it would be but it’s not the second coming either. There is still a lot that could be improved but I think it will get there, the issue of the duplication of effort between Unity and the very similar Gnome 3 is a completely different topic though.