RFID reader for BiuldBrighton door pt II

The RFID reader door-opening mechanism at BuildBrighton went a bit funny a few days back. The screen was full of garbled characters and the system got into a "locked up" state, so that no-one could use the door entry system! As we were using "in-development" firmware, there was no clever trickery like watchdog timers keeping everything in check, it just locked up and stayed locked up.

We're not sure of the exact cause of the failure, but given that we noticed there was no flyback diode on the relay coil, there's a good chance some negative voltage has caused it to go screwy!

After failing (and once someone had arrived at the hackspace with an actual piece-of-metal key to open the door) it also looked like someone had had a go at fixing it - not be consulting the schematics, reading the firmware or tracing back the wires to see how it worked - more like poking odd wires into odd holes. No wonder it stopped working!

So the new v2 version is going to have to be soldered together, to stop little fingers from poking about with the wires. While we're about it, we're also using on of Arthur's really cool ethernet-to-UART modules to do the talking to the BB members website.

At about midnight last night, we finally got a working duplicate copy of the door opening mechanism. We made everything that needed to connect to anything else use a socket (or in some places, a 0.1" pitch pin header) which helped with the modular prototyping. Arthur soldered up the wires from the door into a number of "plugs" using some more 0.1" pin header and plugged it all in.

Amazingly, it worked pretty much first time (although, it had taken about four hours to solder up the perfboard, inbetween helping out other members, drinking tea, munching pizza, doing some laser training and cutting parts for another project).

BuildBrighton once again has a working door entry system.

Which means we can get back to our own personal projects for next time ;-)

How Hirst Arts moulds can change your game

Not just because they create really impressive looking terrain. Not even because you can end up with loads of modular sections which allow you to create thousands of combinations of Space-Hulk style corridors. In our case, the need (ok, the desire) to use the Hirst Art moulds has actually made us change the way we've approached our gameplay.

Originally, all our board sections were designed on a strict 1" grid. All walls were either exactly horizontal or vertical (following the lines of the grid) and each wall filled one square-width.

Collision detection was easy - draw a line from the centre of the start square to the centre of the destination square and walk along it. If, at any point, you hit a square containing an obstacle, the line of sight (or line of firing, it uses the same algorithm) is interrupted where the collision occurs.

However, with the Hirst Arts moulds, we've had to make a few changes.
To begin with, we've had to offset some doors and entrance-ways on the rooms, deviating slightly from the "how to" guides on the Hirst Arts website. The way they are designed in the online guides puts the door in the dead centre of a two-square wide room

On a playing surface with no grid (a typical wargaming table for example) this causes no problems. So that our doors still line up with our grid (along with the walls etc, while still trying to get the maximum playable area within each room) we've moved the door sections across by half-a-square, and replaced the pillars on either side with a single-pieced section, off to one side

In the image above, we can see already where our problems are going to stem from, if we stick with the rule that each wall occupies one floor-tile-width, when it comes to calculating line of sight, and line of firing.

Even if the corner pieces cannot be walked through (the corner section takes up too much room to be able to comfortably place a 25mm base in the square) it's pretty obvious that a character placed in  the centre square below the wall should be able to see the square diagonally opposite. But with the "one wall takes a sqaure" rule for line-of-sight checks, this LOS would fail, and potentially spoil the effect on the game.

When it comes to corner pieces, the answer is simple - remove the corner pieces from the "collision map" when checking for line-of-sight (and line-of-firing)

Now anyone standing in the centre square below the bottom wall can see all squares diagonally. The LOS goes through the corner squares containing a small piece of the wall, but this isn't enough to cause the line-of-sight check to fail, and shouldn't stop a character firing at another square, diagonally across from them.

But even this doesn't actually fix the problem. The problem is that the walls don't take up one square width. And sometimes our line-of-sight check is going to fail incorrectly, because of the angle between the source and destination squares, not just because of corner pieces on room edges. For example:

