Wednesday, 11 March 2015

A tiny ATtiny

Very tiny!
 Recently I was surprised to discover that although I've made several projects using one, I'd never built a development board around the ATtiny85. With any project there are always design choices and a couple of important ones here were:
  • Is a breadboard optional or required? If optional, you get the familiar Arduino form-factor, which can either be connected to a breadboard using jumper cables or populated with pre-built shields.
  • Design a PCB or something more ad hoc? I wanted something quickly --- I wasn't going into competition with the Teensy or Trinket.
  • If not designing your own PCB, use stripboard or protoboard? While I've never been a huge fan of protoboard, because you're basically making your own strips by blobbing solder across pads, you can get quite a high component density with it.
So I opted for the path not taken, requiring a breadboard and using protoboard, and the result is pictured above. Notice that protoboard allows the FTDI connector to be attached at right-angles to the chip (try that with stripboard!) and also exposes more of the breadboard for jumper cables (the 10k resistor connecting reset and Vcc is underneath the chip).

With the ever-useful Tiny-Safe-Boot bootloader and a bespoke entry in my arduino-tiny's boards.txt file, it's as easy as regular Arduino, at a fraction the cost!

Thursday, 19 February 2015

TinySensor Server

Well after almost a year I decided it was time to update this project with improvements to both its hardware and software.

On the hardware side, the server is still the original Raspberry Pi model B, but I've mounted the nRF24L01+ radio on a neat little Slice of Pi board. (These boards also have traces for mounting XBees with their unusual pin spacing. And they're cheap!)

