Well here it is, my first USB-driven device, all soldered up and ready to go.
In case you're wondering, it's a (USB-driven) relay switching device but also has the facility to receive switching instructions via serial communication (so it can be connected to a PC serial port or perhaps even a radio receiver).

Almost there - a few terminals to connect to the common and NO/NC switches on the relay, and some decoupling capacitors to keep the supply voltage from dipping, and I think we're done!

After quite a bit of discussion on a couple of electronics forums, and some help from electro-tech-online, I discovered a couple of interesting things about switching relays. First off, PIC microcontrollers aren't powerful enough to drive a relay coil - you need to use a transistor to provide power to the relay, and use the PIC signal to switch the transistor "on" and "off". Secondly, when using transistors like this, the switching should be done on the 0v side of the coil - not as I had originally done, on the 5v side of the coil. Because relays can generate back-emf when the coil is switched off, it is also necessary to include a "flyback diode" to stop reverse voltage spikes from frazzling the other components on the board, when the relay is no longer energised.

One of the most important things I learned was that I'm rubbish at soldering component parts, but not bad at soldering DIP holders and chips (with plenty of liquid flux thrown around the place). So for each relay that was to be switched, I eventually (after three/four different PCBs were made up and soldered - badly) discovered the ULN2803A chip, better known as a relay-driver. This includes the transistors and reverse diodes as part of the package so simply put, you can send a PIC signal to one pin and connect the relay contact directly to the other side - no need to mess about with any other component parts. This not only reduced the component count on the board (reducing cost to make!) but made the PCB layout quite a bit simpler - and the finished soldering look much, much neater!

Soldering the pins on IC chips is a doddle - quick and easy does it. Soldering little fiddly things like transistors and diodes can be a pain. Stick to IC (integrated circuit) blocks were possible!

Another important lesson was the difference between "sink" and "source" switching.
The ULN2803A can only sink voltage - i.e. it must be connected to the 0v rail - each of the relays is permanently connected to the 5V supply voltage and the relay-driver chip connects the relay coil to ground. It simply doesn't work the other way around: if it took 5V and switched it to drive the relays on and off, this would be "sourcing" and not "sinking" the voltage.

All in all, quite a lot learned. Most of it, to be honest, relearned: I'm sure I learned a lot of this in school, many years ago - but the old adage holds true - use it or lose it. I'm quite enjoying rediscovering things that at the time I thought were a waste of time and useless!

Following on from this, I think I'm shortly in for another whole world of hurt, after reading this post about switching 240v appliances. I know that my board needs A LOT more decoupling, but it's nice to hear the faint click-clack of the relays in response to a few bytes of data sent from the PC. Maybe I'm just a few days behind everyone else working on a similar idea....

A quick update with progress - the spanky new PCB etched a treat (I found out today that etching boards face down rather than face up takes about a tenth of the time - and if you heat the etching container in a bowl of warm water, the same way you use a bowl to melt chocolate, a full 100mm x 50mm board takes about four minutes to etch. 45 minutes is not normal etching time!)

I mounted the components onto it and soldered everything down.
It was the point of no return now - plugged the board into the USB on my PC and everything still works! It still detects the device as a native USB/HID device and I can enter a VID/PID combination and retrieve data from it. Brilliant.

But here's the weird bit.
I'd used a 470uF capacitor to tie Vusb to ground. Although this was using the wrong units, I assumed that there'd been a typo because on other sites and forums, 470nF was recommended.

Anyway, I bought some 470nF and some 470uF capacitors, as well as some 220nF caps (since some sources recommend 220nF capacitor for Vusb). The crazy bit is that the 220nF capacitor doesn't work: the device appears but Windows says that there's a fault with it. But if you use either a 470uF OR a 470nF capacitor to connect Vusb to ground, it gets detected as a valid USB device. Even though one capacitor is 1000 times the "size" of the other.

I still don't get it, but since 470nF works, and a lot of other sources recommend this value, that's what I'm going to stick with. I just don't understand why 470uF also works.....

After finally getting my native USB device working (yay, still pumped about that one) it was time to redesign the schematic and PCB layout for the proposed project: after all, there's no need for any nasty, fiddly FT232RL chips any more!