By using a full square-width for our line-of-sight checks, this would cause one character to be invisible to another - the line-of-sight passes through a square containing a wall section. But if we ignore the darker shaded areas, we can see that in this case both characters would be able to see past the rounded corner of the wall, and should be able to see each other. Here's another example:

A character on the green square should be able to see a character on the blue square. The amount of wall in the way is negligible. But the line-of-sight check still passes through a square which contains a wall section - even though it's not directly in the line of sight between the centre-points of the two squares. Using the current grid-based approach to line-of-sight, we'd still be getting a hit with the wall, when quite clearly there shouldn't be one!

However, the Hirst Art moulds are just too nice not to look at. There are plenty of war-gaming and tabletop gaming fans out there, not only with the moulds, but with some really nice (non-regular) terrain, just waiting to be used in a game like this. So we need to find a way of accommodating different, not-so-blocky rooms and layouts. And the obvious answer is... another software re-write!

This time, our board game (in the app) consists of a graphic/image layer, depicting the map as the playing surface - and underneath this layer (invisible to the player) is a one-bit collision map. We're going to use the grid as a guide for the movement of playing pieces (and for calculating proximity between pieces and special squares on the board) but for line-of-sight, and firing, we're going to pretend the grid simply doesn't exist.

So when playing a game like this, the collision map can have any shaped room, with walls of any thickness, placed directly on the grid, or slightly offset from it. Of course, this is going to make an online editor a little more complicated to code (and maybe even to use) but the end result will not just be a better looking game, but a game with much better (and more accurate) gameplay. And if it helps improve the gameplay, there's no way we're leaving it out!

Now, time to get coding again....

Google Ketchup and Hirst Arts moulds, first room test

First up, Google Sketchup is a great tool - once you've worked out the interface - for arranging Hirst Art castings into something resembling a playing surface. Simply enter "Hirst xx" where xx is the mould number you're looking to use, and the chances are it'll appear in the 3d model warehouse. At least, this worked for all the moulds we've currently got!

