Hall sensors and cascading shift registers

Having just taken receipt of a load of PCBs from 3pcb.com, it was a nerve-wracking couple of hours as Nerd Towers until we found time to actually solder a few up and try them out.

There was nothing to be gained by testing just one (except, perhaps, to confirm that we hadn't done the usual trick of forgetting to connect all the ground connection points together!) since all the boards share a common latch and pulse pin, and data is supposed to be cascaded from one board to the next, via the serial clock and data pins.

The boards soldered up really quickly and easily - just smear some solder paste across the pads (in a sort-of "slug trail" across them, rather than messing about trying to put a dot on each one individually) then touch the pointy tip of a hot iron to rake out any excess between the legs. Same with the surface mount 1206 resistors - a touch of paste on the pads, place the component, touch with a hot iron, fixed. Each board took just a few minutes to complete (solder resist makes such a massive difference, compared to soldering home-made boards!)

The boards were then connected together using a bit of IDE ribbon cable (a bit of forward thinking and we might have set the connecting pins at 0.05" pitch instead of the standard 0.1" and using ribbons cable would have been a doddle).

Although it made us feel dirty, we put together a rough-and-ready, using an Arduino and the IDE serial monitor, to make sure that the boards were working as expected.

All the inputs on the PISO (parallel in, serial out) shift register are pulled high through onboard pull-up resistors. When a magnet is placed near each of the hall sensors, the appropriate shift register input is pulled to ground by the hall sensor.

(at the minute we're just spitting out the raw data from the shift registers as the input pins change, but it's a trivial matter to update the firmware to make it report much more user-friendly messages, like "board A square 2, piece placed" or "board B square 7, piece removed")

So when the device boots up, all inputs are reading 0xFF (255 in decimal)

Where in the video we see board A input value go to 251, this indicates that the input pattern on the shift register pins is now 11111011 (just from the binary value we can see that one sensor has been activated).

So whenever a playing piece (with a magnet in the base) is placed over a hall sensor, the input pin goes low. Similarly, when the piece is lifted away, the input pin goes high again (and in our example, the shift register input value returns to 0xFF - or 255 in decimal).

The important part of the testing here was not just to make sure that the hall sensors were working as expected (they were) but also to be able to distinguish between the inputs on each board piece - this is proven to be working, as the firmware correctly reports the input state on boards A and B only when their input pin values are changed. It's worth noting that, in the video, only board A is connected to the microcontroller - board B is connected to board A, cascading data via the shift register(s) on each board.

In short, a successful test.

It looks like we got the PCBs right after all!