Timers do not have to count down constantly; they can be started and stopped.

Assigning a non-zero value to a timer (i.e., in the Variable Set/Math block) variable always enables the countdown. There is also a somewhat redundant Timer Start block, which does the same job. To pause the timer without resetting its value, use the Timer Stop block.

In this project, pressing the MD button starts the timer. If you keep the button pressed, the timer will count to zero. If you release the button while the timer is still counting, the timer will be stopped, and its current value will be printed to the console.

Up to this point, all blocks of every project were connected sequentially, like beads on a string. This means that an output of one block only connected to a single input of the next block. This doesn't have to be the case. It is possible to connect one block's output to several downstream blocks in a fashion called block stacking.

This project demonstrates how the stacking order of the blocks on the flowchart defines the order of execution. The rule is simple: Out of N stacked blocks, the topmost block executes first, and the lowest block executes last.

Two of the three stacked blocks in this application perform calculations, while the third one prints the result. If the stacking order is left unchanged, the result will be 30. Swap around the topmost and middle stacked blocks, and the result will be 20! Move the Debug Print block to a new position, and you will print the var_x value before all the calculations are performed!

This is the first project in the Tutorial where we use the On Boot event block. Use this block when you need to perform some actions right after the device (re)boots.

This project adds a bit of complexity to the Variables and Arithmetic application of the previous topic. Pressing the MD button will keep incrementing the Counter variable, but the value of this variable will be reset to 1 once it exceeds 10.

Your TPS' MD button was introduced in the Hello, World project.

The value of the Counter variable is limited to 10 using a Condition block. It introduces the flow forking: Comparing the Counter value to 10 results in the execution taking the True or False path in the application's logic.

The project also demonstrates that two execution paths may converge on a single point. This is known as a join.

Eagle-eyed readers will also notice another difference from the Variables and Arithmetic application: Rather than relying on the Arithmetic block to perform calculations, this application takes advantage of the more versatile Variable Set/Math block:

The Variable Set/Math block allows entering math formulas, and these can go way beyond simple addition, subtraction, multiplication, and division offered by the Arithmetic block. The formulas must comply with the syntax of the Tibbo BASIC language. Luckily for AppBlocks' users, this syntax largely follows the "natural" way of writing formulas.

This project introduces a new storage type -- settings. Settings are kept in your device's EEPROM. They are referred to as "persistent storage" because they retain their values even when the device is powered off. Settings are incredibly important, as they provide a way to store your application's operating parameters.

This project builds on the Timers application. It uses a single setting to store the reload value for a (one-shot) timer.

Settings are defined on the Settings page of the Features tab:

Every time you add a setting, a corresponding variable of the same name is created. This is very similar to (one-shot) timers, which also have corresponding variables.

Settings have the same list of types available to them as variables. You can directly use settings in math expressions, just as you would use regular variables. You will notice that in addition to all the properties variables have, settings of certain types can also be limited in the value range:

Since the settings are stored in the EEPROM, and EEPROMs have the maximum number of write cycles they can endure, avoid designs that constantly rewrite the setting data. Depleting an EEPROM IC is not as impossible as one might think!

Settings as Links to the Outside World​

Since settings store your application's operating parameters, it is usually necessary to access them "from the outside." This project facilitates editing its setting through the device's web interface.

The web interface is enabled through the Web Dashboard page of the Features tab. Inside the Web Dashboard, there is a Settings sub-page. Every setting that needs to be exposed through the web interface must be manually added there. Since this application only has a single setting, it is this one setting that has been added to the Settings sub-page of the General group.

Once you add anything to the Web Dashboard, the Web (HTTP) Server is also automatically enabled.

Accessing the Web Interface​

To access the web pages of your TPS, you will need to assign a valid IP address to it first. This is where the Ethernet page of the Features tab comes into play. The DHCP property is set to Enabled by default. Your TPS device will get a valid IP address from the DHCP server, but how will you know what this IP address is?

The simplest way is to use the Device Explorer:

Open it after the application is uploaded onto the device and starts running. Click Refresh to make sure you are looking at the latest data. The Device Explorer can be accessed at any time by pressing this button in the bottom left corner of the page:

Note the IP of your device, and point your browser to this IP. Voila, you have access to your application's lone setting:

Responding to Setting Value Changes​

There is still one last trick to show you in this project: Responding to setting (variable) value changes. The On Variable Changed event block triggers every time the corresponding variable changes its value. In this application, changing the setting value will cause a debug message to be printed.

