Progress continues slowly... I’ve ported the code to the final processor, but then I found out that OSRAM is getting out of the OLED business.

So, first the processor.  SiLabs didn’t have a demo board for the exact processor I wanted to use, so I’ve been getting by with a similar board. It lacked two big features of the processor I wanted to use -- it had only 8KB of memory instead of 32KB, and it lacked the real-time clock that I plan on making use of.

In my original design, the processor kept track of the time.  A timer would count the crystal’s vibrations, and when it reached 16,384 cycles, it would interrupt the processor.  Since the crystal vibrated at 32.768 kHz, this equaled twice a second.  When interrupted, the processor would increment the seconds and checked to see if it overflowed -- if it did, it was reset to zero and the minutes incremented.  If the minutes reached 60, in a similar manner, it was reset and the hours were incremented.

This original design works great, but it means that the processor can never fully sleep -- otherwise it would stop keeping track of time.  It also means that if it ever loses its memory (due to a reset or a bug in the code), it’ll lose the time.  For a simple program, that’s fine... but the second version is going to be much more complicated, so it’ll be good to make timekeeping more robust.

The new processor offers a built-in clock, but it doesn’t keep track of hours and minutes. This clock is just a simple counter -- it’s 47 bits (meaning it counts from 0 to about 140,737,488,000,000) and counts at a rate of 16384 Hz.  This means that it can measure events as small as 1/16384th of a second, and it will count up to 2^32 seconds before overflowing.  That’s a lot of seconds -- 68 years, to be precise!

So, my design now keeps track of time like most heavy-duty unix-based machines.  It records the number of seconds that have ellapsed since 12:00 am January 1st, 1970.  I use some math to convert this count into year/month/day/hours/minutes/seconds.

In terms of hardware, it’s far easier to make a big 47-bit counter than it is to make 6 smaller counters and have them roll over at odd intervals.  Software is far more adept at handling special cases like leap year than hardware.  It can also better handle the error cases -- like, say, when you have 62 seconds.

Another benefit of keeping the time in only seconds is that it’s simple to tell amount of time between two events. For example, I can tell how many days old I am by subtracting the unix times of my birth and today, and then dividing by the number of seconds in a day.  It might be useful for a countdown to an alarm.

On the software side, I’ve also been working on drawing big characters.  I’ve got a routine that draws characters double-sized -- this way, I can reuse my small font table (768 bytes) instead of making a big-character font table (would be 3000 bytes, or 10% of all memory).  I’ve also added a huge version of the digits so that I can fill most of the display with just the time.  This takes an incredible amount of memory (3800 bytes!), but I’ve got a simple compression routine that will make it fit in 1900 bytes (still a lot of space!).  But, these digits look really good, and this is a watch, so I think it’ll be worth it.

-  -  -  -

The other bit of news is that I discovered that OSRAM is getting out of the OLED market.  They make the display I’ve been using & issued a notice in the summer that people needed to get their orders in before they stopped production.  I didn’t notice, so it’s off to find a new supplier.  There seems to be plenty of manufacturers of similar displays, and because they often use the same driver chips, they’ll probably be electrically and software-compatible.  But, I liked OSRAM’s product -- it was available in small quantities from Digikey, came with a datasheet, and a hacker-friendly connector.

The OSRAM’s connector (above, center) was a ribbon cable.  It mated to a small connector, and that connector soldered to the PC board.  By lifting a lever on the back of the connector, the ribbon could easily be removed & the two pieces worked on individually.  This is great because I glued the display in to the case -- it’s easier to work on the PC board when removed.

I was worried because a lot of OLEDs glue directly to a PC board & making that connection isn’t too hobbyist-friendly. The glueing uses special equipment to simultaneously apply heat and pressure. If you mess up this process, you’ll ruin the display and the PC board.  Also, if you accidently yank the OLED away from the PC board, there’s no way to fix it.  But, this process is more reliable than a connector, and it doesn’t take any room.  In fact, it can glue to the back of the PC Board, leaving more room for components on top.  Hopefully this means I can fit either a bigger battery (and get three glorious days out of a charge!!) or make a slimmer watch.

As I looked at options, I found an even better one.  It’s a flex circuit that you can solder to the PC board -- it can be mass-manufactured and be done by hand. It’s flat, but not easily removable (without desoldering).  So, I’ll use this type of connector. (sorry, I couldn’t find a picture)

Because the watch is designed around the OLED (both physically and aesthetically), changing it is a major overhaul.  But, with this, there is opportunity: Now that I know what to look for, I can pick a slightly different display that will work a lot better.

I’ve basically narrowed the selection down to three screens.  I’ve modeled how they affect the case:

From left to right:

1. 1.The current Osram display: 1.3”, 96 x 64
   

2. 2.A full color display, 0.7”, 96 x 96  (not really considering this, but it’s neat)
   

3. 3.A white display, 1.0”, 96 x 64
   

4. 4.A yellow display, 1.1”, 96 x 64  <-- the frontrunner
   

I’ve shown lots of things in the diagrams.  The blue outline is the case; the red outline is the OLED module; the yellow outline is the display area of the screen. I’ve put the modules in so that they’re exactly in the center of the watch -- but since the image isn’t in the center of the module, they’re placed in a little off-center.  The space between the aqua line and the display (red line) shows the unused off-center space.

The 4th display is the frontrunner because it still has a large display, but it’s shorter (shorter = less space between the straps). This will allow the watch to be shorter, too, so it’ll fit under a sleeve better.

OSRAM-based watch: 37.8 x 37.7

frontrunner design: 35 x 33.8

... so it’s off to see if I can score some samples for a prototype.