Introducing the TGL-6502 Single Board Computer

Monday, December 15 2014 @ 05:27 PM

The TGL-6502

Here is a project I've been working on over the past few weeks - a 6502 compatible single board computer with 128K of RAM, 128K of ROM and an IO expansion port. The reason I call it 'compatible' is because the role of the 6502 processor is being played by an emulator running on a 8 pin LPC810 ARM Cortex-M0+ processor. The emulated processor supports all the official 6502 instructions (the undocumented instructions are treated as NOPs) and it is not a cycle accurate emulation. The entire emulator fits in the 4K flash on the LPC810.

The project is not yet complete, at this stage it is capable of running EhBASIC from the on-board EEPROM chip but the code to provide access to the front panel IO and the expansion slots is not yet implemented. I am also in the process of redesigning the main PCB to simplify it - this redesign will remove one of the IO slots and replace the 16 bit IO expander with it's 8 bit little brother.

EhBASIC Works!

You can find the full source code and hardware design in this GitHub repository if you would like to play around with it for yourself. I would appreciate any feedback on the design and firmware as well. I used DesignSpark PCB for the schematic design and PCB layout, to make it easier I've also made the design available in PDF and gerber format in the hardware/RevA/mfr directory of the repository. The firmware is available as an LPCXpresso project. Both of these are free tools so it should be relatively easy to hack away at the project.

Some Background

I've always wanted to build my own single board 8 bit computer, I have a bunch of older 8 bit CPUs such as the 6809 and Z80 in my parts collection that I acquired just for that purpose. Unfortunately it seems to be a project that I never get time for. I have toyed with the idea of building an emulated system on a more modern microcontroller as well but it was this post on the MOS6502 Google+ community that finally triggered me into action.

Milled PCB

That post linked to this entry on StackExchange that had the C source for a compact 6502 emulator core. At the time I was considering the LPC810 for another project and I started wondering if I could fit the emulator into the 4K flash on the chip. A few experiments and a simple breadboard prototype soon followed and the project was born.

The Hardware

LPC810

All the heavy lifting is done by the LPC810 of course but, with only 1K of RAM available on the chip, I needed the ability to access external memory chips to have a system that was at least marginally useful. I also wanted the ability to expand the system at a later date with relative ease so that meant some sort of IO expansion that could be exposed to the emulated processor.

The LPC810 only has 6 IO pins, two of those are needed for the serial interface which leave just 4 to implement all of the above. The best solution turned out to be using external components on a SPI bus to get the additional functionality. The final system has an SPI IO expander, a 1Mbit (128K x 8) SRAM and a 1Mbit (128K x 8) EEPROM. There is a quad 2 input NAND gate in the circuit as well to help with the SPI slave selection logic. You can see how it all fits together on the schematic in the GitHub repository, I will put up a more detailed post about the hardware in the next day or so.

Testing SPI

The board design that is currently in the repository is my RevA board - it uses a 16 bit IO expander (a Microchip MCP23S17) and has two SPI based expansion slots. This is one of the first boards I've made using CNC milling and the quality isn't as good as I had hoped. The board layout was also less than optimal, very long traces for the SPI bus which introduced errors at higher speeds and far too many jumper wires for my liking. As I have to remake the board anyway with better settings for the CNC machine I am taking the opportunity to simplify the design a bit and cut back on some of the more optimistic goals. The RevB board (which will be pushed to the repository in the next few days) drops one of the expansion slots and replaces the 16 bit IO expander with an 8 bit version (a Microchip MCP23S08). This should help make the board a bit more compact and help reduce the size of the firmware a little bit as well.

The Emulator

The Real Thing

The emulated environment is a straight forward emulator based on the C code from this StackExchange post which I have heavily modified to minimise the final code size. I managed to shrink it from 6198 bytes to 2468 bytes by removing some features (undocumented instruction support and cycle counting) and making structural changes to the code such as manually in-lining functions and removing some large look-up tables. The result still correctly emulates a 6502 (enough to run EhBASIC at least) but makes no attempt at cycle accurate emulation.

System memory is made available to the emulator as 8 pages of 8Kb each selected through a memory mapped page table. Each memory access uses this table to convert the processors 16 bit address into a 21 bit 'physical' address before performing the memory access. This gives a physical memory range of 2Mb - I have arranged it so that the RAM chip is found at the bottom of memory and ROM starts at the 1Mb boundary so I can use the most significant bit of the address to determine which chip I should be talking to.

Access to the 'real' hardware is provided to the emulator through a memory mapped IO block just below the interrupt vector address at $FF00, this block is always available at that processor address regardless of the active page mapping. As I mentioned the memory page map is accessible there as well as a few extra bits:

  1. Interrupt source selection for the NMI and IRQ lines. These can be triggered by an internal timer (every 1/4 second), input on the serial port or a pin on the IO expansion slot.
  2. Control of the front panel hardware (2 LEDs and a push button).
  3. A very simple interface to the SPI bus so you can control an SPI device in the expansion slot. This allows transfer of up to 128 bytes at a time over SPI (not enough for an SD card but plenty for a LCD display).
  4. A 'seconds since boot' value that is automatically incremented every second.
  5. A 'KIPS' (Kilo-instructions per second) value that gives you an idea how fast the system is running. This is updated every quarter second.

I really wanted to make the system as useful as possible, not just a proof of concept. With the amount of memory available and some access to external hardware I think I have achieved that goal. I am writing a more detailed post on the emulation environment with examples on how to use the hardware interfaces.

The Casing

Suitably Retro

A retro computer emulator deserves a suitably retro case as well, I had the front panel design in mind from the moment I started implementing the project - I think it conveys the late 70's perfectly. The panel is milled out of a piece of laminated flooring with all engraved text using the Motter Tektura font (as used by Apple, Reebok and others in the 80's) - the combination of the font and the fake plastic wood is exactly what I was aiming for.

I was originally going to build a fully enclosed case but my 3D printer is out of action at the moment so I had to mill MDF to build it. I haven't done much work with MDF on a CNC machine before and wasn't sure how well it would work so I kept the design simple to start with - just a base plate and two side panels. It turned out better than I expected, the case looked like something that would be shown at the Homebrew Computer Club and the open design made it a lot easier to debug the hardware while it was assembled so I stuck with it rather than building a fully enclosed version. When my printer is up and running again I will just make a PCB mounting frame to attach to the base plate so it doesn't slide around.

The casing isn't mandatory of course - all of the external connections (power switch and LED, front panel button and LEDs, etc) are exposed through pin headers on the main PCB so you can use whatever components you like.

Conclusion

