Not much of a blog today, as I have spent the whole day travelling. Either driving the 150 miles each way from home to Loughborough University, or walking (and more walking) round what they claim is the largest university campus in Europe. It certainly felt that way!

As well as visiting general facilities (Students' Union, accommodation, the lovely new library etc.) my daughter and I spent time in the Computer Science and Electronics departments, which was very interesting. Unlike Reading, which we visited last week, Computing and Electronics are kept very separate, Electronics lives with other engineering disciplines, as well as physics and maths, at one end of the campus, while Computer Science is over a km away, almost at the other end. They seem equally far apart organisationally. Despite the overlap of course content (The Computer Systems Engineering course includes software, for example, while the Computer Science course includes AI and robots) neither department seemed at all interested in the other. This is a shame, as otherwise the university seems a lovely place, with a very high student satisfaction score and good academic and career prospects too.

Yesterday I went along to another meeting of the Ipswich Makerspace. This time we were in a larger hall at Holy Trinity Church, just across from the small room we met in last time. We had a few more people turn up, but there's still plenty of room to grow!

Generic PC components are astonishingly cheap, due mainly to economies of scale and the continuing demand for the newest and greatest. This gives a lot of opportunities for anyone with an interest in tinkering. Take for example the PC power supply unit. Since the introduction of the ATX connection standard about 20 years ago, pretty much all PSU boxes have been interchangeable, differing mainly in things such as total power, quietness, length of cables and quantity of extra connectors. This has driven the price right down, but all ATX compatible PSUs provide at least 3.3V, 5V, and +/- 12V and they all provide copious (in microelectronics terms, at least) current

This is exciting. A Raspberry Pi Compute Module Development Kit (a.k.a "Model C") arrived in the post today. At last I have a "Raspberry Pi" with a decent number of GPIO pins.

Just as when the Original Pi launched, there is not much information or third-party support yet. In particular, I'd love to see a sensible way of running and testing this using a proper debugger (JTAG?) but there is no mention of this in the scant documentation from the foundation.

After several attempts (blogged here, here, and here) at getting an Atmel AVR chip on a daughter board to communicate with a Raspberry Pi, I am now excited to report that I have it working.

I turned out here were several things wrong:

• I needed to stop the Raspberry Pi serial port console login, as it was confusing things no end.
• As I reported last time, I had copied a "Board Definition" from one for an Arduino on a Gertboard. Unfortunately it appears that the Gertboard uses a 12MHz crystal, where my circuit uses 16MHz, like the Arduino Uno.
• In addition, there was an error in my wiring. It turns out that all my puzzlement over what pin the data was being transferred on was largely due to me mis-reading my own diagram, and connecting the serial lines to pins 6 and 8 on the Raspberry Pi GPIO header rather than pins 8 and 10. D'oh!

To make sure it all works, I wrote a simple program in the Arduino IDE. The idea is that it prints a prompt asking for input. The user then types a line of stuff (ending with the enter key), which the program gives back. When testing this I found that because the AVR starts so much faster than the Raspberry Pi, the prompt has long since been sent by the time the Pi terminal emulator is running. To make this a little more friendly, I added some code to show the prompt again if the user gives an empty line (by just pressing enter, for example.)

Another demo that I saw while at the Freescale Tech Day was also pretty simple, but already moving a step beyond the traditional Arduino examples. It's just blinking a LED, but rather than the "brute force" approach of switching the pin then forcing a wait before switching it again (the algorithm in the classic Arduino "blink" example), this one is a bit smarter and uses a timer interrupt. Sure, you can use timers and interrupts on an AVR, but it's telling that this is considered an advanced feature.

Yesterday I drove my daughter over to Reading for a university open day. Even though it feels as though she has just started A-levels, it's time to think about what happens after sixth-form. Things kicked off at the university at 09:30, so we left a little before 07:00 to drive the 130 miles or so. Luckily there were not as many traffic problems as when I went to Milton Keynes a few days ago, and we arrived on the campus at about 09:15.

So I'm still banging my head against the difficulty of making a simple serial connection between my Raspberry Pi and an ATMega chip on a daughter board. And I still have not got it working properly.

Overnight it occurred to me that I ought to have turned off the serial port login on the Raspberry Pi. I'm sure this was getting in the way and confusing things, so I followed some steps I found from a quick Google search.

Today, I thought I'd have a go at running one of the simple demonstrations I saw at the recent Freescale Tech Day in Milton Keynes. I have a FRDM-K64F development board which I bought a few weeks ago, and my fresh installation of the KDS IDE. The K64F is a lovely board with a powerful ARM Cortex M4F CPU running at up to 120MHz, has built-in ethernet and debugger support, and was used for several of the demonstrations, so it seems a reasonable choice. Getting started is a lot more tricky than with an Arduino, though.