How fast is a Modern Microcontroller?

At the time of writing, the Raspberry Pi Pico has just been released, so can be considered modern. How fast is it? Compared to the object of a recent project, the Psion Organiser II from the 80s, it is pretty fast. fast enough, in fact, to be able to pretend to be an EPROM in the Psion datapak.

Some Technical Psion History

The Psion Organiser II has two storage slots that were designed to hold data in a similar manner to hard drives on a PC. The sizes range from 16K up to 1Mb, although around 32K was a more usual size. The hardware in a datapak was simple: it was an EPROM. Later paks held RAM (and a battery) or flash for the very latest devices. Using more modern technology had a big advantage in that a UV eraser wasn't needed to clear the data on the pak. EPROMs had to be erased before allocated space could be re-used.

The storage devices in a pak are directly connected to a data bus on the slot connector, but the address bus was different. Due to a desire to reduce the number of connections required, the address bus on the storage device is attached to the outputs of a counter. To set up an address the clock on the counter is pulsed until the address is correct. Control signals then orchestrate the reading or writing of data.

Using this scheme the number of connections on a slot connector is kept to 16, even though datapaks up to 1Mb can be used. Larger address ranges would require a large number of clock pulses, slowing down the data rates, so larger datapaks use extra counters as page and/or segment counters. These control higher address lines and reduces the number of clock pulses needed to move to different addresses.

The Psion technical manual is available on the web and details all of the signals.

Pico

With the RP Pico arriving, I was very interested to see if I could use the programmable IO (PIO) feature to interface to older hardware. Creating a datapak for the Organiser II seemed to be one of those projects. The PIOs are small, fast processors or state machines that can perform tasks that are closely coupled to the GPIO lines on the Pico. As EPROMs (and RAM and flash) devices are usually found attached to processor buses they are inherently fast devices. The datapak doesn't run at high data rates, however, as the processor in the Organiser, a 6303, only runs at 900kHz. The interface code that drives the datapak slot signals drives them with no delays so, for example, the assertion of the slot select signal to read data is just three instructions:

Assert select

Read Data

De-assert select

With 3 or 4 cycles to execute these instructions we end up with a pulse width of about 200kHz or so.

This is well within the capabilities of the PIOs in the Pico, so I decided to go ahead and build a Pico powered datapak breakout board. this plugs in to one of the slots in the Psion and has an OLED display and some switches as well as level shifters (the Organiser is 5V, the Pico is 3V3). The idea is to present the RAM (or some of it) within the Pico as a datapak plugged in to the slot.

There's no commitment concerning GPIO assignment and the PIOs when creating a circuit with the Pico as the PIOs can use any GPIO, and can be disconnected from them entirely if code is to control them. So, I built a circuit before I had prototyped the method it would work under.

As it happened I had to make three boards as I messed up the slot connections on the first board (so it would only work upside down, not useful), and on the second board the level shifters I chose (YE08s) just didn't work. The third board using 74LVC245s worked perfectly. Well, the hardware did. As i looked at the PIO program that would be needed I started to realise that maybe the PIOs couldn't handle this interface. The problem was twofold:

1. The address counters were hard to implement as only one register (X) in the PIO could be changed by one in a PIO program. And it could only be decremented. Only decrementing wasn't too much of a problem, but there were also up to three counters in a datapak. Synchronising the address lines could be tricky.

2. The second problem was more of a show stopper. The address counters have to be combined and then be used to address the RAM buffer in order to get the data to be read or written. I couldn't see how to do this, which put a stop to me using the PIOs

Speed

Coming to the rescue, however, is the sheer speed of the processors in the RP2040 (the Pico processor). There's two cores running at over 100MHz and this is enough processing power to handle the datapak interface in firmware. I had to run the address counter handling on one core and the control signal handling on the other. I also found that interrupt latency was too high and have to poll the GPIOs in a loop. This means that the code has to run in two modes, one that is handling the pak protocol, and one that is driving a UI. This isn't much of a limitation as the Psion only talks to the datapak when reading or writing and actually powers the paks down when not using them. (This power down behaviour means that I have to power the Pico pak with a USB cable otherwise it is turned off between accesses).

After quite a lot of coding and interface investigation I managed to get this working and the code is capable of emulating a 32K datapak. With 235K of RAM on the RP2040 it shoul dbe possible to emulate 64K, and maybe 128K paks.

