Developing your own software for Dynawa TCH1.

You have four choices of how to approach Dynawa software development. These are explained below on this page. But first, to understand the differences between them, let's explain the default TCH1 boot process in some detail:
  1. Power is switched on or TCH1 is reset.
  2. Reset controller is started in internal memory. This lowest-level code is running independently on the main processor and allows the user to reset the device or re-flash its boot loader.
  3. Main CPU is started and begins executing the boot loader from TCH1's internal memory.
    1. If the boot loader detects the special button combination, it switches the device to mass storage mode and allows access to internal microSD card (which is formatted using FAT filesystem). To exit mass storage mode, you must reset the device.
  4. The boot loader performs basic hardware check and initialization.
  5. The boot loader looks for a file called main.bin in microSD card's root directory. This is a boot image containing native RISC code. This file is loaded to a fixed memory address and executed.
    1. If the boot image cannot be loaded / executed, the boot loader halts and waits for reset.
  6. The default main.bin file contains slightly modifier Lua compiler and interpreter. It implements several additional functions in the Lua environment (identified by "dynawa.*" prefix) to access TCH1 hardware.
  7. Lua script in file /_sys/boot.lua is executed. This script loads other Lua scripts and creates WristOS environment. WristOS itself is written in Lua.
  8. Core WristOS applications are loaded (from /_sys/apps/) and started, e.g. Bluetooth services, internal messaging, default clock...
  9. User applications are started from the /apps/ directory and default clock face is displayed.
You can override any of the above phases when creating your own TCH1 software. There are four basic tiers of software development, defined below. Deciding which of these four tiers you will use determines what development documentation you need to study.

Tier 3 development - WristOS apps (Click for Details)

Your apps are written as Lua scripts (text files) residing in /apps/ directory on the SDcard. You don't have to worry about their compilation / execution. To develop them, you need your favorite text editor.

  • You can write your first application in minutes using only text editor.
  • Your applications are written in high-level Lua language (no worries about pointers, garbage collection, compiling etc.) and can use cooperative multitasking.
  • You can look at the default TCH1 apps and create your own by simply modifying those.
  • WristOS takes care of more complex stuff for you (Bluetooth communications, screen management, inter-app messaging, app management etc.)
  • At least intermediate knowledge of Lua is mandatory for anything else than "Hello World" app.
  • If you do stupid things you can crash the whole system easily (there is no process isolation or user permissions)
  • Applications are slower to start and run than native code applications.
  • No preemptive multitasking is available.
  • You are bound by the WristOS API. Although there are hooks provided to easily extend the existing systemand override its basic functionality (for debugging purposes, for example).

Tier 2 development - Roll your own OS in Lua (Click for Details)

You provide your own /_sys/boot.lua and build your own operating system (written in Lua).

  • More freedom than Tier 3 development. You decide what is an "application", how does it work, how it's installed and started, etc...
  • You can use the existing WristOS and modify it to suit your needs.
  • No need for any compilers - the text editor is your friend.
  • Your system and applications are written in high-level Lua language (no worries about pointers, garbage collection, compiling etc.)
  • The default boot image (main.bin) takes care of the most complex stuff (low-level access to hardware, basic input and output)
  • Many hours of work (probably days) needed before you produce anything even remotely useful (e.g. displaying time and date).
  • Requires excellent knowledge of Lua
  • You have to write your own software for any device (e.g. the mobile phone) that should communicate with TCH1.
  • You are bound by Lua boot image API (predefined functions with "dynawa.*" prefix).
  • You cannot easily extend your system using anything else than Lua.

Tier 1 development - Roll your own OS in any language

You provide your own main.bin boot image.

  • You can compile your own interpreter for any language you like (e.g. Python, Perl, Lisp, Basic...).
  • You can create your own high level OS with real preemptive multitasking or install existing full-fledged OS (Linux).
  • You have complete freedom about how the SDcard will be used. The only exception is that the main.bin boot image must be located in card's root directory.
  • You can still use the original boot loader's mass storage mode to transfer files from your computer to device's SDcard
  • You must create your own toolchain for generating RISC native code or you must be able to install, understand and customize our toolchain and C sources.
  • You must implement even the most mundane libraries yourself: E.g. memory allocation, button input, putting pixels to screen, reading and writing timers, serial and Bluetooth communication, based on the hardware documentation (hundreds of pages from different manufacturers).
  • Several months of work before you create anything more complex than Tetris.
  • You must perfectly understand all the hardware components of TCH1 and learn to communicate with them on the lowest level.

Tier 0 development - Roll your own everything

You provide your own boot loader and everything else.

  • You can customize anything and everything.
  • You can even change how the default reset controller works but this is really not recommended because you can completely brick your device very easily.
  • You can brag to everyone how hardcore you are.
  • All the "Cons" as in Tier 1 but much more so. You even have to write your own routines to get any data to the device.
  • You need additional specialized software to re-flash the device's memory.
  • It's insane to attempt this without specialized debugging hardware.
  • Your spouse will leave you.