States and Modes

You need to split your application into states.

A state is just a way to swap code in and out as needed. When you switch states, the active code is discarded and the new code is swapped in.

You could write an app that uses up to ~30kb of code and/or data, but there is only ~2kb of RAM. This is why you need to use states, there is no paging and you couldn’t fit that in!

There is room for some common code that all your states share, and of course there is space for variables, along with a database API for persistent data.

The first few states are reserved for handling common events. The rest you can use for anything you want - you just ask the kernel to switch you whenever you need it!

if (foo > bar) {
    coreRequestStateChange(FOOBAR_STATE);
}

A mode is just a foreground application.

Your app is (probably) providing a mode, but you can also add background tasks, periodic tasks, and so on.

Requesting a mode change is sort of like exit(), the next app will gain control.

coreRequestModeChangeNext();

Events

Each state needs an event handler. A super simple one would be like this:

void default_state_manager(void)
{
    switch (CORECurrentEvent) {
        // This is called when this state becomes active.
        case COREEVENT_STATEENTRY:
            coreEnableSwitchReleaseEvents();
            coreAllowKeys(COREALLOWALLSWITCHES);
            break;
        // This is called when the user pulls the crown out.
        // When they push it back in, you get a CROWN_HOME event.
        // It can be rotated in either home or set positions.
        case COREEVENT_CROWN_SET:
            coreRequestStateChange(CORESETBANNERSTATE);
            break;
        // You can get button events too, like start/split:
        case COREEVENT_STARTSPLITDEPRESS:
            show_message();
            break;
        // The mode button probably means the user wants to exit...
        case COREEVENT_MODEDEPRESS:
            coreRequestModeChangeNext();
            break;
    }

    return;
}

In general, you can ignore any event you don’t care about.

Services

The kernel takes care of handling the hardware, dispatching events to you and provides various services.

Things like timers, generating tones (beeps), scrolling the display, access to database records, etc.

uint8_t banner[] = {
    LCDBANNER_COL10,
    DM5_H, DM5_E, DM5_L, DM5_L, DM5_O, DM5_EXCLAMATION,
    LCD_END_BANNER
};

lcdClearDisplay();

// Draw "hello!" using kernel services.
lcdDispBannerMsg(&banner);

The watch has a crown - and you can ask the kernel to configure it in a few different ways. For example, you might want pulse mode so you can monitor how quickly the user is turning it.

It has a backlight, you can control that from software too.

Simulator

Luckily there’s a really good simulator available, so you don’t have to sit through tedious resets everytime you make a typo. It’s actually an open source 3rd party tool, Virtual Datalink (source).

Sadly it’s for Windows only. I would port it to Linux, but it’s written in Delphi… is it feasible to port it to free pascal? Let me know!

It has conditional breakpoints, a dissasembler, save states, resource and power analysis. I’ve found it pretty capable.

Tips

• Found a watch but missing the cable? It uses the standard USB type-a pinout with an odd connector, you can probably just use an old USB cable and alligator clips.
• Timex used the same connector on a much less desirable device called the T5G751 (probably other model variants too). These are easy to find at reasonable prices (often < $10 at the time of writing), so you can simply toss the device and keep the cable (example).
• There was a m851 variant called the “dress edition”, it has identical specs but a different body. It is sometimes listed with a different model number (example).