Space

The best form factor for a datapak emulator is, well, that of a datapak. So can the RP2040 fit in that footprint? Well, yes it can. The level shifters fit as well, as does a small OLED display and some buttons. In fact, the breakout board circuit can be shrunk down to fit in the datapak enclosure (holes for buttons and the display are needed, and for the USB connector).

For bulk storage I added an SD card slot so datapak images (in .opk format) can be read and written to and from the RAM buffer in the RP2040. That provides enough storage to easily store every datapak image I can find. Any of these can be swapped in to the RAM buffer and used as required. You can also write data to the RAM buffer and then write that to the SD card, providing almost unlimited memory to the organiser.

The wires are for programming the RP2040, they solder to pads on the PCB. The display is mounted 180 degrees from where I want it due to a PCB layout problem. The idea is to have the entire unit fit in the space of one datapak, which it should do when V2.0 fixes the issues on this PCB. 

The package used by the RP2040 turned out to not be a massive issue when hand soldering, using some extra solder and a hot air gun I was able to solder two devices with no problems and a third has some unknown issues which were solved by removing it and replacing with a new device.

The breakout board:

The datapak sized board:

The datapak form factor board, and the gadget plugged in to a model LZ organiser.

Latest OLED Watches

The latest iterations of the OLED watch are finally approaching wearable. Well, the first of the two is wearable but a bit thick. The second is much more wearable size.

The first iteration is the smallest PCB so far fitted into a 3D printed case and mounted on a cloth strap latched with velcro.

The switches are mounted on the top and the clear front flexes when they are pressed.

The overall thickness is 15mm, which is a bit too thick to wear comfortably. It gets caught on sleeves and catches easily on fabric.


The latest iteration is a one that doesn't use a PCB. This removes 1.6mm of thickness immediately, but makes the construction more manual.

The wiring is manually laid out and not very tidy. the thickness is much less, at 9mm, or 10mm to the tops of the front cover screws. Compared to my main watch this is very similar.

The components are mounted in a 3D printed frame like this earlier version:

The minimum thickness is fixed by the switches that I have used. The wiring adds a millimetre or so to the thickness, that could be reduced by inlaying the wires into the frame. More use could also be made of the 3D space in the frame. At the moment there are no components on top of components.

Using a PLA 3D printed frame is useful as it is possible to heat components and wiring up with a soldering iron and push it into the PLA. This then holds the component firm when the plastic cools.

There may be a better way to wire the components, maybe using a smaller PCB that just has the surface mount components on it.

Watch V6 (With Pogos)

The latest iteration of the watch uses a smaller OLED display I found on ebay. Due to the problems and size of the USB socket I used on previous watches I have gone with pogo pins on this version. This means a jig is required, this is done with stacked PCBs in this case. A cutout allows the PCB to fit into the jig when the pogos re used. The pogos have the programming interface, which includes power for charging the battery.

The PCB fits well in the jig:

I used gcode to cut the rectangle in the top and second PCBs in the stack.

The second PCB has a slightly smaller cutout so the PCB doesn't just fall through the top PCB.

The pogo pins are at just the right height to press on pads on the bottom side of the watch PCB.

The PCB when populated is quite small:

This is the first PCB, which had a few mistakes. I've fixed these in a later PCB. The new PIC (16F1829) has a way to measure the battery voltage with no external voltage divider, so a couple of resistors can be removed form the layout. This PIC also has a larger amount of RAM and flash, and may also be able to measure temperature with no external components.

OLED Watch

The PCBs for the OLED watch have come back. That's the good news. The bad news is that the pinout for the PIC was for the wrong package and the battery holder is missing from the back.
They look nice though:

I've relaid the board out and sent the second set of artwork off.

The old boards might be usable if I solder an 8 pin PIC onto the IC pads. I could then maybe use an OLED display on the PCB.

Watch

I have to send my watch off every four or five years and am then left with no watch for a while. In the spirit of other making, I've decided to have a go at a watch of my own.

This is a breadboarded circuit using the 40 pin DIP chip. I bought a few of the DIP versions as they are much better for prototyping, I don't want to have to build a PCB at this stage.

The OLED display is here, I have written some simple I2C functions to talk to it and  have just sent an initialisation sequence. It's quite a complicated driver and so requires a lot of initialisation just to get to this point. The display pattern is just random RAM data, with some other data written on top.