Monthly Archives: August 2013

The BBC Micro linear power supply

The BBC Micro is the machine that really got me into computing. It was designed by Acorn in a tearing hurry for the BBC Computer Literacy Project in 1981 – see the film Micro Men for a great dramatization of the story. Because it was done in such a rush, some things weren’t quite finished for the early machines. One of those things was the power supply.

Why is the power supply interesting? Well, later BBC Micros had a perfectly normal, reliable switch-mode power supply, not dissimilar to the one in a modern PC. But early ones had a linear power supply, which gained a fearsome reputation for overheating, exploding, and being incompatible with nearly everything. I recently dragged an early, Issue 2, BBC Micro out of the loft and realised it contained this elusive beast, the linear power supply. I thought I’d see what all the fuss was about.

First things first: does it work? Well, yes. Despite not having been switched on for probably 20 years, it powered up absolutely fine. Boop-beep. No smoke or flames. Good. Time to see what’s inside.

This particular machine started life as a model A, with just 16K of RAM and very little else. However, it got upgraded at some point into a model B, with the full complement of RAM, and has an unusual Opus double-density disc interface in it as well as a couple of extra ROMs including Wordwise, the word processor. That’s the sort of thing that’s supposed to be impossible with a linear power supply. You can see the black box on the left – later power supplies are a gold colour. Here are a couple of closeups of its labels:

I took it out and examined it. The first thing I noticed was that it doesn’t really fit very well: there are some odd washers sandwiched between the power supply and the case, and they’ve used nylon screws to fit it, for some reason.

You can probably see from the side view that it’s riveted together. The rivets were quickly dealt with, revealing the insides:

Pretty straightforward stuff: a toroidal transformer, rectifier and smoothing, and a row of regulators. Here are closeups of the circuit board and regulators. Note the little orange tantalum capacitors. I suspect that’s where the reputation for explosions has come from: when used like this, they do tend to fail short-circuit and go off like little fireworks from time to time. These ones, however, are rated at 35V, so with only 5V or 12V across them they should be fairly reliable.

It didn’t take long to trace out the circuit.

What is interesting is the way the 2.25A output at 5V is achieved. Rather than use one big regulator, they’ve chosen to use three 7805s, rated at 1A each. Three sets of wires leave the power supply and are delivered to three places on the Beeb’s motherboard. There is no connection between the three 5V rails on the motherboard according to my meter. They’re entirely independent. This is good, because it means that the three 7805s won’t end up fighting each other if their output voltages are slightly different.

I took a few measurements while the machine was running. The voltage on the 4700uF smoothing capacitors was 10.5V. The currents delivered by each output were:

VCC1: 0.49A
VCC2: 0.75A
VCC3: 0.84A
-5V: 15mA

I tried removing the disc interface to see what difference that made to the power consumption. It reduced VCC1 to 0.35A and had no other effect.

The total current flowing at 5V is just over 2A, which is sailing fairly close to the wind given that the power supply is only rated at 2.25A. However, nothing in the power supply is under great stress, and I see no reason why it should fail unexpectedly. Unlike a switch-mode supply, it would also be easy to repair. If it was going to be used for a long time, I’d be very tempted to replace the 1uF tantalum capacitors with modern ceramic or electrolytic ones, just because the tantalums do tend to commit suicide randomly with old age.

These machines are now becoming collectable, and early ones like this are worth preserving in their own right. If you’ve got an early Beeb, there’s no reason to fear the linear power supply and replace it. It’s part of the story, and it’s possible to keep it going more or less indefinitely.

Installing balloonboard.org Debian Linux build on a Raspberry Pi

2 Replies

I’ve just successfully got Debian Linux running on a Raspberry Pi, having built it entirely from the balloonboard.org distribution. Why might you want to do this? Well, I did it because it gives me a small, clean Debian Linux installation which I can then customise. Here’s how I did it.

Get the software:

svn checkout svn://balloonboard.org/balloon/branches/menuconfig2
make menuconfig

Mode Expert mode
Balloon Board Raspberry Pi board
Choose which buildroot version to build -> Feb 2013
Select kernel version 3.8 (rpi)
Select Build boot image
Select Build kernel modules
Select Build initrd kernel
Select Build Raspberry Pi boot patition image
Select Build Debian Root Filesystem

Now type make and it should all build.

Create yourself an SD card with two partitions on it: one smallish FAT partition for the boot files, and a big ext4 one for the root filesystem. Don’t forget to format them.

Into the FAT partition copy the contents of build/kernel/rpi-initrd-boot. Into the ext4 partition untar the file build/rootfs/debianrootstrap.modules.tgz.

Now put the SD card into your Pi and switch it on. This should boot into a ‘recovery kernel’ which has a minimal root filesystem in its initial ramdisk, just enough to sort out the ‘proper’ root filesystem. I used the console serial port to work with it. The HDMI and USB ports might also work but I haven’t tried them. It should come up with a login prompt. Log in as root, password rootme.

Now to configure the root filesystem:

mount /dev/mmcblk0p2 /mnt/root
chroot /mnt/root

