Timex M851 User Manual
M851 WristApp Design Guide
Timex Corporation
July 2003
M851 WristApp Design Guide Rev 1.2
DOCUMENT REVISION HISTORY
REVISION: 1.0 DATE: 07/25/2002 AUTHOR: NINO ALDRIN L. SARMIENTO
AFFECTED PAGES DESCRIPTION
All Created document.
REVISION: 1.1 DATE: 04/09/2003 AUTHOR: NINO ALDRIN L. SARMIENTO
AFFECTED PAGES DESCRIPTION
121 Added software reset sequence.
122,123 Added HTML support for description file.
REVISION: 1.2 DATE: 07/09/2003 AUTHOR: NINO ALDRIN L. SARMIENTO
AFFECTED PAGES DESCRIPTION
11 Corrected icons for alarm and stopwatch.
Timex Corporation i
M851 WristApp Design Guide Rev 1.2
TABLE OF CONTENTS
1 INTRODUCTION ................................................................................................................................ 1
1.1 APPLICABLE DOCUMENTS ...............................................................................................................1
1.2 DEFINITION OF TERMS..................................................................................................................... 1
2 M851 HARDWARE ............................................................................................................................. 2
2.1 MICROCONTROLLER........................................................................................................................ 2
2.2 LCD................................................................................................................................................2
2.3 SWITCHES........................................................................................................................................ 2
2.4 LAMP............................................................................................................................................... 3
2.5 BUZZER ........................................................................................................................................... 3
2.6 USB DATALINK............................................................................................................................... 3
2.7 EEPROM........................................................................................................................................ 4
3 M851 PLATFORM............................................................................................................................... 5
3.1 OVERVIEW....................................................................................................................................... 5
3.2 KERNEL ARCHITECTURE ................................................................................................................. 6
4 WRISTAPP DESIGN GUIDE............................................................................................................. 7
4.1 NAMING CONVENTIONS................................................................................................................... 8
4.2 FILES AND DIRECTORIES.................................................................................................................. 9
4.2.1 Header Files ........................................................................................................................... 9
4.2.2 Source Files............................................................................................................................9
4.2.3 Build Directory.......................................................................................................................9
4.3 APPLICATION SETUP PARAMETERS................................................................................................ 10
4.3.1 Application Offset Mask........................................................................................................ 10
4.3.2 Timer Resource Requirements..............................................................................................10
4.3.3 Icon Resource ....................................................................................................................... 11
4.3.4 Memory Requirements..........................................................................................................11
4.3.5 Application Configuration Data........................................................................................... 12
4.3.6 Application ID ...................................................................................................................... 12
4.3.7 Address Control Block.......................................................................................................... 13
4.3.8 Sample Application Parameter Template............................................................................. 13
4.3.9 Application Initialization...................................................................................................... 14
4.4 APPLICATION STATE HANDLERS ................................................................................................... 15
4.4.1 Application Framework........................................................................................................ 15
4.4.2 State Transition Diagram ..................................................................................................... 15
4.4.2.1 A State Transition Diagram..............................................................................................15
4.4.2.2 Application State Transition Diagram .............................................................................. 15
4.4.2.3 Implementing The Application State Transition Diagram................................................ 16
4.4.3 State Index ............................................................................................................................ 18
4.4.4 System Events........................................................................................................................ 19
4.4.5 Requesting System Events..................................................................................................... 22
4.4.5.1 Switch Depressions........................................................................................................... 22
4.4.5.2 Switch Releases ................................................................................................................ 23
4.4.5.3 Popup Cancel Event.......................................................................................................... 23
4.4.5.4 Ring Edges and Pulses...................................................................................................... 23
4.4.5.5 Icon Refresh...................................................................................................................... 24
4.4.5.6 End of Scrolling................................................................................................................ 24
4.4.5.7 Resource Updates ............................................................................................................. 24
4.4.5.8 Timeouts...........................................................................................................................24
4.4.6 State Manager....................................................................................................................... 25
Timex Corporation ii
M851 WristApp Design Guide Rev 1.2
4.4.6.1 Display Clearing On State Change ................................................................................... 25
4.4.7 Mode Banner State Handler ................................................................................................. 25
4.4.8 Default State Handler........................................................................................................... 28
4.4.9 Set Banner State Handler ..................................................................................................... 28
4.4.10 Set State Handler..................................................................................................................29
4.4.11 Popup State Handler............................................................................................................. 30
4.4.11.1 Special Time Zone Check Popup Processing................................................................ 30
4.4.12 Password Entry State Handler.............................................................................................. 30
4.5 BUILT-IN STATE HANDLERS .......................................................................................................... 30
4.6 TIMER RESOURCE USAGE.............................................................................................................. 33
4.6.1 Display Update Events.......................................................................................................... 33
4.6.2 Popup and Event Generation................................................................................................ 33
4.6.3 Time Of Day Resource.......................................................................................................... 34
4.6.4 Backup Resource .................................................................................................................. 35
4.6.5 Time Zone Check Resource................................................................................................... 36
4.6.6 Timer Resource..................................................................................................................... 37
4.6.7 Stopwatch Resource.............................................................................................................. 39
4.6.8 Synchro Resource ................................................................................................................. 40
4.7 APPLICATION SYSTEM DATA......................................................................................................... 41
4.8 APPLICATION DATABASE DATA .................................................................................................... 42
4.9 SYSTEM VARIABLES...................................................................................................................... 42
4.10 COMMON VARIABLES.................................................................................................................... 44
4.10.1 Foreground Use.................................................................................................................... 45
4.10.2 Background Handler Use ..................................................................................................... 45
4.11 BACKGROUND HANDLER............................................................................................................... 45
4.11.1 Kernel Variables................................................................................................................... 48
4.12 DISPLAY SERVICES........................................................................................................................ 48
4.12.1 Character Sets ...................................................................................................................... 49
4.12.2 Displaying Numbers ............................................................................................................. 55
4.12.3 Displaying Alphanumeric Characters .................................................................................. 56
4.12.4 Displaying Messages ............................................................................................................ 56
4.12.5 Clearing Display Regions..................................................................................................... 57
4.13 MODE BANNER.............................................................................................................................. 58
4.13.1 Handling............................................................................................................................... 58
4.13.2 Banner Message Format....................................................................................................... 58
4.14 MODE CHANGE ............................................................................................................................. 59
4.15 STATE CHANGE ............................................................................................................................. 59
4.16 ICONS ............................................................................................................................................ 60
4.17 GENERIC BLINK SERVICES............................................................................................................. 62
4.18 SCROLL SERVICES ......................................................................................................................... 62
4.19 PASSWORD PROTECTION ............................................................................................................... 63
4.20 SETTING ........................................................................................................................................ 64
4.20.1 CW/CCW Event Swapping.................................................................................................... 64
4.20.2 Ring/Crown Acceleration ..................................................................................................... 65
4.21 TIMEOUT SERVICES .......................................................................................................................66
4.22 POPUPS.......................................................................................................................................... 66
4.23 APPLICATION PEEK SERVICES ....................................................................................................... 67
4.24 BACKGROUND TASKS.................................................................................................................... 67
4.25 APPLICATION REQUESTS ............................................................................................................... 68
4.26 USING DATABASE FILES LOCATED IN EEPROM........................................................................... 71
4.26.1 Database Structures and Access........................................................................................... 71
4.26.1.1 Sequential Database Structure ...................................................................................... 71
4.26.1.2 Fixed-Sized Random Database Structure...................................................................... 72
4.26.1.3 Variable-Sized Random Database Structure................................................................. 74
4.26.1.4 Link-List Database Structure........................................................................................76
4.26.2 Database Usage Macros....................................................................................................... 78
Timex Corporation iii
M851 WristApp Design Guide Rev 1.2
4.26.3 Opening and Closing a Database......................................................................................... 79
4.26.4 Upload and Download of Database...................................................................................... 79
4.26.5 PC Synchronization of Watch Data......................................................................................79
4.27 MELODY SERVICES........................................................................................................................ 80
4.27.1 Melody Table Structure ........................................................................................................ 81
5 COUNTER WRISTAPP: PUTTING IT ALL TOGETHER.......................................................... 83
5.1 SPECIFICATION .............................................................................................................................. 83
5.2 STATES.......................................................................................................................................... 85
5.2.1 State Transition Diagram ..................................................................................................... 85
5.2.2 Banner State.......................................................................................................................... 86
5.2.3 Default State ......................................................................................................................... 87
5.2.4 Set Banner State.................................................................................................................... 87
5.2.5 Set State ................................................................................................................................ 87
5.3 STATE INDEX................................................................................................................................. 88
5.4 USING THE WRISTAPP WIZARD TO CREATE TEMPLATES .............................................................. 88
5.4.1 Step 1 of 3............................................................................................................................. 88
5.4.2 Step 2 of 3............................................................................................................................. 89
5.4.3 Step 3 of 3............................................................................................................................. 90
5.4.4 File Template Generation..................................................................................................... 91
5.5 STATE FILES ..................................................................................................................................92
5.6 BACKGROUND HANDLER............................................................................................................... 92
5.7 PARAMETER FILE .......................................................................................................................... 93
5.8 MISCELLANEOUS FILES ................................................................................................................. 94
5.9 DIRECTORY STRUCTURE................................................................................................................ 95
5.10 CODING THE WRISTAPP ................................................................................................................ 96
5.10.1 Header File........................................................................................................................... 96
5.10.2 Variable File......................................................................................................................... 97
5.10.3 Banner State Handler ........................................................................................................... 98
5.10.4 Default State Handler........................................................................................................... 99
5.10.5 Set Banner State Handler ................................................................................................... 102
5.10.6 Set State Handler................................................................................................................103
5.10.7 Background Handler........................................................................................................... 105
5.10.8 Display Routines................................................................................................................. 106
5.10.9 Utility Routines...................................................................................................................108
5.11 CREATING THE WRISTAPP........................................................................................................... 111
5.11.1 PC Interface Parameter List............................................................................................... 112
5.11.2 Source File Map ................................................................................................................. 112
5.11.3 Saving the Current Workspace ........................................................................................... 116
5.11.4 Creating the Build Scripts................................................................................................... 116
5.11.5 Executing the Build Scripts................................................................................................. 117
5.11.6 Creating the WristApp Downloadable Files....................................................................... 118
5.11.7 WristApp Memory Usage Analysis ..................................................................................... 120
5.11.8 Downloading and Testing the WristApp............................................................................. 120
5.11.9 Creating a Description File................................................................................................ 122
5.11.10 Distributing the WristApp............................................................................................... 123
6 TRADEMARKS ............................................................................................................................... 123
Timex Corporation iv
M851 WristApp Design Guide Rev 1.2
1 Introduction
The M851 Kernel is a platform that is geared for developing a variety of applications that can be
incorporated into the operating system during power up or downloaded to EEPROM through USB Datalink
communications. Refer to the M851 Application Design Guide for an overview of the M851 Kernel and
how applications are processed in the M851 Kernel.
This document serves as a guide for developing a WristApp.
1.1 Applicable Documents
The following documents serves as detailed reference in the creation of this document.
• M851 Application Design Guide
• M851 WristApp API Reference Guide
• S1C88349 Core CPU Manual
1.2 Definition of Terms
ACB
ADD
ASD
API
APP
Common Memory Area
EEPROM
Heap
KERNEL
WristApp
Overlay
Application Control Block
Application Database Data. This is where application database
records are stored.
Application System Data. This is where application will store
variables required for its operation
Application Programming Interface
An application.
Memory area allocated for use by all application.
Electrically Erasable Programmable Read Only Memory. External
storage for the watch. Data and code must be loaded into internal
memory prior to to be used or executed.
Memory allocated for the active application.
Encompasses all components making up the operating system:
display, communication, resources, melody generator, hardware
drivers, database, etc.
An EEPROM-based application.
A memory area allocated for code swapping of an EEPROM-based
application.
Timex Corporation 1
M851 WristApp Design Guide Rev 1.2
2 M851 Hardware
This section defines the hardware components in the M851 Watch.
2.1 Microcontroller
The microcontroller of the M851 is the EPSON 88349. It is an 8-bit microcontroller having 48Kbytes of
ROM and 2Kbytes of RAM. It has built in hardware components to attached external devices like I/O
ports, serial port, LCD, timers, etc. The operating system and a number of internal applications are masked
in ROM.
2.2 LCD
This serves as the information window of the watch. There are four regions in the viewing area:
Regions Description
Icons Unique icons (12) that can be used to shows status of system and
application.
Upper Dot-Matrix An 11 x 5 dot matrix area. Able to display 2 characters in either
fixed or proportional fonts.
Segment Regions Allows for the display of 6-digit segmented digits.
Main Dot Matrix An 42 x 11 dot matrix area. Able to display characters in either
fixed or proportional fonts, large and regular size.
Two lines are available for writing in this area when using the
regular sized fonts.
2.3 Switches
The system provides eigth switches whose functionality and use is defined by the user interface. The
kernel sends out switch activity to the foreground application through system events for processing.
Timex Corporation 2
M851 WristApp Design Guide Rev 1.2
Switch Name Switch Type
START/SPLIT Momentary Close
STOP/RESET Momentary Close
MODE Momentary Close
EL Momentary Close
HOME Permanent
SET1 Permanent
CW Permanent
CCW Permanent
2.4 Lamp
The display device is illuminated by an Electo-Luminescent (EL) display. The Night-mode feature is
controlled by the kernel.
2.5 Buzzer
This will convert the digital signals generated inside the microcontroller into audible tones. Through a
melody generator provided by the kernel, complex melodies can be generated following a melody structure.
2.6 USB Datalink
This includes the physical components that allows two-way communications between the watch and the
PC. The PC serves as a user interface to the watch. It coordinates and controls the information that will be
transferred to and from the watch. With the PC, the user can do the following:
• Activate or deactivate applications
• Customized mode names
• Select the order of the active applications in the mode list
• Set time and date
• Download EEPROM-based applications
• Download new databases for active applications
• Upload information stored in the watch
• Etc.
An internal application, COMMUNICATION MODE, interprets and processes all the commands being
sent from the PC. This mode is automatically enabled when an active USB cable is plugged to the watch.
Timex Corporation 3
M851 WristApp Design Guide Rev 1.2
2.7 EEPROM
Microcontrollers have limited internal memory that can be used to store data and applications. The
EEPROM serves as a high-capacity storage device that can be used to store data or code. The
microcontroller is not capable of directly executing code stored in EEPROM. It must first be copied into
internal memory prior to any processing or execution.
Utilities are provided by the kernel to facilitate accessing data from the EEPROM.
Timex Corporation 4
M851 WristApp Design Guide Rev 1.2
3 M851 Platform
This section provides an overview of the M851 Kernel Architecture.
3.1 Overview
The M851 Kernel is a real-time operating system that serves as a platform for executing applications in a
state machine framework. The kernel is composed of the core, hardware, display, audio, timer resource,
EEPROM manager, utilities, and communications.
Core
Hardware Drivers
Display Drivers
Audio Drivers
Timer Resource
Database Utilities
Utilities
Communications
The core module controls the operation of the entire system. It makes sure
that all hardware events are processed in a timely manner and that
applications operate in a predefined manner. The core architecture defines
how applications are structured to work within the system.
The core manages the resources that are made available to applications as
well as manage the application. The core processes hardware events, and if
required, it will pass system events corresponding to the hardware event to the
application for further (and custom) processing.
The Hardware drivers provide a layer abstraction to the actual implementation
on how to operate any hardware. The hardware macros are available for use
by the core and the applications. Some macros are to be used exclusively by
the kernel.
The Display drivers are an extension of the hardware drivers dedicated only to
display services. It is a high level driver to allow the kernel and applications
to display any data in any region on the display hardware. It provides
complex display services such as blinking and scrolling.
The Audio drivers are an extension of the hardware drivers dedicated only to
the melody generation. It is a high level driver that provides services to
generate complex melodies.
The Timer Resources handles all time keeping requirements for an
application. A resource contains both data and code to control the data.
The available resources are Time-of-Day resource, Time Zone Check
resource, Backup resource, Timer resource, Stopwatch resource, and the
Synchro resource.
The resources are executed in the background. It provides macros to
manipulate every aspect of its operation. The resource frees up the
application from having to supply code to do timing specific operations such
as keeping track of time, timer functions, and comparing time data.
Provides utilities to access (read and write) records stored in EEPROM. It
provides a number of database access operations namely: sequential, fixedsized random, variable-size random and double linked list access.
The Utilities modules provides common functions that may be used by any
applications. For example: conversions, formatting, lookup, common banner
display, pseudo-randon number generation, etc.
The Communication module consists of two modules that work together.
Timex Corporation 5
M851 WristApp Design Guide Rev 1.2
The first module are the the low level drivers that communicates
with the serial port to receive and pre-process the data packets
received through datalink.
The second module is the communication application. This receives
the valid data packets and processes the command embedded in the
packet.
3.2 Kernel Architecture
The Kernel manages a memory area known as Heap Memory. The Heap Memory serves as a depository
for code or data that an application will use. It also allocates space used for code overlay for swapping in
EEPROM-based applications code and code for periodic tasks.
The Kernel interfaces to the application through the Application Configuration Data (ACD) and the
Application Control Block (ACB). The ACD and ACB provides the kernel with the info on how an
application is configured in the system, the location of the application data, location of the state manager
and the resource handler routines.
With this generic structure, the Kernel can process any application regardless of it being stored in internal
memory or external memory. Adding new applications to the system is facilitated by this architecture
whether the application will be added during the design time or after the microcontroller has been
permanently programmed.
Due to its dependence on heap memory, the Kernel is limited in its ability to spawn a larger number of
application in memory due to limited internal memory of the microcontroller.
Timex Corporation 6
M851 WristApp Design Guide Rev 1.2
4 WristApp Design Guide
A WristApp is basically an EEPROM-based application. The kernel will support multiple EEPROM-based
applications that also has a fixed address for its overlay area. Applications of this type can be larger than
the maximum available heap memory. When an EEPROM based application becomes the foreground
application through a mode change, the kernel will load the banner state into the application state handler
overlay area. On the succeeding request for a state change, the kernel will load the new state handler code
into the overlay area for execution.
The overlay memory area is used by all EEPROM-based applications to store both common and state code
and has a fixed location in memory.
The ASD is located in the heap. Each EEPROM based application will have its own dedicated ASD
section in the heap.
The code space is composed of two sections: common code and the application states. The common code
has all the routines that will be called by the kernel and the application states. These routines are the:
resource handler, mode banner message (if defined in application), display routines, and utility routines.
The application states are the state handlers for each state used in the application.
Since only one state can be in the foreground at any given time, the kernel will automatically swap in the
required state handler into the state section. This makes for efficient use of code space and allows for
larger applications to be built even with limited physical memory. The figure below shows the memory
usage of the overlay area.
HEAP
TOD ASD
COMM ASD
EEPROM APP 1
COMMON
EEPROM APP 1 STATE 3
EEPROM OVERLAY AREA
EEPROM APP 1 ASD
EEPROM APP 2 ASD
EEPROM
EEPROM APP 1 ADD
EEPROM APP 2 ADD
EEPROM APP 2
COMMON
EEPROM APP 2 STATE 0
EEPROM APP 2 STATE 1
EEPROM APP 2 STATE 2
EEPROM APP 2 STATE 3
EEPROM APP 1
COMMON
EEPROM APP 1 STATE 0
EEPROM APP 1 STATE 1
EEPROM APP 1 STATE 2
EEPROM APP 1 STATE 3
Timex Corporation 7
M851 WristApp Design Guide Rev 1.2
The total size requirement for an EEPROM-based application must not exceed the HEAP memory
specified by the system. The EEPROM-based application overlay usage is computed based on the sizes of
the common code and the largest state handler. The overlay size is 900 bytes.
COMMON CODE
STATE 0
STATE 1
STATE 2
STATE SECTION
APPLICATION MEMORY USAGE
4.1 Naming Conventions
A three character prefix application code will be used to distinguish application owned labels and
subroutines.
Type Usage
Constants
Variables Prefix is in upper case with mixed case for descriptive variable
Bit Variables The letter ‘B’ in lower case with the application prefix code in upper
All upper case characters.
Example:
TODNUMBEROFRESOURCE equ 2
TODSECONDSDATAOFFSET equ 0
name.
Example:
TODSecondData
TODMinuteData
case and mixed case for descriptive bit variable name.
Example:
bTODTrackingHoldToSet equ 00000001B
Timex Corporation 8
M851 WristApp Design Guide Rev 1.2
Labels
Subroutines
Filenames MSDOS Filename convention. Eight character filename (maximum)
All in lower case characters and descriptive of its function within the
subroutine or program flow.
Example:
todchecknextevent
Prefix is all in lower case with mix case for descriptive label name.
Example:
todDefaultStateManager
todResourceRefreshHandler
with 3 character extension (maximum). ASM for source code files.
H for header files.
Example:
toddef.asm
tod.h
4.2 Files and Directories
4.2.1 Header Files
Header files are stored under the H directory of an application. They will have the extension *.H.
Generally, applications will have three header files associated with them. Namely:
General header File
Macro File
Variable File
Contains application specific equates used by an application as well
as redefinitions of system equates.
Contains macro definitions that will be used by the application.
Contains the offset definitions for variables as well as definitions for
the application system and application database heap memory
requirements. Bit definitions of application status flags are defined
in this file.
4.2.2 Source Files
Source files are stored under the SRC directory of an application. They will have the extension *.ASM.
Typical source files are for the banner state, default state, set banner state, set state, popup state,
background handler, display routines and utilities.
4.2.3 Build Directory
The build directory is where all outputs of the build scripts will be stored. This will allow the source and
header directory free from the clutter of multiple object and list files. On a successful build of a wristapp,
this directory will contain the parameter and code binary files for download to the watch.
Timex Corporation 9
M851 WristApp Design Guide Rev 1.2
4.3 Application Setup Parameters
The kernel will use these parameters to setup an application. The application will not be initialized if the
kernel cannot allocate all the required system resources.
Application setup is done during power up for enabled ROM-based applications. During a communication
session, any application can be initialized under PC control. In both operations, the setup parameters
remain the same.
Most of the parameter settings indicated in this section (after some manipulation) will be stored in the
kernel to the Application Configuration Data and Application Control Block. Each application has its own
dedicated ACD and ACB.
4.3.1 Application Offset Mask
The Application Offset Mask specifies whether data specified in the parameter table needs to be converted
to the absolute address in heap memory. This is because the kernel will allocate available heap memory for
application system data as it is initialized in the system.
The Application Control Block addresses are all absolute memory addresses in internal memory.
This is the structure of the Application Offset Mask
Byte Bit Offset Mask Name
0 0
1
2
3
4
5 Unused
6 Unused
7 Unused
bCOREAppSystemDataOffset
bCOREAppDatabaseDataOffset
bCOREAppStateManagerOffset
bCOREAppResourceHandlerOffset
bCOREAppModeNameOffset
0 = Absolute Address
1 = Relative Address
0 = Absolute Address
1 = Relative Address
0 = Absolute Address
1 = Relative Address
0 = Absolute Address
1 = Relative Address
0 = Absolute Address
1 = Relative Address
4.3.2 Timer Resource Requirements
The application will specify the number of timer resources it would require for its operation. It will retain
ownership of the resource until it is removed from the system. When a resource is reserved, the kernel will
place the index of the resource (in order of allocation) at the start of the application system data area.
Byte Timer Resource Type Maximum
0 Time of Day Resource1 4
1 Backup 2
2 Time Zone Check Resource 5
3 Timer Resource 3
4 Stopwatch Resource 2
5 Synchro Resource 1
1
The TOD application owns three TOD resources. The kernel owns one TOD resource.
Timex Corporation 10
M851 WristApp Design Guide Rev 1.2
The resource index always start at 0x00. For example, the TOD Resource index are 0x00, 0x01, 0x02 and
0x03. The Timer Resource index are 0x00, 0x01 and 0x02.
4.3.3 Icon Resource
The application will specify the LCD flags it will use to convey status information when operating in
background mode. These status flags will be visible only when the primary mode (TOD Application) is the
foreground application. For example, a timer application will use the hourglass icon to indicate that it is
running in the background.
A maximum of three applications can own and reserve an LCD icon during initialization. The kernel will
check the usage status from each of the owners to determine how to display the icon. A BLINK condition
has precedence over an ON or OFF status.
Byte Bit Icon Bit Name Icon Graphic
0 0 bCOREAppFlag_L
1 bCOREAppFlag_A
2 bCOREAppFlag_P
3 bCOREAppFlag_NOTE
4 bCOREAppFlag_HOURGLASS
5 bCOREAppFlag_RING
6 bCOREAppFlag_ARROW
7 bCOREAppFlag_ALARM
1 0 bCOREAppFlag_MOON_Flag
1 bCOREAppFlag_STP
2 bCOREAppFlag_TIMELINE_Flag
3 Unused
4 Unused
5 Unused
6 Unused
7 Unused
NOTE: When an application is in foreground mode, it has full use of all the icons and is not restricted to
the display limitations imposed by this parameter. The Timeline Icon should not be used (displayed) by the
application owner when it is currently the foreground application.
L
A
P
Note
Hourglass
Ring
Arrow
Alarm
Moon
Stopwatch
Timeline
4.3.4 Memory Requirements
The application will specify the number of bytes it requires of heap memory space. Heap memory can be
used for both data and code. An application is not initialized if the kernel does not have enough memory to
be allocated.
Word (16-bit) Heap Memory Use
Timex Corporation 11
M851 WristApp Design Guide Rev 1.2
0 Application Code Size
1 Application System Data Size
2 Application Database Size
For EEPROM-based applications, the code size and database size define the amount of EEPROM memory
to be allocated. Application System Data size will be the amount of memory from the internal memory
heap allocated for the ASD.
Although the code size for EEPROM-based apps can be larger than the wristapp overlay area size, the
common code section and the state handler code must fit within the overlay area limitations (900 bytes).
4.3.5 Application Configuration Data
The application will specify through the Application Configuration Data how the application is going to
behave in the kernel when initialized or executed. It also provides additional information to the kernel
other system requirements.
Byte Bit Bit Name Description
0 0
1
2
3
4
5
6
7
The table below shows some predefined configuration data definitions for WristApps.
COREACDEEPROMAPP
bCOREACDReserved
bCOREACDCodeLocation
bCOREACDDatabaseDataLocation
bCOREACDCodeInvalid
bCOREACDDatabaseModified
bCOREACDInvalidDatabase
bCOREACDPasswordRequired
bCOREACDUserSpecifiedModeName
Configuration Byte Application
Restricted. Kernel Use Only.
0 = Internal Memory
1 = External Memory
0 = Internal Memory
1 = External Memory
1 = Code is invalid
1 = Database modified by user
1 = Database is invalid/not present
1 = Password required for access
1 = Mode name located in
EEPROM
CODE external. ADD external.
4.3.6 Application ID
This two-byte parameter is a unique identifier of an application. The application type is used during an
application peek operation where the kernel searches for the first matching application for peeking.
The first byte indicates the application type, while the second byte indicates an instance of that application.
By default, all ROM based application have an instance value of 0x00. If another instance of a ROM
based application is initialized, the system will increment the Instance Number by 1.
Byte Description
0 Application Type
1 Application Instance Number
Code Application Type
000H COREAPPTYPESYSTEM
002H COREAPPTYPEOPTION
011H COREAPPTYPEDATE
020H COREAPPTYPECHRONO
021H COREAPPTYPETIMER
Timex Corporation 12
M851 WristApp Design Guide Rev 1.2
022H COREAPPTYPESYNCHROTIMER
023H COREAPPTYPECOUNTER
040H COREAPPTYPECONTACT
050H COREAPPTYPETASK
060H COREAPPTYPENOTES
070H COREAPPTYPESCHEDULE
080H COREAPPTYPETIDE
090H COREAPPTYPEDEMO
0A0H COREAPPTYPEGAME
0E0H COREAPPTYPEALARM
0E1H COREAPPTYPEAPPOINTMENT
0E2H COREAPPTYPEOCCASION
Application types above index 0xDF are considered to be applications that is dependent upon the primary
time zone settings. This will allow the background handler of these application to be called with the event
COREEVENT_PRIMARY_TIME_CHANGE whenever the primary time zone data changes.
NOTE: The instance number may be different than the value specified in this parameter table if
downloaded through a PIM.
4.3.7 Address Control Block
The kernel uses these parameters to locate the start address of both data and code used during application
execution. With the data in the Application Offset Mask, the kernel will convert the offset parameters into
absolute memory addresses.
Word (16-bit) Description
0 System Data Address/Offset
1 Database Data Address/Offset
2 State Manager Address/Offset
3 Resource Handler Address/Offset
4 Application Banner Name Address/Offset
The WristApp build script provides equates to plug into offset 2 and 3 of the Address Control Block. So
use the following below:
Word (16-bit) Description
0 System Data Address/Offset
1 Database Data Address/Offset
2
3
4 Application Banner Name Address/Offset
NOTE: The string data array referenced by the Application Banner Name must follow the Application
Banner Message Format.
CODESTATEADDRESS
CODECOMMONADDRESS
4.3.8 Sample Application Parameter Template
The following is a sample application parameter template for a WristApp.
Timex Corporation 13
;============================================================
; ACB offset mask.
;============================================================
M851 WristApp Design Guide Rev 1.2
; Application System Data is located in heap.
; Other ACB entries are located either in ROM or EEPROM.
db bCOREAppSystemDataOffset
;============================================================
; Number of resources required.
;============================================================
db 00h ; TOD
db 00h ; Backup
db 00h ; Time Zone Check
db 00h ; Timer Resource
db 00h ; Stopwatch Resource
db 00h ; Synchro Timer Resource
;============================================================
; Flag(s) ownership.
;============================================================
db 0 ; LCD Flags 1
db 0 ; LCD Flags 2
;============================================================
; Heap size requirements.
;============================================================
dw 0280H ; Code
dw CNTSYSTEMDATASIZE ; ASD
dw CNTDATABASEDATASIZE ; ADD
;============================================================
; Application Configuration Data Byte.
;============================================================
db COREACDEEPROMAPP ; Code is external.
;============================================================
; Application Unique ID.
;============================================================
db COREAPPTYPECOUNTER ; Application type
db 01h ; Application instance number
;============================================================
; ACB Parameters.
;============================================================
dw CNTSYSTEMDATASTARTOFFSET ; ASD address offset.
dw CNTDATABASESTARTOFFSET ; ADD address offset.
dw CODESTATEADDRESS ; App state manager address
dw CODECOMMONADDRESS ; App background handler address
dw lcdBannerMsg_COUNTER ; App mode name function address
4.3.9 Application Initialization
A WristApp is initialized for the first time when the current communication session is completed. The
WristApp’s background handler is processed with the system event COREEVENT_INIT. This will allow
the WristApp to setup the required parameters in the ASD section. It could also use this time to update
ASD information from the database header info if available.
Timex Corporation 14
M851 WristApp Design Guide Rev 1.2
4.4 Application State Handlers
4.4.1 Application Framework
The application is based on the state machine concept. Only one state is active at one time and processes
all the external events. When a state becomes active, it will first initialize all required data and status prior
to receiving and processing external events.
The M851 Kernel provides the mechanism to implement the state machine architecture. The applications
are basically made up of a number of states, where each state handles a specific function of an application.
For example, there is always a banner state, default state, a set state and a popup state.
The Kernel will only know the address of the Application State Manager located in the Application Control
Block. The State Manager will use the system variable CORECurrentState to determine the actual state
handler to execute.
For EEPROM based application, only one state handler is located in the overlay area in heap. There is no
need to have a state manager. The entry in the Application Control block will be the address of the state
handler.
4.4.2 State Transition Diagram
The State Transition Diagram (STD) facilitates the creation of an application in a state machine framework.
The STD shows in a graphic format the available application states, the events the state will be processing
and the associated action and state transitions resulting from the event being processed. With the STD, the
application can be analyzed at this stage for commonality and optimization. Once the STD is complete and
optimized, it becomes the template in coding the state handlers.
4.4.2.1 A State Transition Diagram
The state is represented as a circle. The name of the state describes the general function of the state. The
lines and arrows indicate the events that have occurred and the action to be taken.
4.4.2.2 Application State Transition Diagram
The diagram below shows the state transition diagram for an entire application. This diagram shows the
relationships and interaction between states.
Timex Corporation 15
M851 WristApp Design Guide Rev 1.2
4.4.2.3 Implementing The Application State Transition Diagram
The State Transition Diagram will serve as a guide to develop the application template for all the state
handlers. With the template ready, the actual code to implement the function can be added to the
appropriate sections.
Guidelines in the implementation:
• The arrows pointing from a state indicates the events that occurred while in the state is active.
This will be processed inside a state.
• The arrow pointing into a state from another state will be processed in the new state as a state
entry event.
• The actions are initialized inside the state handler when the event is processed.
The code template below shows the actual code to implement the application state transition diagram
shown in the previous section. The macro code shown below are not the actual macros used in the M851
Kernel, but are used here for purposes of facilitating explanation of the operation of the code. The code
below uses C syntax for discussion purposes only.
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; DEFAULT STATE HANDLER
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
AppDefaultStateManager()
{
switch(CORECurrentEvent)
{
case STATEENTRY:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; STATE ENTRY PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//
Timex Corporation 16
M851 WristApp Design Guide Rev 1.2
// insert State Entry Processing Here
//
break;
case SET1DEP:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; SET 1 DEPRESS PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Breg = SET1BANNERSTATE;
CORE_REQ_STATE_CHANGE;
break;
case MODEDEP:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; NEXT MODE PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
CORE_REQ_NEXT_MODE_CHANGE;
break;
}
}
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; SET 1 BANNER STATE HANDLER
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
AppSet1BannerStateManager()
{
switch(CORECurrentEvent)
{
case STATEENTRY:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; STATE ENTRY PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//
// insert State Entry Processing Here
//
CORE_REQ_TIMEOUT_2SEC;
break;
case HOMEDEP:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; HOME DEPRESS PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Breg = DEFAULTSTATE;
CORE_REQ_STATE_CHANGE;
break;
case TIMEOUTDONE:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; TIMEOUT DONE PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Breg = SETSTATE;
CORE_REQ_STATE_CHANGE;
break;
}
}
Timex Corporation 17
M851 WristApp Design Guide Rev 1.2
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; SET STATE HANDLER
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
AppSetStateManager()
{
switch(CORECurrentEvent)
{
case STATEENTRY:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; STATE ENTRY PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//
// insert State Entry Processing Here
//
break;
case HOMEDEP:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; HOME DEPRESS PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Breg = DEFAULTSTATE;
CORE_REQ_STATE_CHANGE;
break;
case CWPULSE:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; CW PULSE PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//
// Insert CW Pulse Setting Here
//
break;
case CCWPULSE:
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
// ; CCW PULSE PROCESSING
// ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
//
// Insert CCW Pulse Setting Here
//
break;
}
}
4.4.3 State Index
The application can have a maximum of 256 states. The first six states are predefined for common
operation among applications. The predefined states are shown in the table below.
Index Kernel Definition Description
0x00 COREBANNERSTATE The state to proceed on a mode entry.
0x01 COREDEFAULTSTATE The state to proceed to after a mode banner
state and for any mode change requests that
bypasses the mode banner state.
0x02 CORESET1BANNERSTATE Using the common crown handler, this is
the state that will be active when the crown
is placed in the SET 1 position.
Timex Corporation 18
M851 WristApp Design Guide Rev 1.2
0x03 CORESET1STATE Handles the application SET 1 processing.
0x04 COREPOPUPSTATE The state to proceed on an application
popup request through the kernel.
0x05 COREPASSWORDDEFAULTSTATE Password entry default state handler
0x06 COREPASSWORDSETBANNERSTATE Password entry set banner state handler
0x07 COREPASSWORDSETSTATE Password entry set state handler
0x08
0xFF
USER INTERFACE NOTES:
• When in the CORESET1BANNERSTATE, the application must request for a banner timeout
prior to changing state to CORESET1STATE.
APPLICATION NOTE:
• If the application does not support a popup state, the state index COREPOPUPSTATE can be used
as a general purpose state index. Same rule follows for COREPASSWORDDEFAULTSTATE,
COREPASSWORDSETBANNERSTATE and COREPASSWORDSETSTATE. This prevents
skipping of unused state indexes.
• To support password protection, then the following indexes:
COREPASSWORDDEFAULTSTATE, COREPASSWORDSETBANNERSTATE and
COREPASSWORDSETSTATE should be used for common password entry and verification
utility.
General Purpose State Index These states have no kernel restrictions on
…
its usage.
4.4.4 System Events
When the user depresses a switch, or a requested timeout has expired, or a state change was requested, the
kernel will send these events to the foreground state of an application for processing. The following system
events are defined:
System Event Description
COREEVENT_STATEENTRY
COREEVENT_TIMEOUTDONE_LOWRES
COREEVENT_TIMEOUTDONE_HIGHRES
COREEVENT_STICKY_TIMEOUTDONE
COREEVENT_CROWN_EL_DEPRESS
COREEVENT_CROWN_EL_RELEASE
• Used to initialize a state when it becomes
the foreground state.
• Passed always on a mode or state change to
the new state handler.
• When a requested low resolution timeout
expires
• When a requested high resolution timeout
expires
• When a sticky timeout conditions are
completed.
• Passed when the crown is depressed
• Used exclusively for EL control
• Passed when the depressed crown is
released.
• Used exclusively for EL control.
Timex Corporation 19
M851 WristApp Design Guide Rev 1.2
COREEVENT_CROWN_HOME
COREEVENT_CROWN_SET1
COREEVENT_CW_PULSES
COREEVENT_CCW_PULSES
COREEVENT_CW_EDGE_TRAILING
COREEVENT_CW_EDGE_LEADING
COREEVENT_CCW_EDGE_TRAILING
COREEVENT_CCW_EDGE_LEADING
COREEVENT_MODEDEPRESS
COREEVENT_STOPRESETDEPRESS
COREEVENT_STARTSPLITDEPRESS
COREEVENT_MODERELEASE
COREEVENT_STOPRESETRELEASE
COREEVENT_STARTSPLITRELEASE
COREEVENT_POPUPCANCEL
• Passed when the crown returns to the
HOME position from any SET position.
• Passed when the crown is placed in the
SET 1 position.
• Sent to the application every 125ms when
a CW transition of the crown is detected
within the 125ms sample window.
• Used when the application places the
system in pulse mode.
• The variable COREEventArgument stores
the number of pulses detected within the
sample window.
• Sent to the application every 125ms when
a CCW transition of the crown is detected
within the 125ms sample window.
• Used only when the application places the
system in pulse mode.
• The variable COREEventArgument stores
the number of pulses detected within the
sample window.
• Sent to the application on a trailing/leading
edge transition of the crown in the
clockwise direction.
• Used only when the system is not in pulse
mode.
• The application must use only the
TRAILING events when in edge mode.
This is where the iControl hardware makes
a cliking sound.
• Sent to the application on a trailing/leading
edge transition of the crown in the counterclockwise direction.
• Used only when the system is not in pulse
mode.
• The application must use only the
TRAILING events when in edge mode.
This is where the iControl hardware makes
a cliking sound.
• Switch depression was detected.
• Switch releases was detected.
• Sent to the application if any switch events
was detected during melody generation
phase of a popup. The event that cancelled
the melody is stored in
Timex Corporation 20
M851 WristApp Design Guide Rev 1.2
COREEventArgument.
• The current popup melody is cancelled.
COREEVENT_DISPLAY_UPDATE_TODRES
COREEVENT_DISPLAY_UPDATE_TMRRES
COREEVENT_DISPLAY_UPDATE_STPRES
COREEVENT_DISPLAY_UPDATE_SYNCRES
COREEVENT_MELODY_DONE
COREEVENT_END_OF_SCROLLING_MESS
COREEVENT_ICON_REFRESH
COREEVENT_EVENTGENERATION
• Sent to the application to indicate that a
TOD resource (whose display update
request bit was set) has been updated.
• The event is sent directly by the timer
resource when it updates it data set.
• The application must specifically request
the resource to send the update event.
• Sent to the application to indicate that a
TIMER resource (whose display update
request bit was set) has been updated.
• The event is sent directly by the timer
resource when it updates it data set.
• The application must specifically request
the resource to send the update event.
• Sent to the application to indicate that a
STOPWATCH resource (whose display
update request bit was set) has been
updated.
• The event is sent directly by the timer
resource when it updates it data set.
• The application must specifically request
the resource to send the update event.
• Sent to the application to indicate that a
SYNCHRO resource (whose display
update request bit was set) has been
updated.
• The event is sent directly by the timer
resource when it updates it data set.
• The application must specifically request
the resource to send the update event.
• Sent to the application when the melody
generator completes the requested melody.
• The application must specify that a melody
done event is to sent after completion of
the melody.
• Sent to the application when the scrolling
has reached sentinel character.
• The application must request that the event
be sent after completion of the scroll.
• Scrolling is stopped.
• Sent to the application when any LCD
icons for the primary mode is updated.
• The application must request for these
events.
• Sent to the application when a resource
Timex Corporation 21
M851 WristApp Design Guide Rev 1.2
(previously setup for event generation) has
detected a resource specific event
condition.
COREEVENT_COMMDATAPACKETREADY
COREEVENT_COMMFIRSTBYTERECEIVED
COREEVENT_COMMDISCONNECTED
• Sent to the comm application when a
datalink packet has been completely
received by the system
• Sent to the comm application when the
first byte of the datalink packet has been
received by the system.
• Sent to the comm application when the
USB cable has been disconnected.
4.4.5 Requesting System Events
Certain system events are passed to the application for processing only when it is requested by the
application that these events be passed.
4.4.5.1 Switch Depressions
Switch depressions are passed to the applications only when the keymask for the switch has been enabled.
It is advisable to allow only the switches that is used by the current state handler to prevent the switch event
to be passed to the application and thus canceling all blinking, scrolling and timeouts.
The three macros to setup switch depress events are shown below:
CORE_ALLOW_KEYS
CORE_MASK_KEYS
CORE_ALLOW_ALL_KEYMASK
The keymask bits are defined below:
bCOREModeSwitch
bCOREStopResetSwitch
bCOREStartSplitSwitch
bCORECWSwitch
bCORECCWSwitch
bCOREELSwitch
To allow only the mode and the stop/reset switch to be passed to the application, use the following code:
CORE_ALLOW_KEYS (bCOREModeSwitch|bCOREStopResetSwitch);
When using the macro CORE_ALLOW_KEYS, take note to specify the bit mask bCOREModeSwitch in
the default state to allow mode changes.
Using the specified keymask bits, this macro specifies the switches to be
passed as events to the application.
Using the specified keymask bits, this macro specifies which switches
are to be removed from the existing mask.
This allows all switches to be passed to the application.
Timex Corporation 22
M851 WristApp Design Guide Rev 1.2
4.4.5.2 Switch Releases
Switch Release events are only passed to the application if a switch depression was done previously. It is
advisable to suspend switch releases if the application does not handle them in the current state handler to
prevent an unused release event to be passed to the application killing any current blinking, scrolling or
active timeouts.
The application can cancel the release event of the current depressed switch by calling the macro:
HW_KBD_CANCEL_CURRENT_SWITCH_RELEASE;
If an application does not want to handle any switch release events in the current handler, then the macro
below should be used.
CORE_SUSPEND_SWITCH_RELEASE;
To re-enable switch releases to be passed as events again, then the macro below should be called.
CORE_ENABLE_SWITCH_RELEASE;
4.4.5.3 Popup Cancel Event
If a popup state handler generates a melody, the UI specifies that any switch depression will cancel the
melody and proceed with processing. The application can define all switch cases to handle killing the
melody.
The application can make use of the macro shown below. This macro will trap the “allowed” switch
depress events and crown events and wrap it all in one core system event COREEVENT_POPUPCANCEL.
The trapped switches are now stored in COREEventArgument. This will also cancel the currently active
melody.
CORE_REQUEST_MELODY_POPUPCANCEL;
The “allowed” switch depress events mentioned above indicates the switch events that matches the key
mask on the foregroundstate handler. By default, EL switch depression are not passed as an event to the
application. The UI might specify that the EL also cancel a popup. It is required that popup state handlers
that requires the EL to cancel the popup must call the macro CORE_ALLOW_ALL_KEYMASK to have the EL
depress events be processed. When the popup has processed the popup cancel event, it can restore or
specify a new keymask.
4.4.5.4 Ring Edges and Pulses
Ring Trailing Edges are ring events passed to the application by default. Ring Leading Edge Events are
suspended by default.
To request ring pulse events to be passed to the application, the macro below should be called:
CORE_ENABLE_PULSE_MODE;
To request ring edge events again, the macro below should be used:
CORE_DISABLE_PULSE_MODE;
To suspend all ring types of ring edge events, the macro below should be used:
CORE_SUSPEND_RING_EVENTS;
Timex Corporation 23
M851 WristApp Design Guide Rev 1.2
4.4.5.5 Icon Refresh
Certain application requires that it be called whenever changes are being done to the status of the primary
mode icons. These applications may be the TOD and the Options Mode. The TOD application requires an
icon refresh event whenever the user manually enables/disables NightMode or the system automatically
enables/disables Nightmode so it can update the MOON icon. The Options mode requires the update of the
NightMode or the Chime whenever the system changes the current status so it can display the appropriate
message. In the option mode, the event was used to update the message along with the icon depending on
the UI requirement.
To enable or disable receiving the event COREEVENT_ICON_REFRESH, then the macros below should be
called:
CORE_BACKGROUND_ICON_REFRESH_ENABLE;
CORE_BACKGROUND_ICON_REFRESH_DISABLE;
4.4.5.6 End of Scrolling
The application can request an event everytime a message that is scrolling reaches the end of the message.
The macro is below to send the “end of scrolling” event to the application. This will also stop scrolling the
message once it reaches the end of the message. If the size of the message does not require scrolling, then
the event COREEVENT_END_OF_SCROLLING_MESS is sent after the message is displayed on the LCD.
LCD_SCROLL_RAM_OR_ROM_MSG_MAIN_DM_LINE2 EVENT_ON;
If the application want the message to scroll continuosly, then the macro below is used:
LCD_SCROLL_RAM_OR_ROM_MSG_MAIN_DM_LINE2 EVENT_OFF;
4.4.5.7 Resource Updates
By default, on any state change, resource display updates are disabled by the core. To have resource
display updates event passed to the application, the application must make an API call to the resource to
request for updates. These events can then be used to display the new or updated data.
An application may request different types of resource to send the update events. Each resource type will
send a unique system event. To request (and cancel) a resource update, use the followingAPIs:
KTOD_ENABLE_DISP_UPD_SEC_EVENT
KTOD_DISABLE_DISP_UPD_SEC_EVENT
KSTP_ENABLE_DISP_UPD_EVENT
KSTP_DISABLE_DISP_UPD_EVENT
KTMR_ENABLE_DISP_UPD_EVENT
KTMR_DISABLE_DISP_UPD_EVENT
KSYN_ENABLE_DISP_UPD_EVENT
KSYN_DISABLE_DISP_UPD_EVENT
4.4.5.8 Timeouts
Application must request application timeouts for the system to generate the timeout done events. The
events are passed when the timeout counters decrements to zero.
CORE_REQ_TIMEOUT_HIRES <timeout_count_hires>;
CORE_REQ_TIMEOUT_LORES <timeout_count_lores>;
Timex Corporation 24
M851 WristApp Design Guide Rev 1.2
CORE_REQ_TIMEOUT_STICKY <timeout_count_hires >;
The parameter timeout_count_lores is specified in seconds. The following equates are available for
timeout_count_lores:
Equate Description
TIMEOUTLORES_2SEC
TIMEOUTLORES_3SEC
TIMEOUTLORES_4SEC
TIMEOUTLORES_10SEC
TIMEOUTLORES_20SEC
2 seconds
3 seconds
4 seconds
10 seconds
20 seconds
The parameter timeout_count_hires is specified in increments of 0.125 seconds. The following equates are
available for timeout_count_hires:
Equate Description
TIMEOUTHIRES_P250SEC
TIMEOUTHIRES_P5SEC
TIMEOUTHIRES_1SEC
TIMEOUTHIRES_1P5SEC
TIMEOUTHIRES_2SEC
TIMEOUTHIRES_3SEC
TIMEOUTHIRES_4SEC
TIMEOUTHIRES_5SEC
TIMEOUTHIRES_6SEC
0.250 seconds
0.500 seconds
1 second
1.500 seconds
2 seconds
3 seconds
4 seconds
5 seconds
6 seconds
4.4.6 State Manager
There is no need for a state manager for EEPROM based applications. This is because the kernel will only
load the foreground state handler and into the same base address in the overlay area. The State Manager
address specified in the application control block will store the base address for state handler.
4.4.6.1 Display Clearing On State Change
Using the macro CORE_REQ_STATE_CHANGE to request a state change, the lcd display is always cleared.
To prevent the display from being cleared during a state change, then the macro
CORE_REQ_STATE_CHANGE_NO_CLEAR_DISPLAY should be used.
4.4.7 Mode Banner State Handler
The core will always make the mode banner the state to proceed on a mode change.
It is advised that the mode banner state define a popdown state usually the default state. This prevents a
popup from occurring in the middle of the banner timeout from returning to the banner state. To set the
popdown state, the following code is used:
It is advised that the mode banner utilize the following code to display the mode banner message. This will
allow the user through the PC to change the mode banner name.
// set popdown state should a popup occur during mode banner timeout
CORE_SET_POPDOWN_STATE OPTDEFAULTSTATE;
// display the mode banner for the application
AReg = CORECurrentMode;
CORE_CALL_MODE_NAME;
Timex Corporation 25
Loading...