I received 5 x FT232RL chips in the post today from RS (cost £2.40 each instead of the £8.00 I paid for one on a breakout board). I carefully positioned one onto my not-so-brilliantly etched board and got the pads to line up as best I could. And wouldn't you just know it, I made the spacing between the pads too narrow! With the tiny chip in the correct place, no part of any of the pads are visible! How can I use my brilliant (but yet-to-be-tried) drag soldering technique if I can't see the pads I'm soldering too??

With the chip on the board, not all traces can be soldered. Pins 1, 4, 5 and 7 on the left-hand edge of the board are the only ones actually used, but the traces to pins 5 and 7 are obscured making soldering impossible. The penny is shown to indicate how small the FT232RL chip really is!

It looks like another etching will be necessary - this time with the surface mount pads a little bit wider. I also think that next time I'll only etch the pads that are actually used for the chip, instead of having loads of blank pads with no traces on them. Not only will it make the image transfer easier, it should also make soldering a bit simpler too. More details will be posted here soon....

It took four attempts and lots of cleaning and scrubbing of the copper board (after each one failed) and I managed to ruin a wooden cutting board, using it as a heat proof mat (d'oh!) but finally here it is: one complete (almost) etched PCB board.



It's a bit ropey on some of the traces, and some of the pads do look very close together, but all in all, a success! Mostly.
A couple of tracks broke before I got to the etching stage but I figured that they could be patched up with some silver paint. On the very left-hand edge and right-hand edges of the board you can see a couple of tracks that are incomplete: this is probably due to not putting enough pressure on the board at the edges while transferring the image onto the copper board.

By far the most difficult part was transferring the PCB image onto the copper.
It took a few attempts trying to work out which way around (mirrored or not) the image needed to be - in the end I printed the PCB layout without flipping it. The process of transferring it onto the copper resulted in a mirrored layout. But considering that the components will be mounted onto the top (i.e. non-track) side of the board, this worked out just right. So if you're trying this at home, there's no need to mirror your PCB layout (if you're mounting your components onto the same side as the tracks, then you do need to mirror the PCB image before printing it).

The PCB layout was printed onto single-sided Kodak Photo paper on a Xerox Phaser Laser printer. After printing, I split the photo paper, removing the thick "backing" from the shiny part of the paper. For the first few tries, I ironed the image onto the board, pressing and moving for about ten minutes. After allowing to cool, I peeled the image off and the tracks around each edge of the board came away too. I also tried baking the board in a hot oven for ten minutes (with a stone quiche dish to add pressure during "cooking") after ironing, but had the same problem when it came to peeling the paper away.
On the fourth (and already I'd decided last) attempt I spent a good fifteen minutes applying pressure with the iron. I then moved the iron around, and then smoothed over the entire surface using just the very tip of the iron. The paper looked scorched and the tracks started showing through. I soaked the whole lot in cold water and left for half an hour, before rubbing and peeling the paper away from the copper.
Even so, at this point, a couple of tracks broke away (they obivously hadn't fused properly onto the copper) and I had to use a craft knife to remove some of the more stubborn bits of paper.

The etching solution from Maplin was a white powder which dissolved in warm water. Unlike other corrosives, which appear brown and stain everything yellow, this was clear and after the copper board was put into it, started to turn blue.
It took about 15-20 minutes for all the copper to be completely removed from the board, then I left it a little longer, as I had some quite fiddly bits and I wanted to be sure that all the unwanted copper was removed.

The moment of truth came when the board was rinsed then rubbed with a light sanding block, to remove the black toner (and leftover bits of paper). The end result - as you can see above - was not exactly perfect, but with a bit of work, should prove a suitable board for my next project.

The blog posts seem to be getting less and less frequent, although this is probably due to stuff actually being done now, and not just written about. Since the arrival of my PIC programmer, no end of ideas have been tried out on the little breadboard/prototyping board. But for one idea, it's time to think about going into production. It doesn't matter whether you're building a robot (cool) or an automated garden-watering system (not so cool, but useful) there comes a time where you need to think about how to put the idea into practice, in a real-world environment. And that means building a PCB.
You can use so-called vero-board (copper strip board) but really this stuff is only one step up from a breadboard prototype and is not really "production quality".

Using the FREE software from Express PCB I put together a schematic, linked it to a PCB and started doodling. After a few hours, I managed to get all my pins connected (the PCB software highlights which pins need joining up as you click on them) with no crossed wires (very important that) and not too many long, snaking traces roaming around the board.

The next step is to get the design off the PC and onto a PCB.
I did think about simply printing the design and tracing over each of the traces in a conductive silver pen (available from Maplin but at a hefty £25). In fact, I even tried out a micro-tipped pen, but the lines it drew were much thicker than I could use, so that idea very quickly got kicked into touch. If you're thinking along similar lines, don't waste your own hard-earned on such a folly: silver pens are for touching up broken contacts (and even then I'm not sure how much use they'd be on a PCB circuit) and are no good for drawing your own layout.

My current method of production (yet to be tested fully but results will be written up here) is the laser-toner-copper-board-etching method as described in many videos on Youtube. I've no idea how the final board will end up, but what I do know already is that my trace layout (above, right) actually looks pretty impressive, whether it works or not!

I learned a very important lesson while getting back into my PIC programming. And that is to never overlook the basics! I'm already onto about my fourth project (but only having one PIC and one breadboard, I put an idea together then as soon as it's working, rip it all apart again). Each time I've been caught out with the fuse settings on the chip - supposedly the very first thing to check when putting an application together.

Most PIC microcontrollers have a clever little thing called a watchdog timer.
It's basically like a time bomb which, when it goes off, resets your PIC.
If you don't know to look out for the watchdog timer, it can make a working project look like a duffer - the PIC looks like it's dead (when in actual fact, it's resetting itself every few hundred microseconds).

The idea behind the watchdog timer is that it counts to a number, using an independent oscillator to your main program. When it gets to that number, it resets your microcontroller and starts counting again!
What's the point in that? Well, if you write some dodgy code, or you're expecting a response from another device that has died, get stuck in an endless loop, or perhaps are just working in a noisy environment* - there are loads of reasons why - you might want the PIC to abort whatever it's doing and start again. Hence the need for a watchdog timer.

The thing to remember is that at frequent intervals in your code (exactly how often depends on the frequency of your main oscillator) you need to reset the watchdog timer. Just every now and again, pepper your code with CLRWDT (clear watchdog) instructions.
Or you could just do what most hobbyist coders do and disable it!

*working in a noisy environment as in putting components onto an electrically noisy board, with lots of power rails and switching power supplies, not you sitting in an office with Radio2 playing too loudly

Like Dr Frankenstein on a stormy night, tonight I looked over my very own living breathing monster creation. Well, that's a bit over the top, granted, but it's been such a long time coming, that's how it felt when a few LEDs finally flickered into life this evening!
Following the arrival (finally) of a PIC programmer (although not the one I'd originally ordered) I couldn't wait to try out the whole host of applications I'd been coding and testing in the PIC simulator.

Disappointing didn't cover it.
Nothing. Zilch. Nought. Nada.
Each and every bit of code I tried resulted in a blank, no lights, no response to inputs, nothing to even suggest that the PIC microcontroller was running at all! So another frustrating few hours ensued, with the code snippets getting smaller and simpler, until even a simple routine which said "turn the pins to outputs, turn on pin 1, repeat" failed to produce even a flicker.

A trawl through the datasheet turned up something that I'd overlooked - and had resulted in the PIC forever resetting itself, giving the impression that nothing was happening - the set-up "fuses".
After disabling a couple of reset parameters, the first LED winked into life!
A bit of poking about in the code and re-programming the chip a few dozen times, and suddenly it was working! Working exactly as it had been programmed to. It didn't really do much, but what it did, it did perfectly - every time!
Check out the project page and forum discussion for more details and pictures!

It's been a bit like Groundhog Day in Nerd Towers this week, each morning getting up, checking the post, no PIC programmer, sinking into a malaise of misery, getting up, checking the post.... you get the idea.
Well, it's finally arrived! So it's down to business.
First off is getting the USB-to-serial connection working, but already I'm looking towards using the 18F range of PIC microcontrollers which have built-in USB support. For now, the FTDI chip is working a treat and LEDs are flashing perfectly in line with the serial data that's being squirted down the wire.
Send it a letter "A" and the 1st and 7th LEDs light up a treat.
The letter "J" and the 7th, 4th and 2nd LEDs glow in all their glory.
Beautiful.

For the non-binary literate, here's what happens:
The character received by the serial port is sent as a single byte.
Each character has it's own byte (ascii) code. "A" is 64, "J" is 74 for example.
So when "J" is sent, the PIC micro receives the number 74.
The number 74 represented in binary is 01001010
The LEDs are wired to the output PORTA of the PIC micro so that when the number 74 is sent to the outputs, the 7th, 4th and 2nd pins are "high" and the corresponding LEDs light up.

For a quick lesson in binary, see the forum post here.

On the face of it, a two wheeled device will be nice and simple to get working, a three-wheeled device would look cool and a four-wheeled device would be expensive! So the idea (for today at least) is to build a two-wheeled robot, which could then, by simply changing the wheel types, become a four-wheeled robot (with omniwheels). This means that the design can be kept simple, the robot will be able to move (forwards/backwards) by driving both wheels in the same direction and turn by driving them in opposite directions. The introduction of a second set of wheels, at 90 degrees to the first pair simply provides the robot with the ability to "strafe" or move in any direction without turning.

So there we go - look out for a simple two-wheeled 'bot in the projects page. Photos and development details will be posted here as it goes along.