The Slice of Pi board (left) with radio and status LEDs
While I had the soldering iron out, I added a couple of status LEDs (see picture). The green one indicates recent activity on the radio, while the red one indicates a timeout but also flashes every time a packet is received. Both of them are driven by a single GPIO line on the Pi. (This was motivated by the radio cutting out on the Pi, probably due to the original Heath-Robinson jumper cable arrangement, and since its transplant it's behaved perfectly.)

On the software side, there are now quite a few little daemons, each doing one thing well:
  • A wireless hub, running RF24-rpi, sends packets received on a TCP socket,
  • A wired hub, running remotely, polls a legacy 1-wire sensor network and sends its readings on another TCP socket,
  • A multiplexor, connected to the two data sources above, sends their streams to its connected clients, described next,
  • A MySQL client writes readings to a database,
  • A status client manages the LEDs described above,
  • An RRD client maintains a round-robin database,
  • An lcdproc client updates a wireless LCD display.
All of these are, as usual, on GitHub.

Future software components planned for this system include a simple weather service to inject local weather data into the stream, and a client for one of the various IoT services now becoming widespread. (Here is a fairly recent overview of some of these.)

Wednesday, 3 December 2014

Space Invaders!

When I was a teenager Space Invaders arrived and changed the world. I must have put pounds into that machine in the local chipper, in the days when chips cost shillings. It never occurred to me that you could actually buy one of your own until one of my brother's friends' fathers did. (Come to think of it though, if I'd kept all of the cash I put into various machines, I probably could have had one of my own. I believe this is known as delayed gratification.)

Same Hardware, Different Processor!

Fast-forward 30-odd years and I'm sitting there blogging about an emulation of an 8-bit microcomputer of similar vintage. Hmm...

Space Invaders hardware comprises an Intel 8080 clocked at 2MHz, 8k ROM, 1k RAM and 7k memory-mapped video RAM. (An Emutalk thread has all the details and the ROMs.) The most difficult part is definitely the CPU but that only has to be done once to open up a whole world of crap games.

There are dozens of 8080 emulations out there, of varying quality. (Most of them written solely for this game!) I picked one and remixed it in the spirit of the 6502 emulator I made for the UK101; it plugs into that framework quite easily.

When a moderately-complex project like this links for the first time, the natural thing to do is upload it, more in hope than expectation, and when it fails, start debugging. The best way to do this is with a test-suite, preferably one which someone else has written in advance. (This worked out really well for my 6502 core thanks to Klaus Dormann's excellent 6502 tester.)

For the 8080, all searches led to a 'CPU exerciser'. Rather than testing a single instruction in isolation, this program runs a group of operations with different arguments and merging the resulting CPU state into a checksum as it goes. If the final checksum obtained by 'your' CPU is the same as one from a real chip, you know (to a high probability anyway) that your implementation is good for the instructions tested. (Luckily, that page documents results from real CPUs so there's no need to dig up an old 8080 board.)

If that sounds daunting, it is! Fortunately a preliminary test is also provided which tests the instructions required to run the exerciser itself. This helped fix a few bugs on its own and, since it used the CP/M "bdos conout" operation to report success, raised the interesting possibility of implementing a virtual 8080-based CP/M machine. I subsequently found a slightly more complex set of tests in another emulator's repository which helped find enough bugs to get all-but-two of the exerciser's tests passing.

(Timings of the exerciser indicate that my 8 year-old Lenovo laptop runs an emulated 8080 about 80x faster than the 2MHz 8080 for which it was intended. I haven't timed it on a Stellaris Launchpad however.)

Adventures in Dremel

So, despite the fact that some bugs remain in the emulation, enough of it is working to run Space Invaders properly. It runs at correct speed because it is driven by a timer interrupt (emulated with Energia's millisecond timer) and therefore we didn't need to bother keeping track of individual instruction timings, which all of the CPU emulators I looked at did. (Most of them were similar in other ways too, indicating a common influence, perhaps in this document.)

Just like the real thing, if you're 6" tall.

You can find the whole thing at Github, as usual.

Wednesday, 12 November 2014

In the Beginning... was the Command Line

Say what you like about the Arduino IDE, it's certainly lowered the barriers to entry for kids messing about with microcontrollers. 

Oh wait, that's not what I wanted to say at all...

Sometimes the Arduino IDE is simply not enough. It just gets in your way. Your project has outgrown it.

These were a few of my more printable thoughts as I tried to force a quart of UK101 emulation into the pint-pot of that tiny editor window. At times I'd no idea which file I was even editing! I longed to bust out emacs (or even vi).

What I really wanted was make. In particular GNU make. Simply the best build-tool ever, no question.

Many people have written Makefiles to build Arduino sketches but none of them felt right to me. They were all too complicated, too monolithic. Or maybe it was just a case of not-invented-here. In any case, I present uC-Makefile, which supports Arduino-1.0 and Energia.

The best thing about it so far has been control over the compiler's optimisation levels. Compiled with optimisation -O3, that old microcomputer's emulated Basic interpreter ran almost 5x faster!

Bye-bye, Arduino IDE!

Wednesday, 20 August 2014

Retrocomputer Resurrection

"What's a Computer?"
This chimera is a microcontroller emulation of a UK101, an 8-bit microcomputer from the early 1980s. Needless to say I had one; it is a shocking thirty-three years since, as a spotty teenager, I soldered one together over the course of a few days. I recall the kit cost the equally shocking sum of £99.95 (a lot of pocket-money), and had to be smuggled through Irish customs in my parents' car because the Single European Market was at that time merely a twinkle in M. Delors' eye. In its original configuration it had 1k of user RAM, 1k of display RAM, 8k ROM Basic (from Microsoft) and a 2k ROM monitor. When it went to its present resting place in the attic a couple of years later, it had 16k of user RAM, 2k of display RAM and an additional 6k of utility ROM, all piggy-backed on the original chips.

The last time I had patently too much time on my hands, in 1997 (seventeen years!), I hacked together a software simulation of it. I had intended this to be a general purpose simulator but it fell by the wayside after the UK101. In the intervening time I'd often regretted not writing the simulator in Java (indeed, a very good Java-based simulator now exists) but luckily where microcontrollers are concerned, C/C++ is still the only game in town, and most of the code compiled under the Energia IDE.

The hardware is almost insultingly simple, there are five components:
  • A Stellaris Launchpad from Texas Instruments,
  • An SD card drive,
  • A TFT LCD boosterpack,
  • A PS/2 socket,
  • A PS/2 keyboard.
While the Launchpad has only 16k of RAM, of which 12k is used for the main memory and 2k for the display, it does have 256k of flash, easily enough to contain all of the ROMs I've collected for it. (Another UK101 hardware instantiation can support the full 40k of user RAM.)

This build's main limitations are the display (only 30 lines of 40 characters vs the original's 32x48 ---  affordable TFT screens max-out at 240x320 pixels these days) and the keyboard (a lot of the games use the Control, Left-shift and Right-shift keys, which aren't available individually from the off-the-shelf PS/2 keyboard library).

However it has one modern advantages over the original which almost makes it enjoyable to use: checkpointing and restoring the machine state using the SD card. This allows creation of initial game images (which load instantly since they're only 14k) and progressive checkpoints, as adventure games are completed, for instance, or new programs developed.

Space Invaders: it doesn't get much better than this!
Code and programs are at GitHub, should you care.

The final thing is to find a suitably retrotacular housing for it. Something like this would be about right...

Kim Greist in "Brazil" by Terry Gilliam

Thursday, 31 July 2014

RF24 and ATtiny, now with added debugging!

Last time's throwaway comment about the potential to use plain-old Serial.print() instead of printf() for debugging RF24 on constrained platforms turned into an itch that had to be scratched. The latest versions of RF24 and RF24Network on the GitHub have a bunch of improvements:

  • RF24Debug (and RF24NetworkDebug) now extend the non-debugging classes,
  • Their constructors take a Print object which defaults to Serial,
  • Their implementations use plain-ol' Print.print() throughout,
  • An ATtiny example, tinypingpair, has been added.
You've seen it all before, but hey!
The upshot of all this is that simply replacing the declaration of RF24 by RF24Debug in your sketch causes all sorts of debugging to be written to the serial port, even on ATtiny!

A nice side-effect is that debugging can be directed at anything which implements the Print interface, for example, anything which extends Adafruit's GFX library, i.e., their LCD screens.

Note that tinypingpair with debugging now takes up 99% of the available space on my ATtiny development board (there would be slightly more room without a bootloader). In spite of that, this work remains useful, helping beginners get started with this nice combination of radio and microcontroller.

Update: I've just verified that debugging works on the Fraunchpad with the new scheme, noting the usual caveat about timeouts.

Tuesday, 29 July 2014

RF24 with MSP430 revisited

Well it's taken longer than expected, but today the RF24 and RF24Network libraries are finally ready for use with MSP430. (Get them from GitHub as usual.)

The main improvement is to switch from using the C++-preprocessor to conditionally-compile debugging printf() statements, to explicitly configuring a debugging class into the sketch. For an example of its use, see the revamped pingpair sketch.

The advantage of this is that it allows other approaches to debugging, such as blinking LEDs (on platforms without serial ports) or using plain old Serial.print() on platforms too constrained to support printf(), such as the ATtinys. A secondary advantage is that it makes the mainline code easier to read.
MSP430 (with jumpers set for Hardware UART)

Note that the MSP430 has a fairly restricted serial port itself, at least compared to what we're used to from Arduino. A long description can be found here, but suffice it to say that, as shipped, you have to change jumpers to see anything output by Serial.print() and what you get is limited to 9600 baud. This means that the very act of debugging can cause some of the examples to timeout, so caution is required!

Linux users are rewarded with an additional set of problems to deal with, as documented here. Follow the instructions from the section "Fix a Linux kernel bug..." to rebuild the relevant kernel driver. (Note that there are some existing patches floating around the network which no longer work because this driver has seen some updates recently --- my kernel is version 3.11).

Once the driver was patched, I found that the serial port is best accessed using minicom as root. (Furthermore the first attempt at an upload usually fails for me, although the second and subsequent ones succeed.)

Finally note that a quick smoke test showed these libraries working on the Fraunchpad and Stellarpad too, although serial port issues prevented me seeing any debugging info on these targets.