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....






Friday, 24 June 2016

Resin casting with a hand-drill

Not much to say about this.
Mike wanted to resin-cast some ball-shapes.
This contraption is as brilliant as it is simple

Thursday, 23 June 2016

Running Arduino atmega328 at 3.3v from lipo battery

Here's something that kept us stumped for a full day - getting an atmega328 to run at 3.3v.
We're using an accelerometer and a sound module that both run at 3.3v, so it made sense that we run our Arduino/AVR at 3.3v too.

Using our spanky TQFP socket, we could easily drop code onto an atmega328 chip; in the IDE simply select Sketch - Upload with programmer


And everything worked just fine.
But what we really wanted to do was make a "bootable" chip, so - if necessary - we could fine-tune the firmware, once the actual chip had been soldered onto the (tiny, cramped) PCB.

Which meant burning a bootloader - so we selected the appropriate board (since we're running at 3.3v we ditched the 16Mhz crystal and went with an 8Mhz ) and hit "burn bootloader".




Again, everything worked, and we could upload sketches from the IDE to the (naked) chip over serial. So then we pulled the power and connected up our lipo battery. For testing, we simply put the lipo output voltage - about 3.8v - through a diode to drop it down to around 3.35v

And then things started getting a bit weird.
Because the chip would respond at 5v, and at 3.7v. But at 3.3v it appeared dead.

(shocking ferric-fingers just look like dirty fingernails - how embarrassing!)

Very peculiar. Whether using the usb-to-serial 3.3v option or the "output" from the diode on the lipo, at anything less than about 3.5v the microcontroller appeared dead.

The first clue about what was going on came from this post: http://arduino.stackexchange.com/questions/23245/confusion-with-atmega328p-and-3-3v-8mhz

Already we were beginning to suspect the brown fuse settings, but we were unable to correctly change them and get a fresh bootloader burned. The "extended" fuse settings are where the brown-out voltage resides:


And we definitely wanted to disable the brown-out detector. So a value of 0xFF seemed like the best option. In the boards.txt file, we found the 3.3v/8Mhz option and changed it. After burning a fresh bootloader to the chip, we got this:


No bootloader. No flashing LED. Nothing.
But if bits 7-3 are not used, and we wanted to set bits 2-0, an extended fuse value of 0xFF seemed like the best option. Except it wasn't. It was only after setting masking the extended fuse value, and ensuring that the first 5 (most significant bits) were cleared could we even get the bootloader to burn.




With the extended fuses set to 0x07 (bit pattern 00000111) the bootloader not only burned, but the mcu started to work with voltages of 3.3v (and lower). So today's lesson: in Microchip and AVR land, "not used" means two very different things!