The bit of extra board space I gained from removing the FT232RL was quickly taken up by the longer PIC chip, and the additional crystal and capacitors. My board has outputs going to transistors (to amplify the current) so I can switch relays on and off.
Relays = coils = inductance, so I added some diodes to the board as well. All in all, it's getting a bit cramped on there, but with some clever re-routing (and only one "jumper" where I had to break a trace and pick it up elsewhere on the board) I managed to get everything in a 100mm x 50mm space.

I've had differing levels of success with the toner-transfer method of producing PCBs, but none of them 100% successful. Apparently it's all down to the paper type but I've tried four or five different photo papers and all of them leave broken tracks and need touching up afterwards.
Having invested in some Press-n-Peel (blue iron on paper) and reading mixed reviews (some people say it's no better than photo paper) and I pleased to report that it is the dog's doodies. There's no messing about, guessing at when your board is done. You don't need to have the iron on full heat and you certainly don't need to press and press and press for twenty minutes or more!

The image transferred perfectly, leaving a crisp, clean image on the copper board. The camera had problem focussing on the board because of the reflective surface, but the final image is much clearer than this!

Simply print onto the dull side of the paper, cut to size, clean the copper board and iron on as normal. As each of the tracks is transferred onto the copper, it turns a dark black colour on the top (the surface you're ironing over). So it's really easy to tell when the entire image has transferred. It's also easy to see which tracks need a bit more heat, so you can concentrate the iron in just the right places.
When you're done, a quick quench under the cold tap until the whole board is cool, then peel the plastic-coating backing off the board.

The image was beautiful and sharp. There were no broken traces and everything was just as it should be. The backing that came away was a perfect negative image of the board design.

The backing came away easily and was a perfect negative of the image transferred.

I'd read some reviews that said Press-n-Peel was just as hit and miss as other toner transfer methods. The one thing I know is that after tonight, there's no way I'm going back to messing about with scorched worktops and soaking paper for hours and hours: I'll happily pay £1.50 per sheet, knowing that from now on my boards will work first time, every time!

The final etched board.

Graham Wiseman from Shadow Robot came to Hove last night, to give a robot talk about robots. And very interesting it was too.

He demonstrated how someone can have an idea, make a series of decisions - in this case, to build a robotic hand using pneumatic pumps to replicate the action of human muscles - only to have each decision reversed, as practical applications are applied! Shadow Robot actually have two types of robotic hand - a pneumatic version (using patented muscle technology) and an electronic version (using motors).

The original idea was to replicate human muscle action, and the pneumatically-driven hand was built. But when third parties started to take an interest, alternatives had to be invented. For example, after getting interest from NASA about sending Robot Hand up into space, it was quickly realised that it's behaviour in a vacuum was unknown! (How would a pneumatically driven muscle operate in a vacuum?).
Instead of going for a hydraulic solution (potential for leakage and maintenance costs I suppose) Shadow built an electronic hand, with an array of tendons driven by 16 motors. Brilliant! That solves that problem. But it caused the project to deviate from the original idea of replicating human-muscular action, and demonstrates how practical applications can dilute even the most brilliant of ideas.
Then when the clever bods from the nuclear industry started sniffing about, they wanted something that could be used in hazardous environments - not something with exposed electronics and nasty sparky stuff. So it was back to the pneumatic hand to supply them with a solution.

It was a shame we couldn't see the hands powered up and actually working, but then again, not everywhere is kitted out with an industrial air compressor - the Werks certainly isn't!

The two hands were passed around and everyone got to push and pull the digits and make the tendons flex. Apparently the robot hands are just as (if not more so) dexterous as a real human hand. I still couldn't get one to hold a barre chord shape.
The weird rubbery surface was warm but clammy to touch - just as if someone had licked their entire hand before offering it to shake.
It was very good of Graham to let the rabble play about with his robots - especially considering that each one is worth £80,000-£100,000. And he also brought the original prototype with him - a fantastic wooden effort, covered in Polyfilla and operated with bits of string. Sellotape and blu-tack held things in place: it looked just like one of my own contraptions!

It must have been quite a scary train ride for Graham, coming from Islington to Brighton on the train, with about a quarter of a million pounds worth of hardware stuffed into his rucksack! Thanks for coming anyway!

After attending the Robot Brighton Shadow Robot Company Talk I had just a few minutes from getting home to retiring to bed (it was gone midnight after all!).
I'd asked around and managed to blag a 470nF capacitor from Kind Steve (and borrowed a PIC programmer from him, just in case mine was playing up: I still didn't know if it was burning hex files onto the 18F series of chips properly) and thought I'd shove it into my breadboard and see what happened.

As I pulled it from it's little plastic bag, I realised he'd given me a 470uF not a 470nF capacitor. It was a big black cylindrical thing, not the little round disk I'd been expecting.

I was about to call it all off and go to bed, when I decided that there'd be no harm in giving it a try anyway, what with him having taken the time to dig one out and bring it with him. So I did. And then plugged in the USB cable.

Nothing happened.
And then this came up:



Wahoo! I finally had a native USB device working!
And just to make sure, I ran the test app that came with the PIC 18 simlulator called hidterminal.
What is does is generate a random 8-byte string and send it to the device.
If you read through the sample code, you'll see that it decreases each value in each byte of the feature code by one, just before the data is sent back to the host (and increases the i/o report by one). From the screenshot below, you can actually see this in action:

The vendor ID was changed to 1221 just to see that a USB device with
any VID/PID combination would be recognised

And all this without having to use a different programmer.
It seems that mine does work with 18F chips, using DonkeyProg after all.
Here's the final schematic for anyone trying to get a native USB device working from a PIC18F2455 controller - don't skimp on any of the parts: they're all critical!



How exciting!
Tomorrow I might just lay out a PCB for it....

After several attempts of modifying code and getting nowhere, I followed the schematics on the Oshonsoft website exactly and copied and pasted the example code and burned it all to my 18F2455. I even included the 22pF capacitors across the crystal (not something I usually bother with) just to make sure that the code and hardware exactly matched the working setup.



The only thing I didn't have was a 470nF capacitor to connect the Vusb pin to ground. But then again, it's only a capacitor to ground: it's obviously not that important. Here's the schematic that I sent to Vladimir, author of Oshonsoft's Pic Simulator:



I sent the diagram to Vlad, pleading for help.
What could I have possibly done wrong? It all looks perfect and still my Windows PC can't detect the device (it recognises that something has been plugged in but keeps saying that there's been an error with the device)