This has been a fun project to do and the result so far is quite usable (even if it is a little slow). The two large changes I would like to make would be to increase the speed a bit and to have some form of persistent storage available. Increasing the speed mainly revolves around the SPI interface to the memory chips which is the real bottleneck for performance, support for persistent storage could be provided with an IO expansion board (something I already have some ideas on how to implement).

Some Assembly Required

The design is not limited to emulating a 6502 either, I have tried to keep the emulator core and the hardware emulation functionality as separate as possible with a well defined interface between the two. You could replace the 6502 core with something different and build a single board computer for your favourite microprocessor. The only limitation is that it has to fit in the 4K of flash available - a 6809 might be possible but the Z80 might be a bit too complex (which is unfortunate, I would love to run Fuzix on the hardware). As I mentioned earlier - the full code is up on GitHub and I would welcome any alternative processor cores if someone has a mind to write one.

This post is the first in a series of three that will appear over the next week or so - future posts will cover details of the hardware design and provide more information about the emulated environment. I will be posting updates on Google+ as well.


CNC Milled PCBs

Monday, November 17 2014 @ 07:18 PM

As I've mentioned before on the site I have been looking for a more effective way to create prototype PCBs than sending them off to somewhere like Seeed Fusion or using the toner transfer method - I have started down the path of trying to build a small CNC machine for this purpose and even experimented with lasers as a method of preparing boards.

CN-3020T Milling Machine