Finish the Debian installation (this has to be done now because some aspects of it need to run on the ARM processor, so it’s not easy to have your PC do it). It will ask you questions about time zones and things:

/var/lib/dpkg/info/dash.preinst install
dpkg --configure -a

Set a password for the root account so you can log in

passwd root

and add the serial port to the list of secure ports which are considered safe for root logins:

echo /dev/ttyAMA0 >> /etc/securetty

And shut things down

halt

That last step will probably produce an error message, but it doesn’t matter as long as it’s written everything to the SD card.

Now put the SD card back in your PC, and copy the contents of build/kernel/rpi-boot into the FAT partition. That contains the real kernel which will mount the newly-minted root filesystem. Put it back into the Pi and boot. It will ask you to change the root password at first login.

It worked for me, though I had to ‘ifdown eth0’ and ‘ifup eth0’ again to get Ethernet to work. From that point on I was able to install Debian packages normally.

How to get the second Raspberry Pi I2C bus to work

5 Replies

One of the useful interfaces on the Raspberry Pi is the I2C bus. Originally invented by Philips in the 1970s for controlling functions inside consumer electronics, especially TVs, it’s still very handy for connecting up lowish-speed peripherals to computers. Some of the most popular are real time clocks like the MCP7940, amongst many others, and general purpose input-output chips like the venerable PCF8574. One of its convenient features is that it only involves two wires: SCL (clock) and SDA (data).

The Raspberry Pi originally exposed one I2C bus on its GPIO connector, P1. It had another I2C bus dedicated to the camera connector, S5. However, with revision 2 of the Raspberry Pi, another connector was added. This was P5, squeezed in next to P1, and it also carried the second I2C bus, making it easier to get at and use. However, for some reason the two I2C buses got swapped over between revision 1 and revision 2. And to add a further layer of complication, the camera connector and P5 are wired to different GPIO pins on the processor, even though they are both logically the same bus. I’ve tried to summarise the situation in the table below.

	Revision 1		Revision 2
GPIO0	SDA0	P1 pin 3	SDA0	S5 pin 13
GPIO1	SCL0	P1 pin 5	SCL0	S5 pin 14
GPIO2	SDA1	S5 pin 13	SDA1	P5 pin 3
GPIO3	SCL1	S5 pin 14	SCL1	P5 pin 4
GPIO28			SDA0	P1 pin 3
GPIO29			SCL0	P1 pin 5

Working on the CUED MDP project recently, I had a need to get the both I2C buses working on a revision 2 Raspberry Pi. There was no problem with the one on P5: typing

i2cdetect -y 1

showed the devices I had connected to it. But

i2cdetect -y 0

showed nothing at all, and examining pins 3 and 5 of P1 showed no activity. Disappointing. After a bit of digging, it seemed to me that the standard Raspberry Pi Linux kernel configures the processor to use GPIO 0 and 1 as I2C bus 0, and GPIO 2 and 3 as I2C bus 1. I wanted the bus on P1 to work, so I needed GPIO 28 and 29 to be my bus 0.

The BCM2835 processor on the Raspberry Pi, like most modern integrated processors, can have its pins programmed to do various different functions. In this case I needed to disable I2C on GPIO 0 and 1 and enable it on GPIO 28 and 29. To do this I enlisted the help of Mike McCauley’s BCM2835 library. It makes reprogramming the GPIOs fairly straightforward.

To install the library on your Raspberry Pi, make sure it’s connected to the internet, then:

wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.26.tar.gz
tar xzvf bcm2835-1.26.tar.gz
cd bcm2835-1.26
./configure
make
sudo make check
sudo make install

By the time you read this, there might be a new version of the library, so check on Mike’s site to see what you’re getting.

The C code to set up the bus looks like this:

#include <bcm2835.h> 

#define BCM2835_GPIO_FSEL_INPT 0 
#define BCM2835_GPIO_FSEL_ALT0 4 

main() {
    bcm2835_init(); 
    bcm2835_gpio_fsel(0, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(1, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(28, BCM2835_GPIO_FSEL_INPT); 
    bcm2835_gpio_fsel(29, BCM2835_GPIO_FSEL_INPT); 

    bcm2835_gpio_fsel(28, BCM2835_GPIO_FSEL_ALT0); 
    bcm2835_gpio_set_pud(28, BCM2835_GPIO_PUD_UP); 
    bcm2835_gpio_fsel(29, BCM2835_GPIO_FSEL_ALT0); 
    bcm2835_gpio_set_pud(29, BCM2835_GPIO_PUD_UP); 
}

It initialises the library, sets GPIO 0 and 1 as normal inputs (thus disabling their I2C function) and enables GPIO 28 and 29 as alternate function 0 (I2C bus), with pullup enabled. To build it, cut and paste the code into a file. I called it i2c0.c. Then compile it:

cc i2c0.c -o i2c0 -lbcm2835

and run it:

sudo ./i2c0

Now I2C bus 0 will be active on P1. Well, it worked for me. Once the code is compiled, of course, you can just run ‘i2c0’ after booting the Pi.

I realise that in future this will probably be made obsolete by changing the device tree sent to the Linux kernel at boot time, but for now it’s useful!