I got this reply from Vladimir:

Please take a look at the schematics published on the web site.
There is one critical component missing on the schematics you sent
to me. It is 470n cap from Vusb pin to ground. According to the
datasheet it should be at least 220n value, and its presence is
critical. I hope that fixing this will lead to success!

Good luck and best regards,
Vladimir

I couldn't believe that something as insignificant as a tiny capacitor - which simply connects to ground - would cause the device to run, but not enumerate properly. I did some digging about on the 'net and came across this forum post; it's almost exactly the same problem I was having

http://www.picbasic.co.uk/forum/archive/index.php/t-3724.html

I re-read the datasheet for the 18F2455 and searched for "Vusb". There were references there to tying Vusb to D+ or D- and in a lot of the diagrams it showed Vusb connected to ground through a capacitor (but curiously no capacitance value is shown).
The datasheet does indeed mention 220nF but in his forum post, Robert says:

Robert Hedan - 6th July 2006, 17:14

Thanks to everyone!
I just received my order from DigiKey this morning. The 220pF caps didn't work, despite what the datasheet says. :( But the 470pF worked beautifully, man I'm happy I ordered a set of each, just in case. The device is recognized, YAHOO!!!

Robert
:D

I'm assuming that it's a typo in the forum post and that Robert actually meant 220nF and 470nF, as all other entries talk about nano- not pico- farad capacitors. Time will tell. So it looks like yet another trip to Maplins to try to find some 220nF/470nF capacitors.....

I bought my full licences for the Oshonsoft PIC18 simluator today and got the version that has USB support. I was a bit sceptical about spending about £70 on something that has a few questions hanging over it, and since yesterday morning have installed, tried and failed to get some code to compile in about four different compilers.
I really like the Oshon software and decided that, for the cost of a pre-build programmer and test board, it should take a lot of the pain out of USB development.
If the examples are anything to go by.
If they work....

