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!)

Using an ATMega128 in place of an ATMega165

Since the code requirements for our board game project is really very simple, the actual type of mcu used doesn't really matter than much. We went with the ATMega165 simply because it had 64 pins, 53 i/o lines and, according to the intertubes, could be programmed via the Arduino IDE.

As it turns out, it can't, without a lot of buggeration.
And to add insult to injury, after designing a simple test programmer board, it doesn't use the MISO/MOSI lines for programming, but the PDI/PDO lines.

So we've got some chips we can't compile code for through Arduino (but did get some code up and running quite quickly using Atmel Studio 6) and even when we do, they're a pig to burn the code onto (a lot of programmers, including our USBTiny don't support the ATMega165 by default).

On a completely unrelated note (at the time) an email arrived this morning, from Vlad - the author of Oshonsoft PIC simulator.

It was a thank you note for supporting the project (we have licences for the entire range of Oshonsoft products) and a note to say that there were some updates in the pipeline. And then we got to thinking.....

Many years ago, we worked on a project called Shoeduino.
This was an Arduino-based shoe-shaking project, that used an AVR328; at the time we actually wrote the code for it using the Oshonsoft AVR simulator rather than the Arduino IDE. The code was dumped onto the chip using a USBTiny programmer and no bootloader - the whole project worked perfectly, without even having to invoke the Arduino IDE. Perhaps there's another way.....

