Sunday, 31 July 2016

Unity fonts PC vs mobile

Unity is a great, cross-platform development environment. Ok, it uses crappy C# and Monodevelop (which, despite it's problems, knocks crappy Visual Studio into a cocked hat!). But it's pretty good.

The 3d engine is great, the built-in physics work well, and the asset store is a god-send for us non-artistic coders who are used to placing blocks, cubes and pyramids as place holders in our games and never really progressing from there.

But Unity is also a bit buggy.
Sometimes it just craps out and closes. Sometimes Monodevelop just throws up a runtime error and wipes out your latest code changes. But these things are few and far between (unless you're working with a particularly badly written asset-store script).

And we've got a particularly quirky bug in our latest game/app for our electronic board game. It's all the more frustrating because it only appears after compiling and deploying onto a mobile device. On the PC, and in the runtime/test environment, everything works as it should. But on our mobile device, something as simple as changing a textbox is causing no end of headaches.


(in the editor, click the boxes in the bottom left, and the character successfully changes and the character name and weapon text changes as it should)

[image]

(on the mobile device, each time the text is updated, the previous entry looks like it remains on screen, creating a white blobby mess instead of clear, easy-to-read text)

Also we're struggling to understand how lighting works - particularly baked lighting and optimising for mobile. The first time we baked the lights for this demo scene, the bitmaps for the textures were updated and had an amazing, realistic looking set of shadows on them. But every subsequent compile rendered the entire scene as black (as if no lights were present in the scene).

The only way we've managed to make our characters visible again is by using an unlit shader to render the scene.

Is this another bug? Or just a fundamental lack of understanding of Unity?
Or both?



Friday, 29 July 2016

Troubleshooting WTV020-SD-16P and arduino

Today was quite a trial, getting our .ad4 files playing consistently well on a WTV020-SD-16P module with an Arduino. We'd had this running for a few weeks, and all appeared to be well. But today, after we put some different .wav files onto the SD card, and tried running it from a usb-based device, things started to go awry.

It's not that the sound files wouldn't play - they did. But quite often they would "clip" during playing; so after a second or two of sound, the audio would stop, but the module would remain in a "busy" state, and refuse to play any more sound files. The problem was particularly noticeable if we interrupted one file that was already playing and tried to play a second file.

Unfortunately, there were a lot of changes between the module we had working (running off an Arduino Pro Micro at 3.7v with a lipo battery) and the one that gave us so much trouble today (an Arduino Pro Mini, off a changeable 3.3v/5v laptop usb supply).


  • We were using a different SD card - although both were branded Sandisk, it's quite possible that one, neither or both actually were! The working sd card was 2Gb, the non-working one was 1Gb.
  • We were using a different power supply - the working module was powered off a 3.7 lipo, the non-working one was problematic at both 5v and 3.3v
  • We were using different sound files - though even when we copied the .ad4 files off the working sd card onto the non-working one, the problem remained.


Clipping has already been identified as a possible problem with these modules.
Because the module uses the data instruction 0xFFFF to stop the audio playing and values 0xFFF0-0xFFF7 to change the volume, any clipping in the audio data might accidentally fire the "stop" command



So we made sure that all our sound files had no clipping in them. But the problem remained.
We tried copying the working .ad4 files onto the non-working sd card - but the problem remained.
We tried powering the non-working device off a lipo battery - but the problem remained.

We tried playing each sound file in it's entirety, instead of interrupting the file and trying to play a different one, mid-way through. Success was more frequent. But every now and again the module would "lock up" and get stuck in the busy state.

It was starting to look like we had two identical-looking modules, potentially with different firmware versions handling how the audio data is read and played back off the SD card. And that's when Steve had a bit of a breakthrough - a full, complete, FAT-format of the card, then copy the files onto the disk in one go (instead of copying them one-at-a-time).

When we did this, the audio playback worked as expected.

The more we pondered why this was, the more we were reminded of when we created our own audio module a few years back. Parsing FAT tables was quite arduous. And most of the time, a file was written to disk using consecutive sectors. So when the file was written to a blank, virgin disk, it would be written onto sector one, then two, then three etc.

We spent quite a bit of time making our playback routines work with a FAT-based file system. It was tempting at the time to simply find the start of the file and assume that is was written on consecutive sectors - it would have saved a lot of messing about every 512 bytes! But while we went out on a limb to ensure that our playback routines would work with files anywhere on the disk, it appears that the WTV020-SD modules don't....

So if you've copied files onto your sd card and then deleted them (in doing so, the 8.3 file format name is simply prefixed with a ? character) then it's quite possible that any subsequent file might get written to sectors one, two, then nine,  forty-seven etc. The FAT table does the job of bringing all the file fragments together.

But if your playback routine assumes that the file continues on consecutive sectors, it's easy to see why playback would fail. And it would also explain why the WTV020 module doesn't like playing back files that have been copied onto a disk after other files have been deleted off or moved around on it.

So, in short, to get your sound modules to work consistently well, always format the SD card fully before copying your files to it. Not a "quick format" (we tried that, it didn't work, since quite format simply blanks down the FAT table but leaves the data still written on the sectors). But a full, slow, 3-4 minutes to blank a 1Gb disk type format.

Do that and everything should be golden!


Thursday, 21 July 2016

Arduino Pro Mini - it's ok as it is

Sometimes, making custom PCBs can be quite fun. There still remains - even after all these years - that little tingle of a thrill when you boot up your custom circuit board and everything works.

It's like committing to your idea. Once etched in copper, there's no going back and changing it (although given the number of times we've forgotten to add a ground plane, it is easy to tack on a wire or two to correct a couple of mistakes!),

I still love making PCBs (at least, I do, when they work). But that's only for one-offs or small volume prototypes. The idea of having to make 100 identical circuit boards leaves me cold.

Which is probably what Tony was thinking when he asked why, for our latest board-game-controller-idea, we'd stuck a "hulking great big atmega" onto a board and simply extended all of the i/o lines to the edges.


But that's all we actually need - we're multiplexing an array of hall sensors, and sending the data out to a bus-connected serial port. That's all there is to the board! Size is important, so we made the board as small as we could. But not everyone is a whizz with hand-soldering surface mount parts, so we used the large, through hole components.

So he asked "why are you making your own boards? Why aren't you using an Arduino Pro Mini?"


And we couldn't think of a single good reason.
Although not everyone may be comfortable hand-soldering surface mount parts, there are more people comfortable with ebay than a soldering iron - so why not just buy the boards, ready-made?

It seemed like such a dumb question. Which made our current approach look even more stupid! So that's what we're doing - not only going open source, but using off-the-shelf parts. Steve would be so proud!

Tuesday, 19 July 2016

Inkscape to draw PCBs

Of course, drawing PCBs with Inkscape is an utterly ridiculous idea. After all, that's what ExpressPCB is for, right?

Well, 99.9% of the time, we'd agree with that. ExpressPCB is indeed a brilliant bit of PCB design/layout software. It encourages you to lay things out in a nice, neat grid, with perfectly perpendicular lines and 45 degree elbows on all your joins. It's great for making professional-looking boards with 90 and 45 degree angles.

But for this one particular project, that's a bit of  a restriction.
We're looking to put 12 hall sensors around a ring. Which means we want to space them at 30 degree intervals. And ExpressPCB doesn't like rotating anything that isn't 90 (or 180) degrees. So we had to try something else.

Which is where Inkscrape came in.
Using ExpressPCB to get the dimensions of our components the right size, I "printed" the document to a PDF document (using the excellent CutePDF virtual printer) and imported that into Inkscape. From there, I could add and embellish as much as I liked to get the final PCB design!


And suddenly, without the constraints of 45 degrees, the artwork started to get a little bit more... well, arty. I think I've been hanging around artists and designers too long this month!

Monday, 18 July 2016

Through hole as surface mount components

We love surface mount components at Nerd Club. Not just because they're tiny (although miniaturising designs to as small an area as possible is quite fun sometimes too) but because they eliminate the need for all that fussy drilling.

Putting a 1mm hole in the centre of a 2mm pad is straight-forward enough. But if you're soldering up a 40-pin DIP and a number of wire-pads for socket connectors then all that drilling can make your eyes go funny! Surface mount components mean far fewer holes, which means more time making cool stuff and less time hunched over a dremel drill.

We've already come up with a number of designs for our electronic board game, using surface mount components. But, going down the open source route, we're also acutely aware that not everyone is as confident at soldering, or has the same degree of practice we have, with soldering tiny little surface mount parts.


Coupled with the extra difficulty when soldering to homebrew boards (there's no solder resist to ensure it only goes where you want it, so bridging tracks is quite easy to do) we thought about how best to make the controller PCBs as simple as possible to solder.

Now it seems like through-hole is obviously the way forward; everyone with a soldering iron has probably soldered through-hole components in the past. But that then means that our PCBs would have a load of components on the top, and a whole load of little spiky bits on the bottom - neither surface would be completely flat (which would be preferable, so you can stick the flat part of the board to be flush with the bottom of the playing surface).

Through-hole components are larger, and therefore easier to solder. So we came up with (yet another) compromise: use through-hole components (for their larger size) but treat them as if they are surface mount components.


So the components go on the "copper side" of the PCB, but have much larger pads and legs, for the homebrew hobbyist to have a go at soldering.

(our "surface mounted" through-hole atmega DIP chip waiting to be soldered in place)


This approach has meant that pretty much all the designs we've spent the last few evenings working on are now redundant. But that's just a casualty of the rapid-reiterative-design-process we're embarking on - not to make the PCBs the "best" or the smallest, or even the cheapest; but to make them the easiest for most people to work with.

(checking the overall height of the board + mcu against 6mm thick mdf playing surface)

(before soldering, we'd snip the legs off, to make the understand completely flat and flush. By turning the entire thing upside-down we can more easily see that it fits within the profile of piece of 6mm thick mdf)

More updates with more designs as they are worked on (and, probably, discarded!)

Monday, 11 July 2016

Multiplexing A3144 hall sensors with an Arduino/AVR

After deciding to go down the "open source" route for producing an electronic board game, we've spent quite a bit of time focussing on almost the opposite end of the market for hobbyists and gamers - originally we focussed very much on mass production, cheap components, robustness and simplicity for gaining the necessary CE marks and other standards required for selling a manufactured product.

With a self-assembled kit of parts, from an open source list of components, we're focussing much more on ease of use, familiarity and "hackability".

Which inevitably means shoe-horning an Arduino in there somewhere.
Our original electronics for the board game were based around a super-cheap PIC 16F1829 (with plenty of internal pull-up resistors, an internal clock running at up to 32mhz) and an A2892 source driver IC (to provide power to each row of hall sensors).

But that was back when we were making a 12x12 grid of sensors. Or when we were looking at an 8x6 grid. Or even 6x6 shaped PCBs for a dungeon crawler type of game. But now we're looking at a 7x7 square grid per board section, possibly running off an Arduino/AVR...

And so, in the name of simplifying things for the Arduino hobbyists, we checked out the datasheets for the A3144 hall sensors and the AVR atmega328P.

(typical values for an A3144 hall sensor)


The A3144 typically uses 4.4mA as the supply current.
We've got 7 of them in a row. That's 7 x 4.4  = 30.8mA if all the sensors in a single row are powered at the same time (we're multiplexing, so only one row is active at any one time anyway).

Modern PICs can generally sink about 40mA but many still only source up to 20mA. Looking at the datasheets for our 16F1829 it says it's a symmetrical i/o port, sinking and sourcing up to 25mA. Just not quite enough.

However, atmega chips can sink and source up to 40mA per i/o pin.
What if....?

If we could source the power for an entire row of seven hall sensors from a single output pin on an  (atmega328 powered) Arduino then we could simplify the design even further and lose the need for a current driver too - simply hook up the sensors directly to the Arduino i/o pins: something that a lot of electronics hobbyist users would be more used to doing.

All we needed to do was try the idea out and see how it fared....

Here's some simple firmware for the Arduino. It uses digital pins 2-8 for the "outputs" (driving each row of hall sensors at a time) and pins 9-12 for the inputs (we only hooked up four of the seven inputs, for ease of use while testing).



int row=0;
int col=0;
int inputValue=0;
int lastValue[]={0,0,0,0,0,0,0,0};
int k;
int j;
bool led;

void setup() {
     // put your setup code here, to run once:
     for(int i=2; i<=8; i++){
          pinMode(i,OUTPUT);
     }

     pinMode(9,INPUT_PULLUP);
     pinMode(10,INPUT_PULLUP);
     pinMode(11,INPUT_PULLUP);
     pinMode(12,INPUT_PULLUP);

     pinMode(13,OUTPUT);

     delay(500);
     Serial.begin(9600);
     Serial.println(F("Let's go"));
     led=false;
        
}

void clearAllPins(){
     for(int i=2; i<=8; i++){
          digitalWrite(i, LOW);
     }
}

void getInputValue(){
     inputValue=0;
     int bitValue=1;
   
     for(int i=0; i<=3; i++){
          k = digitalRead(i+9);
          if(k==LOW){ inputValue+= bitValue;}
          bitValue = bitValue << 1;
     }

}

void loop() {
     // put your main code here, to run repeatedly:

     clearAllPins();
     digitalWrite((row+2), HIGH);
     delay(5);
     getInputValue();

     j=lastValue[row];
   
     if(inputValue!=j){
          Serial.print("row: ");
          Serial.print(row);
          Serial.print(" old value: ");
          Serial.print(j);
          Serial.print(" new value: ");
          Serial.println(inputValue);
          lastValue[row] = inputValue;   
     }

     row++;
     if(row>=7){ row=0;}
   
}


And the end result was...


Success. Sort of.
As we moved the magnet over the sensors, each one triggered and released as expected. Almost perfect operation! Almost. Because this time, we had to use a much larger magnet than with our PIC-based design.


The magnet at the top of the image is 10mm across and 2mm deep. This triggered the sensors when driven directly from the Arduino i/o ports. The smaller magnets are the ones we used for testing our PIC-based board (with dedicated current driver). They are just 8mm across and only 0.5mm deep.

The smaller magnets still work with the Arduino-based test rig, but they need to be placed exactly over the top of each sensor. The larger magnet allowed for a bit of imprecision when placing it (which is what we need, when using it to trigger the sensors from inside a playing piece on a board game). The larger magnet also worked on the reverse side of the board, through 6mm thick mdf. The smaller magnets could not be detected from the underside of the 6mm mdf.

So there we have it - if we compromise on the size of the magnets used in the playing pieces (i.e. go bigger, whereas we've tried to keep them as small as possible) we'll be able to simplify the electronics to just a PCB with an atmega on it (and the usual supply caps of course!) and a diode on the ground pin (swap the polarity of your power supply on an atmega and it goes pop very quickly).

And of course, for the open source brigade (some people are really quite militant about it) we can also now include an Arduino instead of one of those tricky-to-use, industrial-strength PIC microcontrollers - AVRs and Arduino are already the de-facto for hacking and doing your own thing with.

If we were looking at manufacturing, I'd absolutely insist on PIC, even if it meant adding the source driver. But for simplified open source kits that anyone can make themselves... well, Arduino seems to have that corner of the market well and truly sewn up. We'd be crazy not to take advantage!




Thursday, 7 July 2016

More MMA8452 accelerometer (and Arduino) testing

In "real work" we got a prototype device working for  a client who said they loved the idea and commissioned a set of audio devices. The idea is that each device is a ceramic shell-like shape, with an mp3 audio player, speaker and accelerometer (plus, of course, an Arduino, urgh!) embedded inside.

The shells sit in a vertical position, in their holders, but when they are lifted up and placed against the ear, the mp3 player triggers a short audio sample. Because the shell acts like a natural amplifier, and we want the audio to only be audible when it is placed right up against the ear, a tiny 1cm piezo speaker connected directly to the pwm outputs of the audio module is plenty loud enough.

There is more than one sound file in the mp3 module/player. To play different sounds, you simply rotate the shell as it is pressed against your ear.

So we poll the accelerometer and when the y-axis is zero, we take it that the device is "horizontal". We then read the x and z axis values to work out the amount of rotation applied.



In recent testing (albeit with a different accelerometer module for the actual prototype) we simply plotted the x, y and z axis values over time, while rotating the accelerometer around the y-axis. The results looked something like this.


Which is pretty much what we were expecting.
So we ordered up a bunch more MMA8452 accelerometers and prepared to make a few of these devices for the project.

Except this time, something weird happened with the x,y,z results.
When placed on a flat surface, and we expected all values to read zero, there was a constant "flickering" on each axis - it would occasionally go from near zero to near maximum.



These values were arrived at while the accelerometer was on a flat surface and not moving!
For some reason, the x-axis value hovers around zero. But every now and again, spikes to the full/max value, around 1, then quickly falls back to zero.

We thought that perhaps this  is something we might be able to take out in software. But it's not. If we rotate the accelerometer around the y-axis, as before, and plot the x and z values, we get this;



You can sort-of see the 90-degree offset in the x- and z- axes. But the constant spiking is something of a worry. It's as if the axis values are getting "mixed up" - the x value is being reported as the y value and so on.

Whatever it is, it's a mess.
And has put a bit of a question mark over the whole thing!
Unless we can be guaranteed that our accelerometers can be relied upon, we could end up with audio devices that trigger at random, and play any old mp3 file, in any old order.

In which case we should just ditch the accelerometer and write a random number generator in firmware! More investigations will continue over the coming days....

Arduino, AVR and internal/external oscillators

One of the nice things about working with PICs is that you know straight away if you've done something wrong. Things work. Or - if you've got them wrong - they don't.

And when things go wrong, the first thing that most people do is revert to a simple "blinky"  example - check that the microcontroller is actually running, and at the correct speed. It's a time-honoured thing that we all do.

So things got a bit weird today, using the same idea with Arduino.
We wanted our breadboard AVR chip to run from it's own internal oscillator at 8Mhz. We managed to get a blinky sketch running, after poking about with the fuses, but it was at about 1/8th of the required speed; our chip was running off it's internal oscillator, but at 1Mhz.

Of course, simply changing the firmware would fix this - shortening a 1sec delay to 125ms for examply - but this isn't the answer we wanted to implement. So we tried running the board off an external 8Mhz crystal, to see where the problem lay.

Here's the boards.txt we used, complete with fuse settings

##############################################################

atmega328bb.name=ATmega328 on a breadboard (1 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

atmega328bb.bootloader.low_fuses=0x62
atmega328bb.bootloader.high_fuses=0xD9
atmega328bb.bootloader.extended_fuses=0x07

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

atmega328bb.build.board=avr_atmega328bb
atmega328bb.build.mcu=atmega328p
atmega328bb.build.f_cpu=1000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard


atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude

##############################################################

atmega328bb2.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb2.upload.protocol=arduino
atmega328bb2.upload.maximum_size=30720
atmega328bb2.upload.speed=57600

atmega328bb2.bootloader.low_fuses=0xE2
atmega328bb2.bootloader.high_fuses=0xD9
atmega328bb2.bootloader.extended_fuses=0x07

atmega328bb2.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb2.bootloader.unlock_bits=0x3F
atmega328bb2.bootloader.lock_bits=0x0F

atmega328bb2.build.board=avr_atmega328bb
atmega328bb2.build.mcu=atmega328p
atmega328bb2.build.f_cpu=8000000L
atmega328bb2.build.core=arduino:arduino
atmega328bb2.build.variant=arduino:standard


atmega328bb2.bootloader.tool=arduino:avrdude
atmega328bb2.upload.tool=arduino:avrdude


##############################################################

atmega328bb3.name=ATmega328 on a breadboard (8 MHz external clock)

atmega328bb3.upload.protocol=arduino
atmega328bb3.upload.maximum_size=30720
atmega328bb3.upload.speed=57600

atmega328bb3.bootloader.low_fuses=0xCF
atmega328bb3.bootloader.high_fuses=0xD9
atmega328bb3.bootloader.extended_fuses=0x07

atmega328bb3.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb3.bootloader.unlock_bits=0x3F
atmega328bb3.bootloader.lock_bits=0x0F

atmega328bb3.build.board=avr_atmega328bb
atmega328bb3.build.mcu=atmega328p
atmega328bb3.build.f_cpu=8000000L
atmega328bb3.build.core=arduino:arduino
atmega328bb3.build.variant=arduino:standard


atmega328bb3.bootloader.tool=arduino:avrdude
atmega328bb3.upload.tool=arduino:avrdude


And the result...


See that little silver thing on the desk?
That's our 8mhz crystal. We took it off the breadboard and yet the sketch still runs. So the mcu is obviously still running off it's internal oscillator. And still only running at 1Mhz.

So it looks like it's working.
Except it's not.

It's on days like this that I really hate Arduino.




EDIT: a few people have suggested that there's no reason why we can't treat our AVR chips just like PICs - i.e. create a hex file (albeit using the Arduino IDE to code it up) and then burn it to the chip using a separate program, just as we do with PICKit2.

AVRDudess is just such a program.
And when we used that to burn our hex files instead of the Arduino IDE, everything worked as expected!


It's on days like this that I really hate Arduino.

Wednesday, 6 July 2016

Electronic board game - we're going Open Source

Remember a while back - and it's something that has become a bit of a running thread on this blog over the last 18 months or so - we had an electronic board game? Although it took a bit of a back-burner, it's something that we just can't let go; and we've tried all number of different ways of turning it into some kind of product that could be released, for gamers to play their tabletop wargames on.

Originally it was a digital football pitch. Then a hex-based multi-section game board. Then a multi-part board game. After that proved too costly, we tried a dungeon-crawler. Creating shaped PCBs with fewer squares than a full square section, but for the same cost, seemed a bit crazy. So we went back to multi-part boards.

And so on and so on.
Each time we tried finding not just a cost-effective set of components, but also a way of assembling (or having the board sections manufactured) that would produce a viable product.

After much trying - and much to Steve's frustration, going around in lots of circles - we finally decided that it couldn't be done. At least, not in a way that would be financially viable as a product for sale.

But, determined not to give up on the entire project, it was with some curiosity that we followed up a couple of suggestions about making the whole thing "open source".


Going with the idea of making the hardware open source means re-thinking it all over again. This time we're not restricted by the cost of assembly, but more like the complexity of assembly. If we published the design files online, how likely is it that someone could pick them up and actually make one of our electronic board games? While it'd be tempted just to stick the PCB designs online and say "off you go, make one of these" not everyone has access to a bubble-tank that can etch 9" square boards, for example, nor feel comfortable hand-soldering tiny sot-23 sized components.

This has led us to re-designing the entire board game section, to make it possible for someone with moderate "crafting" skills to put one together. Wargamers tend to be a pretty "crafty" lot - making, assembling, painting and building - as they do - miniatures and terrain. But our target audience may not be quite so hot on the electronics side of things. Do we even want to try to teach a complete new-comer how to solder, let alone make them responsible for the success (or otherwise) of assembling a kit of bits?

So we hit a compromise.
We can have some (much smaller) PCBs manufactured (our original designs were massive 180mm x 240mm PCBs) and even populate them, and leave the placement and assembly of the hall sensors to the end user.


After laser-cutting some mdf, we came up with some easy-to-follow templates, for placing strips of copper tape across one of the 245mm x 245mm sections


A dab of glue holds the hall sensors in place, before they are electrically connected to the copper strips. In our original design, we simply soldered them in place.


But, recognising that not everyone might be so competent with a soldering iron, we thought we'd try (Bare Conductive) conductive ink as an adhesive. Amazingly, it worked!


Just a nice big, messy blob of graphite-based goop on each leg, and after a couple of hours drying time, everything worked just as we'd hoped:



More details on how to make your own to follow!

Monday, 4 July 2016

Getting comfortable with Microchip PICs again

We've been doing a lot of work lately with Arduino. A lot of people love it, because you can just copy-n-paste some code off the intertubes and get a project running quickly. But that's also the reason why we really don't like it so much.

Recently we discovered another problem with the AVR chips (other than they let out the magic smoke really easily if you're not careful with the power supply!) regarding programming fuses. It's something that a lot of Arduino users never have to bother with. And as a result, there's not much information out there about it. And the bit of information out there usually involves the "copy-and-paste this code and everything will be ok" approach.

So when things don't work, it can take a long, long time to get to the bottom of things!

It was with relief that we returned to programming PICs again this weekend. Rather like having had a heavy night out in some new shoes, it was lovely to come home and put on an old, battered, but ultimately, really comfy pair of slippers. That's how I - personally - feel about PIC programming.

Now we've a bunch of 16F1829 chips lying around, so it made sense to use these for a new project. Since discovering the 16F1825, with it's 32Mhz internal oscillator and billions of onboard peripherals, it quickly became our favourite - and thus our go-to - PIC of choice. The 1829 is the same, but with more pins. And more pins means better, right?

Anyway, it was with some concern that we wired one up only for it to be unrecognised by our PICKit2 clone programmer.



We've got three or four of these, and not a one of them programmed the chip.
So we checked the wiring. It looked ok.
We were using a SOIC-clip to program a surface mount version of the chip.



Perhaps the problem was with the clip - so we put an SMT chip onto a breakout board.



Still nothing. Yet the chip was brand new and appeared to be wired correctly.
Then I remembered that I nuked my laptop a couple of months ago. Around about the same time we started playing around with Arduino.

It turned out that the PICKit2 software (re-installed after the nuking a while back) was running the older (original) device file. To support newer chips, like the 1825, you need to update the device file for the PICKit2 software. There's an updated file available by searching the Microchip forums. For anyone looking for it, we've uploaded the file to the nerd-server: http://www.nerdclub.co.uk/files/PK2DFUpdate-1-62-14.zip

Now the software can find our device and we can easily burn firmware to our PICs again. Lovely.
Arduino is already beginning to feel like a distant memory....