I contacted Vladimir and he sent over the USB-enabled version in a few hours.
I compiled the examples from the Oshonsoft website and prepared the hex files for burning to my fancy new 18F2455 chip(s).

Then it all started to fall apart.
I've never had a ROM error before, nor an EEPROM error when writing to the microchip, but got both of those when trying to write to the 18F2455. I found an updated firmware for my programmer (it's a DIY 149-BC off eBay which is suspect might be a chinese clone, but as I bought it second-hand, I'm not sure where it came from). Anyway, for whatever reason, I couldn't get a the hex file onto the PIC18F.
I tried using fixhex2.exe (which comes bundled with the DIY programmer, v2.5) which apparentl is necessary for a lot of C-compiled code which has been targetted for the 18F series. No difference. I tried lots of different code from different sources, using different compilers.
To be honest, I didn't really know what I was doing, but as long as I managed to build a hex file with no errors (and correct fuse settings of course) I figured it should be good to go. But there was no way I could get the hex file to burn.

I lot of hunting around - it's taken two days in total - and I finally came across Donkey Prog which adds 18F support to the DIY programmers.
It even includes a special version of the software for USB-only programmers (which apparently are nothing short of a nightmare to use and write code for) which has special timing code or something which works with some DIY programmers.
Given that the alternative was to abandon the programmer I'd waited so long for, I decided to give it go.

The software didn't work straight away, but the archive zip came with a firmware update - so using my current app microbrn.exe to copy the dprog.hex file onto a blank 16F628A (phew, lucky I'd bought a few of those instead of the beefier 16F877A variants) I disconnected the programmer, whipped out the PIC that was onboard and replaced it with this new one.

Yay! The software recognised the programmer, dropped by sample hex file onto the 18F2455 chip and validated it a treat. I loaded a new file into Oshonsoft 18F simulator, a simple LED blink program, and burned this to the chip.
It worked a treat! So I now had a way of getting hex files onto my 18F2455 chip!