It turns out that the AVR Simulator supports the ATMega128 chip (though there's no sign of the ATMega165 chips we went and bought the other day!) and a super-cheap programmer off eBay supports programming of the ATMega128.

So the new chips are on order from Farnell (they're quite pricey, at about £4 each, but can be sourced much more cheaply in bulk) and the programmer is awaiting delivery. The code has been cranked out in Oshonsoft AVR simulator, so all that we need to do now is design a breakout board for the ATMega128 to make sure we put the programming pins in the correct places this time!

As Steve said the other day, we'd hate to see the spreadsheet for the bill of materials for the development of this board game idea! Maybe it's time to start putting some of these over-ordered parts back on eBay!

PCB layout for ATMega165 for electronic board game

Having designed a number of PCBs for different 64-pin chips, it was with some relief that we printed our latest design onto paper and got a perfect alignment with an ATMega165 chip

Of course, Thursday night is BuildBrighton night, so it didn't take long to get a etched PCB cranked out

Thankfully, the pins and pads lined up just as they did on the printed version (proving that the BuildBrighton laser cutter is, indeed, etching at 100% scale - not 99% or 101%, but bang on actual size!)

With the board etched we needed a way to program the chip before soldering it onto the board (because there wasn't room to add in ICSP headers on the actual PCB).


We decided to make an ICSP programmer using the same pins and pinouts as the ICSP header on a standard Arduino board.

To keep the chance of shorts to a minimum and to aid aligning the chip on the programmer, we took away a lot of the copper away from around the 64 pins.

Because the chip will be placed on the copper-side of the board, we had to solder the through-hole components on the "wrong side" of the board, so that the whole board can be placed on the tabletop without tipping or moving around (some self-adhesive cork on the back helps with this)

However, despite advice to the contrary, we haven't yet been able to compile even the simplest blinky-test project for our ATMega165 chips.

No matter how much we mess about with the boards.txt file, taking unused "boards" (chips) out of the list, and adding in our own descriptors, we simply can't get the ATMega165 to appear in the list of available boards

The nearest we got was to add in a zipped file of arduino-extras and ATMega165 appeared in the list - but trying to compile anything outside of the "standard" chips provided with the Arduino IDE resulted in a compile error and linker messages saying that numerous files could not be found.

Once again the curse of Arduino seems to have struck.
Just like using someone else's library of code, when it works, it works really well.
But when there's a problem, there are a hundred or more posts online describing similar symptoms, and a noticeable lack of solutions.

Steve spent a lot of time playing around and eventually found that an earlier version of the IDE would successfully compile (but was unable to actually upload) some code for the ATMega165. The current version of the Arduino IDE is 1.5 and Steve managed to get version 0.22 to compile code for the 64-pin chips. In the meantime,  I spent some time getting familiar with Atmel's official Atmel Studio 6.

Personally, I think that any desktop application built using .NET belies this by performing incredibly badly. And Atmel Studio is no exception. It's based on the .NET version of Visual Studio. The IDE takes an age to boot up, screen refreshing is slow and it feels worse than an open source app running in a virtual Java machine (cough, Open Office, Inkscrape, cough, GIMP, splutter). It's not a nice experience.

On the plus side, using nothing more than a bit of intuition, I managed to get some code compiling correctly in Atmel Studio 6 in very little time at all.

I spent some time writing my own Oshonsoft-a-like macros, for enabling and reading individual pins on a port - and found I'd recreated something very similar to the bit-level manipulations here: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=318198#318198

/*
* bit_functions.h
*
* Created: 30/05/2014 22:05:05
* Author: CHolden
*/

#ifndef BITFUNCTIONS_H_
#define BITFUNCTIONS_H_

#define LOW 0
#define HIGH 1

#define INPUT(port,pin) DDR ## port &= ~(1<<pin)
#define OUTPUT(port,pin) DDR ## port |= (1<<pin)
#define CLEAR(port,pin) PORT ## port &= ~(1<<pin)
#define LOW(port,pin) PORT ## port &= ~(1<<pin)
#define SET(port,pin) PORT ## port |= (1<<pin)
#define HIGH(port,pin) PORT ## port |= (1<<pin)
#define TOGGLE(port,pin) PORT ## port ^= (1<<pin)
#define READ(port,pin) (PIN ## port & (1<<pin))

#endif /* BITFUNCTIONS_H_ */

This allows functions to be used like:

HIGH (B, 4);

to set bit four of PORTB.
Similarly, we can use LOW(C,3) to turn a pin off, and even TOGGLE(A,2) to flip the state of bit two on PORTA.

Of course we could just use bitmasking and write values directly to the PORT values, but somehow, setting and unsetting individual pins just makes the code more readable!

So now we've got a programming board soldered up, and an IDE that can actually compile some code for our ATMega165 chips. We're two-out-of-three steps along the way already: the last step is to get the .hex file from the PC onto the AVR chip via our USBTiny.

Maybe the Arduino IDE doesn't want to play nice. And maybe the Atmel Studio doesn't support USBTiny straight out of the box. But there's always a chance that AVRDude and a few command line parameters might just do the job......

Yes it does

No sooner had I hit "publish" on the last blog post, than a UPS courier knocked on the front door at Nerd Towers. He had with him a massive box.

Considering I'd only bought a few things from Farnell, I presumed there'd been some mistake, or some bizarre doubling-up on an order. After all, I hadn't ordered that much. And I'd only just asked "does it get more ridiculous than this?"

The answer, it seems, is yes.

I tore into the box to see what was in it, before taking the photos. So closed it up to show what had just arrived:

Once more, half a pound of paper stuffed into a box, with a large silver envelope at the bottom. Containing a tray with some chips in it.

Inside the tray were....

6 x atmega165 chips. The fifty pence piece is to show the size of the components sent. These could easily have been fit inside an A5 envelope and sent in the regular post (after all, the label on the box says it was sent via Royal Mail, yet it still arrived via a UPS courier). Farnell do send stuff in envelopes, in the post, mostly. So I really don't understand why I've now got two massive, empty boxes and literally less than a handful of components, which fit in less than one half of one hand!

Farnell packaging - does it get more ridiculous than this?

It's almost a year ago to the day that we noticed Farnell doing something crazy with their postal packaging. Namely going right over the top with it! The other day, in a fit of haste, I ordered some XMega chips and a pcb for programming them.

The PCB is smaller than a credit card and the chips are smaller than a penny piece. They're 10mm square. This is the box that arrived yesterday:

While I appreciate that the box containing the pcb is much larger than the pcb itself, I'm pretty sure all this extra packaging could be removed and a smaller box/envelope used...

The box felt pretty weighty for 4 QFN chips and a small PCB. Inside was....

... a whole heap of padding. And a large silver envelope in the corner. Which contained...

Contents measuring less than the size of a eurocard copper board (160x100mm). And suppliers can send 20 or more of those at a time, in the post, in a padded envelope. What's with all the packaging Farnell? Do you have reams of brown paper and a stack of boxes you need to get rid of?