A few weeks ago I had the opportunity to get a small CNC machine for a very reasonable price so I jumped at it. I am now the proud owner of a CN3020T desktop CNC router and have had a bit of time to learn how to use it. My main purpose for it is PCB creation but I have also had a chance to play with engraving and cutting other materials such as wood and plastic (it is supposedly capable of working with soft metals such as aluminium as well but I haven't had a chance to try that).

This post describes how I am going about making PCBs with a CNC machine, like many other things the process is not as simple as it looks at first glance and, having had to do numerous searches on the internet to find the information I needed I thought I would document as much as possible here to help others who are going through the same thing.

A Brief Introduction

Essentially a CNC machine is a drill that can be moved in 3 dimensional space. You place a tool bit in the drill which is then moved in the X, Y and Z directions to cut into the material you have mounted on the bed. Where a 3D printer uses an additive process to get to the end result (slowly layering material at various points to build up a solid object) a CNC is subtractive - you start with a solid piece of material and slowly cut away at it.

Software Tools

As with 3D printers a CNC is controlled by g-code and you will need a way to generate that g-code. There are no shortage of tools that will help you do that, I am just going to cover the ones I have had some success with.

To generate g-code for PCBs I have been using Line Grinder which takes a set of gerber files as input and generates g-code output. The output is in the form of three g-code files - one to do the isolation routing that defines the copper tracks on the PCB, another that controls drilling the holes for through hole components and a third that will cut the board outline from the PCB blank you routed on. Each file requires a different tool bit to do it's job. There is a similar tool called pcb2gcode which I haven't played with yet.

For general operations (cutting out shapes, cutting areas into a solid surface and etching) I have been using the gcodetools plugin for Inkscape. Inkscape is a very powerful vector drawing program that is available on a number of platforms including OS/X, Windows and Linux so this is a good solution no matter what OS you use. Inkscape can also import a large number of image formats and convert bitmap graphics to vector format so there is a lot of flexibility there. Even if your only interest is making PCBs you will still need to occasionally perform some of the basic cutting and area clearing operations so learning how to use Inkscape and gcodetools is useful.

OpenSCAM

To check the resulting g-code I recommend OpenSCAM. Despite the unfortunate name this is a very, very handy tool - essentially it is a CNC emulator - it will run the g-code you provide it and show you how the tool will move on and what the effects on the work-piece will be. I would go as far as saying this tool is essential - especially as you are learning or are experimenting.

Most CNC machines seem to be very dumb devices - the 'control box' that they come with is little more than a power supply, some regulators and a parallel port interface. All the interpretation of the g-code (translating it into actual motor movement) is done by software on the PC. There seem to be two major programs for this - LinuxCNC for Linux and Mach3 for Windows. LinuxCNC was previously known as EMC2 so you will see that name pop up a lot in searches. I am using LinuxCNC with my machine, simply because I prefer Linux over Windows and I'm too tight to pay for licenses.

LinuxCNC depends on a kernel with real time extensions so it's not really an application that you install on your favourite distro - it's more it's own (Ubuntu based) distribution with the appropriate kernel included. If at all possible you should dedicate a machine to it - I'm using an old desktop with a built in parallel port to run LinuxCNC to drive the CNC and Pronterface to drive the 3D printer.

Hardware Tools

If you are not already familiar with wood and metal working the number of tool bits available can be a bit daunting. My machine came with a small collection of bits and I have bought more of them from eBay as well. Be prepared to (and, really, expect to) break a number of them while you get used to what you can and can't do.

Testing Tool Bits

Different operations require different tools - if you are drilling holes you use a normal drill bit with the cutting edge on the tip - it travels in the Z direction only. To cut out a shape you need a bit with the cutting edge on the side of the bit - as it moves in the X and Y direction it cuts out the shape you specified. There are a range of different cutting bits with flat, conical and curved cutting edges - each of them give a slightly different result.

I have taken to cutting a sample shape at a shallow depth into soft wood like pine to see what effect a tool has - this minimises the stress on the tool and gives me a feel for what it can be used for. The image to the right shows the Garage Lab logo cut with various dremel bits (yes, you can use dremel bits with the CNC machine as well). I drew up a simple version of the logo in Inkscape and generated the g-code with gcodetools - a good example of how useful the that utility is.

General Guidance

Although g-code can use either mm or inches the preference (for CNC machines at least) tends to be for inches so if you are like me and brought up on the metric system get used to converting between the two. It's not a big problem but I find I have trouble visualising things in inches - I need to convert to mm to have a clear idea of what the size actually is.

There seems to be a huge number of parameters that need to be specified with any program that generates g-code for milling - a lot of them are straight forward and can easily be measured (tool size and length, work area size, etc) but others require a bit of playing around with to find the optimal values for you machine and set up. One that I had particular problems with was the feed rate or the speed at which the tool bit travels in inches/minute.

Different rates are used at different points in the process - there is a cutting rate (the speed used while it is actively cutting), a travel rate (when the tool is above the work piece and moving to a new location) and a penetration rate (how fast the tool is pushed into the work piece).

Your machine will have an upper limit on all rates (the motors can only move so fast after all) but the rest of them are up to you to define and will heavily depend on the capabilities of your machine, the type of material you are working on and the bit that you are using. My recommendation is to start low and work the speed up - unfortunately I tend towards the impatient side and broke a few tools simply because I was trying to move them too fast.

Making PCBs

In this section I am not going to go into a lot of details about settings, tool sizes or feed rates - as I said above, those things are very dependant on your particular setup. Instead I'm going to concentrate on broader techniques that worked for me and point out various things that tripped me up.

PCB Milling Bits

For PCB milling you will need three different tool bits - an engraving bit (which looks slightly like a spear head), a 1mm drill bit and a cylindrical edge milling bit. The photo to the right shows the bits I am using - the are a range of different types available and they are generally available cheaply on eBay. Because I don't really understand the difference between all the bits yet I wound up buying a selection and I'm going through them and seeing how they work and which bits are best suited to different materials.

Generating the G-code

I am using the Line Grinder utility I mentioned earlier to generate g-code from gerber files but much of this will be applicable to other utilities as well. Essentially you will get two (optionally three) output files from your gerber input - the isolation routing file, a drill file and perhaps an edge milling file.

Isolation Milling

The isolation milling file is run with the engraving tool (I use one with a 10 degree angle and a 0.1mm tip). This cuts away a thin line of copper around your traces while leaving the rest of the copper behind. Line Grinder also generates pad touchdowns, small dots in the center of each pad that act as a guide if you are drilling the board by hand.

Some parameters to watch out for here are the Z depth for isolation cuts and pad touchdowns and, of course, the feed rate. I had to increase the depth from the defaults used by Line Grinder - it has to be slightly deeper than the copper layer size on the blank boards you are using and the defaults assumed a very thin layer of copper. You don't want to make it too deep though - because of the shape of the tool the deeper it cuts the wider the cut will be on the surface.

The drill file is run with a 1mm drill bit and will drill the holes for the through hole components. Line Grinder generates this file as if the top copper layer was facing up - if you are only doing single sided boards you will need to flip the X co-ordinates and translate the result back into place before running it through your mill. I have been using the grecode utility to do this - it is a very handy tool to have around for basic manipulation of your g-code files.

Work Area Leveling

Because the isolation routes are cut at a very small depth it is very important to have a level work area. My mill is a cheap one and the work bed is not very level relative to the tool tip - there is up to 2mm difference across the entire bed. When you add a sacrificial layer to work on this gets worse as it introduces it's own height differences.

I found a tool called AutoLeveller which is very helpful in this situation. It will take an existing g-code file and add a level probe operation at the start and then use those measurements to adjust the actual Z height used in the rest of the file. You can easily add a probe to your mill by connecting the tool bit to an input pin on the parallel port and connecting your PCB to ground - when the two make contact the connection is shorted out and the CNC software detects the probe contact.

Cable Breakout

The connection between the controlling software and the CNC mill is usually a parallel printer cable (if you have a newer PC that doesn't have an on board printer port you will have to get a PCI printer card). To make it a bit easier to insert additional signals on the various lines (such as a surface probe) I made a small breakout board that gives me access to all 25 pins on the cable including the ability to disconnect them on an individual basis. You can see a photo of the board to the right - with luck it will be the last PCB I have to hand etch. Using this board it was simple to add the probe - I simply connected fly leads with alligator clips on the ends to one of the ground pins and one of the unused inputs to the PC.

Using AutoLeveller alone was not enough however. My original method of holding the PCB on the work area involved using two pieces of MDF, the upper piece having a hole cut in it in which the PCB could be placed. The difference in Z height across the combination was unfortunately too much for AutoLeveller to correct for so the resulting PCB had isolation cuts ranging from being too deep into the PCB and cutting through the track altogether to being mere scratches on the surface.

PCB Holding Bed

My next attempt involved using a piece of pine off-cut as the base in which I milled out a 1.5mm deep area for the PCB to fit into. The benefit of this is that the area the PCB is sitting on is definitely parallel to the tool path giving me a much more consistent depth to start with - the main differences in height will now be from the PCB itself rather than a combination of bed and sacrificial surface errors.

Combining PCBs

Most of the boards I make are fairly small, less than 50mm by 50mm. Going through the process of setting up (levelling, setting the origin, etc) for each board would not really save me a lot of time over the toner transfer method of making PCBs. What I wanted was a way to combine multiple PCB designs into a set of G-code files that would fit on a single larger sheet. I didn't want to do all of this by hand so I wrote a Python script that would do a lot of the work for me. You can see the source for it here but please be aware that it is a work in progress and very much tied to my particular configuration. It may be a useful starting point for your own scripts though.

Completed Panel

The script uses the utilities grecode and opti to do most of the work on the g-code - it expects to find these tools on the path. I have modified the opti tool to compile on Linux and accept g-code on standard input and write the modified g-code to standard output. This archive (gzipped tar file) contains the Python script, the modified source for opti, the design for the parallel port breakout board as a DesignSpark project and some sample g-code for PCBs.

The script takes a list of board names as arguments (you can specify the same name multiple times if you want multiple copies of the same board), tries to fit the boards on to a single sheet of blank PCB (the default size is 150mm by 75mm but this can be overridden with command line arguments) and then combines the g-code files.

The tool expects three g-code files for each PCB - the bottom copper isolation routing file, the drill file and the edge milling file. It uses the default file names as generated by Line Grinder and generates output with similar names. The output files are a combination of the inputs with the appropriate translation and rotation operations performed on them so they will fit into the work area.

A sample run of the utility looks something like this:

$ ./pcbpack.py samples/attiny84 samples/attiny85 samples/serial_onepin
Checking dimensions ...
  OK
Laying out boards ...
  Selecting iteration #0 with area 5620.05 mm2
  Selecting iteration #1 with area 4651.11 mm2
Selected layout:
  'samples/attiny84' (28.68 x 46.81) @ 5.00, 5.00 - rotated = True
  'samples/attiny85' (33.76 x 29.67) @ 38.68, 5.00 - rotated = False
  'samples/serial_onepin' (38.46 x 20.62) @ 38.68, 39.67 - rotated = False
Layout image saved in 'pcbpack.png'
Generating combined g-code ...
  Optimising ..
  pcbpack_ISOLATION_GCODE.ngc
  Optimising ..
  pcbpack_DRILL_GCODE.ngc
  Optimising ..
  pcbpack_EDGEMILL_GCODE.ngc
Operation complete.

The drill files generated by Line Grinder are difficult to manipulate as they are designed to be used with the top copper layer facing upwards. Originally I used 'grecode' to flip the x axis and then translated the co-ordinates to match them up to the bottom copper layer but this turned out to be unreliable. Luckily Line Grinder generates pad touchdowns, small drilling guides in the center of each pad to help with manual drilling. The commands to generate these are nicely bracketed by '(... pad touchdown start ...)' and '(... pad touchdown end ...)' comments in the isolation milling file - the pcbpack script extracts the X and Y co-ordinates from this section of g-code and generates it's own drill file from those.

Drilling Holes

Finally I run each of the generated files through opti to minimise the travel distance of the tool (this results in a 60% to 70% reduction in travel distance, massively speeding up the milling process).

Once pcbpack has generated the output files the isolation milling file needs to be run through Auto Leveller. Auto Leveller is a Java application and at the time of writing this doesn't support command line arguments so it is difficult to automate.

Having an automated workflow makes things a lot easier - I am slowly building up a collection of Line Grinder generated files for the boards I have designed so it is fairly easy to pick a selection of boards for a milling run. Overall the process is a lot quicker and involves a lot less manual handling than the toner transfer method I was using earlier - the end results are far more consistent as well. Given that this was the goal I was after I'm satisfied.

Future Work

At the moment I'm at the stage where I can replicate what I was doing with toner transfer with the added benefit of having the boards drilled and cut for me as well. I would like to see if I can do some things that weren't previously easy or possible with the old method such as milling very fine pitch tracks for surface mount components.

Some of the component footprints are not really suitable for milling either, circular pads require a larger annular ring for example - the small pads can lift off completely during drilling requiring some messy soldering to repair. Luckily DesignSpark makes it very easy to customise the PCB footprints and update existing designs with the new version of the component.

Should You Buy a CNC Machine?

That is a hard question to give a general answer to. It really depends on what you are doing. I'm very satisfied with the purchase and I think it will at least save me a lot of time even if it doesn't save me any money. Getting boards made at a PCB fabrication service like Seeed Studio is not that expensive, it is mainly the turn around time between sending away your order and having your boards delivered. If you go through several iterations of a board this can easily add up to months. Will the CNC machine I can mill a set of boards in an hour or two so I can go through two or three iterations in a single day which is a vast improvement. On the other hand, if I needed a reasonable number of boards (10 or more for example) I would still send them off for fabrication to take advantage of the better build quality and multiple layer boards.

The mill is not just for PCB manufacturing though - I will be using it to work with other materials as well such as structural components out of wood or metal and more decorative items in wood. As a companion tool to a 3D printer it allows for a much wider range of options when it comes to creating designs.

If you wanted to use the mill purely for PCB manufacturing I would think very carefully about it first - you would have to be making a lot of boards to make it worthwhile. If you already do a reasonable amount of woodwork or mechanical construction it can become a valuable tool in that regard as well - that might be enough to tip the balance for you.


5 Simple Ways to Save IO Pins

Sunday, September 28 2014 @ 07:05 PM

It has been far too long since I have put up a new post so I thought I would share some techniques I've discovered while working with low pin count micro-controllers like the ATtiny85, LPC810 and the PIC16F1827. A lack of IO pins can be a limiting factor but there are a number of ways to get more functionality out of what is available. This post covers five useful techniques I have used in various projects.

Please note that the schematics in the post are only meant to give you an idea of how the technique works - you will need to adjust component selection and values to suit your specific application.

Use a Single Pin to Select Two SPI Devices

When you are using SPI based devices the number of pins required can add up very quickly especially if you have more than one in your circuit. You can share the bus lines (MISO, MOSI and SCK) but you will need a separate CE line for each device.

One Pin Select

If you only have two devices on the SPI bus you can use a single pin to switch between them by inverting the selection state to drive a second output, one device will always be selected but you at least have some control over which one it is.

The circuit to the left shows how to achieve this. The SELECT output from the CPU is passed directly to SEL0 and is used to control the select line of the first device. The SEL1 line for the second device is controlled by a NOT gate constructed from a resistor and a transistor. The resister holds SEL1 high while SELECT is low, when SELECT is high the NPN transistor is switched and SEL1 will be pulled to ground selecting the second device.

This simple construction of a NOT gate is very useful and will show up in some other circuits in this post.

Analog and Digital Input on a Single Pin

If you need a single push button in your design you can share a pin with an analog input with one small caveat - that you don't need to measure analog values that are close to 0V.

Shared Input Pin

The circuit to the left shows a good example of this - using a single pin to measure battery voltage as well as a single push button input in a battery powered circuit. In this case the battery voltage is read through a voltage divider that halves the value, giving a range of 0V to 4.5V. Because the battery will never read 0V (the processor would not be running in that case) we can connect a push button between the analog input and ground and use the 0V reading to indicate a button press.

Read Multiple Buttons from One Analog Pin

If you need more than a few buttons in your design you will find that it starts to chew up IO pins very quickly. If you only need to read the state of a single button at a time (no button combinations) you can use a single analog input.

One Pin, Many Buttons

The circuit to the left shows a design to achieve this that I discovered in the Arduino Basic Connections book and covered in detail in a previous post.

Essentially the circuit is a resistor divider, when a button is pressed it selects a different point in the resistor chain to measure which changes the ratio of the divider and the final output voltage. The 1M resistor between ground and the final output ensures the analog pin isn't floating when no buttons are pressed.

As I mentioned earlier, this circuit is only useful if only one of the buttons is pressed at once. This makes it suitable for simple menu navigation or options selection which is often all you need.

Single Pin Serial Port

I have covered this in a lot more detail in Non-existant post but it is worth mentioning again. If your controller does not have a hardware UART available you can still achieve reasonably high speed serial communications by implementing one in software using bit banging.

One Pin Select

Ralph Doncaster took the technique a step further to implement half duplex serial communications on a single IO pin with a handful of discrete components as shown in the circuit to the right.

There are a number of limitations with this circuit:

  • Any bit received on the RX line will be echoed on TX. This means the client will see an echo of everything that it sends.
  • It is half-duplex, you can only be sending or receiving - not both at the same time.
  • The firmware implementation needs to swap the direction of the IO pin to suit the operation being performed.

Once implemented correctly the technique is very reliable - I use it in my serial bootloader implementation for the ATtiny85 and there is support for it in my ATtiny85 template library as well.

Generating a RESET Pulse from SCK

This is another one from Ralph Doncaster and once again relates to SPI. The specific example used by Ralph is to control the CSN pin on a NRF24L01 module from the SCK line but the technique can be adapted to other scenarios.

A number of SPI devices have a RESET input which is used to initialise the device and, in a some cases, this may need to be done under software control rather than through a power on reset circuit. The classic Nokia 5110 LCD module is a good example of this.

RESET from SCK

The circuit to the left shows how to drive the RESET pin using the SCK. In general the SCK line is oscillating as data is fed to the device, this circuit uses long (more than a few microseconds) pulses to trigger a low level on the REST output.

When SCK goes high for several microseconds, C1 will charge through R1 and switch the transistor, bringing the RESET line low. If SCK is brought low for several microseconds before being used to clock the SPI data, C1 will discharge and the transistor will be switched off allowing RESET to be pulled high by R2. High pulses on SCK of less than a few microseconds during normal SPI operation will not be enough to charge C1 - the transistor will remain switched off and RESET will be pulled high.

If you keep the SCK line low during idle periods you can control the RESET line using a long initial high pulse on SCK.

Summary

These techniques are very useful when you are trying to get the most out of the pins available to you and most of them only require a small number of additional components. If you find you are using a large combination of them in a single circuit though you should probably consider using a CPU with a higher pin count.

I would love to hear about additional methods people are using, please post your favourites in the comments.


A CNC Engraver Platform - Part 1

Friday, July 18 2014 @ 10:31 PM

I have been looking for a way to simplify the creation of PCBs with a fairly high degree of accuracy - my series of posts about using a laser diode from a DVD/RW drive was an experiment to see if I could use that to expose copper on a PCB by burning away a layer of paint applied to the board. Unfortunately it turns out they are not powerful enough for the task (although they are still useful for other things).

I started looking at other options including purchasing a CNC router to perform the task by cutting the copper layer away directly. Unfortunately the price of a full CNC router ranges from around $AU 600 to $AU 1500 depending on the size of the work area and if you get it as a kit or not - at this price it is a bit hard to justify given the purpose I want to use it for.

It then occurred to me that I could use a hybrid process - use a layer of paint to protect the copper from etchant and use a simple engraving tool to expose the areas I do want to remove. I did some simple tests using a cheap engraver from Jaycar and proved that you could use it to create relatively fine lines through a coat of spray paint.

The next step is to mount this on a device controllable through G-code commands so I can try it with complete boards. Because the amount of force required is far less than that needed to cut through the copper layer completely and you don't need precise control in the Z direction it should be possible to make the bed at a far cheaper price using easily obtainable materials. This is the first in a series of posts describing my attempt to do just that.

I'm writing these posts as I progress so I have no idea if the end result will be a working device or not. If you spot anything that I'm doing wrong or that I could improve please speak up in the comments. The project is hosted on GitHub so feel free to poke around.

Anticipated Design

The design I'm starting with is fairly simple - a work bed that moves in the X direction and a tool head moving in the Y direction. The tool head only has two states - active and inactive - there is no fine control over movement in the Z direction. There are a few goals I want to achieve with this design:

  1. Wherever possible all the parts should be easily available at a reasonable price from a number of sources - no speciality components or difficult to acquire pieces. I want the project to replicable if I want to build another one at some point or if someone else wants to build one for themselves.
  2. Where custom components are required they should be easy to print on a consumer level 3D printer like a MakerBot or Solidoodle.
  3. Although I'm planning on using the engraver as the tool head I would also like to be able to easily switch it out for a laser and be able to experiment with other tools as well. This means the basic tool head will simply be a mounting frame with a set of control and power lines available that you can attach whatever tool you want to use at the time.

I've settled on using a threaded rod as the drive mechanism for the bed (X axis) rather than a belt driven system - it seems less fiddly and the parts required to put it together are very easy to get as well as being cheap. I will most likely use the same mechanism for the Y axis but I will wait to see how well it works first before finalising that decision.

For the electronics side I'll stick with a standard Arduino or compatible as the main processor and use a motor driver shield to control the stepper motors. The hardware is relatively cheap and definitely readily available - there is also a lot of code available that can be pressed into service to drive the whole thing with minimal modifications. This means I can concentrate on the mechanical side of things without adding additional complexity.

Constructing the Base and Bed

The first step is to build a suitable base and put the mechanical components in place to drive the bed. The threaded rod mechanism requires bearings at either end of the rod and one end to be coupled to a stepper motor. The bed is attached to the rod with nuts and, as the rod is rotated, the nuts slide down the length of it taking the bed with them. We also need some guide rods at the edges so the bed cannot rotate around the drive screw and will remain balanced even if the load placed on it is uneven. The parts I'm using for this are:

  1. 9mm MDF for the base. It's relatively light for it's strength and an easy material to work with.
  2. Xmm MDF for the workbed.
  3. A length of 5/16" threaded rod and matching 5/16" hex nuts.
  4. Two 608 bearings to mount the threaded rod.
  5. Two lengths of aluminium tubing for the guide rods.
  6. A Nyloc nut to help with coupling the threaded rod to the stepper motor.
  7. A stepper motor.
  8. Limit switches for detecting the maximum movement.

All of the parts above came from Bunnings except for the bearings which I bought from a skate shop (they are the same type used in skate boards), the limit switches which came from Jaycar and the stepper motor which I bought from Little Bird Electronics.

Base Layout

I'm aiming for at least a 15cm x 15cm usable work area, it's large enough to be useful but small enough that the final assembly will fit neatly on a workbench. This means the bed will need to be at least the width of the work area and twice the length - so 30cm x 15cm at a minimum. The diagram to the left shows my planned layout for the base and shows the mounts and coupling components that will be required.

Bed Layout

Because the bed and the base are tightly linked they need to be constructed at the same time. The bed is somewhat simpler - it only requires attachments to the guide rods and the threaded rod. The diagram to the right shows how they are laid out.

I apologise for the quality of the diagrams, at this stage it is all very much a work in progress so I'm simply doing a basic layout using the Inkscape tool. The numbers on the components are the arbitrary part numbers I have assigned to the the printed parts - these are described in more detail below.

Coupling and Mounts

All the mounts and the motor coupling are 3D printed and are designed to use M4 bolts to attach them to the base. You can find the OpenSCAD source for them here. At the time of writing these are very much works in progress - I haven't had the chance to put them together yet.

Note: The components in the current design take a long time to print - with my printer (a Solidoodle 2) it takes about 12 hours of printing to make all the parts (4 print runs at an average of 3 hours per run). The largest part just barely fits into the print area I have available (6" x 6"). If you are trying to duplicate this project be prepared for a lot of print time.

At this stage I'm not entirely sure that the plastic components will be strong enough or if they will provide a tight enough grip on the components they are being attached to. I'm trying to avoid the use of non-removable connections so I'm using grub screws instead of glue to fasten the components.

The grub screw concept was introduced to me by a friend. Essentially you need to provide a way to introduce a nut into your print with a bolt hole that will engage with the nut while keeping a slice of plastic between the two. This allows you use the tip of the bolt to apply pressure to the target surface by using the plastic to absorb the force. My friend goes to the extent of dropping the nut in to the print at the opportune time so the print continues around it, my approach is to provide a slot (with a suitable hexagonal shape at the bottom) that you can drop the nut into and insert the screw to the side of it.

In this section of the post I describe the parts that are needed and provide a basic description of their design and requirements. So far I have tested these for sizing and interaction but haven't fully assembled them yet so changes may be required. In the headings for the various components I've included the part numbers I have assigned to them (see the layout diagrams above) so it is a bit easier to match the part type to the purpose it serves.

Guide Rod Mounts (Parts 1, 2 & 6)

Part #2

There are three types of these, the first is used to attach the guide rod to the base and simply consists of a hole for the guide rod to fit in, a slot to hold the nut for the grub screw and bolt holes for attaching to the bed (this is part number 2), the rod is fixed in place with the grub screw. The second type is a simple variation of the first which adds a slot to mount the limit switch (this is part number 1). The arm of the limit switch extends upwards so when the bed has reached its limit of travel the controller knows it cannot move in that direction anymore.

The third and final version is used to attach the bed to the guide rods. This version does away with the grub screw and the hole for the rod passes completely through. The fit on this needs to be relatively tight to avoid wobbles but still loose enough to allow it to slide freely across the guide. I'm planning on using a silicon based lubricant to help with this.

Bed Drive Mount (Part 7)

Part #7

This part (shown to the left) is very simple - it clips on to a hexagonal nut that is screwed on to the threaded rod. My concern with this part is that the orientation of the print means that the force applied to it (and it will be subject to all movement force for the bed) will be in the same orientation of the print layers, although I don't expect a large amount of force to be applied the part may degrade over time.

Bearing Mount (Part 3)

Part #3

The bearing mount (shown to the right) simply needs to hold the 608 bearing in place while allowing it to freely spin. The threaded rod will be mounted in these bearings which will allow it to rotate freely without allowing it to move laterally. There is only a single bearing only mount required, for the other end I merged it with the motor mount to make a single piece.

Motor Mount (Part 4)

Part #4

This is the largest individual piece in the collection - it merges a bearing mount (as described above) with a holder for the stepper motor while allowing space for the motor coupling (described below). The piece, while large, is very straight forward. The only issue to take into account is ensuring the fit for the motor is tight enough that it doesn't wobble when it changes direction. My initial print for this is a little loose (see the image to the left) but I think I can correct for that with some suitable filler material.

Motor Coupling (Part 5)

This part is the most risky - it's job is to couple the shaft of the stepper motor with the threaded rod. To do this I am using a Nyloc nut on the threaded rod and a grub screw to attach the stepper motor shaft.

Part #5

If you are not familiar with Nyloc nuts they are a standard hexagonal nut with a nylon coating on the thread - they require a significant amount of force to screw on to (or screw off) the thread they are put on. This is fairly straight forward and relatively low risk - the hexagonal shape is a lot easier for a 3D printed plastic part to grip on to than a screw thread, by making the part a suitably tight fit you will get a coupling on that end that will transfer the rotational force with very little slippage.

My concern is the coupling to the circular shaft of the stepper motor - some motors provide a shaft with a flat surface on one side, the ones I am using are circular. My coupler design uses a grub screw to attach the motor end so it is purely a pressure based connect - at the moment I'm not sure if the force applied will cause slippage or not (I'm hoping not). This design would certainly not be suitable for applications that would require strong lateral forces (such as cutting through metal, even the thin layer of copper on a PCB). As I'm not planning to do that I'm hoping it will be fine.

Next Steps

I have completed the first design for all the 3D parts and have printed out most of them, the remaining parts are printing now. Over the weekend I will start to put everything together and see how well it all works out. I will be posting updates to my Google+ feed as I go about this and write up the results in a follow up post as soon as I get the chance.

The construction process should be fairly straightforward, how well it works once assembled is something I need to measure fairly carefully. I am hoping for at least an accuracy of 0.3mm - that would allow me to build the type of PCBs I want, if I can get an accuracy of 0.1mm out of the device that would be a great bonus.


Android Wear - A Makers View of the Samsung Gear Live

Sunday, July 13 2014 @ 01:01 PM

This post is a little bit different from the normal content I have here - I recently bought myself a Samsung Gear Live running Android Wear. Now that I've had it for a few days I thought it would be worthwhile doing a review from the point of few of someone who likes to tinker with their devices.

In this review I'm more interested in what I can do with the watch so I'm not going to go into a lot of details about the hardware and software that make it up. If you would like more details about those aspects I recommend the series of reviews at Ars Technica:

In my review I'll give an overview of the device itself and the Android Wear software that runs on it and then show you some ways you can start using it as an accessory for your own projects. I'd like to apologise in advance for the quality of the photos - it turns out to be very difficult to take good quality photos of an LCD screen that wants to turn off very quickly. Where possible I've used images from other sources instead.

Overview

Samsung have released a number of smart watches over the past few years, from the original Galaxy Gear (running Android) to the Gear 2 (running Tizen) and the Gear Fit. The Gear Live, despite being one of the first devices running Android Wear at launch seems to be almost a side project for them (it's not mentioned on their wearables site for example).

Unlike the version of Android for phone and tablets Android Wear seems to be far more tightly controlled by Google so the hardware vendor has much less influence on the behaviour of the device - just about everything I describe here (at least in terms of the software) will behave exactly the same way on the LG G Watch (the other launch device) as well as the upcoming Motorola Moto 360. The biggest differences involve form factor, battery life and what embedded sensors are included.

It's worth making clear that Google Wear devices are not standalone devices, they are an accessory for your phone - a bluetooth screen instead of a bluetooth headset if you like. Take away the phone (or even go out of range) and there is very little you can do with them (apart from tell the time of course).

To use the watch you need an Android phone running Android 4.3 or later - there is no support for iOS or Windows Phone and I doubt there ever will be. Choosing a wearable will lock you into the ecosystem - with Android Wear it is Google, the rumoured iWatch will be Apple. Migrating from one to the other will most likely be a difficult process.

Physical Appearance and Performance

Digital vs Real

Neither the Samsung or LG device could be called stylish - they are more solid, functional devices designed for use rather than looks. They are quite large and clunky for a watch, but not overly so (see the image to the right for a comparison). A nice feature of the Samsung over the LG is the curved back - this lets it fit comfortably on the curve of your wrist where a flat back may feel awkward given the size.

The display is nice and large, it's easy to read indoors but can be difficult to see in bright sunlight. The screen on the Samsung has a slightly higher resolution (320 x 320 pixels) and uses an OLED display rather than LCD.

The watch responds quickly and animations are smooth. The CPU embedded in the device is a quad-core ARM processor running at 1.2GHz with 512Mb of RAM so it has plenty of processing power available. Interestingly the LG and the Samsung both use exactly the same chipset in their watches - I'm assuming it's some sort of Google reference design that the manufacturers have then extended slightly.

An aside: I am forever surprised by the amount of computing power that we routinely carry around with us without thinking much about it. In the late 90s I worked with high end (at the time) Unix workstations worth many thousands of dollars that had less processing power and memory than this watch.

The battery life is more than acceptable - you do have to charge it every night much like a mobile phone but you easily get a full day worth of charge out of it. I've been using mine fairly heavily through the day from about 7:00 AM onwards and still have a 65% charge left by 6:00 PM when I get home - you could probably, at a stretch, get a charge to last two full days if needed.

Communications between the watch and the phone is done over Bluetooth and seems to have a range somewhere between 20 and 50 meters. This varies a lot though, it depends on a lot of external factors including radio interference. I can safely go to the next room without losing the connection but further than that is a bit random - at home it seems to work fine from anywhere in the house, at work more than a room away and it will drop out.

I've found the easiest way is to simply carry my phone in my pocket all the time, which a lot of people do anyway so it's not a big change in behaviour. There are a number of apps available already that will cause the watch to notify you when it is out of range (normally you just get a small icon in the top right of the screen). Currently I'm using the Find My Phone application for this and it has the added benefit of helping you to find your misplaced phone with an audio alert.

Overall there are not a lot of behavioural changes to make to start using the device - it simply replaces your existing watch. Rather than adding a new device to your collection you are simply substituting an existing one - unlike Google Glass the watches are far more subtle and quickly feel comfortable.

Setup

The setup process is driven through the phone - simply download the Android Wear application and follow the instructions it give you. This will find the device, synchronise it with your phone and then manage the communications for you. Once set up there is very little you need to do in terms of managing the device.

When you set it up out of the box it will download a firmware update (it has done this twice for me now, new features seem to be appearing on a regular basis). Over a Bluetooth connection this is a fairly slow process so be prepared to wait for a while.

One issue I had during setup was that it didn't recognise all the Android Wear compatible apps I already had on my phone - I had to power cycle the phone and use the 'Resync Apps' setting in the Android Wear application to get everything up to date.

Notifications

The primary purpose of the watch (apart from telling you the time) is to display notifications. Basically any notification that would normally appear on your phone will now appear on the watch as well. Cards from Google Now will be added as well which means you get all those predictive notifications (traffic reports, where you parked your car, etc) that make Google Now so useful. The interface uses the same card metaphor that Google Now and Google Glass use as well which makes it very easy to navigate on a small screen.

Main Screen

Initially notifications are shown on the main screen as small cards, swiping up will allow you to scroll through the current notifications. For each notification you can tap on it to get more information (the full text of an email for example) and then swipe left to display more detail or display the actions available for that notification. Swiping right will discard the notification altogether. It is a very simple set of operations that gives you a lot of flexibility and makes it extremely easy to deal with incoming notifications.

It seems like overkill to have a device that simply shows you notifications but it is really very useful. For a start, Google did a lot of work with the 4.3 version of Android to provide a richer interface to the notification system which means they are no longer limited to simple strings of text - they can be associated with images and linked back to the original application (or a smaller 'Wear' version of the app) so you can do a lot more things with them. The older, plain notifications will still show up as well so you don't have to wait for an upgrade to the application to see events from it on your watch.

You can filter the notifications you see as well - the Android Wear application on the phone has a settings dialog that lets you block notifications from specific apps. They will still appear on your phone but won't be sent to the watch itself.

It is difficult to describe how much of a difference this actually makes. After a few days of using the watch I am so used to it that it has become integral to how I work on a day to day basis. You often hear the term 'information overload' bandied around to describe how we are bombarded with small snippets of information on a daily basis - there is only so much you can do to reduce the amount of incoming information so the obvious next step is to simplify the management of that information, sorting the useful and important bits from the flow in the current context. Google Wear, if not solving the problem, certainly goes a long way in the right direction. The video below gives you a good overview of how you interact with it:

Now that I have the watch on I tend to keep my phone on silent all the time and inspect notifications on the watch to determine if it's something I need to deal with immediately, later or not at all. It's unobtrusive and avoids the 'always playing with his phone' perception (especially good in meetings). Of course you are just swapping 'playing with your phone' to 'playing with your watch' but the process is a lot quicker and far less distracting.

Wearable Applications

Google Wear is more of a reactive device - it's designed to let you quickly react to incoming events. That doesn't mean you can't instigate events on it though - this is where the applications come in.

Unlike the Android interface where you are presented with a collection of applications to chose from to launch most are started through a voice based interface. First you attract the devices attention with the 'OK Google' key phrase and then state what you want to do.

The speech recognition on the device is really well done (still not perfect, but good enough that you can use it every day without getting frustrate) and makes good use of natural sounding phrases such as 'send a text to contact name', 'take a note' and 'remind me to action tomorrow afternoon'.

I had to devote some time to clean up my contact list so the primary name for all contacts was something I would generally call them, instead of 'Tesla, N' for Nikola Telsa I might put 'Nick' or 'Nick Tesla'. This makes it more likely that the voice recognition will match the right contact. Of course I have 'Mum' and 'Dad' in the list :)

One complaint I have is that there is a very small window of opportunity to cancel the action if the voice recognition makes a mistake and it's not really obvious that you can cancel it (a button appears that looks more like a progress indicator than a button - tapping on it will actually cancel the operation). A text message I tried to send to my sister saying 'Are you at Shawns?' got interpreted as 'Are you trans?' and sent before I could cancel it (the response was 'WTF?'). As I said, the voice recognition is good, but not perfect.

Because, of course.

There are custom applications available (as in applications that get installed on the watch itself rather than 'Wear Aware' apps) and the number is growing on a daily basis. You don't really download an Android Wear application though, they are an add-on to a normal Android application - you install the primary application on your phone and (if it has one) the 'sidekick' application will be pushed to your watch. Naturally one of the first games to appear that plays directly on the watch is a Flappy Bird clone.

Like Glassware these apps can attach themselves to their own keyphrase or you can launch them by name by saying 'start application name' or navigating to them by touch. The touch option is a bit annoying - you can either say the 'OK Google' keyphrase or tap the screen to get into action mode, swipe up to get to a menu, scroll all the way to the bottom to see the 'Start ..' option, tap that and then select your application. I get the feeling Google really don't want to see a lot of applications that need to be 'started' - as I said it is more of a 'reactive' device and applications should really just allow you to do things with notifications sent to it by the host application running on the phone.

Your Own Apps

Now, as makers we would really like it to show our own notifications and trigger our own actions. It would be easy enough to simply send text messages or emails (they will show up as notifications) but it would be nice to have a an interface that is a bit less general than that. Here are some of the options that are available to you for that.

The Android SDK

Obviously you could write your own custom application, the Android SDK is available for free, supports Google Wear as well as 'standard' Android, runs on Linux, Windows and OS/X and you can deploy applications to your own device without going through the Play Store. If all you are interested in is sending notifications to the watch you don't even have to write a Google Wear device - just sending a normal phone notification (preferably through the new notification API) will do the trick.

If you already have experience developing Android applications this might be a good solution for you, if not it is a pretty steep learning curve to climb before you get the results that you want. You probably don't want to install a separate application for every device or set of events you want to see either.

If This Then That

If you haven't already played with IFTTT you probably should. Essentially it allows you to set up simple rules with a 'this' (event) side and a 'that' (action) side. Both 'this' and 'that' are selected from a fixed set of 'channels' (as I'm writing this there are 116 available channels) which include some popular hardware device interfaces and web services.