So just give me a couple of minutes and I'll have some USB up and running, surely...
...not quite so fast there cowboy.
As you can imagine, it was not to be - I took the example code from the Oshonsoft website (which Vladimir assures me works) compiled it and burned it to the 18F2455 chip. When you plug in the USB cable, the output LED comes on, the power LED comes on (so I know that the code is running on the chip and the board is getting 5v from the USB port) but Windows fails to recognise the device.
Not in a "ooooh nearly there" kind of way - when it says something like "Device not recognised". I got nothing. Zero. It didn't even bother to throw up an error.
I swapped the D+ and D- wires (that's a sure way to raise a USB error when working with the FT232RL usb-to-serial chip) and plugged it in again. Still nothing.

I suspect it's something simple, like a fuse setting, or an incorrect oscillator setting (or something equally as daft, like a watchdog timer reset, or the mclr not tied to 5v). But for now, it's off to bed again, still without a working USB-based device.
Here's hoping that tomorrow proves to be a little more fruitful.....

Yahoo! My 18F2455 chips arrived in the post this morning (8am can you believe?!)

And, ok, maybe they're not quite that sophisticated, with all the crying, walking stuff. To be honest, not one of them cries or walks or sleeps or talks. In fact not one of them does anything. Because I haven't programmed one yet.

The first thing I did was find out what type of settings I needed to use for the programmer and found that the internal oscillator for the 18F2455 needs to run at 6Mhz (or 48Mhz) if you're going to use USB. No problems so far - at least it has an internal oscillator. Then I read the spec for the USB port and it says:
"With PIC18F2455/2550/4455/4550 devices, the primary oscillator becomes part of the USB module and cannot be associated to any other clock source. Thus, the USB module must be clocked from the primary clock source; however, the microcontroller core and other peripherals can be separately clocked from the secondary or internal oscillators as before."

So whether you like it or not, you have to use an external crystal if you want to make use of the USB comms. The internal oscillator is either dedicated to the USB timing or the micro clock source - one or the other. Without USB, it is worth noting, that these chips have a wide range of internal oscillator values available - but if you're not using the USB comms, why use one of these chips and not some cheaper alternative??

Added into the mix is this statement:
"When the PIC18F4550 is used for USB connectivity, it must have either a 6 MHz or 48 MHz clock for USB operation, depending on whether Low-Speed or Full-Speed mode is being used....The USB clock for Low-Speed mode is derived from the primary oscillator chain and not directly from the PLL. It is divided by 4 to produce the actual 6 MHz clock. Because of this, the microcontroller can only use a clock frequency of 24 MHz when the USB module is active and the controller clock source is one of the primary oscillator modes (XT, HS or EC, with or without the PLL). This restriction does not apply if the microcontroller clock source is the secondary oscillator or internal oscillator block."
What does all that mean? I'm not too sure.
According to the USB look-up table, it is possible to use a 20Mhz crystal (these are the only ones currently in stock in Brighton's Maplins) as an external clock source and still have access to USB functionality. I think that a bit (or rather quite a lot) of trial and error will be needed here....

So I've now got a chip in my programmer, ready to try out the USB code from the Oshonsoft website (which incidentally behaves peculiarly in the simulator - it keeps jumping back to the start of the code after executing the UsbStart command) but have no way of testing it without YET ANOTHER trip to Maplins for a new crystal

Since I thought that making a PIC-based project would be a bit of a laugh and probably while away a few hours. However, it's been one nightmare after another (with long periods of waiting in-between). First off, getting hold of a PIC programmer proved a disaster. When I finally got one, I bought in a load of 16F628A chips (ok, four) and a usb-to-serial chip on a breakout board. Deciding that this would be too expensive to use for the hundreds of ideas I had bursting around inside my head, and that it wouldn't be too difficult a job to use the much cheaper (and smaller!) surface mount chips, I set about a circuit layout that allowed me to use these two reasonably-priced components together.
Then I found out I was rubbish as surface mount soldering.
But that might also have something to do with being unable to get a decent toner-transfer image, despite trying four different photo papers and even some hand-drawn traces with indelible marker pen.

I've heard good reports (and bad, funnily enough) about Press-n-Peel paper.
Given that I've not managed a single 100% successful image using the toner-transfer method, I thought I'd better give it a go.

But while I was waiting (again) I thought I'd investigate the how to actually implement real USB, using the 18F series of chips. And it looks quite feasible. So now, I've used my first sheet of Press-n-Peel (at a cost of about £2) and finally managed to make a PCB with no broken traces or fudged hand-drawn lines. It worked a treat! But I'm still rubbish at surface mount soldering and decided to bin the whole FT232RL chip idea.

So I now have a perfectly formed PCB, but the pin layout only works with components that I've since decided not to use.
Bugger.

Only a few more days before my 18F2455 chips arrive in the post and I can pretend that the last two weeks never happened, and maybe even get at least one circuit built before I go away on holiday (in August).

Right, let's get this straight. Implementing USB is tricky. It's full of crazy descriptors, end-points, reports and a whole host of weird stuff. Being a fan of Oshonsoft's PIC simulator already, it made sense (to me anyway) to investigate the PIC18 simulator.

I've already got some PIC18F2455 chips on order from RS Components which include built in USB support. And best of all, they cost just £4.60 each - less than the combined cost of a PIC16F628A (or a PIC16F877A) plus a USB-to-serial convertor chip, and there's no messy surface-mount soldering to worry about!

A quick read through the USB basics and a lucky Google hit that shows how to write your own applications with USB support and I think I've got all I need to get started (once the chips arrive I can put the theory into practice). And if you stick to HID-type devices, you can even create your own funky USB descriptors (so when you plug it into your computer it says something like "Found New Hardware - Crazy Dave's Crazy Thing" instead of some boring old "Found USB - serial virtual com port". You can even set your own VID (vendor ID) and PID (product ID) combinations, and write code specifically for your device (and not just send data to anything that happens to be plugged into a virtual COM port, hoping that it's your device on there!).
Here's what I've picked up so far...

PICBasic listing for microcontroller

Define CLOCK_FREQUENCY = 20
Define CONFIG1L = 0x24
Define CONFIG1H = 0x0c
Define CONFIG2L = 0x3e
Define CONFIG2H = 0x00
Define CONFIG3L = 0x00
Define CONFIG3H = 0x83
Define CONFIG4L = 0x80
Define CONFIG4H = 0x00
Define CONFIG5L = 0x0f
Define CONFIG5H = 0xc0
Define CONFIG6L = 0x0f
Define CONFIG6H = 0xe0
Define CONFIG7L = 0x0f
Define CONFIG7H = 0x40

UsbSetVendorId 0x1234
UsbSetProductId 0x1234
UsbSetVersionNumber 0x1122
UsbSetManufacturerString "OshonSoft.com"
UsbSetProductString "Generic USB HID Device"
UsbSetSerialNumberString "1111111111"
UsbOnIoInGosub usbonioin
UsbOnIoOutGosub usbonioout
UsbOnFtInGosub usbonftin
UsbOnFtOutGosub usbonftout

AllDigital
ADCON1 = 0x0e
TRISB = 0
PORTB = 0xff
UsbStart
PORTB = 0

Dim an0 As Byte

loop:
Adcin 0, an0
If an0 < 50 Then
PORTB = 0
UsbStop
While an0 < 100
Adcin 0, an0
Wend
PORTB = 0xff
UsbStart
PORTB = 0
Endif
UsbService
Goto loop
End

usbonftout:
Toggle PORTB.7
Return

usbonftin:
UsbFtBuffer(0) = UsbFtBuffer(0) - 1
UsbFtBuffer(1) = UsbFtBuffer(1) - 1
UsbFtBuffer(2) = UsbFtBuffer(2) - 1
UsbFtBuffer(3) = UsbFtBuffer(3) - 1
UsbFtBuffer(4) = UsbFtBuffer(4) - 1
UsbFtBuffer(5) = UsbFtBuffer(5) - 1
UsbFtBuffer(6) = UsbFtBuffer(6) - 1
UsbFtBuffer(7) = UsbFtBuffer(7) - 1
Return

usbonioout:
Toggle PORTB.6
Return

usbonioin:
UsbIoBuffer(0) = UsbIoBuffer(0) + 1
UsbIoBuffer(1) = UsbIoBuffer(1) + 1
UsbIoBuffer(2) = UsbIoBuffer(2) + 1
UsbIoBuffer(3) = UsbIoBuffer(3) + 1
UsbIoBuffer(4) = UsbIoBuffer(4) + 1
UsbIoBuffer(5) = UsbIoBuffer(5) + 1
UsbIoBuffer(6) = UsbIoBuffer(6) + 1
UsbIoBuffer(7) = UsbIoBuffer(7) + 1
Return

VB6 listing for desktop application (project, form, declarations):
http://www.nerdclub.co.uk/projects/USBPIC/usbhid.rar

The code above (from the Oshon site) doesn't make an awful lot of sense, until you see what's happening from the PC end - the VB code can be opened up in Notepad if you don't have Visual Basic/Studio on your computer.
But - as far as I understand without actually putting the code onto a chip and trying it for real - the Oshonsoft code takes away all the tricky (nasty) stuff like enumerating and responding to requests and gives you a couple of "events" to respond to. Although PICBasic isn't really event-driven, you can create a few GOSUB routines (remember them?) which are called when a USB event causes an interrupt to occur.

USB devices communicate with a PC (or other device) by putting a message into a queue. The host device periodically polls each device, asking if there are any messages from it to be processed. Similarly, when the PC sends a message to a USB device, the message is dropped into a buffer on the device.
This is a massive over-simplification but gives an idea about what is going on!

There are two buffers that can be used to send data back and forth - a feature buffer and an input-output buffer. Of the two, the io buffer is the one that is used to actually transfer data in and out of the device (stands to reason really when you think about the name!). The technique for transferring data, whether to using "feature reports" or "input reports" and "output reports" is the same:

With Oshonsoft's PIC18 Basic language, it seems that you must send data in 8-byte "chunks". On the PC side, you should populate an eight-byte array OutputReportData with data and then call the WriteReport routine. When received by the microcontroller, the USBIOBuffer is filled with these 8 bytes. Back on the PIC end of things, the USB interrupt causes the gosub routine usbonioout to be called. In the example above, it toggles a pin output/LED to show that data has been received.

The same buffer is read by the PC when the ReadReport routine is called.
Note that reading the device data is initiated by the PC, not the device. There is no way to "send" data to the PC from the device: the best you can hope for is to populate the USBIOBuffer array with your 8 bytes of data and wait for the PC to ask for them.
When the PC asks to read this buffer, the USB interrupt causes the gosub routine usbonioin to be called. In this example, each byte value held in the buffer is increased by one - so that, in this example, when the result of reading the device data is displayed on the screen, you can see the data has come from the PIC. Once the usbonioin routine ends, the contents of the buffer are sent to the PC and back at the PC, the array ReadBuffer is populated with the buffer contents.

In your PIC code, you should execute the USBService command as often as is reasonable, at it is while the USB commands are being "serviced" that the i/o interrupts are raised, that transfer the data in and out of your device. Apparently it can take multiple calls to USBService to completely transfer all of the data into/from the buffer.

That's basically it: the rest of your PIC code can get on with processing other inputs, setting output pins and so on. One of the first things to try out with the PIC18F2455 is a simple USB-to-serial alternative. Because it includes a USART interface, it should be quite simple to receive data from the USB port and re-send it down the serial data line. The obvious thing to look out for it timing issues: USB is much, much quicker than sending via serial, so some sort of basic handshaking will be needed. For example, as soon as each byte of data has been transmitted over the serial comms, you could set the appropriate byte to value zero. At the PC end, you could monitor the io buffer and when all bytes read zero, send another 8 bytes of data. This would mean that until all 8 bytes have been transmitted, the PC would do nothing (as the if-statement "are all buffer bytes zero?" would fail). As soon as all bytes have been sent (not quite as soon as, but when the PC next checks the buffer contents and finds them all zero) the PC could then send the next 8 bytes along.
This means no messing about with timing issues and synchronising USB and serial clocks. The only thing to look out for is if the data you are sending genuinely contains a sequence of 8 zero bytes - perhaps some rudimentary encoding could be used to ensure that this never happened?

Of course, all this is just theory, but it's sometimes handy to talk an idea through (and it gives me something to write about while I'm once again waiting for Mr Postman to pop an envelope full of electronic goodies through my letterbox!)

After spending (wasting) hours and hours (not to mention sheet after sheet of copper board) making up PCBs, and giving myself a sore nose from breathing in the etching fumes (it's toxic apparently) I've managed to create about half a dozen half-etched boards. Not wanting them to go to waste, I have been practising soldering the tiny FT232RL (USB-to-serial) chips onto them I've discovered a few things:

1. I'm rubbish at soldering
2. USB-to-serial is an expensive alternative to true USB

Erm, that's it.
So despite having a few FT232RL chips left over (I burned a few out and made a mangled solder-mess of a few) I think it's probably best if I stick to DIP/SDIP packages. So that means either spending £8 on a breakout board each time I want to add USB support to a PIC project, or to forget about the whole USB-to-serial fudge and actually spend some time learning how to create native USB devices.

So it's time to "grow up" and use the stuff that the big boys are playing with....

Still struggling on with toner-transfer PCBs (i.e. I still can't get a consistent finish!) so I decided to use the ruined boards to practice my drag soldering. Even with copious amounts of flux, I found that I was rubbish at it. All the pins got gummed up and I spent that much time applying, removing and re-applying the solder that I burned out some of the fine tracks.
So I reckon that messing about with these tiny FT232RL chips might just be more hassle that it's worth - so it's off to microchip.com to learn a bit more about their 18F range of chips, many of which include integrated USB. Apparently, using USB and creating a HID (human interface device) is not quite as daunting as other device types: so perhaps that's the way to go - cut out the USB-to-serial translator, send data to the micro via USB directly, then use the microchip itself and any onboard UART to send data on to other devices by serial comms.

It's a shame, because I've just spent about twenty quid on usb-to-serial chips and hours and hours building a PCB layout that could be re-used in other projects!

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.