Some 3d models are drawn lifesize (i.e. a 3" pipe appears as a 3" object) and some are drawn life-sized (i.e. a 1" object is drawn as a 4ft object). Mixing and matching models isn't difficult though: if the stuff drawn in inches is imported into a drawing drawn in feet, simply scale up x48 and everything appears just fine.

Here's a final map for our first space-shooter-board game.
Unlike our spaceship-based game with shaped PCBs (which looked more like a Space Hulk type game) this map actually resembles a board-game-based version of our favourite ZX Spectrum strategy game, Laser Squad. We think this makes it all the more impressive!

(the pipes in this map were originally drawn as 1", 2" and 3" sections, whereas everything else on the map was drawn at 1"=4ft. Simply scaling the pipes by 48 put everything into the same scale)

We've spent a few evenings casting a number of blocks and wall pieces from our Hirst Arts moulds. The dental plaster gives a noticeably better (and harder) finish - even without having to "bake" the plaster in the sunshine for two days to remove all traces of water. In future we'll use dental plaster exclusively, but for now we've three boxes of the pesky things in plaster of Paris to use up!

After finally spending some time at the new unit in the Boiler Room studios, we spent a bit of time "dry fitting" some of these plaster shapes, to actually make the rooms, as terrain for our board game.

To begin with we copied and pasted each room section into a new Google Sketchup document and manually moved the pieces outwards from their starting poistions, to create an "exploded view". This not only helped identify which pieces were used in each room, but also helped us get familiar with which blocks made up which rooms, while making the exploded view images.

Putting the rooms together was just a case of finding the appropriate blocks, sanding them where necessary to make the scraped edges absolutely flat, and placing them in the right place on the table. Some of the pieces appear mis-aligned; this is just where the blocks have rested after being placed - when the rooms are made up properly and glued in place, all the walls line up perfectly to give a solid, continuous wall.

It was while we were fitting out the rooms like this that we discovered the true difference between plaster of Paris and our Witestone Ultrahard Orthodontic (type III) plaster - when sanding the plaster of Paris on some wet-and-dry super-fine paper, some - presumably slightly damp, even after three or four days - blocks created a creamy goop on the paper and edges of the block. The dental plaster, however, created a nice, dry, fine powder when sanded. All the more reason to stick to dental plaster in future!

Despite having what feels like millions of blocks, having cast each mould in full each time, we ran out of the "big vertical pipe" blocks after making up just two rooms. We've still got loads of little filler squares and other useless bits and pieces, but some blocks we're already short of.

Maybe the answer is to take the best-cast wall sections, and make our own silicone moulds from an 8-up or 10-up arrangement of blocks - so instead of casting one of each wall section with each cast, we can get 8 or 10 of just the blocks we need at a time. There's a litre bottle of liquid silicone and catalyst somewhere around here.....

Designing layouts for Hirst Arts moulds using Google Sketchup

Having spent a few evenings casting walls and doors for some sci-fi themed rooms, it was really hard not to go crazy and buy up more Hirst Arts moulds. So hard, in fact, that we now have mould numbers #301, #303, #320, #321, as well as the industrial edging mould #325.

The dental plaster turned up (about 10kg of the stuff - we had no idea what volume this was - it turns out, it's quite a lot!) so we've been busy casting more doors, walls, furniture, pipes, tank barrels, and a whole heap of other bits and bobs for making up some board game terrain.

Dental plaster is a great medium for casting these little blocks. Because it sets much harder than plaster of paris, and is much more resistant to chipping and damage, we can make up the gloopy mix just a little thinner than PoP. Using the "wet water" trick (spraying the moulds with window cleaner before starting) this thinner mixture helps reduce air bubbles in the casts. We've not yet got to the point where every cast is perfect, but a lot of our blocks are "good enough".

Just like using regular plaster of paris, we found that the dental plaster sets much harder, and takes on a slightly whiter appearance after a few hours "baking" in the sunshine.

Note the third and fourth blocks (from the left) are fresh out of the mould, and are slightly discoloured compared to the other pieces, which have had a full day drying out in the sunshine.

Thankfully we've had some really nice weather here at Nerd Towers, so the front garden has been filled with tray upon tray of plaster shapes, during the daytime, while they dry out.

We've now got a few boxes full of little shaped and pieces, so it's time to start fitting them all together. The first idea was to simply dry fit the shapes and see what looked nice.

The trouble with this approach is that the blocks are still quite fragile, and without gluing them together, they easily get knocked about and could get damaged if they were to fall over or drop on top of each other. What we needed was some way of making a "virtual dry fit" on the computer.

Incredibly, someone has spent a lot of time making Google Sketchup models for most of the Hirst Art moulds - at least, they have for the moulds we have got here. And the latest version of Ketchup (currently GS2014) has the model warehouse and extensions manager built right into it. So after downloading and installing the free version, it took no time at all to type "Hirst xxx" (where xxx is the mould number we have) and download a whole heap of ready-made 3d models for test-fitting.

We even downloaded a few 3d models of moulds we don't have, to help with the layout. For example, mould #270 is one for making floor blocks, for your tabletop terrain. Since we're going to be placing our models directly onto our electronic board game surface, and don't want to introduce any extra distance between the sensors and the playing pieces, we're not using these blocks - but the 3d models are useful for helping get everything lined up nicely.

Maybe we're just not used to the tools in Sketchup, but getting things to line up using the (rather crude) rotate and translate (move) tools can be quite tricky. Luckily, there's a number of extensions available, which allow you to align objects in your 3d drawing. We just searched the extension manager for "align" and installed the first one that came up - it works well enough and is easy enough to use to enable us to create a 6x8 grid from the 1" blocks in just a few minutes.

Getting useable models from the pieces of blocks was a little more involved, but after about an hour of wrestling with the Sketchup interface, we had a few wall sections ready to copy-and-paste into a board game layout. Here's an example of how the pieces from mould #301 fit together to make wall sections.

All this means we should be able to make up virtual examples of the room sections and extra industrial terrain for our spaceship-based game, without losing, breaking or damaging any of our recently cast pieces. The idea being, of course, that once we've dry-fit the pieces to make our board game sections, and got familiar with which pieces go where, actually constructing the real things should be that little bit easier!

Casting miniature terrain with Hirst Art moulds and Plaster of Paris

When I was about 8 years old, my sisters and I would cast characters from 70s kids shows in Plaster of Paris. Years later, after I'd left home and was struggling to make ends meet, I used to make chess sets from dental plaster, paint them up, and sell them to tourists through a local shop window. I never dreamt then that a lifetime later (yikes, it literally has been over a lifetime later) I'd be mixing up white gloopy gunk and pouring it into little rubber moulds again!

As work continues with our electronic board game, we're starting to think about adding terrain and feature to demonstrate what can really be done with this system - we're pretty fired up about it; maybe it will change the way people play tabletop board games - but first we need to show what's possible. And nothing gets people interested better than an amazing looking set-up.

In fact, that's what drew us at first to the Hirst Arts moulds.

They're not cheap. They require a lot of work (and a lot of multiple casting) and even when you get everything made up, it still needs painting, shading, highlighting and all that. But as miniature board game terrain it looks pretty impressive. And we want our electronic board game to look impressive too.

A lot of people use the "classic" Space Hulk style of board game layout, and moulds to go with it:

In fact, we did the same with our earlier versions of the electronic board game

Some nice industrial edging would finish those board sections off a treat! But then we decided to stick to the original design, and to make a generic, rectangular-section-based gaming system. Which meant that layouts like this...

would eventually need to look more like this:

However, there's something quite appealing about a board layout with no gaps. Somehow it looks more "complete" - more like a claustrophobic sci-fi/spaceship environment. And the photo above is very reminiscent of the early version of Laser Squad (the game upon which we tried to base our own shooting-in-a-spaceship board game Starship Raiders).

We clubbed together and bought a couple of moulds from the Hirst Arts UK reseller - we went for number #301 and #320. We also got some dental plaster off eBay but because the moulds arrived before the plaster, we went to a local art shop and bought some Plaster of Paris, just to try them out.

Making up the models turned out to be quite fun. It was like being nine years old, all over again!

After receiving the moulds, the powder inside them was washed out thoroughly with washing-up liquid and a good blast of hot water. The Plaster of Paris was mixed up to a thick batter-like consistency.

We placed the mould onto a newspaper on top of a "lap tray" (one of those things with a bean bag on the underside that stops your dinner sliding about on your knee while you eat in front of the telly!). While pouring the plaster into the mould, we banged the tray, to help release any air bubbles trapped in the plaster.

After about five minutes or so, the plaster started to go like a toothpaste consistency. At this point we were supposed to scrape the top of the moulds with a paint scraper or palette knife.

Unfortunately, we forgot this bit, and as soon as the plaster was poured, we went out for some dinner and forgot all about them!

A few hours later and the plaster had set (at least, set well enough for us to turn the pieces out). The pieces came out really easily. Simply flex the mould back and lift out where each piece starts to come free of the mould.

For a first casting, the results were OK. Well, ok-ish.
The detail from the moulds came out nicely on the pieces - even the tiny mesh pattern on a grate covering came out quite sharply. But every piece had air bubbles cast into it somewhere.

The instructions said that the quality improves after the first few castings, so it seems that we shouldn't expect our first set to be flawless after all. Also, given we forgot to scrape the top of the mould, none of the pieces sit together nicely - the bases (and sometimes the sides) are all uneven and would need a lot of work to make useable. We'll put this cast down to experience....

On the Hirst Arts US website, under "advanced techniques" (which we ignored, since we classed ourselves quite firmly as "beginner") it mentions "wet water". This is simply water with an additive which breaks the surface tension. We tried the test they demonstrated - firstly, placing a drop of water onto the back of one of the moulds.

The water stayed in a firm, rounded bubble shape.
So we coated the rubber mould with some water mixed with about a tablespoon or more full of dishwasher rinse aid (the stuff that supposedly stops your glass from going streaky). The result was quite noticeable

This time the water ran and dribbled everywhere, uncontrollably. It seems that wet water does make quite a difference to how a liquid performs in the silicone rubber moulds. So we turned the moulds over, filled with the "wet water" solution, eased out any bubbles that formed - using a small paintbrush - and tried again.

This time the results were noticeably better. Compare the two castings above (the first ones are on the left, the second castings on the right).

In this photo (above) the later casting is on the left. The second castings were much better. Not completely perfect - a few of the tiny details still had pin-prick sized holes - but at least gave us some useable pieces, at least good enough to try painting up.

The downside to Plaster of Paris is that it makes quite fragile pieces (dental plaster, apparently, makes much more robust casts) but also the rather "loose" mixture we made (roughly 50/50 water to plaster) means these casts are likely to take a day or two to dry out fully. While they're set hard enough to be taken out of the moulds, they still feel cold and clammy to touch. Which suggests that they wouldn't take paint very well just now.

Luckily we're coming into the start of summer here on the south coast - maybe a few hours in the baking hot sun will help get them ready to paint, sometime tomorrow?

Another Open Evening, another PCB design

Having successfully programmed the ATMega128 chip on the breakout board, it was time to get etching at BuildBrighton's Open Night again.

We've designed another PCB layout, complete with a 6-way programming header, to allow us to use our USBASP programmer and a connector with "pogo pins" to burn code to the ATMega128, even while it's soldered in place on the board. (the earlier design required the chip to be programmed before being soldered to the pcb)

Pogo pins are simply spring loaded pins, which mean you can push a pin header onto the board, and ensure that all pins are making contact with the pads equally. This is a much easier way to program a chip on a homebrew pcb, than trying to push all 64 legs down equally onto an etched board, and hope to get continuity long enough to dump code to the chip!

The first mistake (of many) was laser cutting the top layer for this new design. We're trying out round holes for the hall sensors, with a view to using die cutting rather than laser cutting for the final manufacture. Apparently round dies are much cheaper to make, and more long-lasting, than custom shapes - especially any with sharp corners. All the holes lined up perfectly with the components on the pcb....

The only thing was, we'd forgotten the hole for the mcu! The biggest, most prominent component on the board had nowhere to go. D'oh! A quick hack with a stanley blade and all was good (though pretty rough looking):

There is no hole for the ICSP header. We're not sure that this is necessary - after all, the chip will be programmed then this top layer added once the programmer has been removed. We'll be holding the programming header in place over the board - it's a temporary procedure and doesn't require any additional pins or anything soldering onto the board

Black fingernails can only mean one thing - we've been playing with ferric chloride again without wearing the latex safety gloves. Tut, tut.

Maybe we were just getting a bit impatient, but the board came out this time, less well etched than previously. Maybe it's just because we're using 0.3mm traces in places (whereas we prefer to stick to 0.5mm or above) that it seemed like a good idea to get the board out of the tank as quickly as possible! As a result, there were a few under-etched traces, that needed a good sharp knife taking to them

A bit rough-and-ready, but it least it now works. Some of the traces were also noticeably wobbly and bandly defined. Next time we'll definitely give it another minute or two, even if it looks to be completely etched!

With the chip soldered in place, it was time to test the board.
Nothing happened. We'd only gone and etched an older PCB layout, which we designed before we'd actually tested the programming of the chips on the breakout board. Double D'oh.

There is a degree of confusion amongst users online about which pins are actually used for programming the ATMega128. Usually the programmer is connected to the SPI MOSI and MISO lines (on most AVR chips). But on the ATMega128, the MOSO/MOSI lines on the programmer must be connected to the PDI/PDO pins on the chip (the SPI peripheral is on a different set of pins). However, the SCK (serial clock) and RESET pins are still used, as before. Unless you're using a programmer which supports PDI programming - in which case you need to use the PEN (program enable) pin instead.

Because of this confusion, we thought it best to actually test programming the chip before committing to a pcb design. And we did, and it worked, and everything was great. Then we went and etched a pcb which was designed for a PDI programmer, after successfully using ICSP to program the chip.

Bugger it an damnation. Our reset pin is sitting on the bottom row of pins, fourth from the left. Completely unconnected and not being used (the ATMega128 has a internal pull-up resistor on the reset pin, so it's not necessary to pull it high, externally). Pin1, the PEN pin is the top-most pin on the left hand side. We don't actually need this pin for ICSP programming.

A quick revision and we're ready to go again.
We've deliberately shortened the pin for pin1 (to stop it accidentally bridging the SCK line during soldering, as we're still making prototypes without solder resist) and flipped a few pins around on the ICSP header, to allow the reset pin to be brought up to the connections for the pogo pins.

For now we're going to physically snip pin1 off the pcb and tack a bit of wire from the reset pin to the ICSP header. That'll be a real test for the pogo pins, to see how uneven a board they can actually deal with. But, hopefully, with that done, we'll be able to squirt some code onto this chip, and then - rather gingerly - start adding some hall sensors to the rest of the board.

All being well, we're aiming for a full set of six board sections by the end of the weekend. Well, we can all dream!

Programming an ATMega128

We tried all kinds of ways to get the Arduino IDE to compile and program our ATMega128 chips that we'd so carefully soldered onto our breakout boards. Steve spent longer than could be reasonably expected, hammering away, determined to make progress. In fact, he got so far as to get Arduino 022 to compile some code for the ATMega - it just wouldn't upload via the USBTiny programmer

Wow. That's like a splash screen from the 90s or something!

While Steve refused to give up, I went down a slightly different route. Having recently discovered that the latest Oshonsoft AVR Simulator included support for both the ATMega128 and ATMega165, I threw together a simple blink test and compiled to a .hex file (which the compiler did a great job of creating, at a meagre 240 bytes in size!)

With the Oshonsoft compiler creating the hex file, we were both neck-and-neck: hex file built, just the programming to go. Steve spent a while messing about with the USBTiny config files, trying to add in support for the ATMega128 but the nearest he got to completion was an error message in the avr-gc executable - highlighting the character "h" at the beginning of an innocuous looking entry in the modified config file.

In the meantime, I was having problems of my own.

Despite always running my laptop in "disabled digital driver enforcement mode" there was something about the USBASP programmer that Windows 8.1 really doesn't like. I had to reboot the laptop twice; both times to disable digital signature signing, to enable the device to work. (there are plenty of links on the net about how to disable digital signing so there's no need to go into detail here - except to say that a lot of guides are out of date and that the location of different settings has changed under Windows 8.1 in the later updates; I spent ages only to discover that the settings I wanted were no longer under "general" but "restore pc")

Having finally got the usbasp device installed, it was time to stick some code onto the chip. Taking extra care to wire the programmer to the breakout board, I downloaded and installed a GUI front-end for the command-line programming tool avr-dude (called AVRDudess).

It's worth noting that for the ATMega128, the programming lines are on pins 2+3 (the PDI/PDO lines) and not the dedicated SPI MISO/MOSI lines as suggested by some sources. It's important to route the programmer to the PDI/PDO lines if you're building a programming header onto your project!

After selecting the programmer from the list, I hit "detect" and the software correctly identified the chip as an ATMega128. I hit "read" to get the current fuse settings from the device. Suddenly I was back in familiar territory - no longer was everything abstracted away and hidden behind cute menus in the Arduino IDE; this was programming the way I was used to - create a file, burn it to the chip. I could have been using Oshonsoft's PIC simulator/compiler and PICKit2, it felt so familiar!

Making sure the fuses are correctly set is a critical part of programming any device, whether an AVR chip or a PIC microcontroller. Luckily, there are a number of resources available online to generate the appropriate values for most AVR chips.

Programming the chip was super-fast; verifying the contents was really easy and after coding the chip, I changed the firmware and ran validate again (expecting, and getting, an error message to confirm that the programmer had actually put some data onto the chip). At first the board subbornly refused to run after being programmed. There was no real indication why....

...except on some forums, there was talk of the M103 flag.

A few people said to "look out" for it. A couple of people said "it always catches the newbies out" - but no-one actually said what it was, what it did, or how it affected programming (or running) the firmware on the chip.

By default the option was ticked. After checking and re-checking all the wiring, trying a different crystal to make sure it wasn't that, and burning different versions of the firmware to the chip, I tried unchecking the M103C option and burning the code again.

This time there was rapturous joy, as the little LED starting blinking away furiously (it was set to flash 10 times a second, after all!). So there we have it - we finally have a way of compiling code for and programming the ATMega128 chips, using a dedicated programmer (not the USBTiny and Arduino IDE combo). 

What's great is that it allows us to write the code using the Oshonsoft compiler, just as we do for our PIC projects. The software simulator is really very good - so should we need to use AVR chips on any future projects, we'll be able to code the project up, simulate all the components (external devices like character LCDs, stepper motors, I2C eeprom etc can all be simulated, and all the register values can be read by pausing code execution during the simulation) and make an entire working project, before having to solder a single wire!

Getting the usbasp programmer to work was a bit of a pain, but far easier than the job Steve had, negotiating and updating config files and settings files and reinstalling different, older, crusty versions of the Arduino IDE. And being able to throw some code together in Oshonsoft is a bonus; at last we can write code for AVR chips without having to go near the Arduino IDE! (and even if it's necessary in future, we can always use avr-dude and usbasp to drop a compiled .hex file onto a chip, without having to mess about with config files and go through the - ultimately unsuccessful - hassle that Steve did, trying to get a different programmer to work, or a non-supported chip to work with the usbtiny!)

Now we've got a working programmer, and have successfully identified which pins are necessary to program the chip, it's time for yet another pcb layout. The good news is, it's BuildBrighton's Nerd Night tomorrow evening, so we'll have an opportunity to etch yet another board - only this time, actually stick an mcu on it and try it out for real!

Breakout board for 64-pin QFN/QFP mcus like ATMega128 and ATMega165

Having got the ATMega165 and struggled to get it working with the Arduino IDE, we gave up and bought the ATMega128 and a dedicated programmer for it (not the USBTiny from Adafruit).

We've already designed our board game section(s) numerous times, using different 64-pin chips, in different pin pitches and with different pin assignments. And just when we thought we'd got it sorted, we found that the pins we'd broken out to an ICSP programming header simply wouldn't work with the ATMega128 (because that uses the PDI/PDO pins, not the MOSI/MISO pins for programming)

Before we actually commit chip to board, we thought it best to actually test the pinout for the ATMega chips we have here, so tonight quickly knocked up a breakout board for testing. In the building of this breakout board, we changed a few techniques for hand-soldering surface-mount parts.

QFN/QFP Breakout

Above is the PDF of the breakout board - as ever, if making one of these yourself, print at 100% (or actual size). Because we used the laser-etching method of creating our etch mask, the pdf isn't mirrored - however, because all we're doing it putting pins to edge connections, it doesn't matter a jot!

When hand-drilling 64 holes on a board, using a Dremel with a 0.8mm (extremely brittle) carbide bit, without a press or pillar drill, it's only a matter of time before one or more bits snap! Amazingly, we only broke one drill bit, drilling three breakout boards, each with 64 pins on: that's nearly 200 holes and only one drill bit snapped!

With the board drilled and the pads coated with rosin/flux, a quick snail-trail of solder paste is all that's needed. Unlike other smt boards, where we try to place the solder paste under the leg of the component being fixed down, we put the solder paste along the furthest edges of the component pads.

The reason for this is because our chips are quite large - certainly too large to hold in our little tweezers, so we're going to have to be a little bit ingenious with our placement here:

As we don't have a vacuum pen handy, the next best thing is a blob of blue tack (or, white-tack from the pound shop) which allows us to lift the entire chip in one go. The reason for placing the solder paste so far away from the legs is because any tiny movement from the chip, and the solder paste could get smeared about under the legs. Normally we don't worry too much about this kind of thing - just add plenty of flux and apply some heat and the excess burns away, leaving nice clean joints.

But because our traces for this chip are so fine (0.3mm) there's not much holding the copper to the board - we don't want to be exposing these tiny traces to too much heat for any longer than necessary.

By placing the solder paste around the outside of the legs (rather than under them) we're able to nudge the chip around on the board, until all four sides are perfectly aligned, and all 64 legs are sitting exactly on top of the centre of a pad beneath them.

With the chip held down and correctly aligned, simply solder one side of the chip - using the iron to firstly push the solder paste up the trace and onto the leg, then raking out any excess solder that may gather between the legs (breaking any bridges between the legs, as we normally do with our SMT soldering technique).

After repeating this process for all sides, we then tested every pin on the chip for continuity to the pad on the edge of the board. In our case, all the joins were good - there were no shorts between legs, and no broken traces or bad solder joints. Phew!

Next we need to solder on some pin header sockets, so that we can poke some wires in and connect the chip up to a breadboard (in much the same way people use an Arduino and a breadboard for simple prototyping).

Soldering 64 pins by hand can be a tedious job, and there's always one or two holes that are slightly off-centre (or, worse still, so badly placed as to break the trace from the pad). We had a couple of these on our board, but a technique in mind to fix them!

When soldering the pin headers onto the underside of the board, we made sure that iron was always on the inside of the board, with the solder being applied from off the board:

(right-handers will have the iron on the right, and solder coming in from the left, but with the board also to the left, or "underneath" the iron)

The idea behind this approach is that after applying the solder to the joint, if the trace is broken from the surrounding ring, it's possible to bridge the broken gap by simply dragging the iron from the outside of the board, following the trace, towards the chip in the middle. If there is a break in the trace, or the pad doesn't quite meet the trace, because of a badly placed hole, this technique almost always reconnects the pad back to the trace.

Here's the final breakout board, all soldered up

And on the underside, the rows of pin header sockets, ready to accept some solid-core wires to connect up to a breadboard, ready for prototyping.

On the underside of our board we marked where pin one starts, and the direction of numbering (when looking at a surface mount part from the underside, the numbering goes clockwise from the top right, rather than the usual anti-clockwise from top-left.

Soldering the AtMega128 onto our breakout board was actually a lot less difficult than we'd anticipated. In fact, so bouyed were we by the apparent success of this breakout board, that we put an ATMega165 onto another board, to give to Steve next time we meet - he's spent so long working on the Arduino IDE to get it, and the USBTiny programmer, working (after we gave up on hitting the first hurdle) it'd be a shame if he didn't get to try it all out!

Until then, we've an ATMega128 on a breakout board, ready to try to dump some code to, in the morning. Assuming we've got the pinout correct, for the external crystal and the programming pins, we'll be able to etch some more (hopefully final-design) board game sections and mount the ATMega128 chips onto them, for testing. 

It was tempting to just go for it and stick these chips straight onto the newly-designed board game pieces. But if there was a problem, we'd be none the wiser: at least taking an extra evening to build a breakout board, we'll be able to keep swapping pins and wires to get something working - something we couldn't do if we just went straight to pcb from here (however tempting that has been over the last couple of days!)