You can use the On Variable Changed block to report value changes for plain variables and settings but not for timers.

This application introduces timers. When a timer is preloaded with a value greater than zero, it counts down at the rate of one count per second. Once the timer reaches zero, it generates an event.

In this application, a timer event causes the timer to be reloaded with the same value, causing it to count down again, and so on.

Times are defined on the Timers page of the Features tab:

Adding a timer automatically creates a variable of the same name.

The type of such timer-linked variables is a dword, which is a 32-bit integer value. In Variables and Arithmetic, we already explained that variable types other than the four types explicitly available to the user exist in "certain parts" of the system. This is one such case. You cannot directly declare a variable of the dword type, but you can create a timer, which will be assigned the dword type automatically.

You can use timer variables anywhere in the application, just as you would use plain variables. The only difference is that when a timer runs, its value automatically decrements with each passing second until it hits zero. Once a timer reaches zero, the On Timer event is generated. This application relies on this event to reload the timer.

Your application may have multiple timers and multiple On Timer event blocks. The properties sheet of the On Timer block allows you to select which timer this block belongs to. However, It is impossible to have multiple On Timer blocks for the same timer.

This kind of timer is often referred to as a one-shot timer. It is thus called because the timer stops once the countdown reaches zero. AppBlocks also has periodic timers -- introduced later in this Tutorial -- that keep auto-reloading with the same initial value.

Back to the application now. So, every time the timer expires, it is reloaded by the value stored in the timer_reload_value variable... but where does that variable get its value? The answer: Each variable has a default value property. You can edit default values on the Variables page of the Features tab:

AppBlocks has another type of timer called a periodic timer. Unlike the plain (one-shot) timers discussed in the previous topics, periodic timers:

• Are configured at design time and cannot be reloaded at run time
• Are always running (cannot be stopped)
• Cannot be restarted
• Auto-reload and start counting down again as soon as they reach zero

Periodic timers are implemented as On Time Period event blocks. To configure the timer period, drag the On Time Period block onto the canvas, click on it, and set the desired period in the block's property sheet:

Here is a simple project with two periodic timers, one programmed for a 5-second interval and another one -- for a 7-second interval.

The project also introduces two new useful blocks: LED Pattern and Buzzer Pattern. Every time a 5-second timer expires, an LED pattern will "play" on your TPS' red and green status LEDs. Every time a 7-second timer expires, your TPS will beep a buzzer pattern. Again, the patterns for the LED Pattern and Buzzer Pattern blocks are set on the blocks' property sheets:

LED Pattern Format​

The pattern used in this application -- "G-R-B" -- means:

• Beat 1: Green status LED is on
• Beat 2: No LEDs are on
• Beat 3: Red status LED is on
• Beat 4: No LEDs are on
• Beat 5: Both green and red status LEDs are on

So, G, R, B, and - are like beats in a melody -- each beat is allocated the same standard time. Your pattern may include up to 16 beats.

There are also two modifiers:

• Adding * anywhere in the pattern makes that pattern play twice as fast. You can add up to three * characters to achieve the x8 pattern speed.
• Adding ~ anywhere in the pattern will make this pattern loop, i.e., play repeatedly, until another pattern is loaded (using another LED Pattern block).

Buzzer Pattern Format​

Your beats may include the following:

• B for "beep," and
• - for "silence"

As with the LED patterns, you can add up to three * characters to increase the pattern speed and ~ to make it loop.

This project is the first one that "gives you a reason" to open the Features tab. Nested between the Hardware configuration and AppBlocks (dynamic behavior) tabs, the Features tab comprises a collection of pages that define everything that is permanent in your project. Your application's variables are one such entity in the sense that variables are not created and deleted dynamically but exist as a static list.

To add, delete, or edit the list of variables, turn to the Variables page of the Features tab:

AppBlocks supports four fundamental variable types:

• Numerical (single-precision floating point), a.k.a. a "value" or a "number" type
• String (up to 253 single-byte characters)
• Date Time (1-second resolution)
• Date

A few other variable types exist elsewhere in the system, but only these four are explicitly available.

Once you have at least one numerical variable, you can perform arithmetic operations on this variable using the Arithmetic block. In this simple application, the value of the Counter variable is incremented and printed to the console every time you press the MD button. To see or edit the block's contents, click on the block to open its properties:

The MD button was introduced in the Hello, World project.