IFTTT has had an 'Android Device' channel for a while and has recently introduced an 'Android Wear' channel as well. On the 'this' side the channel allows you to trigger an event by pushing a button in the custom IFTTT application that gets pushed to your watch, on the 'that' side you can send notifications to your watch (with text and an appropriate image).

Unfortunately IFTTT isn't a very open service, if you want to interact with something that isn't already implemented as a channel you only have a few options available to you:

  1. Use the RSS channel to read an RSS or Atom feed from a server you control and use that to provide detail to IFTTT. You can use filters on the data in the RSS entry to trigger an appropriate action. The delay between you adding a new entry in the RSS file and it being processed by IFTTT can be very long though (measured in hours, or even days).
  2. Implement the WordPress API on a server you control and point the IFTTT 'WordPress' channel at it. The timing is a bit better than RSS (but not much) and it allows you to use it for the 'that' (action) side of the recipe as well.

Another downside is that activating a trigger requires you to either navigate to the IFTTT application by touch using the awkward process I described above or saying the phrase 'start I F T T T' which is not exactly intuitive. Despite this, if the services you want to integrate are already supported by IFTTT and you can accept a delay between the event occurring and the action being triggered this may be all you need.

InstaPush

One of the channels available on IFTTT is Instapush and you can use this directly through a very simple REST API as well as through IFTTT. Basically, this service allows you to send a notification to any iOS or Android device. On Android these notifications will automatically appear on your watch. At the moment in only supports basic text notifications, hopefully support for richer notifications will appear in a future release.

There is a little bit of set up required (read the Instapush Getting Started page for more details) but the API itself is very straight forward. Essentially you need an APPID and an APPSECRET string to identify yourself, an event type to identify the event being sent and a dictionary of trackers which are values to be inserted into the notification text.

Where I work we have a number of build processes that can take a very long time to complete - I wrote a small Python script to notify me when they start, succeed and fail so I don't have to keep checking the output log. The notification I get sent has the text 'Project '{project}' build has {status}' where project and status are variables passed to the event. To invoke it I simply use the command line like the following ...

buildevent.py test-project failed

... which will send a notification to my phone (and to my watch) with the text "Project test-project build has failed". The source for this utility looks like this:

#!/usr/bin/env python
#----------------------------------------------------------------------------
# Send build events via InstaPush (http://instapush.im)
#----------------------------------------------------------------------------
import sys
import json
import requests

#--- Instapush validation
APP_URL    = "http://api.instapush.im/post"
APP_ID     = "enter_appid_here"
APP_SECRET = "enter_app_secret_here"

#--- Usage information
USAGE = """
%s project status

  The 'project' parameter specifies the project name, the status describes
  the build status."
"""

def pushEvent(activity, trackers):
  global APP_URL, APP_ID, APP_SECRET
  headers = {"X-INSTAPUSH-APPID": APP_ID, 'X-INSTAPUSH-APPSECRET': APP_SECRET, 'Content-Type': 'application/json'}
  data = {"event": activity, "trackers": trackers}
  return requests.post(APP_URL, headers=headers, data=json.dumps(data))

if __name__ == "__main__":
  # Check command line arguments
  if len(sys.argv) <> 3:
    print (USAGE % sys.argv[0]).strip()
    exit(1)
  # Send out the event
  pushEvent('status', { 'project': sys.argv[1], 'status': sys.argv[2] })

The code to send an event is in the 'pushEvent()' function - only a few lines. I do cheat a bit and use the requests module to simplify making the REST request.

It would be very easy to integrate this into your application to send events from any source you like. I'm going to integrate this into the code driving my Bluebell device to send notifications to my phone (and watch) as well.

Conclusion

I certainly don't regret buying the watch - I came very close to getting the original Galaxy Gear when it came out but was put off by the lack of an SDK or any other way to customise what it displayed. The same went for the Pebble, although it did provide an SDK it seemed like a lot of work to get what I wanted displayed on the watch face.

Your mileage may very though, I had an advantage in that I was already deeply invested in the Google ecosystem so everything would integrate well without having to migrate email accounts, cloud services and the rest of my digital life to get the most out of it. For me this device was a natural extension of the services I already use and had the added benefit of being easy to talk to with existing services and some simple code. Given that it is based on an operating system I am already very familiar with means that I can do some more detailed development on it if I need to.

Although I'm hesitant to recommend that you should go out and buy one (everyones requirements are different) I can certainly recommend that you give it a serious look. Wearables are not going to go away anytime soon and replacing existing technology that we wear on our wrist every day with something that has a lot more functionality is not a huge leap.


Follow me on Google+ to see build images, construction notes and previews of upcoming projects.

Recommended Sites

  • EEWeb

    Electrical Engineering News, Resources, and Community.

  • Sprites Mods

    A collection of projects from a very talented engineer.

  • Blondihacks

    A great collection of hacks and projects by Quinn Dunki.

  • Embedded Projects

    Embedded Projects from Around the Web.

Donate Doge

Like the site? Be kind and send a few Dogecoin my way.
DAqGZFkVj9meRgHMve9W5KQshdvZ3UCtGF